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