AI Memory & Personalization

Your AI coding assistant can remember things between sessions — most people never realize it. This guide explains that memory, why it makes the AI noticeably more useful over time, and how the session-post-mortem skill keeps it sharp instead of letting it rot into a junk drawer.

Not the in-app AI memory. This is your coding assistant’s memory about you and this project. The AI assistant feature you ship to your customers has its own, separate memory and knowledge base — see Knowledge Base (RAG).

Memory files are a Claude Code feature. Other AI tools have their own memory mechanisms; the curation habit below still applies, but the exact file paths are Claude Code’s.

---

What the memory is

Claude Code keeps a small memory folder for each project (on your machine, outside your repo). It has two parts:

• MEMORY.md — a one-line-per-fact index, loaded at the start of every session.
• Individual memory files — one durable fact each, with frontmatter declaring its type:

Type	Holds	Example
user	Who you are — role, expertise, preferences	”10-year Go engineer, new to React”
feedback	How you want the AI to work	”Never push until I explicitly say so”
project	Time-bound context not visible in the code	”Merge freeze until 2026-03-05 for mobile release”
reference	Pointers to external systems	”Bugs tracked in Linear project INGEST”

Because the AI reads the index every session, a fact you save once quietly shapes its behavior from then on — no need to repeat yourself.

---

Why it matters

Without memory, every session starts from zero: you re-explain your preferences, the AI repeats a mistake you already corrected, you re-state the same context. With memory, kept clean:

• Corrections stick. Tell it “don’t refactor unrelated code” once; it stops.
• It learns your stack’s gotchas instead of re-deriving them each time.
• It knows your workflow — how you release, when to ask before pushing.

This is what personalizes the kit to you. The catch: memory only helps while it stays curated. Dump every passing thought in and the signal drowns in noise. Keeping it tidy is exactly the job session-post-mortem does.

---

How session-post-mortem helps

At the end of a session, run:

Use the session-post-mortem skill.

It scans the conversation for durable lessons — corrections, confirmed non-obvious choices, bug fixes where the first attempt was wrong — and routes each one to its single best home. The routing is the whole point: not everything belongs in memory.

What you learned	Where it goes
”Always ask before pushing” (applies anywhere)	Memory (feedback)
An SDK quirk specific to this stack	Scoped rule → ### Project-Specific Corrections
A new non-negotiable for the whole project	AGENTS.md (the skill asks you first)
A gotcha in one feature/module	That module’s README (via readme-updater)
A repeatable 3+ step workflow	A new skill (via skill-builder)

Without that discipline, lessons either pile into memory until it’s noise, or get lost entirely. The skill keeps each lesson in exactly one place and refuses to write duplicates.

---

A concrete example

Say that during a session you:

1. Snap at it: “Stop — never run destructive commands on a guess.”
2. Confirm an unusual call: “Yes, keep Inngest — we’re on Cloud Run, not Vercel.”
3. Fix a bug where it first mocked Prisma in an integration test (wrong) before switching to the real client.

Running session-post-mortem turns that into three correctly-placed entries:

• (1) → a feedback memory: “No destructive actions on guesses.” — applies to every future session, any project.
• (2) → a project memory: “Stay on Inngest; deploy target is Cloud Run.” — context the code doesn’t state.
• (3) → a line under ### Project-Specific Corrections in the testing rule — stack-specific, so it lives with the test patterns, not in memory.

Next session, the AI already knows all three — without you saying a word.

---

Where it fits in the workflow

Run it at natural end points:

• End of a meaningful session — before you switch to unrelated work.
• After a release — it’s the final RETRO step in the recommended flow.
• Any time you say “save what we learned.”

You can also curate by hand: open MEMORY.md, skim the one-liners, and delete anything stale. Memory is just markdown files — yours to read and edit anytime.

---

Related:

• Prompt Library & Skills — invoking skills, the full SDLC flow
• Extending the Framework — adding skills & rules (skill-builder, rule-builder)
• Knowledge Base (RAG) — the separate in-app assistant memory you ship to customers