git-commit

git-commit 技能總覽

git-commit 的用途

git-commit 技能可協助你撰寫符合 Conventional Commits 的 commit message，並套用專案特有規則，例如必填 scope、使用現在式主詞、以及簡短且聚焦的摘要。它特別適合需要可靠 git-commit 指引的人，能把已 staged 的變更整理成符合該 repo 慣例的 commit message，而不是只給一個通用提示詞。

適合哪些人使用

如果你的工作流程很重視 commit 品質，就適合使用 git-commit 技能：例如 feature branches、共享 repo、release notes、changelog 自動化，或是要求歷史紀錄一致性的團隊。當你已經知道改了什麼，但還需要協助把變更整理成正確的 type(scope): subject 形式時，這個技能尤其有用。

它為什麼不一樣

git-commit for Git Workflows 的主要價值，不只是提供一個範本而已。它會先促使你檢查 repository 自己的慣例、閱讀最近的 commit 以找出本地模式，並讓 commit 的寫法與專案既有的歷史紀錄風格一致。這能降低「語法上沒錯、但對這個 codebase 來說不合群」的 commit 風險。

如何使用 git-commit 技能

安裝 git-commit

在你的 skills manager 裡執行安裝指令：npx skills add fvadicamo/dev-agent-skills --skill git-commit。若要執行 git-commit install，先確認 skill 已存在於 repo 路徑 skills/git-commit，再於實際的 commit 流程中使用前開啟 SKILL.md。

先提供正確的輸入

git-commit usage 最適合你提供三項資訊：哪些檔案有變更、這次變更達成什麼目的，以及 repo 是否在 CLAUDE.md 裡有自己的 commit 規則。若你只說「幫我做 commit」，技能就得自己猜 scope 和 message。更好的請求會像這樣：「我修改了 auth token 驗證和測試；請建立一個 scope 為 auth、主旨簡潔的 Conventional Commit。」

先讀這些檔案

先從 SKILL.md 開始，再查看 references/commit_examples.md，了解不同 type 的模式與好壞對照。如果 repository 有 CLAUDE.md，在複製任何範例之前，先以它作為唯一準則。這是最快理解 git-commit skill 實際上如何看待 scope、body 內容與 message 長度的方式。

把零散變更整理成 commit 提示詞

把雜亂的 status 轉成可直接用來做 commit 的簡報：寫出子系統、使用者可感知的影響，以及適合放進 body 的 task 或 requirement ID。比如，不要只說「修了 bug」，而要說「修正下載流程中的逾時處理；使用 fix(download)，並提到重試行為」。這種具體程度能提升 message 品質，也能避免產生違反 git-commit 指南規則的泛泛輸出。

git-commit 技能常見問題

這會取代一般的 commit 提示詞嗎？

不會。一般提示詞也可能產生不錯的 message，但 git-commit 的設計重點，是要落實 repo 的 commit 紀律，包括必要的 scope 和 subject 風格。當你希望 git-commit 的格式能穩定重現、並減少 commit 整理時的來回修改，它會更適合。

對新手友善嗎？

如果你已經了解 staged changes 和基本 Git 概念，那就算友善。這個技能能提供一條清楚路徑，從「我改了檔案」到「我需要一個像樣的 commit」，但新手仍然要知道哪些變更應該併在同一個 commit，哪些應該拆開。如果你的變更混雜了互不相關的功能，請先拆分再使用這個技能。

什麼情況下不該用？

如果 repository 沒有 commit 慣例，或者團隊刻意偏好自由格式的 message，就不要用它。對於大型且混合多種修改的 diff、而你又還沒決定怎麼分組工作時，它也不適合。這些情況下，先把變更整理好，再套用 git-commit 技能。

它對團隊工作流程有什麼幫助？

這個技能能讓 commit 歷史更容易被 reviewer、release 工具，以及未來除錯時閱讀。因為它會檢查專案特有慣例並參考最近的 commit，所以對重視一致歷史紀錄與 Conventional Commits 相容性的團隊來說，比萬用模板更有價值。

如何改進 git-commit 技能

提供更乾淨的變更摘要

最好的 git-commit 結果，來自精準的變更摘要，而不是模糊描述。請包含受影響的範圍、實際行為改變，以及任何限制條件。例如，「更新 cookie 處理，拒絕無效網域並新增測試」就比「做了一些 auth 變更」好。這能幫助技能選對 type、scope 和 body。

對齊專案的本地慣例

要提升 git-commit 輸出的關鍵，是在接受第一版前先檢查 CLAUDE.md 和最近的 commits。如果專案使用特殊 scopes、body 註記或 requirement 參照，請把這些資訊直接放進請求裡。這個技能本來就是為了遵循專案規則而設計，所以輸入越完整，後續需要清理的內容就越少。

留意常見失敗模式

大多數品質不佳的 commit message，問題都差不多：scope 太大、subject 太籠統，或把多個互不相關的變更塞進同一行。另一個常見問題是忽略 50 字元的 subject 長度限制。如果輸出看起來太空泛，就要求它縮小範圍，只聚焦在一個明確的工作單位上。

從草稿迭代到定稿

先把第一版輸出當成候選稿，再對照實際 diff 做調整。檢查 scope 是否命中了正確的子系統、subject 是否使用現在式命令語氣的動詞，以及 body 是否提供了超出 subject 的資訊。這種迭代方式，正是 git-commit skill 在 Git Workflows 中最有價值的地方：它能把粗略的 commit 想法，整理成你真的願意留在歷史紀錄裡的 message。