test-strategy-plus

test-strategy-plus (EN)

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

使用するタイミング

• マイルストーン、ゲート、担当、トレードオフを含む、より包括的な戦略が必要な場合。
• ベース版の戦略よりも充実した計画資料が必要な場合。

スクリプトの機能範囲

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

ワークフロー

1. Progressive disclosure に記載されたメインプロンプト（カバレッジ、構成、品質基準）を読み、それに従います。
2. 要件、分析、技術、計画に関する直接の資料だけで、単独での利用に十分です。source_role が宣言されたロールレポートは、任意の構成入力であり、ロールの Skill のインストールは不要です。
3. 結果に影響するプロジェクトのコンテキストだけを追加します。対象範囲、環境、制約、リスク、依存関係、期待する成果物が該当します。
4. 入力が不完全な場合は、使える初稿を提示し、前提と不足情報を明示します。
5. 既定では Markdown を使用し、ユーザーからの要望がある場合にのみ形式を切り替えます。

基本制約

• リスク／ビジネスへの影響に基づいて優先順位を付け、すべてを同等に扱わないでください。
• 確認済みの事実と現時点での前提を分けてください。
• ユーザーが提示していないエンドポイント、フィールド、環境、根本原因を捏造しないでください。
• ロールレポートを使う場合は、ソースロールの帰属を維持し、デリバリー上の制約、品質に関する事実／結論、リスク受容を分けてください。
• Project Manager はスケジュール、リソース、依存関係、アクションの追跡を提示できますが、品質に関する結論、テストの事実、リスク受容を書き換えることはできません。レポートの内容だけを使用し、ロール Skill の内部実装には依存しないでください。
• 出力は実行可能なものにしてください。具体的なシナリオ、明確な優先順位、明確な次のステップを含めます。

段階的な開示

• 出力を作成する前に、prompts/test-strategy-plus.md を読み、それに従います（最低限のカバレッジ、出力構成、品質基準）。
• 既成のテンプレートが適している場合は、output-templates/ 内の対応するファイルを使用します。
• ユーザーが例や既存アセットとの整合性を求める場合は、関連する examples/ を読みます。
• フレームワーク、トラブルシューティング、スキーマに関する詳細な注記は、references/ 内の関連ファイルだけを読み、ディレクトリ全体を読み込まないでください。
• 形式変換やヘルパーによるチェックには、一から作り直すのではなく、既存の scripts/ を優先して使用します。
• このスキルの評価やリグレッションには、skill-up とともに evals/ を使用します。

提出前チェックリスト

• メインプロンプトの出力構成に従った
• 最低限のカバレッジに注力した：目標と対象範囲、リスクの優先順位、テスト手法と深度、リソースと担当の計画、マイルストーン、品質ゲート、開始／終了の判断、環境とデータの戦略など（詳細はメインプロンプトを参照）
• 最低限のチェックリストを網羅した、または省略した項目について説明した
• 高リスク項目に明確な優先順位を付けた
• ユーザーが提示していない詳細を捏造しなかった
• 前提と不足情報を明示した
• Project Manager のスケジュール／リソース／依存関係に関する制約によって、品質に関する結論を覆したり、承認権限のある者によるリスク受容の代わりとしたりしていない
• ロールレポートの内容でソースロールを維持した。直接の入力だけで十分であり、ロール Skill の内部ファイルへのリンクはない

よくある落とし穴

• 対象範囲やコンテキストが不足しているのに、完全であるかのように装わないでください。
• すべての項目を同等に重要なものとして扱わないでください。
• 前提や情報不足を省略しないでください。
• 現在のツールチェーンと無関係な一般論を並べ立てないでください。