Help us improve
Share bugs, ideas, or general feedback.
From darkroom
Audits entire codebase for structural quality, file sprawl, thin wrappers, leaked logic, spaghetti growth, and dependency freshness via context7. Encourages code-judo simplifications.
npx claudepluginhub darkroomengineering/cc-settingsHow this skill is triggered — by the user, by Claude, or both
Slash command
/darkroom:nuclear-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
An unusually strict **whole-codebase** maintainability audit. Reviews implementation quality, abstraction quality, structural simplification opportunities, **and** dependency freshness + usage quality.
Runs an unusually strict maintainability review focused on abstraction quality, file size limits, and spaghetti-condition growth. Use for deep code quality audits or harsh structural reviews.
Extremely strict maintainability review focusing on abstraction quality, file size discipline, and spaghetti-condition prevention. Useful for harsh code quality audits or deep structural reviews.
Runs mechanical checks (build, typecheck, lint, tests, secrets scan) then dispatches specialist reviewers and produces a scored codebase health report. Use for code quality, security, or performance audits.
Share bugs, ideas, or general feedback.
An unusually strict whole-codebase maintainability audit. Reviews implementation quality, abstraction quality, structural simplification opportunities, and dependency freshness + usage quality.
Adapted from Cursor's internal thermo-nuclear-code-quality-review skill. Cursor's version targets a single PR diff; this version targets the entire repository and adds a context7-driven dependency audit on top, because the same questions ("is this the right abstraction?", "is this thin wrapper earning its keep?") apply equally to library choices.
Above all, this skill should push the reviewer to be ambitious about code structure. Do not merely identify local cleanup opportunities. Actively search for "code judo" moves: restructurings that preserve behavior while making the implementation dramatically simpler, smaller, more direct, and more elegant.
/review — per-PR Darkroom checklist (TypeScript / React / a11y / perf / security). Run on every change./nuclear-review — periodic whole-codebase audit. Run on major version cuts, after extended velocity sprints, before a load-bearing migration, or whenever the codebase feels heavier than its features warrant./zero-tech-debt — rework a specific patch to its intended end-state. Not a review — it edits.A typical sequence: /nuclear-review produces findings → engineers cherry-pick the highest-leverage ones → /zero-tech-debt or /refactor to execute.
Tip (Claude Code v2.1.154+): run
/effort ultracodebefore invoking this skill. The whole-codebase audit is the canonical shape that benefits from dynamic workflows — phase state lives in the workflow script rather than Claude's context window, individual modules can be reviewed in parallel (up to 16 concurrent), and the run can resume from cached agent results within the session.A ready-made example ships at
references/nuclear-review.workflow.js(installed to~/.claude/skills/nuclear-review/references/). It is opt-in, not a dependency — the skill above works with no Workflow tool. Run it withWorkflow({ scriptPath: "~/.claude/skills/nuclear-review/references/nuclear-review.workflow.js" }), or copy it into.claude/workflows/. It maps the repo, fans out one structural reviewer per module, audits dependencies, and synthesizes one report. Treat it as a template — adapt its module list, schemas, and phases to the repo at hand rather than running it verbatim.
The audit covers the entire codebase, not the current diff. That includes:
package.json + lockfile) — every direct dependencySkip vendored code, generated files, and node_modules.
Establish ground truth before judging anything.
# Top-level structure
fd -t d -d 2 --hidden -E node_modules -E .git -E dist -E build
# File-size distribution (largest first) — find the 1k-line crossings
fd -t f -E node_modules -E .git -E dist -E build \
-e ts -e tsx -e js -e jsx -e py -e go -e rs \
-x wc -l {} \; | sort -rn | head -50
# Direct dependency count
jq '.dependencies + .devDependencies | length' package.json
# Direct deps with versions
jq '.dependencies + .devDependencies' package.json
If the project uses tldr, prefer it for the call graph + dead-code pass:
tldr arch .
tldr dead . --entry-points "main,test_"
For each direct dependency in package.json, use the context7 MCP server to verify:
Use context7 in two steps per dependency:
mcp__context7__resolve-library-id { libraryName: "<package>", query: "<what we use it for>" }
mcp__context7__query-docs { libraryId: "<resolved id>", query: "current recommended usage vs <pattern we use>" }
Cap context7 calls at 3 per dependency (per the server's own guidance). Batch the audit: pick the top 10–20 by either bundle weight or surface-area coverage rather than auditing every transitive dep.
Output for each flagged dep: current version → recommended version, deprecated APIs in use, suggested fix.
Apply the non-negotiable standards below to the codebase as a whole. Walk the largest files first, then the modules with the most outbound dependencies, then the entry points.
Produce the output in the format below. Prioritize ruthlessly — a smaller number of high-conviction findings beats a long list.
A nuclear-review that produces fixes but leaves the docs stale is half-done. Whenever findings from this skill turn into code changes, the same pass must touch the docs that describe them. If you only produce the report (no fixes in this session), skip this phase — but flag it for whoever applies the fixes.
For each commit that lands from the audit, update the docs in scope for the change:
| Type of change | What to update |
|---|---|
| New skill / agent / hook / profile | MANUAL.md (the "All Skills" / "All Agents" table + the appropriate prose section), CHANGELOG.md, skill-count references in CLAUDE.md / CLAUDE-FULL.md if the count moves |
| Structural refactor (dedup, extract module, rename across files) | CHANGELOG.md — a one-paragraph entry under [Unreleased] explaining what moved and why |
| Dependency upgrade or deprecated-API swap | CHANGELOG.md — note the package, the old vs new pattern, and any caller-visible behavior |
| New canonical helper that supersedes inline duplicates | CHANGELOG.md, and rules/*.md if the helper is now the project-wide recommended pattern |
| Type/boundary cleanup at a JSON or external-input boundary | CHANGELOG.md, and docs/security-reference.md if the change affects validation |
| API surface change (exported function signature, public schema) | CHANGELOG.md, docs/*-reference.md for any reference docs that mention the symbol, schemas via bun run schemas:emit if the zod surface moved |
Rules for the doc pass:
[Unreleased] entry per landed commit, or one consolidated entry if multiple commits ship together. Don't leave audit-driven refactors anonymous in git history.MANUAL.md intro, CLAUDE.md, CLAUDE-FULL.md).src/schemas/, run bun run schemas:emit and commit the resulting schemas/*.schema.json diff alongside the source change.MANUAL.md triggers tables when a skill's invocation phrasing changes or when a new skill goes in.Verify the doc pass landed correctly before finishing:
bun run lint:skills # frontmatter sanity
bun run schemas:check # derived schemas in sync with sources
git diff --stat HEAD~N HEAD # confirm doc files are in the diff
Be ambitious about structural simplification.
Flag every file over 1k lines.
Do not tolerate spaghetti.
Bias toward cleaning the design, not preserving working code.
Prefer direct, boring, maintainable code over hacky or magical code.
Push hard on type and boundary cleanliness.
unknown, any, or cast-heavy code when a clearer type boundary could exist.Keep logic in the canonical layer and reuse existing helpers.
Treat unnecessary sequential orchestration and non-atomic updates as design smells.
Dependencies must be current and well-used.
For every meaningful surface, ask:
any, unknown, or optional params that muddy the real contract.Do not be satisfied with "maybe rename this" feedback when the real issue is structural.
Direct, serious, demanding about quality. Not rude, but do not soften major maintainability issues into mild suggestions. If the codebase is messier than its features warrant, say so clearly. If a path to a dramatic simplification was missed, say that too.
## Verdict
[CLEAN / NEEDS RESTRUCTURING / NEEDS MAJOR REWORK]
## Code-Judo Opportunities
- [Dramatic simplifications: what to delete, not just polish. Pointers to specific files / modules.]
## Structural Blockers
- [Files over 1k lines, spaghetti growth, boundary leaks, with file paths]
## Dependency Audit (context7)
- [pkg@current → recommended] [reason: stale major / deprecated API in use / duplicates X / unused / etc.]
## Abstraction / Type Cleanup
- [Wrappers, casts, optionality, leaked invariants, with file paths]
## Notes
- [Smaller maintainability concerns worth flagging]
Prioritize findings in this order:
Do not flood the report with low-value nits if there are larger structural issues. Prefer a smaller number of high-conviction comments over a long list of cosmetic notes.
A codebase passes nuclear-review when:
any / unknown papering over an unclear invariant.If any of those fail, the report must include explicit, actionable feedback and push for the cleaner shape.
Structural rubric ported from cursor/plugins/cursor-team-kit/skills/thermo-nuclear-code-quality-review. Reported by Eric Zakariasson as Cursor's most-used internal skill. The whole-codebase scope and context7 dependency audit are cc-settings additions.