thermo-nuclear-code-quality-review

name	thermo-nuclear-code-quality-review
description	Run an opt-in strict maintainability review for giant files, spaghetti growth, misplaced logic, weak boundaries, unnecessary abstractions, and missed structural simplifications. Use for a thermonuclear review, harsh code-quality audit, code-judo review, or a file approaching 1000 lines. Do not use as an automatic rewrite mandate or for cosmetic cleanup.
disable-model-invocation	true

Strict Code Quality Review

This is an unusually demanding review mode, not an instruction to rewrite code by taste. Inspect the current diff and surrounding architecture, then report only high-conviction findings grounded in a contract, reachable behavior, or a material maintainability risk.

Review Bar

Ask:

• Can a simpler ownership boundary remove whole branches or concepts?
• Did the diff add ad-hoc flags, special cases, or feature logic to a shared path instead of using the canonical layer?
• Did a cohesive module become more coupled or cross a meaningful shape limit?
• Are wrappers, casts, optionality, and sequential orchestration earning their complexity?
• Does a proposed decomposition reduce what a reader must hold in mind, rather than merely move the same complexity into more files?

A file crossing roughly 1000 lines is a strong signal to inspect decomposition, not an automatic failure. Apply the project's actual shape policy and explain why a split would improve ownership. Do not manufacture a rewrite when the current structure is coherent and the change is small.

Output

Report findings in this order:

1. structural regressions;
2. missing simplifications with a concrete alternative;
3. spaghetti or branching growth;
4. boundary and type-contract problems;
5. file shape and decomposition;
6. lower-severity readability issues.

For each finding include file/line, contract or evidence, user/operator impact, and a concrete remedy. Separate BLOCKER, ADVISORY, and ACCEPTED decisions. If no finding survives reachability, materiality, and evidence screening, say so.

Independence and scope

Use a fresh reviewer for non-trivial changes. This review does not replace focused tests, security proof, or proof-verify; it evaluates maintainability and architecture. It must not silently edit production code or turn an advisory concern into a rewrite.

Gotchas

• Ambition without a contract becomes over-engineering. Keep the selection gate: a sufficient implementation is a reason to stop expanding.
• A line count is a probe, not a universal design law.
• Moving code across files without reducing coupling is not a successful decomposition.
• Passing tests do not erase a material architecture regression, but a style preference without impact is not a blocker.

Troubleshooting

Symptom	Likely cause	Action
Review proposes a rewrite for a tiny diff	Scope or trigger was too broad	Limit the review to changed behavior and material risks
Many low-value nits	No severity/materiality screen	Keep only findings with evidence and an actionable remedy
File is large but coherent	Threshold treated as a verdict	Record ACCEPTED with rationale and keep the stable boundary
Suggested split adds more indirection	Complexity moved, not removed	Reject it and compare the reader's concepts before/after

Source

Adapted from Cursor Team Kit's MIT-licensed thermo-nuclear-code-quality-review: https://github.com/cursor/plugins/tree/main/cursor-team-kit/skills/thermo-nuclear-code-quality-review