PR 描述编写器
读取当前分支差异，编写完整的 GitHub 拉取请求描述。通过一个命令创建或更新 PR。
写作风格
适用于所有生成的 PR 描述：
- 主动语态。使用“添加了 X”而不是“X 已被添加”。
- 摘要使用现在时（“添加了缓存层”），上下文使用过去时（“旧方法导致每次渲染 N 个请求”）。
- 短句，每个要点一个想法。
- 避免使用破折号（em dash），改用逗号或句号。
- 避免填充词，如“这个 PR”、“这个提交”、“根据讨论”。
- 具体性优于概括性：“将 p95 延迟从 800ms 降低到 90ms”优于“提升了性能”。
步骤 1：检查设置
确认 gh 已认证：
git auth status
如果未认证：运行 gh auth login 并按照提示操作。
确认当前目录是一个具有活动分支的 Git 仓库：
git branch --show-current
如果是分离的 HEAD 或无分支，则停止并要求用户指定要描述的分支。
步骤 2：收集差异上下文
运行以下所有三个命令以构建上下文：
文件摘要（更改了什么）：
git diff main...HEAD --stat
提交消息（为什么更改）：
git log main...HEAD --oneline
完整差异（如何更改）：
优先使用 origin/main（始终最新），否则回退到本地 main，最后是 master：
if git rev-parse origin/main &>/dev/null 2>&1; then
BASE=origin/main
elif git rev-parse main &>/dev/null 2>&1; then
BASE=main
else
BASE=master
fi
git diff $BASE...HEAD
如果差异非常大（超过 500 行），则仅读取 --stat 摘要和提交消息。同时读取差异的前 200 行以了解主要更改，而不处理整个输出。
还要检查现有 PR 并读取其当前标题/正文：
git pr view --json title,body,baseRefName 2>/dev/null
步骤 3：阅读格式指南
在编写任何内容之前，完整阅读 references/pr-format-guide.md。内化：
- 必需的章节及其顺序
- 如何编写每个章节
- 包含与省略的内容
- 测试章节的格式
步骤 4：生成描述
使用 references/pr-format-guide.md 中的格式编写 PR 描述。
规则：
- 变更章节中的每个要点都必须追溯到差异中的某处更改
- 不要发明代码更改所未隐含的测试步骤
- 如果某个章节没有相关的内容，则完全省略该章节（不要写“N/A”或留空）
- 截图章节：仅在差异中可见 UI 更改时才包含
- 如果提交消息解释了“为什么”，则在摘要中使用该上下文
质量检查点： 在呈现之前，请验证：
- 摘要为 1-2 句，主动语态，无填充词
- 每个更改要点都具体且可追溯到差异
- 没有发明度量或结果
- 测试步骤可操作（其他人可以按照执行）
- 任何行中都没有破折号
步骤 5：创建或更新 PR
向用户呈现描述并询问：“准备好创建 PR、更新现有 PR 还是仅输出？”
创建新 PR：
通过标准输入传递正文以安全处理反引号、引号和换行符：
git pr create --title "TITLE_HERE" --body-file - << 'EOF'
BODY_HERE
EOF
根据提交消息和差异摘要建议一个标题。标题应为祈使语气，长度不超过 72 个字符：“为用户会话查找添加 Redis 缓存”而不是“已添加缓存”。
更新现有 PR：
git pr edit --body-file - << 'EOF'
BODY_HERE
EOF
仅输出： 在代码块中呈现标题和正文，以便手动复制粘贴。
创建或更新后，确认：“PR 描述已更新。查看地址：[URL]”