ux-quality-perspective

UX品質の観点（英語）

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

使用するタイミング

• 品質工程において、情報アーキテクチャ、インタラクションの状態、一貫性、レスポンシブ動作、またはアクセシビリティに関するUXの観点が必要な場合。
• プロダクト、デザイン、エンジニアリング、QAの各担当者が、UI、プロトタイプ、ユーザーフロー、またはUIテストの証拠を、実行可能なエクスペリエンスリスクの判断に結び付ける必要がある場合。

入力

• stage（必須）：requirements-analysis、test-strategy、test-strategy-review、code-review、test-case-writing、test-case-review、test-reporting、またはtest-report-review。
• プロトタイプ、スクリーンショット、UIの説明、デザイン仕様、ユーザーフロー、変更資料、テストアセット、レポートなど、提供された証拠。
• 任意のコンテキスト：対象ユーザー、デバイス／ブレークポイント、支援技術、デザインシステム、リリース範囲、既知の制約。

ワークフロー

1. stageを検証します。未指定またはサポート対象外の場合は、該当なしと返し、サポート対象のステージを示して有効な値を求めます。埋め草の指摘事項を生成してはいけません。
2. 有効なstageに対応する表内のプロンプトを1つだけ読み込み、厳密に従います。複数のステージのプロンプトを組み合わせてはいけません。
3. まず提供された資料に基づいて適用可能性を判断します。test-strategy、test-strategy-review、code-review、test-case-writing、test-reportingは条件付きで参加します。追跡可能なUI／UXへの影響、または関連するエクスペリエンスの証拠がある場合に限り分析します。それ以外の場合は、理由、判明している事実、不足情報、再評価に必要な資料を添えて該当なしと返します。埋め草の指摘事項を書いてはいけません。
4. requirements-analysisは、プロトタイプがなくても適用可能です。確認済みの要件に関する事実、UXの証拠の不足、質問、および必要なプロトタイプ／フロー／状態の資料のみを報告します。画面、状態、文言、デバイス間の挙動を決して捏造してはいけません。
5. 事実、証拠、推論、未検証項目を分けた、単独で読めるUX品質レポートを作成します。

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

UXの責任範囲と境界

• 提供されたUX／UIの証拠のみを用いて、情報アーキテクチャ、ナビゲーション、見つけやすさ、インタラクションのフィードバックと状態、一貫性、レスポンシブ動作、アクセシビリティに焦点を当てます。
• プロトタイプ、フロー、状態、ブレークポイント、支援技術に関する証拠がない場合は、不明または確認が必要と明記します。画面、コントロール、文言、エラー状態、デバイスの挙動、テスト結果を決して捏造してはいけません。
• フロントエンド／バックエンドの実装レビュー、APIの信頼性やセキュリティの評価、テストの実施、リリース承認の代わりを務めてはいけません。それらの証拠がない場合、実装の正しさ、APIの信頼性、セキュリティ、テストの合格、リリース準備状況を断定してはいけません。

レポートの要件

該当なしを返す場合を除き、すべてのレポートに以下を順番どおり含めます：概要、事実、証拠、指摘事項、リスク、情報の不足、質問、対応、確信度。影響度に基づいて指摘事項、リスク、対応の優先順位を付け、各結論の根拠となる証拠と責任者を明記します。

提出前チェックリスト

• stageが有効であり、一致するプロンプトを正確に1つ読み込んだ
• まず適用可能性を評価した。該当しない条件付きステージには、埋め草の指摘事項が含まれていない
• プロトタイプがない要件分析では、証拠の不足のみを報告し、UIを捏造していない
• レポートで事実、証拠、推論、不足情報を分け、要件で定めたすべての項目を含めている
• 実装、API、セキュリティ、テスト、リリースに関する主張でUXの境界を越えていない

段階的な開示

• stage を検証してから、prompts/ 内の対応するファイルを 1 つだけ読み込んでください。
• 評価またはリグレッションには evals/ を使用し、スキルの検証を実行してください。評価ケースをプロジェクトの証拠として扱わないでください。

よくある落とし穴

• 一般的な UX チェックリストを、この製品で実証された欠陥として提示しないでください。
• プロトタイプがない場合に、画面、状態、モバイルでの動作を捏造して補わないでください。
• UX レビューを、裏付けのない実装の正しさ、API の信頼性、リリースに関する結論へとすり替えないでください。

レポートの出所情報

レポートのヘッダーには、選択した stage、安定した source_id、提供された version を記載してください。ソース ID がない場合は、一時的なローカル参照先であることを明記してください。バージョンがない場合は、作り上げずに「不明」と記載してください。各指摘には、安定した finding_id、ソース／証拠の参照先、ステータスを記載してください。各アクションには関連する指摘を紐付け、解決を確認するために必要な証拠を明記してください。担当者、日付、アクションのステータスは、提供されていない限り不明のままにしてください。これらは独立したレポート項目であり、別のスキルに依存するものではありません。

任意のユーザー体験に関する証拠マトリクス

プロジェクト資料でこれらの観点が選択されている場合は、入力方法 × デバイス／ブレークポイント × 支援技術 × UI 状態 を記録し、各セルにソース／バージョンと、観察結果または NOT_RUN／不明を記載してください。すべての組み合わせが当てはまると仮定したり、指定されていないデバイスを推奨したり、観察されていないセルを合格と判定したりしないでください。スクリーンショットが裏付けるのは表示されているセルのみです。キーボード、スクリーンリーダー、モバイル、復旧に関する主張には、それぞれ個別の証拠が必要です。