用途：verify 用于验证被改动的服务行为，用可重跑的凭据代替“构建通过”的模糊结论，适用于接口验证或判断改动能否合并。它强调“没有凭据就不算通过”。
主要能力：按顺序执行五道关卡，每道关卡都要在磁盘留下凭据。1）Build：改动代码能否组装，记录命令、退出码、输出尾部；2）Static：仓库自带的语法、类型、lint 与 schema 检查，逐工具记录退出码与问题数；3）Clean code：评审 diff 本身，按严重度判断是否阻塞；4）Scenario：对触及的 API 做真实调用，覆盖多种载荷变体，记录原始请求与响应；5）Report：生成 report.md，给出结论、受限项与后续动作。
结论只有三种：PASS 表示已运行且凭据符合预期；FAIL 表示已运行且凭据显示有问题；BLOCKED 表示无法运行（缺凭据、依赖不可达、无本地运行时）。BLOCKED 不能当作 PASS，必须说明解除阻塞所需的单一条件。同时要区分仓库原有失败与本次改动引入的回归。
使用方式：先用 git diff --stat <base>..HEAD 确定改动范围与 API 目标清单；加载适配器（VERIFY_* 赋值文件），解析顺序为 $VERIFY_ADAPTER_FILE、<target-repo>/.verify/adapter.env、adapters/<name>.env；导出 VERIFY_TARGET_DIR 指向目标仓库，凭据写入 .verify/<YYYYMMDD-HHMM>-<slug>/。随后依次运行 scripts/gate-build.sh --base <base>、scripts/gate-static.sh，再启动服务并确认进程包含本次改动，通过 scripts/token.sh 获取令牌（缓存到 .verify/.token-cache/），必要时创建真实账号，编写每端点场景 JSON，运行 scripts/run-scenarios.sh，写入端点执行后还要回读验证副作用。
适用场景：本地或开发环境的接口改动验证、合并前检查；生产环境禁止使用本技能执行读写，只读也会消耗真实会话与审计日志。
限制：每个端点至少三种变体（happy、boundary、negative）；写操作必须有前后观察；若进程早于改动提交则不能证明包含改动；缺少适配器需按模板自行编写；未提供凭据或账号时对应关卡标为 BLOCKED。具体实现细节与完整参考文档见技能仓库。