Commit plan

Skill yasunori0418/skills/skills/git/commit-plan

実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや parallel-worktree のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション（論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ）が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施（素材収集・メッセージ確定・git commit 実行）は commit-flow スキルが担う。From its SKILL.md

Install

npx -y skills add yasunori0418/skills --skill commit-plan

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.0 KB, as published. Nobody here has run it

コミット計画ルール

このスキルの目的

計画を立てる作業すべてで、実装ステップと対になるコミット計画を含める。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 で判断する。