| name | git-commit |
| description | git差分を分析し、フォーマットに従ったコミットを自動作成する。 |
Git Commit Helper
git の変更内容を分析し、適切なコミットメッセージを生成し、自律的にコミットを実行するスキルです。サブエージェントを使わず、このスキル内で完結して処理します。
- 対象範囲はデフォルトでワーキングツリー・staged 双方の全差分。引数
work(ワーキングツリーのみ)/stage(stagedのみ)で範囲を限定できる
- そのセッションで編集したかどうかは問わず、リポジトリの現在の git 状態にある差分ファイルすべてが対象。ただし並行する別セッションを検出したときは、このセッションで編集したファイルだけに絞る(Phase 1)
- ブランチは確認しない。main ブランチでも確認なしでコミットしてよい
- コミット実行前のユーザー承認は求めない。コミット分割の判断にどうしても迷った場合のみ
AskUserQuestion で確認してよいが、基本は自律的に判断してコミットする
本スキルの役割と参照先
[!IMPORTANT]
(AI・必須) コミットメッセージの内容(なぜを書く・件名フォーマット・(#issue番号)・本文の要否)、粒度、ブランチ命名、rebase 禁止といったルールはすべて docs/policy/git-policy.md で定義される。本スキルはそれを実行する手順だけを定義する。ルール本文はここに再掲しない(二重管理を避けるため)。判断に迷ったとき・本スキルの記述とポリシーが食い違うときは、常に git-policy.md を正とする。
作業開始前に git-policy.md を読み、以下のセクションを参照しながら進めること:
- 件名・本文の書き方 → 「コミットの書き方」「issue対応時のコミットメッセージ」
- 本文に「なぜ」を書くかの判断 → 「『なぜ』をどこに書くか(本文とissueの使い分け)」
- 分割の基準 → 「コミットの粒度」
- type / ブランチ prefix の語彙 → 「ブランチ命名規則」の表
処理フロー
Phase 1:対象範囲の決定と変更内容の取得
引数に応じて対象範囲を決定する:
| 引数 | 対象範囲 |
|---|
| なし(デフォルト) | ワーキングツリー・staged 双方の差分 |
work | ワーキングツリー(未ステージ)の差分のみ |
stage | staged の差分のみ |
並行セッションを検出する
同じ作業ツリーを別の Claude セッションが編集していると、既定スコープは無関係な変更まで巻き込む。巻き込まれた側は自分の作業が別 Issue のコミットに紛れたことに気づけない。そこで、範囲を決めたらまず claude プロセスの数を数える。
ps -eo comm= | grep -cx claude
2以上なら並行セッションがある。このとき既定スコープを「このセッションで自分が Edit/Write したファイルのみ」に切り替える(引数 work / stage の指定も、この絞り込みの中で適用する)。切り替えたことと、除外したファイルのパスを Phase 5 の出力に列挙する。
1なら単独セッションなので、既定スコープをそのまま使う。
範囲を決めたら現在の状態を把握する。スコープに不要なコマンドは実行しない(work なら staged 側、stage なら worktree 側は取得不要)。依存関係のないコマンドは1回の Bash 呼び出しにまとめる:
git status --short
git diff --stat
git diff --cached --stat
git diff(内容)と git log --oneline は無条件に取得しない。Phase 2 の type 判定・Phase 3 の本文執筆で実際に必要になった時点で、必要な対象だけに絞って取得する(type がファイル名だけで判定できるならどちらも不要)。
ステータス出力の先頭2文字でステージ状態・変更タイプを判定する:
M file.ts # Modified(ステージ済み)
M file.ts # Modified(未ステージ)
A file.md # Added(ステージ済み)
?? file.txt # Untracked
Phase 2:Commit Type の判定
type の語彙は git-policy.md「ブランチ命名規則」の prefix 表に従う(末尾の / を除いたものが type)。まずファイル名・パス・ステータス(A/M)だけで判定を試み、それで確定しない場合のみ diff 内容を取得する:
| 材料 | type |
|---|
テストファイル(*.test.*, *.spec.*)のみ | test |
docs/ または *.md のみ | docs |
設定ファイル(package.json, tsconfig.json, *.config.* など)のみ | chore |
| CI・GitHub Actions の変更 | ci |
| ソースの新規追加(A)による機能拡張 | feat |
| ソースの修正(M)によるバグ修正 | fix |
| 振る舞いを変えない構造変更 | refactor |
A=feat・M=fix はあくまで目安。修正が機能追加のこともあるため、ファイル名だけでは判断がつかない場合に限り diff 内容(該当ファイルのみ)を読む。それでも判断に迷う場合や複数解釈がある場合は AskUserQuestion でユーザーに確認する。
Phase 2.5:コミット分割の判定
git-policy.md「コミットの粒度」(無関係なファイルを混ぜない)を実践する。ファイルを type × トップレベルディレクトリでグループ化し、2グループ以上に分かれる場合は分割して進める:
- 異なる type の混在(例:
docs と feat)→ type ごとに分割
- 異なるトップレベルディレクトリの混在 → ディレクトリごとに分割
- 同一 type・同一ディレクトリ → 原則1コミット
分割方針は基本的に自律的に決定する。グループ分けの妥当性にどうしても迷う場合のみ AskUserQuestion で確認してよい。
Phase 3:メッセージの生成
git-policy.md のルールに従って組み立てる。本スキルが担うのは「ポリシーを適用するための入力収集」である:
- 件名:
type: 説明。説明は変更内容が伝わるよう簡潔に(目安30文字以内)。
- issue番号:紐づく Issue があれば件名末尾に
(#番号) を付与する。番号はブランチ名等から推定し、不明な場合はユーザーに確認する。
- 本文(なぜ):本文を書くかどうかは git-policy.md「『なぜ』をどこに書くか」の表で判断する(issueに背景が十分なら省略可/issueに無い判断をした・issueなしなら理由を本文に書く)。書く場合はコードから読み取れない背景・判断理由を記す。
Phase 4:ステージング対象の決定
- Phase 1 で決定した範囲(デフォルト=work+stage全体、または
work/stage 指定範囲)に含まれるソース・ドキュメント・設定・テストの各変更ファイルを対象に含める。単独セッションなら、セッション内で編集したかどうかは問わない。
- 除外して警告表示:
.env*, node_modules/, dist/・build/, .DS_Store/Thumbs.db, *.log。並行セッションを検出したときは、このセッションで Edit/Write していないファイルも除外して警告表示する。
- デフォルト範囲かつ既にステージ済みのファイルは対象に含め、確認表示では
✓ を付ける。
Phase 5:コミット実行
ユーザー承認は求めず、自律的に実行する。グループごとに git add → git commit を行う。
=== Git Commit Summary ===
Commit Type: feat
Message: feat: アカウント同期処理の実装 (#42)
Committed Files:
✓ src/sync.ts
Excluded (warnings):
⚠ .env is ignored (environment file)
⚠ docs/guide/foo.html — 並行セッションを検出したため除外(このセッションで編集していない)
分割する場合は各コミットの Type・Message・対象ファイルを順に列挙する。
- 複数コミットの途中で失敗(pre-commit hook 等)した場合、成功済みコミットはロールバックしない。失敗したグループはステージされたまま残し、原因と再実行を促す。
- 完了後
git log --oneline -n <件数> で結果を表示する。
使用方法
/git-commit # デフォルト:ワーキングツリー+staged全差分が対象
/git-commit work # ワーキングツリー(未ステージ)のみ対象
/git-commit stage # stagedのみ対象