Back to Details

pr-fix

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PR Fix Skill

PR Fix Skill

Operator Context

操作者上下文

This skill operates as an operator for PR comment resolution workflows, configuring Claude's behavior for validated, evidence-based fixes. It implements the Validate-Before-Fix architectural pattern -- verify each comment's claim against actual code, then apply targeted fixes with a single clean commit.
该Skill作为PR评论解决工作流的操作者，配置Claude的行为以实现基于验证和证据的修复。它采用先验证后修复的架构模式——针对每条评论的主张与实际代码进行核对，然后通过一个清晰的提交应用针对性修复。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终适用）

  • CLAUDE.md Compliance: Read and follow repository CLAUDE.md before making any changes
  • Validate Every Comment: NEVER blindly fix a comment without verifying its claim against actual code
  • Show Plan First: NEVER apply fixes without presenting the fix plan and getting confirmation
  • Single Commit: All fixes go into one commit with descriptive message referencing the PR
  • No Scope Creep: Fix only what reviewers asked for. No "while I'm here" improvements
  • Branch Safety: Never commit directly to main/master; work on the PR's branch
  • CLAUDE.md 合规性：在进行任何更改前，阅读并遵循仓库中的CLAUDE.md文件
  • 验证每条评论：绝不在未与实际代码核对的情况下盲目修复评论
  • 先展示规划：绝不在未呈现修复规划并获得确认的情况下应用修复
  • 单次提交：所有修复合并到一个提交中，提交信息需关联该PR并具备描述性
  • 不扩大范围：仅修复评审者提出的问题，禁止“顺带”进行其他改进
  • 分支安全：绝不直接提交到main/master分支；仅在PR对应的分支上工作

Default Behaviors (ON unless disabled)

默认行为（默认开启，可关闭）

  • Comment Classification: Categorize each comment as VALID, INVALID, or NEEDS-DISCUSSION
  • Before/After Display: Show code diff for each fix before committing
  • Skip Invalid Comments: Report invalid comments with explanation instead of fixing
  • Push After Commit: Push changes to update the PR after committing
  • Final Report: Display summary of fixed, skipped, and pending items
  • 评论分类：将每条评论归类为VALID（有效）、INVALID（无效）或NEEDS-DISCUSSION（需讨论）
  • 前后对比展示：提交前展示每个修复的代码差异
  • 跳过无效评论：报告无效评论并说明原因，而非修复
  • 提交后推送：提交后推送更改以更新PR
  • 最终报告：展示已修复、已跳过和待处理项的汇总

Optional Behaviors (OFF unless enabled)

可选行为（默认关闭，可开启）

  • Reply to Comments: Post resolution replies on fixed comment threads via 
    gh api
  • Resolve Threads: Mark fixed comment threads as resolved
  • NEEDS-DISCUSSION Auto-Reply: Draft reply templates for ambiguous comments
  • 回复评论：通过
    gh api
    在已修复的评论线程中发布解决回复
  • 标记线程为已解决：将已修复的评论线程标记为已解决
  • NEEDS-DISCUSSION 自动回复：为模糊评论生成回复模板

What This Skill CAN Do

该Skill可实现的功能

  • Fetch and validate PR review comments against actual code
  • Distinguish valid feedback from incorrect claims
  • Apply targeted fixes for validated comments only
  • Commit and push all fixes in a single clean commit
  • Report what was fixed, skipped, or needs discussion
  • 获取PR评审评论并与实际代码进行验证
  • 区分有效反馈与错误主张
  • 仅对已验证的评论应用针对性修复
  • 将所有修复合并为一个清晰的提交并推送
  • 报告已修复、已跳过或需讨论的内容

What This Skill CANNOT Do

该Skill不可实现的功能

  • Fix comments without first validating them against the codebase
  • Apply fixes without showing the plan and getting confirmation
  • Create PRs (use pr-pipeline instead)
  • Review code for new issues (use /pr-review instead)
  • Make unrelated improvements beyond what reviewers requested
  • 未与代码库验证就修复评论
  • 未展示规划并获得确认就应用修复
  • 创建PR（请使用pr-pipeline）
  • 评审代码以发现新问题（请使用/pr-review）
  • 进行超出评审者要求的无关改进

Instructions

操作步骤

Phase 1: IDENTIFY PR

