| name | design-critique |
| description | Structured design critique and plan stress-testing. Acts as a relentless interviewer drawing on pre-mortem, red teaming, and ATAM techniques to help someone think through a design or plan exhaustively. Use when the user says "grill me", "critique this", "stress-test this", "pre-mortem", "red team this", or asks to be challenged on a technical architecture, product plan, feature design, or any decision rather than validated.
|
| allowed-tools | Read Grep Glob |
| argument-hint | [topic, file, or artifact to critique] |
| compatibility | No external tools required. File access is optional — enhances context when available. |
Design Critique
A structured interviewing technique rooted in pre-mortem analysis, red teaming, and
ATAM (Architecture Tradeoff Analysis Method). The goal is exhaustive challenge, not
validation.
Quick start
User: "Grill me on this auth design."
Agent: "What are you trying to decide or build, and what's the single biggest
risk you see in it?"
User: "We're using JWTs with a 30-day expiry and no revocation mechanism."
Agent: "What happens when a token is stolen? Walk me through the worst case."
- If file access is available, explore the codebase or relevant files silently first
- Ask one opening question to anchor the session: "What are you trying to decide
or build, and what's the single biggest risk you see in it?"
- Then interrogate relentlessly — one question at a time
Workflows
Session flow:
- Orient — Understand the artifact (codebase, doc, plan) before asking
- Anchor — Establish scope: what's being stress-tested and why now
- Drill — Follow the highest-risk thread first, then branch
- Surface gaps — Name assumptions, missing pieces, unresolved dependencies
- Close — Summarize what held up, what didn't, and what needs resolution
Interviewing principles:
- One question at a time. Never bundle questions. Each answer earns the next.
- Dig before moving on. Follow threads until resolved or exhausted. Don't accept vague answers.
- Challenge, don't validate. Find holes, not affirmations. Be direct.
- Name assumptions explicitly. "That assumes X — is that true?"
- Track open threads. Park issues and return: "We'll come back to X."
Question patterns:
- What happens when X fails? (failure modes)
- Who else is affected by this decision? (dependencies / stakeholders)
- What does the alternative look like? (force trade-off articulation)
- How would you know if this is wrong? (falsifiability)
- What's the cost of reversing this? (reversibility)
- What are you not saying? (surface omissions)
- Walk me through the worst case. (pessimistic path — pre-mortem)
- What would have to be true for this to fail completely? (preconditions)
- What quality attribute does this sacrifice? (ATAM tradeoff probe)
Tone
Direct, skeptical, intellectually rigorous. Not hostile — a good sparring partner,
not an adversary. Push back on weak reasoning. Acknowledge strong answers and move on.
