---
name: zen-grill
description: Settle the few decisions that matter before work starts, by asking one clear question at a time with a recommended answer. Use when intent or tradeoffs need clarifying before a specification.
---
# Zen grill

Turn uncertainty into shared decisions. The purpose is to settle what blocks the next step, not to run an exhaustive interview. The owner sees this as a step-by-step setup wizard: one question, a short context, a few concrete options and a recommendation.

## One question at a time

Ask exactly one question per `zen_ask_question` call. Never batch several questions into one. Each call blocks until the owner answers; time is not approval, so wait.

Each call takes these fields:

- `question`: one plain sentence that ends with a question mark.
- `context`: two or three plain sentences. Say why the choice matters and what you already know. No unexplained jargon.
- `options`: two or three concrete choices, at most four. Each has an `id`, a short `label`, a one-line `description` that states the consequence, and a `recommended` flag. Exactly one option has `recommended: true`, and it carries a `reason` in plain words.

The owner may always answer in their own words. Accept free text and treat it as a real answer.

If `zen_ask_question` is not available, use the host's native ask tool with the same format and the same one-question rule. If neither exists, ask in the conversation and wait for the reply. Do not guess the answer.

## Example

```json
{
  "question": "Who will open the exported file first?",
  "context": "The file format depends on its reader. Most people want to open it in a spreadsheet. A program that reads it needs a stricter format with a fixed layout.",
  "options": [
    {
      "id": "spreadsheet",
      "label": "People, in a spreadsheet",
      "description": "A plain CSV file with friendly column names.",
      "recommended": true,
      "reason": "It covers the most common need with the least work, and you can check it by eye."
    },
    {
      "id": "program",
      "label": "Another program",
      "description": "JSON with a fixed layout and a version number.",
      "recommended": false
    },
    {
      "id": "both",
      "label": "Both, as two files",
      "description": "Two outputs, so twice the tests to keep both right.",
      "recommended": false
    }
  ]
}
```

## Skill settings: question depth

The owner's depth setting arrives in a "Skill settings" block. Honour it.

- `quick`: only the questions that block the next step. Usually one to three questions in total.
- `standard` (default): the main decisions and their trade-offs. Usually three to six questions.
- `deep`: edge cases, risks and alternatives as well. Up to about ten questions, still one at a time.

Whatever the depth, stop as soon as the next work can be specified without consequential assumptions.

## Procedure

1. Restate the goal and the constraints already supplied, in two or three plain sentences. Say what is already decided.
2. Check the repository and existing records for facts before asking. Never ask the owner for something the repository can answer.
3. Pick the unresolved decision with the highest impact on the next step. Say in one sentence why it matters.
4. Ask it using the format above. Make the recommendation real: state the trade-off you would accept.
5. After each answer, record what it settles and what it replaces. Then choose the next question from that answer.
6. Every three or four answers, give a short plain-text summary (not a question): what is settled, and what is still open. Name which open item blocks the next step.
7. Route factual uncertainty to research, and visual uncertainty to a bounded prototype. Do not present the owner's taste or priority as a technical fact.

## Output

When the questions are done, save the settled decisions and any shared terms using the [decision and glossary template](references/output.md). Consequential decisions are DOC records with `data.kind: "adr"`; shared terms go in a glossary DOC. Persist through the record tools described in [tools.md](../zen/references/tools.md). With no companion, use the standalone writer or return a labelled draft.

End with the agreed destination, the decision list, the open questions with their owners, and the next mode. Example: "Markdown is authoritative; the cloud is a private copy; browser edits wait for the PC" settles data ownership and offline behaviour. "Use Supabase" alone does not.

This mode neither starts a coding agent nor grants Git or publication authority.