Back to Details

fix-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Fix PR

修复PR

Bring a GitHub pull request to a mergeable state without guessing about review feedback.
无需猜测评审反馈，即可将GitHub Pull Request调整至可合并状态。

Steps

步骤

1. Identify the PR

1. 确定目标PR

Read 
args
.
  • If 
    args
    contains a PR number, use it.
  • Otherwise, if the current conversation clearly names the working PR, use that PR.
  • Otherwise, run 
    gh pr view --json number,url,headRefName,baseRefName
    from the current repo to identify the PR for the current branch.
  • If no PR can be identified, ask the user for the PR number and stop.
Set 
auto=true
only when 
args
contains 
--auto
.
读取
args
参数。
  • 如果
    args
    中包含PR编号，则使用该编号。
  • 否则，如果当前对话明确指定了正在处理的PR，则使用该PR。
  • 若以上都不满足，从当前仓库执行
    gh pr view --json number,url,headRefName,baseRefName
    来确定当前分支对应的PR。
  • 如果无法确定PR，请询问用户提供PR编号并停止操作。
仅当
args
中包含
--auto
时，设置
auto=true
。

2. Inspect Before Editing

2. 编辑前检查

Collect the current state:
bash
gh pr view <PR> --json number,title,url,state,isDraft,mergeStateStatus,reviewDecision,headRefName,baseRefName,comments,reviews,reviewThreads,statusCheckRollup
gh pr checks <PR>
git status --short
Also inspect failing check logs with 
gh run view --log-failed
when a failing run is available.
Do not modify unrelated dirty files. If local changes directly conflict with required fixes, ask the user how to proceed.
Before editing, ensure the worktree is on the PR head branch:
  • If already on 
    headRefName
    , continue.
  • If not on 
    headRefName
    and there are unrelated local changes, ask before switching branches.
  • Otherwise check out the PR branch with the repository's normal workflow, such as 
    gh pr checkout <PR>
    .
  • Never commit or push to a branch other than the PR 
    headRefName
    .
收集当前状态：
bash
gh pr view <PR> --json number,title,url,state,isDraft,mergeStateStatus,reviewDecision,headRefName,baseRefName,comments,reviews,reviewThreads,statusCheckRollup
gh pr checks <PR>
git status --short
当存在失败的运行任务时，使用
gh run view --log-failed
检查失败检查项的日志。
请勿修改无关的未提交文件。如果本地变更与所需修复直接冲突，请询问用户如何处理。
编辑前，确保工作区处于PR的头部分支：
  • 如果已在
    headRefName
    分支上，继续操作。
  • 如果不在
    headRefName
    分支且存在无关本地变更，切换分支前需询问用户。
  • 否则按照仓库常规流程检出PR分支，例如执行
    gh pr checkout <PR>
    。
  • 绝对不要向PR的
    headRefName
    以外的分支提交或推送内容。

3. Review Comment Policy

3. 评审意见处理规则

Review comments are not automatically correct.
If there are actionable review comments and 
--auto
was NOT provided, output a table and wait for user confirmation before editing code:
CommentProposed actionReasonRisk
<file:line summary>
accept / reject / investigate
<why>
low / medium / high
If 
--auto
was provided, handle comments autonomously:
  • Apply clearly correct requested changes.
  • Investigate ambiguous suggestions before editing.
  • Do not apply technically wrong suggestions; explain why in the final report.
  • Prefer minimal fixes over broad refactors.
评审意见并非绝对正确。
如果存在可执行的评审意见且未提供
--auto
参数，需输出表格并等待用户确认后再编辑代码：
意见拟采取操作原因风险
<文件:行 摘要>
接受 / 拒绝 / 调查
<原因说明>
低 / 中 / 高
如果提供了
--auto
参数，则自主处理意见：
  • 应用明确正确的变更请求。
  • 对模糊的建议先调查再编辑。
  • 不应用技术上错误的建议；在最终报告中说明原因。
  • 优先选择最小化修复而非大范围重构。

4. Make It Mergeable

4. 调整至可合并状态

Work through blockers in this order:
  1. Requested changes and unresolved review threads.
  2. Failing required checks.
  3. Branch out of date with base.
  4. Merge conflicts.
  5. Missing local verification.
