zuozh11 To PRD
将当前对话上下文和代码库理解合成为一份 PRD，存放在 docs/scratch/<NN>-<中文需求名称>/PRD.md。NN 记录需求进入仓库的先后顺序；中文需求名称使用 CONTEXT.md 中的统一术语。
PRD 按实际交付范围组织，不预设数量或类型。交付范围使用项目已有的边界名称。
流程
1. 加载项目上下文
使用已加载的 CONTEXT 术语与 RULE。尚未加载则按项目知识协议执行；知识不可用时继续并如实说明。
2. 追问对齐上下文
以产出高质量 PRD 为目标，启动 ask-me。即使当前材料看起来已经完整，也必须进入 ask-me，不得由本 Skill 自行宣布「需求已明确」并跳过。
启动前把下列已确认决策交给 ask-me，视为已锁定，不得再问：本轮用户确认、已有 PRD 的 Implementation Decisions、对应 WAYFINDER.md 的 Decisions so far 及已关闭决策票 Resolution。ask-me 只追问仍会改变实现分支、数据口径、状态变化、权限范围或接口契约、且尚未锁定的取舍。
ask-me 可以 0 轮返回。返回后按「写法」检查；仍缺这类规则则回到 ask-me，不得自行补全。ask-me 标注的未决项保持未决，不写成用户已确认的选择。
3. 确定并贯彻交付范围
交付范围是本次需求中承担独立职责且会发生改动的产品端、系统、服务或渠道。根据需求目标、业务流程、代码入口和仓库布局识别；事实足以确定时直接采用，无法可靠判断且不同选择会显著改变范围时，提问确认。
4. 落地 PRD 文件
新建 PRD 时写入 docs/scratch/<下一个两位序号>-<中文需求名称>/PRD.md；更新已有 PRD 时沿用原路径。由 impl 转入的局部修正只改被推翻的条款和 Implementation Decisions，不重新启动 ask-me；仅当交付范围、能力结构或 Out of Scope 被推翻时才从第 2 步重跑。
PRD 模板
# <功能名称> 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/ <其他> |
写法
- 完整可评审：只读本文就能判断要解决什么问题、由谁使用、交付哪些业务结果，以及明确不做什么。缺少后会改变实现分支、数据口径、状态变化、权限范围或接口契约的规则全部保留。
- 规则可执行：每条规则能单独判断对错：谁、在什么条件、做什么、结果是什么。字段、日期、状态、数量、权限有口径时写到值。
- 边界一起写：每个能力覆盖主流程，以及空数据、失败、无权限、重复提交等会改变结果的情况。
- 合成而非转录：正文是收口后的需求，不是对话、选项或推理过程的摘录。
- 锁定即契约：Implementation Decisions 只收已确认且会改变交付的选择，并标明来源。
- 产品层表达：Requirements 写业务行为和规则。具体文件、代码结构、模块改造、实现步骤和代码库能力缺口留给后续实现过程。