skills/claude-code-audit/SKILL.md
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.
npx skillsauth add petekp/claude-skills claude-code-auditInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
By the end of this audit you will have produced:
If you end the audit having produced only observations, you have failed.
| 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.
~/.claude/projects/<encoded-project-path>/<session-id>.jsonluser, assistant, attachment (hook result), system, file-history-snapshot, last-prompt.~/.claude/ with global CLAUDE.md, skills, settings, and hooks. You'll cross-reference against these during synthesis.references/session_format.md for the JSONL schema and which fields matter.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.
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.
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.
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.
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.
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:
$AUDIT_DIR/aggregate.json so it has global context.$SKILL_DIR/references/step_change_patterns.md as its lens.~/.claude/skills), CLAUDE.md (~/.claude/CLAUDE.md), and settings.json (~/.claude/settings.json), for cross-reference.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.
This is where the skill earns its name.
references/step_change_patterns.md as 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.references/report_template.md.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.
references/step_change_patterns.md explicitly calls these out; reread before synthesis.$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.
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 subagentsdevelopment
Draft short, plainspoken notes in the author's voice that help reviewers understand non-obvious choices, boundaries, and preserved behavior in the author's own pull request or local diff. Use when the user asks to self-review, annotate, or add reviewer context to their PR or changes. Draft locally when no PR exists, and post approved notes as one GitHub review when a PR does exist. Do not use for reviewing someone else's PR, writing code comments, explaining code generally, or drafting a PR description. Never post without explicit approval.
tools
Design and build pure-CSS (zero-JavaScript) Tailwind CSS v4 plugins of unusual depth and craft. Use when the user wants to create, architect, or refine a Tailwind utility plugin or CSS effect — e.g. "make a tailwind plugin", "build a tw-* plugin", "a CSS-only shimmer/fade/glow/grain/noise utility", "tailwind v4 @utility", "package this effect as a plugin", or wants an effect with surprising visual depth (gradients, masks, filters, SVG filter tricks, scroll-driven animation). Pairs deep CSS/SVG technique research with a bespoke tuning workbench for dialing the effect in. Inspired by tw-fade and tw-shimmer.
content-media
Create clear, polished before-and-after screenshots for a GitHub pull request. Use when a UI change needs visual proof: capture matching states, crop to the relevant UI, stitch and caption one comparison image, attach it natively to the PR, and keep the image out of the repository.
testing
--- name: latent-potential description: First-principles, team-of-experts assessment of a software project that surfaces latent potential; underexploited assets, a sharper north star, missing high-leverage capabilities, better framing and messaging. Produces a prioritized, evidence-grounded report with cheap probes, a reframe candidate, a stop-doing list, and an honest skeptic's case. Use whenever the user wants fresh eyes on a project they have built: "what am I sitting on", "what could this be