메뉴
Interview the user one decision at a time to stress-test a plan or design until it holds up. Use when you want to pressure-test an idea, find the weak points in a plan, or be grilled on a design before committing to it.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | grill-me |
| description | Interview the user one decision at a time to stress-test a plan or design until it holds up. Use when you want to pressure-test an idea, find the weak points in a plan, or be grilled on a design before committing to it. |
Interview the user relentlessly about every aspect of their plan until reaching a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.
If a question can be answered by exploring the codebase, explore the codebase instead.
If no plan or design is present in the conversation, stop and ask the user to provide one before proceeding.
Before diving deep, map the full design space with a breadth-first pass.
1a. Identify areas. Read the plan and identify all major areas, subsystems, or concerns that need decisions. An "area" is a cluster of related decisions — e.g., "auth model", "data migration", "API surface", "UI flow", "error handling", "deployment".
1b. Present the map. Show the user the areas you've identified:
## Design Space
I see N major areas to explore:
1. **Area name** — brief description of what needs to be decided
2. **Area name** — brief description
...
Ask 1-2 clarifying questions per area if needed to confirm you've understood the scope correctly. Add any areas the user identifies that you missed.
1c. Assess scope. If there are 5 or more areas, acknowledge the scope is large and ask the user how to proceed:
AskUserQuestion with:
- question: "This is a broad design space. How would you like to proceed?"
- options:
- label: "Drill into all", description: "Work through every area depth-first (long session)"
- label: "Prioritize", description: "Pick the highest-risk areas to explore now, defer the rest"
- label: "Split sessions", description: "Group areas and tackle each group in a separate session"
If the user chooses "Prioritize", ask them which areas to focus on. Mark the rest as deferred in the progress file.
If the user chooses "Split sessions", ask how to group the areas, then proceed with the first group only. Record the other groups in the progress file as planned follow-up sessions.
If fewer than 5 areas, proceed directly — no need to ask.
For each area (in the order agreed with the user, or by priority if not specified):
### Exploring: [Area Name]Maintain a running summary in a local file (.decaf/grill-me/<short-descriptive-name>.md) with this structure:
# Grill Session: <topic>
## Areas
| # | Area | Status | Branches |
|---|------|--------|----------|
| 1 | Auth model | ✅ Done | 4/4 resolved |
| 2 | API surface | 🔄 In progress | 2/5 resolved |
| 3 | Data migration | ⏳ Pending | 0/3 resolved |
| 4 | Deployment | 📋 Deferred | — |
## Resolved Decisions
### 1. Auth model
- **1.1 Token format**: JWT with short-lived access tokens (15min) + refresh tokens
- **1.2 Session storage**: Redis, not database — latency matters more than durability here
- ...
### 2. API surface
- **2.1 Versioning**: URL path prefix (/v1/, /v2/)
- ...
## Open Branches
### 2. API surface
- 2.3 Pagination strategy — cursor vs offset?
- 2.4 Rate limiting approach
- 2.5 Error response format
### 3. Data migration
- 3.1 Migration strategy — big bang vs incremental?
- 3.2 Rollback approach
- 3.3 Data validation during migration
## Deferred Areas
### 4. Deployment
- Reason: Lower risk, can be decided after API surface is stable
Update this file as decisions are reached. Before asking the next question, check the file to avoid revisiting settled topics.
After each area is fully resolved, ask the user whether to continue to the next area or wrap up.
When all areas are resolved (or the user chooses to wrap up with deferred areas remaining):
AskUserQuestion with:
- question: "Create follow-up work items for the N deferred areas?"
- options:
- label: "Yes", description: "Create work items for deferred areas"
- label: "No", description: "Just keep them noted in the session file"
If the user chooses "Yes":
@../../conventions/work-items.md
Detect the available tracking system and create one work item per deferred area, with the area description, known context, and open questions as the body. Title format: Investigate: <area name>.
Run parallel code review agents and consolidate findings into a unified report
Capture a follow-up idea or task as a work-item draft without interrupting current work. Use to quickly jot down something you think of mid-task so it gets tracked. Works with nibs, GitHub, Azure DevOps, or a Markdown fallback.
Take an under-specified work item and make it actionable — resolve its open questions through a short interview grounded in the code, and give it acceptance criteria. Use on a captured draft, or any item too vague to start on.
Reconcile what was built against what was planned, record decisions and deviations, close the item (a single phase or a whole plan), and file follow-ups for deferred work. Use after finishing a phase or plan to keep planned and actual from drifting apart.
Orchestrate execution of MULTIPLE nibs in one run. Selects a queue, understands the nibs collectively (including how they fit together), then chooses the best execution mechanism per cluster — single series agent, parallel fan-out, scripted workflow, or agent team — and dispatches with ONE approval gate. Use when the user wants to work several nibs together (in parallel or series) rather than one at a time. Complements /decaf-build:auto-dev and /decaf-build:auto-tdd (which handle a single nib).
Direct development with automated review. Plans implementation, executes via subagent, then auto-reviews. Use for work that isn't test-driven (UI, config, styling, infrastructure, scaffolding).