reviewing-test-plan

reviewing-test-plan — SKILL.md

バリアント： 標準 · 使用するタイミング： 完成済み（または修正済み）の QA／検証テスト計画を受け入れゲートとして判定します。テスターが実行できること、上流にあるすべての動作に追跡可能なテストケースがあること、テストケース一覧がリスクに応じて構成され、組み合わせの総当たりになっていないこと、必要な非機能テストに数値目標が設定されていることを確認し、実行可能な指摘とともに VERDICT: approve|revise を出力します。

概要

このスキルは、テスト計画の作成と判定を行う一対のスキルのうち、レビューを担います。完成済みの QA／検証テスト計画、つまり何を、どのレベルで、どの環境で、どのデータを使い、どの完了基準を満たすまでテストするのかを示し、実行するテストケース一覧を含む文書を持つレビュアーが使用します。このスキルは、次の一つの問いに基づいてその文書を評価します。テスターが疑問を持つことなくこの計画を実行できるか、提出された上流資料に記載されたすべての動作に追跡可能なテストケースが少なくとも一つあるか、テストケース一覧はリスクに応じた規模か（入力の全組み合わせの総当たりでも、骨組みだけでもないか）？ そこで、固定の網羅性とテスト容易性に関する10項目のチェックリストを適用します。これは、テスト計画の作成者が準拠する基準（authoring-test-plan Step-7）と同じなので、作成基準とレビュアーの判定基準が食い違うことはありません。そのうえで、機械で解析できる単一の判定と、作成者が1回の修正で対応できる指摘を出力します。これは受け入れゲートです。計画の作成、修正、書き換えは行いません。判定して指摘を返し、作成者が修正します。

最も重要なチェック項目は、網羅性（上流資料のすべての動作／操作／エラーを列挙し、それぞれに追跡可能なテストケースが少なくとも1つあることを確認します。テストケースのない動作は最も影響の大きい欠陥です）と、テストケース一覧の規模（リスクに応じて構成され、組み合わせの爆発も、薄すぎる構成や水増しもないこと）です。計画が一見網羅的に見えるときは、どちらも見落としやすい項目です。

有効にするタイミング

• 完成済みの QA／検証テスト計画について、テスト開始前、またはリリース手順書の終了基準に組み込む前に、承認／修正の判定が必要な場合。
• 作成者が作成したテスト計画の独立したレビュアー／ゲート担当者であり、網羅性の確認に使う上流資料（feature-spec／api-spec／PRD）がある場合。
• 前回の revise 判定後に修正されたテスト計画を再判定する場合、または承認済みの計画に対する変更依頼として提出された修正をレビューする場合（条件10に従い、変更範囲に絞って判定します）。

次の場合は有効にしないでください：

• テスト計画の作成や修復を行う場合 → authoring-test-plan を使用してください（このスキルと同じ基準に準拠した計画を作成します）。このスキルは文書を作成しません。
• リリース／デプロイ手順書、つまり本番環境へのリリース手順（デプロイ手順、検証、ロールバック）をレビューする場合 → リリース手順書のレビュー用スキルを使用してください。手順書では、この計画の終了基準を再利用しますが、判定基準は異なります（実行可能性／ロールバックと、網羅性／テスト容易性）。
• エンジニアリング設計文書（仕様、計画、設計文書、RFC、ADR）をレビューする場合 → コードベースと照らして設計上の主張を検証する設計レビュー用スキルを使用してください。そちらは設計を審査し、こちらは設計から派生した検証計画を審査します。
• 実行可能なテストスクリプト（pytest／Playwright など）を判定または実行する場合 → それらはこの計画より下流にある実装です。このゲートが判定するのは計画文書であり、自動化コードやテスト実行の結果ではありません。
• テンプレートやセクションへの準拠を確認する場合 → それはテンプレート上の問題です。このスキルが判定するのは基準に照らした品質であり、すべての見出しが揃っているかどうかではありません。

