memory

Memory

Memory keeps short notes a person checked: each one sized to its evidence, stating when it applies, what to do, its support, its limits and what retires it, and saved only after review. Use a note only when it changes an action. A run that worked returns a narrow, reviewed entry or says why nothing was saved. Memory is optional: no mandatory recall at RPI entry, lesson at completion, worksheet, page quota or background mining. A trivial edit can proceed directly to implementation.

Rules for any saved lesson or rule

Apply these whenever a request would save or promote a lesson, including a request to turn an incident into a rule for an instruction file:

1. Look for an existing entry first. Search the selected .context/ pages, external topic pages or the target instruction file (AGENTS.md, CLAUDE.md, a team rules file). Amend the entry that already covers the behavior; add a new one only when none fits. If the final code, tests, comments or a doc already explain the reasoning, point there rather than save a copy; save only what they cannot show a later reader, such as ruled-out causes, why the fix works and what brings the failure back. Effort, a finished task or a large diff never qualifies a lesson. If nothing qualifies, save nothing and say why.
2. Size the claim to its evidence. One incident supports a narrow observation scoped to the conditions it actually had. A universal rule needs repeated independent occurrences and later reapplication. When a recurring correction is a mechanical slip that a lint rule, test or hook could catch, propose that check alongside the prose rule or in its place, as Postmortem does for such a miss; a check fails where a rule can only ask.
3. State all five fields: applicability, action, support, limits and invalidation. Use the template below; an entry with no invalidation is incomplete. For an incident, applicability includes the exact error text or observable symptom, the words a later search will use. An instruction file such as AGENTS.md loads into every session, so its entry is usually one line: the action and when it applies, worded as information rather than an order to read, linking the project .context/ page or the doc beside the governed code (never an external-bundle page from a checked-in file) that carries all five fields. A line that only restates what agents already do by default earns no place.
4. Review before admission. Give the draft inline in your reply unless the caller named storage outside Git; never write it into the repository before review. A saved note is one a person checked: the person who asked reads the exact text, paths and destination and approves it before it enters .context/, an instruction file such as AGENTS.md, or any Git object. When they ask you to save it without reading it, get one fresh read from a context that did not write the draft, checking factual support and disclosure; one round, and a repair does not start a second review. When neither can check it, write nothing: keep the draft inline, report it as not saved and name the missing check. Promoting an entry into an instruction file is a separate policy change owned by that file. On an explicit request to remember something, the runtime's own memory store (such as Claude Code auto-memory or Codex memory) is a valid destination; rules 1-3 still apply, and this review is owed only when that store is shared or checked in.
5. Saving proves nothing. Saved pages, retrieval counts and structural checks prove no benefit. Only later work can show that reuse changed an action and helped; keep failed, harmful and no-change results. Until then a saved rule is an untested hypothesis.

### <one-line claim>
- Applies when: <the conditions the evidence covered>
- Action: <the check or step to take>
- Support: <cited sources, each with the commit or date observed; number of independent occurrences>
- Limits: <where it is untested or may not hold>
- Invalidate when: <the change or contrary evidence that retires it, and how to check it>

Keep rare useful constraints; age or low frequency alone is no reason to delete them. Learning may also simplify or remove rules.

Choose one operation

Need	Read on demand
An earlier constraint or source map may change the next action	Find / recall
Draft a note from an incident, correction or source the person names	Capture a note
Update, qualify, consolidate or retire a supported claim	Curate / qualify / retire
Rank repeated operational friction in supplied history	Toil evidence
Trace a corrected claim or audit the loaded instruction set	Instruction sources

Memory owns these operations. Whether recurring evidence warrants a general rule is decided by Research's pattern mode (independent exemplars and a holdout). Capture drafts notes for a person to check; it does not extract lessons from history in bulk, and it is never a required completion step. Load only the selected operation's reference. The optional OKF page profile checks structure only.

One authority per fact

BD or the caller's tracker owns work and handoffs, Git owns content history, and native sessions or CASS own episodes. Reviewed topic pages in a project .context/ or an external bundle hold reusable claims and point to the docs, ADRs and code that own a policy instead of copying it. Do not make one lesson file per session, copy a transcript lake, or silently initialize a memory store. Read a project .context/ from its README.md map, when present, with rg and cat; this needs neither BD nor AO and creates nothing. External bundles and the ao config context route are in Find / recall.

Access, storage and honest limits

Use only sources already authorized for the task, owner, model/provider and exact destination; read permission does not imply publication or Git storage. This skill enforces no access control, so do not route restricted material through it; ao session read-source grants no broader transcript access. Unavailable and denied evidence remain explicit gaps; do not fetch then redact. Drafts and review proof go inline in your reply or to storage outside Git that the caller named; missing routing does not authorize a workspace fallback. Preserve requested legacy .agents/ proof and unique evidence under owner policy. No blind TTL or delete operation is part of Memory. Labels and structural parsers do not prove isolation. ADR-0016 (AgentOps source checkout only) owns these boundaries. Drafting a note cannot delay an authorized change or alter its verdict.