verifying

検証

計画と実際の変更を照らし合わせ、見落としや古くなった内容がないこと、実装が計画どおりであることを確認する、実装後の監査を行います。

作業上の合意事項

ユーザー向けの質問はすべて AskUserQuestion を通じて行います — 規約については desplega:ask-user を参照してください。

読み取り、調査、検証の作業はすべてサブエージェントを通じて行います — デフォルトで run_in_background: true を設定してください。

ファイルレビューはデフォルトで有効です（Autopilot の場合を除く）。準備ができたら、検証レポートに対して実行してください。

使用するタイミング

このスキルは、次の場合に有効になります。

• ユーザーが /verify-plan コマンドを実行した場合
• 実装スキルが完了時に検証を提案した場合
• ユーザーが完了した計画の監査または検証を依頼した場合

自律性モード

検証を開始する際は、自律性モードに応じてやり取りのレベルを調整します。

モード	動作
Autopilot	すべてのチェックを実行し、計画を更新して、最後に概要を報告します
Critical（デフォルト）	不一致やブロッカーについて確認します
Verbose	各チェックを順に確認し、解釈が正しいか確認します

自律性モードは、呼び出し元のコマンドから渡されます。指定がない場合は、デフォルトで Critical とします。

プロセスの手順

手順 1：計画を読み込む

計画を最後まで読みます。パスが指定されていない場合：

1. thoughts/*/plans/ 内で status: in-progress または status: completed の計画を検索します
2. 複数見つかった場合は、AskUserQuestion を使用してユーザーに選択してもらいます
3. 見つからない場合は、その旨を報告して終了します

手順 2：チェックボックスの監査

計画内のすべての - [ ] と - [x] の項目を解析します。次の情報を報告します。

指標	説明
項目の合計数	チェックボックス項目の合計数
チェック済み項目	- [x] 項目の数
未チェックの自動検証項目	#### Automated Verification: 配下にある、未チェックの項目
未チェックの自動 QA 項目	#### Automated QA: 配下にある、未チェックの項目
未チェックの手動検証項目	#### Manual Verification: 配下にある、未チェックの項目

未チェックの Automated Verification 項目または Automated QA 項目にはフラグを立てます。これらは、実装スキルまたはフェーズ実行スキルによってチェックされていることが想定されます。

手順 3：Git diff との照合

計画のフロントマターで git_commit フィールドを確認します。

git_commit がある場合：

1. git diff <git_commit>..HEAD --name-only を実行して、変更されたファイルを取得します
2. 計画の「Changes Required」セクションに記載されたファイルパスをすべて抽出します
3. 比較して、次の項目にフラグを立てます。
   • 想定外の変更：計画に記載されていない変更ファイル
   • 実装漏れ：計画に記載されているが、変更されていないファイル

git_commit がない場合：

• 次の注記を添えて、この手順をスキップします：「計画のフロントマターに git_commit がありません — git diff との照合をスキップします」

計画とは異なるブランチにいる場合：

• ブランチの違いを記録し、可能な範囲で比較を進めます

手順 4：スコープの検証

計画の「What We're NOT Doing」セクションを読みます。スコープ逸脱の証拠がないか、git diff を検索します。

• 明示的に対象外とされた項目に関連するファイルやパターンを探します
• 対象外の機能に言及しているコミットがないか確認します

ここでは慎重に判断してください。明らかなスコープ違反のみを指摘し、判断が分かれるケースにはフラグを立てないでください。

ステップ 5：成功基準の再実行

各フェーズの成功基準について、再実行可能な 2 つの分類を再実行します。

自動検証（コマンド）：

1. 各チェックボックス項目からコマンドを抽出します
2. 各コマンドを再実行します
3. 成功／失敗を報告します

自動 QA（エージェント駆動のシナリオ）：

1. 各シナリオを、適切なツール（browser-use、スクリーンショット差分、CLI の手順確認）を使って再実行します
2. シナリオごとに成功／失敗を報告します

エッジケース（両方に適用）：

• 明らかに存在しなくなったファイルやパスを参照している項目はスキップします
• 項目が失敗した場合は、レポート用にエラー／出力を記録します
• 破壊的な項目や状態を変更する項目は再実行せず、読み取り専用のチェックのみ実施します
• フェーズの QA Spec が外部 QA ドキュメントにリンクしている場合は、そのパスをレポートに記載します。そのドキュメントの再実行は qa スキルの担当であり、このスキルの担当ではありません

オプションのサブスキル： 検証コマンドがない場合、不安定な場合、または再実行するとレポートが過剰な出力で埋まる場合は、desplega:script-builder を呼び出して、再実行可能なスクリプトでラップします。生成されたスクリプトは PASS/FAIL と /tmp へのログ出力を徹底するため、以降の検証では大量の stdout ではなく、すっきりした 1 行の結果を得られます。ラップされたコマンドはプラン内に残ります。後続の検証では、script-builder が CLAUDE.md に追加する <important if> ブロックを通じて、新しいスクリプトを検出します。

ステップ 6：プランの鮮度チェック

フェーズの説明を実際の実装と照合します。

• プラン内のファイルパスは現在も正確ですか？
• 「必要な変更」の説明は、実際に行われた作業と一致していますか？
• 実装中に大幅に変更されたフェーズはありましたか？

説明が実態と一致しなくなったフェーズには、古い情報であることを示します。

ステップ 7：検証レポート

以下の分類で調査結果を提示します。

分類	意味	例
ブロッキング	プランを完了としてマークする前に解決が必要	未チェックの自動項目、失敗した成功基準
警告	完了を妨げないものの、確認が必要	予期しないファイル変更、スコープ拡大の可能性
情報	対応不要の参考情報	古い説明、軽微な不一致、ブランチの差異

ステップ 8：ステータスの更新

すべてのブロッキング項目が解決した場合：

• frontmatter のプランの status: completed を設定するか確認します
• last_updated と last_updated_by のフィールドを更新します

ブロッキング項目が残っている場合：

• 該当項目を明確に列挙し、次の手順を提案します

学びの記録

オプションのサブスキル： このワークフロー中に重要な知見、パターン、注意点、判断が得られた場合は、desplega:learning を使って /learning capture 経由で記録することを検討してください。今後のセッションで他の人の役に立つ学びに焦点を当てます。

Review スキルとの連携

検証が完了したら、AskUserQuestion を使って次の質問をします。

質問	選択肢
「検証が完了しました。次はどうしますか？」	1. QA を実行する（→ /qa）、2. review を実行する（→ /review）、3. 完了

Review との連携

File-review はデフォルトで有効です（Autopilot を除く）。

• 検証レポートの後に、インラインの人間によるコメントを得るため /file-review:file-review <plan-path> を呼び出します
• フィードバックは file-review:process-review スキルで処理します