Can a "thermonuclear" review skill stop the AI slop?

Why automated code review matters

Matt Pocock opens with a blunt claim: automated code review is "one of the most impactful ways that you can improve the code quality coming out of your agent." 0:00

The logic is simple. When an AI agent writes code, the fastest way to raise its quality is to have a second agent review that code against a strict standard, before a human ever looks at it. Matt already keeps his own review skill in a public repo (109,000 stars at the time of filming), but he marks it "in progress" because he isn't happy with it. So he does what good engineers do: he goes hunting for other people's skills to steal ideas from.

Meet the "thermonuclear" skill

The skill that catches Matt's eye comes from the Cursor team. It's called thermo-nuclear-code-quality-review, and it's just one file: a single SKILL.md. Its description promises "an extremely strict maintainability review for abstraction quality, giant files, and spaghetti." 0:39

What Matt finds notable is how ambitious it tells the reviewer to be. Most review prompts are timid. This one explicitly tells the reviewer to hunt for "code judo" moves: restructurings that preserve behavior while making the code dramatically simpler.

Running it on a real codebase

Matt copies the skill to his machine and points it at Sandcastle, his open-source "software factory" (a TypeScript toolkit that orchestrates AI coding agents inside isolated sandboxes). His command is deliberately loose:

"thermonuclear code quality review, review the last five PRs that made it to main."Run on Claude Code, in auto mode, while he reads the skill aloud.

Inside the skill: the rules that matter

While the agent works, Matt reads the skill top to bottom. This is the heart of the lesson: what actually makes a review skill good.

The baseline: be ambitious, look past the diff

The core prompt starts: "Perform a deep code quality audit of the current branch's changes… Rethink how to structure / implement the changes to meaningfully improve code quality without impacting behavior… Be ambitious… Measure twice, cut once." 2:25

Matt's key insight: most review skills fail because of diff bounds. Hand an agent a diff and it treats that diff as the walls of its world. This prompt breaks out of that, telling the reviewer to scan the whole codebase for opportunities, starting from the branch's changes.

The one rule everyone remembers: the 1,000-line wall

Rule 1: "Do not let a PR push a file from under 1k lines to over 1k lines without a very strong reason." Matt reached the same conclusion on his own. Big files hurt agents because to find one useful function, the agent must load the entire file into its context window. Splitting into smaller files lets the filename act as a pointer to what's inside, far more context-efficient. (His personal rubric is 5,000 tokens rather than 1,000 lines.)

Rule 2 is the anti-spaghetti rule: if a change adds weird if statements in random places, treat it as a design problem, not a stylistic nit. Push the logic into a proper abstraction, helper, state machine, or policy object instead.

Types, canonical helpers, and parallelism

More standards worth stealing:

• Prefer direct, boring, maintainable code over hacky, magical code (an echo of Claude Code's simplify skill).
• Push hard on type boundaries: question unnecessary optionality, unknown, any, or cast-heavy code. Matt's pet peeve: agents mark every new prop optional even when it's always required, just to shrink the blast radius.
• Keep logic in the canonical layer and reuse existing helpers over bespoke one-offs.
• Treat needless sequential orchestration as a design smell (run independent work in parallel), but don't over-index on micro-optimizations. Matt calls this rule's wording "word salad."

Then the Primary Review Questions for every change: "Is there a code judo move that would make this dramatically simpler? Can this be reframed so fewer concepts / branches / helper layers are needed?" Matt loves those. He dislikes "Does this improve or worsen the local architecture?", because "improve or worsen" means nothing to an agent unless you define what good and bad look like. 5:45

Output rules: prioritize, don't flood

Finally the skill sets output expectations: report findings in a fixed priority order (structural regressions at the top, legibility at the bottom) and "do not flood the review with low-value nits." Then an explicit approval bar: do not approve just because behavior seems correct. Matt's worry: the whole thing is a "huge ball of mud", and it's genuinely hard for the agent to know what to prioritize inside so much repetitive text. 7:38

Did it actually find anything?

The agent reviewed the last five PRs to main and sorted its findings into tiers. This is where you learn to grade a reviewer, keeping the good calls and dismissing the false positives.

Blocker-class: the 1,094-line file

Top finding: InitService.ts is now 1,094 lines, grown across these PRs with no decomposition. It mixes four registries, six inline Dockerfile constants, package-manager detection, and more. The agent proposed splitting it into per-registry modules, and adding a generic makeRegistry function to delete ~20 lines of duplicated boilerplate. Matt's score: two for two, both genuinely good. 8:48

A good call and a false positive, side by side

On PR #741, the reviewer spotted a feature-specific special case scattered across three layers (if issueTracker.name === 'custom') and suggested pushing that variation into the type itself, a real code judo move. Good call. But it also flagged templateArgs for carrying both real shell commands and prose markers, proposing a discriminated union. Matt knows this code and calls it a false positive from an inaccurate mental model, "which is okay", because a false positive is cheap to say no to. 9:20

The "worst of both worlds" abstraction

On PR #750: a generic dependencies: readonly string[] model that is only ever used for one value ("zod"), hardcoded in three places. The reviewer's line, "worst of both worlds," nails it: it pays the cost of a generic abstraction without the benefit. It also caught execSync inside Effect.sync with swallowed errors, and a file split that was only half finished. 10:00

Where Matt pushes back

The reviewer flagged two prompt files whose diffs are byte-identical and wanted them factored into a shared partial. Matt disagrees: those prompts should stay independently changeable. Not every duplication is a DRY violation worth fixing. Final tally: about five of seven findings genuinely useful. 11:40

The final judgment

Against the skill's own approval bar, the verdict is a rejection: "#741 and #750 should not have landed in their current shape… The behavior is correct in all three substantive PRs, but the codebase is meaningfully messier than it was a week ago." The whole review "cooked for 2 minutes 35 seconds." 11:52

What Matt would change, and what to keep

The most valuable part of the lesson is the critique. A skill that scores 5/7 is useful, but Matt names two real weaknesses. 12:05

His overall verdict: worth pulling down and experimenting with. Steal the ambition and the concrete rules; add the tests-and-seams focus it's missing.

Your score

One-sentence summary

An ambitious, whole-codebase review skill catches real structural problems an ordinary reviewer misses; the false positives it adds are cheap, but you still have to supply the tests-and-seams thinking it leaves out.

Glossary

Every term marked with a dotted underline above. Skim it, or search the page for a word.

Ideas worth stealing into your own setup