mcpField
P
pr-finish

pr-finish

github.com/gjkim42开发01.1k 次安装7 周前更新
代码仓库

关于 pr-finish

用于在限定的审查、修复、验证和 CI 周期内完成 PR 的技能。它指导开发者汇总分类审查意见、批量修复，并按规则结束后续检查。

主要功能

  1. 01获取完整 PR 审查与检查状态
  2. 02编辑前分类所有发现
  3. 03批量修复有效的 P0–P2 问题
  4. 04运行针对性与最终验证
  5. 05限制复审和 CI 跟进周期

适用场景

  1. 01分类 PR 中的审查意见
  2. 02一次批量处理多项审查修复
  3. 03验证并推送一批修复
  4. 04长时间 CI 超过限制后停止等待

安装

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

$npx skills add https://github.com/gjkim42/kanon-repo --skill pr-finish

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

详细介绍

完成 PR

使用此技能完成 PR，避免让评审和 CI 陷入无休止的循环。保持 review-all 仅用于评审；此技能负责分类、修复、验证、推送和有界的 CI 工作流。

规则

  • 不要逐条修复评审评论。
  • 编辑前获取所有当前评审状态：PR 评审正文、行内评审评论、议题评论、当前 head SHA 和检查状态。
  • 将每条发现分类为 valid、already fixed、obsolete 或 not actionable。
  • 一次性批量应用所有有效的 P0-P2 修复。
  • P3 视为可选项，除非它违反了明确的仓库规范、修复成本很低且明显有用，或用户要求修复所有小问题。
  • 先对改动代码运行有针对性的测试，然后在推送前运行一次最终仓库验证。
  • 每批只推送一次。
  • 批次完成后运行一次 review-all。如果仍有有效的 P0-P2 发现，最多再进行一轮修复，除非用户明确要求继续。
  • 不要在每次单独修复后重新运行 review-all。
  • 如果 10 分钟后只剩耗时较长的端到端任务仍在等待，报告状态并停止，除非用户明确要求等待。

流程

1. 确定 PR 上下文

查找当前分支对应的 PR：

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

如果此分支没有 PR，请询问 PR 编号。

2. 获取评审状态

获取评审摘要、议题评论和检查状态：

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

获取行内评审评论：

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

使用 gh 执行 GitHub 操作。如果 API 调用因沙盒网络访问而失败，请在获得所需授权后重试相同的命令。

3. 编辑前分类

进行更改前，先创建一张简洁的分类表：

来源文件:行号优先级发现状态操作

分类说明：

  • valid：仍适用于当前 HEAD，应予以修复。
  • already fixed：代码、文档或测试已解决此问题。
  • obsolete：评论针对的是旧提交或已移动的代码，不再适用。
  • not actionable：发现有误、属于推测，或要求实现超出所请求范围的行为。

完成表格后再进行编辑。

4. 一次性批量修复

一次性应用所有有效的 P0-P2 修复。改动应尽量精简，并符合仓库规范。对于 P3，仅在有规范依据或明显值得花费少量成本时进行修复。

5. 验证

先对改动代码运行有针对性的检查。示例：

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

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

make test
make verify

仅在改动代码或评审发现确有必要时，才运行 make test-integration 等更广泛的目标。

6. 提交并推送

检查差异和状态：

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

使用范围明确的提交消息，并为此批次推送一次。

7. 仅运行一次 Review-All

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

如果 review-all 报告了有效的 P0-P2 发现，再进行一轮批量修复：对所有发现进行分类，一并修复，验证、提交并推送。未经用户明确确认，不要继续进行第二轮之后的修复。

如果只剩 P3 发现，将其报告为可选项，除非它们违反了明确说明的仓库规则。

8. 有限度地监控 CI

检查状态：

gh pr checks <pr>

如果检查失败，请检查对应任务并修复问题。如果检查通过，或只剩耗时较长的端到端任务仍在等待，请遵循以下策略：

  • 等待待处理的长任务，总时长最多 10 分钟。
  • 如果 10 分钟后任务仍在运行，报告待处理的任务并停止。
  • 只有用户明确要求等待所有检查时才继续等待。

最终报告

最终回复应简短：

  • 已修复或分类的评审发现
  • 已推送的提交
  • 已运行的本地检查
  • PR 检查状态
  • 仍在等待的长任务或可选的 P3 项

评论

支持 Markdown