Most code review catches bugs. I shipped one that argues with the design.

Tomas Grasl — Tue, 14 Jul 2026 18:00:00 +0000

The cheapest bug to catch is the one a reviewer circles on line 40. The expensive one never shows up as a bad line it ships as the wrong approach, clean and green. Your retry loop is correct and also retrying in the wrong layer. Your cache has no bug and invalidates on the wrong key. A normal review human or AI slides right past those, because it's anchored on "is this line right," not "is this the right thing to build."

This week I shipped v0.4.0 of cursor-plugin-cc, and the headline is a review command whose entire job is that second question.

Quick context if you haven't seen the plugin: it's a Claude Code plugin that keeps one loop running Claude plans, Cursor's Composer writes the code, Claude reviews the diff without leaving the Claude Code TUI. Two tools, each doing the half it's best at. v0.4.0 sharpens the review half.

`/cursor:adversarial-review`

A read-only review that questions the chosen implementation and design instead of only hunting implementation defects. You point it at a diff (working tree by default, --base <ref> for a branch, --scope, --model same target selection as the normal /cursor:review) and it pressure-tests:

the assumptions the change depends on,
the tradeoffs you made, spoken or not,
the failure modes under real load, concurrency, and edge cases,
and the one that matters most — whether a simpler or safer approach would have done the job.

It's steerable: any trailing text is a focus. "is the retry/backoff design sound under load?" aims the whole challenge at exactly the thing you're nervous about.

/cursor:adversarial-review
/cursor:adversarial-review --base main
/cursor:adversarial-review "question the retry/backoff design under load"
/cursor:adversarial-review --background --model opus look for race conditions and question the approach

Under the hood it's /cursor:review --adversarial, so it shows up as a normal job in /cursor:status, /cursor:result and /cursor:cancel. What used to be a --adversarial flag most people never found is now a first-class, discoverable command — and it's user-invoked only (disable-model-invocation: true), because a design challenge is something you reach for on purpose, not something an agent should fire off on its own.

Why split it out instead of just telling /cursor:review to "try harder"? Because a stricter bug pass and a design challenge are different jobs, and conflating them gets you neither. Naming the second one makes you actually run it — right before you ship a change you're not fully sure about, which is exactly when nobody bothers.

The part I'm quietly proud of: it can't touch your code

Both review commands are read-only by construction, not by good intentions. The run happens, then a post-flight check fails the job if the working tree changed. So a review can never quietly turn into an edit — even though the same plugin runs Composer elsewhere with auto-approve on. You can hand a fast model your diff and know the worst it can do is talk.

That guarantee is the whole reason I trust an adversarial pass. A reviewer that might also "helpfully" refactor while it argues is a reviewer you have to babysit.

Estimate first, then ask

Small ergonomics fix that removes a daily papercut. If you don't pass --wait or --background, the command now sizes the diff first — git status, git diff --shortstat, counting untracked files — and asks you once whether to wait or run it in the background, recommending background for anything beyond a tiny 1–2 file change. A multi-file review takes a while; you shouldn't have to guess up front whether it's going to block your terminal for the next two minutes.

The real lesson: I moved the know-how into a skill

The most interesting change isn't a command. For a while, the guidance for how to turn a task into a tight Cursor prompt ground it in the target repo's conventions, the five required sections (Goal / Repo context / Acceptance criteria / Files to touch / How to verify) plus a guardrails block, chunk anything over ~5 steps or ~10 files or 2 architectural layers, pick the smallest model that fits, resume vs. fresh — lived inline inside the cursor-runner subagent's prompt.

In v0.4.0 that moved into a composer-prompting skill. The subagent now references it with a single skills: line and shrank down to its operational spine: ground → invoke /cursor:delegate → return Cursor's output verbatim.

The lesson generalises past this plugin, and it's the same thread running through everything I've been writing about MCP and agents: an agent's prompt is context you pay for on every single run. Reusable know-how doesn't belong restated inside each agent that needs it — it belongs in one referenced skill that loads when it's actually relevant. The agent gets leaner, the knowledge gets a single home instead of three drifting copies, and the thing you maintain shrinks. Same instinct as splitting tools from resources on an MCP server: put weight where it earns its place, and nowhere else.

The boring guarantees

Still zero runtime dependencies — plain ESM, Node stdlib, no build step, no dist/. Still MIT. CI runs the tests and lint across Node 18.18 / 20 / 22 on Linux and macOS on every PR. And it's openly adapted from openai/codex-plugin-cc — the Codex/GPT original that pulls the same trick on OpenAI's side — ported to the Cursor CLI. Credit where it's due.

Try it

/plugin marketplace add freema/cursor-plugin-cc
/plugin install cursor@tomas-cursor
/reload-plugins
/cursor:setup

👉 github.com/freema/cursor-plugin-cc — v0.4.0, MIT.

When did a code review last change your **approach* instead of your lines? That's the review I actually want — and the one almost nobody runs. Curious whether you've found a way to make it a habit.*

DEV Community: Tomas Grasl