Cursor Hardcore Code Review Skill Tested: Can It Block AI-Generated Bad Code?

AI writes code faster and faster, but the quality of its output varies wildly. Automated code review is widely seen as the most effective lever for improving the quality of Agent output, yet actually shipping a reusable review Skill is not easy. A review skill repository on GitHub has already racked up 109k stars but is still marked "under development" — a sign that this is not so simple. Well-known developer Matt Pocock (with a Chinese-dubbed version on Bilibili) recently ran a real-world test: he pulled Cursor's "hardcore-level code quality review" Skill to his local machine, ran it against his own real project, and saw what it could actually catch.

What This Skill Is Actually Asking For

The entire Skill is just a single skill.md file, but the wording inside is quite aggressive. It demands that the reviewer be "ambitious" and constantly look for opportunities for "code judo" — that is, simplifying implementations with minimal effort for maximal effect. The opening sets a clear tone: deeply audit the code quality of changes on the current branch, rethink how the changes should be implemented, genuinely raise quality without changing behavior, improve abstraction and modularization, and reduce spaghetti code.

The most notable point: it does not treat the diff as the scope of activity. Usually when you give an Agent a diff, it just circles around inside the diff; this prompt instead asks it to start from the changes and look for improvement opportunities across the entire codebase. The accompanying hard standards include: don't let a PR push a file from under 1000 lines to over 1000 lines (unless there's a strong reason), don't let existing code casually sprout spaghetti code, treat nested ifs and weird conditionals as design problems rather than minor style nits, and preferentially extract logic into dedicated abstractions or standalone modules.

Matt strongly resonates with the "1000 lines" rule. His own experience is to split files once they exceed 5000 tokens — large files are hard for Agents to handle because they have to stuff the whole file into the context window to find the genuinely useful parts; once split into multiple files, the file names themselves become context pointers, which is far more efficient.

Code Judo is the core methodology this review Skill repeatedly emphasizes. It is not a standard term in programming but a metaphorical expression. It means: solve problems not by piling on code or patching, but by finding the path of least resistance and dissolving complexity with minimal effort for maximal effect. Concretely, this shows up as identifying repeated patterns and extracting generic functions, collecting scattered special-case checks into the type system, and expressing equivalent logic with fewer abstraction layers. Its opposite is "spaghetti code" — implementations whose control flow tangles like noodles and whose execution paths are hard to trace. Code judo requires the reviewer to be dissatisfied with "it runs, that's good enough" and instead ask, "could this logic have been shorter and more direct in the first place?"

The context window mentioned in the article is the key to understanding "why large files are hard to handle." An LLM can only process a limited number of tokens per inference, and that upper limit is the context window. When an Agent needs to modify a file of over a thousand lines, it must read the entire file into the window to locate the relevant fragments, which eats into the budget that could be used for reasoning and other files, and makes it easy to lose details in long text. After splitting a large file into multiple small files, the Agent only needs to judge which one to read by file name; the file name itself becomes a low-cost retrieval clue. This is precisely the underlying reason Matt advocates splitting files once they exceed 5000 tokens.

Where Matt Nodded and Where He Frowned

Types and boundaries — he quite likes this one. The Skill requires strict gatekeeping against superfluous optional parameters and sloppy unknown/any casts. Matt says Agents always love to make props optional when adding them to React components, even when they're always required, just for the sake of "backward compatibility," and this drives him crazy every time.

Output ordering — he also approves: rank results by importance, put structural quality regressions at the top and readability/maintainability at the bottom, and require a clear approve-or-reject conclusion.

But the problems are equally obvious: too much repetition. Concepts like "be ambitious," "code judo," "split large files," and "type boundaries" appear over and over in the text, and Matt worries that with so many scattered instructions the Agent will struggle to judge priorities — "to an Agent it's just a big pile of mud." In addition, the Skill says nothing about testing, nothing about CI, and nothing about how to establish an improvement feedback loop — and that is precisely the key to a codebase's long-term health.

