non-committed-analyzer - SKILL.md Agent Skill

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