Verify Implementation

Gitリポジトリの未コミット変更を分析し、与えられた仕様・要求事項が正しく実装されているかを検証する。

入力

引数として仕様・要求事項のテキストを受け取る。テキストは自由形式で、箇条書き・文章・チケットのコピペなど、どんな形式でも対応する。 ファイルパスを受け取った場合は、そのファイルを仕様・要求事項のテキストとして読み込む。（例: ~/.claude/plans/xxxx-yyyy-zzzz.md のPlanファイルなど ）

ワークフロー

1. 仕様テキストを要件に分解する
2. Gitの未コミット変更を取得する
3. 変更内容を読み込み、各要件との対応を分析する
4. 検証結果をPlanモードで提示する

Step 1: 仕様テキストの分解

引数で受け取ったテキストを、検証可能な個別の要件に分解する。

• 曖昧な表現はそのまま残す（勝手に具体化しない）
• 暗黙の要件（テキストから論理的に導かれるもの）も抽出する。ただし明示的な要件と区別して扱う
• 各要件に通し番号を振る

Step 2: 未コミット変更の取得

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

• git status — 変更・未追跡ファイルの一覧
• git diff — 未ステージの変更差分
• git diff --cached — ステージ済みの変更差分

変更がない場合は、その旨をユーザーに伝えて終了する。

Step 3: 変更内容の分析

3a. 変更ファイルの読み込み

変更されたファイルについて、差分だけでなくファイル全体を読み込む。差分だけでは文脈が不足し、要件の充足を正しく判断できないことがあるため、周辺コードも把握する。

ファイル数が多い場合は、要件に関連しそうなファイルを優先して読み込む。

3b. 要件との照合

各要件について以下を判定する:

• 実装済み: 変更内容が要件を満たしている
• 部分実装: 要件の一部は実装されているが、不足がある
• 未実装: 要件に対応する変更が見つからない

判定の根拠として、どのファイルのどの変更が要件に対応するかを具体的に記録する。

3c. 要件外の変更の検出

どの要件にも対応しない変更がある場合、それも記録する。リファクタリング、フォーマット変更、依存関係の更新など、要件とは無関係だが妥当な変更は「要件外だが妥当」として分類する。

Step 4: 検証結果の提示

EnterPlanModeを使用して、検証結果をユーザーに提示する。

結果レポートの形式

## 実装検証結果

### サマリー
- 実装済み: N件
- 部分実装: M件
- 未実装: L件

### 要件別の検証結果

#### 1. [要件の内容]
- **判定**: 実装済み / 部分実装 / 未実装
- **根拠**: [どのファイルのどの変更が対応するか]
- **不足点**: [部分実装・未実装の場合、何が足りないか]

#### 2. [要件の内容]
- **判定**: ...
- **根拠**: ...

...

### 暗黙の要件（推測）

#### N+1. [推測された要件]
- **判定**: ...
- **根拠**: ...
- **推測の根拠**: [なぜこの要件が必要と判断したか]

### 要件外の変更
- `path/to/file.ts`: [変更内容の要約] — 要件外だが妥当 / 要確認

レポート作成のポイント

• 判定に自信がない場合は正直にその旨を記載する。曖昧な要件に対して無理に「実装済み」と判定しない
• 根拠は具体的に書く。「実装されている」ではなく「src/auth/login.tsの30-45行目でJWTトークンの検証ロジックが追加されている」のように、ファイルパスと変更内容を示す
• 部分実装の場合は、実装済みの部分と不足している部分の両方を明記する
• 要件のテキストが曖昧で判定が困難な場合は、どう解釈したかを記載した上で判定する

注意事項

• 仕様テキストの内容を勝手に拡大解釈しない
• コードの品質やベストプラクティスへの準拠は検証対象外（あくまで仕様との整合性のみ）
• テストの実行やビルドの確認は行わない（静的な変更内容の分析のみ）
• 大量のファイルが変更されている場合は、要件に関連するファイルを優先して分析し、全ファイルの読み込みに時間をかけすぎない