ai-builder-club/agent-context-audit
> Audit a repo's agent context — CLAUDE.md files, codebase docs, skills, and tool/MCP designs — against Anthropic's Claude 5 context-engineering guidance loss). Finds overconstraint, conflicting instructions, redundancy, stale facts, and missing "unknown knowns"; produces a scored findings report with concrete rewrites, then applies approved fixes. Use when someone says "audit my CLAUDE.md", "context audit", "unhobble this repo", "review our agent docs/skills/tools", or after upgrading to Claude 5-generation models.
npx skills add https://github.com/AI-Builder-Club/skills --skill agent-context-audit
Goal: find where this repo's context (CLAUDE.md, docs, skills, tool designs)
hobbles a Claude 5-generation model — overconstrains it, contradicts itself,
repeats itself, or hides context the model actually needs — and leave behind a
findings report plus approved fixes.
Background: Anthropic removed over 80% of Claude Code's system prompt for
Claude 5 models with no measurable loss on coding evals. Older context was
written for models that needed rules; newer models need judgment, good
interfaces, and the facts they can't infer. This skill audits against that
shift, plus the "finding your unknowns" framework (the gap between the *map* —
your prompts/docs — and the *territory* — the actual codebase).
You are auditing first, fixing second. Do not edit anything until Step 4.
Every finding maps to one of these. Cite the shift number in the report.
comments", "one-line docstrings max") that encode a *preference*, not a real
constraint, should become judgment framing ("write code that reads like the
surrounding code") — or be deleted if the model would infer it anyway.
Keep hard rules only where violation is genuinely costly (security, prod
data, irreversible actions, legal/billing).
transcripts constrain exploration. Prefer expressive interfaces: good
parameter names, enums that hint at valid states, tight descriptions.
In tool/MCP definitions, an enum of pending | in_progress | completed
teaches more than three worked examples.
sometimes needed (review checklists, deploy runbooks, style deep-dives)
should move out of CLAUDE.md into a skill or linked file loaded on demand.
CLAUDE.md is loaded *every* session — it should carry only what every
session needs.
appearing in CLAUDE.md *and* a skill *and* a tool description is a bug:
copies drift and eventually conflict. Each instruction gets exactly one
home — tool-usage guidance lives in the tool description, repo gotchas in
CLAUDE.md, team opinions in skills.
hand-maintain notes/changelogs in CLAUDE.md, or accumulated session-specific
trivia, are obsolete where auto-memory exists. Flag CLAUDE.md content that
is really *memory* (per-user, per-incident, time-bound) rather than
*repo truth*.
prose, prefer pointing at the real thing: @-referenced source files, a
test suite, an HTML mockup, a rubric a verifier can score against. Code-based
specs beat prose paraphrases of code.
Cross-cutting failure modes to hunt alongside the shifts:
thoroughly" in one file, "DO NOT add comments" in another). Highest-value
findings; a conflict forces the model to deliberate or guess on every task.
services that no longer exist, or missing ones that now do. Verify every
concrete claim you audit against the actual repo.
the non-obvious build step, the directory you must never touch, the reason a
weird pattern exists. These are what CLAUDE.md is *for* ("repository
gotchas rather than obvious patterns").
Collect everything that gets assembled into an agent's context here. Look for
the capability, not a specific filename:
~/.claude/CLAUDE.md onlyif the user asks for a global audit. Also AGENTS.md, .cursorrules,
.github/copilot-instructions.md if present (same disease, same cure).
.claude/skills//SKILL.md, skills//SKILL.md, pluginskills committed to the repo.
descriptions, parameter schemas), custom slash commands, hooks, and any
agent definitions (.claude/agents/*.md).
referenced from CLAUDE.md or skills.
Record rough sizes (lines/tokens) per artifact — total always-loaded weight is
itself a finding when large.
For each artifact, walk the six shifts and cross-cutting modes. For every
finding record: file:line, quote, shift #, severity, proposed rewrite
(the actual replacement text — or "delete", with one line of why it's safe).
Severity:
stale facts an agent would act on.
a skill.
Verify before you flag: a claim of staleness must be checked against the repo
(does that script exist? does that command run?); a claim of redundancy must
cite both locations.
Auditing text only finds what's written. Now find what's missing:
the weirdest-looking directories — and list load-bearing facts that appear in
no doc. Each is a candidate "unknown known" to add.
here safely ("how do I run one test?", "what must never be committed?",
"which service is the source of truth for X?"). Answer each *using only the
audited docs*. Unanswerable questions = gaps; wrong answers = stale docs.
git log --oneline -20 -- <doc> — a CLAUDE.md untouched formonths in an active repo is presumptively stale; recent churny areas of the
codebase with no doc coverage are presumptive gaps.
Deliver a findings report (markdown in the repo, e.g.
docs/agent-context-audit-YYYY-MM-DD.md, or just in the reply if the user prefers):
verdict (keep / trim / restructure / delete).
the home it belongs in (CLAUDE.md vs skill vs tool description).
Lead with the top 3–5 highest-value changes; don't bury a layer conflict under
twenty style nits.
Ask which findings to apply (all high, everything, or cherry-pick). Then:
a one-line pointer behind.
/doctor is available in this Claude Code install, suggest the user alsorun it as a second opinion on CLAUDE.md/skill sizing.
point is removing *fake* constraints, not real ones.
is sound.
actionable as written.
Sources: Anthropic, "The new rules of context engineering for Claude 5
generation models" (claude.com/blog); "A field guide to Claude Fable: finding
your unknowns" (claude.com/blog).
Take ai-builder-club/agent-context-audit from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.