commit-plan

コミット計画ルール

このスキルの目的

計画を立てる作業すべてで、実装ステップと対になるコミット計画を含める。Claude の plan モード（ExitPlanMode で提示する plan）に限らず、計画ドキュメント・並列作業のタスク分解（parallel-worktree の spec・各エージェントへの指示文）など、計画を成果物として書き出す場面すべてが対象。実装ステップだけの計画で実装に入らない。

コミットの実施（素材収集・メッセージ確定・git commit 実行）は本スキルの範囲外で、commit-flow スキルが担う。

1. コミット計画を計画成果物に明示する

実装ステップと対になる「コミット計画」セクションを計画成果物に組み込む。

• plan モード: ExitPlanMode で提示する plan 本文に含める。含まれていない状態で実装に入らない。
• plan モード外の計画（計画ドキュメント・タスク分解 spec・サブエージェントや他エージェントへの指示文）: 同じ形式のコミット計画を成果物内に含める。plan モードでないことを省略の理由にしない。

## 実装ステップ
1. ドメインモデルに `Foo` を追加
2. リポジトリ層に永続化メソッドを追加
3. ユースケース層から呼び出し
4. テスト追加

## コミット計画
1. `feat(domain): Foo モデルを追加`
2. `feat(infra): FooRepository に永続化メソッドを追加`
3. `feat(usecase): Foo 永続化ユースケースから呼び出し`
4. `test(usecase): Foo 永続化のユースケーステストを追加`

2. 並列作業ではタスク単位に計画する

parallel-worktree 等で作業を並列タスクへ分解するときは、コミット計画もタスク（ブランチ／エージェント）単位で立て、各タスクの指示文（spec の prompt 等）へ含める。タスク間で 1 つのコミット計画を共有しない（ブランチが別なら履歴も別）。各タスク内の粒度は §5 の基準に従う。

3. 粒度判定は計画段階で済ませる

§5 の基準を立案時に適用する。「実装してみないと粒度が分からない」と先送りしない。

4. コミット数を理由に統合しない

分割か統合か未確定で残す場合、粒度に意味があるなら分割を推奨案として書く。コミット数増加はレビュアー追跡性・ロールバック容易性を確保するメリットの方が大きい。

5. コミット粒度の判断基準

分割する: 別の関心事／片方だけ revert したくなる可能性／別 discussion・別 issue の対応。 統合する: 同じ論理変更を機械的に行数で割っただけ／片方だけ戻すと壊れる／同じ discussion 内の一連の修正。

「コミット数が増えるから 1 つにまとめる」は採用しない。

6. 計画時のメッセージ形式

計画に書くメッセージは Conventional Commits 1.0.0 の 1 行形式:

<type>(<scope>): <description>

主要 type: feat / fix / refactor / test / docs / chore / build / ci / perf / style / revert

計画段階ではこの 1 行があれば足りる。body／footer・破壊的変更の書き方・type 選択の詳細は、実施時に commit-flow スキルの references/conventional-commits.md で判断する。

関連スキル

• commit-flow: コミットの実施（素材収集スクリプト・メッセージ確定・粒度の実施時判断・git commit 実行）
• parallel-worktree: 並列タスク分解時、§2 に従いタスク単位のコミット計画を各エージェントの指示文へ含める