Can Cursor's HARDCORE Review Skill Stop The Slop?

1. Why automated code review matters (0:00)

Matt opens with the thesisautomated code review is "one of the most impactful ways that you can improve the code quality coming out of your agent." He has his own review skill in his skills repo (109,000 stars) but marks it "in progress" because he is not happy with it, so he hunts other people's skills for ideas to steal.

Source statementhis review skill lives here and is still "in progress." The repo is mattpocock/skills, "Skills for Real Engineers." 00:22

2. The "thermonuclear code quality review" skill (0:39)

The skill that caught his eye is from the Cursor team: thermo-nuclear-code-quality-review. It is a single SKILL.md file. Its frontmatter description: "Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti." What Matt finds notable is how ambitious it asks the reviewer to be, explicitly hunting for "code judo" moves.

Visual evidencefrontmatter shows disable-model-invocation: true (the skill only fires when a human asks for it). The body says "push the reviewer to be ambitious about code structure... Actively search for 'code judo' moves." 00:52

3. Testing it on Sandcastle (1:12)

Matt copies the skill locally and runs it against Sandcastle, his open-source "software factory" (a TypeScript toolkit that orchestrates AI coding agents inside isolated sandbox environments). The 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.

Visual evidenceSandcastle is "a TypeScript toolkit that orchestrates AI coding agents inside isolated sandbox environments." Running on Claude Code (Opus, 1M context), "auto mode on." 01:20

4. Breaking down the skill's instructions (1:36)

While the agent runs, Matt reads the skill.

The core prompt baseline"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... Be extremely thorough and rigorous. Measure twice, cut once." Matt's insight: most review skills fail because the agent treats the diff as its bounds. This prompt pushes it to look across the whole codebase, starting from the current branch's changes.

Source statementthe baseline prompt plus rule 0, "Be ambitious about structural simplification." 02:25

The non-negotiable standards that follow:

• Rule 1, the file-size rule: "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 independently: large files are hard for agents to navigate because they must ingest the whole file into context to find the useful part. Better to split into multiple files and let the filename act as a context pointer. (His own rubric is 5,000 tokens rather than 1,000 lines.)
• Rule 2, anti-spaghetti: if a change adds weird if statements in random places, treat it as a design problem, not a stylistic nit. Prefer pushing logic into a dedicated abstraction, helper, state machine, policy object, or separate module.

Source statementrule 1 (1k lines) and rule 2 (no random spaghetti growth). 02:48

More standards, plus the review questions:

• Prefer direct, boring, maintainable code over hacky, magical code (Matt notes this echoes the simplify skill in Claude Code).
• Push hard on type and boundary cleanliness: "Question unnecessary optionality, unknown, any, or cast-heavy code when a clearer type boundary could exist." Matt's pet peeve: agents add every new React prop as optional even when it is always required.
• Keep logic in the canonical layer and reuse existing helpers over bespoke one-offs.
• Treat unnecessary sequential orchestration and non-atomic updates as design smells (run independent work in parallel), but do not over-index on micro-optimizations. Matt calls the wording here "word salad."
• Primary Review Questions for every meaningful 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 the first two; dislikes "Does this improve or worsen the local architecture?" because "improve or worsen" means nothing to an agent unless you define good and bad.

Source statementrules 5-7 and the Primary Review Questions. 05:45

The output expectationsprioritize findings in a fixed order (structural regressions at the top, legibility at the bottom) and "do not flood the review with low-value nits." Then an approval bar: do not approve merely because behavior seems correct. Matt's main complaint about big review prompts: they are "a huge ball of mud" and it is hard for the agent to know what to prioritize.

Source statementthe 7-item priority order and the approval conditions. 07:38

5. Reviewing the feedback results (8:39)

