prd-to-spec

产品设计文档到技术规范的转换

以50年代码开发工作经验及架构师身份从代码工程范式、可维护性、性能、质量、安全等角度出发，生成具体代码详细技术规范。根据(PRD)文档内容，补全代码领域潜在行业知识、代码风格、技术规范，并澄清潜在的问题，来指导工程师或人工智能如何构建。

何时使用

• 根据/prd生成得文档，弥合它与实施落地之间的差距。
• 当未开始实时编码，方案调整阶段，prd文档更新对应spec同步更新时。
• 你希望在编码开始之前就把架构决策记录下来。
• 多个开发人员/智能体将实现此功能，因此需要一份共享合约。
• 在落地实施之前，生成产品需求文档 (PRD) 之后，您需要验证技术可行性以及问题。

步骤1:找到PRD

可以通过以下方式之一找到输入 PRD：

Provide the PRD to convert:

A. File path (e.g., docs/prd/prd-priority-system.md)
B. Accessible web service URL 
C. Paste PRD content directly
D. Auto-detect: scan docs/ directory for recent PRDs

如果自动检测，则列出可用的 PRD 并让用户选择：

**Found PRDs in docs/prd/:**
  1. docs/prd/prd-priority-system.md (2024-03-15)
  2. docs/prd/prd-user-auth.md (2024-03-10)

Which PRD should I convert? [1/2]

如果没有找到PRD则引导用户执行/prd 技能并生成PRD文档，然后在执行后续操作。

步骤2:信息收集(可选)

结合项目工程上下文收集信息，补充实际落地代码之间的隐藏关键差距信息

• 现有架构——当前系统的结构方式
• 技术栈——已使用的语言、框架、依赖库、代码管理工具。
• 模式——文件组织、公共包、通用方法、组件、帮助函数、错误处理方法
• 代码规范——命名约定、代码风格、规范、质量标准、设计模式
• 数据库——当前模式、迁移工具、ORM
• API 风格— REST/GraphQL/gRPC、身份验证方法、响应格式
• 测试——测试框架、覆盖模式、测试工具

收集方式如下:

1. 用户提供得prompt、文档、图片、链接、可访问资源等。
2. 检索架构设计文档 docs/architecture/ADR-[number]-[title].md 文档，存在则参考设计。
3. 当前已有的项目实现，优先读取CLAUDE.md、AGENTS.md、README.md等文档内容，或分析现有代码仓库实现。
4. 知识库、.docs/、.spec/、plan/ 、prd/检索
5. 检索skills以及rules .claude/skills/**/SKILL.md，.codex/skills/**/SKILL.md，.**/skills/**/SKILL.md、.claude/rules/* 、.codes/rules/* 等可用得技能、规则, 提取最佳实践、约定规范、案例等。
6. 外部知识检索，当收集到的信息不足、了解最新技术方案与技术调研，如下:
   1. Context7 MCP（mcp__context7__resolve-library-id，mcp__context7__query-docs）：当 MCP 服务器连接时首选，返回结构化文档MCP检索。当MCP不可用但ctx7 CLI 可用则作为备用方案
   2. WebSearch/WebFetch。
   3. 其他可访问知识检索MCP、skills、知识库检索等。

对收集得信息进行分析并归纳总结，用于后面澄清与决策。

步骤3:澄清问题

当产品需求内容存在潜在问题、矛盾、缺失，或对技术决策存在歧义时才提出问题，一次只提一个问题。

1. 需求模糊，交互流程缺失、逻辑矛盾，边界不清晰。
2. 数据流转生命周期是否完整，是否闭环，是否矛盾。
3. 错误处理、限流控值、服务降级、安全保证，兜底方案。
4. 需求不合理处，技术瓶颈，实现风险。
5. 复用现有实现，如不能复用，在原有的接口、页面、组件、方法、对象，以及功能模块紧邻相关方法上进行修改或扩展。
6. 澄清内容矛盾点，例如一个需求功能提供了多份资料来源:
   1. 文档与文档之间描述不一致情况问题。
   2. 文档与截图，UI图，原型图所呈现不一致内容矛盾点(图中展示5个字段文档中为6个字段)。
   3. 现有代码与文档之间的矛盾点。
7. 补充prd文档、需求中没有提到的隐形知识与规则，根据 信息收集 丰富上下文。例:
   1. 平台支持了国际化，默认人是知道的但是文档没有体现。
   2. 增加了新的支付方式，文档并没有提出账户流水处理方式。
   3. 默认样式颜色、布局、弹窗、组件、间距、字体、内容过长缩略展示策略等。
   4. 接口参数的规则规范，字段命令都是采用驼峰还是下滑线。
   5. 具体领域知识的默认、约定俗成规则，比如文件命名不能采用中文等。