spec-driven-verify

仕様駆動の変更をアーカイブする前に、ユーザーが変更を検証できるよう支援します。

このスキルのコマンド

このスキルで使う正確なコマンドを思い出せない場合は、何かを実行する前にここで確認してください。 推測してはいけません。

modify: node {{SKILL_DIR}}/scripts/spec-driven.js modify
verify: node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
verify-spec-mappings: node {{SKILL_DIR}}/scripts/spec-driven.js verify-spec-mappings
apply: node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>
audit-spec-mapping-coverage: node {{SKILL_DIR}}/scripts/spec-driven.js audit-spec-mapping-coverage <spec-path> [--implementation <repo-path> ...] [--tests <repo-path> ...]
audit-unmapped-spec-evidence: node {{SKILL_DIR}}/scripts/spec-driven.js audit-unmapped-spec-evidence [--implementation <repo-path> ...] [--tests <repo-path> ...]

前提条件

.spec-driven/ ディレクトリがプロジェクトのルートに存在している必要があります。先に進む前に、次のコマンドで確認してください。

ls .spec-driven/

失敗した場合、プロジェクトは初期化されていません。まず /spec-driven-init を実行してください。

手順

1. 変更を選択する — node {{SKILL_DIR}}/scripts/spec-driven.js modify を実行して、アクティブな変更を一覧表示します。検証する変更を尋ねてください。すでに指定されている場合は、それを使用します。

2. フォーマットチェック — 次を実行します。

   node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
   

   エラー（ブロッキング）または警告（ノンブロッキング）があれば報告してください。

   • スクリプトによるテスト準備状況のエラーは、重大として扱ってください。これには、## Testing の欠落、lint／検証のカバレッジ不足、単体テストのカバレッジ不足、または明示的に実行可能なコマンドがない必須テストタスクが含まれます。

   また、次も実行します。

   node {{SKILL_DIR}}/scripts/spec-driven.js verify-spec-mappings
   

   不正な仕様マッピングのフロントマター、マッピングフィールドの欠落、またはマッピング対象ファイルの欠落は、該当するメイン仕様に関する重大な指摘として扱ってください。

3. タスク完了チェック — 次を実行します。

   node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>
   

   remaining > 0 の場合は、未完了のタスクを一覧表示してください。これらは重大な問題です。

4. 未解決の質問のチェック — .spec-driven/changes/<name>/questions.md を読み、- [ ] Q: の項目を確認します。

   • 未解決の質問は重大です
   • スクリプトもこれらをエラーとして報告します。ここでも重大として扱ってください

5. 実装の証拠のチェック — tasks.md の完了済みタスクごとに、次を行います。

   • タスクによって変更されるはずのコードまたはファイルを特定する
   • 関連ファイルを読み、変更が実際に存在することを確認する
   • 完了済みタスクが実装、テスト、または仕様に関する作業を主張していて、目に見える証拠がない場合は、その曖昧さが questions.md に明確に記録されていない限り、重大として扱ってください

6. マッピング証拠セットを作成する — マッピングの品質を評価する前に、次から変更固有の証拠セットを作成します。

   • .spec-driven/changes/<name>/specs/ 内で変更された差分仕様ファイル
   • 完了した動作のために実際に変更された実装ファイル
   • 完了した動作のために実際に変更されたテストファイル
   • 完了した動作を提供する、または直接検証するために明示的に依存しているファイル

   確信を持てる範囲で、できるだけ小さい証拠セットを優先してください。メインの実装ファイルや直接のテストファイルが明確な場合、離れたヘルパーから意味上のカバレッジを推測してはいけません。

   変更された差分仕様ファイルごとに、次を実行します。

   node {{SKILL_DIR}}/scripts/spec-driven.js audit-spec-mapping-coverage <spec-path> [--implementation <repo-path> ...] [--tests <repo-path> ...]
   

   作成した証拠セットを、明示的な --implementation および --tests の入力として使用してください。

   また、次も実行します。

   node {{SKILL_DIR}}/scripts/spec-driven.js audit-unmapped-spec-evidence [--implementation <repo-path> ...] [--tests <repo-path> ...]
   

   同じ証拠セットを使って、どのメイン仕様にもマッピングされていない実装ファイルまたはテストファイルを特定してください。

