Code Review Starts Before You Open the PR

For a long time I thought the point of requesting code review was to get my work looked at.

That's technically true. But it's not the useful framing.

The useful framing is: a code review request is a context transfer. You have a precise mental model of what you built and why. The reviewer has none of it. The quality of the review depends almost entirely on how well you close that gap.

What Most Review Requests Actually Are

The default pattern is something like: you finish a piece of work, push it to a branch, open a PR with a title like "Add verification function," and ping someone.

They look at a diff. They see changes. They comment on things that catch their eye.

This isn't useless. But it's also not what a good review looks like. A good review asks: does this implementation actually satisfy the requirements? Are there edge cases the author didn't anticipate? Is the approach sound given the constraints of this specific codebase?

Those questions require knowing what the requirements were. They require knowing what constraints exist. A reviewer working from a diff alone has to infer all of that, which means they'll often focus on surface-level things — style, variable names, obvious errors — rather than the deeper structural questions.

The Precision Dispatch Model

The requesting-code-review skill from obra/superpowers treats review requests differently. It dispatches a code-reviewer subagent with precisely crafted context: what was implemented, what the requirements or plan specified, the exact commit range to evaluate, and a brief description to orient the reviewer.

The key design decision is that the reviewer gets this crafted context — not your session history. Not the five approaches you tried before landing on this one. Not the internal debate you had about the architecture. Just the work product, evaluated against the stated requirements.

This distinction matters for two reasons.

First, a reviewer drowning in context about how you got here will often comment on your journey rather than your destination. The review becomes a conversation about your process instead of an evaluation of your output.

Second, preserving your own context for continued work is a real engineering constraint. If review requires re-explaining everything you know about the problem, the cost of requesting review frequently gets too high and developers start batching it — reviewing at the end instead of throughout. The skill's model is that review should happen after each significant task, not just before merge.

Review Early, Review Often

The skill makes review cadence explicit. In the context of longer development workflows — subagent-driven development or executing plans — review is mandatory after each task. Not after all the tasks. After each one.

The reasoning is that issues compound. A structural problem in Task 2 that doesn't get caught until you're reviewing the full feature at Task 8 has ramifications in Tasks 3 through 7 that now also need to change. Catching it at Task 2 is cheap. Catching it later isn't.

This is the kind of advice most developers have heard before. What makes the skill concrete is that it specifies exactly how to request review so the cost stays low enough that you'll actually do it frequently.

Get the base and head commit SHAs. Fill the template with what you built and what it was supposed to do. Dispatch the reviewer. Act on what comes back before moving to the next task.

That's the whole loop. Simple enough to run after every meaningful unit of work.

The Feedback Response Protocol

The skill is paired with receiving-code-review, which covers what to do with the feedback that comes back. But the requesting side has its own guidance on this: Critical issues get fixed immediately, Important issues get fixed before proceeding, Minor issues get noted for later.

And if the reviewer is wrong — push back. With technical reasoning. The skill explicitly notes that pushing back with evidence is appropriate when the reviewer lacks full context or is technically incorrect for this codebase.

This reframes code review from a judgment you receive to a technical conversation you participate in. The reviewer brings a fresh perspective and catches things you're too close to see. You bring the full context of the constraints, the codebase history, and the requirements. Neither side has complete information. The review is where those partial pictures get reconciled.

I now think of a review request not as submitting work for approval, but as asking a specific question: given these requirements and this implementation, what am I missing?

That question is much more useful than "please look at my diff."

---

Part of the Superpowers series — 14 specialist skills from obra/superpowers.