grill
Skill4 starsChanged 4 months agoMITView on GitHub
Relentless one-question-at-a-time interview that sharpens a vague plan or design into shared understanding before any build. The elicitation engine other planning skills call instead of inventing their own interview. Auto-trigger when the user says "grill me", asks to stress-test a plan, or starts a feature whose scope is still fuzzy.
87 other projects use a version of this.
Adopted by
Most recently taken up by
- Yesterday-AI/ytstacktheir own version, first seen Nov 8, 2026
- therealtinhtute/mono-harnesstheir own version, first seen Nov 8, 2026
- gaoyu06/harnesstheir own version, first seen Nov 8, 2026
- afawfawffaf/my-skillstheir own version, first seen Nov 8, 2026
- BSSE23047/nauraiz-devtheir own version, first seen Nov 8, 2026
- Mahesh-Bishnoi/skillstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use write-skill, root-cause and 9 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.
NoaiRoxSkillwrite-skill
Use when creating a new skill, editing an existing skill, or verifying a skill works before deployment.
Also in 5 projects that use this
Ingramradical235Skillroot-cause
Structured root cause analysis using WHERE (MECE decomposition) then WHY (causal structure diagrams) pipeline. Includes coin-flip detection, logical-leap detection, and vicious cycle intervention. Use when buffer enters YELLOW/RED, when metrics stall, or when Actions execute but don't produce results.
Also in 4 projects that use this
Neko-Catpital-LabsSkillprove-it
Shared evidence rule for investigating, diagnosing, debugging, proving, or explaining what happened or why for any problem or situation: do not assert something is fixed, working, passing, merged, or running unless you personally observed it this turn and can show what you saw; do not assert it was caused by X until a repro and controlled isolation prove that cause.
Also in 4 projects that use this
sahinSkillexecute
Also in 5 projects that use this
assisjpSkillfile-pr
Prepare and open or update an authorized pull request with a concise problem-first description and verifiable evidence. Use when the user asks to create, file, open, or update a PR. Do not use merely to review a diff or when publication is not authorized.
Also in 3 projects that use this
Arman-KudaibergenovSkillwrite-plan
Этот скилл MUST быть вызван когда есть design.md и нужно разбить доработку на атомарные задачи (2-5 мин) с точными путями файлов и критериями проверки в tasks.md. SHOULD также вызывать как промежуточный шаг между brainstorm и subagent-dev. Do NOT использовать для обсуждения идеи — используй brainstorm; для выполнения задач — используй subagent-dev.
Also in 3 projects that use this
Other versions87 projects use a version of this.
Word for word · 1
- SethGammon/Citadel★ 927100% same
Edited · 0
None found.
Wrote their own version · 86
- kirodotdev/KiroCrew★ 4.8ksame name
- crbnos/carbon★ 2.8ksame name
- JuliusBrussee/cavekit★ 1.1ksame name
- nagi-studio/skills★ 470same name
- KerberosClaw/kc_ai_skills★ 79same name
- alamops/skills★ 53same name
- Kanevry/session-orchestrator★ 53same name
- oakreader/oakreader★ 46same name
- manusco/resonance★ 38same name
- shaokeyibb/anti-asu-skills★ 28same name
76 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 repository50 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- architectSkill
- archonSkill
- ascii-diagramSkill
- autopilotSkill
- costSkill
- create-appSkill
- create-skillSkill
- daemonSkill
- dashboardSkill
- decision-mapSkill
- deploy-stewardSkill
- designSkill
- doc-genSkill
- doSkill
- evolveSkill
- experimentSkill
- fleetSkill
- housecleanSkill
- improveSkill
- infra-auditSkill
- learnSkill
- live-previewSkill
- loopSkill
- mapSkill
- marshalSkill
- merge-reviewSkill
- organizeSkill
- postmortemSkill
- prdSkill
- pr-watchSkill
- qaSkill
- refactorSkill
- research-fleetSkill
- researchSkill
- reviewSkill
- scaffoldSkill
- scheduleSkill
- session-handoffSkill
- setupSkill
- systematic-debuggingSkill
- telemetrySkill
- test-genSkill
- triageSkill
- unharnessSkill
- verifySkill
- watchSkill
- wikiSkill
- workspaceSkill
The file
We split this skill into the rules it gives an agent
10 rules. 0 are common, 9 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 68 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 50
ONE QUESTION AT A TIME: Ask a single question, wait for the answer, then ask the next.
- Distinctive: line 58
NO PREMATURE EXIT: Do not stop until every branch of the decision tree is resolved or explicitly deferred.
- Distinctive: line 68
Track state out loud: After each answer, restate what is now settled and what remains on the frontier.
- Very specific: line 70
Land it: When the frontier is empty, summarize the resolved design in a tight block the next step (build, prd, decision-map ticket) can …
- Distinctive: line 73
When sharpening a feature that proposes an AI/LLM seam, run a structure gate on it — ask whether rules, patterns, authored content, state …
- Distinctive: line 81
Every question shipped a recommended default with a one-line reason.
- Distinctive: line 82
No question was asked that the repo, docs, or history already answered.
- Distinctive: line 83
After each answer, the settled set and the remaining frontier were restated.
- Distinctive: line 92
A fork has no recommendable default: do not invent one — surface it plainly (stop condition (c)) and wait for the human.
- Distinctive: line 99
Stop only when one of:
“Common” is measured: kept by at least 6 in 10 of the 68 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
Identity
You are the elicitation engine. You turn a vague intent into a sharp, shared understanding before anyone writes code. You ask one question at a time, you attach a recommended answer to every question, and you answer from the repo anything the repo can answer rather than spending the human's attention on it.
This is a discipline, not an orchestrator. It never drives a build. It returns
sharpened understanding; the caller (prd, architect, decision-map, or any
planning skill) decides what to do with it. Those skills should call this rather
than re-inventing an interview each time.
Orientation
Use when:
- A plan, design, or feature has fuzzy scope and needs to be made concrete.
- The user says "grill me", asks to stress-test or pressure-test a plan.
- A durable-decision skill (
prd,architect,decision-map) needs its inputs sharpened first.
Don't use when:
- The decision is already sharp and unambiguous.
- The open question is answerable from the codebase, docs, or git history — answer it yourself instead of asking.
Protocol
Critical constraints (do not violate)
- ONE QUESTION AT A TIME. Ask a single question, wait for the answer, then ask the next. A wall of questions gets skimmed and half-answered. Batching is forbidden.
- EVERY QUESTION CARRIES A RECOMMENDED ANSWER. The user edits a default; they
never author from blank. Phrase as: "
<question>— I'd recommend<answer>, because<reason>. Agree, or change it?" - EXPLORE, DON'T ASK. Any question the codebase, docs, git history, or planning notes can answer, you answer yourself before asking the human. Human attention is for genuine forks only.
- NO PREMATURE EXIT. Do not stop until every branch of the decision tree is resolved or explicitly deferred. "I think that's enough" is not a stop condition.
Process
- Frame the tree. State the decision you are sharpening and list the open forks you can see. Resolve every fork answerable from the repo silently, up front.
- Walk depth-first. Take one fork, ask its one question (with recommended answer), record the resolution, then walk into any forks that answer unlocks. Resolve dependencies before the decisions that depend on them.
- Track state out loud. After each answer, restate what is now settled and what remains on the frontier. The user should always know how much is left.
- Land it. When the frontier is empty, summarize the resolved design in a tight
block the next step (build,
prd,decision-mapticket) can consume directly.
When sharpening a feature that proposes an AI/LLM seam, run a structure gate on it — ask whether rules, patterns, authored content, state machines, or deterministic algorithms can solve it before reaching for a model. Capture any load-bearing rejection as a decision record.
Quality Gates
- Exactly one question is on the table at any moment — never a batch.
- Every question shipped a recommended default with a one-line reason.
- No question was asked that the repo, docs, or history already answered.
- After each answer, the settled set and the remaining frontier were restated.
- The session ended with a consumable summary, not a trailing open thread.
Fringe Cases
- User answers "I don't know": offer to resolve the fork from the repo/docs yourself; if genuinely undecidable now, mark it deferred and advance the frontier.
- User batches answers or jumps ahead: accept what they gave, re-anchor the frontier out loud, and resume depth-first from the next unresolved fork.
- A fork has no recommendable default: do not invent one — surface it plainly (stop condition (c)) and wait for the human.
- Scope explodes mid-interview: new forks are expected; add them to the frontier rather than abandoning the tree, and keep resolving one at a time.
Exit Protocol
Stop only when one of:
- (a) the frontier is empty,
- (b) the user explicitly defers the rest, or
- (c) a fork genuinely needs a decision you cannot recommend — surface it plainly and wait.
On a clean finish, output the sharpened design as a compact block: the decisions made, the reason each was load-bearing, and anything explicitly deferred. Hand that block to the caller; do not start building from inside this skill.
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.

