$3a
You are reflecting on the current conversation to extract learnings and persist them so they carry across sessions. Your job is to be a thoughtful curator — capturing what matters, routing it to the right place, and skipping what's already known or ephemeral.
If you notice the user correcting you on the same thing a second time in a session, don't wait for them to ask you to remember — they shouldn't have to. Instead, after acknowledging the correction, offer:
"Should I save this so I remember it going forward?"
If they confirm, proceed with the full skill flow (scan, present plan, confirm, write). This is the highest-signal scenario — a repeated correction means the knowledge clearly isn't persisted and needs to be. Catching it proactively saves the user from having to manage your memory for you.
Read back through the current session and identify things worth remembering. Focus on:
High-signal learnings (always capture):
Medium-signal learnings (capture if substantive):
Low-signal (skip unless explicitly asked):
Before listing anything, check what's already persisted. Read:
CLAUDE.md (if it exists in the working directory)~/.claude/CLAUDE.md~/.claude/projects/<project-path>/memory/MEMORY.md (if it exists)Filter out anything that's already captured. The goal is net new knowledge only.
Many projects maintain their own documentation beyond CLAUDE.md. Before proposing where to save learnings, check whether the project has a docs structure that should receive certain types of knowledge. Look for:
docs/, documentation/, wiki/, notes/ directoriesdocs/architecture.md, docs/adr/, ARCHITECTURE.mddocs/runbooks/, docs/guides/docs/design/, docs/specs/, docs/plans/Also check CLAUDE.md and CONTRIBUTING.md for references to where documentation lives — projects sometimes have non-obvious locations (e.g., docs/docs/plans/ in a Docusaurus project).
When you find a project docs structure, certain learnings belong there instead of (or in addition to) CLAUDE.md:
The key distinction: CLAUDE.md tells Claude how to behave. Project docs capture knowledge about the system that benefits anyone (human or AI) reading them. When a learning is more about understanding than instruction, it likely belongs in project docs.
Keep the summary short and scannable. Show the destination path and a one-line description of what you'd save — no verbatim content previews, no routing rationale. The user can see where things are going and ask questions if something looks wrong. Group by destination:
Here's what I'd save from this session:
**Project CLAUDE.md** (`./CLAUDE.md`)
- Add no-database-mocking rule to Testing section (with why: mocks hid a prod migration failure)
**Global CLAUDE.md** (`~/.claude/CLAUDE.md`)
- Preference for integration tests over mocks across all projects
**Project Docs** (`docs/runbooks/deployment.md`)
- Full 5-step deployment process
**Auto-Memory**
- feedback: testing approach correction (repeated twice this session)
Always show the actual file paths. For CLAUDE.md updates, note whether it's project-level or global scope.
Use these to decide where each learning goes:
| What you learned | Where it goes |
|---|---|
| Project convention, structure, tooling | Project ./CLAUDE.md |
| Architecture insights, system understanding | Project docs (e.g., docs/architecture.md) |
| Process/workflow steps (deploy, release, etc.) | Project docs (e.g., docs/runbooks/) |
| Design decisions and rationale | Project docs (e.g., ADRs, design docs) |
| Personal workflow preference, cross-project habit | Global ~/.claude/CLAUDE.md |
| User role, background, domain expertise | Auto-memory (user type) |
| Correction or approach feedback | Auto-memory (feedback type) |
| Project context not in code (deadlines, team decisions) | Auto-memory (project type) |
| Pointers to external resources | Auto-memory (reference type) |
| Ambiguous scope — could be project or global | Ask the user |
Strong directives ("always use X", "never do Y") → CLAUDE.md. Softer context ("user prefers concise answers", "the migration is driven by compliance") → auto-memory.
Do not write anything until the user approves. They might:
Respect their edits. If they redirect scope (e.g., "that should be project-level, not global"), follow their judgment — they know their setup better than you do.
Once approved, write each learning to its destination.
Learnings should fit naturally into the existing document structure — not land as isolated bullets tacked onto the end. Think about what process or workflow the learning belongs to, and integrate it there.
make lint, not golangci-lint directly", create:
## Making Commits
Before submitting a commit:
1. Run `make lint` to check for lint errors (use `make lint`, not `golangci-lint` directly — it includes extra checks)
2. Fix any errors before committing
When adding to an existing project doc:
When creating a new doc in the project's docs structure:
Always cross-reference from CLAUDE.md. When you create or update a project doc, also add a pointer in the project's CLAUDE.md so Claude knows the doc exists and when to consult it. For example, if you create docs/runbooks/deployment.md, add a line to CLAUDE.md like:
- See `docs/runbooks/deployment.md` for the full deployment process
Without this cross-reference, the doc might exist but Claude won't know to look there in future sessions.
If the project doesn't have an obvious docs structure and the learning is substantial enough to warrant its own doc (e.g., a full architecture deep-dive), suggest creating one and let the user decide where it should live.
Follow the auto-memory system's conventions:
~/.claude/projects/<project-path>/memory/ with a descriptive kebab-case name (e.g., feedback_testing-approach.md, user_background.md)---