ワークフロー

Step 1: 計画全体を新鮮な目で読み、上流資料を確認する

テスト計画を最初から最後まで、作者の説明にとらわれず、明日実行しなければならないテスターのつもりで読んでください。そのテスターを支援するゲートキーパーとして、指摘が重みを持つのは、テスターがケースを実行できない、完了基準を満たしたか判断できない、またはケースのない動作を見つけたことを示す場合に限ります。この計画が想定するプロジェクトの類型（小規模な CLI か、幅広い UI 製品か）を特定してください。Step 2 の適切さの評価はこれに左右されます。特に、提出された上流資料（機能仕様／API 仕様／PRD／NFR など、実際にプロジェクトで作成されたもの）を読み込んでください。これらは網羅性チェックリストです。すべての動作／受け入れ基準（機能仕様）、すべての操作とエラーケース（API 仕様）、または、それらが作成されていない場合はすべての要件（PRD）を列挙し、非機能テストが必要な NFR を記録してください。固定の入力を想定せず、提出された上流資料に含まれるものをすべて列挙してください。上流資料が提出されていない場合は、今の時点で記録してください。Step 4 では前提として明記し、手元にある資料に基づいて網羅性を評価します。プロジェクトで作成されていない文書を要求すると想定してはならず、チェックリストを最後まで実行できなかったことを理由に、承認を既定の判断にしてはなりません。既存の計画に対する変更依頼が提出されている場合は、これは改訂です。条件 10 を差分の範囲に限定して実行してください（Step 2）。

Step 2: 網羅性とテスト可能性のチェックリストを実行し、各条件を評価する

以下の各条件について、合格または不足を判定してください。条件が不合格となるのは、実在し、具体的に特定できる不備がある場合に限ります。「ケースの順序を別のものにしたかった」は不足ではありません。不足ごとに、正確な箇所と欠けている内容を記録してください（Step 4 で実行可能な指摘にします）。この 10 条件が、単一の基準です（authoring-test-plan の Step-7 で出力されるものと同じです）。独自の条件を追加しないでください。詳細と、合格／不足の具体例については、references/coverage-testability-bar.md を参照してください。

