| name | review |
| license | MIT |
| description | Use when you want an independent review pass before merging or between plan tasks - dispatch a fresh reviewer with crafted context (not your session history) to catch what you cannot see in your own work. The second set of eyes that pass asks for and that hands off to sendback. Triggers on "get this reviewed", "request a review", "second opinion", after finishing a feature or task, before merge. |
review
After an hour at the pass you cannot taste your own seasoning. The chef sends a plate to a cook who did not make it, because the person who built the dish has gone nose-blind to it. This skill is that second palate for code: dispatching a fresh reviewer that sees the work product, not the hour of reasoning that produced it. It is the independent pass that pass calls for and the producer of the feedback that sendback acts on.
Core principle: the reviewer gets the work and the requirements, never your session history. A reviewer fed your reasoning reviews your reasoning; a reviewer fed the diff reviews the code. Crafted context keeps it honest and keeps your own context free for the work.
When to request a review
- After each task in a plan or stations fan-out, before the next one compounds on it.
- After a major feature, before merge to a shared branch.
- On any change to a repo you do not own.
- Optionally when stuck, for a fresh angle.
A one-line, obviously-safe change (a dependency bump, a typo) does not need this; the pass self-review covers it.
How to run it
1. Pin the range.
BASE_SHA=$(git rev-parse HEAD~1)
HEAD_SHA=$(git rev-parse HEAD)
2. Dispatch a reviewer subagent with a complete, self-contained ticket. It inherits nothing, so the prompt is everything it knows:
You are reviewing a focused code change. Review only the diff between {BASE_SHA} and {HEAD_SHA}.
What it is meant to do: {DESCRIPTION}
Requirements / acceptance criteria: {PLAN_OR_REQUIREMENTS}
Inspect: git diff {BASE_SHA}..{HEAD_SHA}
Check, in order:
- Correctness: does it do what the requirements say? Edge cases, error paths, off-by-ones.
- Real fix vs bandaid: does it address the root cause, or mask a symptom (silenced error, widened timeout, catch-and-ignore)?
- Tests: is there a test that fails without the change and passes with it? A regression test for a bugfix?
- Scope: is this one concern, or are unrelated changes bundled in?
- Leaks: secrets, internal hostnames, private IPs, AI-authorship trailers in the diff or messages.
Return findings bucketed Critical / Important / Minor, each with file:line and a concrete fix. End with a one-line verdict: ready to merge, or what blocks it. Do not edit anything; report only.
Fill every placeholder. Dispatch a general-purpose reviewer (or a dedicated code-review skill/agent if the harness has one).
3. Act on what comes back through sendback: verify each claim before implementing it, fix Critical and Important before proceeding, note Minor, and push back with reasoning (and the test that proves it) when the reviewer is wrong. Performative agreement helps no one.
Common mistakes
- Handing the reviewer your conversation instead of the diff and the requirements, so it grades your thinking, not the code.
- Skipping review because "it's simple," on a change that touches behavior.
- Treating the review as the final gate. Review feeds pass; the change is still not filed until the pass clears and the user approves the PR body.
- Implementing every suggestion verbatim, including the wrong ones. Run it through sendback, do not rubber-stamp.
- One reviewer per file on a single coherent change, fragmenting the picture. One change, one review with the whole diff.
