| name | non-committed-analyzer |
| description | 未コミットの変更ファイルを全て読み込み、施策の意図を分析し、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。トリガー：「コミット分析」「変更まとめて」「何やってたっけ」「commit analyze」「未コミット確認」「変更の棚卸し」 |
Commit Analyzer
未コミットの変更（staged / unstaged / untracked）を全ファイル読み込み、施策の意図を推測した上で、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。
トリガー
- 「コミット分析」「変更まとめて」「何やってたっけ」
- 「commit analyze」「未コミット確認」「変更の棚卸し」
- 「コミットどう分ける」「差分見て」
ワークフロー
Step 1: 変更の全体像を把握
以下のコマンドを 並列で 実行する:
git status --short
git diff --cached
git diff
git log --oneline -10
git ls-files --others --exclude-standard
Step 2: 全変更ファイルの中身を Read
ここが最重要。diff だけでなく、変更ファイルの全文を Read ツールで読む。
- Modified ファイル: ワーキングツリーの現在の状態を Read で読む
- New（untracked）ファイル: ファイル全体を Read で読む
- Deleted ファイル: diff の
- 行から内容を把握（Read は不要）
大量のファイルがある場合は、関連性の高そうなファイルから優先的に読む。読むファイル数が 15 を超える場合は、ユーザーに「全部読みますか？ 主要ファイルだけにしますか？」と確認する。
Step 3: 施策の分析
読み取った変更内容から、以下を推測・整理する:
- 何の施策か: 変更の目的・意図を 1-2 文で要約
- 変更のカテゴリ分類: 各ファイルの変更を以下のカテゴリに分類
feat: 新機能fix: バグ修正refactor: リファクタリングconfig: 設定変更style: フォーマット・見た目の変更docs: ドキュメントchore: 雑務（依存関係更新、CI等）test: テスト追加・修正
- 変更間の依存関係: どのファイル群がセットで意味を成すか
Step 4: コミット分割案の提示
以下の形式で提示する:
## 施策の概要
（1-2文で何をやっていたかの要約）
## コミット分割案
### 案A: N コミットに分割（推奨）
| # | タイプ | コミットメッセージ | 対象ファイル |
|---|--------|-------------------|-------------|
| 1 | config | ghostty: キーバインドの設定を更新 | config, keybindings.conf |
| 2 | feat | zsh: ghostty-dev 関数を追加 | dot_zsh/functions/ghostty-dev |
| 3 | ... | ... | ... |
### 案B: 1 コミットにまとめる
| # | タイプ | コミットメッセージ | 対象ファイル |
|---|--------|-------------------|-------------|
| 1 | feat | ghostty: レイアウト管理機能の追加と設定整理 | （全ファイル） |
コミット分割の判断基準
- 別の施策は別コミット: 無関係な変更は分ける
- config + それを使う機能コードはセット: 設定とコードが対の場合はまとめる
- 削除は独立: ファイル削除が多い場合は「不要ファイルの整理」として独立コミットにする
- リポジトリの既存スタイルに合わせる: Step 1 で取得した直近コミットのメッセージスタイルを踏襲する
コミットメッセージのルール
- リポジトリの既存コミットメッセージのスタイル（prefix の有無、日本語/英語、長さ）を分析し、それに合わせる
- スタイルが判別できない場合は
<type>: <scope>: <summary> 形式を使う
- 「何をしたか」ではなく「なぜしたか」を優先する
Step 5: 検証手順の提示
変更内容に応じて、以下の観点で検証手順を提示する:
## 検証手順
### 動作確認
- [ ] 確認項目1（具体的な手順）
- [ ] 確認項目2
- ...
### 副作用の確認
- [ ] 既存機能への影響（具体的に何が壊れうるか）
- [ ] 設定ファイルの反映確認（`chezmoi apply` 後の状態等）
検証手順の生成ルール
変更の種類に応じた検証テンプレート:
| 変更種別 | 検証観点 |
|---|
| シェル関数 | which <func> で認識されるか、引数パターン別の動作、エラーケース |
| Neovim プラグイン | :Lazy sync 後にエラーなく読み込まれるか、既存キーマップとの衝突 |
| Ghostty 設定 | ghostty +show-config で構文エラーがないか、レイアウトスクリプトの実行 |
| chezmoi テンプレート | chezmoi diff で意図通りの出力か、chezmoi apply --dry-run |
| zshrc / 環境変数 | 新しいシェルセッションで echo $VAR 確認、source ~/.zshrc で構文エラーなし |
| Git config | git config --list で反映確認 |
| AppleScript | osascript <file> で実行、権限ダイアログの確認 |
| CSS / UI | ブラウザでの表示確認、レスポンシブ確認 |
| API 連携 | エンドポイントへのリクエスト/レスポンス確認 |
| パッケージ更新 | npm install / pip install 後の動作確認、lockfile の整合性 |
Step 6: テスト実装案の提示（該当する場合）
自動テストが書ける変更の場合のみ提示する。dotfiles のような設定系リポジトリでは省略可。
## テスト案（該当する場合）
### ユニットテスト
- テストファイル: `tests/xxx.test.ts`
- テストケース:
- `should ...` — 正常系
- `should throw when ...` — 異常系
### 統合テスト
- テストシナリオ: ...
### スモークテスト（手動）
- 手順: ...
テスト実装の判断基準
| 変更種別 | テスト適用 | 理由 |
|---|
| ライブラリのコード (TypeScript, Python等) | 適用 | ユニットテスト可能 |
| CLI ツール / シェルスクリプト | 条件付き | bats 等でテスト可能な場合のみ |
| 設定ファイル (dotfiles) | 不適用 | 動作確認で代替 |
| AppleScript / GUI 自動化 | 不適用 | 手動確認で代替 |
| Neovim プラグイン設定 | 不適用 | 起動確認で代替 |
出力の注意事項
- 日本語で出力する（コミットメッセージも既存スタイルに合わせる）
- コミットの実行はしない。あくまで分析と提案のみ
- ユーザーが「これでコミットして」と言った場合のみ、実際の git 操作に移る
- 変更が大量（20ファイル超）の場合は、まず概要を見せて方針を確認してから詳細分析に入る
