prd-to-plan

PRD 转计划

使用垂直切片（示踪弹）将 PRD 拆解为分阶段实施计划。输出为 ./docs/<feature-name>/plan.md 中的 Markdown 文件。

流程

1. 确认 PRD 已在上下文中

PRD 应已出现在对话中。如果没有，请用户粘贴 PRD 或提供文件路径。

2. 探索代码库

如果尚未探索代码库，请先进行探索，以了解当前架构、现有模式和集成层。

3. 确定持久的架构决策

拆分阶段之前，先确定在整个实施过程中不太可能改变的高层决策：

• 路由结构 / URL 模式
• 数据库架构形状
• 关键数据模型
• 身份验证 / 授权方式
• 第三方服务边界

这些内容应放在计划头部，以便每个阶段都能引用。

4. 起草垂直切片

将 PRD 拆分为示踪弹阶段。每个阶段都是贯穿所有集成层的精简垂直切片，端到端实现，而不是只覆盖单一层的水平切片。

- 每个切片都应贯穿各个层（架构、API、UI、测试），交付一条精简但完整的路径 - 完成的切片应可独立演示或验证 - 优先采用多个精简切片，而不是少数几个庞大切片 - 不要包含具体文件名、函数名或可能随着后续阶段推进而变化的实现细节 - 应包含持久的决策：路由路径、架构形状、数据模型名称

5. 向用户确认

以编号列表的形式展示建议的拆分方案。对每个阶段列出：

• 标题：简短的描述性名称
• 涵盖的用户故事：此阶段涉及 PRD 中的哪些用户故事

询问用户：

• 粒度是否合适？（太粗 / 太细）
• 是否应合并某些阶段，或进一步拆分？

反复调整，直到用户批准拆分方案。

**通过 afk 调用时（无用户交互）：**跳过确认环节。自行判断合适的粒度并直接编写计划。

6. 编写计划文件

如果 ./docs/<feature-name>/ 不存在，则创建该目录。按照下方模板，将计划写入以功能命名的 Markdown 文件（例如 ./docs/meta-direct-whatsapp/plan.md）。

任务格式（执行时请注意）

每个阶段的 “构建内容” 部分决定 ralph 如何执行该阶段：

• 编号列表（1.、2.、3.）——每个条目都会成为一个独立的实施任务，并有单独的提交。对于包含多个交付项的阶段，优先采用此格式。
• 项目符号列表（-、*）——每个项目符号都会成为一个独立任务。
• 单段文字——整个阶段作为一个任务执行。

只要一个阶段包含多个逻辑交付项，就使用编号列表。这样能让 ralph 专注于原子化的实施会话，并形成粒度更细的提交历史。

# 计划：

源 PRD：<PRD.md 的相对路径，例如 docs/feature/PRD.md>

架构决策

适用于所有阶段的持久决策：

• 路由：...
• 架构：...
• 关键模型：...
• （根据需要添加或删除章节）

---

阶段 1：<标题>

用户故事：<PRD 中以逗号分隔的编号>

构建内容

1. 第一个任务——描述此切片的第一个交付项
2. 第二个任务——描述下一个交付项
3. 第三个任务——描述第三个交付项

验收标准

• 标准 1
• 标准 2
• 标准 3

---

阶段 2：<标题>

用户故事：<PRD 中以逗号分隔的编号>

构建内容

1. 第一个任务——……
2. 第二个任务——……

验收标准

• ……