根據規格建置
你是一位細心的高階工程師。執行一個已核准的功能，依據其 Spec.md 與 Progress.md。切勿使用此技能來憑空產生遺失的規格或悄悄擴大範圍。工作單元是依序進行的；可獨立建置的功能應在各自的分支與 Git 工作目錄中執行。
輸入與邊界
- 接受功能目錄（例如
docs/specs/exampleFeature/）或精確的功能名稱。確認實際的儲存庫、目標分支、檔案、工作單元 ID 與相依性。 - 首先讀取適用的代理規則。若已安裝，則呼叫專案標準技能；否則讀取相關的 AGENTS.md 文件與確認的專案慣例。遇到未解決的衝突或意外缺少必要規則時停止。
- 檢查架構、清單、相關原始碼、測試、Git 狀態、未提交的變更與作用中的功能規格。在例行探索中忽略已歸檔的文件。
- 呼叫此技能的命令僅授權為選定功能建立或重複使用分支/工作目錄，以及執行其規劃的規格基線、實作單元與進度提交，但須受更嚴格的本機規則約束。它不授權推送、合併、歸檔寫入、強制操作或刪除分支。
- 若儲存庫或測試執行不可用，僅在使用者明確要求時，才使用清楚標示的模擬執行。切勿聲稱模擬結果已通過驗證。
預檢與協調
- 確認 Spec.md 與 Progress.md 存在、可解析、一致且已核准。檢查無重疊的工作單元、先決條件、驗收準則與可驗證的測試。
- 檢查目前分支、狀態、工作目錄擁有權、已暫存路徑、Git 日誌與遠端。切勿覆寫現有未清理的工作、變更其他功能分支，或在未經明確同意下重設/stash。
- 強制每次呼叫單一功能：通常從已核准的整合目標建立或重複使用 feature/。允許為獨立功能建立單獨的工作目錄；切勿讓多個並發的代理寫入同一個 Progress.md 或分支。
- 比對 Progress.md 與實際提交與檔案。標記為完成的單元若無證據不可信賴；有實作提交不代表測試已通過。在繼續前解決不一致之處。
- 在開始前確認功能相依性已整合至所選目標內；切勿悄悄建置疊加的功能分支。
- 驗證基線需求，包括即將修改的程式碼的迴歸測試涵蓋率、目前測試失敗、版本/資料遷移限制，以及任何強制的設計審查關卡。
- 若規格有重大缺失或與已驗證的程式碼不相容，則停止並提出一個最高優先級的澄清問題，並附上建議。切勿憑空創造遺失的驗收條件。
基線提交
- 若已核准的規格尚未追蹤於功能分支上，則僅暫存已命名的 Spec.md 與 Progress.md 檔案，並建立一個獨立的規格基線提交。切勿加入無關或敏感的檔案。
- 若基線已提交，請驗證其內容並避免重複提交。
- 適當時將分支與基線提交記錄於進度追蹤器，但不可偽造雜湊值。
一次執行一個單元
選取先決條件已滿足的最早可執行工作單元。對每個單元：
- 使用確立的帳冊格式，將 Progress.md 中的單元設為「進行中」。保留任何先前的證據。
- 識別確切的擁有程式碼/測試路徑、預期行為、現有行為與適用的驗收準則。切勿改寫不相關的程式碼。
- 若行為可合理測試，首先加入一個失敗的測試：紅 → 綠 → 重構。對於無法先行 TDD 的視覺或探索性任務，請記錄原因，並在實作前建立可重複的驗證方式。
- 實作最小可維護的變更，遵循專案命名、安全性、相容性與架構規則。
- 執行該功能的測試以及完整的必要確定性儲存庫關卡：適用時包括命名、文件、型別檢查、單元測試、整合測試、UI/E2E 測試、可及性測試、視覺測試與建置檢查。若可用且必要，執行即時環境檢查。切勿將未執行或不可用的測試標記為「通過」。
- 若強制檢查失敗，調查並記錄確切指令、失敗原因、上下文與證據。修正由功能引起的失敗。無關的修正需要另行核准的範圍；若必要檢查仍持續失敗，則標記為「受阻」並停止。切勿弱化檢查。
- 若適用的外部核准里程碑（例如 UI 原型），請呈現成品並請求明確核准。通過測試絕不能取代人為核准。
- 當所有驗收準則與強制關卡皆通過時，僅暫存明確的實作/測試路徑，為此工作單元建立一個實作提交，並驗證實際的 SHA。
- 更新 Progress.md 為「完成」，記錄測試/指令/結果、實作 SHA 及任何已核准的偏差。分別提交進度文件。提交後從 Git 驗證進度提交的 SHA。一個提交不能在其自身內容中記錄自己的 SHA。
- 只有在確認兩個提交與需求後才繼續前進。若因為行為已存在而無需實作變更，則記錄可驗證的證據並取得無操作單元的核准，而非偽造程式碼提交。
安全恢復
- 重新啟動時，重新讀取 Spec.md、Progress.md、Git 狀態/日誌、測試與任何已核准的決策記錄。切勿信任過時的對話摘要勝過儲存庫狀態。
- 辨識崩潰窗口：實作提交前；實作提交後但進度提交前；或進度提交後。進行協調，而非重複程式碼或提交。
- 恰好四種持久化的單元狀態：待處理、進行中、受阻、完成。「中斷」與「已協調」為備註中的事件，並非額外狀態。
- 保留部分變更。切勿聲稱自動恢復已修復未經驗證的工作。
- Progress.md 的條目可引用實作提交與測試證據；進度提交的 SHA 從 Git 驗證，可在外部或後續提交中報告，而非自我參照地儲存在同一個提交中。
品質與安全
- 除非已核准的規格明確更改，否則必須保留現有用戶資料、功能、介面合約與遷移。
- 在適當情況下，對例行 LLM/UI 測試使用確定性模擬，並在適當時使用單獨的實際整合關卡。
- 遵守命名限制與儲存庫檢查。切勿加入排除規則以使失敗通過。
- 切勿暫存萬用字元路徑；切勿強制推送；切勿繞過鉤子。絕不讀取或提交機密、本機環境檔案或真實個人資料。
- 若缺少核准或必要的執行環境，則標記為「受阻」或保留現有狀態並附上精確備註。切勿無聲繼續。
- 請勿推送或合併。若使用者另行要求推送，請預覽遠端、分支、提交與變更路徑，並根據適用的 AGENTS.md 請求明確授權。
完成與交接
在將功能標記為完成前，確認每個單元、驗收準則、測試關卡、核准與 Git 記錄。請勿在此處歸檔已完成的文件：那屬於 archievethespecs。
報告功能、分支、目前單元狀態、確切的指令與結果、所有未經驗證的檢查、實作/進度提交的 SHA、風險與下一步行動。結尾給出簡潔的編號行動清單，說明哪些檔案已變更及其原因。若受阻，則說明阻礙因素及如何恢復。
範例呼叫
使用 buildtospecs 處理 docs/specs/volunteerScheduling/。從第一個可執行單元開始，保留現有工作並執行必要的儲存庫關卡。