阶段1：识别PR

Goal: Determine which PR to work on.
If no PR number is provided as argument:
bash
gh pr view --json number,title,headRefName --jq '{number, title, headRefName}'
If no PR is found for the current branch, inform the user and stop.
Verify the current branch matches the PR's head branch. If not, ask the user before proceeding.
Gate: PR identified with number, title, and correct branch checked out.
目标：确定要处理的PR。
如果未提供PR编号作为参数：
bash
gh pr view --json number,title,headRefName --jq '{number, title, headRefName}'
如果当前分支未关联任何PR，告知用户并终止流程。
验证当前分支是否与PR的源分支匹配。若不匹配，需先询问用户再继续。
准入条件：已识别PR的编号、标题，且已切换到正确的分支。

Phase 2: FETCH & VALIDATE

阶段2：获取与验证

Goal: Retrieve all review comments and validate each claim against actual code.
Step 1: Fetch comments
bash
undefined
目标：获取所有评审评论，并针对每条评论的主张与实际代码进行验证。
步骤1：获取评论
bash
undefined

Get review comments (inline comments on code)

获取评审评论（代码上的行内评论）

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

Get review-level comments

获取评审级评论

gh api repos/{owner}/{repo}/pulls/{number}/reviews
--jq '.[] | select(.body != "") | {id, body, state, user: .user.login}'

**Step 2: Validate each comment**

For EACH comment:
1. Read the actual file and line referenced
2. Test the reviewer's claim (does the issue actually exist?)
3. Classify:
   - **VALID**: Claim verified, fix needed
   - **INVALID**: Claim does not match actual code state
   - **NEEDS-DISCUSSION**: Subjective or design-level feedback

**Gate**: Every comment classified with evidence. Proceed only when gate passes.
gh api repos/{owner}/{repo}/pulls/{number}/reviews
--jq '.[] | select(.body != "") | {id, body, state, user: .user.login}'

**步骤2：验证每条评论**

针对**每条**评论：
1. 读取评论引用的实际文件和行
2. 验证评审者的主张（问题是否确实存在？）
3. 分类：
   - **VALID（有效）**：主张已验证，需要修复
   - **INVALID（无效）**：主张与实际代码状态不符
   - **NEEDS-DISCUSSION（需讨论）**：主观或设计层面的反馈

**准入条件**：所有评论已完成分类并附验证依据。仅当满足条件时才可继续。

Phase 3: SHOW FIX PLAN

阶段3：展示修复规划

Goal: Present the plan and get user confirmation before making changes.
Display a structured plan:
PR #{number}: "{title}"

Comments to address: {N} VALID, {N} INVALID, {N} NEEDS-DISCUSSION

Will fix:
  1. [VALID] src/auth.go:42 - "Add nil check for user"
  2. [VALID] src/utils.go:15 - "Remove unused import"

Will skip:
  3. [INVALID] src/api.go:99 - "URL is outdated" (verified: URL returns 200)

Needs discussion:
  4. [DISCUSS] src/db.go:55 - "Consider using transaction"

Proceed with fixes?
Gate: User confirms the plan. Proceed only when gate passes.
目标：在进行更改前呈现修复规划并获得用户确认。
展示结构化的规划：
PR #{number}: "{title}"

需处理的评论：{N}条有效，{N}条无效，{N}条需讨论

将修复：
  1. [VALID] src/auth.go:42 - "为user添加空值检查"
  2. [VALID] src/utils.go:15 - "移除未使用的导入"

将跳过：
  3. [INVALID] src/api.go:99 - "URL已过时"（验证：URL返回200状态码）

需讨论：
  4. [DISCUSS] src/db.go:55 - "考虑使用事务"

是否继续修复？
准入条件：用户确认修复规划。仅当满足条件时才可继续。

Phase 4: APPLY FIXES

阶段4：应用修复

Goal: Apply each validated fix, showing before/after for each change.
For each VALID comment:
  1. Read the file at the referenced location
  2. Apply the minimal fix that addresses the comment
  3. Show the before/after diff
  4. Verify the fix compiles or passes basic checks
For NEEDS-DISCUSSION items the user chose to address, apply the same process.
Gate: All approved fixes applied. Code still compiles/passes basic checks.
目标：应用每个已验证的修复，并展示每项更改的前后对比。
针对每条VALID评论：
  1. 读取引用位置的文件
  2. 应用解决评论问题的最小化修复
  3. 展示修复的前后差异
  4. 验证修复后的代码可编译或通过基础检查
