用途：在功能实现完成后，系统化验证 issue 中的每条验收准则，并输出可追溯的验证报告。核心原则是每条准则都被验证、每次验证都有记录。开始时应声明正在使用该技能进行实现验证。
主要流程：第一步用 gh issue view [ISSUE_NUMBER] --json body -q '.body' 读取 issue 正文，解析 - [ ] 或 - [x] 形式的验收准则。第二步为每条准则规划验证类型与方式，如单元测试、集成、E2E 或人工。第三步执行验证：单元/集成可运行 pnpm test --grep "[test pattern]" 或指定测试文件；E2E 可用 npx playwright test [test file]，或使用 mcp__playwright、mcp__puppeteer 等浏览器自动化；人工验证则启动应用、导航操作、必要时截图并记录结果。
结果记录与报告：每条准则记录准则文本、状态（PASS、FAIL、PARTIAL、SKIP）、证据和备注。随后用 gh issue comment [ISSUE_NUMBER] --body 发布结构化报告，包含运行时间、执行者、commit、分支、结果表格、状态汇总、折叠的测试输出和后续步骤。通过准则可在 issue 正文中勾选，并用 gh issue edit [ISSUE_NUMBER] --body 更新；项目字段可经 project-status-sync 更新验证状态、达标数量、最后验证时间和验证者。
状态含义：PASS 表示完全达标，FAIL 表示未达标需修复，PARTIAL 表示可用但有问题，SKIP 表示无法验证并需说明原因。E2E 建议每次使用全新会话、在关键点截图、检查可见渲染、覆盖错误路径并清理会话。失败时应具体记录失败内容、复现步骤、错误信息或截图，修复后重新验证，不得把失败标为 PASS 或因“应该能工作”而跳过。完成前需确认所有准则已评估、状态明确、证据留存、报告已发布、复选框与项目字段已更新，失败项已记录后续步骤。全部 PASS 进入代码评审；有 FAIL 返回开发修复并重新验证；仅 PARTIAL 需与用户讨论是否可接受。该技能由 issue-driven-development 调用，并会调用 project-status-sync 与 issue-lifecycle。资料未提供具体安装命令、收费或平台限制信息。