用途
Verify 是一个用于自动化测试、手动验证脚本和验收门禁的技能。它的核心理念是：验证即运行时观察。你需要构建应用、运行它、驱动它到变更代码执行的位置，并捕获你看到的结果。这个捕获就是你的证据，除此之外都不是。
该技能明确反对用运行测试或类型检查来替代验证。运行测试只能证明你能运行 CI，而不能证明变更有效。同样，不要通过 import-and-call 的方式写单元测试来验证，因为函数只是做了它该做的事，应用从未真正运行。
主要能力
- 确定变更范围：在 git 仓库中，通过
git log --oneline @{u}..、git diff @{u}.. --stat、git diff origin/HEAD... --stat、git diff HEAD --stat或gh pr diff等命令建立完整的变更范围。差异是事实依据，任何描述都是对它的声明，两者需对照阅读。 - 识别运行时表面：变更到达的表面是用户（人或程序）与变更相遇的地方。技能列出了多种表面类型及其观察方式：CLI/TUI 在终端输入命令并捕获窗格；服务器/API 通过套接字发送请求并捕获响应；GUI 在 xvfb/Playwright 下驱动并截图；库通过公共导出采样代码；提示/智能体配置运行智能体并捕获行为；CI 工作流调度并读取运行结果。内部函数不是表面，需要跟随调用者到达上述某一行。
- 获取操作句柄：首先检查
.claude/skills/目录，寻找匹配的verifier-*技能，这是仓库的证据捕获协议。技能位于仓库根目录和差异触及的包/应用目录中。如果没有匹配的验证器，可以使用run-*技能的构建/启动原语，或从 README/package.json/Makefile 冷启动，时间限制约 15 分钟。成功后应持久化所学内容，创建或编辑.claude/skills/verify/SKILL.md。 - 驱动变更：选择使变更代码执行的最小路径。例如，更改了标志就用它运行；更改了处理器就访问该路由；更改了错误处理就触发错误；更改了内部函数就找到到达它的 CLI 命令、请求或渲染并运行。
- 端到端验证：通过真实界面进行端到端验证，因为孤立的部分通过并不意味着流程工作，接缝处是 bug 隐藏的地方。如果用户点击按钮，就通过点击按钮来测试，而不是在底层 curl API。
- 探测边界：在确认声明后，主动探测周围情况，例如新标志的空值、重复传递、与冲突标志组合、拼写错误；新处理器的错误方法、畸形主体、缺失必填字段、超大负载；更改的错误路径的相邻错误；交互式/TUI 的中途 Ctrl-C、调整窗格大小、粘贴垃圾、快速按键、错误时刻按 Esc；状态/持久化的重复操作、陈旧状态、两个会话同时操作。
- 捕获证据：捕获标准输出、响应体、截图、窗格转储。捕获的输出是证据，记忆不是。对于共享进程状态（tmux、端口、锁文件），需要隔离，例如使用
tmux -L name、bind :0、mktemp -d。 - 报告：以内联最终消息形式报告，包含验证标题、结论（PASS/FAIL/BLOCKED/SKIP）、声明、方法、步骤（每个步骤是对运行中应用做的一件事及其显示结果，用 ✅/❌/⚠️/🔍 标记，至少一个 🔍 探测）、截图/样本、发现。
使用方式
该技能通过自然语言指令触发，适用于运行自动化测试、手动验证脚本和验收门禁的场景。使用时，按照技能指导的流程：确定变更范围、识别表面、获取句柄、驱动变更、探测边界、捕获证据、生成报告。
适用场景
- 需要验证代码变更在实际运行环境中的行为时。
- 进行验收测试或门禁检查时。
- 需要为代码审查提供可重放的证据时。
- 在 CI 之外进行手动验证时。
限制
- 如果没有运行时表面（如仅文档、仅类型声明、仅测试），应报告 SKIP 并说明原因。
- 对于破坏性路径（删除、发布、发送或写入工作区外的代码），如果没有干运行或安全目标，不应实时驱动，只能验证周围部分并说明未执行的路径。
- 如果无法到达变更可观察的状态（构建失败、环境缺少依赖、句柄无法启动），应报告 BLOCKED，并说明确切停止位置和
/run-skill-generator提示。 - 结论没有部分通过，"4 个中 3 个通过" 视为 FAIL，直到 4 个全部通过或被解释清楚。
- 当有疑问时，应判为 FAIL。错误的 PASS 会发布损坏的代码，错误的 FAIL 只多一次人工检查。
- 模糊的输出应判为 FAIL 并附上原始捕获，不要解释。