Session audit

Session Audit

A lightweight audit that runs at the end of a session. It catches things the user said during the session that should be saved permanently, so they never have to say them again.

What this skill does

Two things, and only two:

1. Scans for uncaptured learnings. Looks through the conversation for corrections, preferences, decisions, and new context that aren't already written in the workspace files.
2. Proposes where to save each one. For each finding, names the file, the section, and the exact wording. The user approves or skips each one.

No file reorganization, no cleanup. Just: "Did we learn anything this session that should be remembered, and where does it go?"

Step 1: Discover the workspace's memory structure

Different workspaces store memory differently. Before scanning, find out what exists here:

1. Look for a root CLAUDE.md (standing behavior rules) and a root MEMORY.md (facts that change over time).
2. Look for a memory/ folder with deeper files (for example memory/people.md, memory/terminology.md, or per-project subfolders).
3. Look for per-project CLAUDE.md / MEMORY.md files inside project folders that were worked on this session.

Read every memory file that exists and was relevant this session. Note which of the three layers above are present; Step 4 adapts to what you found.

If no memory files exist at all, don't fail. Run the scan anyway, and at the end offer to create a minimal structure: one CLAUDE.md for behavior rules and one MEMORY.md for facts.

Step 2: Scan the conversation

Go through the whole conversation top to bottom. Look for four signal types:

A. Corrections. The user fixed something you produced: changed a word, rewrote a sentence, adjusted a format, said "no, do it this way." Each correction reveals a rule. Ask: what underlying preference drove the change?

B. Explicit preferences. The user stated a preference directly. Words like "always," "never," "I prefer," "from now on," "don't do that."

C. Decisions. The user made a decision that affects future work: chose one option over another, set a deadline, resolved an ambiguity.

D. New context. The user shared a fact about themselves, their work, or their world that wasn't known before: contacts, schedules, relationships, project updates, terminology.

Step 3: Filter against what's already saved

For each finding, check whether it's already captured in the files from Step 1. Skip anything already written down. Only surface genuinely new findings.

Step 4: Decide where each finding goes

Apply two tests, then match the result to the structure discovered in Step 1:

• Behavior or fact? A behavior rule ("always/never," "before doing X, do Y") belongs in a CLAUDE.md. A changeable fact (people, status, decisions) belongs in a MEMORY.md or the memory/ folder.
• Scope? Cross-cutting and applies everywhere: the root file. Deep or detailed knowledge that would bloat the root file: a memory/ file. Specific to one project: that project's own file.

Examples: a corrections-derived rule that applies to all writing goes in the root CLAUDE.md. A new contact goes in the root MEMORY.md, with any deep profile in memory/people.md if that file exists. A decision on one project goes in that project's MEMORY.md.

If the workspace only has some of these files, place findings in the closest existing file rather than inventing new structure. Only propose a new file when nothing suitable exists, and say so explicitly.

Step 5: Present findings

Present each finding in this format:

**[Number]. [What happened]**

- **The rule or fact:** [exact wording to save]
- **Where it goes:** [file path, section]
- **Why:** [one sentence on why it matters next time]

Group findings into two categories:

• Recommend (apply unless you object): clear-cut findings where the right action is obvious.
• Your call: findings with a judgment call, or where the user might phrase the rule differently.

If there are no findings, say so: "Clean session. Nothing new to capture." Don't manufacture findings.

Step 6: Apply approved changes

After the user approves (all, some, or none), write the approved changes to the right files. If a MEMORY.md carries a "Last updated" date, update it. For each change, confirm what was written and where.

Important: Never write changes without approval. Always present findings first and wait.