Overview
Matt Pocock examines the thermonuclear code quality review skill from Cursor's official plugins repo — an aggressively ambitious automated code review prompt that pushes AI agents to suggest structural improvements, not just surface-level style fixes. He tests it against his own open-source project Sandcastle (a software factory), walks through the skill's instructions line by line, and evaluates the quality of its feedback: 5 out of 7 suggestions hit the mark, proving that high-ambition prompts with some false positives are better than conservative reviews that miss real opportunities for improvement.
1 Why Automated Code Review Matters
Matt opens by stating that automated code review is one of the most impactful ways to improve code quality coming out of AI agents. He has been working on his own review skill in his skills repo (which has reached 109,000 stars), but considers it still a work in progress — marked as "in progress" and not something he's entirely happy with.
Rather than building from scratch, he's been looking for inspiration from other people's skills that he can borrow ideas from. This leads him to a particular skill from the Cursor team that caught his attention.
2 Discovering the Thermonuclear Code Quality Review
The skill in question comes from the Cursor team's official plugins repository — specifically the cursor-team-kit/skills directory. It's called the thermonuclear code quality review, and its stated purpose is:
- Unusually strict review — focused on implementation quality, maintainability, abstraction quality, and code base health
- Ambitious by design — it explicitly asks the reviewer agent to be very ambitious and look for "code judo moves" throughout the review
- Single file — the entire skill is one
SKILL.mdfile, making it easy to copy and experiment with
Matt notes the ambition aspect as particularly notable — most review skills are too conservative, but this one pushes the agent to think beyond the immediate diff.
3 Testing on Sandcastle
To evaluate the skill, Matt copies it to his local system and runs it against Sandcastle, his open-source software factory project. His prompt is deliberately loose:
He puts the agent in auto mode and lets it run while he reads through the skill's source code. This approach tests the skill against real production code changes he made the day before, giving him ground truth to evaluate the suggestions against.
4 Breaking Down the Non-Negotiable Standards
The skill begins with a baseline instruction: "Perform a deep code quality audit of the current branch's changes. Rethink how to structure and implement the changes to meaningfully improve code quality without impacting behavior." Matt highlights the key directives:
- Be ambitious — if there's a clear path to improvement involving restructuring, go for it. This goes beyond treating the diff as the bounds of the review
- Structural simplification — the skill repeatedly pushes for ambitious structural changes
- 1,000 line limit — "Do not let a PR push a file from under 1K lines to over 1K lines without a very strong reason." Matt finds this particularly interesting because he's reached the same conclusion independently
- No spaghetti growth — if a change adds weird if statements in random places, treat that as a design problem, not a stylistic nit
Why large files are bad for agents
Matt elaborates on the 1K line rule: large files are hard for agents to navigate because they need to ingest the entire file into their context window to find the useful part. A better structure is splitting into multiple files where the file name acts as a context pointer — telling the agent what's inside without having to open it. This is much more context-efficient. Matt personally splits files at 5K tokens, while this skill uses 1K lines as its rubric.
Abstraction over nesting
The skill instructs: "Prefer pushing the logic into a dedicated abstraction, helper, state machine, policy object, or separate module instead of tangling an existing path." Matt notes this is another way of telling the agent to be aggressive about abstracting nested conditionals into cleaner patterns, though he admits he sometimes agrees and sometimes doesn't.
5 Type & Boundary Cleanliness
Matt highlights a TypeScript-specific instruction he particularly likes: "Push hard on type and boundary cleanliness when they affect maintainability." The skill calls out:
- Unnecessary optionality — question optional params when they should be required. Matt calls this a chronic agent behavior: "Whenever an agent adds a prop onto a React component, it always adds it as optional. I don't know why. Even when it's always required."
unknownandany— question cast-heavy code when a clearer type boundary could exist- Existing helpers — prefer canonical utilities over bespoke one-offs. The skill tells the agent to look for places where the problem has already been solved in the codebase
Parallelism over sequential execution
The skill also includes a performance-oriented rule: "Treat unnecessary sequential orchestration and non-atomic updates as design smells when the cleaner structure is obvious. If independent work is serialized for no good reason, ask whether the flow should run in parallel instead."
Matt's reaction is mixed — he agrees with the concept (independent tasks should run in parallel for speed) but criticizes the wording: "Treat unnecessary sequential orchestration and non-atomic updates as design smells — that's just word salad to me." He says if this were his skill, he'd rewrite this section to be far more direct.
6 Code Judo & Primary Review Questions
The skill defines primary review questions the agent should ask for every meaningful change:
- "Is there a code judo move that would make this dramatically simpler?" — Matt loves this framing
- "Can this be reframed so that fewer concepts, branches, or helper layers are needed?" — also praised
- "Does this improve or worsen the local architecture?" — Matt is less impressed: "You've got to say exactly what good and bad looks like to an agent in order for 'improve or worsen' to mean anything"
Escalation triggers
The skill defines when to escalate findings to blocker-level:
- A complicated implementation where a cleaner reframing could delete whole categories of complexity
- Refactors that move code around but fail to reduce the number of concepts a reader must hold in their head
- Unnecessary casts,
any,unknown, or optional params
Matt's concern about prompt density
Matt expresses a key worry: "What sort of scares me about these big review-based prompts is that this is a huge ball of mud for the agent to read. There's a lot of instructions and it's hard to know what to prioritize." He notes significant repetition throughout the skill — the ambition message is stated in at least 4-5 different ways. He also finds the "Review tone" section ("Be direct, serious, and demanding about quality. Do not be rude.") an odd inclusion.
Suggested improvements
The skill instructs the agent to suggest bold actions: "Delete a whole layer of indirection rather than polishing it. Split a large file into smaller focused modules. Make type boundaries more explicit so the control flow gets simpler." Matt sees this as mostly duplication of earlier points.
7 Output Expectations & Approval Bar
The final section of the skill defines how the agent should structure its output:
- Priority ordering — float the important stuff to the top. Structural code quality regressions rank highest, while legibility and maintainability concerns are at the bottom
- Approval/rejection — the agent should approve or reject the PR based on defined conditions
What's missing
Matt identifies critical gaps in the skill:
- No mention of testing — the entire skill focuses on source code with zero attention to test quality or coverage
- No mention of seams — architectural seams that enable testability and modularity are ignored
- No feedback loop improvement — nothing about making future agent runs better through better code structure
8 Review Results — Blocker-Class Issues
With the review complete, Matt walks through the agent's findings on his last 5 PRs to main:
Blocker #1: Init service file over 1,000 lines ✅
The agent found that an init service file had grown past the 1K line threshold, mixing multiple responsibilities. It recommended splitting the file and proposed a concrete decomposition. Additionally, it suggested a generic makeRegistry function that would "delete 20 lines of duplicated boilerplate." Matt agrees: "Feels good. That's nice."
Blocker #2: Feature-specific conditionals scattered across layers ✅
The agent identified that if (issueTrackerName === 'custom') checks were scattered across three different layers. Its code judo suggestion: push the custom tracker variations into the type itself so it can be read later without special-case if statements. Matt confirms this is a legitimate improvement: "I happen to know this code quite well. Two out of two."
Blocker #3: Inconsistent contract template args ❌
The agent flagged that template args carried both shell commands and prose markers, suggesting a discriminated union to separate them. Matt disagrees: "I think that this comes from an inaccurate understanding of the whole system." He considers this a false positive — the kind of thing he'd dismiss in a real PR review with "this is fine, don't worry about it."
Score so far: 2 out of 3 — "not bad."
9 Strong Quality Issues & Final Score
Moving to the "strong code quality issues" tier:
Issue #4: Hard-coded Zod dependency path ✅
The agent spotted a weird code path where Zod was hard-coded as a dependency despite templates having a system for declaring their own dependencies. Matt confirms: "It's definitely pulled up something weird here." Score: 3 out of 4.
Issue #5: Swallowed errors in exec sync ✅
Found an execSync call wrapped in a try-catch that silently returns false on failure. The error is swallowed completely. Matt agrees this should be flagged. Score: 4 out of 5.
Issue #6: Half-finished file decomposition ✅
The agent noticed that a large file had been started to be decomposed into smaller files, but the work was only half-done. Matt confirms: "This again is a good one." Score: 5 out of 6.
Issue #7: Prompt duplication ❌
The agent flagged byte-identical content between two different prompts and suggested refactoring them into a shared preamble. Matt disagrees: "I think the prompts should just be independently changeable." Score: 5 out of 7.
The verdict
The agent's final approval assessment: "Under the skill's stated bar, a couple of the PRs should not have landed in their current shape. The behavior is correct in all three substantive PRs, but the code base is meaningfully messier than it was a week ago."
10 Lessons Learned & Improvements
Matt distills the experience into actionable insights:
The ambition tradeoff
High ambition produces more false positives, but those are easy to dismiss. The dangerous ones are the opportunities you never see — the improvements the agent never suggests because it wasn't pushed to look for them. A 5-out-of-7 hit rate with ambitious suggestions is far better than a 7-out-of-7 rate on trivial style nits.
What Matt would change
- Reduce duplication — the skill repeats its core messages (ambition, structural simplification) in 4-5 different ways. It could be significantly shorter and more DRY
- Add testing focus — the biggest gap is the complete absence of test-related review criteria. Think about the seams in the codebase
- Clearer language — rewrite "word salad" instructions like "unnecessary sequential orchestration" into direct, concrete guidance
- Integrate with his own "improved code base architecture" approach — focusing on testability seams and feedback loops for future agent runs
🎯 Key Takeaways
🔑 Key Takeaways
- Automated code review is high-impact — it's one of the most effective ways to maintain code quality when working with AI coding agents
- Ambition beats conservatism — pushing the reviewer agent to suggest structural changes produces more false positives, but catches improvements you'd otherwise miss entirely
- 5 out of 7 hit rate — the thermonuclear skill produced 5 genuinely useful suggestions out of 7 total across 5 PRs reviewed on the Sandcastle project
- 1,000 line file limit — enforcing maximum file sizes improves agent navigability by keeping context windows manageable and using file names as natural context pointers
- Type boundary cleanliness matters — questioning unnecessary optionality,
any/unknowntypes, and cast-heavy code catches a chronic agent behavior of making everything optional - Code judo framing works — asking "is there a move that makes this dramatically simpler?" gives agents a productive mindset for structural review
- The skill has too much repetition — the core messages about ambition and structural simplification are repeated 4-5 times and could be significantly condensed
- Testing is completely absent — the biggest gap in the skill is zero attention to test quality, coverage, seams, or feedback loops for future runs
- Word salad instructions harm clarity — vague phrases like "unnecessary sequential orchestration and non-atomic updates" should be replaced with direct, concrete guidance
- False positives are easy to dismiss — saying "this is fine" to a false positive costs seconds; missing a real structural improvement costs technical debt forever
🔗 Resources & Links
- Thermonuclear Code Quality Review SKILL.md — the full skill from Cursor's official plugins repository