review

name	review
description	Review a diff, pull request, commit, spec, story, plan, or document through focused lenses and return triaged, evidence-based findings. Use when the user explicitly asks to review something.

Review

Run a deliberate multi-lens review. This is a review workflow, not an invitation to rewrite the artifact or apply fixes without permission.

Scope

Accept a file, directory, diff, commit, branch, pull request, or the current uncommitted work. If no target is supplied, use the conversation context first, then inspect the current Git state and ask for a target if it remains ambiguous. Include untracked files when reviewing uncommitted work.

Classify the target as one of: code, diff, specification, plan, story, or general document. A specification or plan may still receive behavioral review when it defines system behavior.

Lenses

Select only applicable lenses unless the user names lenses explicitly. Run independent lenses in parallel through the matching opencode subagents:

• cynical-reviewer — adversarial omissions, contradictions, unsafe assumptions
• edge-case-hunter — branching, boundaries, failure recovery, rollout gaps
• code-reviewer — changed-code correctness and acceptance concerns
• structural-editor — document organization and information flow
• prose-editor — clarity and comprehension without changing meaning
• fact-check or scholarly-fact-check — externally verifiable claims

Do not run every lens blindly. Code changes normally need cynical, edge-case, and code review. Specs and plans normally need cynical and edge-case review. Documents may need structural/prose review. Use fact-checking only when claims matter to the artifact.

If the user names lenses, honor that selection exactly.

Review method

1. State the target, classification, and lenses.
2. Read the target and its surrounding context. For a diff, inspect the changed files in full where practical, not only the hunks.
3. Give each subagent the target path/content, scope, and expected output. Do not pass one lens's findings to independent lenses; this reduces anchoring.
4. Reconcile the findings without silently deduplicating overlap. Repeated findings across lenses are useful signal.
5. If the user requests a focused follow-up such as dig into auth, rerun only the relevant scope in correctness mode.

Do not invent findings to make the review look thorough. A clean result is valid.

Finding contract

Every finding should use this shape:

{
  "lens": "edge-case-hunter",
  "location": "src/auth.ts:42-57",
  "trigger_condition": "A retry occurs after the token expires",
  "guard_snippet": "Define expiry handling and a bounded retry policy",
  "potential_consequence": "Requests loop or fail with an ambiguous error"
}

Use repository-relative path:line locations for code. For documents, use a heading or section. Do not assign severity or priority in the canonical JSON; describe consequence and evidence instead. If the existing reviewer agent returns severity, preserve it only as an additional note in the markdown view.

Output

Return:

1. A short review header with target and lenses.
2. A markdown report grouped by lens, retaining every finding.
3. A fenced JSON array containing the canonical findings.

For no findings, state which scope was reviewed and say that no material issues were found. Do not change files unless the user explicitly asks for fixes.