repo-audit

A common ask is a whole-repo read that ends in a report: "analyze this repo in very detail, find bugs", "analyze again complete repo", then "give me report". code-review sees a diff, a graph tool explains structure; nothing owns the deep single-repo pass. Read-only by design: the fix is the user's next message.

Read first

• Your always-on rules, if you keep them (honesty and verification; a described problem gets an assessment, not a patch)
• The repo's CLAUDE.md, README.md, TODO.md, docs/ index, the last 30 commits (git log --oneline -30), open issues (gh issue list --state open)
• graphify-out/ when present and the graphify skill is installed: graphify query "<question>" before grepping for architecture questions

Procedure

1. Header first: repo, branch, git rev-parse --short HEAD, files by language (git ls-files | sed 's/.*\.//' | sort | uniq -c | sort -rn | head), entry points, deploy target. Print it before anything else.
2. Baseline the repo's own gates once, exactly as its CLAUDE.md names them (pnpm run check, uv run pytest, npm run typecheck, pnpm build). Record pass/fail with counts. A red baseline is finding #1, not a stop.
3. Sweep in lanes. Over ~150 source files, fan the lanes out with the parallel skill (one read-only agent per lane, shared return shape file:line | severity | claim | evidence | one-line fix); below that, run them yourself in this order.

4. Deduplicate across lanes, then rank: critical (data loss, auth, secrets), high (wrong output, red gate, vulnerable dep), medium (perf, structure), low (style, docs). A finding without evidence is dropped, not softened.
5. Verify the top ten yourself before publishing: open the file, run the repro. Subagent findings are claims until you looked: the summary describes intent, not reality.
6. Print the report and stop. The last line is the offer. When the user answers "fix", "fix all", or names numbers ("do 1, 3, 4"), the report is the worklist for fix-all (enumerate-first, fixed N/N); a single named finding is fixed inline on a branch and verified the way its evidence column says.

Output

repo <owner>/<repo> @ <sha> on <branch> | 412 files (ts 288, py 61, md 24) | <YYYY-MM-DD>
baseline: pnpm run check FAIL (2 type errors) | tests 212/214 | build pass

| # | sev | lane | file:line | finding | evidence | fix (one line) |
| 1 | critical | security | backend/api/upload.py:88 | soft delete not user-scoped | grep shows no user_id predicate on the query | add user_id filter |
| ... |

counts: critical 1, high 4, medium 9, low 6 (20 total, 20 with evidence)
skipped on purpose: <area> (reason)
say "fix" to run fix-all on this list, or name the numbers to do.

Must not

• Never edit, format, commit, or open a PR from this skill; report only.
• Never state a bug without file:line plus the command or input that shows it; "looks suspicious" is not a finding.
• Never stop at the first hits in a lane; grep the full set and give counts.
• Never pad with generic advice (add tests, add docs, enable strict); each finding names this repo's line.
• Never audit an upstream fork as if it were the user's own; its bugs go through the oss skill and its 7/10 bar.
• Never read .env* or local database file contents; tracking state and existence are the findings, never the values.
• Never chain commands with a double ampersand; one per line.

Non-goals

Diff review (code-review), architecture explanation (graph or diagram skills, if installed), the fix itself (fix-all), docs rewrite (docs-fresh), CI repair (gh-actions), design critique (a design skill, if installed).