Back to Details

follow-up-on-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Follow Up on PR

跟进PR

Take over an existing PR, bring it up to date, address all feedback, and push it to a merge-ready state. This skill is language- and framework-agnostic — substitute your project's actual build, lint, test, and format commands where examples are shown.
接管现有PR，使其保持最新状态，处理所有反馈，并将其推进至可合并状态。此技能与语言和框架无关——在示例所示位置替换为项目实际的构建、代码检查、测试和格式化命令即可。

Inputs

输入项

  • PR URL or number (required): e.g. 
    https://github.com/<owner>/<repo>/pull/9996
    or 
    #9996
  • Branch name (optional): If not provided, extract from PR metadata
  • PR链接或编号（必填）：例如 
    https://github.com/<owner>/<repo>/pull/9996
    或 
    #9996
  • 分支名称（可选）：如果未提供，将从PR元数据中提取

Workflow

工作流程

1. Study the PR

1. 研究PR

Fetch the PR via 
FetchUrl
(or 
gh pr view
) to get:
  • File changes (diffs)
  • Reviewer comments (inline and general)
  • CI workflow status and logs
  • PR description and any linked ticket
Read all changed files in depth. Understand the intent and scope of the change.
If the PR fixes a specific issue (e.g. error report, user-reported bug): investigate the root cause before reviewing the code. Confirm the fix addresses the actual problem. PRs are sometimes already superseded by other fixes.
通过
FetchUrl
（或
gh pr view
）获取PR信息，包括：
  • 文件变更（差异）
  • 评审意见（行内和整体）
  • CI工作流状态和日志
  • PR描述及任何关联工单
深入阅读所有变更文件，理解变更的意图和范围。
如果PR修复了特定问题（如错误报告、用户反馈的bug）：在评审代码前先调查根本原因。确认修复方案解决了实际问题。有时PR可能已被其他修复方案取代。

2. Fetch and Check Out the Branch

2. 获取并切换到分支

bash
git fetch origin <branch-name> <base-branch>
git checkout <branch-name>
If the branch doesn't exist locally, 
git checkout
will create a tracking branch from 
origin/<branch-name>
.
bash
git fetch origin <branch-name> <base-branch>
git checkout <branch-name>
如果本地不存在该分支，
git checkout
会从
origin/<branch-name>
创建一个跟踪分支。

3. Rebase on Latest Base Branch

3. 基于最新基准分支变基

bash
git pull origin <base-branch> --rebase
If conflicts occur:
  1. Read each conflicted file to understand both sides
  2. Resolve conflicts, preserving the PR's intent while incorporating base-branch changes
  3. git add <resolved-files>
  4. git rebase --continue
If rebase is clean: Verify the state with 
git log --oneline -5
and 
git diff --stat origin/<base-branch>..HEAD
.
bash
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. Address Reviewer Comments

4. 处理评审意见

Review comments were already fetched in step 1. For each unresolved comment:
  1. Read the comment and understand what's being asked
  2. Make the code change (or explain why it's not needed)
  3. Add tests if requested
  4. Commit the fix with a descriptive message
Already-addressed comments: Check if a reply already exists (
in_reply_to_id
field). Skip comments that have been resolved.
评审意见已在步骤1中获取。对于每个未解决的意见：
  1. 阅读意见，理解要求
  2. 进行代码修改（或解释为何无需修改）
  3. 如要求则添加测试
  4. 用描述性信息提交修复
已处理的意见： 检查是否已有回复（
in_reply_to_id
字段）。跳过已解决的意见。

5. Run Local CI Checks

5. 运行本地CI检查

Run the project's lint, format, typecheck/compile, and test commands for the affected areas. Discover them by reading the repo root (e.g. 
Makefile
, 
package.json
, 
pyproject.toml
, 
Cargo.toml
, 
go.mod
, 
build.gradle
, 
mix.exs
, 
Gemfile
, 
composer.json
, 
justfile
, 
Taskfile.yml
, 
README.md
, or the CI workflow config).
Prefer filter / target flags to scope runs to the affected areas — it is faster than running the whole repo. Common patterns:
  • JS/TS monorepos: 
    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/...