Discriminated union is a type-modeling technique in TypeScript: add a literal field to each member of a union type (such as kind: 'issue' | 'custom'), and the compiler can then narrow types accordingly and exhaustively check all branches. The review Skill suggests using it to replace sloppy unknown/any casts; the essence is moving implicit runtime conventions into the type system so that illegal states cannot be constructed. The accompanying "optional-soup" problem is the opposite: marking props that should be required as optional means the compiler no longer checks for callers, and errors are deferred until runtime.

Cutting Into a Real Project: Seven Findings, Five Solid

Matt tested the Skill on Sandcastle, a project he is actively developing, having it review the five most recent PRs merged into main. The results were as follows:

• The init service ballooned past 1000 lines, mixing multiple responsibilities; the Skill gave a decent splitting plan and also wanted to add a small generic function to delete about 20 lines of repeated boilerplate at once.
• Special-case checks in the issue tracker were scattered across three layers; it suggested using code judo to fold the differences of custom trackers into the type system. Matt knows this code well, and his assessment was "both points are right."
• Inconsistent template args types; it suggested changing to a discriminated union or separate fields. Matt considers this a false positive — the other party didn't fully understand the system, but such false positives are unavoidable for any review prompt.
• Swallowed errors: execSync wrapped in a call that swallows errors, returning false outright on failure. This is exactly what he wants reviewers to keep an eye on.
• A large file only half split, and identical changes duplicated verbatim in two prompts — the latter Matt doesn't fully agree with; he thinks prompts should be changed separately.

Five of the seven were solid. There was also a thought-provoking conclusion: by this Skill's approval standards, three substantive PRs recently should not have been merged — behavior was correct, but the codebase was noticeably messier than a week earlier.

False Positives Aren't the Problem; False Negatives Are

Matt's core judgment: making the review "super ambitious" and raising more structural proposals inevitably increases false positives, but false positives are easy to handle; what's truly dangerous is false negatives — the improvement opportunities you never see, you'll never know you missed.

His improvement directions are also concrete: trim repetitive content and make the instructions more DRY; add attention to testing and CI; and borrow from his own architecture Skill's emphasis on codebase sims (consistency of similar patterns). The overall conclusion is that this Skill is worth pulling down and trying.

For teams wanting to add a quality line of defense to their Agents, the value of this real-world test is this: a good review Skill is not about piling up more rules, but about giving the Agent a clear language of "good and bad" and enough room to operate — ambition should be big, but instructions should be lean.

False positive and false negative are terms borrowed from the field of detection. In the context of code review, a false positive is a suggestion raised by the reviewer that does not actually hold or is not worth changing; a false negative is a real quality problem that goes unmentioned. The two trade off against each other: the more aggressive the review standards and the more structural refactoring is encouraged, the higher the false positive rate. Matt's judgment rests on cost asymmetry — a false positive only costs a human a few seconds to dismiss, a negligible price; a false negative means the problem lurks forever, and the team doesn't even know what improvement opportunities it lost. So he leans toward setting the threshold to "better to over-report," then reducing the noise of false positives by trimming instructions and adding testing and CI concerns.

One-line Summary

Cursor hardcore code review Skill tested: five of seven findings solid; false positives tolerable, false negatives the real danger.

Paragraph Summary

The article documents developer Matt Pocock's real-world test of Cursor's "hardcore-level code quality review" Skill. The Skill is just one skill.md, yet it asks the reviewer to step outside the diff and hunt across the entire codebase for "code judo"-style simplification opportunities, and sets hard standards on file line counts, type boundaries, and nested conditionals. Matt tested it on the five most recent PRs of the Sandcastle project; five of seven findings were solid, covering file bloat, scattered special-case checks across three layers, and swallowed errors, while one was a false positive. He points out that the Skill's main weaknesses are excessive repetition of instructions, which makes it hard for the Agent to judge priorities, and complete neglect of testing, CI, and improvement feedback loops. The core conclusion: false positives are easy to handle, false negatives are what's dangerous; a good review Skill should be big on ambition and lean on instructions, not a pile of rules.