针对用户选择处理的NEEDS-DISCUSSION项，遵循相同流程。
准入条件：所有已批准的修复已应用，代码仍可编译/通过基础检查。

Phase 5: COMMIT & PUSH

阶段5：提交与推送

Goal: Create a single clean commit and push to update the PR.
bash
undefined
目标：创建一个清晰的提交并推送以更新PR。
bash
undefined

Stage changed files (list specific files, not -A)

暂存更改的文件（列出具体文件，而非使用-A）

git add {file1} {file2} ...
git add {file1} {file2} ...

Commit with descriptive message

提交并附上描述性信息

git commit -m "Address PR review comments
  • {fix description 1}
  • {fix description 2}
  • {fix description 3}
Resolves review comments on PR #{number}"
git commit -m "处理PR评审评论
  • {修复描述1}
  • {修复描述2}
  • {修复描述3}
解决PR #{number}的评审评论"

Push to update PR

推送以更新PR

git push
undefined
git push
undefined

Phase 6: FINAL REPORT

阶段6：最终报告

Goal: Summarize what was done.
PR FIX COMPLETE

Fixed: {N} issues
Skipped: {N} (invalid)
Pending: {N} (needs discussion)

Commit: {hash} "Address PR review comments"
Pushed to: origin/{branch}

PR: https://github.com/{owner}/{repo}/pull/{number}

Remaining:
  - Discuss {topic} in {file}:{line} with reviewer
目标：总结已完成的工作。
PR修复完成

已修复：{N}个问题
已跳过：{N}个（无效）
待处理：{N}个（需讨论）

提交记录：{hash} "处理PR评审评论"
已推送至：origin/{branch}

PR地址：https://github.com/{owner}/{repo}/pull/{number}

剩余事项：
  - 与评审者讨论{file}:{line}处的{topic}

Examples

示例

Example 1: Mixed Valid and Invalid Comments

示例1：有效与无效评论混合

User says: "/pr-fix 42" Actions:
  1. Fetch 5 review comments on PR #42 (IDENTIFY, FETCH)
  2. Validate: 3 VALID, 1 INVALID (import IS used on line 45), 1 NEEDS-DISCUSSION (VALIDATE)
  3. Show plan, user confirms 3 fixes (PLAN)
  4. Apply fixes, show before/after for each (FIX)
  5. Single commit, push (COMMIT) Result: 3 fixes committed, 1 invalid explained, 1 pending discussion
用户指令："/pr-fix 42" 操作：
  1. 获取PR #42的5条评审评论（识别、获取）
  2. 验证：3条有效，1条无效（第45行确实使用了该导入），1条需讨论（验证）
  3. 展示规划，用户确认修复3个问题（规划）
  4. 应用修复，展示每项的前后对比（修复）
  5. 单次提交并推送（提交） 结果：3个修复已提交，1个无效问题已说明，1个待讨论

Example 2: All Comments Invalid

示例2：所有评论均无效

User says: "/pr-fix" Actions:
  1. Detect PR for current branch, fetch 3 comments (IDENTIFY, FETCH)
  2. Validate all 3: each claim does not match current code state (VALIDATE)
  3. Report: no changes needed, explain why each is invalid (REPORT) Result: No changes made, user informed with evidence
用户指令："/pr-fix" 操作：
  1. 检测当前分支对应的PR，获取3条评论（识别、获取）
  2. 验证所有3条：每条主张均与当前代码状态不符（验证）
  3. 报告：无需更改，说明每条评论无效的原因（报告） 结果：未进行任何更改，已向用户提供验证依据

Error Handling

错误处理

Error: "No PR Found for Current Branch"

错误："当前分支未关联PR"

Cause: Branch has no open PR, or 
gh
not authenticated Solution:
  1. Verify 
    gh auth status
    succeeds
  2. Check if a PR exists: 
    gh pr list --head {branch}
  3. If no PR, suggest creating one first
原因：分支未关联开放的PR，或
gh
未认证 解决方案：
  1. 验证
    gh auth status
    是否成功
  2. 检查是否存在PR：
    gh pr list --head {branch}
  3. 若无PR，建议先创建PR

