grilling

How it is organised

What’s inside

The skill’s top-level sections, in order. The bar is each section’s share of the 1,458 words, so you can see where the weight sits before reading.

1. 1The two rules159 words
2. 2The tree and the order of questions140 words
3. 3Every question188 words
4. 4Keep track of what you know73 words
5. 5What to probe200 words
6. 6Guard against agreeing too easily79 words
7. 7Handling answers95 words
8. 8Knowing when to stop108 words
9. 9When the project keeps a glossary or decision records149 words
10. 10Common mistakes114 words

The skill itself

Read it before you install it

---
name: grilling
description: Interview the user relentlessly about a plan, design, decision or idea until every branch of the decision tree is resolved and nothing is silently assumed, before anything is built. Each decision is put to the user with a recommended answer; facts are looked up, never asked. Use when the user says "grill me", "stress-test this plan", "poke holes in this", "what am I missing", "challenge my design" or "interview me about this", or hands over a request too vague to start on. Also covers grilling a plan against a project's glossary and decision records ("grill with docs"). Not for reviewing code, not for turning an agreed plan into a document, and not for one quick clarifying question on an otherwise clear task.
license: MIT
---

# Grilling

A plan is only as good as the questions nobody asked. Grilling is a deliberate, heavier-than-usual interview that walks every decision in a plan until you and the user understand the same thing, and nothing important is left assumed. The aim is a plan someone with no context could carry out without coming back with questions.

Start when the user asks for it. If a request is plainly too vague to act on, offer it once in a sentence; do not impose a long interview unasked. If a grilling is already running, continue it rather than starting again.

## The two rules

**Facts are yours; decisions are the user's.**

- A fact is anything the environment can tell you: what the code does, what a config says, what the docs or history show, how a tool behaves, whether the thing the plan proposes already exists in the project or publicly (which can change the decision). Look it up. Do not spend the user's attention on it. If the lookup is slow, hand it to a helper if you have one, and keep asking about everything that does not depend on the result.
- A decision is intent, priority, constraint, taste, risk appetite, or something that exists outside this machine. Put each one to the user and wait for the answer. Do not answer it yourself and move on.

**Do not act on the plan until the user confirms the shared understanding.** That confirmation covers the design only. It is not permission for an irreversible step; those still need their own yes.

## The tree and the order of questions

Treat the plan as a tree: each decision branches into the decisions that hang off it. Ask only questions whose prerequisites are already settled. A question whose answer depends on one still open waits for a later turn.

Versions of this method differ on pacing: some ask one question at a time, others put every currently askable question in one numbered round. Both are defensible. A workable default:

- Ask one question per turn when the decisions are weighty or tangled, and wait for the answer.
- When several questions are independent and small, put a few together, numbered, and wait for all the answers. A question that could have been in the last round but was held back is a dribble; fold it in.
- Never ask a wall of questions. It gets one answer and a closed laptop.

## Every question

1. **Check that it is a real fork.** Name the two plans the answer chooses between. If the plan comes out the same either way, do not ask. Pick a default, record it, and move on. Do not spend questions on naming and cosmetics.
2. **Say why it matters,** in a clause: what changes depending on the answer.
3. **Give your recommended answer** and a one-line reason, so that "yes" is a complete reply. Make the recommendation a real position. When what you found contradicts the user's approach, lead with the evidence and recommend the correction.
4. **Make vague words concrete.** "Fast", "simple", "secure" and "soon" get a number or an observable inside your recommendation: "fast enough means search returns in under two seconds. Right number?"

A host's pick-list tool is fine for asking if it has one. Otherwise plain text:

```
Q3 - Retry policy: should failed uploads retry on their own, or stop and ask?
     Why it matters: automatic retries need an idempotent endpoint.
     Recommended: retry up to three times, then stop and ask. The endpoint
     already deduplicates by upload id (I checked the handler).
```

## Keep track of what you know

Say where each fact came from: the user said it, you checked it in a named place (a file, a command, a document they gave you), or you are assuming it, with what changes if the assumption is wrong. Training memory and "the docs say" without a read are assumptions. When the user states something a source contradicts, show both and let them choose. Do not quietly comply and do not quietly override.

## What to probe

Plans usually break in one of these places:

- **Goal.** Where would two reasonable people build different things? What does "done" look like, concretely?
- **Acceptance.** Can someone check that it is done, or is it an aspiration?
- **Boundaries.** What is tempting to touch that should stay untouched? What is explicitly out of scope?
- **Alternatives.** What was ruled out, and why? What was not considered?
- **Assumptions.** Which load-bearing ones are guesses?
- **Contradictions.** Do the goal, the data, the method, the time and the money agree with each other?
- **Landmines.** Irreversible actions on real data, other systems or scripts that depend on what will change, differences between this environment and the target, credentials or approvals that do not exist yet, interfaces that must not move, scale far beyond the test data, regulated or personal data, and code that looks odd but is deliberate. Also check whether the named means serves the real end.

