fix-github-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fix GitHub PR

修复GitHub PR

Overview

概述

Systematically read, evaluate, implement, and resolve all review comments AND CI test failures on a GitHub PR — one issue at a time, with tests and commits after each fix.

Core principle: Never mark a comment as resolved without verified implementation and passing specs. Never claim CI is fixed without confirmed green status.

系统地读取、评估、实施并解决GitHub PR上的所有评审意见和CI测试失败问题——逐个处理每个问题，每次修复后都进行测试并提交。

核心原则： 未经过验证的实现和通过的测试，绝不要标记评论为已解决；未确认状态为绿色通过，绝不要声称CI已修复。

The Process

执行流程

Phase 1: Setup

阶段1：准备工作

Identify the PR

If a PR number was provided, use it directly. Otherwise, detect the PR from the current branch:
bash
```
# Auto-detect PR from current branch (when no PR number is given)
gh pr view --json number,title,headRefName,baseRefName,statusCheckRollup
```
If no PR is found for the current branch, list recent open PRs and ask the user to confirm:
bash
```
gh pr list --limit 10 --json number,title,headRefName
```
Once identified, set
```
$PR_NUMBER
```
for all subsequent steps.

Get full PR details

bash

gh pr view $PR_NUMBER --json number,title,headRefName,baseRefName,statusCheckRollup

Determine where to work

Check if the current working directory is already on the PR branch:
bash
```
git branch --show-current
```
- Already on the PR branch → work here directly, no worktree needed
- On a different branch → check if a worktree exists for the PR branch:
  bash
```
git worktree list
```
  - Worktree exists → navigate to it
  - Worktree does not exist → create it:
    bash
```
git worktree add ../worktrees/<branch-name> <branch-name>
```
  Then navigate to the worktree and work exclusively there

确定PR

如果提供了PR编号，直接使用该编号。否则，从当前分支检测PR：
bash
```
# 当未提供PR编号时，从当前分支自动检测PR
gh pr view --json number,title,headRefName,baseRefName,statusCheckRollup
```
如果当前分支未找到对应的PR，列出最近的开放PR并请用户确认：
bash
```
gh pr list --limit 10 --json number,title,headRefName
```
确定PR后，为后续所有步骤设置
```
$PR_NUMBER
```
变量。

获取完整PR详情

bash

gh pr view $PR_NUMBER --json number,title,headRefName,baseRefName,statusCheckRollup

确定工作目录

检查当前工作目录是否已处于PR分支：
bash
```
git branch --show-current
```
- 已在PR分支 → 直接在此处工作，无需使用worktree
- 在其他分支 → 检查是否已为PR分支创建worktree：
  bash
```
git worktree list
```
  - 已存在worktree → 切换到该目录
  - 不存在worktree → 创建新的worktree：
    bash
```
git worktree add ../worktrees/<branch-name> <branch-name>
```
  然后切换到该worktree并仅在此目录下开展工作

Phase 2: Load All Issues to Fix

阶段2：收集所有待修复问题

Collect ALL issues in parallel before starting to fix:

在开始修复前，并行收集所有问题：

2a. Review Comments

2a. 评审意见

bash

gh api repos/:owner/:repo/pulls/$PR_NUMBER/comments \
  --jq '.[] | {id, path, line, body, user: .user.login}'

Filter for unresolved comments only. Skip already-resolved threads.

bash

gh api repos/:owner/:repo/pulls/$PR_NUMBER/comments \
  --jq '.[] | {id, path, line, body, user: .user.login}'

仅筛选未解决的评论，跳过已解决的对话。

2b. CI Test Failures

2b. CI测试失败

bash

undefined

bash

undefined

Get check runs status

获取检查运行状态

gh pr checks $PR_NUMBER

Get detailed failure logs from the failed check

从失败的检查中获取详细日志

gh run list --branch <branch-name> --limit 5 gh run view <run-id> --log-failed


Parse the output to extract:
- Which spec files failed
- Exact error messages and line numbers
- Whether failures are related to review comment fixes or pre-existing

gh run list --branch <branch-name> --limit 5 gh run view <run-id> --log-failed


解析输出内容，提取：
- 哪些测试文件失败
- 具体错误信息和行号
- 失败是否与评审意见的修复相关，或是预先存在的问题

Phase 3: Process Each Review Comment (Loop)

