| name | pr-follow-up |
| description | 在别人提的 PR 的分支上直接改代码并推回去:切分支、改代码、commit、push 全部已获用户授权,不要再逐项确认权限。当用户贴出 PR 链接或 PR 号并要求跟进、按评审意见修改、补提交、修复该 PR 时使用。只在真障碍(工作区脏、push 被拒、仓库检查跑不过)时停下来问。 |
在指定 PR 的分支上直接改代码并推送。PR 是别人提的,后续改动由用户负责 —— 已授权:切分支、改代码、commit、push 全部直接做,不要再问权限相关的问题。
前提
- 用户调用时会贴 PR 链接或 PR 号。没给就按当前分支推断(
gh pr view --json number,url);都拿不到就要一个链接,别猜。
- 不需要问的:能不能改这个 PR、能不能 push 到别人的分支、要不要另开分支或提新 PR —— 答案一律是"直接在 PR 自己的分支上改、往回推"。
- 需要停下来的只有真障碍:工作区有未提交改动、push 被远端拒绝、仓库检查跑不过。这些说清楚现状再让用户决定。
1. 切到 PR 分支
先确认工作区干净,再切分支:
git status --porcelain
gh pr checkout <PR-URL 或号>
记下 PR 信息备用:
gh pr view --json number,title,url,headRefName,baseRefName,isCrossRepository,author
isCrossRepository=true(fork 过来的 PR)时 push 目标是作者的 fork,需要作者勾了 "Allow edits by maintainers"。不用提前确认,push 真报 403 再按第 5 节处理。
2. 确定要改什么
- 用户已经说清要改什么 → 照做。
- 没说清 → 先按
/pr-comments 的第 2、4 节抓取并分析评论,把未解决的 必改 项当成待办清单,再动手。做之前用一句话说明你打算改哪几条。
3. 改代码
- 就在 PR 分支上改,不新建分支。
- 只覆盖用户要求 / 评论指出的范围,不顺手重构无关代码。
- 跟着这个 PR 和周围代码已有的风格走(命名、错误处理、注释密度),不引入新模式。
- 改完跑仓库自己的检查:测试 / lint / typecheck(去 README、package.json、Makefile、CI 配置里找)。跑不过先修,不要带着红灯提交。
4. 提交
- commit message 跟着仓库现有风格(
git log --oneline -20 看一眼),别自创格式。
- 一个 commit 一个主题,别把无关改动塞进同一个 commit。
5. 推送
git push
- 默认不要 force push。确实需要改写历史(rebase / amend)时用
git push --force-with-lease,并在回复里说明原因。
- 推不上去时:
- 远端有新提交 →
git pull --rebase,重跑检查,再推。
- 403 / 分支保护 / fork 没开 maintainer edits → 说明具体原因和可选做法(比如改从自己的分支另提 PR),交给用户定夺。
6. 收尾
推送成功后汇报:改了哪些文件、commit hash、推到了哪个 remote/分支、仓库检查跑了什么结果。
若本次改动解决的是已授权评审者(名单见 ~/.claude/pr-reviewers.local)的行内评论,按 /pr-comments 第 5 节对相应 thread 自动 reply + resolve。