1. 網羅性。 提出された機能仕様書に記載されたすべての動作／受け入れ基準、および提出された API 仕様書に記載されたすべての操作とエラーケース（API 仕様書がない場合は PRD のすべての要件）に、追跡可能なテストケースが 1 件以上あること。列挙された上流の動作／操作／エラーに、それに対応するケースが 1 件もない場合は「ギャップ」です。最も影響の大きい欠陥クラスです。（規模を問わず適用されます。）
2. 適切な機能テストレベル。 選択した機能テストレベルと種類がプロジェクトに適していること。システムに応じて、ユニット／統合／E2E／受け入れテストを実施し、必要に応じて回帰／スモークテストも実施します。省略する場合は、その理由を明記し、黙って省略しないでください。システムに明らかに必要なレベルが、根拠なく欠けている場合（例：複数サービスのシステムで統合テストケースがない）は「ギャップ」です。（非機能テストは条件 9 の対象であり、ここには含みません。）適正な規模にすること：小規模なプロジェクトでは、不要なレベルを統合できます。
3. テスト可能な開始／終了基準。 開始基準と終了（「完了」）基準は、観察または測定が可能で、読者が各基準を機械的に判定できること（例：「優先度 High のケースがすべて合格している。各動作に合格済みの追跡可能なケースがある。未解決の Critical／High の不具合がない」）。終了基準には、カバレッジの下限と未解決不具合のしきい値を含めます。カバレッジは、単なるコードカバレッジ率ではなく、要件またはリスクに照らして記述します。基準が曖昧で（「テストの結果が良好」など）、読者によって判定が分かれうる場合は「ギャップ」です。適正な規模にすること：小規模な計画では基準のリストが短くてもかまいませんが、各基準は判定可能でなければなりません。
4. 環境とテストデータの指定。 各レベルについて、実行環境、必要なデータ／フィクスチャ、その用意とリセットの方法、および機微なデータ（PII／PHI）の取り扱いを明記します。あるレベルの実行環境が記載されていない場合や、計画に指定されていないフィクスチャをケースが前提としている場合は「ギャップ」です。適正な規模にすること：小規模な計画なら、環境は 1 つで、フィクスチャもシンプルでかまいません。
5. カタログ内の各ケースが実行可能で、追跡可能であること。 すべてのケースに、事前条件、単一アクションの手順、観察可能な期待結果（否定的なケースでは正確なメッセージ／エラー。ML／確率的なケースでは、名前を明示したデータセットに対するメトリクスのしきい値、または変形関係。「モデルの精度が高い」「結果が関連性を持つ」は、ここで排除される実行不能な結果です）、およびトレース先があること。事前条件がない、手順が曖昧または複数のアクションを含む、期待結果が観察不能、またはトレース先がない場合は「ギャップ」です。（規模を問わず適用されます。実行可能性の最低基準です。）
6. リスクに基づく優先順位付けとリスクに応じた設計。 計画では発生可能性 × 影響度に基づいて優先順位を付け、カタログの深さをリスクに応じて決めます。高リスク領域には（境界値、同値分割、決定表／状態遷移／ペアワイズの選択、否定的なパスなどの）ケースを多くし、単純な領域では少なくします。すべての入力組み合わせを総当たりする必要はありません。 以下の 3 つはすべて「ギャップ」です：リスクに対してケースが少なすぎるカバレッジ不足、あらゆる組み合わせを網羅する組み合わせの爆発（例：10 個のスイッチを持つモジュールで、リスク評価とペアワイズの代わりに 1,024 通りすべてをテストする）、および水増しされた／薄すぎるカタログ（カバレッジを増やさないケースや、高リスク領域にハッピーパスのケースしかない状態）。ケース設計の手法は作成者の補助として用いるものです。評価するのは結果であり、「決定表を作成したか」ではありません。
7. 捏造しないこと。 すべてのケースは実在する上流仕様に追跡できること。テスト不能な要件や不足している NFR など、カバレッジ上の不足は、創作した動作で補うのではなく、明示的な前提条件として提示します。上流仕様で定められていない動作をケースがテストしている場合は「ギャップ」です。ケースの一部を抽出し、トレース先を実際の上流仕様と照合して抜き取り確認してください。（規模を問わず適用されます。）
8. プロジェクトの類型に見合った規模であること。 カタログとテストレベルの構成をプロジェクトの規模に合わせます。小規模な CLI なら、ケースは少数で、非機能テストを省略する場合もあります。一方、大規模な UI 製品なら、多くのケースが必要です。計画がその類型に対して骨組みだけである場合、または組み合わせの爆発が起きている場合（条件 6）に限り「ギャップ」です。適切な規模にすることはギャップではありません。
9. 非機能テスト（該当する種類には数値目標を設定すること）。 NFR／プロジェクトの類型から必要とされる各非機能テストの種類について、検証可能なアプローチと数値または標準に基づく目標を定めます。例：パフォーマンス（負荷プロファイル＋p95／スループット）、セキュリティ（脅威分析に基づくテストセット）、アクセシビリティ（WCAG 2.2 AA）、ユーザビリティ、互換性（マトリックス）、i18n／l10n。必要な種類がアプローチや目標なしで記載されている場合（負荷プロファイル／目標なしに「パフォーマンスをテストする」とだけ書かれているなど）、または NFR があるのに、それを網羅する非機能テストがない場合は「ギャップ」です。プロジェクトの規模に応じた適切な判断（重要）： NFR がなく、非機能テストが一切必要とされない小規模なプロジェクトでは、非機能テストがなくても「ギャップ」ではありません。プロジェクトの類型から必要とされない非機能テストを要求してはならず、目標を捏造してもいけません。（この条件が非機能テストの範囲を担当します。条件 2 は機能テストのみを対象とするため、必要なパフォーマンステストレベルの欠落は、重複して 2 件ではなく、ここでの指摘 1 件となります。）
10. 変更差分に限定した修正（変更リクエストが提出された場合のみ）。 入力に既存の計画に対する変更リクエスト／差分が含まれる場合は、差分に限定して評価します。差分の範囲を守り、全面的に描き直さないこと。カバレッジマップを再トレースすること（変更された動作の対応関係を再設定し、削除された動作は対象から外し、ケースのない動作を残さない）。回帰テストの対象は、影響度とリスクに基づいて選ぶこと（すべてでも、ゼロでもありません）。発見された不具合の修正では、トレース可能な回帰テストケースを追加すること。計画自体のバージョンと変更履歴を記載し、廃止されたケースを明示すること。変更箇所のケースが条件 5～6 を満たすこと。変更されていない計画全体を再レビューする必要はありません。 差分が説明のない全面的な描き直しになっている、変更された動作に再トレース済みのケースがない、回帰テストの選定が不十分または過剰、あるいはバージョン／変更履歴がない場合は「ギャップ」です。適正な規模にすること： 新規開発の初回リリース（変更リクエストなし）では、この条件は該当なしであり、「ギャップ」にはなりません。 比例性。「テスターが実行でき、すべての動作がカバーされているか」は、プロジェクトの規模に応じて判断します。小規模なプロジェクトの計画では、不要なものを正当に省略できます。NFR がなければ非機能テストは不要（条件 9 は該当なし）、接続点がなければ統合テスト層は不要、動作が少なければカタログは簡潔でよく、新規開発なら amend セクションは不要（条件 10 は該当なし）です。これは適切な規模調整であり、抜けではありません。ケース数ではなく、テスターが実行できることと、列挙された動作がカバーされていることを評価してください。該当するすべての条件を満たす、小規模で完全な計画は合格です。簡潔さを理由に抜けを作り出さないでください。（条件 1、5、7 は、どの規模でも適用されます。）

