test-coverage

テストカバレッジ

機能、仕様、モジュール、PR、またはチケットを一度に1つ扱う、テスト作成のワークフローです。 機能の実装後（実装と並行して、またはPRの後でも）に使用し、何をテストする必要があるかを判断し、適切なテスト戦略を選び、作成担当者に包括的なテストを作成してもらい、テストを実行して結果を記録します。

作成担当者を通じて、人が読めるMarkdown（test-spec.md、test-report.md）とテストコードを生成します。レポートには、何をどのテスト種別でテストし、何が成功したかという事実を記録します。評価付きの信頼度判定は記録しません。

このスキルが管理するもの

• specs/<feature>/test-spec.md — 長期的に維持される「何をテストするか」の契約です。動作、不変条件、リスク、およびそれぞれに宣言された優先度を記載します。
• specs/<feature>/test-report.md — セッションの記録です。何をどのテスト種別でテストし、何を実行し、何が成功、失敗、またはブロックされたかを記載します。
• リポジトリルートの TESTING.md（任意） — プロジェクトのテスト戦略に関するメモです（推奨するモダリティ、優先度ごとのゲート／姿勢、コンテキストラベル）。単独でも使用でき、ファイルがない場合は組み込みのデフォルトが適用されます。

2つのレイヤー

1. 何をテストするか — 機能を信頼するために検証すべき動作、特性、要件、不変条件。それぞれに宣言済みの優先度（P0～P3）が付与されます。
2. どのようにテストするか — 検証に用いるエビデンスです。ユニット、コントラクト、インテグレーション、E2E、エージェント、手動、テレメトリー、静的、スモーク、スクリプトが該当します。

包括的なテストとは、テスト数のことではありません。コスト（作成者、実行、保守）あたりに得られる、正当化された信頼度を最大化し、安定性、レイテンシー、診断価値も最適化します。最低限のコストで十分な信頼度を確保し、限られた高コストなテスト（E2E、エージェント）の予算は、優先度が最も高いところに使います。

優先度は宣言済みの事実です

テスト対象の各項目には、上流の開発成果物（PRD、機能の分解、仕様）から読み取った priority（P0～P3）が付与されます。この場で新たに決めることはありません。優先度は労力を調整する基準です。P0には最も強固な姿勢を適用し、P3には最も軽い姿勢を適用します。動作ごとの優先度は、機能に宣言されたPレベルをデフォルトとします。仕様またはオーナーがより細かいレベルを宣言している場合に限り、test-spec.md に記録します。上流で優先度が宣言されていない場合は、推測せず UNKNOWN として記録し、オーナーに確認します。推測した優先度は事実ではありません。

別個の1～5のリスク重みはありません。優先度が、重要度を示す唯一の統制対象シグナルです。

テスト種別は事実としてここに記録します

テストを作成または特定したとき、その種別（unit、contract、integration、e2e、agent、manual、telemetry、static、smoke、script）は成果物に関する事実です。種別は、そのテストを作成する担当者によって決まります。種別は test-report.md に動作ごとに記録します。強度ラベル（depth、reliability）や HIGH/MEDIUM/LOW の判定は作成しないでください。レポートには事実（優先度、テスト種別、実行結果）を記録し、評価付きの信頼度判定は記録しません。

テスト戦略と予算ポリシー

各動作に適用する戦略上の姿勢は、次の順に解決します。最初に該当したものを使用します。

1. test-spec.md の動作ごとのメモ（個別調整）。
2. 存在する場合は、リポジトリルートの TESTING.md（プロジェクト全体の姿勢に関するメモ）。
3. assets/default-testing-strategy.md にある組み込みのデフォルト。

デフォルトには、モダリティのコスト特性、判断の原則、3つのガードレール（コストより能力を優先、優先度の下限／予算の上限、多層防御）、および必須の下限（コアロジック／変更ロジックのユニットテストカバレッジ、すべてのP0チェックに少なくとも1つのゲート）が定められています。単独でも使用できます。TESTING.md を必須にせず、ファイルがない場合は組み込みのデフォルトにフォールバックします。

