| name | commit-flow |
| user-invocable | true |
| argument-hint | [コミット対象の範囲や粒度の指示(任意)] |
| description | gitコミット運用ルール。**主目的は論理的に独立した修正を都度・適切な粒度でコミットすること**、および plan モードで実装計画を立てる際に必ずコミット計画を plan 本文に含めること。メッセージ形式は Conventional Commits。「コミットして」「コミット分けて」「コミット計画を立てて」「分けてコミット」「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画」と依頼される、`git commit`を実行する、ExitPlanMode 前に plan を提示する、複数の独立した修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase/squash で履歴を整える、`gh pr create`時にPRタイトルをコミット流儀に揃える等の場面で必ず参照する。変更を約30〜50行の論理単位へ分割してコミットを積む実務手順は micro-commit スキル側が担い、本スキルは粒度の判断基準・plan 段階のコミット計画・メッセージ規約を定める(併用時は本スキルの基準で分割単位を決め、micro-commit で実行する)。 |
コミット運用ルール
このスキルの目的
優先度順:
- 論理的に独立した修正は都度コミットする（最重要）
- plan モードで実装計画を立てる際は、plan 本文に必ずコミット計画を含める
- コミットメッセージは Conventional Commits 形式で書く
メッセージ書式より粒度と都度コミットが本質。
1. plan モードでの責務
plan モードで実装計画／リファクタリング計画／レビュー対応計画を立てる際は、以下を必ず行う。
1.1 コミット計画を plan 本文に明示する
実装ステップと対になる「コミット計画」セクションを plan に組み込む。ExitPlanMode で提示する plan に含まれていない状態で実装に入らない。
## 実装ステップ
1. ドメインモデルに `Foo` を追加
2. リポジトリ層に永続化メソッドを追加
3. ユースケース層から呼び出し
4. テスト追加
## コミット計画
1. `feat(domain): Foo モデルを追加`
2. `feat(infra): FooRepository に永続化メソッドを追加`
3. `feat(usecase): Foo 永続化ユースケースから呼び出し`
4. `test(usecase): Foo 永続化のユースケーステストを追加`
1.2 粒度判定は plan 段階で済ませる
§3 の基準を立案時に適用する。「実装してみないと粒度が分からない」と先送りしない。
1.3 コミット数を理由に統合しない
分割か統合か未確定で残す場合、粒度に意味があるなら分割を推奨案として書く。コミット数増加はレビュアー追跡性・ロールバック容易性を確保するメリットの方が大きい。
2. 実装時の都度コミット
plan のコミット計画に従い、各単位で 編集 → テスト → git commit を 1 サイクルとして繰り返す。次の作業に進む前に必ず前のコミットを確定させ、一括編集→git stash/部分 add での後分割はしない。
plan にコミット計画が無くても、論理的に独立した複数の修正（複数レビューコメント対応・複数の独立バグ修正など）は原則として個別コミット。例外はユーザーから「一括でやって」「後でまとめて」と明示指示された場合のみ。
2.1 検証ゲートとコミットはコマンドを分ける
サイクル中の「テスト」（検証ゲート）と git commit を同じシェル行に繋がない。検証 | tail && git commit はパイプ全体の exit が tail の成功で 0 になり、検証が赤でもコミットが走る（赤いゲートのままコミットが本流へ入る再発事例が実際に複数ある）。検証; git commit も ; が失敗を無視するので同罪。まず検証だけを実行して exit 0 を確認し、別コマンドでコミットする。1行に書くなら if <検証コマンド>; then git commit ...; fi の形で、パイプの出力整形をゲート判定に混ぜない。
3. コミット粒度の判断基準
分割する: 別の関心事／片方だけ revert したくなる可能性／別 discussion・別 issue の対応。
統合する: 同じ論理変更を機械的に行数で割っただけ／片方だけ戻すと壊れる／同じ discussion 内の一連の修正。
「コミット数が増えるから 1 つにまとめる」は採用しない。
4. 適用判断
- 単独コミット・PR 内コミット・squash 前のコミット全てに本ルール（特に §1〜§3）を適用
- マージコミット（
Merge branch ...）は Git 自動生成のため対象外
- リバートコミット（
git revert 自動生成）は接頭辞 revert: のまま使える
- rebase / squash / cherry-pick で履歴を整える際も、結果のメッセージは §5 に揃える
5. メッセージフォーマット（Conventional Commits）
Conventional Commits 1.0.0 に従う。形式:
<type>(<scope>): <description>
主要 type: feat / fix / refactor / test / docs / chore / build / ci / perf / style / revert
詳細（type 一覧の解説、body／footer、破壊的変更の書き方、例、アンチパターン）は references/conventional-commits.md を参照。type 選択に迷う・破壊的変更を含む・PR タイトル整形時など、書式判断が必要な場面で読み込む。
6. セッションURLを含めない
Claude Code の既定動作はコミットメッセージ末尾に Claude-Session: <URL> のようなセッションへのリンク行を付与するが、このリポジトリでは付与しない。ローカル CLI・remote-control のどちらのセッションでも、コミットメッセージは本文（type/scope/description・必要な body・footer）のみで完結させ、セッションURLの行は書かない。
7. 完了条件
§1〜6 を満たし、対象の変更に未コミット差分が残っていない状態で完了とする。
