The Best Code Review Skill Is the One You Never Have to Run

The fastest-growing search in AI coding right now is people looking for a code review skill to install. The best one is the one you never have to run.

That sounds like a dodge, but it is the whole argument. A code review skill is a file you drop into Claude Code or Codex that tells the agent how to critique a diff: check correctness, flag security anti-patterns, look at test coverage, rate readability. They are genuinely useful, and the good ones are getting shared fast. But every one of them reviews the code against a general standard of what good code looks like. None of them can tell you the thing you actually need to know, which is whether the code does what you meant it to do. That question was never in the skill, because your intent was never in the skill.

#The review skill gold rush is real, and it is mostly good

Look at what ranks when you search "code review skills" today and you see the shift in real time. The top result is obra's receiving-code-review skill, whose core principle is blunt: verify before implementing, ask before assuming, technical correctness over emotional performance. Right below it, Addy Osmani's agent-skills repo publishes a five-axis review, correctness, readability, architecture, security, performance, as a reusable rubric any agent can run. Anthropic's own Code Review docs now analyze your pull requests and post findings as inline comments. There is even a two-layer review skill in the Anthropic skills discussions with project-aware checklists.

This is a good development. A shared, structured rubric beats an ad hoc glance every time, and handing your agent a consistent review procedure is strictly better than hoping it critiques carefully on its own. The community answer that keeps surfacing in the r/ClaudeCode threads gets the nuance right:

The best code review skill is the one you build for your own repo. Generic ones catch style and obvious bugs but miss the stuff that actually matters.

That instinct is correct, and it points at exactly the gap. The reason a generic skill misses the stuff that matters is not that it was written badly. It is that the stuff that matters lives outside the code entirely.

#What a review skill can see, and what it can't

A code review skill reads a diff and evaluates it against patterns of good engineering. It can tell you this function is doing too much, this query is unindexed, this endpoint has no auth guard, this branch is untested. That is real value, and it is the kind of value that scales, because good-engineering patterns are general. They apply to any codebase.

Here is what the same skill cannot do. It cannot tell you that the checkout flow was supposed to apply the discount before tax, not after. It cannot tell you that "notify the user" was supposed to mean an email and an in-app toast, not just the toast. It cannot tell you that the report was supposed to exclude cancelled orders. Those are not code-quality facts. They are product facts, and they are not in the diff. The code can be clean, well-tested, correctly typed, secure, and completely wrong, and a review skill checking the code against a standard of good code will pass it, because by every standard it can see, it is fine.

This is the distinction that gets lost in the rush to install a rubric. There are two questions a review answers, and they are not the same question:

Is this built well? A review skill can answer this by reading the code.

Is this the right thing, built correctly? Only your intent can answer this, and your intent is not in the code.

The first question is about the how. The second is about the what. Review skills are getting very good at the first and cannot touch the second, and the second is the one that ships broken features while every automated check stays green.

#Where the durable standard actually lives

If the review skill can only check the code against generic quality, then the standard for "did this do the right thing" has to come from somewhere else. It comes from what you decided the feature should do, written down before the agent built it. That written-down decision has a name in every mature engineering process: acceptance criteria. They are the per-feature definition of what "correct" means for this specific change, and they are the only thing that lets any reviewer, human or agent, check the build against your actual intent instead of against a general notion of tidy code.

Consider the difference concretely.

Generic review skill: "This function looks correct, is well-typed, and has test coverage. Approved."

Review against a standard: "Criterion 3 says a cancelled order must not appear in the revenue total. The test only covers active orders. This is not done until there is a test asserting a cancelled order is excluded, and it passes."

The second review is not smarter about code. It is anchored to a target the first review never had. And notice what it produces: not a subjective opinion you have to adjudicate, but a checkable claim with a pass-or-fail answer. That is the review you do not have to run by eye, because the criterion either has evidence behind it or it does not.

#Why this matters more now, not less

The reflex is to think that as agents get better at reviewing code, this problem shrinks. It grows. The better the review skill gets at catching style issues and security holes, the more confident the green checkmark looks, and the easier it becomes to mistake "passed the review skill" for "does what I wanted." A rubric that catches nine kinds of code smell and cannot see intent is more dangerous than no rubric, because it manufactures a feeling of thoroughness around the one gap it structurally cannot close.