TESTING.md はエージェントが読む説明文であり、スキーマ定義済みの設定ファイルではありません。また、Quality Center のスコアリングでは読み込まれません（スコアリングの透明性は保たれます）。機能間で一貫したプロジェクト全体の姿勢を適用するためのファイルです。TESTING.md の変更はすべての機能の姿勢に影響するため、変更についてはユーザーに確認してください。

機能マップ — 各モダリティで証明できるチェック項目

コストよりも能力を優先します。「最も安価」とは、実際にそのチェック項目を 証明できるモダリティの中で最も安価という意味です。単体テストでは実際のブラウザーフローを証明できません。

• 決定論的な純粋ロジック → 単体テスト。
• 公開境界、サーバーアクション、ルートハンドラー、認可、スキーマ検証 → コントラクトテスト。
• DB の状態、トランザクション、監査行、マイグレーション、ジョブ、モジュール間の不変条件 → 統合テスト。
• ブラウザーでレンダリングされる動作、ルーティング、セッション／ロールで制御される UI、レンダリング のリグレッション → プロジェクト標準の E2E、エージェント、または手動のブラウザーチェック。
• サードパーティーのコールバック、ステージング環境のみの認証、本番環境の SLO、ライブシグナル → エージェントテスト、手動チェック、またはテレメトリー。

専門的なテスト作成

このスキルは戦略を決定して作成を推進します。実際の作成はプロデューサースキルとプロジェクトのワークフローに委任し、その後、作成内容を記録します。

• create-yaml-tests：決定論的な Shiplight YAML E2E テスト（Playwright + エージェント SDK）。
• create-agent-tests：ライブ環境検証向けの、コーディングエージェント主導の Markdown ケース （ブラウザー、API、DB、ログ、クラウド、テレメトリー）。
• その他の種類には、プロジェクト独自の単体、コントラクト、統合、ブラウザー、モバイル、負荷、 マイグレーション、またはテレメトリーのワークフローを使用します。

コードに紐づくテスト（単体、コントラクト、統合、API）については、テストをその場で作成するか、 ベースとなるコーディングエージェントを誘導して、優先度の高いギャップに対する網羅率の高い 詳細なテストを作成します。編集対象はテスト、フィクスチャ、テストスクリプト、およびテスト可能性のために必要な最小限の補助コードに限定してください。

エージェントテストでレポートが生成された場合は、その PASS／FAIL／BLOCKED／ ABORTED のステータスと、監査可能な成果物（HTML レポート、スクリーンショット、動画、 トレース、ログ）を test-report.md に記録します。テキストのみのブラウザーに関する申告では不十分です。 ブラウザー主導のケースでは、監査可能な成果物を必須としてください。ABORTED は製品の証拠ではなく、 オーケストレーションの中断として扱い、再実行してください。

ワークフロー

1. 対象と入力を特定する

• 機能の対象を特定します（NNN-kebab-case 形式のスラッグ。既存の specs/NNN-* スラッグがある場合は再利用します）。
• 優先度の記載を確認するため、PRD／機能の内訳／仕様書を読みます。
• 変更された実装と既存のテストを読みます（利用可能な場合はブランチのマージベースを使用します）。
• 以前の specs/<feature>/test-spec.md と test-report.md があれば確認します。

2. テスト対象を定義または更新する

assets/test-spec-template.md から specs/<feature>/test-spec.md を作成します。 製品の動作、システム／API／スキーマ／データの不変条件、リスクベースの動作、運用／リリース時の動作、 ステークホルダーの信頼性目標を記録します。各動作に宣言された priority を事実として引き継ぎます。 対象外の動作を明示的に列挙します。

3. 戦略を決定し、既存の証拠を一覧化する

