implement-specs

implement-specs

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

概述

在产品和技术规格获批后使用此技能。目标是构建规格所描述的功能，同时随着工作的推进，保持已检入的规格与实现的一致性。

已批准的规格应直接放在 specs/ 下以工单命名的目录中，例如 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 和技术设计过程中做出的具体产品和决策

这些是可选的辅助文档，不是必需的交付物。当它们能减少混淆或帮助未来的代理避免重新探索相同路径时，提供它们。

3. 根据规格进行规划和实现

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

实现过程中：

• 保持行为与 PRODUCT.md 一致
• 保持架构和顺序与 TECH.md 一致
• 随着工作的落地，添加或更新测试和验证产物

在可行的情况下，将规格和实现放在同一个 PR 中，以便整个功能演进可以在一个地方审查。

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

如果实现揭示预期的行为或设计应更改，则更新已检入的规格，而不是让它们过时。

特别是：

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

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

5. 根据规格进行验证

在认为工作完成之前，验证代码与当前规格匹配。

优先使用：

• 遵循仓库本地测试约定的单元测试和回归覆盖
• 针对重要用户流程的集成或端到端测试

最佳实践

• 在整个实现过程中保持规格和代码同步。
• 当决策发生变化时，立即更新规格，而不是将规格清理推迟到最后。
• 仅在复杂功能中真正增加价值时使用可选的跟踪文档。
• 保持同一个 PR 的连贯性：规格更新、代码更改、测试和可选的跟踪文档都应支持相同的功能叙事。

相关技能

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