ステップ 3：判定する

• approve — 該当するすべての条件を満たしています。テスターは記載どおりに計画を実行でき、上流で列挙されたすべての動作に追跡可能なケースがあり、カタログはリスクに応じて重み付けされ、必要な非機能テストには目標値が設定され、捏造された内容もありません。文体上の改善案が思い浮かんでも承認してください。基準は網羅性とテスト可能性であり、完璧さでも最大限の網羅性でもありません。
• revise — 該当する条件に、実際の明確な抜けが 1 つ以上あります。

努力を示すため、あるいはあると望ましいだけの要件を求めるために修正を求めないでください。条件は、満たされているか、満たされていないかのどちらかです。

ステップ 4：判定と実行可能な指摘を出力する

判定は、単独行として VERDICT: approve または VERDICT: revise の文字列をそのまま出力してください。コードフェンスや引用符で囲んだり、余計な語句を付けたりしないでください（ここにあるフェンスは説明用です）。

VERDICT: approve

続く行に指摘を列挙してください。revise の場合、指摘はすべて実行可能な内容にしてください。すなわち、不合格となった条件、正確な箇所、修正方法を示します。approve の場合、指摘は省略可能な、承認を妨げない注記です。修正が必要だと受け取られるような書き方は避けてください。

上流資料が提出されていない場合は、明示的な前提として記載してください（例：「api-spec が未提供のため、操作／エラーの網羅性（条件 1）は feature-spec のみを基準に判定」）。そのうえで、手元にある資料に基づいて他の条件を評価してください。実行できない確認を黙って見過ごしたり、自動的に承認したりしないでください。

適切な指摘では、抜けと修正方法が明確に示されています。

