non-committed-analyzer

name	non-committed-analyzer
description	未コミットの変更ファイルを全て読み込み、施策の意図を分析し、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。トリガー：「コミット分析」「変更まとめて」「何やってたっけ」「commit analyze」「未コミット確認」「変更の棚卸し」

Commit Analyzer

未コミットの変更（staged / unstaged / untracked）を全ファイル読み込み、施策の意図を推測した上で、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。

トリガー

• 「コミット分析」「変更まとめて」「何やってたっけ」
• 「commit analyze」「未コミット確認」「変更の棚卸し」
• 「コミットどう分ける」「差分見て」

ワークフロー

Step 1: 変更の全体像を把握

以下のコマンドを 並列で 実行する:

# 変更ファイル一覧（untracked含む）
git status --short

# staged の diff
git diff --cached

# unstaged の diff
git diff

# 直近のコミット履歴（メッセージスタイル把握用）
git log --oneline -10

# untracked ファイル一覧（ディレクトリは展開しない）
git ls-files --others --exclude-standard

Step 2: 全変更ファイルの中身を Read

ここが最重要。diff だけでなく、変更ファイルの全文を Read ツールで読む。

• Modified ファイル: ワーキングツリーの現在の状態を Read で読む
• New（untracked）ファイル: ファイル全体を Read で読む
• Deleted ファイル: diff の - 行から内容を把握（Read は不要）

大量のファイルがある場合は、関連性の高そうなファイルから優先的に読む。読むファイル数が 15 を超える場合は、ユーザーに「全部読みますか？ 主要ファイルだけにしますか？」と確認する。

Step 3: 施策の分析

読み取った変更内容から、以下を推測・整理する:

1. 何の施策か: 変更の目的・意図を 1-2 文で要約
2. 変更のカテゴリ分類: 各ファイルの変更を以下のカテゴリに分類
   • feat: 新機能
   • fix: バグ修正
   • refactor: リファクタリング
   • config: 設定変更
   • style: フォーマット・見た目の変更
   • docs: ドキュメント
   • chore: 雑務（依存関係更新、CI等）
   • test: テスト追加・修正
3. 変更間の依存関係: どのファイル群がセットで意味を成すか

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ファイル超）の場合は、まず概要を見せて方針を確認してから詳細分析に入る