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.