Invent concrete scenarios that probe edge cases, and make the user be precise about the boundary.

**Danger rule.** Any destructive or irreversible step gets its own confirmation question that names the irreversibility, and the plan gets a backup, dry run or rollback step.

## Guard against agreeing too easily

Once scope and shape stop moving, spend one question inviting the user to prove you wrong: state the two or three riskiest assumptions, then aim at the one that would hurt most. "The claim most likely to sink this plan is X. Does it hold?" A confirmed landmine must visibly change the plan, and you follow it all the way down, not patch it with a sentence. Repeat the checkpoint after any answer that makes you rebuild the plan.

## Handling answers

- **"You decide", or a bare "yes" to a batch.** Take your recommended answers and mark them as your choices, so the user can see which decisions were theirs and which were delegated.
- **They reject your recommendation.** Accept it. Do not argue it again unless new evidence appears.
- **An answer conflicts with an earlier one.** Show the smallest conflict and ask which stands.
- **They ask you something.** Answer plainly first, then continue.
- **They end the session.** Stop at once and list what is unresolved. Do not invent answers to close it.

## Knowing when to stop

You are done when no open fork remains whose wrong answer would be expensive and every assumption you rely on has been stated and confirmed or corrected. Stop asking when the next question would cost more to ask than the mistake would cost to fix; default and record everything still open. Two answers in a row that do not shrink the open set mean churn: checkpoint or close.

Close by playing it back: the decisions with the reason for each, the defaults you chose for the user, and what is still open. Ask whether that matches their understanding. Write it to a file only if they want one.

## When the project keeps a glossary or decision records

If the repository has a glossary file or decision records (for example `CONTEXT.md` and `docs/adr/`), also:

- **Challenge terms against the glossary.** "Your glossary defines cancellation as X, but you seem to mean Y. Which is it?"
- **Sharpen fuzzy words.** When a term is overloaded, propose one canonical word. "Account" might mean the customer or the user.
- **Cross-check against the code.** If the user says how something works and the code disagrees, say so and ask which is right.
- **Record as you go,** with the user's agreement, instead of at the end. A resolved term goes in the glossary, which holds terms and nothing about implementation. Create these files only when there is something to put in them.
- **Offer a decision record sparingly,** only when the choice is hard to reverse, would surprise a future reader, and came from a real trade-off with real alternatives.

## Common mistakes

| Mistake | Fix |
|---|---|
| Asking what the code could tell you | Look it up |
| Asking a question whose answer changes nothing | Default it and record it |
| Questions with no recommendation | Always recommend, with the reason |
| Stacking questions that depend on each other | Ask the prerequisite first |
| Letting "yes" settle everything silently | Mark which answers were delegated to you |
| Treating plan approval as permission to do anything | Irreversible steps still need their own yes |
| Interviewing past the point of use | Stop when the next fork costs less to fix than to ask |

The second audit

What we found in the sources

Almost every skill in this family descends from one short instruction (interview the user relentlessly, walk the decision tree, recommend an answer for each question, look facts up instead of asking). Later copies add rounds of questions, a glossary variant, and wrappers that only call other skills. This rewrite keeps the method, reconciles the one-at-a-time and whole-round versions, and adds the checks the fuller variants found useful: a necessity test for each question, source tags for facts, a mid-interview challenge to the plan, a danger rule, and clear stopping rules. The interrogate skills in this bundle are a different job (multi-reviewer code review) and are covered in a proposal instead. Every source below was read at the commit the auditor recorded. Nothing was taken from a source without a permissive license.

What each source contributed

• the-inconvenience-store/skills ↗ · Primary basis · MIT

  The design-tree method: map decisions as a tree, ask only the questions whose prerequisites are settled, let answers push the frontier outward, treat finding facts as the agent's job and decisions as the user's, run lookups without blocking the rest of the questions, finish when every branch is visited and nothing is silently assumed, and do not act until the user confirms the shared understanding.

• dougborg/harness-kit ↗ · Structure and wording · Apache-2.0

  The shape of the description ("grill me", stress-testing, requirements still fuzzy), the recommended answer given for every question, a round that is complete when each question is answered or explicitly deferred, the done condition that every assumption relied on has been stated and confirmed or corrected, and summarising decisions before acting. Its Claude Code question-tool section was left out so the skill reads the same in any host.

