$npx -y skills add softspark/ai-toolkit --skill grill-meStress-tests a plan via Socratic questioning down each decision branch. Triggers: stress-test, grill me, validate assumptions, challenge plan, socratic review.
| 1 | # Grill Me |
| 2 | |
| 3 | $ARGUMENTS |
| 4 | |
| 5 | Interview relentlessly about every aspect of the plan until reaching shared understanding. |
| 6 | |
| 7 | ## Usage |
| 8 | |
| 9 | ``` |
| 10 | /grill-me [plan or design to stress-test] |
| 11 | ``` |
| 12 | |
| 13 | ## What This Command Does |
| 14 | |
| 15 | 1. **Reads** the plan or design (from context, file, or user description) |
| 16 | 2. **Walks** down each branch of the decision tree |
| 17 | 3. **Resolves** dependencies between decisions one-by-one |
| 18 | 4. **Provides** recommended answers for each question |
| 19 | 5. **Continues** until shared understanding is reached |
| 20 | |
| 21 | ## Rules |
| 22 | |
| 23 | - **MUST** ask questions one at a time — batching defeats the Socratic process |
| 24 | - **MUST** provide a recommended answer with every question so the user can accept, refine, or reject |
| 25 | - **NEVER** settle for vague or hand-wavy answers — press for specifics ("what does 'scale' mean here — 10k req/s or 10M?") |
| 26 | - **NEVER** skip ahead before the current branch is resolved — dependencies between decisions matter |
| 27 | - **CRITICAL**: if a question can be answered by **exploring the codebase**, explore instead of asking. Do not outsource verifiable facts to the user. |
| 28 | - **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 |
| 29 | |
| 30 | ## Gotchas |
| 31 | |
| 32 | - 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. |
| 33 | - Fatigue kicks in around 10 questions deep. For larger plans, pause and summarize every ~7 questions so the user can reorient before continuing. |
| 34 | - 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. |
| 35 | - 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. |
| 36 | - 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". |
| 37 | |
| 38 | ## When NOT to Use |
| 39 | |
| 40 | - For **implementation** — use `/plan`, `/refactor-plan`, or `/prd-to-plan` |
| 41 | - For code review after the code is written — use `/review` |
| 42 | - For architecture decisions with 2-3 named options — use `/architecture-decision` (structured trade-off) rather than open-ended grilling |
| 43 | - When the plan is crystal-clear and the user just needs a sanity check — grilling overkills trivial decisions |
| 44 | - In a production incident — use `/workflow incident-response`, speed beats thoroughness there |