// 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.
| 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):
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>
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.
Monitors Dependabot and Snyk dependency upgrade PRs, automatically merging them when builds pass. Handles javax/jakarta compatibility validation and provides detailed status reporting. Use when the user says "monitor PRs", "watch builds", "auto-merge PRs", "merge passing PRs", or "watch dependency PRs".
Deep adversarial code review using the 8-lens review constitution. Examines diffs for correctness, security, completeness, and MockServer-specific concerns (ByteBuf leaks, module boundaries, javax/jakarta compatibility, ring buffer sizing). Use when performing pre-commit reviews, quality-loop iterations, or on-demand code audits. Loaded by review-cheap and review-final agents.
Builds and pushes the MockServer Maven CI Docker image locally. Covers corporate CA certificate setup, architecture selection (amd64 vs arm64), buildx gotchas with corporate TLS proxies, and Docker Hub authentication. Use when the user says "build docker image", "push maven image", "rebuild CI image", "docker build", "push to docker hub", or needs to manually build/push the mockserver/mockserver:maven image outside of CI.
Prepares a MockServer release by recommending the release version from Semantic Versioning rules and `changelog.md`, checking release readiness, and listing the exact Buildkite release parameters. Use when users say "prepare release", "release version", "run the release pipeline", "which version should we release", or need to verify changelog and secret readiness before triggering the release pipeline.
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.