Smart Commit スキル

作業差分を分析し、論理的な単位でコミットを分割提案する。ユーザーの承認後、実際の git 操作（add / commit / push）も実行する。

ワークフロー

1. 差分の取得

# ステージング済み + 未ステージングの変更一覧
git status --short

# 未追跡ファイルを含む全差分
git diff HEAD

# 未追跡の新規ファイル内容
git diff --no-index /dev/null <file>  # 新規ファイルごとに実行

2. 変更の分類

各ファイルの変更内容を分析し、以下の観点でグルーピングする:

• •機能単位: 同じ機能に関する変更はまとめる（例: コントローラ + テスト + ルーティング）
• •関心の分離: 設定変更、リファクタリング、新機能、バグ修正は分ける
• •依存関係: 後のコミットが前のコミットに依存する場合、依存される側を先にする

分割の粒度ガイドライン

• •1コミット = 1つの論理的変更（「なぜこの変更をしたか」を1文で説明できる単位）
• •設定ファイルの変更（Gemfile, package.json 等）は関連する機能変更と同じコミットに含める
• •テストは対応する実装と同じコミットにする
• •リンティング修正やフォーマット変更は独立したコミットにする
• •ファイル削除は、その理由となる変更と同じコミットにまとめる

3. コミットメッセージの生成

プロジェクトのコミットプレフィックス規約に従う: fix:, add:, feat:, update:, change:, refactor:, remove:, test:, chore:, docs:

メッセージは変更の「なぜ」を簡潔に記述する。日本語・英語はプロジェクトの慣習に合わせる。

4. 提案の出力

以下のフォーマットで出力する:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
コミット 1/N
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
メッセージ: <prefix>: <コミットメッセージ>

対象ファイル:
  A  path/to/new-file.ts
  M  path/to/modified-file.rb
  D  path/to/deleted-file.ts

変更概要: <このコミットで何をしたかの1行説明>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ステータス記号: A = 新規追加, M = 変更, D = 削除

全コミットの出力後、実行用の git コマンド一覧も表示する:

# コミット 1/N: <メッセージ>
git add <files...>
git commit -m "<prefix>: <メッセージ>"

# コミット 2/N: <メッセージ>
git add <files...>
git commit -m "<prefix>: <メッセージ>"

5. フィードバック対応

提案後、ユーザーからの調整リクエストに対応する:

• •コミットの統合・分割
• •メッセージの修正
• •ファイルの振り分け変更

調整が完了したら、更新された git コマンド一覧を再出力する。

6. コミットの実行

提案内容についてユーザーの承認を得たら、提案した順序で git add / git commit を実行する。 承認前に勝手にコミットしてはならない。必ずユーザーの明示的な承認（「OK」「実行して」「コミットして」等）を待つこと。

7. プッシュ

すべてのコミットが完了したら、現在のブランチをリモートにプッシュする。

git push -u origin $(git branch --show-current)

注意事項

• •ユーザーの承認なしに git add / git commit / git push を実行しない
• •サブモジュール内の変更がある場合は、サブモジュール側とメインリポジトリ側でコミットを分けて提案する
• •$ARGUMENTS が指定された場合、それを変更の背景コンテキストとして活用する