The agent reviewed the last five PRs to main (#750 zod auto-install, #743 loop prompt hint, #741 custom issue tracker, #740 a rename, #737 an ADR doc) and produced findings in tiers.

Blocker-class findings. InitService.ts is now 1,094 lines, pushed there across these PRs with no decomposition; it mixes four registries, six inline Dockerfile constants, package-manager detection, and more. Suggested split into per-registry modules. It also proposed a generic makeRegistry function to delete ~20 lines of duplicated boilerplate. Matt: two out of two, both good.

Visual evidence"InitService.ts is now 1094 lines, pushed there across these PRs without any decomposition." 08:48

On #741, a feature-specific special case. The custom issue-tracker logic is scattered across three layers via if issueTracker.name === 'custom'. The skill suggests pushing the variation into the type itself (a nextStepsOverride closure) so the CLI never needs to know "custom" exists. Then it flags templateArgs carrying both real shell commands and prose markers, and proposes widening the type to a Command | TodoMarker discriminated union. Matt calls the second one a false positive from an inaccurate understanding of the system, "which is okay."

Visual evidenceLIST_TASKS_COMMAND is real shell; VIEW_TASK_COMMAND and CLOSE_TASK_COMMAND are prose markers, so the field name lies about being runnable. 09:20

On #750, strong code-quality issues. A generic dependencies: readonly string[] model that is used for a single purpose ("zod") and hardcoded in three places, "worst of both worlds." Then execSync inside Effect.sync with swallowed errors. Then a large-file decomposition that was only half finished (InitService.test.ts still 2,337 lines).

Visual evidencegetTemplateDependencies(...).includes("zod") special-cased in three places; suggested either an honest boolean (requiresZod: true) or a real generic loop. 10:00

On #743, prompt duplication. The diff for two prompt files is byte-identical; the skill wants them factored into a shared _issue-list-preamble.md partial. Matt disagrees: the prompts should stay independently changeable. Then a list of smaller items. Running score by the end: about five of seven findings genuinely useful.

Visual evidencetwo prompt files are "byte-identical" for the issue-listing section; skill wants a shared partial. Matt would keep them independent. 11:20

The verdict. "Under the skill's stated bar, #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 2m 35s."

Visual evidencethe agent rejects two PRs against the skill's own bar despite correct behavior. 11:52

6. Lessons learned and next steps (12:05)

• Making the review super ambitious produces more false positives, but those are easy to say no to. The dangerous cases are the improvements you never see, the ones a timid reviewer misses silently.
• Matt would clean the skill up to be less duplicative (more DRY) and, crucially, get it to focus on tests and seams, none of which the skill mentions. In his view that is the entire point of a healthy, changeable codebase.
• Verdict: worth pulling down and experimenting with.

Tools and resources

Claims to verify

• "109,000 stars" on mattpocock/skills: stated on-screen 2026-05-28; star counts drift, verify before citing.
• "Opus 4.7 (1M context)" shown in the Claude Code banner is Matt's local setup at record time, not a general claim.
• The skill's exact wording may have changed upstream since capture; treat quoted lines as of 2026-05-28.

Glossary

• Automated code review: having an AI agent review code changes against a quality rubric, rather than (or before) a human reviewer.
• Skill (agent skill): a reusable instruction file (here a single SKILL.md) you hand an AI coding agent to make it perform a specific task consistently.
• SKILL.md: the markdown file that defines a skill, with YAML frontmatter (name, description, flags) and an instruction body.
• disable-model-invocation: a skill frontmatter flag; when true the model cannot fire the skill on its own, so it only runs when a human explicitly asks.
• Code judo: the skill's term for a dramatic restructuring that preserves behavior while making the implementation much simpler, smaller, and more elegant, rather than polishing code in place.
• Diff bounds: the tendency of an agent handed a diff to treat that diff as the only region it is allowed to change, missing better fixes elsewhere.
• Spaghetti code: tangled control flow with scattered conditionals and no clear structure, hard to follow or change.
• Abstraction: a named construct (function, module, type) that hides detail behind a simpler interface.
• Helper: a small reusable function that factors out repeated logic.
• State machine: a model where code is in one of a fixed set of states with defined transitions, used to replace tangled boolean flags.
• Policy object: an object that encapsulates a decision or rule, so the rule lives in one place instead of scattered conditionals.
• Optionality: whether a value or field is allowed to be absent; "unnecessary optionality" is marking things optional that are actually always required.
• any (TypeScript): a type that opts out of type checking entirely; a common smell because it hides real type errors.
• unknown (TypeScript): a safer top type than any; you must narrow it before use, so it forces explicit handling.
• Cast: forcing the compiler to treat a value as a different type (as), which can paper over an unclear type boundary.
• Type boundary: the point where data of an uncertain shape becomes a well-typed value; making it explicit catches errors early.
• Discriminated union: a union of types that each carry a distinct tag field, letting code branch safely on the tag (e.g. Command | TodoMarker).
• Canonical layer / canonical utilities: the agreed single place in a codebase where a kind of logic or a shared helper lives, versus bespoke one-off copies.
• Bespoke one-off: a custom implementation of something the codebase already solves elsewhere; a duplication smell.
• Sequential orchestration: running independent steps one after another when they could run in parallel; flagged as a design smell when the parallel structure is obvious.
• Non-atomic update: a multi-step change that can leave state half-applied if it fails partway; the fix is a more atomic structure.
• Micro-optimization: a tiny performance tweak with negligible impact; the skill warns against over-indexing on these.
• Ball of mud: an architecture (or here, a prompt) with so much tangled content that it is hard to know what matters.
• Layer of indirection: an intermediate wrapper between caller and implementation; the skill prefers deleting a useless one over polishing it.
• DRY: "don't repeat yourself," the principle Matt says the skill itself violates by being so repetitive.
• Blast radius: how much of a system a change can affect; agents often over-use optionality to keep the blast radius small.
• Context window: the amount of text an agent can hold at once; large files waste it because the whole file must be ingested to find the useful part.
• Auto mode: an agent setting where it proceeds through steps without pausing for approval at each one.
• PR (pull request): a proposed set of changes submitted for review and merge.
• Sandcastle: Matt Pocock's open-source TypeScript toolkit that orchestrates AI coding agents inside isolated sandbox environments.
• Zod: a TypeScript schema-validation library; the reviewed code special-cased installing it.
• Effect (Effect.sync): a TypeScript library for typed effects; execSync inside Effect.sync with swallowed errors was flagged.
• Seam: a place in a codebase designed so behavior can be changed or substituted (often for testing) without editing surrounding code; Matt faults the skill for ignoring seams.
• Feedback loop: the mechanisms (tests, types, tooling) that make future changes safer and faster; Matt considers improving these the real goal of code health.
• False positive: a finding that looks like a problem but is not; the skill produces more of these because it is ambitious, but they are cheap to dismiss.
• Approval bar: the explicit conditions under which the reviewer may approve a PR, rather than approving just because behavior is correct.