prd-workflow

PRD 转实现工作流

当用户要求「根据 PRD 实现」「实现此功能」或正在编辑 config/PROJECT.md 所描述的 PRD 目录下的文档时，按以下步骤执行。总规则见 00-prd-kit.mdc 与项目 config/PROJECT.md。

Globs 说明：本文件默认匹配 docs/prd/**/*.md。若你项目的 PRD 根路径不同，请同时修改本文件头部的 globs 与 config/PROJECT.md 中的 PRD 目录。

无 Stack Profile 时：项目未从本工具包复制任何 examples/<stack>/ 的架构/命名 mdc 时，PRD 必须自行写明文件路径、模块划分、命名与验收标准；仅依赖本工作流 + 通用项目配置。

Composer / 自动模式

• 在 Composer 中 @ 对应 PRD（如 @docs/prd/active/xxx.md），并 @ 00-prd-kit.mdc 与本 prd-workflow.mdc；若已启用 profile，@ 对应 framework / 命名等 mdc（以你 .cursor/rules/ 中实际文件名为准）。
• 用户开启高自主执行时：仍先列出将创建/修改的文件清单（可一段话），再执行；若 PRD 缺验收标准或关键行为，先补问或补写 PRD，不要凭空虚构业务规则。
• 涉及编辑器/资源绑定/场景与脚本关联等工具链专属步骤时，在说明中提醒用户在对应 IDE 中人工确认（例如游戏引擎中场景与脚本的引用）。

1. 分析阶段

1.1 阅读 PRD

• 理解目标与验收标准。
• 识别涉及的模块/场景/子系统。
• 明确新增/修改的文件清单与依赖。

1.2 检查规范

• 阅读 config/PROJECT.md 中的技术栈、验证命令、补充架构链接。
• 若已启用 Stack Profile：阅读对应 架构 与命名/分层 规则；识别仓库内相似实现作参考。

1.3 列出文件清单

向用户确认，例如：

将创建以下文件：
- path/to/new/module_a.ext
- path/to/new/module_b.ext

将修改以下文件：
- path/to/existing/file.ext

确认后开始实现。

2. 实现阶段

• 严格遵守 config/PROJECT.md 与已启用的 Stack Profile；二者与 PRD 冲突时，先向用户确认。
• 无 profile 时：以 PRD 中给出的路径、数据结构与风格为准，并与现有代码库风格对齐。
• 不引入 PRD 未要求的跨模块副作用；需要新增系统级能力时，先与用户对齐。

3. 验证阶段

3.1 自检

根据 PRD 验收条 与 profile/团队约定 做静态检查（类型、风格、安全相关约束等，依项目而定）。

3.2 执行验证

• 运行 config/PROJECT.md 中列出的构建/测试/检查命令，并记录结果。
• 无自动化命令时，说明已完成的手动物理步骤与结论。

4. 禁止事项（通用）

• 不要为「省事」在 PRD 外发明业务规则或数据契约。
• 不要混用与团队约定/ profile 相冲突的命名与分层（若 profile 有定义）。
• 不要省略「将改动哪些文件」的确认，除非用户明确允许直接改。

5. 报告格式

实现完成后，向用户报告，例如：

功能实现完成

已创建文件：
- `path/a`
- `path/b`

已修改文件：
- `path/c`

验证结果：
- 命令/步骤：…
- 结果：通过 / 未通过（说明原因）

后续建议（若有）：
- 人工在 IDE/产品内验证的条目