Menu
Interview the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way is clear. On ticket close, may offer ADRs (promotion into docs/adr/) when ADR-POLICY criteria hold.
Sharpen a plan or design against this codebase via grilling + domain-modeling (CONTEXT.md / ADR offers). May offer /wayfinder when fog appears. Invoke with `/grill-with-docs`.
Applies Dockerfile, Docker Compose, BuildKit, and container security patterns for local development and hardened deployable images. Use when authoring Dockerfiles or compose files, wiring secrets (runtime vs build-time), reproducible bases, PID 1 and healthchecks, volumes and networking, supply-chain hygiene, or troubleshooting compose stacks.
Routes Go work to the right reference guides and conventions for the task. Use when working on Go architecture, implementation, refactoring, concurrency, error handling, testing, performance, or code review.
PostgreSQL database patterns for query optimization, schema design, indexing, and security. Use when writing SQL or migrations, designing schemas, troubleshooting slow queries, implementing Row Level Security, tuning connection pooling, or reviewing database changes. Based on Supabase-leaning Postgres practice.
Applies Python idioms, PEP 8 norms, typing, packaging, concurrency, tooling, and performance discipline to everyday Python code. Use when writing, reviewing, refactoring, or packaging Python; when the user names type hints, dataclasses, pytest, ruff/black/mypy, asyncio, concurrency, EAFP vs LBYL, or Python idioms; or asks for a Python-specific code-quality pass.
| name | grilling |
| description | Interview the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases. |
Interview the user relentlessly until you reach a shared understanding. Map this as a design tree: every decision branches into the decisions that hang off it.
Work the tree in rounds. The frontier is every decision whose prerequisites are already settled — the questions you can ask now without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
Each round the user answers reshapes the tree — settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a later round, not this one.
Finding facts is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a Task subagent to find it — don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — ask the rest of the frontier now. The decisions are the user's — put each to them and wait.
For Task model / subagent_type routing, follow cursor-task-workflow.md (enum probe, Composer lane for parallel explore/survey workers). Do not copy routing tables into this skill.
The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.
If the user (or their AGENTS.md, CLAUDE.md, or user/rules) says to ask one question at a time when grilling, honor that and fall back to the old one-at-a-time rhythm for this session.
When a frontier round includes discrete decisions with a small set of clear options (about 2–6), prefer the AskQuestion tool: put all such decisions from the current frontier into one AskQuestion call (questions[]), so the user can answer the round in the structured UI.
Put free-form frontier items (open-ended design explanations, pasted logs, custom workflows) in the same round as numbered chat prompts with your recommended answer — do not force them into multiple-choice.
Do not start the next round until both the AskQuestion answers and the free-form replies for this frontier are in.
If AskQuestion is unavailable in the current environment, ask the whole frontier (discrete and free-form) as a numbered chat list with recommended answers.
If a question can be answered by exploring the codebase, explore the codebase instead (via Task when it shouldn't block the rest of the frontier).