阶段3：处理每条评审意见（循环）

For each unresolved comment, in order:

对每条未解决的评论，按顺序执行：

3a. Evaluate

3a. 评估

Read the comment carefully
Understand what change is requested
Check the file and line referenced
Decide: implement, partially implement, or reply with justification

仔细阅读评论
理解所需的修改内容
检查评论引用的文件和行号
决定：实施修改、部分实施修改，或回复说明理由

3b. Implement

3b. 实施修改

Make the minimal change requested
Stay focused on the scope of the comment — no "while I'm here" changes
If comment is unclear or wrong, reply explaining why it won't be implemented

仅进行评论要求的最小化修改
专注于评论的范围——不要进行“顺手牵羊”式的额外修改
如果评论表述不清或存在错误，回复说明不实施的原因

3c. Update/Create Specs

3c. 更新/创建测试用例

bash

bundle exec rspec spec/path/to/changed_file_spec.rb

Create specs if the change introduces new behavior
Ensure all related specs pass before committing

bash

bundle exec rspec spec/path/to/changed_file_spec.rb

如果修改引入了新的行为，创建对应的测试用例
提交前确保所有相关测试用例通过

3d. Commit

3d. 提交修改

bash

git add <changed files>
git commit -m "fix: address PR review comment in <file>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>"

bash

git add <changed files>
git commit -m "fix: address PR review comment in <file>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>"

3e. Resolve the Comment

3e. 标记评论为已解决

bash

gh api repos/:owner/:repo/pulls/comments/$COMMENT_ID \
  --method PATCH \
  --field body="✅ Corrigido no commit <hash>"

bash

gh api repos/:owner/:repo/pulls/comments/$COMMENT_ID \
  --method PATCH \
  --field body="✅ Corrigido no commit <hash>"

Phase 4: Fix CI Test Failures (Loop)

阶段4：修复CI测试失败（循环）

For each failing spec from Phase 2b, in order:

对阶段2b中每个失败的测试用例，按顺序执行：

4a. Reproduce Locally

4a. 本地复现

bash

bundle exec rspec spec/path/to/failing_spec.rb

If it passes locally but failed in CI → use

superpowers:systematic-debugging

to investigate.

bash

bundle exec rspec spec/path/to/failing_spec.rb

如果本地测试通过但CI中失败 → 使用

superpowers:systematic-debugging

进行排查。

4b. Diagnose Root Cause

4b. 诊断根本原因

Read the full error message
Check if failure is caused by a review comment fix from Phase 3
Check if it's a pre-existing or environment-related failure

阅读完整的错误信息
检查失败是否由阶段3中修复评审意见的修改导致
检查是否是预先存在的问题或环境相关的失败

4c. Fix and Verify

4c. 修复并验证

Implement the minimal fix

Run the spec again to confirm it passes:

bash

bundle exec rspec spec/path/to/failing_spec.rb

实施最小化修复

再次运行测试用例以确认通过：

bash

bundle exec rspec spec/path/to/failing_spec.rb

4d. Commit

4d. 提交修改

bash

git add <changed files>
git commit -m "fix: corrigir spec falhando no CI em <file>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>"

bash

git add <changed files>
git commit -m "fix: corrigir spec falhando no CI em <file>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>"

Phase 5: Final Verification and Push

阶段5：最终验证与推送

Run all specs for all modified files (not the full suite):

bash

# Find all changed files and their specs
git diff main...HEAD --name-only | grep -v _spec | while read f; do
  spec="spec/${f#app/}"
  spec="${spec%.rb}_spec.rb"
  [ -f "$spec" ] && echo "$spec"
done

bundle exec rspec <list of spec files>

Push the branch
bash
```
git push origin <branch-name>
```
Monitor CI (optional, if time allows)
bash
```
gh pr checks $PR_NUMBER --watch
```

Add a summary comment on the PR

bash

gh pr comment $PR_NUMBER --body "## Revisão Concluída

**Comentários de revisão endereçados:**
- <list each resolved comment>

**Falhas de CI corrigidas:**
- <list each fixed spec>

Specs dos arquivos modificados estão passando localmente."

运行所有修改文件的测试用例（而非完整测试套件）：

bash

