/memory

name: memory
description: "Find or curate supported lessons and agent rules. Use when: asked to remember, trace a corrected claim, audit instructions or write an agent rule."
practices:
- evidence-based-engineering
- continuous-learning
hexagonal_role: supporting
consumes: []
produces:
- applicable-context
- reviewed-topic-pages
- ranked-toil-evidence
context_rel: []
skill_api_version: 1
user-invocable: true
metadata:
  graph_root: true
  tier: execution
  dependencies: []
  capabilities: [recall_applicable_context, mine_supported_observations, curate_topic_pages, toil_mining]
  effects: [write_protected_drafts, update_authorized_topic_pages, write_requested_toil_report]
  canonical_status: canonical
  disposition: keep_off_path
output_contract: 'bounded applicable evidence or no-match; reviewed topic-page updates or no-change; ranked toil evidence with support, limits and unresolved gaps'

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](../postmortem/SKILL.md) 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](references/recall.md) | | Draft a note from an incident, correction or source the person names | [Capture a note](references/mine-learn.md) | | Update, qualify, consolidate or retire a supported claim | [Curate / qualify / retire](references/curate.md) | | Rank repeated operational friction in supplied history | [Toil evidence](references/toil.md) | | Trace a corrected claim or audit the loaded instruction set | [Instruction sources](references/instruction-sources.md) |

Memory owns these operations. Whether recurring evidence warrants a general rule is decided by [Research's