revise — 網羅性（条件 1）：feature-spec の動作「ユーザーはメールリンクからパスワードをリセットできる」に対応するケースがありません。修正方法：この動作への traces-to を設定したケースを追加してください（正常系に加え、期限切れ／無効なリンクの異常系も追加）。

revise — 非機能テスト（条件 9）：NFR-PERF は p95 <= 200ms を要求していますが、計画の性能テストの行には負荷プロファイルも目標値もありません。修正方法：負荷プロファイル（同時実行数／期間）、p95 の目標値、使用するツールを追加するか、この NFR は検証不能であると明記してください。

revise — 差分範囲に絞った amend（条件 10）：変更リクエストで「チェックアウト時にクーポンを適用する」動作が変更されていますが、カタログの再トレースが行われておらず、回帰テストセットも選定されていません。修正方法：クーポンのカバレッジ行を再マッピングし、そのケースを追加または調整して、影響範囲とリスクに基づく回帰テストセットを選定してください（クーポンに依存するカートと価格設定のケース）。

不適切な指摘は、曖昧で実行に移せません。

カバレッジをもっと充実させられます。（どの動作ですか？どのケースですか？どう修正すればよいですか？）

ルール

必ず守るルール（違反禁止）：

• 判定行は VERDICT: approve または VERDICT: revise のいずれか1行だけを出力してください — この文字列を単独の行に記載し、ほかの文字は同じ行に含めないでください。後続のツールが解析します。別の判定表現は使わないでください。
• 評価に徹してください。作成はしないでください。 指摘事項を返し、計画を書き換えたり、修正したり、足りない内容を補ったりしないでください。作成者が修正します。
• 単一の評価基準を適用してください。 Step 2 の10項目（作成者が準拠する「authoring-test-plan」の Step-7 と同じ基準）に照らして評価してください。条件を独自に追加したり、非公開のより厳しい基準を適用したりしないでください。
• 網羅性は重要です。 提出された upstreams にあるすべての振る舞い／操作／エラーを列挙し、それぞれに追跡可能なケースが1つ以上あることを確認してください（条件1）。実際に提出された upstream を基に列挙し、入力が固定されていると想定しないでください。
• リスクに応じた設計にしてください。組み合わせ網羅でも、薄すぎる内容でもいけません。 網羅性の欠落、入力の全組み合わせ直積、および水増しされた／薄いケース一覧は、それぞれ revise の理由になります（条件6）。ケース設計の手法は作成者を支援するためのものであり、手法名の使用を要求するのではなく、結果で評価してください。
• 非機能要件は、対象を絞り、相応の水準にしてください。 正当化される非機能要件にアプローチ／目標がない場合は欠落です。対象の特性上、該当しない非機能要件は要求しません。また、目標を捏造してはいけません。非機能要件は条件9で評価し、条件2は機能要件のみを対象とします。同じ性能水準の欠落を両方で重複して数えないでください。
• ML のケースには固定の正解ではなく、指標の閾値を使ってください。 ML／確率的なケースの期待結果は、名前を示したデータセット上の指標の閾値（またはメタモルフィック関係）にしてください。「モデルが正確である」は実行できない結果であり、条件5で却下されます。確率的なケースであることを認識し、新たな基準を課さないでください。
• 変更要求が入力された場合は、変更差分だけを対象にレビューしてください（条件10）。 条件10を適用するのは変更要求が提出された場合のみで、新規作成の場合は該当しません。変更差分、網羅性／追跡可能性の整合性、および回帰テストの選定を評価し、変更されていない計画は評価対象にしないでください。
• 捏造しないでください。 upstream に宣言されていない振る舞いをテストするケースは欠陥です（条件7）。実際に欠落している場合は、前提条件として指摘してください。traces-to を実際の upstream と照らし合わせて抜き取り確認してください。
• 誤って revise と判定しないでください。 適用可能なすべての条件を満たす計画は、内容が薄くても承認してください。列挙されたすべての振る舞いを網羅しつつ、相応の規模に抑えられていることは欠陥ではありません。実際に存在し、明確に特定できる欠落がある場合のみ revise としてください。
• 誤って approve と判定しないでください。 同意を得るために、実際の欠落を見逃して承認してはいけません。重大な欠落があれば revise としてください。
• テストできない完了基準は欠落です。 読み手によって判断が分かれうる終了基準は条件3を満たしません。完了基準は、機械的に判定できるもの（網羅率の下限と未解決欠陥の閾値）でなければなりません。
• upstream が不足している場合は明示してください。黙って問題なしとしてはいけません。 明示的な前提条件として示し、手元にある情報で残りを評価してください。デフォルトで approve にしてはいけません。
• 文書に提出された upstream に基づいて評価してください。 提出されていない upstream を理由に revise としてはいけません。一方、提出済みの upstream を計画が無視している場合（提出された feature-spec に記載された振る舞いにケースがない場合など）は、正当な指摘です。
• revise の指摘はすべて、対応可能な内容にしてください。 未達の条件、該当箇所、具体的な修正方法を示してください。曖昧な指摘は避けてください。

