Suggest commit

docs/git_commit_message_guidelines.md の規約に従って、現在の変更内容に適したコミットメッセージを提案してください。

入力

追加スコープヒント（任意）: $ARGUMENTS

1. 変更内容を取得する

# ステージ済みの変更
git diff --cached --stat
git diff --cached

# 未ステージの変更（参考）
git diff --stat

# 直近のコミット（文体・スコープの参考）
git log --oneline -5

ステージ済みの変更が空の場合は、未ステージの変更を対象にしてください。両方空の場合は「変更がありません」と報告して終了してください。

2. 変更を分析する

以下の観点で変更を読み取ってください。

• 変更の種類: 新機能・バグ修正・リファクタリング・ドキュメント・テスト・CI・ビルドのどれか
• 変更対象: 主に影響するモジュール・コンポーネント・ファイル群
• 変更の意図: なぜこの変更が必要か（コード差分から推測）

3. コミットメッセージを組み立てる

フォーマット

<type>(<scope>): <subject>

[body]

[footer]

type の選択基準

type	使う場面
feat	新機能の追加
fix	バグ修正
docs	ドキュメントのみの変更
refactor	バグ修正でも機能追加でもないコードの変更
perf	パフォーマンス改善
test	テストの追加・修正
build	ビルドシステムや外部依存関係の変更
ci	CI 設定ファイル・スクリプトの変更

各要素のルール

• scope: 変更対象のモジュール名やファイル名（ディレクトリ名可）。省略可だが積極的に付ける
• subject: 現在形・命令形の動詞で書く / 先頭を大文字にしない / 末尾にピリオドなし / 50文字以内推奨
• body: subject だけで意図が伝わらない場合のみ記述。「なぜ変えたか」を中心に書く
• footer: Breaking Change は BREAKING CHANGE: で始める / Issue を閉じる場合は Closes #番号

Breaking Change の判定

後方互換性を壊す変更（API変更・インターフェース変更・設定フォーマット変更）がある場合は ! を付けるか footer に記述する。

4. 提案する

変更内容に最適なメッセージを 1〜3案 提示してください。

• 最初の案を推奨案とする
• 案ごとに理由を一言添える
• 最後にそのままコピーできるコードブロックを付ける

出力フォーマット

## コミットメッセージ案

### 案1（推奨）
**理由**: ...

\`\`\`
<type>(<scope>): <subject>
\`\`\`

### 案2
**理由**: ...

\`\`\`
<type>(<scope>): <subject>
\`\`\`

body・footer が必要な場合は案の中に含めてください。