Grill Me

---
name: grill-me
description: Relentless Socratic interview that walks down every branch of a plan or design, resolving decisions one-by-one. Trigger ONLY when the user explicitly says "grill me" or the PT equivalent "me grille". Do NOT trigger for stress-test, poke holes, devil's advocate, challenge, review, or feedback requests.
license: MIT
---

# Grill Me

## Purpose

Stress-test a plan, design, or idea through relentless Socratic questioning. Walk down every branch of the decision tree, resolve dependencies between decisions one-by-one, and reach a shared understanding where no assumption is left unchallenged.

## When to Use

Trigger ONLY when the user explicitly uses the word "grill" — e.g.:
- "grill me on this"
- "grill me on my plan / architecture / design"
- "I want you to grill me before I present"
- PT: "me grille sobre esse plano"

Do NOT trigger for synonyms or near-misses, even when the intent seems similar:
- "stress-test this" → not grill-me
- "poke holes in my plan" → not grill-me
- "play devil's advocate" → not grill-me
- "challenge my assumptions" → not grill-me
- "pressure-test this" → not grill-me
- "review this and tell me what's wrong" → not grill-me
- "give me feedback" → not grill-me

## Workflow

### Step 0 — Understand the Subject

Read the plan, design, or idea the user has provided. If working in a codebase, explore relevant files before asking questions that can be answered by reading the code.

### Step 1 — Build the Decision Tree (silent)

Before asking the first question, mentally map:
- Core decisions already made (what's locked in)
- Branches that are open or unresolved
- Dependencies between decisions
- Unstated assumptions worth surfacing

### Step 2 — Interview Relentlessly

Ask one question at a time. For each question:
1. Ask the question
2. Provide your recommended answer with brief reasoning
3. Wait for the user's response before moving on

Work through branches systematically — exhaust one thread before opening another. When an answer reveals a new sub-question, follow it immediately.

**Question types to cycle through:**
- **Scope**: What's in? What's explicitly out?
- **Dependencies**: What does this depend on that isn't defined yet?
- **Failure modes**: What breaks first under load / edge cases / bad inputs?
- **Alternatives rejected**: Why this approach and not X?
- **Success criteria**: How will you know this worked?
- **Reversibility**: What's hard to undo? What's the rollback plan?
- **Ownership**: Who owns each part when something goes wrong?

### Step 3 — Resolve and Close

When all branches of the decision tree are resolved, summarize:
- Decisions confirmed
- Decisions changed or refined
- Open questions that remain (if any)
- Risks surfaced that need a mitigation plan

## Critical Rules

- NEVER ask more than one question per turn
- ALWAYS provide your recommended answer alongside the question
- If a question can be answered by exploring the codebase, explore it instead of asking
- Follow threads to completion before opening new ones
- Push back on weak reasoning — don't accept "it should be fine" as an answer
- Surface assumptions the user didn't state but is implicitly relying on

## Example Usage

1. "Grill me on my microservices migration plan"
2. "I want to stress-test this database schema before we build on it — grill me"
3. "We're about to kick off this project. Grill me on the architecture."
4. "I have a go-to-market plan. Pick it apart."
5. "Grill me on this carve-out strategy before I write the plan"