/grill-me

name: grill-me
description: "Stress-tests a plan via Socratic questioning down each decision branch. Triggers: stress-test, grill me, validate assumptions, challenge plan, socratic review."
user-invocable: true
effort: medium
argument-hint: "[plan or design to stress-test]"
allowed-tools: Read, Grep, Glob, Bash, Agent

Grill Me

$ARGUMENTS

Interview relentlessly about every aspect of the plan until reaching shared understanding.

Usage

/grill-me [plan or design to stress-test]

What This Command Does

1. **Reads** the plan or design (from context, file, or user description) 2. **Walks** down each branch of the decision tree 3. **Resolves** dependencies between decisions one-by-one 4. **Provides** recommended answers for each question 5. **Continues** until shared understanding is reached

Rules

• **MUST** ask questions one at a time — batching defeats the Socratic process
• **MUST** provide a recommended answer with every question so the user can accept, refine, or reject
• **NEVER** settle for vague or hand-wavy answers — press for specifics ("what does 'scale' mean here — 10k req/s or 10M?")
• **NEVER** skip ahead before the current branch is resolved — dependencies between decisions matter
• **CRITICAL**: if a question can be answered by **exploring the codebase**, explore instead of asking. Do not outsource verifiable facts to the user.
• **MANDATORY**: apply Devil's Advocate critique to every major decision — the default answer ("let's ship it") is almost always the one that needs challenging

Gotchas

• Grilling can feel adversarial. Frame questions as "what if X happens" not "your plan is wrong because X" — the goal is shared understanding, not winning.
• Fatigue kicks in around 10 questions deep. For larger plans, pause and summarize every ~7 questions so the user can reorient before continuing.
• Some disagreements cannot be resolved by argument — they need data. If a question loops (user defends A, grill defends B, repeat), recommend a spike or experiment instead of more questions.
• The user's "final answer" after heavy grilling may be reluctant compliance, not genuine agreement. Watch for hedging language ("I guess", "sure, fine") and probe once more.
• Grilling a plan that is already detailed and well-vetted produces diminishing returns and annoyance. Know when to stop — exit condition is "shared understanding", not "exhaustive coverage".

When NOT to Use

• For **implementation** — use `/plan`, `/refactor-plan`, or `/prd-to-plan`
• For code review after the code is written — use `/review`
• For architecture decisions with 2-3 named options — use `/architecture-decision` (structured trade-off) rather than open-ended grilling
• When the plan is crystal-clear and the user just needs a sanity check — grilling overkills trivial decisions
• In a production incident — use `/workflow incident-response`, speed beats thoroughness there