Hermesエージェントに自分専用のライフOSとセカンドブレインを構築させる方法について、これまで見た中でも最高クラスの解説記事
EPが公開したのは、4つの連携レイヤーを作り出すたった一つのプロンプト:
1. あなたの信頼できる情報源となるMarkdownナレッジベース
2. 今後どのセッションでも場所がわかるようにする永続的なメモリポインタ
3. コンテキストの取得・保存・修正を行うエージェントスキル
4. 習慣・目標・プロジェクト・振り返りをセッション間で同期する、プライベートなライフトラッカー
理解するのはなかなか大変なので、システム全体を図解してみた。保存して、このプロンプトと一緒にエージェントに送ってみて
EP@eptwts
as promised, this prompt will change your life...
(send it to your hermes agent & thank me later)
----------------------------------------------
create this system - a generic, durable, private, file-based knowledge base and synchronized life tracker that works across sessions without making the user repeat context.
build and test the working system. inspect first and extend any existing knowledge base or tracker instead of creating a competing one.
## core outcome
create four connected layers:
1. a portable markdown knowledge base that is the detailed source of truth.
2. a compact persistent-memory pointer that tells future agents where the knowledge base lives and how to retrieve from it.
3. reusable agent skills and scripts for capturing, retrieving, correcting, and maintaining context.
4. a private life operating system for checklists, habits, goal breakdowns, projects, reviews, and read-only life data, with the agent handling planning and contextual writes.
all four layers must use the same conventions, dates, privacy rules, and source hierarchy.
## non-negotiable principles
- files are the authoritative detailed record. do not use model memory as the database.
- persistent memory stores only the knowledge-base path, stable user preferences, and essential retrieval routing.
- conversation history is secondary context, not proof of current state.
- never invent facts to fill empty fields.
- distinguish direct user reports, verified facts, observations, preferences, and hypotheses.
- preserve uncertainty and conflicts instead of silently resolving them.
- user corrections override summaries while important superseded claims remain traceable.
- use exact dates when known and explicitly record approximate date precision when not known.
- current summaries answer “what is true now?” while dated records answer “what happened and when?”
- markdown is authoritative; indexes, csv, charts, sqlite, and search manifests are rebuildable derivatives.
- optimize for fast natural-language capture. do not turn every casual update into a long data-engineering job.
- default to one targeted write plus one concise acknowledgement for routine updates.
- do not create multiple writable copies of the same fact.
- use lexical search, ids, aliases, tags, dates, and one-hop links before considering embeddings.
- never store credentials, passwords, cookies, recovery codes, keys, seed phrases, payment authentication, or portal credentials.
- do not send private knowledge-base content to third parties without explicit approval.
## phase one: discovery and user rules
before creating files:
1. search for an existing knowledge base, notes vault, tracker, or personal database.
2. if one exists, extend it unless the user explicitly requests a replacement.
3. ask no more than four foundation questions unless the answers are already available:
- what should the agent call the user, and which timezone should dates use?
- what information must never be stored or must be generalized?
- which life domain matters most right now?
- which existing documents, links, exports, or records should be ingested first?
4. write the answers into the system rules before capturing personal context.
done: one knowledge-base location, timezone rule, and privacy/exclusion list are agreed.
## phase two: knowledge-base structure
create this portable structure and adapt domains only when useful:
```text
life-knowledge-base/
├── readme.md
├── agent_rules.md
├── 00-index/
│ ├── master_index.md
│ ├── open_questions.md
│ ├── people_index.md
│ ├── projects_index.md
│ └── sources_index.md
├── 01-inbox/inbox.md
├── 10-profile/profile.md
├── 20-timeline/
│ ├── timeline.md
│ └── events/yyyy/
├── 30-health/
│ ├── health_summary.md
│ ├── conditions/
│ ├── medications/
│ ├── procedures/
│ ├── tests/
│ └── logs/
├── 40-nutrition/
│ ├── nutrition_summary.md
│ └── logs/
├── 50-projects/
│ ├── projects_summary.md
│ └── projects/
├── 60-finance/finance_summary.md
├── 70-goals/
│ ├── goals_summary.md
│ └── goals/
├── 75-ideas/
│ ├── ideas_index.md
│ └── ideas/
├── 80-interests/interests_summary.md
├── 85-resources/resources.md
├── 90-sources/
│ ├── records/
│ └── files/
└── 95-system/
├── schema.md
├── changelog.md
├── intake.md
├── backups.md
└── templates/
```
rules for the structure:
- keep one concise canonical summary per major domain.
- put detailed history in dated event or entity notes, not in giant summaries.
- use one file per durable project, goal, condition, medication, decision, or entity when it improves retrieval.
- keep one categorized resources file until its size harms retrieval.
- preserve original documents in `90-sources/files/` and create a source record in `90-sources/records/`.
- put unprocessed material in the inbox, then clear or link it after normalization.
- append significant structural or high-value context changes to the changelog.
done: every directory has a purpose, all entry points exist, and the master index links every canonical summary.
## phase three: schema and provenance
use yaml frontmatter where it improves retrieval. only include applicable fields.
```yaml
---
id: evt-yyyymmdd-nnn
type: event
subtype: health | nutrition | project | personal | finance | goal
record_status: current | historical | resolved | uncertain | superseded
epistemic: fact | self_report | observation | hypothesis | preference
occurred_at: yyyy-mm-dd
valid_from: yyyy-mm-dd
valid_to: null
recorded_at: yyyy-mm-dd
created: yyyy-mm-dd
updated: yyyy-mm-dd
people: []
projects: []
source_ids: []
confidence: high | medium | low
verification: verified | user_reported | unverified
needs_verification: false
supersedes: []
aliases: []
tags: []
---
```
use stable identifier prefixes:
- `evt-` event
- `src-` source
- `sym-` symptom
- `cond-` condition or diagnosis
- `med-` medication
- `sup-` supplement
- `lab-` laboratory result
- `per-` person
- `org-` organization
- `prj-` project
- `dec-` decision
- `goal-` goal
- `idea-` inactive idea
- `res-` curated external resource when individual ids are useful
record bodies should use this pattern when relevant:
```markdown
# human-readable title
## summary
## details
## evidence and provenance
## connections
## uncertainty and follow-up
```
source records include origin, known author or provider, document or event date, date received, path or url, extraction status, and reliability.
done: every consequential claim links to a source or is labeled user report, observation, preference, or hypothesis.
## phase four: domain-specific rules
### projects
for each active project, capture:
- purpose and desired outcome
- status and current phase
- owner and collaborators
- target users
- scope and non-goals
- architecture or operating model
- current priorities
- decisions and rationale
- constraints, risks, metrics, deadlines, and review triggers
- important links, repositories, documents, and source records
- next actions without duplicating facts from the canonical project note
separate facts, assumptions, forecasts, decisions, and experiments. give time-sensitive metrics an `as_of` date and source.
### resources
when the user saves a url:
1. read the original source before summarizing it.
2. store the canonical url and date accessed.
3. record its purpose, useful capabilities or ideas, limits, and future retrieval triggers.
4. preserve installation or invocation commands only when the source documents them.
5. do not treat a saved resource as endorsed or verified truth.
6. reopen the original source before exact quotation, installation, purchase, or consequential use.
### goals
capture outcome, baseline, target, rationale, constraints, deadline, measurement, plan, review cadence, progress, and adjustment trigger. distinguish goals, projects, milestones, tasks, and recurring habits.
break goals into this hierarchy when useful:
```text
life area
└── goal
├── success criteria
├── milestones
│ └── projects or workstreams
│ └── next actions and checklists
└── recurring habits or routines
```
every active goal must have:
- a clear outcome and definition of done
- a small number of measurable success criteria
- the next milestone
- at least one concrete next action when action is possible
- any recurring habits that support it
- a review date or cadence
- a status such as `not_started`, `active`, `blocked`, `paused`, `completed`, or `abandoned`
- a reason for changing, pausing, or abandoning it
do not create fake precision. some goals are binary, some are milestone-based, some use a percentage, and some require a qualitative review.
### habits and routines
- support daily, weekly, selected-weekday, interval, and minimum-frequency habits.
- allow a parent habit to contain individually checkable subtasks.
- distinguish a habit from a temporary checklist and from a project task.
- record completion only from an explicit user action or reliable evidence.
- do not infer completion because a reminder fired or time passed.
- permit pause, skip, replacement, and rescheduling without corrupting historical completion.
- calculate completion only on scheduled days; unscheduled days are not failures.
- avoid worshipping streaks. show consistency, rolling completion, and recovery after missed days.
- let habits link to the goals they support, but never claim that habit completion caused the goal outcome.
### general life data
support user-defined numeric, boolean, categorical, duration, count, rating, or text metrics, including sleep, mood, energy, symptoms, exercise, focus, learning, social time, finance, body measurements, nutrition, weight, or medication adherence.
each metric defines its id, label, type, unit, valid range or options, aggregation, chart, privacy, and whether missing means unknown, zero, not applicable, or incomplete.
### ideas
ideas use `not_started`, `exploring`, `promoted`, `parked`, or `rejected`; when work starts, preserve the idea and create a bidirectional project link.
## phase five: capture and retrieval behavior
### capture workflow
when the user provides durable context:
1. decide whether it is stable and useful enough to save.
2. search for the authoritative existing note before writing.
3. append to an existing same-day event when appropriate instead of creating fragments.
4. preserve the user’s wording when nuance matters.
5. update the smallest authoritative set of files.
6. update a canonical summary only when the new information changes current understanding.
7. preserve corrections and superseded history.
8. verify with one representative search.
9. acknowledge the capture briefly.
for large imports, preserve the original and one source-grounded summary; deeply normalize only when requested.
### retrieval workflow
before answering a question about the user:
1. read `agent_rules.md`.
2. search the original knowledge-base files.
3. read the relevant canonical summary.
4. read newer matching events and entity notes.
5. follow source links for consequential claims.
6. distinguish current, historical, resolved, uncertain, and superseded context.
7. state uncertainty and conflicts explicitly.
8. cite note paths, source ids, and dates when accuracy matters.
9. obey the user’s requested scope and exclusions literally.
completion criterion: the answer can be traced to current notes and newer records rather than stale memory.
## phase six: persistent memory
save one compact durable memory entry that says:
- the absolute knowledge-base path
- that it is the detailed source of truth
- agents must search it and follow `agent_rules.md` before answering personal questions or storing substantial context
memory holds only stable routing preferences, never histories, logs, or raw documents.
## phase seven: agent skills
create these reusable skills with yaml frontmatter, lowercase hyphenated names, “use when” descriptions, versions, tags, steps, pitfalls, and verification checklists.
### `life-knowledge-base`
responsibilities:
- search and read personal context
- capture durable updates
- apply privacy and correction rules
- maintain summaries, events, entities, indexes, sources, and changelog
- perform evidence-only exports
- validate links, ids, dates, csv headers, and retrieval
include scripts for deterministic validation and optional lexical indexing. scripts must never print secrets.
### `life-tracker`
responsibilities:
- read today’s checklist
- complete or reopen a habit or nested subtask only from explicit user confirmation
- create and maintain recurring habits, schedules, routines, and temporary checklists
- connect habits and tasks to the goals or projects they support
- log any registered life metric from natural-language reports
- add, correct, and remove structured events or measurements
- read goal, project, habit, and custom-metric trends
- update metric definitions or targets only when the user explicitly requests it
- use the user’s timezone for dates
natural-language logging rules:
- log only what the user says actually occurred or completed, not intentions or reminders.
- preserve a useful human-readable description, quantity, unit, category, and source if relevant.
- use exact values when supplied.
- if missing details materially affect a value, ask one focused question or obtain permission to use an estimate.
- mark every agent-derived value as estimated and preserve the assumption.
- after a write, report the date, record, estimate status when relevant, and updated progress or aggregate.
- after corrections or batches, read the data back from the api.
- never guess record ids when deleting; read first.
### `goal-planning`
responsibilities:
- convert broad ambitions into clear outcomes and definitions of done
- identify constraints, baselines, success criteria, milestones, projects, habits, and next actions
- keep the plan small enough to execute
- schedule reviews and define adjustment triggers
- distinguish outcome progress from activity volume
- preserve the user’s priorities instead of inventing new goals
- update the canonical goal note and tracker hierarchy together without duplicating truth
### `project-context`
responsibilities:
- create and maintain project notes
- break projects into milestones, workstreams, tasks, dependencies, and the next executable action
- capture decisions, assumptions, constraints, metrics, links, deadlines, blockers, and review triggers
- retrieve current project state before planning or execution
- prevent stale summaries by checking newer dated records
- archive completed tasks without losing decisions or project history
### `life-review`
responsibilities:
- run daily, weekly, monthly, and quarterly reviews without duplicating canonical records as cron jobs
- summarize completed actions, stalled goals, project blockers, habit consistency, and meaningful metric changes
- distinguish observations from explanations
- identify a small number of decisions and next actions
- update goal or project status only with evidence or user confirmation
- avoid guilt-oriented language and avoid turning every metric into a target
### `resource-library`
responsibilities:
- inspect original urls
- create concise retrieval-oriented resource entries
- prevent unsupported summaries
- search the library before recommending a previously saved tool or source
done: each skill predictably changes behavior, uses exact operations where possible, and validates independently.
## phase eight: private life tracker
build a minimal private life operating system sharing authenticated server state with agent skills. it guides today’s actions, routines, goals, projects, reviews, and life data; stuff like nutrition and weight is good to track too.
use a connected hierarchy rather than unrelated lists:
```
life area → goal → milestone → project or workstream → task
└────────→ recurring habit or routine
metric definition → dated observations → aggregates and trends
```
keep it flexible: a goal may need only a checklist or several projects and habits.
### tracker information architecture
use four primary views:
1. `today`
- one focused interactive checklist
- previous day, current date, next day
- the day’s habits, routine subtasks, due goal actions, and project next actions in one stable vertical list
- expandable parent habits with individually checkable subtasks
- completed habits in a collapsed section
- completion count and progress by day
- links showing which goal or project an action supports
- concise safety guidance where relevant
2. `goals`
- active goals grouped by life area
- outcome, definition of done, status, target date when set, and next review
- milestones and progress based on explicit success criteria
- supporting projects, habits, and next actions
- blocked, paused, completed, and abandoned states without deleting history
- an agent command or conversation is used to create, restructure, or reprioritize goals; the web app may allow simple checklist completion
3. `projects`
- active projects with status, phase, owner, deadline when applicable, blockers, and next action
- expandable milestones, workstreams, and task checklists
- project health based on explicit rules, not invented percentages
- recent decisions and updates linked to the knowledge base
- completed and archived projects remain retrievable
4. `data`
- read-only dashboard
- no contextual log, metric, target, project, goal, or note form inputs
- no direct delete or correction controls
- the agent is the write interface for contextual life data
- compact summaries for goal progress, project delivery, habit consistency, and selected custom metrics
- a metric picker generated from the user’s metric registry
- one readable chart at a time rather than a wall of graphs
- useful chart types chosen by data semantics: line, bar, calendar, count, distribution, or categorical history
- range controls such as 7, 30, 90, and 365 days where useful
- coverage counts showing how many observations support each average
- automatic refresh on focus and a reasonable polling interval so agent writes appear without manual editing
the web app handles explicit completion toggles. the agent handles goal creation, project restructuring, metric definitions, logs, corrections, and interpretation using natural language and knowledge-base rules.
### data semantics
- every metric declares its own missing-value semantics.
- unknown, zero, not applicable, not scheduled, and not completed are different states.
- averages use only valid observations unless the metric definition explicitly says otherwise.
- intermittent metrics use only recorded measurements; missing days are ignored.
- habit completion averages use only scheduled habit days.
- goal progress is derived from success criteria or completed milestones, not task volume alone.
- project progress is derived from explicit milestones or task scope and must never be fabricated from elapsed time.
- paused or intentionally skipped habits are not silently counted as failures.
- do not imply that correlations among habits, metrics, goals, health, or projects prove causation.
- store timestamps and selected dates separately.
- preserve observations, completions, events, and status changes for correction without rewriting history.
- optional modules add rules, such as nutrition averages excluding unlogged days and weight trends excluding missing weigh-ins.
### api and security
create authenticated endpoints for:
- reading dated checklist state
- completing or reopening a habit or nested subtask
- creating and updating goals, success criteria, milestones, review dates, and goal status
- creating and updating projects, workstreams, tasks, dependencies, blockers, and project status
- linking habits, tasks, projects, and goals
- reading the data dashboard
- defining custom metrics and aggregation semantics
- adding, correcting, and deleting dated metric observations or life events
- changing tracker targets, schedules, and review cadences
requirements:
- browser sessions use a secure, http-only, same-site cookie.
- agent access uses a separate bearer credential stored outside source code.
- never expose bearer credentials in browser bundles, urls, logs, docs, or public environment variables.
- validate dates, primitive types, identifiers, ranges, unknown fields, and scheduled-habit constraints.
- prevent concurrent checklist and agent updates from data loss.
- make storage replaceable: local sqlite or json for local use, and an authenticated durable store for deployment.
- include backup and recovery instructions.
### design rules
- use a restrained neutral interface with readable system typography.
- primary text must be readable without zooming.
- frequent touch targets must be at least 44 by 44 pixels.
- use one centered content column for the checklist.
- avoid permanent calendar strips, three-column task boards, repeated summary cards, and simultaneous charts.
- show normal sync state as a subtle indicator; show errors only when actionable.
- provide explicit loading, empty, offline, retry, and all-complete states.
- use accessible names, visible focus, selected states, chart descriptions, and meaningful text alternatives.
- avoid decorative copy, excessive borders, tiny uppercase labels, and technical api controls in primary navigation.
## phase nine: tests and validation
create and run tests for:
- schema normalization and invalid data rejection
- canonical-summary and event separation
- correction and supersession behavior
- privacy exclusions and secret scanning
- source and provenance links
- representative search retrieval
- checklist parent and nested-subtask completion
- habit schedules, skips, pauses, and unscheduled-day semantics
- goal decomposition, milestone completion, and review dates
- project task, dependency, blocker, and status transitions
- links among goals, projects, habits, and tasks
- concurrent updates without lost state
- natural-language agent logging commands
- custom metric validation and aggregation rules
- missing values following each metric’s declared semantics
- intermittent measurements excluding missing days
- goal progress not being inferred from elapsed time or unrelated task counts
- empty and sparse data
- unauthorized api requests
- mobile layout without horizontal overflow
- minimum touch targets and accessible names
- chart metric and range switching
- data view containing no form inputs
- production build and live authenticated smoke tests
also validate:
- all required files exist
- frontmatter parses
- ids are unique
- internal links resolve where required
- csv headers parse
- no secret appears in source or output
- the working tree or artifact directory contains every promised deliverable
## final delivery
finish by reporting:
- the knowledge-base path
- the tracker path and live url if deployed
- every created skill and its trigger
- privacy rules and storage model
- tests executed and actual results
- backup and recovery method
- any assumptions or remaining user decisions
provide a short usage guide with examples such as:
- “remember that i prefer…”
- “save this resource…”
- “what do we know about this project?”
- “turn this goal into milestones, projects, habits, and next actions.”
- “what should i do today to move my active goals forward?”
- “i completed the morning routine.”
- “mark the research milestone complete and show the next project blocker.”
- “create a weekly habit for three focused work sessions.”
- “log my energy as 7 out of 10 and two hours of focused work.”
- “run my weekly review.”
- “show goal progress, project status, habit consistency, and the life metrics i selected.”
- “log this meal” or “record my weight” when the user has enabled those optional metrics.
claim completion only after the knowledge base, skills, tracker, tests, and verification artifacts exist and run.
explain to the user what was just created after creation & how they can use it
