hl-grill

Installation
SKILL.md

Grill

Input: [idea, problem, plan, or path] [--docs | --gaps [--write]]

Reach a shared understanding of what to build, before any plan or code. The input is the idea; if empty, the idea under discussion. Nothing to work on: ask what the user wants to build, and stop. A written plan or spec is the idea: the decisions it already settles are facts; quote them instead of asking. Never modify the source plan unless the user asks.

Facts first

Facts are your job; decisions are the user's. Before asking, look up what the code, docs, and tools answer; use subagents for independent lookups when available. A question whose answer you can read is not a question. A running lookup blocks only the questions that depend on it. When the user states how something works and the code disagrees, show both and ask which is right.

Check whether existing code or tools already meet the need. Fully met: the first line, in place of the round header, says how and names the defining file; then ask only whether it meets the need (recommended: yes). Weaknesses you notice that the user did not ask about do not make it partly met: list each in one line, with no options. Partly met: under the round header, say what exists and what is missing, with locations; the missing part becomes the idea.

Design tree

Keep a tree of decisions internally: each decision branches into the decisions that depend on it. Show it only when the user asks. The root is the outcome and who benefits. Below it, these angles become questions only where the input leaves them open and the answer changes what gets built: one case that must work and one that must not, the smallest useful version and non-goals, the signal that proves it done, the failure cases that change scope (empty, duplicate, concurrent, stale, partial, hostile). They are angles, not a checklist.

Ask at the user's level (product, technical, or operational). Record finer how-to (sort order, paging, naming) as an assumed decision for planning. Test a vague or overloaded term with a concrete scenario ("an order is half shipped and the user cancels: what happens?"; "account": customer or user?).

A solution-shaped request ("add a cache") is one option for an outcome. When the request, code, or docs state that outcome, go to an options question with the stated solution as one option. Otherwise ask for the outcome first.

Installs
2
GitHub Stars
2
First Seen
Oct 13, 2026