• rengwu/wayfinder-maps ↗ · Added ideas · MIT

  Waiting for the answer to each question before continuing because asking many at once is bewildering, the facts-versus-decisions wording, and not enacting the plan until the user confirms.

• rengwu/wayfinder-maps ↗ · Added ideas · MIT

  Challenging the user's terms against a glossary, sharpening fuzzy language into canonical terms, stress-testing relationships with edge-case scenarios, and updating the glossary and decision records as terms and decisions settle, creating those files only when needed.

• leobbaroni/cockpit ↗ · Added ideas · MIT

  The necessity test (name the two plans an answer chooses between, otherwise default and record), a recommended answer with a stated basis so that "yes" is complete, tagging facts as stated by the user, verified from a named source, or assumed with the consequence if wrong, quantifying vague words, one question to invite the user to falsify the riskiest assumption once scope and shape settle, following a confirmed landmine all the way down the plan, the list of places plans break, the danger rule for irreversible steps, and stopping when the next question costs more to ask than to fix.

• max4c/skills ↗ · Added ideas · MIT

  The five dimensions to probe (goals, acceptance, boundaries, alternatives, assumptions), the test that a plan should be executable by an agent with no context, and listing the weak spots even when the user ends the session early. The numeric scores and thresholds were dropped.

• max4c/skills ↗ · Added ideas · MIT

  Checking the user's statements against the code and surfacing contradictions, the glossary holding terms and no implementation detail, and offering a decision record only when the choice is hard to reverse, surprising without context and a real trade-off.

• xu91102/claude-everything-Workflow ↗ · Added ideas · MIT

  Treating "you decide" as delegation and recording the default as delegated, accepting a rejected recommendation without repeated persuasion, showing the smallest conflict when an answer contradicts an earlier one, and stopping at once and listing the unresolved decisions when the user ends the session.

• Ezra144israel/governed-agent-skills ↗ · Added ideas · MIT

  Scoping the confirm-before-acting rule to the design being agreed so that it is not permission for irreversible acts, and the idea that a question which could have been asked in the previous round is a dribble.

• kostachernyshov/skills ↗ · Added ideas · MIT

  Checking for contradictions between goal, data, method, time and money in each round, marking which decisions were the person's and which the agent's, searching for existing public work before asking, and continuing a grilling already running instead of restarting.

• jjilli/fable-flow ↗ · Added ideas · MIT

  Starting only when the user asks for it, because it is heavier than normal clarification.

