grilling
Skill2 starsChanged 2 months agoMITView on GitHub
Stress-test a plan, design, decision, or idea with rounds of exhaustive questions until shared understanding, then return a decision handoff. Use when the user wants to stress-test their thinking before a spec or plan, or says grill / grill me / 拷问 / 盘问.
193 other projects use a version of this, 125 of them edited.
Adopted by
Most recently taken up by
- xiaoxiaosrm/dsh-mattpocock-skillsedited, first seen Nov 8, 2026
- wowyuarm/dsh-agent-teamedited, first seen Nov 8, 2026
- Contexera/dsh-agent-teamedited, first seen Nov 8, 2026
- awslabs/agentic-developer-platformedited, first seen Nov 8, 2026
- microsoft/frontier-agentic-modernization-rvasedited, first seen Nov 8, 2026
- The-Vibe-Company/quivredited, first seen Nov 8, 2026
Used with
Projects with it also use capture-learning-tools, design-frontend-dev and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
The-Vibe-CompanySkillcapture-learning-tools
Turn technical conversations, bugs, CI failures, review comments,
Also in 5 projects that use this
The-Vibe-CompanySkilldesign-frontend-dev
Clean Impeccable frontend design skill. Use when the user wants to
Also in 5 projects that use this
RoentekSkillloop-me
Grill me about specs for the workflows I want to build, within this workspace.
Also in 58 projects that use this
liufeng1976Skillsetup-ts-deep-modules
Wire dependency-cruiser into a TypeScript repo so each package is a deep module — implementation hidden in subfolders, reachable only through its entry-point files. User-invoked.
Also in 42 projects that use this
FabienDehopreSkilldecision-mapping
Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time.
Also in 8 projects that use this
AWSSkillwizard
Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.
Also in 136 projects that use this
- +3 more from The-Vibe-Company
Other versions193 projects use a version of this.
Word for word · 0
None found.
Edited · 125
- mattpocock/skills★ 309k51% same
- QuivrHQ/quivr★ 40k18% same
- The-Vibe-Company/quivr★ 40k18% same
- windmill-labs/windmill★ 18k52% same
- formbricks/formbricks★ 13k52% same
- ArcReel/ArcReel★ 6.3k52% same
- pollinations/pollinations★ 5.3k52% same
- withcoral/coral★ 4.9k52% same
- bestofjs/bestofjs★ 3.1k52% same
- The-Vibe-Company/claude-code-controller★ 2.4k18% same
115 more not listed
Wrote their own version · 68
- GreyDGL/PentestGPT★ 16ksame name
- PX4/PX4-Autopilot★ 13ksame name
- vinvcn/mattpocock-skills-zh-CN★ 5.5ksame name
- AUTO-MAS-Project/AUTO-MAS★ 774same name
- stevesolun/ctx★ 583same name
- devcxl/mattpocock-skills-zh★ 522same name
- Tiberriver256/mcp-server-azure-devops★ 399same name
- ninehills/skills★ 280same name
- loulanyue/skills★ 231same name
- heyongjun666/AICU-Graph★ 200same name
58 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository25 other files it gives its agents.
- AGENTS.mdAGENTS.md
- humanizer-zhSkill
- backend-patternsSkill
- frontend-patternsSkill
- security-reviewSkill
- fastapiSkill
- python-projectSkill
- ts-backendSkill
- ts-frontendSkill
- readmeSkill
- codebase-designSkill
- code-reviewSkill
- coding-standardsSkill
- domain-modelingSkill
- fixSkill
- living-docs-governanceSkill
- planSkill
- prototypeSkill
- publish-ticketsSkill
- resilienceSkill
- session-handoffSkill
- specSkill
- systematic-debuggingSkill
- tddSkill
- verificationSkill
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 6 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 71 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 36
After each round of answers, recompute the frontier: settled decisions push the frontier outward and unblock the questions that depended on …
- Distinctive: line 54
If the user ends the interview before the frontier is empty, treat every open decision as unresolved and continue to the handoff with its …
- Distinctive: line 79
Never present a recommended answer as decided, and never answer for the user.
- Distinctive: line 80
Never block a round on an unfinished fact lookup.
- Distinctive: line 81
If the whole tree resolves in one round, re-examine each top-level decision for unvisited downstream consequences — failure, rollout, …
- Distinctive: line 82
Never turn the handoff into a specification: no requirements, invariants, acceptance criteria, or implementation steps.
“Common” is measured: kept by at least 6 in 10 of the 71 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Grilling
Interview the user relentlessly until you reach a shared understanding, then stop with a decision handoff. Grilling exhausts the decision tree and produces the handoff only — the behavior contract itself (requirements, invariants, acceptance criteria) is written in the spec stage that follows (the spec skill when loaded).
Workflow
1. Map the design tree
Restate the subject of the interview and map it as a design tree: every decision branches into the decisions that hang off it. Mark which decisions depend on which, so no question is asked before its prerequisites are settled.
Completion criterion: the root decision is stated, and every listed decision has its dependency edges identified.
2. Ask the frontier in rounds
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 have not 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. A question whose answer depends on another question still open in this round belongs to a later round, not this one.
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>
➡️ <your recommended answer>After each round of answers, recompute the frontier: settled decisions push the frontier outward and unblock the questions that depended on them. Ask the next round.
Completion criterion: every round asked only frontier questions, and no dependency edge was skipped or silently assumed.
3. Split facts from decisions
Finding facts is your job, never the user's. When a frontier question needs a fact from the environment — filesystem, tool output, dependency versions, repository state — look it up yourself. If the current session can dispatch subagents, dispatch parallel lookups; if it cannot, explore in the main agent. Either way, do not block the round: a running lookup is an unsettled prerequisite, so only the questions downstream of it wait; ask the rest of the frontier now.
The decisions are the user's. Put each to them and wait. A recommendation is not an approval: an unanswered question stays open, and no answer may be supplied on the user's behalf. When the user decides, record the chosen option and the options they rejected, with the reason given.
When a lookup fails or a fact is unavailable (missing tool, missing permission, unreachable upstream), record it as an unresolved prerequisite instead of guessing. If the fact stays unavailable, the questions downstream of it cannot be settled now: propose ending the interview and carrying them as blockers in the handoff.
Completion criterion: every decision in the tree is either user-answered or explicitly unresolved with its unblocking condition named; every fact a decision depends on is either agent-verified with a recorded source or carries the same unresolved marker.
4. Confirm shared understanding
The interview is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Recite the approved decisions and the unresolved items back to the user and ask them to confirm the shared understanding.
If the user ends the interview before the frontier is empty, treat every open decision as unresolved and continue to the handoff with its blockers.
Completion criterion: the user explicitly confirms the decision set, or the interview is explicitly ended with every open decision recorded as unresolved.
5. Return the decision handoff and stop
Once the user confirms, return the handoff once:
Producer: grilling (decision-tree stress test)
Approved decisions: <each decision with the option chosen>
Rejected options: <the options turned down, with the reason given>
Unresolved blockers: <decisions the user could not answer or facts that were unavailable, each with the condition that would unblock it>
Source authority: <paths, versions, or links that supported the verified facts>
Artifact pointers: <entry points the next stage should read: draft notes, related ADRs, CONTEXT.md, upstream issues>
Next: <the next stage, normally spec — with the invocation that starts it (/skill:spec)>Return the handoff and stop. Do not start writing the spec, plan, or implementation — requirements, invariants, and acceptance criteria belong to the spec stage, not this handoff. A later decision change invalidates this handoff: re-grill, or let the spec record an explicit revision.
Completion criterion: the handoff carries every field plus the next stage, and no contract, plan, or code artifact was produced.
Guardrails
- One question set per round; never ask a downstream question before its prerequisite is answered.
- Never present a recommended answer as decided, and never answer for the user.
- Never block a round on an unfinished fact lookup.
- If the whole tree resolves in one round, re-examine each top-level decision for unvisited downstream consequences — failure, rollout, migration, cost, security — before declaring the frontier empty.
- Never turn the handoff into a specification: no requirements, invariants, acceptance criteria, or implementation steps.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

