visual-pr 的用途是规范 PR 正文的写法，让评审者不用先读代码就能明白改了什么、并看到它确实生效。它强调用为本次 PR 制作的证据说话，而不是只靠文字：同一输入在 main 与分支上的渲染对比、放慢到可判断缓动的动图、裁剪放大的边界情况，以及实测数字。
正文结构：开头 1–2 段大白话摘要（两段合计最多 120 词，写用户能感知的具体症状而非类别）；随后紧跟一个标题下的图示分组，每张图配 2–5 词粗体标题和一句说明输入、差异与观察位置的图注；细节部分按需使用 How（不明显决策与被放弃的方案及原因）、Verification（实测结果，长时可折叠）、Not in this PR（范围界定），以及按需的 Review first、Merge notes、Tests changed and why。参考 PR 约 1,300 词，建议更短。
视觉规范：每张图须对应一个评审者问题，否则删掉；成对图用表格并列为 main 与分支两列，适合窄主体；宽主体用整宽堆叠合成图；动效对比必须是一张合成 GIF；表格外不得连续两张图无文字。图注需回答三点：什么输入、面板或帧之间差异、看哪里。图像标签可写入图片本身，图内也要有说明条与时间或数值。
工作流：构建过程中就规划镜头并先渲染 main 确认前提；制作真实且确定的合成 fixture；确定性捕获（冻结或伪造时钟逐帧步进，并用同一 fixture 与输入脚本渲染 main）；用随附脚本合成（web-frames.mjs、compare.py、strip.py、gif.sh、check-body.sh、chart.py）；发布前逐张查看图片；用 --attach 上传媒体而不提交进 git；把正文写入专用临时文件后执行 gh pr create --title … --body-file "$body" --attach ./a.png 或 gh pr edit <n> --body-file "$body" --attach …，随后运行 scripts/check-body.sh <n>。
后端与全栈改动要“为行为做一块屏”，用图展示 trace 瀑布、ECDF 延迟、worker 泳道与回放 GIF、故障注入时间线、EXPLAIN 前后、契约 diff 或 ER 图；若改动对用户可见，还需同时给出用户操作层的 GIF 与请求层瀑布图。
限制与要求：不得声称未见过的结果；验证要写数字与命令而非结论，并区分“你运行的”与“作者报告的”；边界情况与影响面表格用于大多数 PR，纯复制或仅文案改动除外；媒体附着需 gh ≥ 2.99，仓库自身媒体规则优先。关于该技能的具体安装命令、运行环境依赖版本与收费信息，资料中暂未提供。