# 找出所有修改的文件及其对应的测试用例
git diff main...HEAD --name-only | grep -v _spec | while read f; do
  spec="spec/${f#app/}"
  spec="${spec%.rb}_spec.rb"
  [ -f "$spec" ] && echo "$spec"
done

bundle exec rspec <list of spec files>

推送分支
bash
```
git push origin <branch-name>
```
监控CI（可选，若时间允许）
bash
```
gh pr checks $PR_NUMBER --watch
```

在PR上添加总结评论

bash

gh pr comment $PR_NUMBER --body "## Revisão Concluída

**Comentários de revisão endereçados:**
- <list each resolved comment>

**Falhas de CI corrigidas:**
- <list each fixed spec>

Specs dos arquivos modificados estão passando localmente."

Quick Reference

快速参考

Phase	Action	Success Criteria
1. Setup	Get PR info + worktree	Correct worktree active
2. Load issues	Comments + CI failures	Full list collected
3. Review comments	Evaluate → implement → spec → commit → resolve	Comment marked resolved
4. CI failures	Reproduce → diagnose → fix → spec → commit	Spec passes locally
5. Final	Run all related specs + push + summary	PR updated, no red specs

阶段	操作	成功标准
1. 准备工作	获取PR信息 + 配置worktree	激活正确的worktree
2. 收集问题	评审意见 + CI失败	收集完整问题列表
3. 处理评审意见	评估 → 实施 → 测试 → 提交 → 标记解决	评论标记为已解决
4. 修复CI失败	复现 → 诊断 → 修复 → 测试 → 提交	本地测试用例通过
5. 最终步骤	运行所有相关测试 + 推送 + 总结	PR已更新，无失败测试

Red Flags — STOP and Reassess

危险信号 — 停止并重新评估

Marking a comment resolved WITHOUT a commit
Running the full test suite (only run related specs)
Making changes outside the scope of the comment
Skipping spec creation for new behavior
Claiming CI is fixed without running the spec locally
Pushing without verifying specs pass

STOP. Follow the process.

未提交修改就标记评论为已解决
运行完整测试套件（仅运行相关文件的测试用例）
进行超出评论范围的修改
为新行为跳过测试用例创建
未在本地运行测试就声称CI已修复
未验证测试通过就推送修改

停止操作，遵循流程执行。

Common Rationalizations

常见自我合理化借口

Excuse	Reality
"Comment is trivial, no test needed"	Every behavior change needs a test.
"I'll run all specs at the end"	Run per-file specs after EACH change.
"I'll resolve comments in batch"	Resolve after EACH commit, not after all.
"This change is obvious, skip the worktree"	Use a worktree only when NOT already on the PR branch. Never switch local branches.
"The comment is wrong, I'll ignore it"	Reply explaining why — never silently skip.
"CI failure is flaky, I'll ignore it"	Reproduce locally first, then decide.
"Spec passes locally, CI must be wrong"	Investigate environment differences — don't assume.

借口	实际情况
"评论内容无关紧要，无需测试"	任何行为变更都需要测试。
"我会在最后运行所有测试"	每次修改后都要运行对应文件的测试。
"我会批量标记评论为已解决"	每次提交后就标记对应评论为已解决，而非全部完成后再标记。
"这个修改很明显，跳过worktree"	仅当未处于PR分支时才使用worktree。绝不要切换本地分支。
"这条评论是错的，我忽略它"	回复说明原因——绝不要默默跳过。
"CI失败是偶发的，我忽略它"	先在本地复现，再做决定。
"本地测试通过，CI肯定有问题"	排查环境差异——不要主观臆断。

Notes for Kobana Project

Kobana项目专属说明

Never push to main — always use the worktree branch
Brazilian Portuguese for commit summaries and PR comments
Only run specs for modified files — not the entire suite
Worktrees live in
```
../worktrees/<branch-name>
```
relative to the main repo
Use
```
gh
```
CLI for all GitHub operations
For flaky CI failures, use
```
superpowers:systematic-debugging
```

绝不要推送到main分支 — 始终使用worktree分支
提交摘要和PR评论使用巴西葡萄牙语
仅运行修改文件的测试用例 — 而非整个测试套件
Worktree位于主仓库相对路径
```
../worktrees/<branch-name>
```
下
所有GitHub操作使用
```
gh
```
CLI
对于偶发CI失败，使用
```
superpowers:systematic-debugging
```
排查