test-strategy-review

テスト戦略レビュー

使用する場面

• テスト戦略の草案について、十分性、実現可能性、ビジネス上および技術上の制約との整合性を判断する必要がある場合。
• レビュー会議で、阻害要因、期限付きの条件、任意の非阻害的な改善を区別する必要がある場合。
• 要件、役割分析、技術メモ、またはプロジェクト制約が相反しており、人間が判断するための追跡可能な AI 推奨が必要な場合。

入力

提案されたテスト戦略を必須とします。提供された要件、役割分析、技術的制約、プロジェクト制約のみを使用してください。資料が不足している場合はギャップとして記録し、補完しないでください。特定可能なドキュメント識別子、情報源、提供された担当者を保持してください。

ワークフロー

1. prompts/test-strategy-review.md を全文読み、従ってください。これは単独で実行できる仕様です。
2. 戦略本文と情報源を検証し、不足または矛盾する入力を記録してください。レビュー可能な戦略が存在しない場合は、実質的なレビューを中止してください。
3. ビジネス要件のカバレッジ、テストの深度、実現可能性、環境、データ、品質ゲート、依存関係、明示的な除外をレビューしてください。
4. 阻害要因と非阻害要因を分け、各非阻害要因を、期限付きで必須の条件または任意の改善として分類してください。
5. 決定的なルールを適用し、ギャップに対する担当者と検証可能な修正依頼を含めて、AI 支援による pass、conditional_pass、または reject の推奨を作成してください。
6. 提出前に、証拠、範囲、担当者、推奨、人間の判断に関する境界を確認してください。

判断の制約

• 阻害要因が一つでもあれば、reject を推奨します。
• 阻害要因はないものの、明示されたゲートまでに解消すべき条件が一つ以上ある場合は、conditional_pass を推奨します。
• 阻害要因も条件もない場合は、pass を推奨します。任意の非阻害的な改善は残してもかまいません。
• 範囲、重大なリスク、ゲート、または除外に影響する未解決の情報源間の矛盾は、阻害要因として扱ってください。権限なく一方を選ばないでください。
• 担当者は入力に記載された人のみを使用してください。記載がない場合は unassigned とし、担当者の割り当てを修正依頼に含めてください。
• 戦略が記述するのは実施予定の作業であり、実施済みのテストではありません。テスト結果、証拠、リスク受容、免除、承認を決して捏造しないでください。
• 結果には常に AI-assisted recommendation と明記してください。最終的な pass、conditional_pass、または reject の判断は人間が行います。最終承認が行われたと主張しないでください。

出力仕様

次の順序で出力してください。Review Status, Inputs and Conflicts, Dimension Review Matrix, Blockers, Non-Blocking Items, Revision Requests, Exclusion Review, Recommendation Basis and Limitations, Human Decision Questions。各指摘と修正依頼には証拠を示し、影響を説明し、提供された担当者を保持し、検証可能な完了条件を記載してください。

条件付き読み込み

• 入力の検証、8つの観点のレビュー、分類ルール、出力構成について、実行のたびに prompts/test-strategy-review.md を読んでください。
• evals/ は、この Skill の評価または回帰テストを行う場合にのみ読み込んでください。評価シナリオは実際のプロジェクトの証拠ではありません。

提出前の確認

• 8つすべてのレビュー観点について、証拠、ギャップ、または該当しない理由が示されている
• 阻害要因と非阻害要因が分けられ、条件が任意の改善と混在していない
• 推奨が分類ルールに従っており、スケジュールの圧力によって品質上のギャップが見過ごされていない
• 情報源間の矛盾が明示されたままであり、変更、免除、判断が捏造されていない
• すべての修正依頼に対象、担当者または unassigned、期限／ゲート、完了を示す証拠がある
• 結果に AI 支援によるものと明記され、最終的な人間の判断が未確定のままである

よくある間違い

• 文書の長さから網羅性を推測せず、重大なリスクがテストとゲートに対応していることを確認してください。
• 環境の準備状況を後回しにできる詳細事項として扱わないでください。機能が不足していると、重大なテストを実施できない場合があります。
• 明示的な除外を無条件に受け入れず、承認された範囲、リスクの処置、情報源を確認してください。
• conditional_passを曖昧な妥協案として使用しないでください。すべての条件について、担当者を割り当てられ、検証可能であり、完了ゲートに紐付いている必要があります。