建立訊息清晰且能有效傳達價值 Central 意圖的 git commit。當使用者要求提交或保存已暫存（staged）或未暫存（unstaged）的變更，並希望附上符合儲存庫習慣且能傳達價值的 commit 訊息時使用。
Git Commit
從目前工作區（working tree）的變更中，建立單一且精心撰寫的 git commit。
Context
透過將下方每條命令作為其獨立的 shell 工具調用（單一 argv 風格調用，僅包含程式及其引數）來收集工作區上下文（working-tree context）。切勿使用 ;、&&、||、管道（pipes）、$(...) 或如 2>/dev/null 的重導向（redirects）將它們連接：該語法僅能於 POSIX shell 解析，在 Windows PowerShell 環境下會直接中斷。請直接讀取每條命令的結束狀態碼（exit status）——非零的結束狀態是需要解讀的正常狀態，而非需要屏蔽的錯誤。
| Command | Purpose | Non-zero exit / empty output means |
|---|---|---|
git status |
工作區狀態 | 非 git 儲存庫——回報並停止執行 |
git diff HEAD |
未提交的變更 | 尚未建立 commit 的全新儲存庫——將每個追蹤的變更視為新檔案 |
git branch --show-current |
目前分支 | 空白輸出 = detached HEAD 狀態 |
git log --oneline -10 |
近期 commit 風格 | 尚未建立 commit 的全新儲存庫——尚無歷史紀錄可比對 |
git rev-parse --abbrev-ref origin/HEAD |
遠端預設分支 | 未設定 origin/HEAD——依步驟 1 判斷預設分支 |
這些數值是在執行任何動作前截取的快照（snapshot）。在正式提交前，請立即重新確認所有關鍵資訊（如目前分支、已暫存的檔案集合），因為從收集上下文到實際執行提交的這段時間內，工作區可能會發生變化。
Workflow
步驟 1：收集上下文（Gather context）
分別將上文 Context 區塊中的命令（git status、工作區 diff、目前分支、近期 commit、遠端預設分支）作為獨立的 shell 工具調用並執行。
遠端預設分支的值會傳回類似 origin/main 的結果。請移除 origin/ 前綴以取得分支名稱。若該命令結束狀態碼為非零（未設定 origin/HEAD）或僅傳回純 HEAD，請嘗試執行：
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
若兩者皆失敗，則退回使用 main。
若 git status 顯示工作區乾淨（沒有任何已暫存、已修改或未追蹤的檔案），請回報目前沒有需要提交的內容並停止執行。
若目前分支為空白，代表儲存庫處於 detached HEAD 狀態。若使用者希望將本次修改關聯至某個分支，請向使用者解釋必須先建立分支才能提交。詢問使用者是否現在建立功能分支（feature branch）。請使用系統平台的阻斷式提問工具：Claude Code 中的 AskUserQuestion（若其 schema 未載入，請先調用 ToolSearch 並傳入 select:AskUserQuestion）、Codex 中的 request_user_input、Antigravity CLI (agy) 中的 ask_question、Pi 中的 ask_user（需要 pi-ask-user 擴充功能）。只有在環境完全不存在阻斷式提問工具或工具調用報錯（例如 Codex 編輯模式）時，才退回在聊天中列出選項——絕對不能因為需要載入 schema 就改在聊天中提問。切勿默許跳過提問。
- 若使用者選擇建立分支，請根據變更內容推導分支名稱，使用
git checkout -b <branch-name>建立分支，接著再次執行git branch --show-current，並將其結果作為後續工作流程的目前分支名稱。 - 若使用者拒絕，則繼續在 detached HEAD 狀態下進行 commit。
步驟 2：確定 commit 訊息規範（Determine commit message convention）
請遵循以下優先順序：
- 已在上下文中的儲存庫規範 -- 若專案說明檔案（AGENTS.md、CLAUDE.md 或類似檔案）已載入且其中指定了 commit 訊息規範，請直接遵循。無需重新讀取這些檔案；它們在 session 開始時就已載入。
- 近期的 commit 歷史紀錄 -- 若未明確記錄規範，請檢查步驟 1 中取得的最近 10 筆 commit。若呈現出明顯的模式（例如 conventional commits、ticket 前綴、emoji 前綴），請匹配該模式。
- 預設：Conventional Commits -- 若上述兩者皆未提供模式，請使用 conventional commit 格式：
type(scope): description，其中 type 為feat、fix、docs、refactor、test、chore、perf、ci、style、build之一。
使用 conventional commits 時，請選擇能最精準描述該變更的類型（即上述類型清單）。當 fix: 與 feat: 似乎都適用時，預設選擇 fix:：用於修復故障或補齊缺失行為的變更屬於 fix:，即使是透過新增程式碼來實現也是如此。請將 feat: 專門留給使用者先前無法完成的新功能。其他類型在更契合時仍作為首選。使用者可針對特定變更覆寫此邏輯。
步驟 3：考量邏輯 commit（Consider logical commits）
在將所有檔案一次性暫存之前，請先掃描已變更的檔案，檢查是否存在自然獨立的關注點（concerns）。若已修改的檔案明顯能歸類為不同的邏輯變更（例如某一目錄下的重構與另一目錄下的新功能，或是測試檔案與原始碼檔案屬於不同的變更），請為每個分組分別建立獨立的 commit。
保持輕量化原則：
- 僅在檔案層級進行分組 -- 切勿使用
git add -p或嘗試拆分單一檔案內的區塊（hunks）。 - 若拆分方式顯而易見（不同的功能、無關的修復），則進行拆分。若界線模糊，合併為一個 commit 即可。
- 拆分出 2 到 3 個邏輯 commit 是最佳平衡點。切勿過度切碎成大量微小的 commit。
步驟 4：暫存與提交（Stage and commit）
若上述上下文中的目前分支為 main、master 或步驟 1 中判定的預設分支，請在 commit 前自動建立功能分支。請根據變更內容推導分支名稱，執行 git checkout -b <branch-name> 建立分支，執行 git branch --show-current 進行確認，並在後續工作流程中將新分支作為目前分支。無需詢問是否建立分支——在此情況下不允許直接在預設分支上 commit。
撰寫 commit 訊息：
- 主旨行（Subject line）：簡明扼要、使用祈使句語氣，聚焦於為什麼（why）改動而非改了什麼（what）。遵循步驟 2 確定的規範。
- 內文（Body）（必要時）：對於非微小的變更，請在主旨行下方留一空行並加入內文。解釋改動動機、權衡考量或未來閱讀者需要了解的任何背景資訊。對於目的顯而易見的單項變更，可省略內文。
針對每個 commit 分組，在單次調用中完成暫存與提交。建議透過檔案名稱明確指定要暫存的檔案，而非使用 git add -A 或 git add .，以避免意外包含敏感檔案（.env、金鑰憑證）或無關的變更。使用 heredoc 保持格式：
git add file1 file2 file3 && git commit -m "$(cat <<'EOF'
type(scope): subject line here
Optional body explaining why this change was made,
not just what changed.
EOF
)"
步驟 5：確認（Confirm）
在 commit 後執行 git status 驗證是否成功。回報 commit hash 以及主旨行。
