Minimal Git Commit
目標
為當前代理任務建立一個或多個原子化提交。每個產生的提交訊息都遵循 Conventional Commits。保持常規提交低脈絡；將完整的差異分析保留給明確的完整模式要求。
模式選擇
- 預設使用快速模式。
- 僅在使用者說
full、要求掃描或分析完整差異、或明確要求檢查每次變更時，才使用完整模式。 - 不要默默將快速模式升級為完整模式。如果快速模式缺乏足夠資訊，請要求變更摘要或要求使用者選擇完整模式。
快速模式
首先使用代理程式對當前任務的明確摘要。必要時，僅檢查：
git status --short
git diff --stat
請勿讀取完整差異或歷史記錄。請勿猜測摘要中未提及的變更。將所述的變更分組為原子化提交並產生其訊息。如果使用者明確要求提交，請在修改索引或建立提交之前，顯示規劃的檔案/訊息（當檔案邊界不明確時）。
完整模式
讀取完整的相關工作目錄與暫存區差異，檢查所有變更的檔案，並閱讀 Conventional Commits 參考文件。檢查是否有遺漏的功能、測試、文件、設定、不相關檔案、敏感檔案、產生的檔案以及獨立的邏輯變更。確認產生的檔案是否應納入版本控制：保留專案所需的輸出（如鎖定檔或遷移檔），並排除建置產物和本地輸出。將獨立的功能、錯誤修正、重構和僅格式化變更拆分為原子化提交；當變更緊密耦合且無法獨立測試或還原時，則保持在一起。使用現有專案命令來執行與變更檔案相關的檢查。預設不執行完整的測試、lint 和型別檢查套件；重複使用任務期間已執行的檢查，並僅在要求或因變更需要時擴展驗證。除非明確要求，否則不檢查歷史記錄。
在 git add 或 git commit 之前，保留當前任務範圍外的使用者變更。僅在使用者明確要求提交時，才執行這些變更。切勿作為此技能的一部分進行推送。
提交規則
使用此格式：
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
- 使用
feat表示新功能，使用fix表示錯誤修正。 - 當專案類型
docs、style、refactor、perf、test、build、ci、chore和revert能準確描述變更時，優先使用。 - 只有在能添加有用脈絡時，才在括號中使用名詞範圍。
- 使用
!放在冒號前，或使用大寫的BREAKING CHANGE:頁尾來標記破壞性變更。 - 保持描述簡潔、現在式、祈使語氣，最好在 72 個字元以內。
- 一個提交代表一個邏輯變更。盡可能拆分獨立的功能、修正、測試、文件和重構。
fix對應 SemVer PATCH，feat對應 MINOR，任何破壞性變更對應 MAJOR；除非另外要求，否則不要更改版本檔案。
安全性與確認
- 預設不要使用
git add .；僅新增屬於當前任務的檔案。 - 絕不提交
.env、憑證、權杖、私鑰或其他機密。 - 在完整模式中，檢查暫存內容是否有機密，並在包含產生的或建置的檔案之前，確認它們是專案預期的。
- 除非使用者明確要求該確切操作，否則不要修改 Git 設定、跳過鉤子、強制推送或修改現有提交。
- 不要將預先存在的使用者變更與代理程式的變更混在一起。
- 當任務邊界、檔案所有權、邏輯拆分或敏感檔案狀態不明確時，請停下來詢問。
- 產生訊息不等於允許建立提交；在
git add或git commit之前，需要明確的提交請求。
參考資料
在完整模式中，或當類型、頁尾、破壞性變更、還原、SemVer 或 FAQ 問題需要詳細處理時，閱讀 references/conventional-commits.md。