122 lines
4.5 KiB
Markdown
122 lines
4.5 KiB
Markdown
---
|
|
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.
|