---
name: review
description: Produce a structured, report-only review of a context-selected change set across risk, standards, intent, evidence, and documentation.
---

# review

Review a change set selected from context and produce a structured review report.
This skill is standalone and context-driven.
It does not know about implementation lifecycle, task claiming, task resolution, PR creation, or task result recording.
It must not edit code.

Reviewer prompts live under [`reviewers/`](reviewers/).
Load the relevant reviewer files before running independent dimension reviews.

## 1. Select and capture the change set

Select the relevant change set from current context.
The change set may be uncommitted changes, branch changes, a PR, explicit files, or another clear source.
State what change set you selected before reviewing.
Ask or stop only when scope ambiguity would make the review untrustworthy.

Capture enough material for reviewers to inspect the selected change set.
This may include a diff, changed-file list, commit list, PR details, relevant intent source, available verification evidence, and repository instructions or standards sources.
Do not overprescribe mode selection or intent-source taxonomy.
Use agent judgment when the selected change set and intent source are clear enough to review.

Done when the chosen change set is explicit and reviewers have enough input to judge it.

## 2. Run dimension reviews

Run independent dimension reviewers through whatever real context boundary the current harness provides.
A separate agent, worker, subprocess, or documented headless session is sufficient when each reviewer can inspect its dimension without seeing the parent review's intermediate conclusions.
Use one reviewer per dimension when practical.
If no real context boundary is available, stop before reviewing and report that independent review cannot be completed in the current runtime.
Do not replace independent reviewers with in-process role switches.

Use these reviewer files:

- [`reviewers/risk.md`](reviewers/risk.md)
- [`reviewers/standards.md`](reviewers/standards.md)
- [`reviewers/intent.md`](reviewers/intent.md)
- [`reviewers/evidence.md`](reviewers/evidence.md)
- [`reviewers/documentation.md`](reviewers/documentation.md)

Each reviewer should follow its own purpose, boundary, rubric, and output expectations.
The shared base finding shape is flexible:

```markdown
- **Severity**: error | warning | info
  **Blocking**: yes | no
  **Location**: <file, line, command, artifact, or none>
  **Finding**: <specific issue>
  **Why it matters**: <impact>
  **Suggested fix**: <concrete next action, or none>
```

Reviewers may add dimension-specific fields where useful.
Reviewers classify findings as blocking or non-blocking.
The caller or user decides final disposition.

Done when each applicable dimension has returned findings or a clear statement that the dimension does not apply.

## 3. Run targeted checks when useful

Run targeted checks when they are needed to assess a dimension.
Prefer focused commands that clarify evidence, risk, or standards conformance.
Do not turn review into a full external validation pipeline.
If a full suite or expensive check is clearly needed, explain why before relying on it.

Record commands and artifacts that materially influenced the review.
Do not present unrun checks as evidence.

Done when the review has enough evidence for its findings and limitations are stated honestly.

## 4. Aggregate the structured review report

Produce a structured review report, not a gate artifact and not a pass/fail verdict.
Keep sections separate so one dimension does not mask another.
Deduplicate exact duplicates only.
Mention when separate dimensions independently flag the same issue.

Use this report shape unless the selected change set calls for a small adaptation:

```markdown
## Reviewed change set

<what was reviewed and how it was captured>

## Risk

<risk reviewer section>

## Standards

<standards reviewer section>

## Intent

<intent reviewer section>

## Evidence

<evidence reviewer section>

## Documentation

<documentation reviewer section>

## Summary

- Blocking findings: <count>
- Non-blocking findings: <count>
- Targeted checks run: <commands or none>
- Evidence limitations: <limitations or none>
```

Do not invent a pass/fail verdict.
Use blocking findings present or absent as the review's actionable summary.

Done when the report states the reviewed change set, preserves every applicable dimension, and summarizes blocking status and evidence limitations.