pr

PR

为当前分支创建或更新拉取请求。

将 ../write-pr/SKILL.md 用作 PR 标题、描述、发布说明、API 变更、代码变更表和保留人工备注的标准参考。

工作流

1. 收集上下文：
   • 当前分支：git branch --show-current
   • 工作树：git status --short
   • 现有 PR：gh pr view --json number,title,url 2>/dev/null
   • 分支近期提交：git log main..HEAD --oneline 2>/dev/null || git log -3 --oneline
2. 检查是否有重叠工作，避免影响队友：
   • 列出涉及相同区域的未关闭 PR：gh pr list --state open --json number,title,url,author,headRefName,updatedAt，并搜索相关工作：gh pr list --search "<keywords>" --state open。
   • 将它们变更的文件与我们的文件进行对比（gh pr diff <number> --stat），判断是否存在实际重叠，而不只是文件名相同。
   • 如果有人已经为此创建了 PR：优先基于对方的工作继续，而不是与其竞争。可以提出将我们的分支基于对方分支、贡献审查意见或后续提交，或者移交我们的变更。只有当方案确实不同且值得创建竞争性 PR 时，才创建此类 PR；创建时应链接对方的 PR，并说明我们的方案有何不同，让审查者能轻松做出选择。
   • 如果发现有实质性重叠，应在继续之前向用户说明情况。
3. 准备分支：
   • 如果当前位于 main，请创建一个描述性的新分支。
   • 提交相关变更，不包括机密和明确标记为私有的内容。
   • 将分支推送到远程。切勿强制推送。
4. 在请人工审查之前，先进行一轮初步审查。并行启动几个子 Agent，从不同角度检查差异（git diff main...HEAD），然后将审查结果落实为具体修复：
   • 变更是否端到端地解决了所述问题，而不是只掩盖表面症状？
   • 变更是否让代码库变得更好——命名更清晰、没有无用或重复代码，也没有顺手引入回归？
   • 是否存在审查者会指出的奇怪抽象、过早泛化或不必要代码？优先采用更精简、直接的实现。
   • 检查差异中新增的注释是否冗赘，并按照 ../write-pr/SKILL.md § 注释检查中的说明执行陈旧邻近内容检查。更新 PR 时，这可以检查自 PR 创建以来分支新增的内容；对于长期存在的分支，这通常占大部分。
   • 修复明显值得修复的问题，让人工审查从高质量的差异开始。如果某项发现需要产品或设计决策，应向用户提出，而不是自行猜测。
   • 提交并推送此轮审查中进行的修复，确保在创建、更新或分享 PR 之前，远程分支已同步。切勿强制推送。
5. 如果不存在 PR，使用 gh pr create 创建一个。
6. 如果已存在 PR，使用 gh pr view --json title,body,labels,number 阅读其内容，并使用 gh pr diff --stat 检查变更文件摘要。
7. 如果现有 PR 与当前差异或 write-pr 标准不符，使用 gh pr edit 更新标题或正文。
8. 搜索相关议题，并在适当时使用 Closes #123 或 Relates to #123 在 PR 描述中关联它们。
9. 将 PR URL 分享给用户。

问题处理

提交时会自动运行钩子。对于格式、lint、类型或导入问题，如果修复方式明确且机械化，请予以修复。

如果钩子失败需要有实质影响的产品或实现决策，应停止并询问用户如何继续。

切勿强制提交或强制推送。

规则

• PR 内容标准遵循 ../write-pr/SKILL.md。
• 提交消息、PR 标题或 PR 描述中不得包含 AI 署名。
• 不得将自己或 AI 工具添加为共同作者。