Audit Toolkit
Overview
One entry point that maps the entire audit-and-fix toolkit and routes you to the right skill for your goal. It does NOT load every skill — that would blow the context window. It names the skills by purpose so you (or the human) pick the one that fits, then invoke that skill directly. Pick by GOAL, not by running everything.
When to use / when NOT
Use when: the human wants to assess or improve an existing project but has not named a specific dimension; you need to decide between a quick readiness gate, a deep audit, a focused single-dimension pass, or a full audit-to-fix pipeline.
Do NOT use when: the dimension is already obvious — invoke that skill directly (e.g. "is the docs site deployable?" → docs-deploy-readiness; "review this PR" → code-audit or a normal review). This is a router, not a step in any pipeline.
Decision router — goal → reach for
| Your goal |
Reach for |
| One go/no-go answer: "is it ready to ship?" |
release-audit (detects shape, dispatches the right dimensions, one scorecard + blockers) |
| Deep audit → prioritized fix-spec → execute the fixes |
nuke-audit (audit→spec), then nuke-exec (execute the spec — formerly nuke-fix) |
| Run a large audit that must CONVERGE and survive usage limits / crashes |
convergence-loop (the orchestration engine this repo's focused audits run on) |
| Is a publishable artifact (package/library/SDK/CLI/registry) handoff-ready? |
handoff-readiness |
| Is a docs / content site deploy-ready (coverage, accuracy, SEO, prose)? |
docs-deploy-readiness |
| What attack surface does this expose (web / local server / CLI / lib / deploy)? |
security-surface-audit (audit of exposure) · security-review (implementation-time checklist) |
| Internal codenames / jargon leaking onto public or reusable surfaces? |
jargon-leak |
| Cross-package duplication, missed reuse, consolidation targets |
reusability-audit |
| DRY / SRP / naming / dead code / types / errors across the codebase |
code-audit |
| AI-slop: filler comments, over-engineering, defensive over-coding |
anti-slop (audit) · anti-slop-fix (auto-fix) |
| Maximum-rigor quality / correctness sweep on critical code |
nuke-audit in full mode |
| Apply state-of-the-art bar to whatever you are building or reviewing |
sota (before) · sota-verify (after implementing a spec) |
| User-facing prose reads machine-generated |
humanizer (any text) · humanize-readme (READMEs) |
| React code quality |
react-senior-guide (+ its subskills) |
| Accessibility conformance of a UI |
accessibility-compliance |
| Test quality / behavior-vs-implementation |
test-behavior-not-implementation |
The pipeline
For a project you intend to release, the tools compose into a pipeline — use as much of it as the goal needs:
release-audit quick gate: is it ready? scorecard + ship-blockers (stop here if you only need a verdict)
│ NOT READY and you want it fixed
▼
nuke-audit deep multi-round audit → converged findings ledger → prioritized fix-spec
│ (has its own convergence loop; pulls dimension content from the focused + library skills above)
▼
nuke-exec execute the fix-spec phase by phase, fresh-agent validation per phase, gates green
▼
sota-verify confirm the implemented spec meets the bar; loop until clean
▼
(human/runtime) the things static analysis cannot prove: clean-env build, publish smoke,
deploy dry-run, live perf, real screen-reader pass
The focused skills (handoff-readiness, docs-deploy-readiness, security-surface-audit, jargon-leak) and the library skills (code-audit, reusability-audit, anti-slop, humanizer, react-senior-guide, accessibility-compliance) are the DIMENSIONS that release-audit and nuke-audit dispatch — you can also run any of them standalone when you only care about that one dimension.
How to pick (fast)
- Just want a verdict? → release-audit. Done.
- Want it actually fixed? → nuke-audit → nuke-exec.
- One known dimension? → invoke that focused/library skill directly (router table above).
- Big codebase, long run, limit-prone? → whichever audit, but make sure it runs on convergence-loop.
Common mistakes
- Trying to load everything. This skill is a map, not a bundle. Force-loading 15 skills blows the context window. Name and invoke the ONE that fits the goal.
- Deep audit when a gate would do. If the human only wants go/no-go, release-audit answers in one pass — don't spin up nuke-audit.
- Gate when they wanted fixes. "Is it ready?" → release-audit. "Make it ready" → nuke-audit → nuke-exec. Match the verb.
- Skipping the runtime caveats. No static audit proves a clean-environment build, a publish smoke, or a screen-reader pass. Always hand those to the human.
- Referencing skills via @-paths. Name them; @-paths force-load and burn context.
1---2name: audit-toolkit3description: Use when you want to audit, review, harden, ship, or remediate a codebase but are not sure which audit/review/fix skill to reach for — the single index and decision-router for the whole audit-and-fix toolkit. Triggers include "audit this", "review the codebase", "is this ready", "what audit should I run", "harden this", "find issues and fix them", "release readiness", "deep quality review", or any broad ask to assess or improve an existing project's quality, security, docs, or shippability.4---56# Audit Toolkit78## Overview910One entry point that maps the entire audit-and-fix toolkit and routes you to the right skill for your goal. It does NOT load every skill — that would blow the context window. It names the skills by purpose so you (or the human) pick the one that fits, then invoke that skill directly. Pick by GOAL, not by running everything.1112## When to use / when NOT1314**Use when:** the human wants to assess or improve an existing project but has not named a specific dimension; you need to decide between a quick readiness gate, a deep audit, a focused single-dimension pass, or a full audit-to-fix pipeline.1516**Do NOT use when:** the dimension is already obvious — invoke that skill directly (e.g. "is the docs site deployable?" → **docs-deploy-readiness**; "review this PR" → **code-audit** or a normal review). This is a router, not a step in any pipeline.1718## Decision router — goal → reach for1920| Your goal | Reach for |21|---|---|22| One go/no-go answer: "is it ready to ship?" | **release-audit** (detects shape, dispatches the right dimensions, one scorecard + blockers) |23| Deep audit → prioritized fix-spec → execute the fixes | **nuke-audit** (audit→spec), then **nuke-exec** (execute the spec — formerly nuke-fix) |24| Run a large audit that must CONVERGE and survive usage limits / crashes | **convergence-loop** (the orchestration engine this repo's focused audits run on) |25| Is a publishable artifact (package/library/SDK/CLI/registry) handoff-ready? | **handoff-readiness** |26| Is a docs / content site deploy-ready (coverage, accuracy, SEO, prose)? | **docs-deploy-readiness** |27| What attack surface does this expose (web / local server / CLI / lib / deploy)? | **security-surface-audit** (audit of exposure) · **security-review** (implementation-time checklist) |28| Internal codenames / jargon leaking onto public or reusable surfaces? | **jargon-leak** |29| Cross-package duplication, missed reuse, consolidation targets | **reusability-audit** |30| DRY / SRP / naming / dead code / types / errors across the codebase | **code-audit** |31| AI-slop: filler comments, over-engineering, defensive over-coding | **anti-slop** (audit) · **anti-slop-fix** (auto-fix) |32| Maximum-rigor quality / correctness sweep on critical code | **nuke-audit** in full mode |33| Apply state-of-the-art bar to whatever you are building or reviewing | **sota** (before) · **sota-verify** (after implementing a spec) |34| User-facing prose reads machine-generated | **humanizer** (any text) · **humanize-readme** (READMEs) |35| React code quality | **react-senior-guide** (+ its subskills) |36| Accessibility conformance of a UI | **accessibility-compliance** |37| Test quality / behavior-vs-implementation | **test-behavior-not-implementation** |3839## The pipeline4041For a project you intend to release, the tools compose into a pipeline — use as much of it as the goal needs:4243```text44release-audit quick gate: is it ready? scorecard + ship-blockers (stop here if you only need a verdict)45 │ NOT READY and you want it fixed46 ▼47nuke-audit deep multi-round audit → converged findings ledger → prioritized fix-spec48 │ (has its own convergence loop; pulls dimension content from the focused + library skills above)49 ▼50nuke-exec execute the fix-spec phase by phase, fresh-agent validation per phase, gates green51 ▼52sota-verify confirm the implemented spec meets the bar; loop until clean53 ▼54(human/runtime) the things static analysis cannot prove: clean-env build, publish smoke,55 deploy dry-run, live perf, real screen-reader pass56```5758The focused skills (**handoff-readiness**, **docs-deploy-readiness**, **security-surface-audit**, **jargon-leak**) and the library skills (**code-audit**, **reusability-audit**, **anti-slop**, **humanizer**, **react-senior-guide**, **accessibility-compliance**) are the DIMENSIONS that **release-audit** and **nuke-audit** dispatch — you can also run any of them standalone when you only care about that one dimension.5960## How to pick (fast)61621. **Just want a verdict?** → **release-audit**. Done.632. **Want it actually fixed?** → **nuke-audit** → **nuke-exec**.643. **One known dimension?** → invoke that focused/library skill directly (router table above).654. **Big codebase, long run, limit-prone?** → whichever audit, but make sure it runs on **convergence-loop**.6667## Common mistakes6869- **Trying to load everything.** This skill is a map, not a bundle. Force-loading 15 skills blows the context window. Name and invoke the ONE that fits the goal.70- **Deep audit when a gate would do.** If the human only wants go/no-go, **release-audit** answers in one pass — don't spin up **nuke-audit**.71- **Gate when they wanted fixes.** "Is it ready?" → release-audit. "Make it ready" → nuke-audit → nuke-exec. Match the verb.72- **Skipping the runtime caveats.** No static audit proves a clean-environment build, a publish smoke, or a screen-reader pass. Always hand those to the human.73- **Referencing skills via @-paths.** Name them; @-paths force-load and burn context.
b4r7x