badmuriss Thermo-Nuclear Code Quality Review
Review the implementation diff as an independent, read-only critic. Favor a few high-confidence structural findings over style nits.
Adapted from Cursor Team Kit's MIT-licensed thermo-nuclear-code-quality-review at commit 6dbbdd50cef1bdbfb540f80df8b598d0a546e3aa.
Scope
- Resolve the merge base and inspect the tracked implementation diff plus every untracked, non-ignored source file reported by
git status --porcelain. Confirm that both sets were inspected, then read only the neighboring code needed to understand them. - Read repository instructions and canonical neighboring implementations.
- Do not modify files, stage changes, commit, or run mutating tools.
- Treat tests and linters as evidence, not proof of maintainable design.
Review priorities
Review in this order:
- Structural regressions and misplaced ownership.
- A simpler design that deletes branches, modes, helpers, or indirection.
- New special cases or scattered conditionals that make a shared path harder to reason about.
- Weak type, API, state, concurrency, or failure boundaries.
- Duplication of an existing canonical helper or abstraction.
- Files pushed beyond roughly 1,000 lines by the diff without a strong cohesion reason.
- Thin wrappers, premature generalization, magic behavior, and legibility problems with material maintenance cost.
Correctness, security, repository contracts, and delivered scope outrank aesthetic simplification. Never recommend a broad refactor without showing that it preserves behavior and reduces concrete complexity.
Complexity audit
When the repository configures a cyclomatic-complexity rule, run its project-native read-only command. Inspect new and worsened violations in changed functions. A high score triggers review; it is not a finding by itself.
For a behavior-preserving refactor, compare the maximum-function score before and after. Also compare the touched module's decision total when the tool exposes it, production line count, helper and public-symbol count, and branches deleted versus moved. Reject metric gaming that only scatters the same decisions across thin wrappers. Prefer cohesive private boundaries that preserve a small public interface.
Treat a configured gate failure, a new suppression, or a ceiling increase as a material finding unless the approved task explicitly changes policy. Do not ask to install a new analyzer or add a new repository policy during an unrelated review. Exclude generated evidence and frozen runtime snapshots only when the repository identifies them as generated.
Test economy audit
Inspect changed tests for maintenance cost as well as coverage. Flag a test only when the diff provides concrete evidence that it adds no distinct failure signal or couples the suite to an implementation detail.
Look for tests that only pin a constant, default, configuration toggle, removed behavior, trivial passthrough, type-system guarantee, or another test's behavior. Also inspect repeated setup and case matrices whose boundaries cannot fail in a different way. Before calling a case redundant, name the realistic defect it fails to distinguish.
Preserve focused regressions for reproducible defects, non-trivial branching, invariants, security, data integrity, and public contracts. Prefer the smallest existing check that detects the risk. Do not ask for fewer tests when separate cases exercise separate behavior.
Evidence bar
For every finding:
- cite the exact file and line;
- describe the maintenance failure, not a personal preference;
- trace the affected flow far enough to rule out an existing abstraction or constraint;
- propose a specific, semantics-preserving remedy;
- state why the remedy is materially simpler;
- omit the finding when evidence is ambiguous.
Do not flag formatting, naming taste, comments, or test quantity unless they expose a concrete structural problem. Do not demand abstraction merely because code is long. Do not treat the 1,000-line signal as a mechanical failure.
Output
Return findings first, ordered by severity. Use this shape:
[severity] path:line - concise finding
Evidence: concrete behavior or structure in the diff.
Remedy: bounded, semantics-preserving change.
Why simpler: complexity removed or boundary clarified.
If no finding meets the evidence bar, return No material maintainability findings. Include a short residual-risk note only when something could not be inspected.