technical-quality-perspective

技術品質の観点

使用するタイミング

選択した提供段階において、宣言されたアーキテクチャ、API、データ、コード、セキュリティ、パフォーマンス、互換性、可観測性に関する根拠から、技術品質を評価する際に使用します。

入力とワークフロー

• stage は必須です。有効な値は requirements-analysis、test-strategy、test-strategy-review、code-review、test-case-writing、test-case-review、test-reporting、test-report-review です。
• stage を検証します。値がない場合、またはサポートされていない場合は、適用対象外を返し、サポートされている値を列挙して、有効なステージを指定するよう求めます。対応するプロンプトを正確に1つだけ読み込みます。
• code-review では、コードの識別情報（PR、コミット、ブランチ、リリースバージョンなど）とレビュー可能な変更内容（差分、ファイル、コード）の両方が必要です。いずれかがない場合はレビューをブロックし、指摘事項やマージ可否を推測しないでください。
• 選択したプロンプトの適用基準を適用します。提供された資料は事実として扱い、推論にはその旨を明記し、不足している資料については質問とアクションに置き換えます。

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

責務と範囲

• 選択した段階と提供された根拠に関連する場合に限り、アーキテクチャ、API、データ、互換性、セキュリティ、パフォーマンス、可観測性、保守性を扱います。
• 根拠、影響、重大度、不足情報、アクション、確信度を含む技術的な指摘を提示します。不足がある場合は条件付きのリスクを示す根拠にはなりますが、実装、メトリクス、脆弱性、実行結果を捏造してはいけません。
• 製品の範囲、ビジネスルール、受け入れ基準、リリース承認を判断しないでください。直接的な根拠がない限り、コードの正しさ、テストの実行、テスト合格を主張しないでください。

レポートの要件とセルフチェック

ブロックされている場合、または適用対象外の場合を除き、次の項目を出力します。概要、事実、根拠、技術的な指摘、影響と重大度、不足情報、質問、アクションと次のステップ、確信度。

• 有効なステージが指定され、対応するプロンプトが正確に1つ読み込まれている
• コードレビューではコードの識別情報とレビュー可能な変更内容が揃っている、または明示的にブロックされている
• 指摘事項は根拠に基づいており、不足や推論にはその旨が明記されている
• 製品やテストに関する事実を捏造または変更していない
• ステージに関連する技術的な観点のみを扱い、根拠なしにテスト合格やコードの正しさを主張していない

ステージの検証後は、対応するプロンプトのみを読みます。evals/ は回帰作業でのみ読み込み、プロジェクトの根拠としては使用しないでください。

レポートの出典情報

選択した stage、安定した source_id、提供された version をレポートのヘッダーに記載します。ソース ID がない場合は一時的なローカルロケーターを明記します。バージョンがない場合は捏造せず、不明と記載します。各指摘には、安定した finding_id、出典・根拠のロケーター、ステータスを付与します。各アクションは関連する指摘に紐づけ、解決に必要な根拠を指定します。提供されていない場合、担当者、日付、アクションのステータスは不明のままにします。これらは独立したレポート項目であり、他の Skill に依存するものではありません。

静的な指摘の場所と引き継ぎ

提供されたコードや行番号付きテキストには file:line@version を使用し、提供された根拠を正確に引用します。設計資料のみの場合は、その文書、セクション、バージョンを指定します。コードファイル名や行番号を捏造してはいけません。コードレビューまたは専門的な設計レビューに Skill 名で引き継ぐ際は、同じ指摘 ID と根拠を引き継ぎます。これにより、実行時の欠陥を主張したと重複させることなく、受け手側のレビューで詳細化できます。