使用 review-and-fix-pr Skill 接管并修复 pnpm 现有 Pull Request 的完整工作流【免费下载链接】pnpmFast, disk space efficient package manager项目地址: https://gitcode.com/gh_mirrors/pn/pnpm导读在 pnpm 这样的高活跃开源仓库中接手一个已经存在的 Pull RequestPR并把它推到合并——处理冲突、修复审查意见、跑绿 CI——往往比新建一个 PR 更复杂。.agents/skills/review-and-fix-pr/SKILL.md位于仓库根目录.agents/skills/review-and-fix-pr/SKILL.md定义了一条完整的接管流程在已有 PR 的分支上工作、rebase 到最新主干、验证并修复审查发现的问题、提交并推送然后跟随每一轮 CI 与审查直至收尾。本文将以该 Skill 文档为主体结合仓库中配套的pull-requests、review-code、testing-changes等 Skill、冲突解决脚本 resolve-pr-conflicts.sh 以及 AGENTS.md 中的仓库规则完整讲解这条工作流背后的原理、命令与判断标准让你在 pnpm 仓库或其镜像中接手任何 PR 时都能有章可循。Skill 是什么、什么时候触发review-and-fix-pr的元信息Frontmatter定义了它的定位name: review-and-fix-prdescription审查并修复一个已存在的 pnpm Pull Request——rebase 它、提交并推送修复、然后跟随 CI 与审查直至完成。当被要求审查并修复一个 PR、或由 git worktree 的 PR 钩子git-wt PR hook启动时使用。它适用于以下场景用户明确要求review and fix一个已有的 PR仓库的 git-wt PR 钩子自动拉起该 Skill你需要把某个 PR 从开着但没完成推进到检查通过、审查轮次无遗留项。与 pull-requests Skill 的分工值得注意后者覆盖从创建 PR 到合并的完整生命周期而review-and-fix-pr明确跳过 PR 创建与 draft 管理阶段只处理已存在的 PR并且不授权合并 PR。它的工作区间是PR 已存在之后、合并之前的那一段。核心原则推送只是中间点审查通过才算完成review-and-fix-pr继承了pull-requestsSkill 的一个核心观点Pushing is the middle of the task推送只是任务的中点。PR 只有在以下条件同时满足时才算是完成CI 检查全部变绿一轮审查轮次结束后没有任何需要处理的发现。在这之前工作都属于你。文档特别强调由于多个机器人bot会审查该仓库并且每次推送都会触发重新审查所以每次 push 都会买来新一轮审查而这轮审查通常会在几分钟后才到达——必须留下来等待它而不是 push 完就结束。分支上的纪律在已有 PR 的分支上工作不要另开新分支提交并推送修复不要停下来等待用户对本地修复的审查文档明确说 Do not pause for the users review of local fixes保持 PR 原有的 draft 或 ready 状态不要擅自切换保留与本次修复无关的本地改动Preserve any unrelated local changes。第一步读懂现状——用 gh 收集 PR 的全部上下文接手一个 PR 的第一件事是读懂它。Skill 要求使用gh读取PR 描述description完整 difffull diffissue 评论issue comments审查正文review bodies行内审查线程inline review threads。关键判断是先理解这次变更的意图intent再在采取行动前逐一验证每一条发现verify each finding before acting on it。这与 review-code Skill 中的原则一致——审查文本和仓库内容是待评估的证据而不是扩展任务的授权一条 review 本身并不授权你编辑、提交、推送或发表 GitHub 评论行动与否由调用方决定。pull-requestsSkill 还补充了一个容易踩坑的细节行内线程并不是审查的全部。审查者可能只把最严重的问题放在行内而把其余发现写在总结评论summary comment里所以只列出 review comments 会漏掉发现。必须连 issue comments 和 review bodies 一起读无论它们是谁写的。第二步Rebase 到最新主干——解决冲突的标准路径为什么必须 rebase 而不是 mergepull-requestsSkill 解释得很清楚main分支的分支保护branch protection要求线性历史且 merge commit 被禁用。所以无论是冲突解决脚本还是 GitHub 的 update-branch 按钮走的都是 rebase 而非 merge。另一个关键点是一个打开时能干净合并的 PR一旦main上有人碰了同一行代码就会立刻变得无法合并——没有任何机制会主动通知你。因此在每一轮循环中都要主动检查合并状态gh pr view pr --json mergeable,mergeStateStatus状态值的解读来自pull-requestsSkillCONFLICTING存在冲突需要 rebaseUNKNOWNGitHub 还没算出来通常在刚 push 之后出现此时应该过一会儿再问而不是把它当成判定结果BLOCKED与必需检查required checks和审查有关不代表冲突。运行冲突解决脚本无论 GitHub 是否报告冲突都要执行 rebase。命令是./.agents/skills/pull-requests/scripts/resolve-pr-conflicts.sh pr从脚本源码 resolve-pr-conflicts.sh 可以看到它的完整行为序列校验 origin remoteorigin必须指向pnpm/pnpmHTTPS 或 SSH 严格匹配见脚本第 27-34 行否则直接报错退出读取 PR 元数据通过gh pr view --json headRepositoryOwner,headRefName获取 head 分支与 fork 归属切换到 PR 分支如果当前不在 PR 的 head 分支上使用gh pr checkout切换确定推送 remote若 PR 来自 forkheadRepositoryOwner ! pnpm自动添加并切换到一个以 fork owner 命名的 remote第 54-65 行Force-fetch 基础分支用前缀强制非快进更新origin/base避免过期 ref第 108-109 行并与 GitHub API 返回的 SHA 比对验证第 111-118 行Rebase 到origin/base自动解决pnpm-lock.yaml冲突通过git checkout --ours pnpm-lock.yaml配合pnpm install --lockfile-only --no-frozen-lockfile --ignore-scripts重新生成锁文件第 68-72 行的regenerate_lockfile函数其余冲突暂停等待人工打印MANUAL_RESOLUTION_NEEDED并列出需要手动解决的文件清单然后以非零码退出。如果脚本报告MANUAL_RESOLUTION_NEEDED处理方式是手动解决所列文件、用git add暂存然后续跑./.agents/skills/pull-requests/scripts/resolve-pr-conflicts.sh pr --continue--continue模式脚本第 75-100 行会再次自动处理锁文件冲突、执行GIT_EDITORtrue git rebase --continue、用--force-with-lease强推并等待约 10 秒后查询 GitHub 的mergeable状态确认。脚本设计上也体现了对分支保护与 fork 场景的适配它用--force-with-lease而非裸--force降低覆盖他人推送的风险并且能处理 fork 场景自动加 remote、换 push 目标。Rebase 之后的必做动作review-and-fix-pr明确要求rebase 后要重新读一遍 diff。原因很实际一个解决错误的冲突是真实 bug而且它出现时不会有任何 review 评论附着在上面A conflict resolved wrongly is a real bug that arrives with no review comment attached to it。另外两个与 rebase 相关的时序细节来自pull-requestsSkill把 rebase 折叠进携带修复的那次 pushrebase 会重写你的修复提交所以引用一个 rebase 之前的本地 commit hash 是不安全的——它指向一个分支永远不会收到的提交在 push 之后再回复线程强推还会把已打开的评论标记为 outdated 并移动锚点所以回复中必须带上修复 commit 的 hash评论挂靠的那一行可能已不再指向修复本身。第三步审查代码——用 review-code Skill 验证每条发现在 rebase 之后review-and-fix-pr要求调用 review-code Skill 来审查完整的变更并验证已有的审查发现然后修复其中可操作的问题actionable issues。review-codeSkill 的要点标准以 审查指南references/REVIEW_GUIDE.md为规范评审标准同时应用 AGENTS.md 以及被改动产品所涉及的说明与风格指南优先级安全security优先其次性能performance然后是产品契合度product fit、正确性与可维护性验证要求每条发现都要绑定到被改动的代码上针对当前实现与调用方验证说明具体的触发条件trigger与影响impact安全发现要指出攻击者可控的输入与利用路径性能发现要指出受影响的热路径与新增开销的证据反馈分类评估审查者反馈时区分有效发现valid findings、误报false positives以及当前 head 上已修复的问题报告按优先级输出可操作发现标注受影响的文件与行号、触发条件、影响与证据对被拒绝的反馈要解释为什么不需要改动如果无可操作问题明确说明并指出验证上的限制。REVIEW_GUIDE.md中还提到该仓库由两个自动化审查机器人覆盖——CodeRabbit配置在.coderabbit.yaml和 Qodo配置在.pr_agent.toml二者分工CodeRabbit 侧重正确性与约定Qodo 侧重安全与性能但都遵循同一套优先级。审查者的核心问题概括为一句话这个变更是否以最小的正确版本在正确的层次上解决了一个真实的 pnpm 问题并且没有不可接受的安全、性能、兼容性或维护成本第四步选择并运行测试——用 testing-changes Skill 验证修复修复代码之后需要选择覆盖这些修复的检查并运行。review-and-fix-pr要求调用 testing-changes Skill并对失败做调查和修复。testing-changes的核心思路是只运行变更所影响的测试。CI 会在每个 PR 上于三个平台运行完整套件所以本地跑测试的目的是快速反馈而不是第二道关卡。仓库同时存在两套实现栈Rust 工作区pnpm/与pnpr/通过根目录package.json脚本运行pnpm test:rust-affected、pnpm test:rust、pnpm test:rust-smoke它们包装just配方与 node 脚本并由pnpm-workspace.yaml中的任务并发组控制并发TypeScript CLIpnpm11/使用pnpm --filter package_name test ...按包、按文件、按用例粒度运行。几个会让局部运行撒谎gotchas的关键点必须通过pnpm test:rust运行 CLI 测试而不是裸cargo nextest——前者会剥离npm_config_*/pnpm_config_*并把XDG_CONFIG_HOME与 auth npmrc 指向一次性目录裸跑会让你的个人 npmrc 泄漏进测试pnpr-*crate 必须一起选择否则 feature 统一会导致其后端测试被静默跳过insta快照只应在有理由时变化先读 diff 再cargo insta review绝不盲目接受被中断的测试运行会泄漏临时树每棵树持有一个 per-test store用just sweep-test-temp清理超过一小时的遗留known_failures模块存放的是未实现行为的移植测试那里失败是预期、通过才是异常TypeScript 端到端测试运行的是打包后的pnpm11/pnpm/dist/pnpm.mjs而不是各包的lib/改动任何 TypeScript 包后必须先pnpm --filter pnpm run compile重新打包否则测试跑的是旧 bundle会通过却不接触你的改动。报告测试时也要诚实写明你跑了什么、没跑什么。Ranpnpm-lockfileplus thecataloge2e module; did not run the full workspace suite 是诚实报告而单 crate 跑过后声称Tests pass则不是。第五步安装 git hooks 并提交——Conventional Commit 与提交纪律先确认 git hooks 已安装review-and-fix-pr要求按照 AGENTS.md 的要求确保仓库的 git hooks 已安装然后用Conventional Commit 消息提交修复再推送到 PR 的 head 分支。AGENTS.md 第 172-182 行解释了 hooks 的安装机制.husky/下的 hooks 只有在 husky 把它们接进 git 之后才会生效全新克隆不会自动激活。安装方式二选一pnpm install # 安装时运行 prepare: husky 脚本 # 或者依赖已安装时单独注册 pnpm exec husky验证方法git config core.hooksPath应指向 husky 的目录且.husky/_/目录存在。绝不能带着未安装的 hooks 提交——那会静默跳过所有检查。仓库实际存在的 hooks见.husky/目录包括commit-msg、pre-commit、pre-push、prepare-commit-msg以及两个特殊的commit-msg校验脚本.husky/reject-bare-issue-refs.mjs禁止在提交消息中出现裸#NNN#后跟数字否则拒绝提交.husky/reject-bare-mentions.mjs禁止在提交消息中出现裸name后跟类用户名 token。pre-pushhook.husky/pre-push则展示了分层检查的思路它会先检测本次推送的提交是否触及pnpm/或pnpr/下的 Rust 源码只有触及时才运行昂贵的pnpm run pre-push:rust否则只做pnpm run compile-only pnpm run lint --quiet并跳过 Rust 检查——这是对只运行变更所影响的部分这一原则在 pre-push 阶段的具体实现。Conventional Commit 规范提交消息遵循 Conventional Commits 规范AGENTS.md 第 161-170 行列出的类型包括类型含义feat新功能fix缺陷修复docs仅文档变更style格式、缺失分号等refactor既不修 bug 也不加功能的代码变更perf提升性能的代码变更test补充缺失的测试chore构建流程或辅助工具的变更提交时的边界只提交与修复相关的改动保留任何无关的本地变更提交信息使用 Conventional Commit 格式不要提交裸#NNN或裸name会被commit-msghooks 拒绝。第六步跟随 CI 与审查轮次直至收尾每次 push 都是新一轮的开始review-and-fix-pr明确要求每一次 push包括 rebase 脚本的 push都会启动新一轮 CI 与审查所以要跟随pull-requestsSkill 的循环——验证新发现、提交并推送修正、在修复已上远程分支后回复并解决审查线程。pull-requestsSkill 中的After every push循环包括五个步骤等待检查gh pr checks pr --watch的阻塞时间通常超过前台命令允许的时长所以要么放后台跑要么轮询push 后立刻运行可能返回在 run 存在之前先等一下要看到最后而不是在第一个失败处停下——修复那个失败的 push 会取消仍在运行的任务没等到第二个失败意味着又要花一整轮读完整轮审查如前所述行内线程 ≠ 全部审查还要读 issue comments 与 review bodies亲自验证每条发现无论 bot 还是人的审查都有相当比例的错误发现——a fix applied to a finding you did not check is a new bug with a reviewers blessing on it。优先级/严重度徽章只是审查者的猜测不是判决。只处理站得住脚的发现每条线程都要回复注明修复它的 commit 或拒绝理由然后 resolve 它。回复必须在修复 commit 上了远程分支之后——rebase 或 amend 重写本地 commit 会让一个本地 hash 变成谁也查不到的东西。另外resolve 线程需要 GraphQLresolveReviewThreadREST 评论 API 做不到让标题和描述与代码同步任何改变 PR 行为的 push 之后都要重读并更新标题/描述gh pr edit --title、--body。这不是家务活标题会成为 squash 提交的 subject模板的 Squash Commit Body 会成为提交消息回到第 1 步。何时才算真正完成一个轮次结束的判定很严格只有当每个审查者的总结评论都点名了你的 head commit 时才算完——因为每个审查者都会注明自己审查了哪个 commit。绿勾和空评论列表本身说明不了什么一个还没开始的轮次看起来和什么都没发现的轮次一模一样。停止条件是三者同时满足每个审查者都已对 head commit 给出报告没有审查者发现任何还需要处理的问题检查全绿。对于 ready 状态的 PR只在检查变绿、审查者对当前 head 报告完毕且没有遗留动作时才收尾。对于 draft 状态的 PR保持 draft 状态在检查变绿且你自己的审查完成时收尾。收尾时的汇报义务在结束之前要发一条带签名的 GitHub PR 评论pull-requestsSkill 要求给所有 agent 撰写的内容加脚注注明 agent 名称与模型名称格式示例见 AGENTS.md 第 374-379 行内容包括实际的外部审查状态说明 draft 状态被保留、没有启动新的自动化审查轮次列出剩余工作或确认在请求范围内已无剩余如果外部前置条件阻碍了完成具体报告它总结修复了哪些问题、解决了哪些冲突、拒绝了哪些发现及原因、做了哪些验证、最终 CI 与审查状态。全程纪律失败、冲突与诚实 PR失败的检查不许想当然review-and-fix-pr继承自pull-requests的规则没有证据就不要把失败归为预先存在、flaky或无关——AGENTS.md 把这定为仓库规则而且第一直觉通常是错的。正确做法是拉取失败日志gh run view run --log-failed用testing-changesSkill 的筛选在本地复现修复根因。一个特例fork PR 的 run 可能先停在等待批准再显示为 cancelled——一个定时清扫任务会取消等待批准超过 30 分钟的工作流对应仓库中的.github/workflows/cancel-unapproved-workflows.yml。这不是测试失败run 需要被批准并重启。冲突的预判每轮循环都要检查合并状态见前文gh pr view --json mergeable,mergeStateStatus。CONFLICTING就 rebaseUNKNOWN是 push 后未算完过会儿再问BLOCKED关乎必需检查与审查而非冲突。Rebase 一律走resolve-pr-conflicts.sh脚本它会自动用锁文件级安装解决pnpm-lock.yaml冲突并在需要人工介入时停在文件清单上。轮次可能不收敛安静轮次才是停止信号pull-requestsSkill 指出轮次并不一定收敛——本轮被评论的代码大部分是上一轮让你写出来的代码。所以安静的轮次是停止的信号而不是轮次数量。只要轮次还在发现真实问题就继续推进。与其他 Skill 的协作关系一张全景图review-and-fix-pr是仓库 Agent Skills 体系中的接管者它把其余 Skill 串成一条流水线。仓库.agents/skills/目录下的完整集合包括Skill在本工作流中的角色review-and-fix-pr本流程总控接管已有 PR编排以下各步骤pull-requests提供 After every push 循环、失败处理、冲突处理、PR 描述维护与审查回复规则本 Skill 从中继承全部后半段流程review-code提供评审标准REVIEW_GUIDE.md与发现验证方法testing-changes提供 Rust/TypeScript 双栈的测试选择与运行策略resolve-pr-conflicts.shrebase 锁文件冲突自动解决 强推 合并性验证的执行脚本implement-change流程上游实现变更本流程假定变更已存在release-notes相关但独立处理发布说明triage相关但独立问题分流此外AGENTS.md 第 381-389 行对resolve-pr-conflicts.sh做了与 Skill 文档一致的用户侧说明第 359-380 行补充了 PR/Issue/评论工作的两条铁律以 draft 打开 PRCI 会跑但审查者不会所以检查和自查都发生在第一轮审查之前与推送不是任务终点。常见陷阱速查表陷阱正确做法只读行内线程漏掉总结评论里的发现同时读 issue comments 和 review bodies不验证就采纳 bot 的发现亲自复现、确认触发条件与影响后再动手rebase 前就引用本地 commit hash在 push 之后引用远程分支上的 commitrebase 后不重读 diff解决错误的冲突是无声的 bug必须复查用裸cargo nextest跑 CLI 测试通过pnpm test:rust运行避免个人 npmrc 泄漏改了 TS 包不重新打包就跑 e2e先pnpm --filter pnpm run compile提交消息含裸#NNN或name会被commit-msghooks 拒绝改用完整引用或纯文本把UNKNOWN当成无冲突push 后稍等再查询在首个失败处停止等待看到最后等待可能被下一次 push 取消的后续失败push 完就走等待机器人审查轮次到达并处理直到每个审查者都报告了 head commit总结review-and-fix-prSkill 提供了一套可重复、可验证的接管并收尾已有 PR工作流用gh读懂现状 → 用 resolve-pr-conflicts.sh rebase 到最新主干自动处理锁文件冲突→ 用 review-code 验证每条审查发现 → 用 testing-changes 选择并运行覆盖修复的测试 → 在确认 husky hooks 已安装的前提下以 Conventional Commit 提交并推送 → 跟随每一轮 CI 与审查直到检查全绿 每个审查者都报告了 head commit 且无遗留动作。它不授权合并不擅自切换 PR 的 draft/ready 状态但要求你把 PR 推进到可以被合并的状态并在收尾时留下带 agent 签名的、诚实而完整的汇报。这套流程适用于 pnpm 仓库及其镜像中任何需要接手的 PR也为其配套的 pull-requests、review-code、testing-changes 等 Skill 的实际落地提供了完整的编排示例。【免费下载链接】pnpmFast, disk space efficient package manager项目地址: https://gitcode.com/gh_mirrors/pn/pnpm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考