7. 仕様との整合性チェック — .spec-driven/specs/、.spec-driven/config.yaml、.spec-driven/changes/<name>/proposal.md、および .spec-driven/changes/<name>/specs/ 内のすべてのファイルを確認します。

   • 実装は提案された内容と一致していますか？
   • changes/<name>/specs/ 内の差分ファイルは、実装された内容を正確に記述していますか？実際に動作が変更されているのに specs/ が空の場合は CRITICAL です。
   • 各差分ファイルのパスは、対応するメイン仕様ファイルのパスを反映していますか？パスが一致しない場合、マージに失敗します。
   • 差分ファイルは標準形式（### Requirement: <name>、RFC 2119 キーワード、#### Scenario: ブロック）に従っていますか？形式に準拠していない場合は CRITICAL です。仕様形式は必須です。
   • 変更された差分仕様ファイルごとに、node {{SKILL_DIR}}/scripts/spec-driven.js audit-spec-mapping-coverage <spec-path> [--implementation <repo-path> ...] [--tests <repo-path> ...] の監査出力を使用して、mapping.implementation と mapping.tests を変更ローカルの証拠セットと比較します。
   • 証拠から、変更された仕様がマッピングに含まれていない実装ファイルまたは直接検証するテストファイルに依存していることが明らかな場合、その欠落を CRITICAL として報告します。
   • 証拠が曖昧な場合は、確信を持てる範囲で最小限のセットを選び、意味的なカバレッジを作り上げずに曖昧さを報告します。
   • node {{SKILL_DIR}}/scripts/spec-driven.js verify-spec-mappings の結果を使用して、リポジトリ全体の構造上のマッピングエラーと、変更ローカルのマッピング漏れを分けて報告します。
   • 未マッピング証拠の監査で、この変更の主要な実装ファイルまたは直接検証するテストファイルがどのメイン仕様にもマッピングされていないことが判明し、その欠落によってこの変更の仕様カバレッジが不完全になる場合は、CRITICAL として報告します。
   • 未マッピング証拠の監査で、この変更の範囲外にあるファイルまたは関連性の低い候補のみが見つかった場合は、REPO DEBT または確信度の低い WARNING として分けて報告します。
   • config.yaml に rules フィールド（fileMatch エントリーを含む）がある場合、実装と成果物がルールに準拠しているか確認します。違反は WARNING です。
   • proposal.md に内容のある Unchanged Behavior セクションがある場合、実装が記載された動作に違反していないか確認します。違反は CRITICAL です。
   • 整合性の不一致は WARNING または CRITICAL として報告します。

8. 段階別レポートを出力します：

   CRITICAL（アーカイブをブロック）：
     - [一覧または「なし」]
   
   REPO DEBT（この変更の範囲外）：
     - [一覧または「なし」]
   
   WARNING（対応を推奨）：
     - [一覧または「なし」]
   
   SUGGESTION（任意の改善）：
     - [一覧または「なし」]
   

9. 次のステップを推奨します：

   • CRITICAL がある場合：アーカイブする前に対応してください
   • WARNING のみの場合：対応するか、そのまま進めるかをユーザーに確認してください
   • 問題がない場合：/spec-driven-review <name> を提案してください

ルール

• 誠実であること — タスクにチェックが付いているというだけで変更を承認しないでください
• CRITICAL は、変更を不正確または不完全にする問題です
• REPO DEBT は、変更の範囲外にある既存のリポジトリの問題です。変更に固有の指摘とは明確に分けて報告してください
• WARNING は、確信度を低下させますが、必ずしもブロックするものではありません
• SUGGESTION は任意の品質向上案です
• 実装とテストのマッピングは要件の文面ではなく、フロントマターに記載してください