ポリシーチェーンに従って、各動作のテスト方針を決定します。既存のテスト（単体、コントラクト、統合、 E2E、エージェント、手動、テレメトリー、静的解析、CI）と、それぞれがカバーする動作を一覧化します。

4. ギャップを分析し、証明方法を選択する

各ギャップを「必要な方針から既存の証拠を差し引いたもの」として評価します。それを埋める能力がある 最も安価なモダリティを選択します。高コストなテストの予算は、最も優先度の高いギャップに充てます。 得られる信頼性、フレークのリスク、実行時間、フィクスチャの複雑さ、クリーンアップ、診断価値、 保守性を考慮します。P0 の動作については、最も安価な証明方法を一つ選ぶよりも、多層での防御を 検討してください。

5. 作成を推進する

プロデューサーに作成を促すか（またはコードに紐づくテストをその場で作成し）、予算に関係なく 妥協できない最低基準を守りながら、価値のあるギャップを埋めます。信頼性を実質的に高める場合にのみ テストを追加し、件数を増やすために壊れやすいテストを追加しないでください。予算の都合で動作に理想的な 証明方法を適用できない場合は、選択した配分と、認識したうえで受け入れるギャップを記録します。 テスト不足を黙って放置してはいけません。

6. 検証を実行する

まず対象を絞ったチェックを実行し、その後、妥当な場合はより広範なテストスイートを実行します。新規または変更したテスト、関連する既存テスト、型チェック／lint／ビルド、マイグレーションのチェック、仕様で必要とされるエージェントのチェックが対象です。実行した正確なコマンドと結果を記録します。必要な機能が利用できない場合は、BLOCKED または NOT MEASURED と記載してください。合格したと偽ってはいけません。

7. テストレポートを作成または更新する

assets/test-report-template.md を基に specs/<feature>/test-report.md を作成します。実行したコマンド、追加または更新したテスト、カバレッジマトリクスを記録します。カバレッジマトリクスには、振る舞いごとに1行設け、優先度、その振る舞いに対して作成したテスト種別、セッションの結果を記載します。ブロッキングの指摘事項を最初に記載してください。確信度の判定や強度ラベルは作成しないでください。

成果物のひな形

成果物	テンプレート
specs/<feature>/test-spec.md	assets/test-spec-template.md
specs/<feature>/test-report.md	assets/test-report-template.md
リポジトリルートの TESTING.md（任意）	assets/TESTING.template.md

ステータスの語彙（テスト種別、結果ステータス、カバレッジステータス）は references/vocabularies.md に記載されています。

運用ルール

• テスト、テストフィクスチャ、テストスクリプト、specs/<feature>/test-spec.md、specs/<feature>/test-report.md は編集できます。リポジトリルートの TESTING.md は、方針の変更がすべての機能に影響するため、ユーザーの確認を得た場合に限り編集できます。
• depth、reliability、1～5のリスク重み、または HIGH/MEDIUM/LOW の確信度判定は作成しないでください。事実（優先度、テスト種別、実行結果）のみを記録してください。
• 無関係なリファクタリングや、本番コードへの無関係な変更は避けてください。
• 仕様、レポート、ログ、成果物に、シークレット、Cookie、トークン、データベース URL、または非公開の顧客データを含めないでください。
• コマンドの出力または監査可能な成果物がない状態で、合格／不合格を報告してはいけません。
• 単独で安全に動作できるようにしてください。TESTING.md を必須にせず、ファイルがない場合は組み込みのデフォルトにフォールバックしてください。

使用しない場合

• ユーザーがプロジェクトのオーケストレーション、PRD、または機能の分解を求めている場合：これはこのスキルの範囲外となるプロジェクトレベルの作業です。
• ユーザーがテストの作成を伴わないコードレビューのみを求めている場合：review を使用してください。
• 実装が存在せず、ユーザーが計画のみを求めている場合。