用途：帮助智能体排查 PostHog Visual Review 运行——CI 捕获 storybook 与 playwright 截图，与已提交的基线哈希比对，直到人工批准可视变更才放行 PR。适用触发条件包括：PR 号、分支名或提交 SHA 与 visual review/VR/snapshot/screenshot/storybook diff/playwright snapshot/baseline/approve/tolerated/quarantine 等词同时出现；询问 PR 为何被阻塞、可视上改了什么、diff 是否真实；“我的运行完成了吗”“还剩什么要审”“这个 story 最近是否不稳定”；visual-review 的 GitHub 检查失败，或 posthog-bot 提到 visual review 的评论。若用户要查看渲染的 diff 图片本身，VR 网页 UI 更快。
主要能力（工具）：读工具（可自由调用）visual-review-runs-list（按 pr_number/commit_sha/branch/review_state 过滤，起点）、-retrieve（单次运行详情）、-snapshots-list（每次截图结果，含 identifier、result、diff%、classification、baseline 与 current 制品 URL，隔离的快照默认排除，可传 include_quarantined=true）、-snapshot-history-list（单个 story 最近 N 次运行，用于“不稳定检查”）、-counts-retrieve（队列聚合计数）、-tolerated-hashes-list（团队接受的已知 flake/可接受变体哈希）、visual-review-repos-list 与 -retrieve（仓库元数据）。可逆的纯 DB 分诊工具：approve-create（标记已审，不提交、不放行）、tolerate-create（标记单个变更为已知可容忍变体，不改基线）。不可逆的交付工具 finalize-create（把已批准基线提交到 PR 分支并让 GitHub 检查变绿）。
使用方式：approve-create 需要 id（运行 UUID，必填）和 snapshots:[{identifier,new_hash}]（new_hash 为 current_artifact 的 content_hash）。tolerate-create 需要 id 和 snapshot_id（两者均必填）。finalize-create 需要 id，可选 approve_all:true 先批准所有仍未决的 changed/new 快照；省略则默认为 false，逐张已审的分诊收尾。finalize 是全有或全无：除非每张 changed/new 快照已批准、容忍或隔离，否则返回 409 not_fully_resolved 并列出未决项。它只提交 DB 中已批准的快照，被容忍的快照保留基线永不被覆盖；推送基线提交后其 SHA 出现在 metadata.baseline_commit_sha；若无须提交或提交被跳过（无 PR，或 409 sha_mismatch 因 PR 有更新提交，此时检查保持红色，需在最新提交上重跑 CI 再 finalize），则该字段缺失。若返回 409 stale_run，说明运行已被取代，应 visual-review-runs-list {pr_number} 并对最新运行 finalize。
finalize 门禁：这是本技能唯一不可逆、面向外部的动作，如同向他人分支推送，绝不自动执行。调用 finalize-create 前必须满足：已实际查看当前（以及 changed 的基线）PNG 并逐张给出结论；已向用户展示结论并等待；用户已明确批准这一次运行——笼统的“把门禁弄绿”或“修好 PR”只是授权调查与建议，不是授权 finalize。approve-create 与 tolerate-create 是无需此门禁的可逆分诊，但也不交付任何东西。
常见工作流：“这个 PR 的 VR 状态如何”——visual-review-runs-list {pr_number, limit:5} 按 created_at 倒序取最新非 stale 运行；若 summary.changed>0 或 summary.unresolved>0，再用 snapshots-list 报告 changed 快照，回复 PR 号、运行 UUID、review_state、summary 计数和 _posthogUrl 深链。“diff 是真的还是无关”——结合范围匹配、flake 历史与实际渲染图，用 curl -s -o /tmp/vr-baseline.png "<baseline_artifact.download_url>" 与 curl -s -o /tmp/vr-current.png "<current_artifact.download_url>" 拉取 PNG 并查看，注意尺寸不一致通常是不稳定信号而非回归。flake 检查用 snapshot-history-list {id:snapshot_id}：多数未变而本次为离群→可能真实回归；跨无关分支/master 频繁 changed→flaky，建议容忍该哈希；近期 removed 或尺寸大幅跳变→基线可能过期，建议在 master 重新基线。队列分诊：counts-retrieve 看队列规模，list {review_state:needs_review, limit:50} 按作者或 run_type 分组，优先处理 summary.changed>0 的运行（new 通常只是尚无基线，易批准）。
输出期望：PR 状态先给一行结论，再 2-4 条支撑要点，始终附上运行的 _posthogUrl 深链；分诊/聚合问题用简短表格。
不要做：未经用户明确确认不要批准或容忍；不要因 PR 上 visual-review 检查红就认定与 VR 无关；result 为 changed 时不要仅凭元数据下结论，须拉取并查看基线图与当前图。
限制：最终交付需人工逐次确认；finalize 可能因未全决、sha 不匹配或运行被取代而失败；对渲染 diff 图片本身的查看，网页 UI 更快。资料未提及收费、价格、平台与效果信息。