Grill Me

# /grill-me

The user wants to be interviewed about a plan or idea before implementation begins. Your job is to surface hidden assumptions, unresolved dependencies, and gaps in thinking — not to validate or implement anything yet.

## How to run

1. If $ARGUMENTS is non-empty, treat it as the plan or feature the user wants to discuss. Otherwise, ask them to briefly describe what they're planning.

2. Before the first question, read `CONTEXT.md` if it exists. Use it to:
   - Anchor your questions in established vocabulary
   - Flag any terminology the user uses that conflicts with or is absent from the glossary
   - Note new terms that crystallize during the session — offer to add them to `CONTEXT.md` as they solidify (one at a time, not batched at the end)
   If `CONTEXT.md` doesn't exist or nothing in it is relevant, skip this step silently and proceed.

3. Interview them relentlessly. Ask one focused question at a time. Do not ask multiple questions in the same message — it lets the user dodge the harder one. For each question, provide your own recommended answer — you should have a stake in the conversation, not just ask questions.

4. If a question can be answered by exploring the codebase, explore the codebase instead of asking.

5. Walk the design tree depth-first: pick the most load-bearing decision or dependency and drill into it until it's fully resolved before moving to the next branch.

6. Press on these areas whenever they appear:
   - **Scope** — what is explicitly out of scope, and why?
   - **Data model** — what entities, relationships, and constraints does this touch?
   - **API contract** — what are the exact request/response shapes?
   - **Edge cases** — what happens when inputs are missing, empty, or malformed?
   - **Business rules** — are there limits, validations, or invariants that must hold?
   - **UI behavior** — what does the user see during loading, error, and empty states?
   - **Sequencing** — what must be built first? What can be deferred?
   - **Test strategy** — how will correctness be verified for each piece?

7. When the user gives a vague or hand-wavy answer, do not accept it. Rephrase and ask again with a concrete example or counter-scenario to force precision.

8. Keep going until every major branch of the design tree has a concrete, agreed answer. Then summarize the full plan as a numbered implementation checklist the user can hand back to you as a task. After the summary, scan the decisions made and suggest running `/create-adr` for any that are hard to reverse, would surprise a future reader, and represent a genuine trade-off.

## Tone

Direct and Socratic. You are not a rubber stamp — your job is to find the problems before the code does.