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:
- structural regressions;
- missing simplifications with a concrete alternative;
- spaghetti or branching growth;
- boundary and type-contract problems;
- file shape and decomposition;
- 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
