---
name: grill-me-plus
description: Interview the user relentlessly about a plan, decision, or idea until reaching shared understanding, resolving each branch of the decision tree. Use Claude Code's AskUserQuestion or Codex's request_user_input when available so decisions are click-to-answer. Use when the user says "grill me", wants to stress-test their thinking, compare design choices, or resolve ambiguous implementation decisions.
---

# Grill Me Plus

Interview the user relentlessly about every aspect of a plan, design, product idea, implementation approach, or architectural choice until there is shared understanding.

Walk the decision tree one branch at a time. Resolve dependencies between decisions in order. The **frontier** is every open decision whose prerequisites are already settled — the questions that can be asked now without guessing at answers not yet given. For each question, provide a recommended answer and concrete alternatives with trade-offs.

Finding facts is never the user's job. If a question can be answered by exploring the environment — codebase, files, docs, tools, or current implementation — inspect that context instead of asking. When a fact needs real research, dispatch a sub-agent to find it and keep interviewing — a running lookup is an unsettled prerequisite, so only the decisions downstream of it wait. The rest of the frontier stays askable now.

## Core Loop

1. Identify the next unresolved decision that matters.
2. Check whether existing context already answers it. If yes, record the decision and move on. If it needs a fact worth researching, dispatch a sub-agent, mark the branch deferred, and continue with the rest of the frontier while it runs.
3. Ask one focused structured question through the current harness's question tool when available.
4. Lead with the recommended option and explain the trade-off for every option.
5. After the user answers, update the decision ledger and infer any downstream decisions that answer implies.
6. Continue until the plan is resolved, the user stops the grill, or the remaining uncertainty cannot be resolved without external information.

## Decision Ledger

Maintain a running internal ledger:

- `settled`: decisions the user explicitly chose.
- `implied`: decisions that follow from earlier answers.
- `open`: branches still worth asking about.
- `deferred`: questions blocked by missing context, a pending fact-finding sub-agent, external constraints, or user choice.

Before asking anything, check the ledger. Never re-ask a resolved or implied branch. When a fact-finding sub-agent reports back, move its downstream branches from `deferred` to `open`.

## Tool Selection

Use the best structured question tool exposed by the current agent harness:

- **Claude Code:** use `AskUserQuestion`.
- **Codex:** use `request_user_input` when it is listed in the available tools for the current turn. Codex only exposes this tool in Plan mode.
- **Other agents or missing structured tool:** ask directly in chat, one question at a time, preserving the same recommendation/options/trade-off structure.

Do not print fake tool JSON to the user. Either call the available tool or ask naturally in chat.

## Shared Question Rules

- Ask one decision at a time by default.
- Batch only questions on the current frontier: every prerequisite settled, none depending on another answer in the same batch.
- Put the recommended option first and suffix its label with ` (Recommended)`.
- Use concise option labels, ideally 1-5 words.
- Make every option real. No filler choices.
- Do not add an explicit `Other` option when the tool already provides free-form custom answers.
- Use a short header/tag, 12 characters or fewer when the tool supports headers.
- Phrase the question so answering it commits to a concrete decision.
- Explain what each option commits the project to, not just what it is.

## Claude Code: AskUserQuestion

Use `AskUserQuestion` for every question when it is available.

**These questions are always blocking. Do not time out and do not continue without a real user response.** Every `AskUserQuestion` call must wait for the user to actually answer. Never proceed on an assumed answer, a default, or your own best guess when the tool is still waiting. If the user has not responded, stay blocked — do not advance the grill, infer the answer, or move to the next decision until a genuine answer comes back.

Use the tool to its full capability:

- Ask 1 question per call by default.
- Batch up to 4 frontier questions per call — the tool's cap. A question whose answer depends on another question in the batch belongs to a later call.
- Provide 2-4 options per question.
- Use `multiSelect: true` only when options can legitimately stack, such as feature support lists or acceptable constraints. Otherwise leave it false or omit it.
- If the tool supports option `preview`, use it only for useful concrete snippets or examples. Never pass `null`; omit `preview` entirely when there is no meaningful preview.
- Keep `header` short: `Auth`, `DB`, `Scope`, `UI`, `Risk`, `API`, `Ship`.

