用途：确认已交付的工作是否符合工单的验收标准，并写成产品经理可据以行动的报告。定位为常规质量工作，而非被动响应投诉。
主要能力：
- 双重验证规则：每条发现都要在代码中追踪、并实际运行代码确认。只读源码只能说明“应该发生什么”，运行才能说明“实际发生什么”；仅凭其一的结论不算发现，需补全或标注为未验证。
- 前置条件：必须先让应用在本地跑起来。需从 README、CONTRIBUTING、CLAUDE.md、compose 文件、安装脚本或项目指向的本地基础设施仓库中找到运行方式，启动并确认有响应后再测试。若无法启动，应停下询问用户，不得悄悄退化为仅读源码的报告；可如实提供“仅源码”选项，但需说明其结论未经运行、日志或真实请求响应确认，属较弱交付物。
- 收集验收标准：三个来源缺一不可——工单自身的验收标准列表、评论（PM 或相关方提出的任何要求都算验收标准，需读完整串，包括已答与未答的问题）、子议题（已交付、被标记 Won't Do、事后作为缺陷提交的内容）。测试前先编号写出，避免遗漏。
- 逐条在代码中追踪：定位实现代码，记录文件与行号，形成具体预测（满足、失败或部分满足，以及在何种输入下）。预测不是结果，只是待运行验证的假设。
- 运行验证：针对真实运行的应用而非脑内模型。仅后端改动可直接驱动 API（使用适当种子用户）或调用真实服务与任务；UI 改动在可用时驱动 Chrome，不可用则回退到 API 并说明所用方式。先做正向对照：在声称某事未发生前，先证明你的环境能观察到它发生。测试后不留残留（无新增行、无标志变更、无遗留文件）。
- 查重：在将任何发现称为“新”之前，必须搜索议题跟踪器（标注已提交并附链接，或标为新）与 git 历史（检查后续改动是否已修复；说明所测提交；反向确认引用为覆盖的开放工单其修复是否已落地）。同时阅读近似工单，以厘清需求差异或同类代码路径是否被遗漏。
- 检查现有测试：运行相关测试套件，对每条未被捕获的发现说明原因（测试将当前行为断言为正确、行为超出断言范围、该路径无测试），以指出补充覆盖的位置。
- 撰写并发布报告：作为可分享的产物发布，并在工单上发布一份。报告不含环境特定信息（数据库名、行数、端口、本地路径、种子数据）；不针对个人提问，未决事项统一放在末尾的 Open questions；开头写方法与 TL;DR；使用平实语言；完整证据默认折叠；如实报告，未复现的场景要明说并说明替代做法。
使用方式：技能启动时声明“Using qa-verification to test [ticket] against its acceptance criteria.”。详细运行指引见 references/running-the-code.md，报告格式与发布机制见 references/report-format.md。
适用场景：需要对照工单验收标准验证已交付功能、并产出可执行报告的质量检查工作。
限制：无法在本地启动应用时不能完成完整验证，只能询问用户或提供较弱的仅源码报告；报告不得包含环境特定细节；不得对个人提问；未复现场景须如实说明。