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，从表格中加载并严格遵循唯一一条提示词；绝不组合多个阶段的提示词。
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 有效，且已加载且仅加载一条匹配的提示词
• 已先评估适用性；不适用的条件性阶段不包含填充性发现
• 没有原型时，需求分析仅报告证据差距，不臆造 UI
• 报告区分事实、证据、推断和差距，并包含约定中的所有字段
• 未超出 UX 边界，未对实现、API、安全、测试或发布作出断言

渐进式披露

• 只有在验证 stage 后，才读取 prompts/ 中对应的文件。
• 对于评估或回归，使用 evals/ 并运行 skill-up 验证；不要将评估用例视为项目证据。

常见陷阱

• 不要把通用 UX 检查清单说成已证实的产品缺陷。
• 不要因缺少原型而虚构界面、状态或移动端行为。
• 不要把 UX 审查变成缺乏依据的实现正确性、API 可靠性或发布结论。

报告来源信息

在报告标题中保留所选的 stage、稳定的 source_id 和提供的 version。如果未提供来源 ID，请声明一个临时本地定位符；如果未提供版本，请写明 unknown，而不是自行编造。每项发现都有稳定的 finding_id、其来源／证据定位符和状态。每项行动都关联其对应的发现，并说明关闭该项所需的证据；除非已提供，否则负责人、日期和行动状态均保持 unknown。这些是独立的报告字段，不依赖其他 Skill。

可选的体验证据矩阵

当项目材料选择了这些维度时，记录 输入方式 × 设备／断点 × 辅助技术 × UI 状态，并为每个单元格记录来源／版本以及观察结果或 NOT_RUN／unknown。不要假定每种组合都适用，不要规定未提供的设备，也不要将未经观察的单元格标记为通过。截图只能支持其显示的单元格；键盘、屏幕阅读器、移动端和恢复操作相关的声明都需要各自的证据。