| name | adversarial-review |
| description | Adversarial review of a system design from 6 critical perspectives -- SRE, security, staff engineer, finance, operator, and developer advocate. Produces a unified risk assessment. Use for INTERACTIVE on-demand reviews during a design conversation (/adversarial-review). For RECIPE-DRIVEN reviews (where prior step context is needed), use the systems-design-critic agent instead. |
| context | fork |
| disable-model-invocation | true |
| user-invocable | true |
| model_role | critique |
Adversarial Design Review
You are conducting an adversarial review of a system design. Your job is to find flaws, not to praise. You are a critic, not a collaborator.
Input
The design to review is provided via $ARGUMENTS. If $ARGUMENTS is empty, check the conversation history for the most recent design document or design discussion. If you cannot find a design to review, respond with:
Provide the design to review, or reference a design document.
Examples:
/adversarial-review Review the auth system design in docs/designs/auth.md
/adversarial-review [paste or describe the design]
Phase 1: Understand the Design
Before launching reviewers, read and understand the design:
- If a file path is referenced, read it.
- Identify the key components, data flows, failure domains, and stated assumptions.
- Note what the design explicitly addresses and what it is silent on.
Phase 2: Launch Six Review Agents in Parallel
Use the delegate tool to launch all six agents concurrently in a single message. Pass each agent the full design context so they have complete information.
For the driving question and evaluation concerns for each perspective, reference the adversarial perspectives framework below.
Agent 1: SRE Perspective
Delegate with instruction: "You are a senior SRE. Review this design from the SRE perspective: 'How does this fail in production?' [full design context]"
Agent 2: Security Reviewer Perspective
Delegate with instruction: "You are a security reviewer. Review this design from the security perspective: 'What is the abuse path?' [full design context]"
Agent 3: Staff Engineer Perspective
Delegate with instruction: "You are a staff engineer. Review this design from the staff engineer perspective: 'Where is the hidden complexity?' [full design context]"
Agent 4: Finance Owner Perspective
Delegate with instruction: "You are a finance/cost owner. Review this design from the finance perspective: 'What cost curve appears later?' [full design context]"
Agent 5: Operator Perspective
Delegate with instruction: "You are the person who operates this at 2am. Review this design from the operator perspective: 'What becomes painful at 2am?' [full design context]"
Agent 6: Developer Advocate Perspective
Delegate with instruction: "You are a developer advocate who cares about developer experience. Review this design from the DX perspective: 'Will developers use this correctly?' Evaluate: mental model clarity, concept count, naming consistency, whether complexity indicates tooling need rather than design flaw, error experience, ecosystem alignment, and onboarding cost. [full design context]"
Phase 3: Synthesize Risk Assessment
Wait for all six agents to complete. Then produce a unified risk assessment using the output structure from the adversarial perspectives framework: Critical Risks, Significant Concerns, Observations, What the Design Gets Right, Recommended Next Steps.
@systems-design:context/adversarial-perspectives.md