推奨事項（必要に応じて変更可能）：

• 指摘事項は重要度順に並べてください。まず網羅性の欠落と捏造、その次にケース一覧の規模と非機能要件、続いて amend、最後に軽微なものとしてください。
• 作成者が評価基準と対応付けられるよう、各指摘に条件番号／名称を記載してください。
• approve に添えるコメントは少数にし、明確に非ブロッキングであることを示してください。

注意点

• 実行可能性ではなく、完全性を基準に承認すること。 すべてのセクションが揃っていても、計画が実行不可能な場合があります（事前条件がない、手順が曖昧、期待される結果を観察できない、トレース先がないなど）。テスターが実行して追跡できるかを判断してください。テンプレートが埋まっているかではありません。
• ケースのない動作。 計画は、長い一覧やカバレッジマトリクスがあって、一見徹底しているように見えても、上流の動作のうち1つに対応するケースがひそかに抜けていることがあります。対策は、上流の動作を列挙して一つずつチェックすることだけです（条件1）。一覧が長くても、網羅性の証明にはなりません。
• 厳密さに見える組み合わせ爆発。 あらゆる順列を列挙した一覧は網羅的に見えますが、保守不能で、リスクの重み付けもできていません（条件6）。10個のスイッチを持つモジュールに1,024件のケースがあるのは欠陥です。リスクの高い領域には深さがあり、単純な領域はハッピーパスだけになっているかを確認してください。
• 薄すぎる／水増しされた一覧。 互いに言い換えただけのケース（水増し）や、リスクの高い領域にハッピーパスのケースしかない状態（薄すぎる）は、件数が適切に見えても、どちらも条件6を満たしません。リスクに照らして深さを判断してください。
• テスト不可能な終了基準。 「カバレッジが十分ならテスト完了」は、機械的に判定できません（条件3）。実際の終了基準は、合格したケースと未解決不具合の閾値に結び付いています。
• MLの期待結果として「モデルが正確である」とすること。 非決定的なシステムには固定されたオラクルがありません。決定論的な合否判定は実行できません（条件5）。名前を指定したデータセットに対するメトリクスの閾値、またはメタモルフィック関係を受け入れてください。条件5を超える新たな基準を作らないでください。
• 非機能要件の二重計上や過剰要求。 パフォーマンスレベルの欠落を条件2と条件9の両方で指摘しないでください。これは条件9の範囲です。また、プロジェクトの類型に見合わない非機能テストの種類を要求しないでください（条件9は比例性を重視します。NFRがなければ該当なしです）。
• 捏造されたケース。 上流で宣言されていない、ありそうな動作をケースでテストしている場合があります（条件7）。トレース先を抜き取り確認してください。実際の上流の根拠がないケースは、カバレッジではなく欠陥です。
• 修正を全面レビューとして評価すること。 変更依頼では、変更差分、カバレッジ／トレースの整合性、回帰テストの選定（条件10）を評価してください。変更されていない計画を最初から全面レビューするのではありません。反対に、カバレッジを再トレースせず、回帰テストのセットも選定していない修正を、問題なしとして通さないでください。
• 体系的な過剰指摘（誤った修正要求）。 問題を見つけるよう依頼されたレビュー担当者が過剰に修正し、妥当な計画を欠陥ありと判断してしまうことがあります。基準を適切に調整してください。条件の不足とみなすのは、明確に特定された実在の欠陥がある場合に限ります。ケースの順序や、自分なら別のレベルを選んだという理由ではありません。
• 規模に見合った計画への誤った修正要求。 小規模プロジェクトの計画が適切に小さいこともあります。ケースは少数で、NFRがなければ非機能テストはなく、接続点がなければ統合テスト階層もありません。これは適切な規模設定です（条件1、5、7は引き続き適用されます）。
• これをリリース手順書や設計レビューのゲートと混同すること。 ここで評価するのはQA／検証計画です。release-runbook-reviewでは、この計画の終了基準を再利用する運用手順を評価します。design-reviewでは、エンジニアリング設計文書をコードベースと照合して評価します。
• 判定トークンの揺れ。 「Approved」、「LGTM」、「needs work」、または段落の途中に埋め込まれた判定は、パースできません。単独の行に、文字列 VERDICT: approve|revise をそのまま出力してください。

