Synthesize the current conversation context and codebase understanding into a PRD, stored in docs/scratch/<NN>-<中文需求名称>/PRD.md。NN Record the order in which requirements entered the repository; use the unified terminology from CONTEXT.md for Chinese requirement names.
Organize the PRD by actual delivery units; do not presuppose a number or type. Delivery units use the boundary names already present in the project.
Process
1. Load project context
Use the already-loaded CONTEXT terminology and RULEs. If not yet loaded, follow the project knowledge protocol; if knowledge is unavailable, continue and state so truthfully.
2. Ask follow-up questions to align context
With the goal of producing a high-quality PRD, start the ask-me process. Confirmed conclusions serve as input for subsequent steps.
3. Determine and carry through the delivery scope
A delivery unit is a product-side, system, service, or channel that bears an independent responsibility in this requirement and will undergo changes. Identify it based on requirement goals, business processes, code entry points, and repository layout; when the facts are sufficient to determine it, adopt it directly, and when it cannot be reliably judged and different choices would significantly change the scope, ask to confirm.
4. Write the PRD file
When creating a new PRD, write to docs/scratch/<下一个两位序号>-<中文需求名称>/PRD.md; when updating an existing PRD, use the original path.
PRD template
# <功能名称> PRD
## Solution
<用一个段落从用户视角概括整体解决方案，不展开各交付单元的实现细节>
## Scope
### <交付单元 1>范围
- <该交付单元的交付内容与职责>
### <交付单元 N>范围
- <该交付单元的交付内容与职责>
### 涉及角色
- <使用或办理本功能的角色>
## Out of Scope
<本次明确不做的内容>
## User Stories
1. As a <角色>, I want <功能>, so that <收益>
2. ...
## Requirements
<!-- 先按业务能力分节，再在能力内展开实际涉及的交付单元。 -->
### <能力项 1>
#### <交付单元 1>逻辑
- <按该单元职责写清交互、业务规则、状态、数据、权限、接口或流程边界>
#### <交付单元 N>逻辑
- <按该单元职责写清交互、业务规则、状态、数据、权限、接口或流程边界>
#### 协作契约
- <仅在多个交付单元存在调用顺序、数据交换或失败处理时保留>
### <能力项 2>
...
## Implementation Decisions
### 锁定决策
| 决策项 | 决策值 | 来源 |
| --- | --- | --- |
| ... | ... | 用户确认 / RULE/ <其他> |
Writing approach
- Complete and reviewable: Reading only this document should be enough to judge what problem is being solved, who uses it, which business outcomes are delivered, and what is explicitly not being done. Retain all rules whose absence would change implementation branches, data definitions, state changes, permission scopes, or interface contracts.
- Rules are executable: Each rule can be judged right or wrong on its own: who, under what conditions, does what, and what the result is. When fields, dates, statuses, quantities, and permissions have definitions, write them to the value.
- Write boundaries together: Each capability covers the main flow, as well as situations that change the result, such as empty data, failures, lack of permission, and duplicate submissions.
- Synthesize rather than transcribe: The body is the finalized requirement, not excerpts of conversations, options, or reasoning processes.
- Locking is a contract: Implementation Decisions include only confirmed choices that will change delivery, and indicate their source.
- Product-level expression: Requirements describe business behavior and rules. Specific files, code structure, module changes, implementation steps, and codebase capability gaps are left to the subsequent implementation process.