| name | jp-validate-plan |
| description | 実装を計画と照合して検証し、成功基準を確認し、問題を特定します。計画を実装した後、すべての要件が正しく満たされたことを確認するために使用します。 |
| compatibility | GitHub Copilot CLI用に設計 |
| metadata | {"author":"humanlayer","version":"1.0","original-source":"https://github.com/humanlayer/humanlayer"} |
計画の検証
実装計画が正しく実行されたことを検証し、すべての成功基準を確認し、逸脱や問題を特定するタスクです。
初期セットアップ
呼び出された場合：
-
コンテキストを判断する - 既存の会話にいるか、新規で開始するか？
- 既存の場合：このセッションで何が実装されたかを確認する
- 新規の場合：gitとコードベースの分析を通じて何が行われたかを発見する
-
計画を特定する：
- 計画のパスが提供された場合、それを使用する
- そうでなければ、最近のコミットで計画の参照を検索するか、ユーザーに確認する
-
実装の証拠を収集する：
git --no-pager log --oneline -n 20
git --no-pager diff HEAD~N..HEAD
npm test
検証プロセス
ステップ1：コンテキストの発見
新規開始またはさらにコンテキストが必要な場合：
-
実装計画を完全に読み込む
-
変更されたはずのものを特定する：
- 変更されるべきすべてのファイルをリストする
- すべての成功基準（自動および手動）を記録する
- 検証すべき主要な機能を特定する
-
task ツールで explore エージェントを使用して並行調査タスクを生成する：
- データベース/スキーマの変更が計画と一致するか検証する
- 実際のコード変更と計画の仕様を比較する
- テストが指定通りに追加/変更されたか確認する
ステップ2：体系的な検証
計画の各フェーズについて：
-
完了ステータスを確認する：
- 計画のチェックマーク（
- [x]）を探す
- 実際のコードが主張された完了と一致するか検証する
-
自動検証を実行する：
- 「自動検証」の各コマンドを実行する
- 合格/不合格のステータスを記録する
- 失敗がある場合、根本原因を調査する
-
手動基準を評価する：
- 手動テストが必要なものをリストする
- ユーザー検証のための明確なステップを提供する
-
エッジケースについて深く考える：
- エラー条件は処理されたか？
- 不足しているバリデーションはないか？
- 実装が既存の機能を壊す可能性はないか？
ステップ3：検証レポートを生成する
包括的な検証サマリーを作成する：
## 検証レポート：[計画名]
### 実装ステータス
✓ フェーズ1：[名前] - 完全に実装済み
✓ フェーズ2：[名前] - 完全に実装済み
⚠️ フェーズ3：[名前] - 部分的に実装（問題を参照）
### 自動検証結果
✓ ビルド合格
✓ テスト合格
✗ リンティングの問題（警告3件）
### コードレビューの所見
#### 計画と一致：
- [計画と一致する実装の詳細]
- [別の正しい実装]
#### 計画からの逸脱：
- [file:line]で異なるアプローチを使用
- [file:line]で追加のバリデーションを追加（改善）
#### 潜在的な問題：
- [発見された問題]
- [別の懸念事項]
### 手動テストが必要：
1. UI機能：
- [ ] [機能]が正しく表示されることを確認する
- [ ] 無効な入力でエラー状態をテストする
2. 統合：
- [ ] 既存の[コンポーネント]と連携することを確認する
### 推奨事項：
- マージ前にリンティングの警告に対処する
- [シナリオ]のテストの追加を検討する
既存のコンテキストでの作業
実装に参加していた場合：
- 会話履歴を確認する
- 完了したことをToDoリストで確認する
- このセッションで行われた作業の検証に焦点を当てる
- ショートカットや未完了の項目について正直に報告する
重要なガイドライン
- 徹底的かつ実践的であること - 重要なことに焦点を当てる
- すべての自動チェックを実行する - 検証コマンドをスキップしない
- すべてを記録する - 成功も問題も
- 批判的に考える - 実装が本当に問題を解決するか疑問を持つ
- メンテナンス性を考慮する - 長期的にメンテナンス可能か？
検証チェックリスト
常に確認する：
