test-case-reviewer-plus

test-case-reviewer-plus（EN）

中国語版： 対応する中国語スキルを参照してください。

使用するタイミング

• テストの実行前またはリリース前に、既存のテストケースをより厳格にレビューする必要がある場合。
• 問題の重大度、ビジネスへの影響、再テストの順序を明確にする必要がある場合。

スクリプトの機能範囲

オプションの scripts/run_*.py は、解析済みの証拠やソース候補を NOT_ASSESSED として準備します。モデルの呼び出し、メインプロンプトの実行、意味的な結論、リスクの優先順位付け、完全なケースの作成、承認は行いません。メインプロンプトはエージェントが実行します。ヘルパーを実行する前に references/script-contract.md を読んでください。

ワークフロー

1. Progressive disclosure に記載されているメインプロンプト（網羅性、構成、品質基準）を読み、それに従います。
2. 直接提供された資料、またはユーザーが提供した複数ロールによるレビュー報告を受け入れます。ロール別の報告を使用する場合は、source_role とソース識別子を保持します。
3. 結果に影響するプロジェクトのコンテキストのみを追加します。範囲、環境、制約、リスク、依存関係、期待される成果物が該当します。
4. 入力が不完全な場合は、利用可能な初稿を返し、前提条件と不足事項を明示します。
5. 既定では Markdown を使用します。形式を切り替えるのは、ユーザーから求められた場合のみです。

主な制約

• リスク／ビジネスへの影響に基づいて優先順位を付け、すべてを同等に扱わないでください。
• 確認済みの事実と現時点での前提を分けてください。
• ユーザーが提示していないエンドポイント、フィールド、環境、根本原因を作り出さないでください。
• 出力は実行可能なものにしてください。具体的なシナリオ、明確な優先順位、明確な次のステップを示します。
• ブロッカー、重大なリスクのある網羅性の不足、保守性に関する指摘、価値の低いケースまたは重複ケースは、一般的な問題一覧にまとめず、それぞれ別のセクションに記載します。
• AI による指摘と推奨のみを出力し、常に human_final_decision: pending を出力します。最終的な合格、条件付き合格、または却下の判断は人間が行います。

段階的な開示

• 出力を作成する前に、prompts/test-case-reviewer-plus.md を読み、それに従います（最低限の網羅性、出力構成、品質基準）。
• 既成のテンプレートが適している場合は、output-templates/ 内の対応するファイルを使用します。
• ユーザーが例や既存のアセットとの整合性を求めている場合は、関連する examples/ を読みます。
• 形式変換やヘルパーチェックには、独自に作り直すのではなく、既存の scripts/ を優先して使用します。
• このスキルを評価または回帰テストする場合は、skill-up と evals/ を使用します。

納品前チェックリスト

• メインプロンプトの出力構成に従った
• 最低限の網羅性に関する重点項目：重大度の高い指摘、網羅性の不足、正常系シナリオの不足、異常系シナリオの不足、境界値シナリオの不足、トレーサビリティ、手順と期待結果の品質、ビジネスへの影響、…（詳細はメインプロンプトを参照）
• 最低限のチェックリストを網羅した、または省略した項目について説明した
• リスクの高い項目に明確な優先順位を付けた
• ユーザーが提示していない詳細を作り出していない
• 前提条件と不足事項を明示した
• 複数ロールの入力で役割のソースを保持し、4 つの主要な指摘カテゴリを別々に維持した
• AI の推奨を、人間による最終承認または却下の記録として装っていない

よくある落とし穴

• 範囲やコンテキストが不足しているのに、完全であるかのように装わないでください。
• すべての項目を同等に重要なものとして扱わないでください。
• 前提条件や情報の不足を省略しないでください。
• AI による合格／却下の推奨を、人間による最終判断に置き換えないでください。
• 現在のツールチェーンに関係のない一般論を羅列しないでください。