Audit Session Context

Audit Session Context

Overview

Everything that loads into a session — global CLAUDE.md, project CLAUDE.md/CLAUDE.local.md, auto-memory, settings.json hooks, persona plugins, skill index — accumulates silently across sessions. Nothing prunes it. This skill audits that whole chain as a new agent would receive it, and reports problems by category instead of narrative.

When to Use

• Before trusting a repo's accumulated rules/memory for a big task
• After a preference change, to check it didn't collide with something already in place
• When something feels off but you can't point to which file

Not for: reviewing a single file in isolation (just read it) — this is for the whole chain, where the value is in cross-file interaction.

Procedure

1. Gather in load order. For the target repo: global ~/.claude/CLAUDE.md (+ any @imports) → project CLAUDE.md → CLAUDE.local.md → .claude/rules/*.md (only if actually referenced somewhere — not auto-loaded) → auto-memory ~/.claude/projects/<repo-slug>/memory/MEMORY.md + every linked file → project .claude/settings.local.json → global + project settings.json hooks → any SessionStart persona hooks (enabled plugins) → MCP server instructions → skill index. Read each file that exists; note absence of project-level files as a finding, not a skip.
2. Verify memory links, don't trust the index. ls the memory directory and diff it against every filename MEMORY.md references. A missing file is a dead link masquerading as a fact — this is the single highest-value check in the whole audit.
3. Check memory against current ground truth, not just internal consistency — a lockfile, git log, a grep for the symbol it names. Memory is point-in-time; code moves.
4. Classify every finding using these categories, not vibes:
   • Contradiction — a source disagrees with itself (a memory index summary vs. the file it links to).
   • Conflict — two independent sources disagree with each other, neither wrong standalone (a persona plugin vs. global CLAUDE.md; a global hook vs. a project's documented workflow).
   • Duplication — the same instruction or fact stated in more than one place, redundant but not disagreeing.
   • Unnecessary info — loads every session regardless of relevance to this repo (noise, not wrong).
   • Deprecated — self-flagged or superseded, still loading anyway.
   • Stale state — a time-bound claim (bug status, TODO, "in progress") not reverified against current code.
   • Stumble risk — synthesis: concretely how a new agent gets misled because of the above.
   • Hook candidate — a rule currently enforced only by hoping the model remembers, that a PreToolUse/PostToolUse/Stop hook could enforce mechanically instead.
5. Quote, don't recall, whenever a finding hinges on what a rule currently says. Before citing global CLAUDE.md (or any other source) as contradicted, deviated-from, or superseded, re-read its exact current text and quote the actual line — don't rely on your own sense of what it "usually" says or what it said earlier in training or in a prior session. Rules get edited; a plausible-sounding paraphrase of a rule that's since changed is a confident wrong finding, not a hedge, and it reads exactly as trustworthy as every correct finding around it.

Output Format

One section per category above, in that order, plus a leading "pull-in order" summary. Bullets only, no narrative paragraphs. Each pull-in-order line: [type] short description, type ∈ rule/memory/config/persona/context. Empty categories still get listed as "none found" — silence reads as "didn't check," not "found nothing."

Remediation Plan

Every audit ends with a plan, not just the findings — a categorized list of problems isn't actionable on its own. Write it as a durable artifact (.claude/docs/ per this project's convention). Structure:

• Actionable now — fixes with no judgment call attached: broken links, self-contradicting text, mechanical scoping fixes. If you can name the fix in one sentence and it doesn't trade off against another stated preference, it goes here.
• Open questions — anything where two legitimate sources disagree and closing the gap is a preference call, not a bug fix (persona vs. global-rule precedence; picking a default among overlapping skills; whether upstream/third-party content is worth patching). Frame each as the actual tradeoff, with options — don't pre-pick one and ask for a rubber stamp.
• Risks to other workflows — for every actionable item and open-question outcome, check its actual scope (a config file's location tells you: global ~/.claude/settings.json or ~/.claude/CLAUDE.md reaches every repo; a project-local file reaches only that repo) and name what could break at that scope — don't assume either way going in. A hook scoped wrong (checks cwd, not repo root — false-blocks in subdirectories/monorepos), a rule trimmed because it looked redundant with something outside your control that could drift later, a precedence decision that's fine for a low-stakes repo but risky in one with heavier existing infra or higher failure cost.
• Not planning to touch — found it, considered fixing it, declined, and why (usually: cost of the fix exceeds the cost of the problem, or it's owned by something outside your control).

After the plan file is written, post a short chat-facing todo list — one line per open question, phrased as the decision itself (not "see question A"), so the human can answer inline without opening the file. Don't just point at the plan and say "see open questions" — the file is the record, the chat message is what gets answered.

When the human answers, edit the plan file before doing anything else with the answers: move each resolved question out of "Open questions" into "Actionable now" (or "Not planning to touch," if that's what was decided), recording the choice and its rationale inline — don't just delete the question. Re-check "Risks to other workflows" against the new answers; a resolved precedence question can surface a risk that wasn't visible while it was still open. Only after the file reflects the decisions do you act on them.

Common Mistakes

• Trusting a memory index's one-line summary instead of opening the file it links to (that's exactly where the contradiction hides).
• Treating "deprecated" and "duplication" as the same finding — a deprecated skill still loading is a staleness problem even when there's no duplicate text anywhere.
• Skipping the "none exist" case for project CLAUDE.md/CLAUDE.local.md — their absence is itself a finding (no project-specific onboarding), not nothing to report.
• Stopping at "this hook could exist" without naming the concrete trigger (PreToolUse matcher, file path pattern) — a vague hook candidate isn't actionable.
• Citing what a rule "says" from memory of it rather than a fresh read. Observed case: an agent confidently reported global CLAUDE.md required an old directory convention and flagged the target repo's current convention as a deviation — backwards. The rule had been rewritten earlier in the same session; the agent never re-read it before citing it. The finding was formatted identically to every correct one around it, which is what made it dangerous.