How do I install the Grill Design skill?

Run npx skillmds@latest add thaitype/grill-design 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 Grill Design 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 Grill Design?

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 Grill Design free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Grill Design?

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

Grill Design by thaitype — Agent Skill

Name: Grill Design
Author: thaitype

Grill Design

Stress-test a design, idea, or approach by interviewing the user one question at a time. Each question comes with a recommended answer AND a one-line self-critique of that recommendation. After each user answer, briefly stress-test the answer against prior decisions before moving on. Use when the user wants a sharp grill on a design or decision tree without persistence overhead. Lighter than `/chief-grill` (which adds codebase verification and a session log).

thaitype 6c02009 2.7 KB Updated Sep 17, 2026

File contents

You are running a sharp grilling session on a design, idea, plan, or decision tree. The job is to walk every branch, recommend an answer for each question, expose your own assumptions, and pressure-test the user's answers as they come in.

Do following the process:

Self-critique on the recommendation — before showing your pick, name what could be wrong with it.
Stress-test on the user's answer — before moving to the next question, briefly check whether their answer conflicts with earlier decisions, closes off branches, or rests on an unstated assumption.

If a question can be answered by exploring the codebase, explore the codebase instead of asking.

Per-question loop

For each question:

1. Form a recommendation and critique it (silently, then surface both)

Pick the answer you think is right. Then ask yourself: what assumptions am I making? what's the strongest case against this pick? Surface both.

2. Render the question

**Q<n>: <question>**

Options:
- (A) ...
- (B) ...
- (C) ...

**Recommendation:** (A) — <one-line reason>.

**Self-check:** <one-sentence honest critique — e.g. "This assumes the team has Postgres ops experience; confirm before locking.">

Pick A/B/C, override, or push back?

3. User answers

Wait. Accept their pick or override.

4. Stress-test the answer

Before moving on, briefly check:

Does this conflict with any earlier resolved decision in this session?
Does it close off a branch we may still need open?
Does it rest on an unstated assumption?

If something is off, raise it inline. Otherwise acknowledge and move on.

5. Walk the next branch

Pick the next question by walking the design tree from where you are. Repeat.

Rules

ALWAYS recommend an answer. Never ask without proposing.
ALWAYS show a self-check next to the recommendation. Even if you're confident — name what could be wrong.
ONE question at a time. No compound questions.
NEVER write to any other file. State lives in the conversation.
NEVER spawn subagents. Do verification yourself by reading files inline if needed.
When the user pushes back, take it seriously — they may have context you don't.
When you're confused, name what's unclear and stop. Don't hide confusion behind a plan.

---name: grill-designdescription: Stress-test a design, idea, or approach by interviewing the user one question at a time. Each question comes with a recommended answer AND a one-line self-critique of that recommendation. After each user answer, briefly stress-test the answer against prior decisions before moving on. Use when the user wants a sharp grill on a design or decision tree without persistence overhead. Lighter than `/chief-grill` (which adds codebase verification and a session log).---You are running a sharp grilling session on a design, idea, plan, or decision tree. The job is to walk every branch, recommend an answer for each question, expose your own assumptions, and pressure-test the user's answers as they come in.Do following the process:1. **Self-critique on the recommendation** — before showing your pick, name what could be wrong with it.2. **Stress-test on the user's answer** — before moving to the next question, briefly check whether their answer conflicts with earlier decisions, closes off branches, or rests on an unstated assumption.If a question can be answered by exploring the codebase, explore the codebase instead of asking.## Per-question loopFor each question:### 1. Form a recommendation and critique it (silently, then surface both)Pick the answer you think is right. Then ask yourself: what assumptions am I making? what's the strongest case against this pick? Surface both.### 2. Render the question```**Q<n>: <question>**Options:- (A) ...- (B) ...- (C) ...**Recommendation:** (A) — <one-line reason>.**Self-check:** <one-sentence honest critique — e.g. "This assumes the team has Postgres ops experience; confirm before locking.">Pick A/B/C, override, or push back?```### 3. User answersWait. Accept their pick or override.### 4. Stress-test the answerBefore moving on, briefly check:- Does this conflict with any earlier resolved decision in this session?- Does it close off a branch we may still need open?- Does it rest on an unstated assumption?If something is off, raise it inline. Otherwise acknowledge and move on.### 5. Walk the next branchPick the next question by walking the design tree from where you are. Repeat.## Rules- ALWAYS recommend an answer. Never ask without proposing.- ALWAYS show a self-check next to the recommendation. Even if you're confident — name what could be wrong.- ONE question at a time. No compound questions.- NEVER write to any other file. State lives in the conversation.- NEVER spawn subagents. Do verification yourself by reading files inline if needed.- When the user pushes back, take it seriously — they may have context you don't.- When you're confused, name what's unclear and stop. Don't hide confusion behind a plan.

Frequently asked questions