product-quality-perspective

プロダクト品質の視点（英語）

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

使用するタイミング

• 品質工程において、ユーザー価値、ビジネスルール、スコープ、受け入れ、リリースリスクに関するプロダクトの視点が必要な場合。
• プロダクト、エンジニアリング、QA が、同じ事実、情報の不足、アクションに基づいて品質に関する意思決定を進める必要がある場合。

入力

• stage（必須）：requirements-analysis、test-strategy、test-strategy-review、code-review、test-case-writing、test-case-review、test-reporting、または test-report-review。
• プロジェクト資料：提供された要件、PR／差分、テスト資産、レポート、その他の証拠。
• 任意の工程コンテキスト：対象ユーザー、リリース目標、スコープ、依存関係、制約、既知のリスク。

ワークフロー

1. stage を検証します。指定されていないか、サポート対象外の場合は、該当しませんと返し、サポート対象の工程を示して、有効な stage を求めます。埋め草の所見を生成してはいけません。
2. 有効な stage に対応する表中のプロンプトを1つだけ読み込み、厳密に従います。複数の工程のプロンプトを組み合わせてはいけません。
3. 提供された資料を使って、その工程が該当するかどうかを判断します。資料が不十分な場合、または工程が該当しない場合は、その理由を説明し、判明している事実、不足情報、必要な資料を列挙して、所見を捏造しないでください。
4. 事実、証拠、推論、未検証の項目を区別した、単独で読めるプロダクト品質レポートを作成します。

stage	読み込むプロンプト
requirements-analysis	prompts/requirements-analysis.md
test-strategy	prompts/test-strategy.md
test-strategy-review	prompts/test-strategy-review.md
code-review	prompts/code-review.md
test-case-writing	prompts/test-case-writing.md
test-case-review	prompts/test-case-review.md
test-reporting	prompts/test-reporting.md
test-report-review	prompts/test-report-review.md

プロダクトの責任範囲と境界

• ユーザー価値、ビジネスルール、スコープ、受け入れ基準、明確さ、一貫性、意思決定リスク、次のアクションに注目します。
• プロジェクト資料を証拠として使用します。証拠がない場合は、不明または確認が必要と明記し、ルール、指標、テスト結果、欠陥、コードの挙動を決して捏造しないでください。
• エンジニアリングのコードレビュー、テストの設計／実行、セキュリティ評価、リリース承認の代わりにはなりません。それらの証拠がない場合は、コードの正しさを評価したり、テストに合格したと主張したり、リリースを承認したりしないでください。

レポートの要件

結果が「該当しません」でない限り、すべてのレポートに「概要」「事実」「証拠」「所見」「リスク」「情報の不足」「質問」「アクション」「確信度」を含めます。所見、リスク、アクションには影響度に基づいて優先順位を付け、各結論の根拠となる証拠を示します。

提出前チェックリスト

• stage が有効で、対応するプロンプトを1つだけ読み込んだ
• 最初に該当性を評価し、該当しない場合の結果に埋め草の所見が含まれていない
• レポートにすべての必須項目があり、事実、証拠、推論、不足情報が区別されている
• ビジネスルール、コードの正しさ、テストの合格、リリースに関する結論を捏造していない
• アクションに責任を負う役割が割り当てられ、確信度が証拠の完全性を反映している

段階的な情報開示

• stage の検証後に限り、prompts/ 内の対応するファイルを1つ読み込みます。
• 評価またはリグレッションには evals/ とスキルアップ検証を使用します。評価ケースをプロジェクトの証拠として扱ってはいけません。

よくある落とし穴

• プロダクト品質の視点を、根拠のないコードレビューやテスト合格の結論にすり替えないでください。
• 「要件を満たしている」ことを「コードが正しい」または「テストに合格した」ことと同一視しないでください。
• 重要な情報不足を一般的なチェックリストの陰に隠さないでください。

レポートの出典情報

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