How do I install the Workflow Grilling skill?

Run npx skillmds@latest add kensaurus/workflow-grilling in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Workflow Grilling safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Workflow Grilling?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Workflow Grilling free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Workflow Grilling?

kensaurus (@kensaurus) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Workflow Grilling by kensaurus — Agent Skill

Name: Workflow Grilling
Author: kensaurus

Workflow Grilling

Grill the user relentlessly about a plan, decision, or idea — one question at a time — until shared understanding is reached. Use when the user says "grill me", "stress-test this plan", "interview me about this", "poke holes in this", "challenge my thinking", or before committing to a non-trivial design.

kensaurus Updated Sep 21, 2026 8 repo stars

File contents

Grilling

Degree of freedom: MIXED. Which branch to walk and how hard to challenge [HIGH freedom]; one-question-at-a-time, recommend-an-answer, and no-act-until-confirmed [LOW freedom — run exactly].

The most common failure mode in software work is misalignment: the agent builds what it thinks was asked. A grilling session closes that gap before any work starts. Adapted from mattpocock/skills (MIT).

Interview the user relentlessly about every aspect of the plan, decision, or idea until you reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one by one.

How to reason

Surface — what decision or vague term is actually in play?
Depend — which upstream choice must land before this one?
Recommend — your answer and why, in one sentence
Confirm — wait; log the user's words, not yours

Worked example

Surface: "add AI chat to the dashboard" — "AI" and "dashboard" are both overloaded. Depend: audience (internal ops vs customers) gates model, retention, and auth. Recommend: internal ops assistant on existing /dashboard — cheapest test of the idea. Confirm: user picks customers instead; log that, then ask the next downstream (retention vs ephemeral).

Self-critique before reporting

One question — the last turn asked exactly one thing
Recommendation present — every question included a default the user can accept
Facts looked up — nothing askable from the repo was asked
Right owner — session over → design-prd / workflow-spec-tdd / a plan-*; do not start building here

Rules of the session [LOW freedom — run exactly]

One question at a time. Ask a single question, then wait for the answer before continuing. Asking multiple questions at once is bewildering.
Recommend an answer with every question. State your recommended answer and why, so the user can accept it with a single word or push back.
Facts are yours; decisions are theirs. If a fact can be found by exploring the environment (filesystem, git history, docs, running commands), look it up instead of asking. Decisions belong to the user — put each one to them and wait.
Resolve dependencies in order. When one decision hinges on another, surface the upstream decision first.
Challenge vague terms. When the user uses an overloaded or fuzzy word, propose a precise one (see docs-domain-modeling when the vocabulary itself needs fixing).
Do not act until confirmed. No edits, no scaffolding, no "getting a head start". The session ends when the user confirms shared understanding — then summarize the decisions made and hand off to the appropriate skill (workflow-spec-tdd, design-prd, plan-*).

Output [LOW freedom — run exactly]

Close the session with a compact decision log: each decision on one line, in the user's confirmed vocabulary. This log is the input to the spec or plan that follows — offer to carry it into design-prd or /plan.

---name: workflow-grillingdescription: Grill the user relentlessly about a plan, decision, or idea — one question at a time — until shared understanding is reached. Use when the user says "grill me", "stress-test this plan", "interview me about this", "poke holes in this", "challenge my thinking", or before committing to a non-trivial design.license: MIT---# Grilling**Degree of freedom: MIXED.** Which branch to walk and how hard to challenge`[HIGH freedom]`; one-question-at-a-time, recommend-an-answer, andno-act-until-confirmed `[LOW freedom — run exactly]`.> The most common failure mode in software work is misalignment: the agent builds> what it *thinks* was asked. A grilling session closes that gap before any work> starts. Adapted from [mattpocock/skills](https://github.com/mattpocock/skills) (MIT).Interview the user relentlessly about every aspect of the plan, decision, or ideauntil you reach a shared understanding. Walk down each branch of the decisiontree, resolving dependencies between decisions one by one.## How to reason1. **Surface** — what decision or vague term is actually in play?2. **Depend** — which upstream choice must land before this one?3. **Recommend** — your answer and why, in one sentence4. **Confirm** — wait; log the user's words, not yours## Worked example> **Surface:** "add AI chat to the dashboard" — "AI" and "dashboard" are both overloaded.> **Depend:** audience (internal ops vs customers) gates model, retention, and auth.> **Recommend:** internal ops assistant on existing `/dashboard` — cheapest test of the idea.> **Confirm:** user picks customers instead; log that, then ask the next downstream (retention vs ephemeral).## Self-critique before reporting- **One question** — the last turn asked exactly one thing- **Recommendation present** — every question included a default the user can accept- **Facts looked up** — nothing askable from the repo was asked- **Right owner** — session over → `design-prd` / `workflow-spec-tdd` / a `plan-*`; do not start building here## Rules of the session [LOW freedom — run exactly]1. **One question at a time.** Ask a single question, then wait for the answer before continuing. Asking multiple questions at once is bewildering.2. **Recommend an answer with every question.** State your recommended answer and why, so the user can accept it with a single word or push back.3. **Facts are yours; decisions are theirs.** If a *fact* can be found by exploring the environment (filesystem, git history, docs, running commands), look it up instead of asking. *Decisions* belong to the user — put each one to them and wait.4. **Resolve dependencies in order.** When one decision hinges on another, surface the upstream decision first.5. **Challenge vague terms.** When the user uses an overloaded or fuzzy word, propose a precise one (see `docs-domain-modeling` when the vocabulary itself needs fixing).6. **Do not act until confirmed.** No edits, no scaffolding, no "getting a head start". The session ends when the user confirms shared understanding — then summarize the decisions made and hand off to the appropriate skill (`workflow-spec-tdd`, `design-prd`, `plan-*`).## Output [LOW freedom — run exactly]Close the session with a compact decision log: each decision on one line, in theuser's confirmed vocabulary. This log is the input to the spec or plan thatfollows — offer to carry it into `design-prd` or `/plan`.

Frequently asked questions