需要为当前任务创建或更新 Pull Request 描述时…

当用户显式按名称调用 visual-pr，且需要为当前任务创建或更新 Pull Request 描述时使用。

适用场景

解决思路

1. 读取描述模板：`Read({SKILLBASE}/references/pr_description_template.md)`
2. 识别或创建 Pull Request。
3. 使用 `gh pr view --json url,number,title,state,baseRefName,headRefName 2>/dev/null` 检查当前分支是否已有 PR。
4. 如果没有 PR，检查 `git status --short --branch` 和当前分支上的提交。
5. 必要时提交任务相关改动，用上游推送分支，并为它创建 PR。
6. 遵循仓库的 git safety protocol。
7. 仅当当前分支没有相关工作且没有可安全创建的当前分支 PR 时，才请用户选择 PR。
8. 只收集解释改动所需的上下文。
9. 读取 ticket 和任何相关任务产物。
10. 读取完整 PR diff 以及足够的周边代码，以理解行为和归属。
11. 使用 `gh pr view` 收集 PR 元数据和变更文件。
12. 读取 `{SKILLBASE}/references/show-me.md`，了解用于 PR body 的可视化大纲约定。
13. 使用模板编写 PR 描述。
14. 将 **Why the change** 保持为恰好一句话。
15. 将 **Special things to note** 保持为 1-3 个 bullet。
16. 在 **Special things to note** 中优先写评审者警告、迁移、兼容性约束、有意省略或意外决策。
17. 没有特殊考虑时写 `- None.`。
18. 将 **Change outline** 写成紧凑的、受 `/show-me` 启发的结构视图，而不是散文或逐文件变更日志。
19. 只包含有助于解释此 PR 的视图。
20. 包含 SQL 表和 endpoint contract 变更，以及业务逻辑的 pseudocode。
21. 包含关键数据结构/类型变更。
22. 包含显示变更职责的浅层 file tree。
23. 包含 React 组件树变更，包括重要的 hooks、state 和 package boundaries。
24. 包含 call-tree、call-stack、control-flow 或 data-flow 变更。
25. 展示对现有形状的变更时优先使用 `diff` blocks。
26. 当大部分内容是新的时候，或 diff 表示法会掩盖归属或顺序时，展示完整目标形状。
27. 让每个视图聚焦于评审者需要的内容。
28. 省略没有变化的类别。
29. 可选：如果你知道 ticket id/url、humanlayer task url、相关 plan/document url 或其他相关链接，将其包含在 header 中，否则省略 header。
30. 保存和发布描述。
31. 当任务目录存在时，使用 `.humanlayer/tasks/{task-slug}/pr-description.md`。
32. 否则使用 `.humanlayer/tasks/pr-{number}/description.md`。
33. 使用 `gh pr edit {number} --body-file {output-path}` 更新 PR。
34. 确认更新成功。
35. 报告完成。
36. 读取 `{SKILLBASE}/references/describe_pr_final_answer.md`。
37. 使用该最终答案模板回应，包含 PR URL、保存的描述 URL 和简明的变更文件列表。
38. 始终阅读并遵循 `{SKILLBASE}/references/pr_description_template.md`。
39. 不要将 PR body 扩展到该模板之外。
40. 像一个人对另一个人说话那样写作：避免行话和俚语，使用简单、连贯、简洁的语言。

适用边界 · 注意事项

• 用户没有显式按名称调用 `visual-pr` 时不要使用。
• 环境没有 `gh` CLI、不是 GitHub 仓库或无法安全创建/更新 PR 时不要使用。
• 没有 `{SKILLBASE}/references` 模板文件或 `.humanlayer` 任务目录约定时不要依赖该技能产出。