For each code or behavior fix, follow test-driven-development when feasible: reproduce the failure first, make the smallest fix, then verify it passes.
Use normal non-interactive commands. If the branch needs updating from base, first confirm you are on the PR head branch. Prefer the repository's documented merge/rebase convention. If no convention exists, prefer a non-rewriting merge from the base branch. Do not rebase, force-push, or otherwise rewrite published PR history without explicit user approval.
按以下顺序处理障碍：
  1. 变更请求和未解决的评审线程。
  2. 失败的必填检查项。
  3. 分支与基准分支不同步。
  4. 合并冲突。
  5. 缺失本地验证。
对于每个代码或行为修复，尽可能遵循测试驱动开发：先复现失败，再做最小化修复，最后验证通过。
使用常规非交互式命令。如果分支需要从基准分支更新，首先确认处于PR的头部分支。优先遵循仓库文档中规定的合并/变基约定。如果没有约定，优先使用非改写式的基准分支合并。未经用户明确批准，请勿变基、强制推送或以其他方式改写已发布的PR历史。

5. Verify and Push

5. 验证并推送

Run targeted tests or checks that cover the fixes. If the repo has an obvious full validation command and it is reasonable to run, run it too.
Before pushing, inspect:
bash
git status --short
git diff
Only commit and push when there are intentional local changes that need to be sent to the PR branch. Use the repo's commit style. If no changes are needed, skip commit/push and report the current PR state.
运行覆盖修复内容的针对性测试或检查项。如果仓库有明确的完整验证命令且执行合理，也可运行该命令。
推送前检查：
bash
git status --short
git diff
仅当存在需要推送到PR分支的有意本地变更时，才提交并推送。遵循仓库的提交风格。如果无需变更，跳过提交/推送并报告当前PR状态。

6. Re-check PR State

6. 重新检查PR状态

After pushing, re-run:
bash
gh pr checks <PR>
gh pr view <PR> --json mergeStateStatus,reviewDecision,statusCheckRollup
If checks are still pending, report that the PR is waiting on CI. If checks fail, continue investigating unless blocked by permissions, missing secrets, flaky external services, or user policy.
If 
reviewDecision
remains 
CHANGES_REQUESTED
or required threads remain unresolved after fixes, do not call the PR mergeable. Report that reviewer action is still required. If appropriate for the repo workflow, leave a concise PR comment explaining rejected review suggestions with technical reasons.
推送后重新执行：
bash
gh pr checks <PR>
gh pr view <PR> --json mergeStateStatus,reviewDecision,statusCheckRollup
如果检查项仍在等待中，报告PR正在等待CI处理。如果检查项失败，除非受权限限制、缺少密钥、外部服务不稳定或用户政策阻止，否则继续调查。
如果修复后
reviewDecision
仍为
CHANGES_REQUESTED
或必填线程未解决，请勿宣称PR可合并。报告仍需评审者操作。如果符合仓库工作流，可在PR中留下简洁评论，说明拒绝评审建议的技术原因。

Output

输出

When finished, report:
  • PR URL.
  • Fixes made.
  • Verification run and results.
  • Remaining blockers, if any.
  • Review suggestions intentionally rejected, with reasons.
完成后报告：
  • PR链接。
  • 已完成的修复内容。
  • 执行的验证及结果。
  • 剩余障碍（如有）。
  • 有意拒绝的评审建议及原因。

Common Mistakes

常见错误

  • Do not edit before presenting the review-comment table unless 
    --auto
    was passed.
  • Do not assume a review suggestion is correct.
  • Do not force-push, rebase, or rewrite PR history unless the user explicitly approves it or the repo's instructions require it.
  • Do not claim mergeable until 
    gh pr view
    and 
    gh pr checks
    confirm it, or clearly state what is still pending.
  • 除非传入
    --auto
    参数，否则在展示评审意见表格前请勿编辑代码。
  • 不要假设评审建议是正确的。
  • 除非用户明确批准或仓库要求，否则请勿强制推送、变基或改写PR历史。
  • 除非
    gh pr view
    和
    gh pr checks
    确认PR可合并，否则不要宣称其可合并；若仍有等待项需明确说明。