| name | to-review |
| description | Concern-based fan-out review of a branch or PR where every finding is adversarially verified before it is reported, producing .dev/{plan-name}/review_N.md. Use when the user asks for a code review of their changes or before opening a PR. |
| disable-model-invocation | true |
To Review
Review the current changes with a panel of concern-focused agents, verify every finding against the repo, and write the report as a plan artifact.
You are the orchestrator: gather context, select the panel, run it, aggregate, write the report.
Do not review the code yourself.
Invoking this skill is the task - start at step 1 immediately and detect the diff yourself; do not ask what to review or wait for a task description.
Workflow
1. Detect context and gather the diff
- PR number given -> review that PR; else check
gh pr view for an open PR; else review the local branch against the default branch (git merge-base HEAD origin/{default}).
- Diff with local git only (never
gh pr diff), excluding lockfiles, build output, minified files, binaries, fonts, snapshots:
':!*lock*' ':!go.sum' ':!dist/' ':!build/' ':!*.min.*' ':!*.map' ':!*.png' ':!*.jpg' ':!*.gif' ':!*.webp' ':!*.woff*' ':!*.ttf' ':!**/__snapshots__/'
- Write the diff to a scratch file; agents read it from there, not inline.
- No reviewable files: say so and stop. Diff is tiny (1-2 files) or huge (>25k lines): confirm with the user before spending on the panel.
2. Load intent
The review checks the diff against what was planned, not just general quality.
- Find the plan directory the diff implements (branch name, commit messages, or ask if ambiguous). If found, read
plan.md and its task_N.md files for acceptance criteria and agreed seams.
- Also read
.dev/{plan-name}/implementation-notes.md if present (deviations logged during implementation) and the latest ~/tmp/{project-slug}/reports/{plan-name}-e2e-report.html's data block if present (which e2e scenarios exist, their pass/fail status) - both are additional evidence for the plan-conformance and tests lenses, not just the diff itself.
- No plan: derive
{plan-name} from the branch name and fall back to the PR body and commits for intent.
- Build a short brief: what the change does, what's on the critical path, what was planned.
3. Check for previous reviews
review_N.md files present -> this is a re-review: extract unresolved findings from the highest-numbered one as verification items (fixed or not?), and the new report gets the next index.
4. Select the panel
Read references/lenses.md; select only lenses with surface in this diff (a docs-only change skips performance).
Include plan-conformance whenever a plan was found.
At most one diff-specific custom lens (migrations, concurrency, i18n) when clearly warranted, defined in the same shape as the built-ins.
Tell the user which lenses you selected and why before launching.
5. Run the review panel
Launch as plain parallel subagents with the Agent tool per references/orchestration.md: all lens agents in one message, then all verifiers in a second.
Every BLOCK or CONCERN is adversarially verified - the verifier's only job is to refute it against the actual repo.
6. Aggregate
- Drop REFUTED findings entirely.
- BLOCK stays BLOCK only when CONFIRMED; PLAUSIBLE demotes to CONCERN.
- Dedupe by file:line across lenses; keep the most detailed wording, tag all lenses that found it.
- Verdict: any BLOCK -> BLOCK; else any CONCERN -> CONCERNS; else PASS.
- A failed lens doesn't abort the review; note it so the verdict is honestly partial.
7. Write the report
Write .dev/{plan-name}/review_N.md (next free index, starting at 1):
# Review {N}: {title}
Verdict: {PASS | CONCERNS | BLOCK}
Panel: {lenses run}, {failed lenses if any}
Base: {branch or PR}, {date}
{1-2 sentence summary}
## Plan conformance
Acceptance criteria met/not met, seams tested/untested. Omit if no plan.
## Previous findings
{re-review only} Each finding from review_{N-1}: fixed or still open.
## Blockers
[{lenses}] {file:line} - {title}
{The scenario that triggers it, confirmed by verification.}
## Concerns
Same shape as blockers.
## Nits
| File | Lens | Issue |
## What's good
One line per lens; omit empty ones.
## Next step
What to fix first and why.
8. Publish the report
Map the report onto REVIEW_DATA per references/data-schema.md, write ~/tmp/{project-slug}/reports/review_N.html from templates/review.html, replacing only the data block between its markers.
Before first authoring or restyling this template, load the artifact-design skill; a plain data refresh on an existing template doesn't need it again.
Publish it with the Artifact tool using that file_path (a stable magnifying-glass favicon across every review this skill produces, a title and description naming the plan and review number) - this is the literal artifact to hand a PR reviewer, not just the markdown file in the repo.
Re-reviewing the same plan later reuses the same file_path convention (a new file per review_N, so each gets its own URL); tell the user both the local path and the returned URL.
9. Present and follow through
Summarize the verdict and top findings in chat, link both the review_N.md file and its published URL.
If the user accepts findings needing real work, suggest to-tasks to turn them into task_N.md files; do not invoke it yourself.
Also suggest, as independent optional next steps rather than a mandatory chain: to-pitch when the change needs buy-in from someone who wasn't in this conversation, and to-quiz when a reviewer wants a comprehension check before merging.