There is a real trade-off here worth naming. Writing acceptance criteria before the build is work, and it is work you do when there is nothing to look at yet, which is exactly when it feels least urgent. Installing a review skill takes thirty seconds and feels productive immediately. The review skill is the easy purchase; the standard is the thing that actually protects you, and it costs you upfront attention instead of a download. Most people buy the easy thing. That is precisely why the durable advantage sits with the builders who do the harder one.

If you are shipping features with Claude Code, Cursor, or Codex right now, the practical implication is direct. Keep the review skill, it is a fine second line of defense for catching the code-quality issues a spec would not mention. But stop treating it as the standard. The standard is the set of acceptance criteria you wrote before the agent started, and the review that matters is the one that checks the diff against those, not against a general idea of good code.

#The review you don't have to run

This is the exact seam BrainGrid is built to close, and it sits one step before any review skill runs. You describe the feature in plain language, and the Planning Agent turns it into a requirement with explicit, testable acceptance criteria, the questions you did not think to ask, the edge cases you did not name, pinned down as the definition of correct for this change. Those criteria are not a document you file away. They become the standard the build is checked against.

Then the loop closes on them. Whether the Builder Agent works in BrainGrid Cloud or you hand the plan to your own agent in your GitHub repo over MCP, the feature is not done until every criterion is verified with evidence, not "the code looks good," but "criterion 3 has a passing test that proves a cancelled order is excluded." That is the review nobody has to run by eye, because the standard was set before the build and the evidence is checked against it. As we argued in the verification gap, code review tells you the code is well-written; verification tells you it does what you intended. A review skill is firmly on the first side of that line.

Strip away the skills and the agents and the argument is older than any of them. Reviewing code against a general standard of quality has always been necessary and never sufficient, because a reviewer who does not know what the feature was supposed to do can only tell you it was built tidily, not that it was built right. What changed is that the reviewer is now often an agent running a rubric, and the intent it is missing is now often nowhere written down at all. Write the standard first, and the best code review skill becomes the one you set up front and never have to run in a panic later.

#FAQ

#What is a code review skill?

A code review skill is a reusable instruction file you install into an AI coding agent like Claude Code or Codex that tells it how to critique a code change. It typically defines a rubric, common examples include correctness, readability, architecture, security, and performance, so the agent reviews a diff systematically and consistently instead of critiquing ad hoc. Popular ones are published in repos like Addy Osmani's agent-skills and obra's superpowers. They are useful for catching code-quality issues, but they evaluate the code against a general standard of good engineering, not against what your specific feature was supposed to do.

#What is the best code review skill?

The most useful installable skills give the agent a clear, consistent rubric, Addy Osmani's five-axis review (correctness, readability, architecture, security, performance) is a well-regarded example, and Anthropic's built-in Code Review posts findings directly on your pull requests. But the best review, the one that catches shipped-but-wrong features, is not a skill you run after the build. It is the acceptance criteria you write before it: the per-feature definition of what correct means for this change. A generic skill checks whether the code is good; your criteria check whether it does what you intended, which is the failure a rubric structurally cannot see.

#How do I improve my code review skills?

Two moves compound. First, learn to read a diff for the general engineering issues a good rubric covers: correctness, edge cases, security, test coverage, and unnecessary complexity. A shared skill or checklist accelerates this and keeps you consistent. Second, and more important as agents write more of the code, get in the habit of defining what "done" means before the work starts, as specific, testable acceptance criteria, and reviewing every change against those rather than against a vague sense of quality. The reviewers who add the most value now are the ones checking intent, not just style.

#Can AI do code review?

Yes, and it is increasingly good at the part that generalizes: spotting anti-patterns, missing tests, security holes, and readability problems by comparing a diff to patterns of good engineering. What AI code review cannot do on its own is judge whether the change matches your intent, because your intent is not in the code. It will happily approve a clean, well-tested implementation of the wrong behavior. To close that gap you have to give the review a standard to check against, acceptance criteria written before the build, so the agent verifies the diff against what the feature was supposed to do, not just against generic quality.

#Is code review still necessary with AI agents?

More than ever, but the useful form of it changes. Line-by-line style review is increasingly handled by review skills the agent runs itself. The review only humans and a well-specified standard can do, confirming the change does what you actually meant, becomes the high-value work. As agents produce more code faster, the bottleneck moves from writing to verifying, and the way to keep that verification fast instead of overwhelming is to define acceptance criteria up front so most of the review is checking evidence against a standard rather than reading everything by eye.

BrainGrid is the plan-first app-building platform that turns your idea into a requirement with acceptance criteria, then verifies every change against them, so the review that matters is set before the build instead of run after it. Try it at braingrid.ai.