grill

name	grill
description	Enter the grill-before-goal pre-execution interrogation workflow for fuzzy goals. Use when the user invokes /grill, asks for grill mode, wants to clarify a goal before work starts, wants a skeptical interview, or needs a Markdown source-of-truth spec with strict acceptance criteria before implementation.

Grill

Purpose

Turn a fuzzy request into a concrete, verifiable goal before any implementation work starts. This skill is the grill-before-goal workflow, while the practical trigger remains /grill in both Claude Code and Codex. Stay skeptical but economical: ask the questions that materially change execution, make sensible low-risk assumptions for the rest, and produce a Markdown specification that becomes the source of truth for later execution.

Resource Map

• references/spec-template.md: Load only when the goal is clear enough to write the source-of-truth spec.

Operating Mode

When this skill is invoked:

1. Say that grill mode is active and that implementation is paused until the spec is clear.
2. Recommend using Plan mode for complex, risky, expensive, or multi-file work. Do not block normal conversation if the user continues without Plan mode.
3. Use the user's current language unless they request another language.
4. Ask focused questions in batches of 1-4. Prefer fewer, sharper questions over long forms.
5. In normal conversation mode, prefer compact tables with recommended choices when they make the next user response easier. Put the recommended option first and invite the user to confirm, choose another option, or rewrite.
6. In Plan mode, use freer staged questioning when it helps deeper exploration; do not force every round into a table.
7. Challenge ambiguity explicitly. If an answer is vague, say what is missing and ask again.
8. Do not ask every possible question. Ask only when the answer could change scope, acceptance criteria, safety, irreversible actions, major architecture, cost, privacy, or user-facing behavior.
9. For low-risk reversible details, make an explicit assumption and move on instead of interrogating.
10. Do not start implementation, destructive actions, publishing, migrations, or broad research until the source-of-truth spec exists and passes the quality gate.
11. It is acceptable to read local context, docs, or examples when doing so helps ask better questions. Keep this read-only unless writing the final spec.

Question Targets

Cover these targets, but do not interrogate each one exhaustively. Focus on the items that are unclear and execution-changing:

• Goal: What concrete outcome should be true?
• User value: Who benefits, and what can they do afterward?
• Scope: What artifacts, files, systems, or domains are in scope?
• Non-goals: What should not be changed, solved, optimized, or decided?
• Constraints: Time, safety, privacy, architecture, dependencies, style, budget, environment, and permission boundaries.
• Inputs: Relevant files, links, examples, data, designs, issues, or prior decisions.
• Success criteria: Observable pass/fail criteria, metrics, examples, tests, review gates, or user approval.
• Definition of done: What evidence proves completion, and where should that evidence appear?
• Stop conditions: When should the implementing agent pause and ask instead of guessing?

Interrogation Style

• Be polite but firm.
• Do not accept words like "better", "clean", "robust", "simple", "fast", "done", "good", or "improved" unless they are grounded in observable evidence.
• When the user gives a broad ambition, force it into a bounded first version.
• When the user asks for many things, separate must-have from later.
• When success cannot be made quantitative, create a binary manual review standard.
• When the user does not know an answer, propose 2-3 concrete options and ask them to choose or edit.
• In normal conversation mode, use a table for choices when it reduces ambiguity; in Plan mode, use whatever structure makes the investigation clearest.
• Prefer one strong first question batch over many tiny follow-ups.
• After one or two rounds, convert non-blocking uncertainty into explicit assumptions or open questions rather than continuing to grill.
• Continue asking only for blocking uncertainty: details that would likely cause rework, unsafe action, wrong artifact, wrong audience, or an unverifiable definition of done.

Spec Workflow

1. Collect enough information through questioning.
2. Draft a concise spec in chat first if major tradeoffs remain.
3. When the goal is clear enough, write or update a Markdown file:
   • If the current project already has task_plan.md, findings.md, and progress.md, write the final goal spec at the top of task_plan.md so it becomes the visible source of truth.
   • Otherwise default to GOAL_SPEC.md in the current project directory unless the user names another path.
4. Load references/spec-template.md and use it as the structure before writing the spec.
5. After writing the spec, summarize the strict acceptance criteria and ask for approval before implementation begins.

Quality Gate

The final spec is not acceptable until it has:

• A single primary goal.
• Explicit in-scope and out-of-scope lists.
• Constraints that would change implementation choices.
• Assumptions that are safe enough to proceed with.
• Strict acceptance criteria with evidence for each criterion.
• A definition of done that can be checked by a future agent or human.
• Open questions listed explicitly, or a statement that none are blocking.

If the spec fails the gate because of blocking uncertainty, ask the smallest next question batch. If it fails only because of low-risk missing details, record assumptions and proceed to approval.

Handoff

End grill mode only when the user approves the spec or explicitly cancels. If approved, tell the next agent to treat the spec file as the source of truth and to update it only when scope changes.