Error: "Comment References Deleted or Moved Code"

错误："评论引用的代码已删除或移动"

Cause: Code was refactored since the review, line numbers no longer match Solution:
  1. Search for the referenced code pattern in the current file
  2. If found at a different location, apply fix there
  3. If code was removed entirely, mark comment as stale and skip
原因：评审后代码已重构，行号不再匹配 解决方案：
  1. 在当前文件中搜索引用的代码模式
  2. 若在其他位置找到，在该位置应用修复
  3. 若代码已完全删除，标记评论为过时并跳过

Error: "Fix Causes Test Failures"

错误："修复导致测试失败"

Cause: Reviewer's suggestion introduces a regression, or other tests depend on old behavior Solution:
  1. Run tests to identify which fail
  2. Evaluate whether tests need updating or fix needs adjustment
  3. If reviewer's suggestion is wrong, classify as NEEDS-DISCUSSION
  4. Document the test failure evidence
原因：评审者的建议引入了回归问题，或其他测试依赖旧行为 解决方案：
  1. 运行测试以确定哪些测试失败
  2. 评估是否需要更新测试或调整修复方案
  3. 若评审者的建议有误，归类为NEEDS-DISCUSSION
  4. 记录测试失败的证据

Anti-Patterns

反模式

Anti-Pattern 1: Blindly Applying All Comments

反模式1：盲目应用所有评论

What it looks like: Fixing every comment without checking if claims are accurate Why wrong: Reviewers make mistakes. Invalid fixes introduce bugs. Do instead: Validate every claim against actual code before fixing.
表现：不验证主张是否准确就修复每条评论 危害：评审者也会出错，无效修复会引入bug 正确做法：修复前必须针对实际代码验证每条主张

Anti-Pattern 2: Fixing Beyond What Was Asked

反模式2：修复超出要求的内容

What it looks like: "While fixing this nil check, I also refactored the whole function" Why wrong: Scope creep makes the PR harder to review again and may introduce new issues. Do instead: Fix exactly what the reviewer requested. Nothing more.
表现："在修复这个空值检查的同时，我还重构了整个函数" 危害：范围扩大会使PR的二次评审更困难，可能引入新问题 正确做法：仅修复评审者明确提出的问题，不做额外更改

Anti-Pattern 3: Separate Commits Per Comment

反模式3：每条评论对应一个提交

What it looks like: Creating 5 commits for 5 review comments Why wrong: Clutters git history. Makes it harder for reviewer to see what changed. Do instead: Single commit with all fixes, descriptive message listing each change.
表现：为5条评审评论创建5个提交 危害：混乱Git历史，使评审者难以查看更改内容 正确做法：将所有修复合并为一个提交，提交信息列出每项更改

Anti-Pattern 4: Skipping the Plan Step

反模式4：跳过规划步骤

What it looks like: Immediately applying fixes without showing what will change Why wrong: User loses control. May fix things they disagree with. Do instead: Always show the fix plan and wait for confirmation.
表现：不展示将进行的更改就直接应用修复 危害：用户失去控制权，可能修复他们不同意的内容 正确做法：始终先展示修复规划并等待用户确认

References

参考资料

This skill uses these shared patterns:
  • Anti-Rationalization - Prevents shortcut rationalizations
  • Verification Checklist - Pre-completion checks
该Skill使用以下共享模式：
  • 反合理化 - 防止走捷径的合理化行为
  • 验证检查清单 - 完成前的检查

Domain-Specific Anti-Rationalization

领域特定反合理化

RationalizationWhy It's WrongRequired Action
"Reviewer must be right, just fix it"Reviewers make mistakes tooValidate claim against code
"Small comment, no need to verify"Small mistakes cause real bugsValidate every comment
"I'll fix extra things while I'm here"Scope creep derails PR reviewsFix only what was requested
"One commit per fix is cleaner"Multiple small commits clutter historySingle commit for all fixes
合理化借口错误原因要求操作
"评审者肯定是对的，直接修复就行"评审者也会犯错针对代码验证主张
"评论很小，不需要验证"小错误也会导致真实bug验证每条评论
"我顺便修复其他问题"范围扩大会偏离PR评审的目标仅修复要求的内容
"每个修复对应一个提交更清晰"多个小提交会混乱历史所有修复合并为一个提交