git-commit

# Git Commit Helper git の変更内容を分析し、適切なコミットメッセージを生成し、自律的にコミットを実行するスキルです。サブエージェントを使わず、このスキル内で完結して処理します。 - 対象範囲はデフォルトでワーキングツリー・staged 双方の全差分。引数 `work`（ワーキングツリーのみ）／`stage`（stagedのみ）で範囲を限定できる - そのセッションで編集したかどうかは問わず、リポジトリの現在の git 状態にある差分ファイルすべてが対象。ただし並行する別セッションを検出したときは、このセッションで編集したファイルだけに絞る（Phase 1） - ブランチは確認しない。main ブランチでも確認なしでコミットしてよい - コミット実行前のユーザー承認は求めない。コミット分割の判断にどうしても迷った場合のみ `AskUserQuestion` で確認してよいが、基本は自律的に判断してコミットする ## 本スキルの役割と参照先 > [!IMPORTANT] > **（AI・必須）** コミットメッセージの内容（なぜを書く・件名フォーマット・`(#issue番号)`・本文の要否）、粒度、ブランチ命名、rebase 禁止といった**ルールはすべて [docs/policy/git-policy.md](../../../docs/policy/git-policy.md) で定義される**。本スキルはそれを**実行する手順だけ**を定義する。ルール本文はここに再掲しない（二重管理を避けるため）。判断に迷ったとき・本スキルの記述とポリシーが食い違うときは、**常に git-policy.md を正とする**。 作業開始前に git-policy.md を読み、以下のセクションを参照しながら進めること： - 件名・本文の書き方 → 「コミットの書き方」「issue対応時のコミットメッセージ」 - 本文に「なぜ」を書くかの判断 → 「『なぜ』をどこに書くか（本文とissueの使い分け）」 - 分割の基準 → 「コミットの粒度」 - type / ブランチ prefix の語彙 → 「ブランチ命名規則」の一覧 ## 処理フロー ### Phase 1：対象範囲の決定と変更内容の取得 引数に応じて対象範囲を決定する： - **なし（デフォルト）**：ワーキングツリー・staged 双方の差分 - `work`：ワーキングツリー（未ステージ）の差分のみ - `stage`：staged の差分のみ #### 並行セッションを検出する 同じ作業ツリーを別の Claude セッションが編集していると、既定スコープは無関係な変更まで巻き込む。巻き込まれた側は自分の作業が別 Issue のコミットに紛れたことに気づけない。そこで、範囲を決めたらまず claude プロセスの数を数える。 ```bash ps -eo comm= | grep -cx claude # 自分を含む claude CLI のプロセス数（起動フラグに依存しない） ``` 2以上なら並行セッションがある。**このとき既定スコープを「このセッションで自分が Edit/Write したファイルのみ」に切り替える**（引数 `work` / `stage` の指定も、この絞り込みの中で適用する）。切り替えたことと、除外したファイルのパスを Phase 5 の出力に列挙する。 1なら単独セッションなので、既定スコープをそのまま使う。 範囲を決めたら現在の状態を把握する。**スコープに不要なコマンドは実行しない**（`work` なら staged 側、`stage` なら worktree 側は取得不要）。依存関係のないコマンドは1回の Bash 呼び出しにまとめる： ```bash git status --short # 常に取得 git diff --stat # スコープが「なし」または work のときのみ git diff --cached --stat # スコープが「なし」または stage のときのみ ``` `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 内容を取得する**： - **テストファイル（`*.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 のルールに従って組み立てる。本スキルが担うのは「ポリシーを適用するための入力収集」である： 1. **件名**：`type: 説明`。説明は変更内容が伝わるよう簡潔に（目安30文字以内）。 2. **issue番号**：紐づく Issue があれば件名末尾に `(#番号)` を付与する。番号はブランチ名等から推定し、**不明な場合はユーザーに確認する**。 3. **本文（なぜ）**：本文を書くかどうかは 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：コミット実行 ユーザー承認は求めず、自律的に実行する。グループごとに、次の手順を順に行う。 **1. ステージする**：Phase 4 で決めた対象ファイルのパスを明示して `git add <パス>...` する（`-A` や `.` を使わない）。 **2. index を突き合わせる**：ステージ済みの一覧を取り、Phase 4 の対象リストと一致するか確認する。 ```bash git diff --cached --name-only ``` - **対象外のパスが混じっている**：別セッションが staged にしたもの。`git reset` で外さない（相手の index を壊す）。手順3のパス指定でコミット対象から外れるので、除外したパスとして出力に列挙する - **対象のパスが出てこない**：別セッションが先にコミットした可能性がある。`git log --oneline -3` と `git show --stat <hash>` で取り込み済みか確かめ、済んでいればグループから外す **3. コミットする**：対象パスを `--` の後ろに並べ、index 全体ではなくそのパスだけをコミットする。 ```bash git commit -m "<件名>" -- <対象パス>... ``` パス指定を省くと、index に載った他セッションの変更ごとコミットされる。Phase 1 でスコープを正しく絞っても実行段階で巻き込むので、ここは AI の判断に委ねず常にパスで縛る。 このコマンドは index を経由せず作業ツリーの内容をコミットする。手順1のステージ後にファイルを直していると、index には古い内容が残り、次のコミットがそれを拾う。コミット後に `git status --short` を見て、対象ファイルが残っていたら `git add <パス>` で index を揃える。 ファイルの一部だけをステージしているときは、pre-commit hook がそのファイルの prettier 整形と再ステージを見送る（`git add <パス>` が未ステージの変更ごとコミットに混ぜてしまうため）。整形の取りこぼしは push 後の `ci-format` が拾う。 ``` === 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のみ対象 ```