Commit Message Generator

工作流程

執行 git diff --staged 檢查暫存變更。如果為空，告知使用者先執行 git add 並停止。
根據下方的語言政策決定描述語言。
產生訊息並顯示供確認，不要立即提交。當有多種合理的表述框架時，將其呈現為簡短的編號清單（1)、2)、…），讓使用者只需回覆數字即可選擇。單一明確的訊息可單獨顯示。使用者也可以回覆修改版本或自己的措辭。
僅在使用者選擇或明確確認後才執行 git commit -m —— 清單中的數字、「commit」或「ok」都算數。除非使用者明確要求，否則不要執行 git push。

對於 type(scope): 後方的人類可讀描述，使用以下優先順序：

嚴格依序套用此規則，並在第一個符合條件時停止。在檢查項目 4 之前，請先檢查項目 2 和 3。單純的斜線指令或技能叫用沒有語言，請繼續檢查項目 5。最多檢查最近 20 個主題。

保留 Conventional Commits 語法 token 不進行翻譯：type、可選的 scope、! 以及 BREAKING CHANGE。保留識別碼、檔案名稱、套件名稱、指令、API 名稱以及作用域（scope）的原始語言。

在一般的提交產生過程中，請勿寫入設定檔。如果使用者明確要求記住提交描述的語言，則主動提供保留選項。當作用域不明確時，詢問使用者要儲存至儲存庫還是全域。

對於儲存庫偏好，建立或更新 .agent-tools/config.jsonc；對於全域偏好，使用 ~/.agent-tools/config.jsonc：

{
  "at-commit.language": "zh-TW"
}

在可行的情況下，保留不相關的鍵與註解。不需要事先安裝設定工具。

讀取 git diff --staged 並產生 Conventional Commits 標題，說明「變更了什麼」以及（如有幫助）「為什麼變更」。

標題：type(scope): description，不超過 74 個字元，句尾無句號，無前綴，無引號，無程式碼區塊。
type：精確選擇一個：
- feat 表示新功能，fix 表示錯誤修正
- refactor 表示保留行為的重構，perf 表示效能
- docs 表示僅文件變更，style 表示僅格式變更
- test 表示新增或修正測試，build 表示建置系統或相依性，ci 表示 CI 設定/腳本
- chore 表示未更動 src/test 的雜項變更，revert 表示還原
scope：可選的受影響模組名稱。使用此儲存庫的慣例。在 monorepo 中，使用應用程式/套件目錄名稱。對於跨領域變更或不確定時，省略 scope。
description：用選定的自然語言撰寫一個簡潔的動詞-受詞短語。避免使用相當於「更新檔案」、「此提交」、「雜項變更」或「數個變更」的填充詞。保留識別碼、函式名稱、檔案名稱、套件名稱、指令和 API 的原始寫法。
僅單行：提交訊息始終只包含標題行。不寫入內文或頁尾。將必要的 WHY 壓縮到標題中。
破壞性變更：使用 type(scope)!: description 標記，仍為單行。不要使用 BREAKING CHANGE 頁尾。
標點符號：使用 ASCII 標點符號。

在撰寫前，找出暫存變更的主線。

訊息必須陳述已確認的程式碼事實，而非猜測的意圖。

優先考量 src 和 test 中的行為變更：文件僅作為輔助背景。不要僅從文件推測 WHAT。
使用者背景勝過文件：明確的使用者目標有助於選擇 WHY 和措辭，但 WHAT 和 scope 仍來自暫存差異。不要包含差異中不存在的純背景變更。如果背景與差異衝突，遵循差異並要求確認。
刪除與重新命名：當無法從程式碼關係確認目的時，僅陳述差異可證明的事實，例如「移除 X」或「將 X 重新命名為 Y」。除非程式碼能證明，否則不要聲稱是替換、遷移或因果關係。
多項變更但目標一致：當變更明顯服務於相同目標（例如品質或建置修正）時，提供一個總結性訊息。僅在拆分能實質改善審查或復原時，才建議拆分。
不相關的暫存變更：為每個連貫的單元提供分開的訊息，並加上一個保守的總結訊息。讓使用者選擇要拆分還是總結，而不是將總結推遲到另一個輪次。
歸屬或意圖不明：列出需要確認的檔案，而不是強行給出模糊的訊息。當意圖不明時，優先選擇確認或拆分，而不是使用「更新」、「調整」或「微調」等含糊詞彙。