用途：write-visual-pr 用于生成结构化的可视化 Pull Request 描述，让评审者能在短时间内理解改动。
主要能力：
- 前置检查：确认工作区是否干净、远程仓库与认证状态、分支是否已推送并与上游同步、是否已存在 PR、提交数量与 diff 规模；远程为 GitLab 时改用 glab 做对应检查（glab auth status、glab mr list --source-branch）。若 gh 或 glab 缺失或未登录（云端会话中常见），使用环境提供的工具（例如 MCP 服务器）完成同样的检查与创建，不因工具缺失而中止。
- 正文结构：写入 .scratchpad/<slug>/pr-body.md，使用简化技术语言与文档语言撰写，包含以下分段：
- In plain words：一段无术语的平实说明。
- New and changed files：用 + 与 ~ 标注的 ASCII 文件树。
- How it works：根据实际实现更新的图示，并说明与规格相比改了什么；仅当存在第二个重要参与方时才画时序图。
- Data and configuration：仅当相关时提供，含 erDiagram、数据行为、变量与简短“try it”代码块。
- How it was checked：改动前后的测试、达成的标准、已做的评审。
- Known follow-ups：有意留待后续处理的内容。
- 结尾附环境要求的署名行。
- 缺陷修复场景（bug-intake）：使用更短的正文结构：In plain words、Reproduction、Root cause、Fix、Contract（来源或假定）、Tests。
- 写作规则：目标篇幅约 120 行、评审者五分钟内可读完；不链接仓库之外的文件（如 .scratchpad/ 下的报告），改为在正文中概述；若为无人值守运行（unattended-run），在 Known follow-ups 前增加“Decisions taken without the user”段；若运行留下了技能反馈，附上拟议技能变更的简要表格。
- 校验：渲染每个 Mermaid 块，发布前修复失败项；逐条对照仓库复核所有数字与断言。
使用方式：
- 只做正文时：若没有远程仓库，或用户不想要托管 PR，则止步于生成正文，报告其路径并继续后续步骤。
- 分支未推送到远程时，推送前先询问用户。
- 已存在 PR 时更新而非再建一个。
- 仅在用户要求时推送并创建 PR： gh pr create --base <base> --head <branch> --title "<title>" --body-file .scratchpad/<slug>/pr-body.md GitLab：glab mr create --target-branch <base> --source-branch <branch> --title "<title>" --description "$(cat .scratchpad/<slug>/pr-body.md)" 标题使用 git-commit-organizer 的提交格式。
- 后续修改正文：gh pr edit <n> --body-file …；若因 Projects (classic) 的 GraphQL 错误失败，改用 gh api repos/<owner>/<repo>/pulls/<n> -X PATCH -F body=@.scratchpad/<slug>/pr-body.md；GitLab 用 glab mr update <n> --description "$(cat .scratchpad/<slug>/pr-body.md)"。
- 最后报告 PR 的 URL，并可提议以 pr-reviewer-guide 作为后续评论。
适用场景：需要为 GitHub 或 GitLab 生成清晰、带图示的 PR/MR 描述的开发流程；尤其适合改动涉及文件结构、运行流程或数据配置变化，且希望评审快速理解的情况；也覆盖缺陷修复的简短说明需求。
限制与注意事项：不估算数字，所有数据须来自仓库核实；仓库外文件不作链接；不在未获用户要求时创建 PR；分支未推送时须先询问；工具未提供或未登录时不中止，但需使用环境可用工具替代；正文语言与简化技术语言、plain-visual-docs 等配套规范相关，这些配套技能的细节本次资料未提供。