See the 
create-pr
skill's "CI Checks Reference" section for a broader template of local commands matching common CI checks.
Distinguishing pre-existing failures from PR issues: Some CI failures exist on the base branch and are unrelated to the PR. If a failure occurs in a file not touched by the PR, verify it exists on the base branch too before spending time fixing it. Common pre-existing issues include module / package resolution errors for recently-added dependencies.
E2E tests: If the PR changes user-facing behavior (UI flow, defaults, keyboard handling, CLI output), E2E tests may break even if the code is correct. Read the failing test to understand what it expects, then update it to match the new behavior. Don't assume E2E failures are flaky — read them first.
针对受影响的区域运行项目的代码检查、格式化、类型检查/编译和测试命令。可通过读取仓库根目录的文件（如
Makefile
、
package.json
、
pyproject.toml
、
Cargo.toml
、
go.mod
、
build.gradle
、
mix.exs
、
Gemfile
、
composer.json
、
justfile
、
Taskfile.yml
、
README.md
或CI工作流配置文件）找到这些命令。
优先使用过滤/目标标志来限定运行范围到受影响区域——这比运行整个仓库更快。常见模式：
  • JS/TS monorepos: 
    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. Commit and Push

6. 提交并推送

bash
git add -A
git commit -m "<type>(<scope>): <description>"

git push origin <branch-name> --force-with-lease
If a commit-scanning bot blocks the push (Droid-Shield, GitGuardian, TruffleHog, etc.): This happens when unrelated test fixtures contain strings that look like secrets. The agent cannot override these. Tell the user to push manually or temporarily disable the scanner per your org's docs.
bash
git add -A
git commit -m "<type>(<scope>): <description>"

git push origin <branch-name> --force-with-lease
如果提交扫描机器人阻止推送（如Droid-Shield、GitGuardian、TruffleHog等）：这通常是因为无关的测试包含了看起来像密钥的字符串。Agent无法覆盖这些限制。告知用户手动推送，或根据组织文档暂时禁用扫描器。

7. Reply to Reviewer Comments

7. 回复评审意见

Reply to each addressed comment on the PR so reviewers know their feedback was handled.
For inline review comments (the most common type):
bash
undefined
在PR上回复每个已处理的意见，让评审者知道他们的反馈已得到处理。
对于行内评审意见（最常见类型）：
bash
undefined

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>"

**For general PR-level summary:**
```bash
gh pr comment <N> --body "<summary of all changes made>"
To check thread resolution status (optional):
graphql
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 } } }
        }
      }
    }
  }
}'
gh api repos/<owner>/<repo>/pulls/<N>/comments/<COMMENT_ID>/replies
-X POST
-f body="<说明已执行的操作>"

**对于PR级别的总结：**
```bash
gh pr comment <N> --body="<所有变更的总结>"
检查线程解决状态（可选）：
graphql
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. Update PR Description

8. 更新PR描述

If the changes made during follow-up are significant (new tests, architectural changes, additional scope), update the PR description:
bash
gh pr edit <N> --body "<updated description>"
Use your org's PR template format. Update the testing section to reflect the additional tests added.
如果跟进过程中做出的变更较为重大（如新测试、架构变更、额外范围），更新PR描述：
bash
gh pr edit <N> --body="<更新后的描述>"
使用组织的PR模板格式。更新测试部分以反映添加的额外测试。

Verification

验证

Before considering the task complete, confirm:
  • Branch is rebased on the latest base branch
  • All reviewer comments are addressed with code changes
  • Local lint, typecheck/compile, and tests pass for affected packages
  • Changes are pushed to remote
  • All reviewer comments have replies explaining what was done
  • PR description is up to date
在任务完成前，确认以下事项：
  • 分支已基于最新基准分支变基
  • 所有评审意见均已通过代码变更处理
  • 受影响包的本地代码检查、类型检查/编译和测试均已通过
  • 变更已推送到远程仓库
  • 所有评审意见均有回复说明已执行的操作
  • PR描述已更新