
claude-code-audit
Forensic audit of the user's recent Claude Code sessions to surface step-change workflow improvements — not marginal ones. Use when the user asks to "audit my Claude Code sessions", "analyze how I use Claude Code", "find patterns in my usage", "improve my Claude Code workflow", "review my sessions", "find leverage in my setup", or wants to understand where their Claude Code setup is leaking time. Samples dozens of real transcripts, extracts quantitative signal via scripts, uses parallel subagents for deep reads, then synthesizes into a short prioritized report with drafted implementations (new skills, CLAUDE.md rules, hooks, settings diffs) that the user can install directly. Trigger even when the user doesn't say the word "audit" — if they're asking about improving or reviewing their Claude Code habits at scale, use this skill.
- Installs
- 130
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/petekp/claude-code-setup --skill claude-code-audit- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads claude-code-audit automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Claude Code Audit
What this is
A disciplined framework for auditing a large sample of the user's Claude Code sessions to find step-change improvements — the 2–3 changes that would transform their workflow, not the 20 that would polish it.
The default behavior when asked "how can I improve my workflow" is to produce a long list of marginal suggestions. That output is worse than useless: it buries real leverage under pleasant-sounding noise, and the user does nothing with it. This skill exists to prevent that outcome.
The guarantee
By the end of this audit you will have produced:
- A short prioritized report — the few findings that would actually move the needle, with quantified evidence.
- Drafted implementations — ready-to-install skills, CLAUDE.md rules, hook scripts, or settings diffs for the top recommendations. Not suggestions. Actual drafts.
- A paper trail — the extracted data, sampled session list, and subagent findings, so the user can verify the synthesis and revisit it later.
If you end the audit having produced only observations, you have failed.
Step-change vs marginal — hold this distinction the whole way
| Marginal | Step change |
|---|---|
| "You should use skill X more often" | "Skill X never triggers on prompts like these — its description excludes the phrasing you actually use. Here's a new description." |
| "You correct Claude a lot about testing style" | "You've given the same correction 14 times in 30 days. The root pattern is Claude defaults to unit tests when you want integration tests. Here's a CLAUDE.md paragraph that eliminates the correction loop." |
| "Consider adding tests earlier" | "19 of your 60 sessions have a 'test afterward' → 'fix regression' → 'fix another regression' loop that averages 35 min and 80k tokens. A pre-commit hook that runs your existing test script would short-circuit it." |
The left column is observation. The right column is diagnosis plus prescription plus evidence. You produce the right column.
Where session data lives
- Root:
~/.claude/projects/<encoded-project-path>/<session-id>.jsonl - Each line is one event:
user,assistant,attachment(hook result),system,file-history-snapshot,last-prompt. - The user is at
~/.claude/with global CLAUDE.md, skills, settings, and hooks. You'll cross-reference against these during synthesis. - See
references/session_format.mdfor the JSONL schema and which fields matter.
Setup — working directory
Before starting, set SKILL_DIR and AUDIT_DIR:
SKILL_DIR=~/.claude/skills/claude-code-audit(where the scripts live — never modify this)AUDIT_DIR=~/claude-audit/<date>(where the audit outputs go — create a fresh subdir per run, or use a path the user provided)
All python $SKILL_DIR/scripts/... invocations below assume these are set. Run from any cwd; the scripts take absolute paths. Create AUDIT_DIR before stage 1.
The five stages
Create a TaskList for these so the user can see progress. This is a long-running analysis — 20 to 60 minutes depending on sample size.
Stage 1 — Inventory
python $SKILL_DIR/scripts/inventory.py --out $AUDIT_DIR/inventory.json
Catalogs every session: path, project, timestamp, size, rough message/turn/tool counts, token totals, version, git branch. Cheap, deterministic. Read the summary it prints.
Stage 2 — Sample
python $SKILL_DIR/scripts/sample.py --inventory $AUDIT_DIR/inventory.json --count 60 --days 60 --out $AUDIT_DIR/sample.json
Stratified sample weighted toward recency but diverse across projects and session sizes. Print the distribution. Tell the user the shape of the sample in one sentence ("60 sessions: 40 from last 2 weeks, 20 older; spanning X projects") and proceed unless they push back.
Stage 3 — Extract
python $SKILL_DIR/scripts/extract.py --sample $AUDIT_DIR/sample.json --out $AUDIT_DIR/extracted/
For each sampled session, writes a JSON with: user prompts (real ones, not command wrappers), assistant tool-use sequence, error counts, skill/command invocations, token usage, approximate wall-clock duration, first-prompt intent, "correction" markers (user messages that follow a failed tool or that use corrective language), and session outcome hints.
Then aggregate:
python $SKILL_DIR/scripts/extract.py --aggregate $AUDIT_DIR/extracted/ --out $AUDIT_DIR/aggregate.json
You now have the quantitative layer. Skim it. Flag any surprises — surprises are leads.
Stage 4 — Deep read via parallel subagents
Scripts miss the qualitative signal: frustration, confusion, circularity, breakthrough moments, mental-model mismatches. Subagents handle this.
Split the sample into batches of 8–10 sessions. Launch all batches in a single message (parallel, not sequential). For each batch, spawn an Explore subagent with the briefing from references/subagent_brief.md plus:
- The list of session file paths in its batch.
- The path to
$AUDIT_DIR/aggregate.jsonso it has global context. - The path to
$SKILL_DIR/references/step_change_patterns.mdas its lens. - The user's current skills dir (
~/.claude/skills), CLAUDE.md (~/.claude/CLAUDE.md), and settings.json (~/.claude/settings.json), for cross-reference. - Tell it to use
python $SKILL_DIR/scripts/render.py <session-path>to get readable transcripts. Using render.py is critical — raw JSONL will blow its context.
Each subagent returns a structured JSON of findings. Save to $AUDIT_DIR/batch-<N>-findings.json.
Stage 5 — Synthesize
This is where the skill earns its name.
- Read every batch-findings file and the aggregate.
- Cluster findings across batches. A pattern that appears in one session is noise; a pattern in eight is signal.
- Rank clusters by frequency × severity × fix leverage. Leverage = how many future sessions the fix would affect. A fix that helps one niche workflow is not leverage; a fix that removes friction from every coding session is.
- Apply
references/step_change_patterns.mdas a filter — is each top cluster a marginal tweak or a step change? If it's marginal, either promote it to something bigger (find the underlying doctrine) or drop it. - Write the report using
references/report_template.md. - Draft the fixes. Every top-tier recommendation gets a real draft, not a description of a draft. New skill? Write the SKILL.md. New rule? Write the paragraph, word for word. New hook? Write the script. Settings change? Show the diff.
Non-negotiables
You draft the fix. If you find yourself writing "the user could consider adding a skill for X", stop and write the skill. If you write "a CLAUDE.md rule about Y would help", stop and write the exact paragraph. This is the single most important thing this skill does. Skip it and the audit is worthless.
Short over complete. A 3-item report the user acts on beats a 30-item report they skim and forget. Cut everything that isn't leverage.
Numbers, not adjectives. "Frequently", "often", "sometimes" are lies. Say "17 of 60 sessions" or "23 corrections across the sample". The scripts give you exact counts — use them.
Cite the sessions. Every claim in the report names specific session IDs as evidence. The user must be able to open a session and verify the pattern.
Audit Claude, not the user. If the user keeps correcting the same thing, Claude's defaults are wrong for them — not the other way around. Don't scold the user for their prompting. Find the pattern in Claude's behavior that forces the correction, and write the fix to Claude's configuration.
Common failure modes
- Observation dump. Listing 40 patterns with no priority. Fix: be brutal in cutting.
- Self-congratulation. Only describing things Claude did well. Fix: deliberately hunt for failures, frustrations, and circling.
- Vague prescriptions. "Consider improving X." Fix: you draft the improvement or you don't include it.
- Project tunnel vision. Reporting only on the most-active project. Fix: sample forces diversity; honor it in the write-up.
- Ignoring the meta-level. Focusing only on in-session behavior and missing cross-session patterns (sessions ending prematurely, same context being rebuilt every time, etc.). Fix:
references/step_change_patterns.mdexplicitly calls these out; reread before synthesis.
Output layout
$AUDIT_DIR/
inventory.json # stage 1
sample.json # stage 2
extracted/<session>.json # stage 3
aggregate.json # stage 3
batch-<N>-findings.json # stage 4
report.md # stage 5 — the deliverable
drafts/ # stage 5 — the implementations
skills/<skill-name>/SKILL.md
claude-md-additions.md
hooks/<hook-name>.sh
settings-diff.json
Default $AUDIT_DIR to ~/claude-audit/<YYYY-MM-DD>/ unless the user specifies otherwise. Everything stays on disk so the user can rerun, verify, or share.
Reference files
references/session_format.md— JSONL schema and field meaningsreferences/step_change_patterns.md— taxonomy of leverage points; the lens for synthesisreferences/report_template.md— required output structurereferences/subagent_brief.md— prompt you pass to stage-4 subagents
FAQ
What does the claude-code-audit skill do?
Forensic audit of the user's recent Claude Code sessions to surface step-change workflow improvements — not marginal ones. Use when the user asks to "audit my Claude Code sessions", "analyze how I use Claude Code", "find patterns in my usage", "improve my Claude Code workflow", "review my sessions", "find leverage in my setup", or wants to understand where their Claude Code setup is leaking time. Samples dozens of real transcripts, extracts quantitative signal via scripts, uses parallel subagents for deep reads, then synthesizes into a short prioritized report with drafted implementations (new skills, CLAUDE.md rules, hooks, settings diffs) that the user can install directly. Trigger even when the user doesn't say the word "audit" — if they're asking about improving or reviewing their Claude Code habits at scale, use this skill.
How do I install claude-code-audit?
Run npx skills add https://github.com/petekp/claude-code-setup --skill claude-code-audit in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/claude-code-audit/ (personal) or .claude/skills/claude-code-audit/ (project).
Which AI agents can use claude-code-audit?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is claude-code-audit safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains claude-code-audit?
It is published by petekp in petekp/claude-code-setup. It has 130 recorded installs.
More from petekp/claude-code-setup
code-comments
petekp/claude-code-setup
Write, review, or remove code comments. Use when adding comments or doc comments, reviewing the comments in a diff, or cleaning up or removing comments.
deep-research
petekp/claude-code-setup
Open the skill to read its SKILL.md instructions.
exhaustive-systems-analysis
petekp/claude-code-setup
Open the skill to read its SKILL.md instructions.
typography
petekp/claude-code-setup
Open the skill to read its SKILL.md instructions.
Popular security skills
azure-compliance
microsoft/azure-skills
Run Azure compliance and security audits with azqr plus Key Vault expiration checks. Covers best-practice assessment, resource review, policy/compliance validation, and security posture checks. WHEN: compliance scan, security audit, BEFORE running azqr (compliance cli tool), Azure best practices, Key Vault expiration check, expired certificates, expiring secrets, orphaned resources, compliance assessment.
minimal-run-and-audit
lllllllama/rigorpilot-skills
Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized reprooutputs/ files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself.
seo-audit
coreyhaines31/marketingskills
When the user wants to audit, review, or diagnose SEO issues on their site. Also use when the user mentions "SEO audit," "technical SEO," "why am I not ranking," "SEO issues," "on-page SEO," "meta tags review," "SEO health check," "my traffic dropped," "lost rankings," "not showing up in Google," "site isn't ranking," "Google update hit me," "page speed," "core web vitals," "crawl errors," "indexing issues," "stuck on page 2," "striking distance keywords," "title tag rewrite," "low CTR," "local SEO," "Google Business Profile," or "map pack." Use this even if the user just says something vague like "my SEO is bad" or "help with SEO" — start with an audit. For building pages at scale to target keywords, see programmatic-seo. For adding structured data, see schema. For AI search optimization, see ai-seo.
firebase-security-rules-auditor
firebase/agent-skills
Audits Firebase (Firestore, Cloud Storage) security rules for vulnerabilities, privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks. Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists. Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries.
audit
pbakaus/impeccable
Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan. Use when the user wants an accessibility check, performance audit, or technical quality review.
competitors
coreyhaines31/marketingskills
When the user wants to create competitor comparison or alternative pages for SEO and buyer-facing use. Also use when the user mentions 'alternative page,' 'vs page,' 'competitor comparison,' 'comparison page,' '[Product] vs [Product],' '[Product] alternative,' 'competitive landing pages,' 'how do we compare to X,' 'competitor teardown,' 'audit our competitor pages,' 'are our comparison pages out of date,' or 'competitive asset audit.' Use this for any content that positions your product against competitors. Covers four formats: singular alternative, plural alternatives, you vs competitor, and competitor vs competitor. For auditing existing claims (not researching competitors from scratch, which is competitor-profiling; not technical SEO on these pages, which is seo-audit), use the asset audit here. For internal battle cards and sales-specific competitor docs, see sales-enablement.