菜单
Interview the user and explore the code to write a spec (PRD) — what to build and why. Use when starting a new feature and you need to capture the problem, solution, and requirements before planning how to build it.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | draft-spec |
| description | Interview the user and explore the code to write a spec (PRD) — what to build and why. Use when starting a new feature and you need to capture the problem, solution, and requirements before planning how to build it. |
Create a Product Requirements Document through user interview and codebase exploration. The PRD captures what to build and why — implementation planning (modules, phases, vertical slices) is handled separately by /decaf-plan:draft-plan.
Ask the user for a detailed description of the problem they want to solve and any potential ideas for solutions.
Skip this step if the user already provided a description in their prompt.
If the codebase has not already been explored in this conversation, explore it to understand the current state — existing architecture, relevant modules, tech stack, and anything related to the problem being described.
Skip this step if the codebase is already in context from prior exploration.
Use /decaf-plan:grill-me to interview the user about every aspect of the problem and proposed solution until reaching a shared understanding.
Skip this step if the user was already grilled on this topic in the current conversation (e.g., a prior /decaf-plan:grill-me session covered the same ground). Use judgement — if the grill-me session was on a related but different aspect, a brief follow-up interview may still be needed to fill gaps specific to the PRD.
@../../conventions/work-items.md
Detect the available system and confirm with the user.
Draft the PRD using the template below. Adapt the sections to the project type — not all projects have routes, schemas, or APIs.
The spec includes a top-level ## Acceptance section — the behaviors that mean the feature is built, runnable where possible. (Phase- and feature-level acceptance is refined later by draft-plan and breakdown-phase.)
@../../conventions/acceptance-criteria.md
Show the draft to the user for review before creating the work item. Iterate if the user has feedback.
Create the work item using the conventions in work-items.md:
PRD: <Feature Name>For markdown output, write to ./plans/<feature-name>-prd.md.
The problem that the user is facing, from the user's perspective.
The solution to the problem, from the user's perspective.
A numbered list of user stories. Cover all meaningful user-facing behaviors, but stay focused — don't enumerate trivial edge cases. Each user story should be in the format of:
Key decisions that constrain or guide implementation. Adapt to the project type — examples include:
Do NOT include specific file paths or code snippets — they become outdated quickly. Focus on durable decisions that will still be relevant when implementation begins.
The top-level checks that mean this feature is built. Runnable where possible; prose tagged [manual] otherwise (see acceptance-criteria.md).
<command> — expect: Things explicitly excluded from this PRD.
Any additional context, open questions, or follow-up items.
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).