pr-finish

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PR Finish

PR 收尾

Use this skill to finish a PR without turning review and CI into an unbounded loop. Keep

review-all

review-only; this skill owns the triage, fix, verify, push, and bounded CI workflow.

使用此技能完成PR，避免将评审和CI变成无限制循环。保持

review-all

仅用于评审；此技能负责问题分类、修复、验证、推送以及有限制的CI工作流。

Rules

规则

Do not fix review comments one at a time.
Fetch all current review state before editing: PR review bodies, inline review comments, issue comments, current head SHA, and check status.

Triage every finding as

valid

already fixed

obsolete

, or

not actionable

Apply all valid P0-P2 fixes in one batch.
Treat P3 as optional unless it violates an explicit repo convention, is very cheap and clearly useful, or the user asks to fix all nits.
Run focused tests for touched code first, then one final repo verification pass before pushing.
Push once per batch.
Run
```
review-all
```
once after the batch. If valid P0-P2 findings remain, do at most one more fix batch unless the user explicitly asks to continue.
Do not rerun
```
review-all
```
after each individual fix.
If only long e2e jobs remain pending after 10 minutes, report status and stop unless the user explicitly asked to wait for them.

不要逐个修复评审意见。
在编辑前获取所有当前评审状态：PR评审内容、行内评审评论、议题评论、当前HEAD SHA以及检查状态。
将每个问题分类为
```
valid
```
（有效）、
```
already fixed
```
（已修复）、
```
obsolete
```
（已过时）或
```
not actionable
```
（无法处理）。
批量应用所有有效的P0-P2修复。
除非违反明确的仓库约定、成本极低且明显有用，或用户要求修复所有细节问题，否则将P3视为可选修复项。
先针对修改的代码运行聚焦测试，然后在推送前运行一次完整的仓库验证。
每批修复仅推送一次。
批量修复后运行一次
```
review-all
```
。如果仍存在有效的P0-P2问题，最多再进行一批修复，除非用户明确要求继续。
不要在每次单独修复后重新运行
```
review-all
```
。
如果10分钟后仍只有长时间的e2e作业在运行，报告状态并停止，除非用户明确要求等待它们完成。

Procedure

流程

1. Resolve PR Context

1. 确定PR上下文

Find the PR for the current branch:

bash

gh pr view --json number,url,title,headRefOid,reviewDecision,statusCheckRollup

If the branch has no PR, ask for the PR number.

找到当前分支对应的PR：

bash

gh pr view --json number,url,title,headRefOid,reviewDecision,statusCheckRollup

如果分支没有对应的PR，请询问PR编号。

2. Fetch Review State

2. 获取评审状态

Fetch summary reviews, issue comments, and checks:

bash

gh pr view <pr> --json url,title,headRefOid,reviewDecision,latestReviews,reviews,comments,statusCheckRollup

Fetch inline review comments:

bash

gh api repos/<owner>/<repo>/pulls/<pr>/comments --paginate

Use

gh

for GitHub operations. If an API call fails because of sandboxed network access, rerun the same command with the required approval.

获取汇总评审、议题评论和检查结果：

bash

gh pr view <pr> --json url,title,headRefOid,reviewDecision,latestReviews,reviews,comments,statusCheckRollup

获取行内评审评论：

bash

gh api repos/<owner>/<repo>/pulls/<pr>/comments --paginate

使用

gh

执行GitHub操作。如果由于网络访问沙箱限制导致API调用失败，重新运行同一命令并申请必要权限。

3. Triage Before Editing

3. 编辑前分类问题

Create a concise triage table before making changes:

Source	File:Line	Priority	Finding	Status	Action

Classification:

```
valid
```
: Still applies to current
```
HEAD
```
and should be fixed.
```
already fixed
```
: The code/docs/tests already address it.
```
obsolete
```
: The comment points at an old commit or moved code and no longer applies.
```
not actionable
```
: The finding is wrong, speculative, or asks for behavior outside the requested scope.

Only edit after the table is complete.

在进行修改前创建简洁的分类表：

来源	文件:行号	优先级	问题	状态	操作

分类说明：

```
valid
```
：仍适用于当前
```
HEAD
```
版本，需要修复。
```
already fixed
```
：代码/文档/测试已解决该问题。
```
obsolete
```
：评论指向旧提交或已移动的代码，不再适用。
```
not actionable
```
：问题错误、具有推测性，或要求超出请求范围的行为。

完成分类表后再进行编辑。

4. Fix In One Batch

4. 批量修复

Apply all valid P0-P2 fixes together. Keep edits narrow and aligned with the repo's conventions. For P3, fix only when it is convention-backed or clearly worth the small cost.

一次性应用所有有效的P0-P2修复。保持修改范围狭窄，并符合仓库的约定。对于P3问题，仅当有约定支持或成本极低且明显值得修复时才进行处理。

5. Verify

5. 验证

Run focused checks for touched code first. Examples:

bash

go test ./internal/cli
go test ./internal/controller

Then run the repo's standard verification targets:

bash

make test
make verify

Run broader targets such as

make test-integration

only when the touched code or review findings justify it.

先针对修改的代码运行聚焦检查。示例：

bash

go test ./internal/cli
go test ./internal/controller

然后运行仓库的标准验证目标：

bash

make test
make verify

仅当修改的代码或评审问题需要时，才运行更广泛的目标，如

make test-integration

。

6. Commit And Push

6. 提交并推送

Check the diff and status:

bash

git status --short
git diff --stat
git diff --check

Commit with a scoped message and push once for the batch.

检查差异和状态：

bash

git status --short
git diff --stat
git diff --check

使用范围明确的提交信息进行提交，并为整批修复推送一次。

7. Run Review-All Once

7. 运行一次Review-All

After the push, run

review-all

once against the committed branch diff.

review-all

reports valid P0-P2 findings, do one more batched fix cycle: triage all findings, fix them together, verify, commit, push. Do not continue past that second cycle without explicit user confirmation.

If only P3 findings remain, report them as optional unless they violate a stated repo rule.

推送后，针对已提交的分支差异运行一次

review-all

。

如果

review-all

报告存在有效的P0-P2问题，再进行一轮批量修复：分类所有问题、一起修复、验证、提交、推送。若无用户明确确认，不要进行超过两轮的修复循环。

如果仅剩下P3问题，将其报告为可选修复项，除非违反明确的仓库规则。

8. Monitor CI With Bounds

8. 有限制地监控CI

Check status:

bash

gh pr checks <pr>

If a check fails, inspect that job and fix the failure. If checks are passing or only long e2e jobs remain pending, use this policy:

Wait up to 10 minutes total for pending long jobs.
If they still run after 10 minutes, report which jobs are pending and stop.
Continue waiting only if the user explicitly asked to wait for all checks.

检查状态：

bash

gh pr checks <pr>

如果检查失败，检查该作业并修复问题。如果检查通过或仅剩下长时间的e2e作业在运行，请遵循以下策略：

最多等待10分钟以处理待运行的长时间作业。
如果10分钟后作业仍在运行，报告哪些作业待处理并停止。
仅当用户明确要求等待所有检查完成时才继续等待。

Final Report

最终报告

Keep the final response short:

review findings fixed or triaged
commits pushed
local checks run
PR check status
any remaining pending long jobs or optional P3 items

保持最终回复简洁：

已修复或分类的评审问题
已推送的提交
已运行的本地检查
PR检查状态
任何仍在运行的长时间作业或可选的P3项