用途：诊断 VibeGuard 钩子延迟回归，适用于基准仍在预算内但比旧设计更慢的隐蔽情况，例如运行时迁移后 post-write-guard 路径丢失了 post-write-fast-check 快速路径。核心原则是把 CI 工件当作趋势来源，本地基准仅用于假设成立后的复现，因为机器负载、shell 启动、缓存状态和 --runs 次数会主导 P95。
主要能力：搜索既有基准文档与 CI 工作流；识别 PR 与主线运行；下载 bench-output 工件到按运行分目录；提取可比的 P95 值；对照预算契约与旧设计比较；定位根因并分类为预算失败、设计回归或测量缺口；验证修复。
使用方式：先用 rg 搜索 benchmark、bench-output、hook latency 等关键词，并查看 docs/reference/hook-latency-contract.md 与 .github/workflows/ci.yml；用 gh repo view、gh pr view、gh run list 获取仓库、PR 与运行元数据；用 gh api 确认工件存在，再用 gh run download "$RUN_ID" --repo "$REPO" -n bench-output -D "$OUT" 下载；用 jq 筛选以 (P95) 结尾的行；用 bash tests/bench_hook_latency.sh --runs=3 --fail-on-regression 判断 CI 是否失败；用 rg 与 git log/git show 关联代码路径。
适用场景：用户询问基准为何变慢、PR 改动钩子延迟或基准报告、需要与 PR #350 等旧锚点比较、钩子低于绝对预算但可能丢失快速设计、需要可复用的工件下载对比流程。
限制：本技能不自行修改基准预算，预算变更需在契约文档、CI 与测试中单独论证；不授权编辑钩子、运行时或 GC 脚本，仅用于调查与报告，实现需另立明确任务。旧工件过期时不得把重建的本地数字当作历史 CI 事实。避免比较不同 fixture（如 post-write-guard (100) 与 (5000)）或不同指标，报告须附运行 ID、提交 SHA、事件类型与工件路径。