Claude 開發工作流程
概觀
擁有任務層級的開發序列，在 Claude Code 中：實作請求的變更、執行其檢查，然後在使用者要求時，在交付前取得獨立的 Codex 審查。適用於純文字請求以及透過其他技能啟動的工作。這是一個基於指令的編排；自動技能選擇與完成並非主機強制的保證。
使用方式
使用 /claude-development <任務> 或將其應用於授權的 Claude 開發請求，例如：修正這個錯誤並交付驗證後的變更。 即使不需要 TDD，也請包含宣告式組態變更。僅有規劃、解釋和審查的請求不授權任何實作。
實作請求授權為達成請求結果所需的本地修正，包括對該範圍內已證實缺陷的有界 Codex 修正。保留更嚴格的使用者限制。提交、推送、PR 發佈、核准與合併保留其現有的授權要求。其他技能擁有其專門步驟；此技能擁有開發何時結束的決定權。
步驟
- 確立任務與前置條件。 讀取儲存庫說明、當前 Git 狀態、相關原始碼和 ADR。識別需求、允許的檔案、現有的變更和驗證邊界。僅使用
requirements-clarification來解決實質性的未知項。驗證所需的檢查是否可用。如果請求了獨立的 Codex 審查，請在該階段之前驗證code-review-fix及其宣告的執行環境。保持自動的 Stop 審查閘門停用；缺少可選的審查工具不應阻擋實作或一般交付。 - 尊重外層工作流程。 對於 Linear 任務，讓
linear-start和linear-workflow擁有資格、分支、追蹤器和 PR 狀態的決定權。其他專門的工作流程保留其自身的權威和邊界。當此任務修復一個開啟中的 PR 時，請使用授權的pr-fix工作流程進行修復和獨立審查；不要啟動並行的本地修復循環。即使未呼叫其他技能，一般的本地實作也在此處進行。 - 實作確定的結果。 保留不相關的工作。對擁有的可執行行為應用
tdd，對宣告式變更應用原生或現有的驗證。使用相關領域技能，但不要將每個測試、工具呼叫或子任務變成單獨的交付階段。記錄完整的任務差異以及任何刻意排除的變更。 - 執行相關檢查。 在格式化、lint 和型別檢查之前，索引預期的新檔案。執行適合實際變更的儲存庫屏障，並指定環境和限制。失敗的檢查代表未完成的開發，而非允許減弱斷言。僅修正授權的失敗，並明確保留缺失的必要證據。
- 在請求時執行一次獨立審查。 Codex 審查是可選的；僅有實作請求不需要它。當使用者請求審查和有界修正時，在完整的本地差異上啟動
code-review-fix，並附上需求、候選身份和原始檢查證據。在授權的工作流程執行期間暫停 Claude 的寫入。僅有審查的請求不授權任何修正，應使用code-review。不要在委派的修正內部重新啟動任一序列。如果pr-fix擁有修復和審查，則保留其範圍，而不是建立第二個循環。 - 交付觀察到的結果。 報告最終的候選方案、變更的行為、發現的處置方式、實際的檢查結果、執行環境和剩餘的限制。缺失、過時或不完整的請求審查仍應視為明確的限制；未經請求的審查不是交付的先決條件。不要僅僅因為程式碼已編寫、檢查通過、子任務已返回或任務被標記為完成就認為開發已結束。保留外層工作流程中任何現有的發佈和核准檢查點。
注意事項
- 純文字請求會繞過專門技能 — 驗證可能會消失；無論任務如何啟動，此工作流程都適用於 Claude 開發。
- TDD 成為外層工作流程 — 一個綠色測試就結束交付為時過早；請在實作和檢查完成後驗證完整任務並執行任何請求的審查。
- 每個子任務都會啟動完成序列 — 審查會遞迴，通過計數器會重置；只有外層開發擁有者才能呼叫最終階段。
- 組態編輯會跳過 TDD — 跳過數值測試也可能意外跳過審查；請使用原生驗證，並在請求時執行獨立審查。
- 現有 PR 修復會產生第二個循環 — 競爭的寫入者和判斷會產生分歧；請保留
pr-fix擁有者及其最終的獨立審查。
約束
- 永遠不要從僅規劃或僅審查的請求開始實作、修復或發佈。
- 永遠不要將未執行的審查報告為已完成，或要求執行未經請求的 Codex 審查。
- 永遠不要覆寫使用者限制或超出請求的結果和確認的修正範圍。
- 永遠不要在委派的修正內部複製
code-review-fix或pr-fix循環。 - 永遠不要啟用 Stop 審查閘門，或將自動技能選擇呈現為技術上強制的。
- 永遠不要安裝缺失的執行環境，或用看似成功的結果取代缺失的證據。