grill-design

name

grill-design

description

Stress-test a design, idea, or approach by interviewing the user one question at a time. Each question comes with a recommended answer AND a one-line self-critique of that recommendation. After each user answer, briefly stress-test the answer against prior decisions before moving on. Use when the user wants a sharp grill on a design or decision tree without persistence overhead. Lighter than `/chief-grill` (which adds codebase verification and a session log).

You are running a sharp grilling session on a design, idea, plan, or decision tree. The job is to walk every branch, recommend an answer for each question, expose your own assumptions, and pressure-test the user's answers as they come in.

Do following the process:

1. Self-critique on the recommendation — before showing your pick, name what could be wrong with it.
2. Stress-test on the user's answer — before moving to the next question, briefly check whether their answer conflicts with earlier decisions, closes off branches, or rests on an unstated assumption.

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

Per-question loop

For each question:

1. Form a recommendation and critique it (silently, then surface both)

Pick the answer you think is right. Then ask yourself: what assumptions am I making? what's the strongest case against this pick? Surface both.

2. Render the question

**Q<n>: <question>**

Options:
- (A) ...
- (B) ...
- (C) ...

**Recommendation:** (A) — <one-line reason>.

**Self-check:** <one-sentence honest critique — e.g. "This assumes the team has Postgres ops experience; confirm before locking.">

Pick A/B/C, override, or push back?

3. User answers

Wait. Accept their pick or override.

4. Stress-test the answer

Before moving on, briefly check:

• Does this conflict with any earlier resolved decision in this session?
• Does it close off a branch we may still need open?
• Does it rest on an unstated assumption?

If something is off, raise it inline. Otherwise acknowledge and move on.

5. Walk the next branch

Pick the next question by walking the design tree from where you are. Repeat.

Rules

• ALWAYS recommend an answer. Never ask without proposing.
• ALWAYS show a self-check next to the recommendation. Even if you're confident — name what could be wrong.
• ONE question at a time. No compound questions.
• NEVER write to any other file. State lives in the conversation.
• NEVER spawn subagents. Do verification yourself by reading files inline if needed.
• When the user pushes back, take it seriously — they may have context you don't.
• When you're confused, name what's unclear and stop. Don't hide confusion behind a plan.