audit

Featured

Whole-repo audits in four modes. Maintainability mode is a strict structural audit — 1k-line sprawl, thin wrappers, leaked logic, dependency freshness via context7, "code-judo" deletions. Triggers "nuclear review", "thermonuclear review", "code judo", "deep code quality audit", "harsh maintainability review", "whole codebase review", "should this exist". Codebase/Docs/Process modes are adversarial honesty audits hunting defects, drift, dead ends rather than validating. Codebase mode triggers "adversarial audit", "fable audit", "expectation gaps", "correctness audit". Docs mode triggers "audit the docs", "docs audit", "doc drift". Process mode triggers "process audit", "audit the workflows", "walk the journeys", "end-to-end audit". Also owns the bare "audit the codebase" — when phrasing doesn't pin a mode, asks ONE question (maintainability vs correctness) before fanning out. Sibling to `/review`, `/zero-tech-debt`, `/verify`.

AI & Automation 42 stars 3 forks Updated today MIT

Install

View on GitHub

Quality Score: 89/100

Stars 20%
54
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Audit One skill, four whole-repo audit modes sharing a skeleton: read the surface **in full** (never sample), hunt with explicit categories, and ship a prioritized, executable report. Two families of question: - **Maintainability** — ported from Cursor's internal `thermo-nuclear-code-quality-review` skill (reported by Eric Zakariasson as Cursor's most-used internal skill; this mode was formerly the standalone `/nuclear-review` skill). Asks **should this code exist?** — structural quality, 1k-line sprawl, thin wrappers, code-judo deletions, dependency freshness via context7. - **Codebase, Docs, and Process** — adapted from the fable audit goal-spec trio (gist `diegomarino/04970a2b8d9cc419de3ba05b9a03db5a`; these modes were formerly the standalone `/adversarial-audit` skill). Ask **does it do what it promises?** — correctness/coherence/affordances (codebase), truth and structure of the docs (docs), walkable end-to-end journeys (process). The July 2026 cc-settings audit ran the codebase spec and produced 28 findings, ~all confirmed and fixed. The mechanics that made that work (stable IDs, CONFIRMED/PLAUSIBLE, concrete failure scenarios, design tensions vs line findings, open questions for the maintainer) are the contract for these three modes, whatever the mode. Maintainability mode should push to be **ambitious** about code structure — do not merely identify local cleanup opportunities, actively search for "code judo" moves. The other three modes hold **no loyalty to the c...

Details

Author
darkroomengineering
Repository
darkroomengineering/cc-settings
Created
7 months ago
Last Updated
today
Language
TypeScript
License
MIT

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

audit

Analyses code from several independent perspectives, then makes those perspectives argue with each other until they converge on a shared verdict. Each lens reviews blind, every finding is cross-examined by a lens that wants to kill it, conflicts are resolved as explicit trade-offs rather than averaged away, and the result is a ranked findings table with recorded dissent plus a full analysis. Use when the user says "/audit", "audit this code", "red-team this", "review this code from every angle", "review this code", "critique this", "analyse this code", "what's wrong with this", "look at this from every angle", "is this any good". For rewriting use rewrite, for improving in place use refactor, for UI use reskin. This skill judges code — for measuring data and writing the result up as a report, use report instead.

0 Updated today
olcayseygan
Code & Development Listed

codebase-audit

Whole-repo, multi-agent audit that IS the Sprint-end cross-review ceremony (product-wide integrity): 4 axes — spec-conformance, logic/defect hunt, redundancy, and product-security — over the ACCUMULATED codebase at HEAD, not the Sprint diff. Findings are swept to zero per defect class — one class = one PBI covering every occurrence, documentation drift batched into a single DOCS PBI — and non-blocking: EVERY finding is PO-adjudicated, Critical/High carrying a next-Sprint recommendation, and a rejected finding is suppressed with a recorded decision. At Integration-Sprint entry a thin re-check confirms the latest audit is fresh and no open blocking (non-Low) audit PBIs remain before testing proceeds.

16 Updated today
sohei56
AI & Automation Listed

code-check

Use for code review, quality audits, SOLID/DRY consistency checks, pattern audits across the codebase, or verifying anti-pattern compliance across a scope.

7 Updated yesterday
grimoire-rs