• Krtiiik/skills ↗ · Added ideas · MIT

  Closing by recording each settled decision as one line (decision, answer, the user's reason) followed by the list of assumptions.

What changed

• The description now carries the phrases a person would type ("grill me", "stress-test this plan", "poke holes", "what am I missing") and a not-for clause. The one-line descriptions in most sources ("A relentless interview to sharpen a plan or design") give nothing to match on.
• Rewritten as one self-contained file. Wrapper skills that only say to run another skill, Claude Code question-tool instructions, plan-mode steps and emoji question markers were replaced by plain text that works in any host.
• The sources disagree on pacing: some ask exactly one question per turn, others ask the whole currently askable set in a numbered round, one caps a round at six. The rewrite gives a default (one question when decisions are weighty or tangled, a few together when independent and small) and says the two are both defensible. This is a judgement, not a tested choice.
• The sources disagree on when grilling starts (only on explicit request, versus whenever a plan is being finalised). The rewrite starts on request and offers it once when a request is plainly too vague.
• The glossary and decision-record variant is folded in as one section instead of a second skill, since its source files are one-line wrappers that call grilling plus a separate domain skill. Where those files hold content, it is kept.
• The confirmation gate is stated as covering the design only, so that agreeing a plan is never read as permission for an irreversible step.

Problems found in the sources

• !mattpocock/skills: The grill-with-docs file is a single line telling the agent to run a grilling session using a domain-modeling skill. A lone copy has no content and depends on two other skills. It sets disable-model-invocation, so it never triggers on its own.
• !the-inconvenience-store/skills: The grilling file is the shortest complete statement of the frontier-round method. Its grill-me file is a one-line wrapper, and its grill-with-docs file is byte-identical (same SHA-256) to the one in mattpocock/skills. The question format uses emoji markers that not every host renders well.
• !CapitalCantrip/quality-gates: The grill-with-docs file is a wrapper that tells the agent to call the Skill tool twice, a tool name only some hosts have.
• !dougborg/harness-kit: The grill-me and grill-with-docs files are wrappers that call the Skill tool. The grilling file has a description with explicit trigger phrases, but one section is specific to Claude Code's question tool, with a plain-text fallback for other hosts.
• !serejaris/ris-claude-code: Short text that asks one question at a time and has no rule on stopping or confirming the result; description includes "mentions grill me" as a trigger.
• !gyuch-an02/claude-omakase: The same short text as serejaris/ris-claude-code with a triggers list added to the front matter.
• !miroo93/dev-workflows: The same short text with a rule that every question must go through one specific question tool and never be inline text, so it does not work where that tool is absent.
• !Rabuno/planship: The same text as rengwu/wayfinder-maps grill-me under the name grilling, with a trigger-phrase description and the words "or project files" dropped from the lookup rule.
• !max4c/skills: The grill-me description names six caller skills in other plugins, and the body tells the model to write the report back with a command from one of them. The numeric thresholds have no stated basis. The text says not to do arithmetic and then defines the aggregate as the mean of five scores. The grill-with-docs file links to CONTEXT-FORMAT.md and ADR-FORMAT.md, which are not in the downloaded file.
• !leobbaroni/cockpit: The grilling file is 19 KB and depends on TRACKS.md and PLAN-FORMAT.md, which are not in it. Its rules are explicit and usable but written for building a complete plan, and it requires one question per turn with a fixed header. The grill-with-docs file depends on the same files and on a separate domain-modeling skill.
• !xu91102/claude-everything-Workflow: Built around that project's router and Spec Gate, with a hand-back format and a reference to skills/using-superpowers/SKILL.md that is not in the file. The interview loop in the middle is self-contained.
• !Ezra144israel/governed-agent-skills: Contains scouting notes with dates and commit ids inside the skill text and boundary sections that refer to its own governance skills (reasoning-doctrine, governed-operator), which a lone copy does not have.
• !kostachernyshov/skills: The grilling file is specific to a bioinformatics project: it reads and writes CLAUDE.md, LOG.md and run.yaml, links TOPICS.md, which is not in the file, and uses a fixed decision-log entry. Its grill-me file calls the grilling skill and refers to a /grill-with-plan command.
• !jjilli/fable-flow: Tied to a /fable-flow:plan step and a task file in that project. It credits an upstream grilling skill in mattpocock/skills.
• !Krtiiik/skills: Requires plan mode, a clickable question tool and an exit-plan approval step, all host-specific.
• !marinvch/Cortex: The grilling file follows the frontier method of the-inconvenience-store/skills closely and says it is adapted from mattpocock/skills. It adds a section about that project's own rituals, an employer-firewall rule, and a fallback for weaker models: run the interview as a written file, three questions at a time.
• !Bossmann007/cursor-kit: The grilling file is the-inconvenience-store/skills text with em dashes replaced by colons and semicolons and a two-question format example.
• !dlmastery/startup-skills: A grill for startup ideas that writes BRIEF.md and ASSUMPTIONS.md under a runs/ folder, takes a venture-partner persona, covers nine question domains from a question bank file not in the download, and says "2-4 rounds is typical" with no basis given.
• !RollRollRoll/agent-toolkit: Chinese. The grill-with-docs file is a translation of the one-line wrapper (call the Skill tool twice, for grilling and domain-modeling); I read the whole file and it has no other content.

What was dropped

• The numeric ambiguity scores, means and thresholds (0.2, 0.3, 0.4) in max4c/skills grill-me. No basis is given for the values, and the file tells the model not to do arithmetic and then asks it to take a mean.
• The six caller skills and the report write-back commands in max4c/skills grill-me, and the references to CONTEXT-FORMAT.md and ADR-FORMAT.md in its grill-with-docs, which are not in the downloaded files.
• The track files, plan-format files, per-turn counters and plan skeleton of leobbaroni/cockpit grilling. It depends on TRACKS.md and PLAN-FORMAT.md which are not in the file, and the whole-plan rehearsal belongs to planning rather than to grilling.
• Plan-mode and approval steps (Krtiiik/skills), routing and hand-back formats tied to one workflow (xu91102/claude-everything-Workflow), and governance references (Ezra144israel/governed-agent-skills).
• The bioinformatics run log, solution-model block and decision-line format of kostachernyshov/skills, and the startup founder brief of dlmastery/startup-skills. Both are domain-specific jobs.
• A fixed per-turn header and the requirement that every statement be tagged, from leobbaroni/cockpit. The tags are kept as a light rule about saying where a fact came from.

Same text, wherever you work

Use it where you work

git clone https://github.com/nikbearbrown/skills
cp -R skills/skills/grilling ~/.claude/skills/

Pairs with