アンチパターン

• ゴム印のように承認する。 カタログの長さをざっと見て承認すること。ゲートは、テスターが実行できない計画や、振る舞いを見落とした計画を見つけるためにあります。
• 上流の列挙を省略する。 「カタログが長いから、カバレッジは十分なはず」と考えること。上流の振る舞いを列挙し、それぞれにチェックを付けなければ、最も影響の大きい欠陥クラス（条件 1）を見落とします。
• リスクではなくケース数を数える。 カタログは大きければよいわけではありません。基準となるのは、リスクに応じて重み付けされたカバレッジです（条件 6）。
• 条件を勝手に作る。 基準にない独自の要件を追加することです（「トレーサビリティツールへのエクスポート／特定のテスト管理フォーマット／文字どおりのデシジョンテーブル／探索的テストの階層を含めるべき」など）。判断するのは10個の条件だけです。テストケース設計手法、探索的テスト／SBTM、メタモルフィックテストは執筆者を支援するものであり、求めるのではなく、あくまで成果で評価します。これは新たな支援手法を導入する際の重要な歯止めです。
• 過剰主義。 条件 9 は比例性を重視します。必要性のない小規模なプロジェクトに、非機能テストの種類や統合テストの階層、あるいはより網羅的なカタログを要求しないでください。
• 細部への過剰な指摘で修正を求める。 ケースの順序に関する好みや、あると望ましい程度のものを欠陥として扱い、阻害要因にしないでください。修正を求めるのは、カバレッジや実行可能性を実際に妨げる問題に限ります。
• 黙って書き換える。 レビュー中に自分で執筆すると、作成と評価の分離が崩れます。
• 曖昧な判定。 「ほぼ承認ですが……」や、判定を2行に分けることです。判定は一つだけ、トークンも一つだけにしてください。

出力

テスト計画1件に対する、単一のレビュー結果です。

• 判定行は1行 — VERDICT: approve または VERDICT: revise を、独立した1行にそのまま記載します。
• 指摘事項 — revise の場合は、修正を妨げているギャップごとに、実行可能な指摘を1つ記載します（満たしていない条件＋該当箇所＋具体的な修正方法）。approve の場合は、任意で阻害要因ではない注記を記載できます。

