requesting-code-review

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. Name material requirements or paths not judged and why; the implementer must resolve or report those gaps, not silently count them as approved.