Grilling
Use when stress-testing a plan, design, spec, or decision before building — or when the user says "grill me", "grilling", "interrogate this plan", "poke holes", "make it airtight/bulletproof", or wants every open decision surfaced and decided before a plan is written.From its SKILL.md
npx -y skills add PieroJF/forging-skill --skill grillingAssembled 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.
SKILL.md
3.3 KB, 694 tokens by cl100k_base, as published. Nobody here has run it
Grilling
Surface and resolve every open decision in a plan, design, or spec before any code or plan is written. The output is a complete decision-log that makes the plan airtight.
How to ask — every question takes this shape
Ask one decision at a time as a multiple-choice question. In Claude Code use the AskUserQuestion tool, one question per call. Each question:
- 2–4 concrete options, the recommended one first, its label ending
(Recomendado). - Each option's
descriptionstates its tradeoff/consequence, not a restatement of the label. - Choose the recommendation from: codebase conventions, the user's stack defaults, security/best practice — and give the one-line why in the recommended option.
multiSelect: truewhen the options are not mutually exclusive.- For code/shape/layout choices, put each candidate in a
previewso the user compares side-by-side. - The tool auto-adds "Other" — that is the user's escape hatch. Never collapse a real choice into a yes/no just to avoid enumerating options.
What to ask — sweep until dry
Walk the decision tree in dependency order: resolve a decision before the ones that depend on it; each answer reshapes and opens the next. If a question is answerable from the codebase, explore the codebase instead of asking.
Sweep every dimension — do not stop at the obvious ones:
scope & non-goals · data model · contracts/API · states & lifecycle · edge cases & failure modes · error handling · security & authz · performance & scale · dependencies/integrations · rollout & migration · testing · observability · cost
Grill irreversible / one-way-door decisions hardest. Surface every decision, including minor ones — do not pre-filter by importance.
Termination: after sweeping all dimensions, do one more pass — "what did the answers open? what's still ambiguous?" Stop only when a full pass surfaces no new decision, or the user calls it. Stopping after a handful of questions is failure.
Record — the decision-log is the airtight artifact
Maintain a running log; append one entry per resolved decision:
### <n> <decision> — <dimension>
Elegido: <option> [recomendado | override | ⚠ supuesto: usuario difirió]
Por qué: <one line>
Abre: <follow-up decisions, or "hoja">
When the user defers ("tú decide"), take the recommended option and mark it ⚠ supuesto — never leave a decision unresolved.
When the sweep is dry, hand the full decision-log to writing-plans to produce the plan/spec.
Red flags — STOP
- A question posed as open prose with no options → reshape into 2–4 options + a recommendation.
- More than one question in a single call → one decision per call.
- Stopping at the "important" few → sweep every dimension, loop until dry.
- A decision left open because the user was vague → take the recommended option, mark
⚠ supuesto. - Finishing without a decision-log → there is no airtight plan without it.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most plan spec skills give in 694 tokens
Counted across 1,099 of the 1,860 authors here whose files we hold, read 2026-08-07
- Ask one question at a timein 51 of 1099
- Break plans into vertical slicesin 29 of 1099, across 11 files
- Publish issues in dependency orderin 27 of 1099, across 9 files
- Iterate until user approves the breakdownin 25 of 1099, across 7 files
- Explore the repository to understand the codebase statein 24 of 1099, across 7 files
- Use domain glossary vocabularyin 23 of 1099, across 5 files
- Apply correct triage labels to published issuesin 23 of 1099, across 5 files
- Prefer AFK slices over HITLin 22 of 1099, across 7 files
- Write a specification before writing any codein 22 of 1099, across 14 files
- Write failing tests before implementation codein 22 of 1099, across 20 files
- Ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
- Respect existing architecture decision recordsin 20 of 1099, across 5 files
Said here and by no other author read
- resolve every open decision before writing a plan
- resolve decisions in dependency order
- sweep every dimension of the plan
- loop passes until no new decisions surface
- take the recommended option when the user defers
- maintain a running decision-log
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.