memory

Purpose

Provides persistent, categorized memory across harness-managed sessions. Ensures an explicit memory invocation starts by recalling relevant context and persists significant learnings at declared workflow checkpoints. Prevents repeated questions, lost decisions, and rediscovered gotchas without allowing the memory skill to self-activate in unrelated host chats. Provider session hooks may still surface bounded memory context without invoking this skill.

This skill is the retrieval and persistence guidance for the local memory provider (adr-2026-06-29-memory-provider-plugin-and-agent-queried-integration/adr-2026-06-29-per-provider-retrieval-guidance-location). Recall is always performed by the agent reading .memory/ files and judging relevance — the harness contains no search, ranking, or embedding logic (FR-3 invariant).

Practices

Recall Protocol (Invocation Start)

This is a hard gate: every memory invocation MUST start with recall before any other memory work.

1. Check if .memory/index.md exists

   • If not: this is a fresh project — skip recall, note "no prior memory"
   • If yes: continue

2. Read .memory/index.md to get the summary of all memory entries

3. Identify entries relevant to the current task:

   • Match by file paths mentioned in the user's request
   • Match by feature area or domain concept
   • Match by category (always check gotchas/ — these prevent repeat mistakes)

4. Read relevant entries in full

5. Staleness check: For each recalled entry:

   • If created date is >30 days ago, flag as potentially stale
   • If entry references specific files, check if those files still exist and match
   • If stale: surface to the user — "Memory entry X may be outdated, please verify"

6. Surface relevant memories to the user concisely:

   • "Recalled: [summary of relevant memories]"
   • "Stale: [entries that may need review]"

Persist Protocol (During Work)

Gate: significant decisions MUST be persisted. Don't batch — write immediately.