requesting-code-review

Files (2)

• SKILL.md
• code-reviewer.md

SKILL.md (first lines)

# Requesting Code Review

## Purpose

Independent review supplies a perspective that implementation reports cannot.
Place it where it changes confidence in semantic behavior, integration, or risk;
do not manufacture a review merely to find a style issue or demonstrate process.

Low-risk mechanical work does not always need an independent reviewer by default.

## When review is warranted

Request independent review at meaningful semantic or risk boundaries, including
user-visible behavior changes, API or compatibility boundaries, cross-module
integration, and substantive implementation milestones. Request a final
whole-change review for substantive work so the reviewer can assess the joined
behavior rather than isolated diffs alone.

Short changes still merit independent review when they involve security, data-integrity, permission, concurrency, or cross-module behavior. Repeated low-risk mechanical changes that follow an already-reviewed pattern may be reviewed as a group, with the chosen semantic acceptance evidence preserved.

## Review inputs and scope

Give the reviewer the smallest durable package that permits real judgment:

- the requirement or task brief and binding constraints;
- the implementer report as evidence to inspect, not authority to trust;
- a review package for the exact commit range; and
- the semantic scenario, acceptance evidence, integration boundary, and named
  risks that warrant the review.

Ask the reviewer to judge semantic behavior and integration: whether the change
solves the intended user or operational problem, preserves its contracts, and
works with neighboring modules. Style and maintainability findings matter when
they threaten that behavior or future safe change; they are not a quota.

## Acting on findings

Fix Critical and Important findings before relying on the reviewed behavior.
Record Minor findings when they have a clear owner or future decision. If a
reviewer is wrong, respond with concrete code or semantic evidence rather than
silencing the review.

After a fix, request another independent review only when the finding or fix
changes semantic behavior, risk, or integration confidence. For a contained
mechanical correction, preserve focused validation and the reason a further
review would not add evidence.

## Dispatch guidance

Use the active harness's supported worker mechanism; do not assume a particular
subagent API. Select reviewer capability proportional to the diff's risk and
the judgment required. Reviewers are read-only and should return evidence-backed
findings with file references and severity tied to impact.

See [code-reviewer.md](code-reviewer.md) for the whole-change review template.

From BB-84C/superpowers-lite, MIT.

More from BB-84C/superpowers-lite