Thermo-Nuclear Code Quality Review

Use for a code review that goes beyond "does it work" — it asks whether the implementation is the right shape. The goal is to find "code judo" moves: restructurings that preserve behavior while making the code dramatically simpler, smaller, and more inevitable-feeling.

Don't stop at local cleanup. Actively look for restructurings that delete whole branches, helpers, modes, or layers. If the cleanest version is a rethink, say so.

When to use

• PR introduces significant new logic or restructures an existing flow.
• A file is approaching or crossing 1000 lines.
• The diff adds conditionals scattered across unrelated code paths.
• You want a second opinion that isn't satisfied by "tests pass."

When to skip

• Trivial one-liner or config change.
• Pure test additions with no production logic change.

What to look for

Structural regressions (highest priority):

• A PR pushes a file from under 1k lines to over 1k lines — treat as a decomposition blocker.
• New ad-hoc conditionals bolted onto existing flows — push logic into a dedicated abstraction.
• Feature-specific checks scattered across shared/general-purpose code.

Missed simplifications:

• Is there a reframing that would make whole branches disappear?
• Does the diff add concepts, or remove them?
• Is this abstraction earning its keep, or is it a pass-through wrapper?

Type and boundary problems:

• Unnecessary any, unknown, or cast-heavy code where a cleaner boundary could exist.
• Silent fallbacks that paper over an unclear invariant.

Canonical layer drift:

• Logic added in the wrong layer when a clear canonical home exists.
• Bespoke helper that duplicates something already in the codebase.

Orchestration:

• Independent work serialized for no reason.
• Related updates that can leave state half-applied.

Approval bar

Treat these as presumptive blockers:

• File crosses 1000 lines due to the PR.
• Plausible code-judo move exists but wasn't taken.
• New spaghetti branching in an already-busy flow.
• Feature logic leaking into shared paths.
• Unnecessary wrapper, cast, or optional that makes the design more indirect.
• Logic duplicated instead of reusing the canonical helper.

Do not approve merely because behavior is correct. The bar is: no structural regression, no obvious missed simplification.

Output should feel like

• A small number of high-conviction structural comments, not a long list of nits.
• Findings prioritized: structural regressions first, then missed simplifications, then boundary/type problems, then file-size concerns.
• Direct, demanding tone — "this pushes the file past 1k lines, can we decompose first?" not "consider splitting this."

Related

• improve-codebase-architecture — longer-horizon architecture improvement using seams and depth.
• skills-index — vault catalog.