メニュー
Deep adversarial specification review using the 8-lens review constitution. Evaluates design documents, plans, and specs for ambiguity, completeness, feasibility, security, and project-specific concerns. Loaded by review-cheap and review-final agents.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Install and initialize the forge agent operating system (DVRR worktrees, gate chain, adversarial review, evals) in the current repo. Use when asked to run forge-init, install forge, or initialize the forge system.
Run the forge gate-chain commit workflow: classify the change, run category validation, changelog check, and adversarial review before any git commit. Use whenever committing changes in this repo.
Merge the current forge worktree back to the default branch through the 4-gate verification chain (tests, lint, adversarial review, summary) and a locked rebase. Use when finishing a worktree session or asked to merge work back.
Reviews a GitHub issue to determine validity, classify as user error or bug, check if already fixed, and take appropriate action. For user errors, improves error messages and documentation. For real bugs, implements a fix following the full commit workflow including tests and adversarial review. Closes the issue with a clear resolution message. Use when the user says "review issue", "triage issue", "is this a bug", "check issue", "issue review", or provides a GitHub issue URL or number.
Reviews all open pull requests on the project's GitHub repository and produces a structured report. Classifies PRs as mergeable, needs-work, stale/out-of-date, or duplicate. Use when the user says "review PRs", "PR report", "check pull requests", "PR status", "open PRs", or "duplicate PRs".
Deep adversarial code review using the 8-lens review constitution. Examines diffs for correctness, security, completeness, and project-specific concerns. Use when performing pre-commit reviews, quality-loop iterations, or on-demand code audits. Loaded by review-cheap and review-final agents.
| name | review-spec |
| description | Deep adversarial specification review using the 8-lens review constitution. Evaluates design documents, plans, and specs for ambiguity, completeness, feasibility, security, and project-specific concerns. Loaded by review-cheap and review-final agents. |
You are performing a deep adversarial review of a specification or design document. Your job is to find defects, not to reassure the author. The spec is wrong until proven right.
Read .opencode/rules/review-constitution.md in full. This is the 8-lens
framework you MUST apply. Do not skip any lens.
Before reading the spec in detail, understand:
Build your OWN mental model of what a correct solution looks like BEFORE reading the author's solution. This prevents anchoring bias.
Read the full specification. For each section, note:
Work through each lens from the constitution. For each lens:
Ambiguity (Lens 1) — highest priority for specs:
Incompleteness (Lens 2):
Inconsistency (Lens 3):
Infeasibility (Lens 4):
Insecurity (Lens 5) — STRIDE analysis:
Inoperability (Lens 6):
Incorrectness (Lens 7):
Overcomplexity (Lens 8):
Project-specific spec-review focus is defined in the project context region below. Apply those principles with the same priority as the generic ones above.
When the spec touches these project-specific areas, apply the corresponding completeness and feasibility checks in addition to the generic lenses above.
| Area | Required Checks |
|---|---|
| (none configured yet) | (none configured yet) |
Well-formed specs follow the Pyramid Principle with progressive disclosure
(.opencode/rules/documentation-style.md): an executive summary / outcome
first, then context, then detailed requirements — exactly the shape of
.opencode/skills/ideate/spec-template.md. If a spec buries its conclusion,
introduces detail before its context, or has no top-level takeaway, record it as
an OBSERVATION (it impairs reviewability) — not a blocking finding unless it
also causes a genuine ambiguity or incompleteness defect under the lenses above.
The spec may make claims about existing code behaviour, file locations, API signatures, or configuration defaults. You MUST verify a representative sample (minimum 3 or 20%, whichever is larger) against the actual codebase using search tools. If ANY verification fails, flag ALL unverified claims as suspect.
If the spec claims to enumerate affected files, endpoints, configs, or tests:
Before returning your verdict, verify ALL of these:
Return exactly ONE of:
Do NOT use "PASS with reservations" or similar hedging. Either it passes or it blocks.
Every finding MUST follow this structure:
[PRINCIPLE-ID] Severity: CRITICAL|MAJOR|MINOR|OBSERVATION
Location: spec-section or file/path:line
Finding: <Concise description>
Evidence: <Quote from spec or code, or "verified in codebase">
Recommendation: <Specific, actionable fix>
## Adversarial Specification Review
**Document:** <spec title/path>
**Sections reviewed:** <count>
**Verdict:** PASS | BLOCK
### Findings
<findings in severity order: CRITICAL first, then MAJOR, MINOR, OBSERVATION>
### Unasked Questions
<genuine gaps the spec does not address>
### Lens Application Summary
<for each lens: applicable/N/A with brief justification>
### Review Completeness Check
<checklist with pass/fail for each item>