菜单
Creates a PRD through structured clarification, codebase exploration, and module design, then saves it as a local Markdown file. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Propose a Conventional Commit message for the staged changes, then commit only after confirmation.
Creates an implementation plan from a PRD or a task description. Researches codebase context, clarifies ambiguities, and outputs a phased plan with vertical slices and acceptance criteria. Use when the user wants to plan a feature, break down a PRD, create an implementation plan, or mentions "tracer bullets".
Dispatches multiple subagents in parallel for 2+ confirmed-independent, each-substantial failures or investigation targets that share no state or sequential dependency. Use when the work splits cleanly and each part is big enough to justify a separate agent.
Decides how to integrate a finished branch — merge, pull request, keep, or discard — once tests pass. Use when implementation work on a branch is complete and you need to decide what happens to it next.
Acts on code-review feedback (from a human, a PR comment, or an AI reviewer) by verifying each item against the codebase before implementing, and asking when items are unclear. Use when receiving code review comments, PR feedback, or suggestions from another reviewer — before implementing any of them.
Investigates a bug, test failure, or unexpected behavior root-cause-first before proposing a fix. Use when a test fails, an error shows up in logs or CI, or something behaves unexpectedly and the next step would otherwise be guessing at a patch.
基于 SOC 职业分类
| name | write-prd |
| description | Creates a PRD through structured clarification, codebase exploration, and module design, then saves it as a local Markdown file. Use when user wants to write a PRD, create a product requirements document, or plan a new feature. |
Skip a step only when its output already exists (e.g. the clarification is done or the codebase is already understood). Never skip exploration.
Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
Scope triage: If the request bundles multiple independent subsystems/features (each could ship and be useful on its own), stop before spending clarification rounds. Help the user split it into separate PRDs — each gets its own PRD and, later, its own plan. Only continue with this workflow once you're working a single, cohesive PRD's worth of scope.
Explore the repo to verify their assertions and understand the current state of the codebase.
Resolve unknowns through 1–3 rounds of structured questions, following the canonical clarification question rules.
Once ambiguities are resolved, propose 2–3 candidate solution approaches with their trade-offs (effort, risk, reversibility, fit with the existing codebase). Lead with a recommendation and your reasoning for it. Get the user to pick one — or steer a hybrid — before moving on to module design.
Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
A deep module hides substantial functionality behind a small, testable interface that rarely changes — see interface design.
Present the module design as part of the flow — do not block on a separate confirmation. Decide the test scope yourself based on the design; raise it as a clarification question (within the rounds from step 3) only if it is a genuine judgment call the codebase cannot answer.
Once you have a complete understanding of the problem and solution, write the full PRD in one pass — no section-by-section confirmation gates. The user reviews the finished document and requests changes there; that is cheaper and more informed than approving fragments. Scale the depth of each section to the complexity of the feature; a small feature doesn't need a long-winded Problem Statement.
Use the template below and save it to docs/prds/prd-<name>.md (create the
directory if it doesn't exist). Use a short kebab-case name derived from the
feature (e.g. prd-user-onboarding.md).
# PRD: <Feature Name>
## Problem Statement
The problem that the user is facing, from the user's perspective.
## Solution
The solution to the problem, from the user's perspective.
## User Stories
A numbered list of user stories with at least one story per actor and one per
distinct capability the Solution names — no capability in the Solution section
is left without a matching story. Each user story is in the format:
1. As an <actor>, I want a <feature>, so that <benefit>
## Implementation Decisions
A list of implementation decisions that were made. This can include:
- The modules that will be built/modified
- The interfaces of those modules that will be modified
- Technical clarifications from the developer
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions
Do NOT include specific file paths or code snippets. They may end up being
outdated very quickly.
## Testing Decisions
A list of testing decisions that were made. Include:
- A description of what makes a good test (only test external behavior, not
implementation details)
- Which modules will be tested
- Prior art for the tests (i.e. similar types of tests in the codebase)
## Out of Scope
A description of the things that are out of scope for this PRD.
## Further Notes
Any further notes about the feature.