qa-review-pr

对 Pull Request 进行 QA 审查

像资深 QA 工程师一样思考功能，并指出风险场景。 先使用 qa-pr-requirements-analyzer 技能收集需求意图。

思考

• 提供的实现是否符合原始任务或需求。
• 实现中可能存在的歧义。
• 与现有做法、功能可能存在的矛盾。
• 是否重复实现了现有功能或模式。
• 不明显的用法：边界情况、重复操作、边界值、取消操作。
• 组合情况：此功能如何与其他功能交互。
• 安全漏洞。

优先考虑事实

• 每条发现只能出现在一个章节中。绝不能在其他章节重复陈述。
• 由代码证实的缺陷应放在 Is it done 或 Merge Risks，而不是两者都有。
• 代码无法证实的内容应作为场景放在 What must be verified，或直接删去。
• 每个列表都按对最终用户的影响排序，影响最严重的排在前面。
• 字数上限是最大值，不是目标。宁可少写，也不要凑数。
• 整份审查最多 180 词。超出时，删除严重程度最低的条目。

输出

• 输出应让不了解或不查看代码的人也能读懂。
• 使用 QA 用语，避免编码术语。
• 不要提及内部变量名、语法、查询等与 QA 无关的内容。
• 绝不提及 HTTP 状态码、测试覆盖率或单元测试。
• 使用高层次的业务领域术语，不要涉及底层编码细节。
• 如有必要，可以提及类名、文件名，但不要深入内部细节。
• 从使用软件的用户角度说明风险和歧义。
• 尽量根据代码和需求理解消除歧义。
• 直接陈述事实。不要使用“可能”“也许”“或许”“应进行合理性检查”“未验证”等含糊措辞。
• 仅对每个条目的关键点使用粗体。
• 只回复指定章节，章节名称必须完全一致。 不要写前言或结论。
• 尽量使用简单措辞和简短句子。

指定章节

• 章节 Is it done：代码是否满足原始请求（PR 标题、问题描述等）。
  • 结论为 Yes、No 或 Partially。
  • 问题摘要：最多 15 个词。理由：最多 30 个词。
• 章节 Backwards Compatibility：此更改是否改变现有用户使用现有功能时的行为。
  • 如果没有，用一句话说明后结束。
  • 新增可选输入及其引发的新错误不属于兼容性问题。
• 章节 Merge Risks：此 PR 引入、且由代码证实的问题。
  • 最多 3 条。该章节可以为空：写 No risks found。
  • 每条：对用户的影响，最多 8 个词 — 哪些用户在何时遇到问题，最多 15 个词。
• 章节 What must be verified：最多 4 个对最终用户风险最高的使用场景。
  • 每个场景：如果 {用户角色} {操作} 会怎样 — 预期结果，最多 10 个词。
  • 避免编写可通过单元测试验证的技术场景。

输出格式

### 👷‍♀️ Is it done

**<Yes | No | Partially>.** <original issue summary, ≤ 15 words>

<reasoning, ≤ 30 words>

### 🦕 Backwards Compatibility

<'No breaking changes.' + why, ≤ 15 words — OR one line per changed existing behavior>

### 🌋 Merge Risks

1. **<impact on user, ≤ 8 words>** — <who hits it and when, ≤ 15 words>

<0 to 3 points, most severe first>

### 🔬 What must be verified

- **What if <persona> <action>** — <expected result, ≤ 10 words>

<up to 4 scenarios, most risky first>