| name | backend-commit-splitter |
| description | 未コミットの変更を依存関係と関心事に基づいて適切な粒度のコミットに分割する。自動生成物・手動実装・テスト・ドキュメントを分離し、レビューしやすい履歴を作る。「コミット分けて」「良い粒度でコミット」「この変更コミットにして」などで起動。 |
Commit Splitter
未コミットの変更を、レビュアーが順に追える粒度 で分割する。プロジェクト非依存の汎用スキル。
参照ファイル
実行手順
1. 現状確認
git status で変更ファイル一覧を取得git diff と git diff --cached で内容確認git log --oneline -10 で既存のメッセージスタイル（日本語/英語、Conventional Commits の有無、プレフィックスの流儀）を把握
2. 分類
変更を以下のカテゴリに分ける。
- 自動生成物 — codegen, lock file, 生成されたスキーマ等
- 設定変更 — tool-versions, package.json の依存追加, lint 設定等
- スキーマ/データ層 — DB スキーマ, proto, GraphQL schema, 型定義
- 実装 — ビジネスロジック, ハンドラ, サービス
- テスト — ユニット, インテグレーション, E2E
- ドキュメント — README, コメント整備, 仕様書
- リファクタ — 挙動を変えない整理
- バグ修正 — 既存挙動の修正
3. 分割方針
principles.md の「粒度の原則」「順序の原則」に従って分割する。要点のみ再掲:
- 1 コミット = 1 つの論理的変更
- ビルドが通る単位 で切る（各コミット単独で CI がグリーンになるのが理想）
- 自動生成と手動実装を分ける（レビュー時に「生成物を飛ばして読める」ように）
- リファクタと機能追加を混ぜない
- スキーマ → 実装 → テスト → ドキュメント の依存順で並べる
4. ユーザー確認
分割案を提示して承認を得る。この時点では まだコミットしない。
提案する分割:
1. [設定] xxx の依存追加
2. [自動生成] yyy.pb.go の再生成
3. [実装] zzz ハンドラの追加
4. [テスト] zzz のユニットテスト追加
順序の根拠: ...
この分割で進めて良いですか？
5. 実行
承認後、以下を各コミットについて繰り返す。
- 対象ファイルだけ
git add <path>（git add . や -A は 使わない）
git commit -m "..." でメッセージ作成（HEREDOC 推奨）- 最後に
git log --oneline で結果確認
6. メッセージ規約
- 既存履歴のスタイルに合わせる（日本語/英語、プレフィックス）
- 迷ったら Conventional Commits (
feat:, fix:, refactor:, test:, docs:, chore:)
- 件名は 50 文字程度、本文が必要なら空行を空けて理由を書く
- WHAT ではなく WHY を書く（差分を見れば WHAT はわかる）
やらないこと
--no-verify でのフック回避（明示的な指示がない限り）git add -A / git add .（意図しないファイル混入防止）- 既存コミットの amend（履歴を書き換えるのは別スキル
commit-rebase の役割）
- 推測でのメッセージ作成（内容を実際に読んでから書く）
