Grill
Skill mickzijdel/dev-hooks/plugins/thinking-tools/skills/grill
Use when a plan, design, or feature idea needs to be interrogated until it is fully specified — the user wants to be interviewed, one question at a time, until every open decision is resolved. Triggers on "grill me", "interview me", "ask me questions about this", "stress-test this plan with me", "help me fully specify this", or before writing a plan/PRD from a still-fuzzy idea — offer to grill first rather than drafting from guesses. Not for generating ideas from scratch (that's brainstorming), third-party critique (that's [[board]]), or failure-mode hunting (that's [[premortem]]).From its SKILL.md
npx -y skills add mickzijdel/dev-hooks --skill grillAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT; copyright Matt Pocock; see ../matt-pocock-skills-LICENSE.txt. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.1 KB, 467 tokens by cl100k_base, as published. Nobody here has run it
Grill
Interview the user relentlessly about a plan or design until you reach shared understanding. The deliverable is a resolved decision tree, restated back as a decisions summary — not a document (unless the user asks for one).
The loop
-
Map the decision tree first. Sketch the branches the plan actually depends on — scope, data model, interfaces, edge cases, sequencing, rollout. Walk them in dependency order: never ask about a leaf while its trunk is unresolved, because the trunk's answer reshapes the leaves.
-
One question at a time. Ask, wait for the answer, absorb it, then ask the next. Batching questions is bewildering, and each answer re-ranks what's worth asking next.
-
Recommend an answer with every question. The user reacts faster and more honestly to a position than to a blank. State your recommendation and the one-line reason; let them push back.
-
Legwork before asking. If the codebase, docs, git history, or a quick command can answer the question, go look instead of asking. The user's time is for judgement calls, preferences, and things only they can know.
-
Show the tree between rounds. Every few questions, restate which branches are resolved (with their decisions) and which are still open. This is how the user steers and how you avoid re-asking.
Completion criterion
Done only when every branch is resolved — no remaining question whose answer would change the plan — and you have restated the full set of decisions back as a compact summary the user confirms. Not done because the user went quiet, a round number of questions has passed, or the conversation feels long. If the user cuts the session short, list the still-open branches explicitly so nobody mistakes the plan for fully specified.
Composing with other skills
- When a term crystallises or two words turn out to mean the same thing, run [[domain-modeling]] inline to capture it in the glossary — grilling is where vocabulary gets sharp.
- A resolved branch that was hard to reverse and cost real deliberation is an [[adr]].
- When the plan is fully specified, offer a [[premortem]] before execution starts.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 3 of the 12 instructions most review quality skills give in 467 tokens
Counted across 1,048 of the 1,783 authors here whose files we hold, read 2026-08-07
- Ask questions one at a timehere, and in 81 of 1048, across 64 files
- Provide a recommended answer for each questionhere, and in 73 of 1048, across 50 files
- Explore the codebase instead of asking answerable questionshere, and in 66 of 1048, across 42 files
- Resolve dependencies between decisions one-by-onein 42 of 1048, across 17 files
- Interview the user relentlessly about the planin 38 of 1048, across 13 files
- Order findings by severityin 31 of 1048
- Resolve each branch of the decision treein 27 of 1048, across 5 files
- Run a grilling sessionin 26 of 1048, across 5 files
- Update CONTEXT.md immediately when a term is resolvedin 26 of 1048, across 11 files
- Propose precise canonical terms for vague languagein 25 of 1048, across 7 files
- Create documentation files lazilyin 24 of 1048, across 5 files
- Assign severity to every findingin 24 of 1048
Said here and by no other author read
- map the decision tree in dependency order first
- restate resolved and open branches between rounds
- walk branches in dependency order
- capture crystallised terms using domain-modeling
- record hard-to-reverse resolved branches as adr
- offer premortem when plan is fully specified
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.