菜单
Deep adversarial specification review using the 8-lens review constitution. Evaluates design documents, plans, and specs for ambiguity, completeness, feasibility, security, and MockServer-specific concerns. Loaded by review-cheap and review-final agents.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Regenerate the MockServer dashboard screenshots used on www.mock-server.com by driving a populated demo dashboard with headless Chromium (Playwright). Use when the dashboard UI has changed and the website screenshots (jekyll-www.mock-server.com/images/MockServer*.png) need refreshing, or when asked to "update the UI screenshots", "regenerate dashboard screenshots", or "take screenshots of the dashboard for the docs". Captures one Retina PNG per tab at the same geometry as the existing images.
Investigates AWS infrastructure issues affecting Buildkite build agents (EC2, AutoScaling, Lambda). Returns structured JSON to the parent for formatting. Triggers when users ask about build agents not running, EC2 issues, ASG scaling problems, or infrastructure health.
Continuously monitors Buildkite pipeline builds, detects failures, investigates root causes, fixes issues, and pushes fixes. Runs a polling loop that checks build status at configurable intervals for a configurable duration. Use when the user says "monitor builds", "watch pipeline", "watch CI", "continuous monitoring", "keep checking builds", or wants automated build-fix cycles.
Investigates Buildkite pipeline failures to find root causes. Returns structured JSON to the parent for formatting. Triggers when users ask about failing pipelines, build errors, or need help debugging CI/CD issues. Accepts Buildkite build URLs or build numbers and performs deep investigation.
Clarifies a rough idea into a precise problem specification through structured dialogue. Asks targeted questions to surface assumptions, scope, constraints, and actors. Produces a specification document defining WHAT needs to change — not HOW to change it. Use when starting a new feature, brainstorming an idea, clarifying requirements, or when a user says "I have an idea", "let's think through", "ideate", "brainstorm", "I want to build", "help me think about", "what should we build".
Interact with Dependabot and Snyk pull requests for dependency upgrades and security fixes. Documents Dependabot commands, javax/jakarta compatibility checks, safe merge workflows, and troubleshooting. Use when managing dependency upgrade PRs or security fix PRs.
| 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 MockServer-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):
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>