選項

使用清晰傳達價值的資訊建立 git 提交。當使用者要求以與倉庫相符且能傳達價值的資訊提交/儲存已暫存或未暫存的更改時,使用此操作。

...展開全部
15
更新時間 2026-08-26

關於 ce-commit

一個工作流,用於從當前工作樹生成單個、精心製作的 Git 提交,其提交資訊在存在倉庫約定時傳達價值並遵循倉庫約定,否則遵循常規提交格式。當使用者要求提交、儲存更改或從暫存或未暫存的更改建立提交時,該工作流即被啟用。在 Claude Code 上,它直接消耗預填充的 Git 狀態、工作樹差異、當前分支、最近提交和遠端預設分支部分;在其他平臺上,它執行單個回退命令以收集相同的上下文。

該工作流分五個步驟執行。第一步收集上下文並處理邊緣情況:乾淨的樹意味著沒有可提交的內容,而分離的 HEAD 會透過平臺的阻塞問題工具提示使用者是否建立功能分支。第二步按優先順序確定訊息約定,優先採用文件化的倉庫約定,然後是從最近十個提交中推斷出的模式,否則採用形式為 type scope description 的常規提交,型別包括 feat、fix、docs、refactor、test、chore、perf、ci、style 和 build;當 fix 和 feat 均適用時,預設選擇 fix。第三步輕度考慮將明顯不同的關注點拆分為單獨的提交,僅在檔案級別進行分組,並將兩個或三個邏輯提交視為最佳數量。

第四步進行暫存和提交,如果當前分支是 main、master 或解析後的預設分支,則自動先建立功能分支,而不是在預設分支上提交。訊息使用簡潔的祈使句主題,側重於“為什麼”而非“是什麼”,可選正文用於非瑣碎的更改;暫存操作優先命名特定檔案,而不是使用 git add all,以避免包含敏感檔案;提交使用 heredoc 編寫以保留格式。第五步透過執行 git status 並報告生成的提交雜湊和主題行來確認成功。

常見問題

它預設使用什麼提交訊息格式?

它優先採用文件化的倉庫約定,然後是從最近十個提交中推斷出的模式,否則回退到形式為 type scope: description 的常規提交。

它會在 main 分支上直接提交嗎?

不會。如果當前分支是 main、master 或解析後的預設分支,它會自動先建立功能分支,然後再提交。

它何時選擇 fix 而非 feat?

當兩者似乎都適用時,預設選擇 fix,將修復損壞或缺失行為的變化視為 fix,並將 feat 保留給真正的新功能。

它會將更改拆分為多個提交嗎?

它會輕度掃描明顯不同的關注點,並可能建立僅在檔案級別分組的單獨提交,其中兩個或三個邏輯提交被視為最佳數量。

它如何避擴音交敏感檔案?

它優先按名稱暫存特定檔案,而不是使用 git add -A 或 git add .,以避免意外包含 .env 或憑據等檔案。

在 GitHub 上查看

Create well-crafted local commit(s) from the current working tree. No push, no PR — use ce-commit-push-pr for the full ship flow.

Done when: each logical change is committed with an explicit file list and a message that states the outcome, and git status is clean of those changes. Stop when: the tree is clean (nothing to commit).

Context

Gather context with each command as its own shell tool call (program + args only). Do not join with ;, &&, ||, pipes, $(...), or redirects — that syntax fails under Windows PowerShell. A non-zero exit is a normal state to interpret, not a failure to suppress.

CommandPurposeNon-zero / empty means
git statusWorking-tree stateNot a git repo — stop
git diff HEADUncommitted changesUnborn repo / no commits yet
git branch --show-currentCurrent branchEmpty = detached HEAD
git log --oneline -10Recent message styleUnborn repo — no history
git rev-parse --abbrev-ref origin/HEADRemote default branchNo origin/HEAD / bare HEAD — try gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name', else main

Treat this as a snapshot. Re-read branch and staged set immediately before committing if anything may have changed.

Default branch name: strip a leading origin/ from origin/HEAD (so origin/trunktrunk). Use that bare name for all “on the default branch?” checks — never compare against origin/<name>.

Workflow

  1. Gather — run every Context command above (own shell call each), then continue.

  2. Nothing to commit — if git status shows no staged, modified, or untracked files, report that and stop. Do not use git diff HEAD alone as cleanliness (it misses untracked files).

  3. Branch first — if detached HEAD, or on the default branch (main / master / the bare default name above), create a feature branch from the change content (git checkout -b <name>), then re-read git branch --show-current. Do not ask — commit-only still must not leave work only on a detached HEAD or the default branch. If the derived name exists, pick a non-conflicting suffix.

  4. Convention — match project commit conventions already in context; else match the recent log pattern; else conventional commits (type(scope): description). When using conventional commits and fix/feat both fit, default to fix: (remedying broken or missing behavior); reserve feat: for new capabilities. User override wins.

  5. Logical commits — if changed files clearly split into distinct concerns, make separate commits (file level only, 2–3 max, no git add -p). If ambiguous, one commit.

  6. Message — subject is imperative and names the outcome (what is now possible or fixed), not the file list. Body only when motivation or trade-offs are not obvious from the subject. When a plan Implementation Unit ID is already in hand for this commit (conversation, caller, or the files belong to one unit), append that unit's U-ID in parentheses — (U3) means unit 3. Do not hunt for a plan. Omit when the commit spans units, the unit is unclear, or no plan is in hand.

    • Bad: Update checkout.rb / Add tests and fix stuff
    • Good: Fix double-submit on checkout
    • Good: Add per-subscription mute (U3)
  7. Stage and commit — stage named files only (never git add -A or git add .). Honor exclude:<paths> when the invocation carries it: those files stay uncommitted no matter what else changed; say in the report that they were left out. Prefer one shell call per commit group:

git add file1 file2 file3 && git commit -m "$(cat <<'EOF'type(scope): subject line hereOptional body when the why is not obvious from the subject.EOF)" -- file1 file2 file3

The trailing path list on git commit is load-bearing: a bare git commit takes the whole index, so anything already staged before this run (a caller's exclude: paths, or work the user staged and did not name) would ride into the commit. Naming the paths commits exactly the group and leaves other index entries alone.

  1. Confirm — git status; report hash(es) and subject(s).

所有檔案

0 個檔案

安裝 ce-commit

將技能檔案下載並解壓至 .claude/skills/ 目錄。

下載 ZIP

複製儲存庫並將技能檔案複製到您的專案中。

git clone https://github.com/EveryInc/compound-engineering-plugin/blob/main/skills/ce-commit/SKILL.md # Copy SKILL.md to your .claude/skills/ directory

複製 複製
快速設定: 將技能資料夾複製到 .claude/skills/,Claude 將自動檢測並使用該技能

相關技能

github-project-management
更新時間 2026-06-29
using-git-worktrees
更新時間 2026-06-29
readme-blueprint-generator
更新時間 2026-07-05
finishing-a-development-branch
更新時間 2026-06-29
OR