オプション

明確で価値を伝えるメッセージを含む git コミットを作成します。ユーザーがリポジトリに適切な、価値を伝えるメッセージとともにステージ済みまたはステージ未変更の変更をコミット/保存するよう依頼した場合に使用します。

...すべて拡張します
15
更新された時間 2026年8月26日

ce-commit について

現在のワーキングツリーから、単一の、精心された git コミットを作成するためのワークフローです。リポジトリの規約が存在する場合はそれに従い、そうでない場合は conventional commit 形式に従い、価値を伝えるメッセージを生成します。ユーザーがコミット、変更の保存、またはステージ済みまたはステージ未済みの作業からのコミット作成を要求した際にアクティブ化されます。Claude Code 上では、事前に入力された git ステータス、ワーキングツリー差分、現在のブランチ、最近のコミット、およびリモートのデフォルトブランチセクションを直接消費し、他のプラットフォーム上では、同じコンテキストを取得するために単一のフォールバックコマンドを実行します。

このワークフローは 5 つのステップで実行されます。ステップ 1 ではコンテキストを取得し、エッジケースを処理します:クリーンなツリーとはコミットするものが何もないことを意味し、デタッチド HEAD では、プラットフォームのブロッキング質問ツールを通じて、フィーチャーブランチの作成についてユーザーに確認します。ステップ 2 では、優先順位に基づいてメッセージの規約を決定します。文書化されたリポジトリの規約を最優先し、次に直近 10 件のコミットから推測されたパターン、その後、type scope description という形式の conventional commits(type には feat, fix, docs, refactor, test, chore, perf, ci, style, build などがある)にフォールバックします。fix と feat の両方が該当する場合、デフォルトでは fix を採用します。ステップ 3 では、明確に異なる懸念事項を別々のコミットに分割することを軽く検討し、ファイルレベルでのみグループ化し、2〜3 件の論理的コミットがベストバランスと考えます。

ステップ 4 ではステージングとコミットを実行し、現在のブランチが main、master、または解決されたデフォルトブランチの場合、デフォルトブランチ上でコミットするのではなく、まず自動的にフィーチャーブランチを作成します。メッセージは、何をではなく、なぜに焦点を当てた簡潔な命令形の見出しを使用し、大規模な変更には任意の本文を含めます。ステージングでは、機密性の高いファイルを巻き込まないよう、git add all ではなく特定のファイル名を指定することを優先します。コミットは書式を保持するためにヒアドキュメントを使用して記述されます。ステップ 5 では、git status を実行して成功を確認し、結果のコミットハッシュと見出しを報告します。

FAQ

デフォルトで使用されるコミットメッセージの形式は何ですか?

文書化されたリポジトリの規約を最優先し、次に直近 10 件のコミットから推測されたパターンを採用し、それ以外の場合は type: scope description という形式の conventional commits にフォールバックします。

main ブランチ上で直接コミットしますか?

いいえ。現在のブランチが main、master、または解決されたデフォルトブランチの場合、コミットする前に自動的にフィーチャーブランチを作成します。

fix と feat のどちらを選択しますか?

両方が該当する場合、デフォルトでは fix を採用し、壊れたまたは欠落した動作を修正する変更を fix として扱い、本当に新しい機能に対して feat を予約します。

変更を複数のコミットに分割しますか?

明確に異なる懸念事項を軽くスキャンし、ファイルレベルでのみグループ化された別々のコミットを作成する場合があります。2〜3 件の論理的コミットがベストバランスと考えられます。

機密性の高いファイルのコミットをどのように回避しますか?

.env や資格情報などのファイルを誤って含めないよう、git add -Agit add . を使用するのではなく、ファイル名を指定して特定のファイルをステージングすることを優先します。

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年6月29日
using-git-worktrees
更新された時間 2026年6月29日
readme-blueprint-generator
更新された時間 2026年7月5日
finishing-a-development-branch
更新された時間 2026年6月29日
OR