implement-specs

implement-specs

根据 PRODUCT.md 和 TECH.md 实现已批准的功能。

概述

在产品和技术规格获批后使用此技能。目标是在功能开发过程中，始终让已纳入版本控制的规格与实现保持一致，并构建规格中描述的功能。

已批准的规格应直接放在以工单命名的目录下，例如 specs/APP-1234/PRODUCT.md 和 specs/APP-1234/TECH.md。

很多情况下，实现应与产品和技术规格放在同一个 PR 中提交。随着工程师不断迭代，PRODUCT.md、TECH.md 和代码的变更都应在同一个 PR 中提交，确保评审始终围绕实际将要发布的功能展开。

前提条件

使用此技能前：

• 确认 PRODUCT.md 存在
• 如果该功能需要 TECH.md，确认它也存在
• 确认相关规格已经过评审并获批，可以开始实现

工作流

1. 先阅读已批准的规格

将以下文件视为：

• PRODUCT.md：用户可见行为的事实来源
• TECH.md：架构、实施顺序和实现形式的事实来源

编写代码前，确保你了解预期行为、约束、风险和验证计划。

2. 为大型功能提供可选的实现辅助文档

对于大型或耗时较长的功能，可以在开始实现前向用户提供以下一种辅助文档：

• PROJECT_LOG.md，用于跟踪检查点、探索过的路径、阶段性发现和当前实现状态
• DECISIONS.md，用于记录 PRD 和技术设计过程中做出的具体产品与技术决策

这些是可选辅助文档，并非必需交付物。在它们有助于减少困惑，或帮助后续 Agent 避免重复探索相同路径时，再提供它们。

3. 根据规格制定计划并实现

将工作拆分为具体的实现步骤，然后根据已批准的规格实现功能。

实现过程中：

• 确保行为与 PRODUCT.md 保持一致
• 确保架构和实施顺序与 TECH.md 保持一致
• 随着工作推进，添加或更新测试及验证材料

条件允许时，将规格和实现在同一个 PR 中提交，以便在一处评审完整的功能演进过程。

4. 随着实现演进更新规格

如果实现过程中发现预期行为或设计需要变更，应更新已纳入版本控制的规格，避免其内容过时。

具体来说：

• 用户可见行为、用户体验、边界情况或成功标准发生变化时，更新 PRODUCT.md
• 架构、实施顺序、模块边界或验证策略发生变化时，更新 TECH.md
• 将这些更新与对应的代码变更放在同一个 PR 中

PR 应描述实际发布的功能，而不仅仅是规格的初稿。

5. 根据规格进行验证

在认为工作已完成前，验证代码是否符合当前规格。

优先采用：

• 遵循代码仓库本地测试惯例的单元测试和回归测试
• 针对重要用户流程的集成测试或端到端测试

最佳实践

• 在整个实现过程中，让规格与代码保持同步。
• 决策发生变化时，优先立即更新规格，而不是等到最后再集中清理。
• 只有在复杂功能确实能从中受益时，才使用可选跟踪文档。
• 确保同一个 PR 内容连贯：规格更新、代码变更、测试和可选跟踪文档都应服务于同一功能叙述。

相关技能

• spec-driven-implementation
• write-product-spec
• write-tech-spec