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

> Source: <https://dev.to/freema/most-code-review-catches-bugs-i-shipped-one-that-argues-with-the-design-1h0h>
> Published: 2026-07-14 18:00:00+00:00

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](https://github.com/freema/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:

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.

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.

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 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.

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](https://github.com/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.

```
/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.*