/agent-memory

name: agent-memory
description: "Repo-local file memory under .scaffolding/ (shared/agent/conversation tiers). TRIGGER when: reading or writing .scaffolding/ memory files, or choosing which file tier an insight belongs in. SKIP: vector memory / MCP search and store (use semantic-memory-mcp); distilling conversations (use distill)."

Agent Memory Protocol

3-tier persistent **file-based** memory under the repo-local `.scaffolding/` directory, for cross-session knowledge accumulation. Vector memory (MCP tools) is covered by the `semantic-memory-mcp` skill.

Memory Tiers

| Tier | Path | Scope | Written By | Read By | |------|------|-------|------------|---------| | **Shared** | `.scaffolding/agent-memory/shared/KNOWLEDGE.md` | Whole project | Any agent | All agents | | **Agent** | `.scaffolding/agent-memory/agents/{agent-name}/MEMORY.md` | Per agent | Owning agent | Own agent + architect | | **Conversation** | `.scaffolding/conversations/{conversation_id}/agent-memory/context.md` | Per conversation | Any agent in conversation | Agents in same conversation |

The Conversation tier lives under `.scaffolding/conversations/`, which is a symlink to `<share>/projects/<repo-name>/conversations` (shared across machines). Paths are unchanged; always go through the symlink.

How Memory Is Read

No hook or pipeline injects these files into agent context -- they are read on demand (see On First Turn). The conversation tier is the inter-agent handoff: a downstream agent in the same chain reads what an upstream agent recorded there.

On First Turn

Before starting work, read available memory (skip if files don't exist):

1. Read `.scaffolding/agent-memory/shared/KNOWLEDGE.md` 2. Read `.scaffolding/agent-memory/agents/{your-agent-name}/MEMORY.md` 3. If `conversation_id` is provided in task context: Read `.scaffolding/conversations/{conversation_id}/agent-memory/context.md`

Before Completing

Write significant findings to the appropriate tier:

Shared Knowledge (KNOWLEDGE.md)

Save here:

• Project architecture facts confirmed across multiple tasks
• Deployment gotchas and infrastructure quirks
• Cross-cutting patterns (e.g. how Redis is used, how tasks flow)
• Known bugs or limitations that affect multiple agents

Do NOT save:

• Agent-specific patterns (use agent memory)
• Task-specific context (use conversation memory)
• Anything already in CLAUDE.md or docs/

Agent Memory (MEMORY.md)

Save here:

• Patterns specific to your agent's domain (e.g. developer saves coding patterns)
• Lessons learned from mistakes in your domain
• File locations you frequently need
• Recurring debugging insights

Do NOT save:

• Generic project facts (use shared knowledge)
• One-time task details
• Speculative or unverified conclusions

Conversation Memory (context.md)

Save here:

• Decisions made during this conversation
• Findings from investigation (debugger -> developer handoff)
• Context needed by downstream agents in the same conversation chain
• Original intent and requirements clarifications

Do NOT save:

• Permanent knowledge (use shared or agent memory)
• Raw data or large code snippets

Read-Only Agents

Agents with `Write` in `disallowedTools` (reviewer, gitops) cannot write to `.scaffolding/agent-memory/` directly. These agents should report findings in their output, and writable agents in the same conversation chain can persist them. Architect has `Write` and may write memory files (only `Edit` is disallowed).

Format Guidelines

• Max 200 lines per file (keeps the file cheap to read in full)
• Use markdown headers to organize by topic
• Include dates `[YYYY-MM-DD]` for time-sensitive entries
• Tag durable facts with `confidence` (high/medium/low) and `last_verified [YYYY-MM-DD]`; re-verify against live code/config before asserting a stale point-in-time fact, and down-grade or remove ones that no longer hold
• Remove outdated entries proactively
• Use concise bullet points, not prose

Hot/Cold Split

File-based memory (this skill) is the **hot** layer — read in full on first turn under a 200-line budget, so keep it lean: stable, high-level facts and pointers only. Push detailed prose and rarely-needed, fuzzy-discoverable knowledge to the **cold** layer (vector store) via the `semantic-memory-mcp` skill — it only surfaces on similarity match and carries no per-turn token cost. Durable source-of-truth facts still get a file here; the cold copy is for natural-language recall.

**Local-only carve-out:** secrets and memory/MCP recovery procedures NEVER go to the cold vector store. Recovery info must stay readable when the store itself is down (a 401 means you cannot query the store to learn how to fix it), and secrets must not be embedded in a remote/shared backend. Keep these as file memory only.

File Creation

If memory files don't exist, create them with the appropriate header:

# Shared Knowledge
<!-- Cross-agent project knowledge. Max 200 lines. -->

# {Agent Name} Memory
<!-- Agent-specific patterns and lessons. Max 200 lines. -->

# Conversation {conversation_id} Context
<!-- Decisions and findings for this conversation chain. -->

Conversation Recall

Conversation memory is plain files: when a task has a `conversation_id`, read `context.md` yourself (see On First Turn). No database setup is required for conversation-tier memory.

Learning Loop

The `/learn` command closes the loop between a finished conversation and the memory tiers above. It distills one conversation into knowledge candidates (via the `distill` skill's Conversation-Scoped Distillation mode) and routes each candidate back into this memory system.

Candidate ingestion into the 3 tiers

| Candidate kind | Target tier | File | |----------------|-------------|------| | Cross-cutting project fact | Shared | `.scaffolding/agent-memory/shared/KNOWLEDGE.md` | | Domain-specific pattern or lesson | Agent | `.scaffolding/agent-memory/agents/{name}/MEMOR