grilling
The facts
Its description
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
The description the agent reads to decide when to use it.
When it starts
The agent picks this skill when the user wants their thinking stress-tested — a plan, decision, or idea they want interrogated rather than built — or when they use a phrase containing 'grill'. It is a conversational interview skill, so it fires on what the person asks for, not on a file or command.
Things a person might say (the model's guesses)
- “Grill me on my plan for the new billing service.”
- “I want to stress-test this architecture decision before I commit to it.”
- “Can you push back hard on my idea for the onboarding flow?”
A model's summary of when it is used.
Starts other agents
1 line mentions starting other agents
Lines in the file that mention starting another agent. Found by matching words, so treat them as pointers.
Stops for a person
3 lines stop to ask a person
Lines that stop and wait for a person before going on. Found by matching words, so treat them as pointers.
What leads to it
- ask-matt hands off to this only when you want the interview with no wrapper ask-matt, line 86
- grill-me hands off to this grill-me, line 7
- grill-with-docs calls this grill-with-docs, line 7
- improve-codebase-architecture calls this once the user picks a candidate improve-codebase-architecture, line 64
- loop-me calls this loop-me, line 8
- triage calls this if the request needs fleshing out triage, line 76
- wayfinder calls this wayfinder, line 79
- writing-fragments calls this writing-fragments, line 9
Other skills that hand off to this one, call it, require it or offer it instead, as a model read them.
Licence
MIT, from LICENSE
The terms its author shares it under, which let it be shown here.
Other files in this skill (1) Close
The text
Most marks come from matching words in the file, so treat them as pointers.
Interview the user relentlessly until you reach a shared understanding. Map this as a design tree: every decision branches into the decisions that hang off it.
Work the tree in rounds. The frontier is every decision whose prerequisites are already settled: the questions you can ask now without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
Format a round like so:
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer>
---
❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer>Word each question so "yes" accepts your recommended answer.
Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a later round, not this one.
Finding facts is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent with a fresh context window to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The decisions are the user's: put each to them and wait.
The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.
Raw lines 1 to 30From mattpocock/skills at 4ae2317, 2026-10-31. Skills read by DeepSeek V4.1 Flash on 2026-11-04. Summary and techniques by Claude Opus 5.5 on 2026-11-06.