mcpField
F
follow-up-on-pr

follow-up-on-pr

github.com/factory-ai开发117111 次安装3 天前更新
代码仓库

关于 follow-up-on-pr

Follow Up on PR 是与语言和框架无关的 Skill，用于将现有拉取请求推进到可合并状态。它指导检查变更与反馈、变基、运行本地检查、推送更新并回复审查者。

主要功能

  1. 01检查差异、评论和 CI 状态
  2. 02将分支变基到基础分支
  3. 03处理审查者反馈
  4. 04运行项目对应的本地检查
  5. 05推送变更并回复审查者

适用场景

  1. 01接手现有拉取请求
  2. 02基础分支更新后同步 PR
  3. 03合并前处理代码审查意见

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/factory-ai/factory-plugins --skill follow-up-on-pr

安装后在 Claude Code 中输入/follow-up-on-pr确认已加载。

详细介绍

跟进 PR

接手现有 PR，使其保持最新、处理所有反馈，并将其推进到可合并状态。此技能与语言和框架无关——示例中出现的构建、Lint、测试和格式化命令，请替换为项目实际使用的命令。

输入

  • PR URL 或编号（必需）：例如 https://github.com/<owner>/<repo>/pull/9996 或 #9996
  • 分支名称（可选）：如果未提供，请从 PR 元数据中提取

工作流

1. 了解 PR

通过 FetchUrl（或 gh pr view）获取 PR，以查看：

  • 文件变更（差异）
  • 审查者评论（行内评论和一般评论）
  • CI 工作流状态和日志
  • PR 描述及任何关联工单

深入阅读所有已更改文件。理解变更的意图和范围。

如果 PR 是为了解决特定问题（例如错误报告、用户报告的 Bug）：在审查代码前调查根本原因。确认修复确实解决了实际问题。有时 PR 中的问题已被其他修复解决。

2. 获取并检出分支
git fetch origin <branch-name> <base-branch>
git checkout <branch-name>

如果本地不存在该分支，git checkout 会从 origin/<branch-name> 创建一个跟踪分支。

3. 基于最新的基准分支进行变基
git pull origin <base-branch> --rebase

如果发生冲突：

  1. 阅读每个冲突文件，了解双方的修改
  2. 解决冲突，在保留 PR 意图的同时纳入基准分支的变更
  3. git add <resolved-files>
  4. git rebase --continue

如果变基没有冲突： 使用 git log --oneline -5 和 git diff --stat origin/<base-branch>..HEAD 验证状态。

4. 处理审查者评论

第 1 步已获取评论。对于每条未解决的评论：

  1. 阅读评论并理解具体要求
  2. 修改代码（或解释为何无需修改）
  3. 如有要求，添加测试
  4. 提交修复，并使用描述性提交消息

已处理的评论： 检查是否已有回复（in_reply_to_id 字段）。跳过已解决的评论。

5. 运行本地 CI 检查

针对受影响的部分，运行项目的 Lint、格式化、类型检查/编译和测试命令。阅读仓库根目录中的文件（例如 Makefile、package.json、pyproject.toml、Cargo.toml、go.mod、build.gradle、mix.exs、Gemfile、composer.json、justfile、Taskfile.yml、README.md 或 CI 工作流配置）来查找这些命令。

优先使用筛选或目标标记，将运行范围限定在受影响的部分——这比运行整个仓库更快。常见模式：

  • JS/TS monorepo：npm run test -- --filter=<workspace>、pnpm -r --filter <pkg> test、nx test <project>
  • Python：pytest <path>、tox -e <env>
  • Rust：cargo test -p <crate>、cargo clippy -p <crate>
  • Go：go test ./<pkg>/...、golangci-lint run ./<pkg>/...
  • Java/Kotlin：./gradlew :<module>:test、./mvnw -pl <module> test
  • Bazel：bazel test //path/...

如需更全面的本地命令模板，可参阅 create-pr 技能中的“CI 检查参考”部分，该部分涵盖与常见 CI 检查对应的命令。

区分既有失败与 PR 引入的问题： 有些 CI 失败存在于基准分支上，与 PR 无关。如果失败发生在 PR 未修改的文件中，请先确认基准分支上也会出现该问题，再决定是否花时间修复。常见的既有问题包括：新添加的依赖项导致模块/包解析错误。

E2E 测试： 如果 PR 更改了面向用户的行为（UI 流程、默认值、键盘操作、CLI 输出），即使代码正确，E2E 测试也可能失败。阅读失败的测试，了解其预期，然后更新测试以匹配新行为。不要想当然地认为 E2E 失败是偶发的——先阅读测试。

6. 提交并推送
git add -A
git commit -m "<type>(<scope>): <description>"

git push origin <branch-name> --force-with-lease

如果提交扫描机器人阻止推送（Droid-Shield、GitGuardian、TruffleHog 等）：这通常是因为无关的测试样例中包含了看起来像密钥的字符串。Agent 无法绕过这些检查。请告知用户手动推送，或根据组织文档暂时停用扫描器。

7. 回复审阅者评论

逐条回复 PR 中已处理的评论，让审阅者知道他们的反馈已得到处理。

针对行内审阅评论（最常见的类型）：

# Reply to a specific inline comment thread
gh api repos/<owner>/<repo>/pulls/<N>/comments/<COMMENT_ID>/replies \
  -X POST \
  -f body="<explanation of what was done>"

针对 PR 整体摘要：

gh pr comment <N> --body "<summary of all changes made>"

检查讨论串的解决状态（可选）：

gh api graphql -f query='{
  repository(owner: "<owner>", name: "<repo>") {
    pullRequest(number: <N>) {
      reviewThreads(first: 20) {
        nodes {
          isResolved
          comments(first: 3) { nodes { body author { login } } }
        }
      }
    }
  }
}'
8. 更新 PR 描述

如果后续修改较为重要（新增测试、架构调整、扩展范围），请更新 PR 描述：

gh pr edit <N> --body "<updated description>"

使用组织的 PR 模板格式。更新测试部分，以反映新增的测试。

验证

在完成任务之前，请确认：

  • 分支已基于最新的基分支进行变基
  • 所有审阅者评论都已通过代码修改处理
  • 受影响的包已通过本地 lint、类型检查／编译和测试
  • 修改已推送到远程
  • 所有审阅者评论都已回复，并说明所做的处理
  • PR 描述已更新

评论

支持 Markdown