Request Code Review
Use this skill as the main code review entrypoint. It can run a quick single-review, a multi-lens lightweight review, or escalate to deep-review for milestone/risky checkpoint review.
Core principle: review early, review precisely, scale reviewer effort to the change, and turn valid out-of-scope findings into follow-up tasks instead of expanding the current PR by default.
Default path: identify the target, load only relevant repo/domain skills or instructions, choose quick/standard/deep by scale and risk, dispatch the minimum useful reviewers, synthesize evidenced findings, fix in-scope blockers, and rerun gates.
Workflow
- Identify the review target:
- plan/spec: OpenSpec change, tasks.md, or implementation plan before coding
- single commit:
HEAD~1..HEAD
- stack:
base..HEAD, often dev..HEAD, main..HEAD, or upstream branch
- uncommitted diff: current working tree
- Summarize what changed or is planned, requirements, non-goals, change type, expected validation gates, and known risks.
- Discover relevant repo/domain skills or instructions from project-local skills, repo docs, and available skill descriptions. Load only the skill bodies or references that match the target, and record which were considered.
- Choose review mode:
- quick = tiny/small low-risk: inline structured review or one reviewer
- standard = medium ordinary work: 2-4 lightweight lenses when cheap models are available
- deep = large/risky/checkpoint/pre-submit/security/process-sensitive/disputed: call
deep-review
- Choose lenses based on likely failure modes: spec/plan correctness, implementation correctness, maintainability/simplify, tests/gates, UX/docs, workflow/process, adversarial. For runnable user-facing UI/UX changes, treat unexplained missing browser or visual evidence as a review finding unless clearly not runnable.
- Dispatch reviewers with
subagent when bounded and cheap. Use swarm only when persistent coordination is needed.
- Require structured output. Prefer JSON when the coordinator must act programmatically. Ask reviewers to summarize large logs or diffs instead of pasting them in full.
- Treat Critical as blocking. Treat Important as fix-before-proceed only when supported by evidence, plausible impact, and an in-scope remedy. Track Minor or create follow-ups opportunistically.
Context funnel
Read references only when needed:
references/review-rubric.md: severity definitions and checklist.references/reviewer-json-schema.md: machine-readable review output.references/adversarial-review.md: minimax or red-team prompts for adversarial/process/security lenses.references/multi-review-fanout.md: lightweight multi-lens roles and synthesis. Escalate to deep-review for milestone/risky checkpoints.assets/evidence-packet.md: copyable review packet template.scripts/validate.sh: behavioral contract checks for this skill.
Minimum reviewer prompt fields
- repo path and branch
- base and head refs or statement that diff is uncommitted
- what was implemented
- change type and expected validation gates
- requirements or acceptance criteria
- gates already run
- known risks or process constraints
- relevant skills or instructions loaded, plus relevant ones considered but skipped
- exact output format requested
- whether out-of-scope findings should become follow-up tasks
Follow-up rule
If a reviewer finds a real issue outside current scope, do not silently expand the PR. Create or propose a follow-up with evidence, impact, acceptance criteria, and priority unless it blocks correctness or acceptance for the current task.
Do not give the reviewer the whole session transcript unless the task is reviewing process or truthfulness. Focus review on plan/diff, requirements, and evidence. If reviewer feedback lacks concrete evidence or conflicts with project conventions, verify before changing code.
1---2name: request-code-review3description: Primary review entrypoint for plans, diffs, commits, subagent results, and pre-submit checks. Selects quick, standard, or deep mode by scale and risk.4---56# Request Code Review78Use this skill as the main code review entrypoint. It can run a quick single-review, a multi-lens lightweight review, or escalate to `deep-review` for milestone/risky checkpoint review.910Core principle: review early, review precisely, scale reviewer effort to the change, and turn valid out-of-scope findings into follow-up tasks instead of expanding the current PR by default.1112Default path: identify the target, load only relevant repo/domain skills or instructions, choose quick/standard/deep by scale and risk, dispatch the minimum useful reviewers, synthesize evidenced findings, fix in-scope blockers, and rerun gates.1314## Workflow15161. Identify the review target:17 - plan/spec: OpenSpec change, tasks.md, or implementation plan before coding18 - single commit: `HEAD~1..HEAD`19 - stack: `base..HEAD`, often `dev..HEAD`, `main..HEAD`, or upstream branch20 - uncommitted diff: current working tree212. Summarize what changed or is planned, requirements, non-goals, change type, expected validation gates, and known risks.223. Discover relevant repo/domain skills or instructions from project-local skills, repo docs, and available skill descriptions. Load only the skill bodies or references that match the target, and record which were considered.234. Choose review mode:24 - quick = tiny/small low-risk: inline structured review or one reviewer25 - standard = medium ordinary work: 2-4 lightweight lenses when cheap models are available26 - deep = large/risky/checkpoint/pre-submit/security/process-sensitive/disputed: call `deep-review`275. Choose lenses based on likely failure modes: spec/plan correctness, implementation correctness, maintainability/simplify, tests/gates, UX/docs, workflow/process, adversarial. For runnable user-facing UI/UX changes, treat unexplained missing browser or visual evidence as a review finding unless clearly not runnable.286. Dispatch reviewers with `subagent` when bounded and cheap. Use `swarm` only when persistent coordination is needed.297. Require structured output. Prefer JSON when the coordinator must act programmatically. Ask reviewers to summarize large logs or diffs instead of pasting them in full.308. Treat Critical as blocking. Treat Important as fix-before-proceed only when supported by evidence, plausible impact, and an in-scope remedy. Track Minor or create follow-ups opportunistically.3132## Context funnel3334Read references only when needed:3536- `references/review-rubric.md`: severity definitions and checklist.37- `references/reviewer-json-schema.md`: machine-readable review output.38- `references/adversarial-review.md`: minimax or red-team prompts for adversarial/process/security lenses.39- `references/multi-review-fanout.md`: lightweight multi-lens roles and synthesis. Escalate to `deep-review` for milestone/risky checkpoints.40- `assets/evidence-packet.md`: copyable review packet template.41- `scripts/validate.sh`: behavioral contract checks for this skill.4243## Minimum reviewer prompt fields4445- repo path and branch46- base and head refs or statement that diff is uncommitted47- what was implemented48- change type and expected validation gates49- requirements or acceptance criteria50- gates already run51- known risks or process constraints52- relevant skills or instructions loaded, plus relevant ones considered but skipped53- exact output format requested54- whether out-of-scope findings should become follow-up tasks5556## Follow-up rule5758If a reviewer finds a real issue outside current scope, do not silently expand the PR. Create or propose a follow-up with evidence, impact, acceptance criteria, and priority unless it blocks correctness or acceptance for the current task.5960Do not give the reviewer the whole session transcript unless the task is reviewing process or truthfulness. Focus review on plan/diff, requirements, and evidence. If reviewer feedback lacks concrete evidence or conflicts with project conventions, verify before changing code.
george-rd