Requesting Code Review
Review the complete change at a coherent verification boundary. Follow the
host's delegation rules; use an available reviewer when independent review
is required or materially useful. A skill does not create a missing agent
capability or authorize commits, publication, or a merge.
When to review
- Review major features and changes before merge, covering their requirements
and affected execution paths.
- For parallel work, review every contribution and the integrated behavior;
one integrated review may cover coupled tasks. Do not require a separate
blocking review after every worker or microstep.
- Seek a fresh perspective when evidence stalls, a complex defect persists,
or the change has a consequential trust or compatibility boundary.
- For a small bounded change, proportionate inline review is sufficient unless
the host, user, or applicable merge policy requires independent signoff.
Prepare a self-contained review brief
Use the reviewer's actual host-provided name and capabilities. No external
prompt template is required. Supply:
- Goal: requested behavior, acceptance criteria and explicit non-goals.
- Scope: diff-review or whole-system audit, changed files, coupled interfaces,
and relevant source context. Use the scope rules in
code-review-and-quality.
- Compared states: the actual baseline and candidate. For uncommitted work,
provide the working-tree diff or before/after snapshots; do not invent SHAs
or create commits just to fill a review template.
- Evidence: commands and observed results, checked state, reproduction steps,
and any verification gaps. Never present a dry-run as a behavior result.
- Output: actionable findings with severity, file/line, contract impact and
supporting evidence. Use
critical, warning, suggestion and the canonical
report/verdict rules in code-review-and-quality and fable-judge.
The reviewer needs the work product and relevant constraints, not an entire
session transcript. In diff-review, suppress hypothetical or unrelated findings;
whole-system audits retain their broader invariant scope.
If independent review is unavailable, finish reachable implementation and
verification, report the unavailable signoff, and do not claim it was obtained.
Do not cross a merge or approval boundary that requires that signoff.
Act on findings
- Check each finding against the actual contract and source; push back with
evidence when it is incorrect.
- Repair material in-scope defects and verify the repair. Suggestions do not
become automatic blockers or new requirements.
- Resolve outcome-changing ambiguity before dependent changes; continue
independent authorized fixes. Follow
receiving-code-review.
- Keep execution tracking separate from reviewer-owned approval. Reuse valid
evidence, but obtain new checks or review when changes invalidate it.
- Report remaining material gaps rather than silently approving, fabricating
review, or marking the reviewer's checkboxes yourself.
Source: obra/superpowers (MIT). Adapted for coding-kit: host-aware review dispatch and coherent change boundaries.
1---2name: requesting-code-review3description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements4license: MIT5---67# Requesting Code Review89Review the complete change at a coherent verification boundary. Follow the10host's delegation rules; use an available reviewer when independent review11is required or materially useful. A skill does not create a missing agent12capability or authorize commits, publication, or a merge.1314## When to review1516- Review major features and changes before merge, covering their requirements17 and affected execution paths.18- For parallel work, review every contribution and the integrated behavior;19 one integrated review may cover coupled tasks. Do not require a separate20 blocking review after every worker or microstep.21- Seek a fresh perspective when evidence stalls, a complex defect persists,22 or the change has a consequential trust or compatibility boundary.23- For a small bounded change, proportionate inline review is sufficient unless24 the host, user, or applicable merge policy requires independent signoff.2526## Prepare a self-contained review brief2728Use the reviewer's actual host-provided name and capabilities. No external29prompt template is required. Supply:3031- **Goal:** requested behavior, acceptance criteria and explicit non-goals.32- **Scope:** diff-review or whole-system audit, changed files, coupled interfaces,33 and relevant source context. Use the scope rules in `code-review-and-quality`.34- **Compared states:** the actual baseline and candidate. For uncommitted work,35 provide the working-tree diff or before/after snapshots; do not invent SHAs36 or create commits just to fill a review template.37- **Evidence:** commands and observed results, checked state, reproduction steps,38 and any verification gaps. Never present a dry-run as a behavior result.39- **Output:** actionable findings with severity, file/line, contract impact and40 supporting evidence. Use `critical`, `warning`, `suggestion` and the canonical41 report/verdict rules in `code-review-and-quality` and `fable-judge`.4243The reviewer needs the work product and relevant constraints, not an entire44session transcript. In diff-review, suppress hypothetical or unrelated findings;45whole-system audits retain their broader invariant scope.4647If independent review is unavailable, finish reachable implementation and48verification, report the unavailable signoff, and do not claim it was obtained.49Do not cross a merge or approval boundary that requires that signoff.5051## Act on findings5253- Check each finding against the actual contract and source; push back with54 evidence when it is incorrect.55- Repair material in-scope defects and verify the repair. Suggestions do not56 become automatic blockers or new requirements.57- Resolve outcome-changing ambiguity before dependent changes; continue58 independent authorized fixes. Follow `receiving-code-review`.59- Keep execution tracking separate from reviewer-owned approval. Reuse valid60 evidence, but obtain new checks or review when changes invalidate it.61- Report remaining material gaps rather than silently approving, fabricating62 review, or marking the reviewer's checkboxes yourself.6364---6566> Source: obra/superpowers (MIT). Adapted for coding-kit: host-aware review dispatch and coherent change boundaries.
oleg494