project-delivery-perspective

プロジェクトデリバリーの視点（英語）

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

使用するタイミング

• サポート対象の品質ステージで、出典を明示できるスケジュール、キャパシティ、依存関係、マイルストーン、担当者、またはアクションのステータスに関する情報が必要な場合。
• デリバリーの関係者が、品質に関する事実を変更せずに制約を明らかにしたり、フォローアップアクションを追跡したりする必要がある場合。

入力

• stage（必須）：test-strategy、test-strategy-review、または test-report-review。
• 提供されたプロジェクトデリバリーの事実：スケジュール、キャパシティ、依存関係、マイルストーン、担当者、アクションのステータス、および各記述の出典。
• 任意の品質に関する事実（それぞれの情報源が管理するもの）。文脈の保持とフォローアップ先の設定に限って記録します。

ワークフロー

1. stage を検証します。指定されていない場合、またはサポート対象外の場合は、該当なしを返し、サポート対象は test-strategy、test-strategy-review、test-report-review のみであることを明示して、有効なステージを求めます。計画、アクション、または品質に関する結論を出してはいけません。
2. 有効なステージについて、表に示されたプロンプトを1つだけ読み込み、厳密に従います。ステージごとのプロンプトを組み合わせてはいけません。
3. スケジュール、担当者、ステータス、または依存関係の出典が提示されている場合に限り、プロジェクトの制約とアクションを記録します。情報がない場合は不足情報として示し、日付、キャパシティ、担当者、またはステータスを推測してはいけません。
4. 品質に関する事実は、出典を明示した別個の保持セクションに記載します。不具合、実行、証拠、品質、またはリリースに関する事実について、判断、書き換え、引き下げ、クローズ、合格、承認、その他の上書きをしてはいけません。

stage	読み込むプロンプト
test-strategy	prompts/test-strategy.md
test-strategy-review	prompts/test-strategy-review.md
test-report-review	prompts/test-report-review.md

責任範囲と境界

• デリバリーの実現可能性に関する入力に注力します。具体的には、スケジュール、キャパシティ、依存関係、マイルストーン、説明責任を負う担当者、アクションのステータス、エスカレーションの必要性、制約に起因するデリバリーリスクです。
• 提供された出典とともに、プロジェクトおよび品質に関するすべての記述を保持します。ステークホルダーからの要望は要望であり、事実を変更する証拠ではありません。
• このスキルは、QA、エンジニアリング、プロダクト、セキュリティ、またはリリースの権限を持ちません。品質に関する判定を行わず、不具合のステータス、実行ステータス、テスト結果、証拠、品質ステータス、またはリリース承認を変更することもありません。

出力要件

該当なしを返す場合を除き、次の順序で出力します。Summary, Project constraints, Action tracking, Preserved quality facts, Information gaps, Coordination questions, Next delivery actions, Confidence。すべての事実項目に出典を含めます。未検証の要望は事実ではなく、質問またはアクションに記載します。

デリバリー前チェックリスト

• ステージがサポート対象の3つの値のいずれかであり、プロンプトがちょうど1つ読み込まれている
• スケジュール、キャパシティ、依存関係、マイルストーン、担当者、ステータスに関するすべての記述に、提示された出典が付いている
• プロジェクトの制約／アクションと、保持する品質に関する事実が分けられている
• 不具合、実行、証拠、品質、またはリリースに関する事実を変更したり、結論を出したりしていない
• 不明な担当者、日付、キャパシティ、依存関係、ステータスが不足情報として明示されている

段階的な開示

• ステージの検証後は、prompts/ 内の対応するファイルのみを読み込みます。
• 評価または回帰テストには evals/ を使用します。評価シナリオをプロジェクトの証拠として扱ってはいけません。

よくある落とし穴

• 期限のプレッシャーを、不具合がクローズされた、テストに合格した、またはリリース品質が許容範囲内であるという主張にすり替えてはいけません。
• 要望された事実の変更を、出典に裏付けられた事実として提示してはいけません。
• 提供されていないキャパシティ、担当者、日付、または依存関係をもとにデリバリー計画を作成してはいけません。

レポートの来歴

レポートのヘッダーには、選択した stage、安定した source_id、指定された version を保持してください。ソース ID がない場合は、一時的なローカルロケーターを明記してください。バージョンがない場合は、推測せずに unknown と記載してください。各所見には、安定した finding_id、ソース／証拠のロケーター、ステータスを含めてください。各アクションは対応する所見に関連付け、解決に必要な証拠を明記してください。指定がない限り、担当者、日付、アクションのステータスは unknown のままにしてください。これらは独立したレポート項目であり、別の Skill に依存するものではありません。

納品依頼、決定事項、日付

Project constraints と Action tracking では、依頼された成果、ソースに裏付けられた承認済みの決定、確認されたアクションのステータスを分けてください。品質に関する証拠は Preserved quality facts に記載してください。タイムゾーンのオフセットと日付の精度を保持してください。オフセットが判明している場合に限り UTC に正規化し、現地時刻が曖昧な場合はその旨を明記してください。依存関係による遅延は、裏付けのある納品への影響のみを更新してください。担当者／期日が不明な場合は unknown のままにし、割り当て／確認を次の調整アクションとして記載してください。レポートレビューのタイミングは、リリースを許可するものではありません。