Thermo-Nuclear Code Review
What it is, who should use it, how to run it.
Disclaimer: I am an actuary. ASA designation pending (expected June or July 2026). The thoughts and analyses here are my own explorations, not professional advice. Draw your own conclusions.
What it is
The thermo-nuclear code review is a rubric shipped in the Cursor team kit under the skill name thermo-nuclear-code-quality-review. It is a single-pass rigorous audit of a codebase or pull request, calibrated harder than a normal review. The rubric asks four things of every layer it touches:
- Does this abstraction earn its place, or could the code below it be called directly?
- Could this file be half its size and still do the job?
- Is each indirection load-bearing, or is it polish on a layer that should be deleted?
- State the mechanism, cite the line, propose the fix.
It is not a style linter. It does not grade on a curve. It treats "works fine" and "has tests" as table stakes and looks for the cuts an LGTM review misses: dead branches, double-fetches, silent no-ops, schema drift, indirection that exists only to make the diff feel small.
Who should use it
Anyone shipping code they wrote themselves, on a codebase they own end-to-end, where the cost of a bug is paid by them and not a separate QA org. Solo developers, small teams, side projects, founder-built infrastructure. The rubric earns its keep when the same person who wrote the abstraction is the one who has to live with it six months later.
It is less useful inside a large team with an established review culture, a strong test pyramid, and a separate platform group already paid to enforce architecture. Those teams have other defenses. The thermo-nuclear pass is a defense for code that has none of those, which is most personal infrastructure.
It also works as a rigorous pre-pass before you ask a senior engineer to review your PR. Run it on your own diff first. Fix the embarrassing things in private.
How to use it
Install the Cursor team kit, load the thermo-nuclear-code-quality-review skill, and run it against a specific target: a file, a directory, a pull request diff, a single function. Scope matters. A whole-repo sweep produces noise; a one-PR sweep produces three concrete deltas you can ship the same afternoon.
Workflow that holds up:
- Pick the target. One file, one PR, one route. Not a whole repo.
- Run the rubric. Capture the findings as a list, with line numbers and mechanism notes.
- Triage by ROI. Structural blockers (monolith splits, route decompositions) first, dead code second, polish never.
- Land each fix as its own commit. The diff is the audit trail.
- Verify the behavior is unchanged. Smoke tests, manual probes, before/after byte counts.
Two cautions. The rubric will tell you to delete things you are emotionally attached to. Delete them anyway. And the rubric will surface bugs adjacent to the structural work, not from the structural work itself. Budget time for the bugs. They are the dividend.
Good luck, happy coding
The rubric is short. Read every line. Run it on code you wrote.