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