$npx -y skills add spencerpauly/skills-repo --skill grill-meInterview the user relentlessly about a plan or design until every branch of the decision tree is resolved. Use when the user says "grill me", "stress-test this plan", "poke holes in this", or "what am I missing".
| 1 | # Grill Me |
| 2 | |
| 3 | Walk the user down their own decision tree until there's nothing left unresolved. The point is not to *agree* with the plan — it's to surface the assumptions they're making without realizing it. |
| 4 | |
| 5 | ## When to use |
| 6 | |
| 7 | - The user shares a plan, RFC, design, or proposal and asks you to challenge it. |
| 8 | - The user says "grill me", "ask me hard questions", "what am I missing". |
| 9 | - Before a big commit / deploy / launch and the user wants a sanity check. |
| 10 | |
| 11 | ## Steps |
| 12 | |
| 13 | 1. **Read the plan once, without interrupting.** Hold it in your head before asking anything. |
| 14 | |
| 15 | 2. **Ask one question at a time.** Wait for the answer before asking the next. Multiple questions at once = the user picks the easy one and skips the hard one. |
| 16 | |
| 17 | 3. **Walk the decision tree depth-first.** |
| 18 | - Pick the most load-bearing assumption. |
| 19 | - Resolve every branch under it before moving to the next assumption. |
| 20 | - Don't context-switch between unrelated decisions. |
| 21 | |
| 22 | 4. **For each question, also state your recommended answer.** Don't just interrogate — give the user something to push back on. A question without a hypothesis is a survey, not a grilling. |
| 23 | |
| 24 | 5. **If a question can be answered by reading the codebase, read the codebase.** Don't make the user look up something you can grep yourself. |
| 25 | |
| 26 | 6. **Track open threads.** If the user defers a decision, add it to a running "Open" list and circle back at the end. |
| 27 | |
| 28 | ## Question patterns that work |
| 29 | |
| 30 | - "What happens if <the assumption you're depending on> is wrong?" |
| 31 | - "Who is the first person to notice this is broken? How long after it breaks?" |
| 32 | - "What's the dumbest version of this we could ship in a day? Why isn't that good enough?" |
| 33 | - "When you say <vague word> — do you mean A, B, or C?" |
| 34 | - "Walk me through the worst-case rollback. How bad is it?" |
| 35 | |
| 36 | ## Output format |
| 37 | |
| 38 | ```markdown |
| 39 | ## Question 1 |
| 40 | <the question> |
| 41 | |
| 42 | **My guess:** <your recommended answer + 1-sentence rationale> |
| 43 | |
| 44 | --- |
| 45 | (after the user answers) |
| 46 | |
| 47 | ## Question 2 |
| 48 | ... |
| 49 | |
| 50 | --- |
| 51 | |
| 52 | ## Open at end of session |
| 53 | - ... |
| 54 | - ... |
| 55 | ``` |
| 56 | |
| 57 | ## Don't |
| 58 | |
| 59 | - Don't ask five questions at once. One. |
| 60 | - Don't cheerlead. "Great plan!" is the opposite of the job. |
| 61 | - Don't ask questions you could answer yourself by reading the repo. |
| 62 | - Don't stop early because the plan "seems fine". The whole point is to find what *doesn't* seem fine. |