Example shape:

```json
{
  "questions": [
    {
      "header": "Auth",
      "question": "Which authentication direction should this plan assume?",
      "multiSelect": false,
      "options": [
        {
          "label": "OIDC (Recommended)",
          "description": "Uses the existing identity provider and keeps authorization centralized."
        },
        {
          "label": "Email magic",
          "description": "Simpler for users, but adds email delivery dependency and weaker enterprise fit."
        },
        {
          "label": "Password login",
          "description": "Familiar and self-contained, but adds password storage and recovery surface area."
        }
      ]
    }
  ]
}
```

## Codex: request_user_input

Use `request_user_input` whenever it is listed in Codex's available tools for the current turn. Codex only exposes this tool in Plan mode. If it is not available, tell the user once — before the first question — that switching to Plan mode (Shift+Tab) enables the click-to-answer picker, then continue with the chat fallback rather than waiting for a mode switch.

Codex has a stricter shape than Claude Code:

- Ask 1 question per call by default.
- Ask at most 3 questions per call.
- Provide exactly 2-3 mutually exclusive options per question.
- Include a stable `id` in `snake_case`.
- Include a `header` of 12 characters or fewer.
- Include a single-sentence `question`.
- Each option must have a short `label` and one-sentence `description`.
- Put the recommended option first and suffix its label with ` (Recommended)`.
- Do not include `Other`; the client adds free-form Other automatically.
- Omit `autoResolutionMs` for grill-me decisions because these questions are usually blocking.
- Use `autoResolutionMs` only when the question is useful but non-blocking and the grill can continue with best judgment if the user does not answer.

Example shape:

```json
{
  "questions": [
    {
      "header": "Data",
      "id": "data_source",
      "question": "Which data source should this design optimize around first?",
      "options": [
        {
          "label": "Primary DB (Recommended)",
          "description": "Keeps the first version aligned with current writes and avoids introducing sync state."
        },
        {
          "label": "Search index",
          "description": "Improves query flexibility, but makes freshness and rebuild behavior first-order concerns."
        },
        {
          "label": "Event stream",
          "description": "Fits audit-heavy workflows, but increases operational complexity before the base flow is proven."
        }
      ]
    }
  ]
}
```

Because Codex options are mutually exclusive and capped at 3, convert multi-select topics into either a smaller mutually exclusive choice or a follow-up sequence.

## Chat Fallback

When no structured tool is available, ask directly:

```text
Auth: Which authentication direction should this plan assume?

1. OIDC (Recommended) - Uses the existing identity provider and keeps authorization centralized.
2. Email magic - Simpler for users, but adds email delivery dependency and weaker enterprise fit.
3. Password login - Familiar and self-contained, but adds password storage and recovery surface area.
```

Then wait for the answer before continuing.

## Stop Conditions

Stop when:

- The user says to stop.
- The plan is sufficiently resolved to act.
- Remaining branches depend on information outside the current context.
- The user asks for a summary, PRD, implementation plan, or next-step artifact.

End with a compact summary of settled decisions and unresolved risks, then the block in **When you're done**.

## When you're done

End the session by printing the block below — whether the plan resolved, the user stopped the grill, or a branch dead-ended. On harnesses without slash commands, write the command as plain phrasing (`run to-spec-plus`) instead of `/to-spec-plus`.

```text
---
Pipeline: **decide** → spec → slice → build   (1 of 4)
Done: <n of m decisions settled; what's still open>
Next:
  • <condition> → /<skill> <ref>
```

List only the conditions that actually apply, most likely first:

- **Plan resolved, spans several slices** → `/to-spec-plus` to record it
- **Plan resolved, fits one session** → `/to-tickets-plus`, or `/implement-plus` if it's genuinely one ticket
- **Resolved but too big for one spec, or still foggy** → `/wayfinder-plus` to chart it as a map
- **A branch is blocked on knowledge someone else holds** → `/to-questionnaire-plus` on that branch
- **A branch is blocked on a fact worth reading for** → `/research-plus` on that question
- **Stopped early** → `/grill-me-plus` to resume; list the open branches by name so the next session starts on the frontier