name: pdd description: 将一个粗略想法转化为带有实施计划的详细设计文档。遵循提示驱动开发——迭代的需求澄清、研究、设计和规划。 type: anthropic-skill version: “1.2”
提示驱动开发
概述
将一个粗略想法转化为带有实施计划的详细设计。该过程是迭代的：澄清需求、研究、设计、规划——根据需要移动各个阶段。
重要注意事项
这些规则适用于所有步骤：
- 用户驱动流程： 在未获得用户明确确认前，绝不要进行下一步。在每个转换点，询问用户下一步想做什么。
- 迭代性： 用户可以随时在需求澄清和研究之间移动。始终在阶段转换时提供此选项。
- 实时记录： 实时将问题、答案和发现追加到项目文件中——不要在最后批量写入。
- Mermaid 图表： 在研究和设计文档中包含架构、数据流和组件关系的图表。
- 资料来源： 如果基于外部材料，在研究文档中引用参考和链接。
- 仅规划： 此标准操作程序产生规划工件。您绝不能实施代码、运行容器、执行脚本或开始任何实施工作。如果用户想要实施，请指导他们使用
ralph run。
参数
- rough_idea（必需）：要开发的初始概念或想法
- project_dir（可选，默认：
specs/{task_name}/）：所有工件的基目录。{task_name}从想法派生为 kebab-case（例如，“build a rate limiter” →rate-limiter）。与 Ralph 的规范驱动管道对齐。
约束：
- 您必须在单个提示中提前询问所有必需参数
- 您必须支持多种输入方法：直接文本、文件路径、URL
- 您必须从粗略想法派生
task_name为 kebab-case - 您绝不能覆盖现有项目目录——如果已有内容，请询问新路径
步骤
1. 创建项目结构
创建目录和初始文件：
{project_dir}/rough-idea.md— 提供的粗略想法{project_dir}/requirements.md— Q&A 记录（初始为空）{project_dir}/research/— 研究笔记目录
告知用户该结构馈入 Ralph 的规范驱动预设。
门控： 在用户确认项目结构可接受前，绝不能进行步骤 2。
2. 初始流程规划
询问用户偏好的起始点：
- 需求澄清（默认）
- 特定主题的初步研究
- 首先提供额外上下文
门控： 必须等待用户选择后才能继续。绝不能在没有明确用户指示的情况下自动开始需求澄清或研究。
3. 需求澄清
通过问题引导用户，将想法细化为详细规格。
约束：
- 每次只能问一个问题——不要列出多个问题
- 不能预填充答案或将 Q&A 批量写入 requirements.md
- 对于每个问题，必须遵循此循环：
- 制定问题并追加到 requirements.md
- 呈现给用户，等待完整响应
- 将答案追加到 requirements.md
- 进行下一个问题
- 在继续前，必须询问用户需求澄清是否完成
覆盖边缘情况、用户体验、技术约束和成功标准。当用户不确定时，建议选项。
门控： 在用户明确确认需求澄清完成前，绝不能进行研究或设计。必须提供进行研究选项，如果问题出现可受益于额外信息。
4. 研究
对技术、库或现有代码进行研究，以指导设计。
约束：
- 必须向用户提议研究计划并纳入他们的建议
- 必须在
{project_dir}/research/中记录发现，作为单独主题文件 - 必须定期与用户确认，分享发现并确认方向
- 在继续前，必须总结关键发现
门控： 在用户确认研究足够前，绝不能进行迭代检查点。必须提供返回需求澄清的选项，如果研究揭示新问题。
5. 迭代检查点
总结当前需求和研究的状况，然后询问用户：
- 继续设计？
- 返回需求澄清？
- 进行额外研究？
门控： 在没有明确用户确认前，绝不能进行设计。必须支持在需求和研究中心之间多次迭代。
6. 创建详细设计
创建 {project_dir}/design.md 作为独立文档，包含以下部分：
- 概述
- 详细需求（从 requirements.md 整合）
- 架构概述
- 组件和接口
- 数据模型
- 错误处理
- 验收标准（Given-When-Then 格式用于机器验证）
- 测试策略
- 附录（技术选择、研究发现、替代方法）
约束：
- 必须将设计写为独立——无需阅读其他文件即可理解
- 必须整合 requirements.md 中的所有需求
- 必须包括附录总结研究（技术选择、替代方案、限制）
- 必须与用户审查设计并基于反馈迭代
门控： 在用户明确批准设计前，绝不能进行实施计划。必须提供返回需求或研究的选项，如果在设计审查中发现缺口。
7. 开发实施计划
创建 {project_dir}/plan.md —— 一系列编号的增量实施步骤。
指导原则： 每个步骤都基于先前步骤，产生可演示的工作功能，并遵循 TDD 实践。无孤立代码——每个步骤以集成结束。核心端到端功能应尽早可用。
约束：
- 必须在 plan.md 顶部包括检查清单跟踪每个步骤
- 必须格式化为 “Step N:” 包含：目标、实施指导、测试要求、集成笔记、演示描述
- 必须确保计划涵盖设计的所有方面，不重复设计细节
门控： 在用户审查并批准实施计划前，绝不能进行总结。
8. 总结并呈现结果
创建 {project_dir}/summary.md 列出所有工件、简要概述和建议的后续步骤。在对话中呈现此总结。
9. 提供 Ralph 集成
询问：“您想让我为 Ralph 创建一个 PROMPT.md 来自动化实施吗？”
如果用户同意，创建一个简洁的 PROMPT.md（少于 100 行）包含：
- 目标陈述
- 关键需求
- 验收标准（Given-When-Then）
- 引用
specs/{task_name}/
建议适当命令：
- 完整管道：
ralph run --config presets/pdd-to-code-assist.yml - 简化流程：
ralph run --config presets/spec-driven.yml
如果用户拒绝，确认并结束会话。
门控： 绝不能运行 ralph run 或开始任何实施。此标准操作程序在此结束。实施是用户自行发起的独立步骤。
示例
输入： “我想为我们的内部工具构建模板管理功能——创建、编辑、共享模板，生成带有自定义字段的文档。”
输出： 一个 specs/template-management/ 目录，包含 rough-idea.md、requirements.md、research/、design.md、plan.md 和 summary.md——可选地包括用于自动化实施的 PROMPT.md。
故障排除
需求停滞： 建议切换到不同方面、提供示例，或转向研究以解除阻塞决策。
研究限制： 记录缺失内容，基于可用信息建议替代方案，要求用户提供额外上下文。不要阻塞进展。
设计复杂性： 分解为更小组件，首先聚焦核心功能，建议分阶段实施，返回需求重新优先级排序。