openspec-verify-change

実装が変更成果物（仕様、タスク、設計）に適合していることを確認します。

入力：変更名を指定できます。指定がない場合は、会話の文脈から推測できるか確認します。曖昧な場合や特定できない場合は、利用可能な変更を必ず提示して選択を求めてください。

手順

1. 変更名が指定されていない場合は、選択を求める

   openspec list --json を実行して、利用可能な変更を取得します。ユーザーが選択できるよう、AskUserQuestion tool を使用します。

   実装タスクがある変更（tasks 成果物が存在する変更）を表示します。 利用可能な場合は、各変更で使用されているスキーマを含めます。 未完了のタスクがある変更には「（進行中）」を付けます。

   重要：変更を推測したり、自動選択したりしないでください。必ずユーザーに選択してもらいます。

2. ステータスを確認してスキーマを把握する

   openspec status --change "<name>" --json
   

   JSON を解析して、以下を把握します。

   • schemaName：使用されているワークフロー（例：「spec-driven」、「tdd」）
   • この変更で存在する成果物

3. 変更ディレクトリを取得し、成果物を読み込む

   openspec instructions apply --change "<name>" --json
   

   これにより、変更ディレクトリとコンテキストファイルが返されます。contextFiles にあるすべての成果物を読み込みます。

4. 検証レポートの構造を初期化する

   次の3つの観点でレポート構造を作成します。

   • 完全性：タスクと仕様の網羅状況を追跡します
   • 正確性：要件の実装とシナリオの網羅状況を追跡します
   • 一貫性：設計への準拠とパターンの一貫性を追跡します

   各観点には、CRITICAL、WARNING、SUGGESTION の問題を含めることができます。

5. 完全性を検証する

   タスクの完了状況：

   • contextFiles に tasks.md がある場合は、読み込みます
   • チェックボックスを解析します：- [ ]（未完了）と - [x]（完了）
   • 完了タスク数と全タスク数を数えます
   • 未完了のタスクがある場合：
     • 未完了のタスクごとに CRITICAL の問題を追加します
     • 推奨事項：「タスクを完了する：<説明>」または「実装済みの場合は完了としてマークする」

   仕様の網羅状況：

   • openspec/changes/<name>/specs/ に差分仕様がある場合：
     • すべての要件（「### Requirement:」で示されるもの）を抽出します
     • 各要件について：
       • 要件に関連するキーワードでコードベースを検索します
       • 実装が存在する可能性を評価します
     • 未実装と思われる要件がある場合：
       • CRITICAL の問題を追加します：「要件が見つかりません：<要件名>」
       • 推奨事項：「要件 X を実装する：<説明>」

6. 正確性を検証する

   要件と実装の対応付け：

   • 差分仕様の各要件について：
     • コードベースで実装の根拠を検索します
     • 見つかった場合は、ファイルパスと行範囲を記録します
     • 実装が要件の意図に合致しているか評価します
     • 相違が検出された場合：
       • WARNING を追加します：「実装が仕様から逸脱している可能性があります：<詳細>」
       • 推奨事項：「要件 X に照らして <ファイル>:<行> を確認する」

   シナリオの網羅状況：

   • 差分仕様の各シナリオ（「#### Scenario:」で示されるもの）について：
     • コードで条件が処理されているか確認します
     • シナリオを網羅するテストが存在するか確認します
     • 網羅されていないと思われるシナリオがある場合：
       • WARNING を追加します：「シナリオが網羅されていません：<シナリオ名>」
       • 推奨事項：「シナリオに対するテストまたは実装を追加する：<説明>」

7. 一貫性を検証する

   設計への準拠：

   • contextFiles に design.md がある場合：
     • 主要な決定事項を抽出します（「Decision:」、「Approach:」、「Architecture:」などのセクションを確認します）
     • 実装がそれらの決定事項に従っていることを検証します
     • 矛盾が検出された場合：
       • WARNING を追加します：「設計上の決定に従っていません：<決定事項>」
       • 推奨事項：「実装を更新するか、実際の状況に合わせて design.md を改訂する」
   • design.md がない場合：設計準拠の確認をスキップし、「検証対象の design.md がありません」と記録します コードパターンの一貫性：
   • 新しいコードがプロジェクトのパターンに沿っているか確認します
   • ファイル名、ディレクトリ構成、コーディングスタイルを確認します
   • 大きな逸脱が見つかった場合：
     • SUGGESTION を追加します："コードパターンからの逸脱：
       "
     • 推奨事項："プロジェクトのパターンに沿うことを検討してください："

8. 検証レポートの生成

   サマリースコアカード：

   ## Verification Report: <change-name>
   
   ### Summary
   | Dimension    | Status           |
   |--------------|------------------|
   | Completeness | X/Y tasks, N reqs|
   | Correctness  | M/N reqs covered |
   | Coherence    | Followed/Issues  |
   

   優先度別の問題：

   1. CRITICAL（アーカイブ前に必ず修正）：

      • 未完了のタスク
      • 要件の実装漏れ
      • それぞれに具体的で実行可能な推奨事項を記載

   2. WARNING（修正を推奨）：

      • 仕様／設計との相違
      • シナリオのカバー漏れ
      • それぞれに具体的な推奨事項を記載

   3. SUGGESTION（修正すると望ましい）：

      • パターンの不整合
      • 軽微な改善点
      • それぞれに具体的な推奨事項を記載

   最終評価：

   • CRITICAL の問題がある場合："重大な問題が X 件見つかりました。アーカイブ前に修正してください。"
   • WARNING のみの場合："重大な問題はありません。検討すべき警告が Y 件あります（改善点を反映したうえで）アーカイブできます。"
   • 問題がない場合："すべてのチェックに合格しました。アーカイブできます。"

検証のヒューリスティクス

• 完全性：客観的なチェックリスト項目（チェックボックス、要件リスト）を重視します
• 正確性：キーワード検索、ファイルパスの分析、妥当な推論を使用します。完全な確実性は求めません
• 一貫性：明らかな不整合を探し、スタイルを細かく指摘しすぎないようにします
• 誤検知：確信が持てない場合は、WARNING より SUGGESTION、CRITICAL より WARNING を優先します
• 実行可能性：すべての問題に、該当する場合はファイル／行番号を含む具体的な推奨事項を記載します

段階的なチェック

• tasks.md のみが存在する場合：タスクの完了のみを検証し、仕様／設計のチェックは省略します
• tasks と仕様が存在する場合：完全性と正確性を検証し、設計のチェックは省略します
• すべての成果物がある場合：3 つの観点すべてを検証します
• 省略したチェックとその理由を必ず記載します

出力形式

以下を含む、明確な Markdown を使用します。

• サマリースコアカードには表を使用
• 問題はグループ化して列挙（CRITICAL／WARNING／SUGGESTION）
• コード参照は file.ts:123 の形式
• 具体的で実行可能な推奨事項
• 「確認を検討してください」のような曖昧な提案は避ける