レビュー対象の計画は、現在はテキスト形式です。つまり、戦略の説明＋カバレッジマトリックス＋非機能要件マトリックス＋テストケースカタログです（ローカルのドキュメント用バックエンドを介した Markdown）。レビューの方法と基準は媒体に依存しません（将来テスト管理ツールへのエクスポートが導入されても、変わるのは媒体だけです）。抽象的なコンシューマーとは、作成からレビューまでのループをオーケストレーションするものです。approve は計画を実行に進めるために承認します（リリース用ランブックで終了基準を再利用できるようにします）。revise は、範囲を定めた修正作業のために指摘事項を返します。

関連項目

• authoring-test-plan — このペアの作成側です。このスキルが評価するものと同じカバレッジおよびテスト可能性の基準に沿って計画を作成します（その Step-7 がこの10個の条件です）。両者を組み合わせることで、基準を一元化し、作成とレビューの間で基準がずれるのを防ぎます。
• 上流の feature-spec／api-spec／PRD／NFRs — 各ケースの根拠となる文書です。このゲートでは、そこに記載された振る舞い／操作／エラーを列挙し、それぞれに追跡可能なケースがあること（条件 1）と、NFR がカバーされていること（条件 9）を確認します。これらの文書は、それぞれの作成時に別途ゲートを通過しています。
• release-runbook-review スキル — この計画の終了基準を再利用する、運用上の本番リリース用ランブックを評価するゲートです。文書も基準も異なります。
• design-review スキル — エンジニアリング設計文書（仕様書、計画書、RFC、ADR）を評価し、主張をコードベースに照らして検証するゲートです。ゲートも成果物も異なり、検証計画を対象とするものではありません。
• テスト計画テンプレート／content-template ツール — セクションの構成を担います。このスキルが評価するのは基準に照らした品質であり、構成への準拠ではありません。

段階的な開示

• references/coverage-testability-bar.md — 10個の条件それぞれについて、合格／ギャップの兆候と具体的な指摘例を記載しています（特に掘り下げた条件 3／4／5、新しい条件 9 の非機能要件と条件 10 の修正）。誤った修正要求を避け、条件を勝手に作らないための指針も含まれています。基準を詳細に適用する場合に読み込んでください。
• references/sources.md — レビュー方法の調査根拠を記載しています（カバレッジとテスト可能性の基準の一元化、ISTQB／ISO-IEC-IEEE 29119／WCAG 2.2／OWASP／NIST に基づく根拠、誤った修正要求を避ける指針の背景にあるレビュー担当者の過剰修正）。指針の出典を監査する場合に限り読み込んでください。

本文の予算

• description は 1,024 文字以下（agentskills.io の上限）。Claude はリスト内の description と when_to_use の合計が 1,536 文字を超えると切り詰めます。
• 本文は約 500 行／5,000 トークン以下にします（各ターンでコンテキストに保持されます）。
• 参照ファイルごとに、10k トークン超で警告、25k トークン超でエラー。参照ファイルの合計は、25k トークン超で警告、50k トークン超でエラーです。

変更履歴

• 1.1.0（2026-06-15）— authoring-test-plan 1.1.0 に合わせて、10 条件の基準に単一ソース化して再構成しました。条件 2 を機能レベルに限定し、条件 9 として非機能テストを追加しました（該当する種類には数値目標を設定：パフォーマンス／セキュリティ／WCAG 2.2 AA／互換性／国際化。従来の条件 2 の非機能に関する条項を包含し、二重計上はしません）。条件 10 として差分の範囲に限定した修正を追加しました。条件 3（カバレッジの下限と未解決不具合のしきい値）、条件 4（テストデータ管理）、条件 5（ML のメトリックしきい値の認識）を強化しました。テストケース設計手法、探索的テスト／SBTM、メタモルフィックテストは、成果に基づいて評価する作成者向けの補助情報として維持しました（条件を創作しないよう注意を強化）。VERDICT 契約と入力契約に変更はありません。
• 1.0.0（2026-06-05）— 初回レビュー済みリリース。