pr-review-address-feedback

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PR Review Address Feedback Skill

PR评审反馈处理Skill

Operator Context

操作器上下文

This skill operates as an operator for PR feedback processing, configuring Claude's behavior for rigorous validation of reviewer comments before acting on them. It implements a Validate-Then-Act pattern -- fetch all feedback, verify each claim independently, summarize findings, then fix only validated issues.

该Skill作为PR反馈处理的操作器，配置Claude的行为，使其在处理评审者评论前先进行严格验证。它实现了**Validate-Then-Act（先验证后行动）**模式——拉取所有反馈，独立验证每条主张，总结发现，仅修复经过验证的问题。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终生效）

Fetch All Sources: Always query reviews, inline comments, AND issue comments -- never rely on a single endpoint
Validate Before Acting: NEVER start fixing code until every comment has been independently verified
Evidence Over Trust: Reviewer claims are treated as hypotheses, not facts -- verify with code, tests, or HTTP requests
Summary Table Required: Always present a validation summary table before making any changes
Phase Gates Enforced: Each phase must complete before the next begins -- no skipping

拉取所有来源：始终查询评审、行内评论和议题评论——绝不依赖单一接口
行动前先验证：在每条评论都完成独立验证前，绝不开始修复代码
证据优先于信任：评审者的主张被视为假设而非事实——需通过代码、测试或HTTP请求验证
必须生成总结表格：在进行任何修改前，必须呈现验证总结表格
强制阶段门控：每个阶段必须完成才能进入下一阶段——不得跳过

Default Behaviors (ON unless disabled)

默认行为（启用状态，除非手动禁用）

Auto-Detect PR Context: Infer owner/repo/PR number from current git branch and remote when not provided
Structured Validation Output: Use the validation entry format for each comment
Classify Verdicts: Every comment gets VALID, INVALID, or NEEDS-DISCUSSION
Show Verification Work: Display evidence for each verdict, not just the conclusion
Fix Only VALID Issues: Skip INVALID comments, escalate NEEDS-DISCUSSION to user

自动检测PR上下文：当未提供时，从当前git分支和远程仓库推断所有者/仓库/PR编号
结构化验证输出：对每条评论使用验证条目格式
分类裁决结果：每条评论都会被标记为VALID（有效）、INVALID（无效）或NEEDS-DISCUSSION（需讨论）
展示验证过程：为每个裁决结果提供证据，而非仅展示结论
仅修复VALID问题：跳过INVALID评论，将NEEDS-DISCUSSION问题提交给用户

Optional Behaviors (OFF unless enabled)

可选行为（禁用状态，除非手动启用）

Post Reply Comments: Reply to individual review comments on GitHub with findings
Request Re-Review: Automatically request re-review after pushing fixes
Commit Per Finding: Create separate commits for each validated fix
Diff Verification: Run
```
git diff
```
after fixes to confirm only intended changes

发布回复评论：在GitHub上针对每条评审评论回复验证结果
请求重新评审：推送修复后自动请求重新评审
按发现结果单独提交：为每个经过验证的修复创建独立的提交
差异验证：修复后运行
```
git diff
```
以确认仅发生预期变更

What This Skill CAN Do

该Skill可完成的工作

Fetch and consolidate PR feedback from all three GitHub comment sources
Independently verify each reviewer claim against the actual codebase
Classify comments as VALID, INVALID, or NEEDS-DISCUSSION with evidence
Fix validated issues after presenting the summary table
Detect reviewer claims that lack supporting evidence

从GitHub的三个评论来源拉取并整合PR反馈
对照实际代码库独立验证每条评审者主张
为每条评论分类为VALID、INVALID或NEEDS-DISCUSSION并提供证据
在呈现总结表格后修复经过验证的问题
检测缺乏支持证据的评审者主张

What This Skill CANNOT Do

该Skill无法完成的工作

Fix issues without completing the validation phase first
Trust reviewer claims without independent verification
Skip the summary table and proceed directly to fixes
Perform general code review (use systematic-code-review instead)
Create or submit new pull requests (use pr-pipeline instead)

在完成验证阶段前修复问题
不进行独立验证就信任评审者的主张
跳过总结表格直接进行修复
执行通用代码评审（请使用systematic-code-review）
创建或提交新的拉取请求（请使用pr-pipeline）

Instructions

使用说明

Usage

调用方式

/pr-review-address-feedback [owner] [repo] [pr_number]

If no arguments provided, auto-detect from current git branch and remote.

/pr-review-address-feedback [owner] [repo] [pr_number]

若未提供参数，将从当前git分支和远程仓库自动检测。

Phase 1: FETCH

阶段1：拉取（FETCH）

Goal: Retrieve all feedback from every GitHub comment source.

Use

gh

CLI (handles auth automatically):

bash

undefined

目标：从所有GitHub评论来源获取所有反馈。

使用

gh

CLI（自动处理认证）：

bash

undefined

Get PR details

获取PR详情

gh api repos/{owner}/{repo}/pulls/{pr_number}

Get formal reviews (submitted via "Review changes")

获取正式评审（通过「Review changes」提交）

gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews

Get inline code comments (added directly to specific lines)

获取行内代码评论（直接添加到特定代码行）

gh api repos/{owner}/{repo}/pulls/{pr_number}/comments

Get issue/PR comments (general conversation - where Claude typically comments)

获取议题/PR评论（通用对话——Claude通常在此评论）

gh api repos/{owner}/{repo}/issues/{pr_number}/comments


All three comment sources must be fetched and combined. Treat all feedback identically regardless of submission method:
- **Formal reviews** -- submitted via GitHub's "Review changes" button
- **Inline code comments** -- added directly to specific code lines
- **Issue/PR comments** -- general comments on the PR conversation

**Gate**: All three endpoints queried successfully, feedback consolidated into a single list. Proceed only when gate passes.

gh api repos/{owner}/{repo}/issues/{pr_number}/comments


必须拉取并整合所有三个评论来源的内容。无论提交方式如何，所有反馈都将被同等处理：
- **正式评审**——通过GitHub的「Review changes」按钮提交
- **行内代码评论**——直接添加到特定代码行
- **议题/PR评论**——PR对话中的通用评论

**门控条件**：三个接口均查询成功，反馈已整合为单一列表。仅当条件满足时才可进入下一阶段。

Phase 2: VALIDATE

阶段2：验证（VALIDATE）

Goal: Independently verify every reviewer comment before acting.

Step 1: Create a validation entry for each comment

VALIDATING: [file:line] - [brief description]

Claim: [What the reviewer claims]

Verification:
  [ ] Read actual file/line: [YES/NO]
  [ ] Tested claim: [describe test performed]
  [ ] Result: [what you found]

Verdict: [VALID | INVALID | NEEDS-DISCUSSION]
Reason: [one sentence explanation]

Step 2: Apply verification tests by comment type

Comment Type	Required Verification
"Unused import/variable"	Grep for usage in file, check if actually unused
"Security issue"	Analyze attack vector, test if exploitable
"Bug in logic"	Write test case or trace execution path
"URL is wrong/outdated"	`curl -sI [URL]` to check HTTP status
"Date is wrong"	Verify actual date, check if format matters
"Regex doesn't work"	Test regex with actual inputs
"Missing null check"	Trace where value comes from, check if can be null
"Performance issue"	Only valid if measurable; otherwise NEEDS-DISCUSSION
"Style/formatting"	Check if matches project conventions
"Off-by-one error"	Write boundary test cases

Step 3: Flag automatic INVALID patterns

Flag as likely INVALID if reviewer:

Claims code behavior without showing evidence
Says "future date" without checking if URL works
Claims unused without searching codebase
Suggests "safer" approach without demonstrating risk

Gate: Every comment has a validation entry with verdict and evidence. Proceed only when gate passes.

目标：在采取行动前独立验证每条评论。

步骤1：为每条评论创建验证条目

VALIDATING: [文件:行号] - [简要描述]

主张: [评审者的主张内容]

验证过程:
  [ ] 读取实际文件/行: [是/否]
  [ ] 测试主张: [描述执行的测试]
  [ ] 结果: [发现的内容]

裁决: [VALID | INVALID | NEEDS-DISCUSSION]
理由: [一句话解释]

步骤2：按评论类型应用验证测试

评论类型	必需的验证操作
"未使用的导入/变量"	在文件中搜索使用情况，确认是否真的未使用
"安全问题"	分析攻击向量，测试是否可被利用
"逻辑错误"	编写测试用例或追踪执行路径
"URL错误/过时"	执行 `curl -sI [URL]` 检查HTTP状态
"日期错误"	验证实际日期，检查格式是否重要
"正则表达式无效"	使用实际输入测试正则表达式
"缺少空值检查"	追踪值的来源，检查是否可能为空
"性能问题"	仅当可测量时才视为有效；否则标记为NEEDS-DISCUSSION
"风格/格式问题"	检查是否符合项目约定
"差一错误"	编写边界测试用例

步骤3：标记自动INVALID的模式

若评审者出现以下情况，标记为可能INVALID：

主张代码行为但未提供证据
声称「日期过期」但未检查URL是否可用
声称代码未使用但未搜索整个代码库
建议「更安全的」方案但未展示风险

门控条件：每条评论都有包含裁决结果和证据的验证条目。仅当条件满足时才可进入下一阶段。

Phase 3: SUMMARIZE

阶段3：总结（SUMMARIZE）

Goal: Present all findings in a summary table before any fixes.

VALIDATION SUMMARY

Total Comments: [N] (from reviews + inline + issue comments)

| # | File:Line | Claim | Verdict | Action |
|---|-----------|-------|---------|--------|
| 1 | foo.py:42 | Unused import | VALID | Fix |
| 2 | bar.js:15 | Future date | INVALID | Skip |
| 3 | baz.go:99 | Race condition | NEEDS-DISCUSSION | Ask user |

VALID: [count] - Will fix
INVALID: [count] - Will skip with reason
NEEDS-DISCUSSION: [count] - Requires user input

Gate: Summary table displayed. User has acknowledged NEEDS-DISCUSSION items (if any). Proceed only when gate passes.

目标：在进行任何修复前，以表格形式呈现所有发现。

验证总结

总评论数: [N]（来自评审 + 行内 + 议题评论）

| 序号 | 文件:行号 | 主张 | 裁决 | 操作 |
|---|-----------|-------|---------|--------|
| 1 | foo.py:42 | 未使用的导入 | VALID | 修复 |
| 2 | bar.js:15 | 日期过期 | INVALID | 跳过 |
| 3 | baz.go:99 | 竞态条件 | NEEDS-DISCUSSION | 询问用户 |

VALID: [数量] - 将修复
INVALID: [数量] - 将跳过并说明理由
NEEDS-DISCUSSION: [数量] - 需要用户输入

门控条件：已展示总结表格。用户已确认NEEDS-DISCUSSION项（如有）。仅当条件满足时才可进入下一阶段。

Phase 4: EXECUTE

阶段4：执行（EXECUTE）

Goal: Fix only VALID issues, verify each fix works.

For each validated fix:

State which validated comment is being addressed
Make the change
Verify the fix works (run tests, grep for correctness, inspect result)
Confirm no regressions from the change

Do NOT fix INVALID comments. Escalate NEEDS-DISCUSSION items to the user.

Gate: All VALID issues fixed and verified. No regressions introduced.

目标：仅修复VALID问题，验证每个修复的有效性。

对于每个经过验证的修复：

说明正在处理哪条经过验证的评论
进行修改
验证修复有效（运行测试、搜索正确性、检查结果）
确认未引入回归问题

请勿修复INVALID评论。将NEEDS-DISCUSSION问题提交给用户。

门控条件：所有VALID问题均已修复并验证，未引入回归问题。

Phase 5: LEARN

阶段5：学习（LEARN）

Goal: Extract reusable review patterns into the retro knowledge store.

After fixes are applied, reflect on what was learned:

Step 1: Identify reusable patterns

Ask:

Did we find a recurring reviewer concern that applies broadly?
Did we discover a pattern (valid or invalid) that would help in future reviews?
Did we learn something about this codebase's conventions from the reviewer feedback?
Were there common false positives that should be documented?

If nothing reusable was learned, skip recording.

Step 2: Record via retro-record-adhoc

bash

python3 ~/.claude/scripts/feature-state.py retro-record-adhoc TOPIC KEY "VALUE"

Where:

TOPIC: Match the domain of the reviewed code (e.g.,
```
go-patterns
```
,
```
python-patterns
```
,
```
code-review-patterns
```
)
KEY: Short kebab-case identifier (e.g.,
```
reviewer-false-positive-unused-reexport
```
)
VALUE: 1-2 sentence specific, actionable finding

Step 3: Report

LEARNED: [key] → [topic]
  [one-line value]

Quality gate: Only record specific, actionable findings. "Reviewers are sometimes wrong" is NOT worth recording. "Reviewers flag fmt.Errorf wrapping but the org convention is errors.New" IS worth recording.

Gate: Learning recorded (or skipped if nothing reusable). Review complete.

目标：将可复用的评审模式提取到回顾知识库中。

修复完成后，反思学到的内容：

步骤1：识别可复用模式

思考：

是否发现了适用于广泛场景的重复出现的评审关注点？
是否发现了可帮助未来评审的模式（有效或无效）？
是否从评审者反馈中学到了关于此代码库约定的内容？
是否存在应记录的常见误报？

若无可复用内容，跳过记录。

步骤2：通过retro-record-adhoc记录

bash

python3 ~/.claude/scripts/feature-state.py retro-record-adhoc TOPIC KEY "VALUE"

其中：

TOPIC：与评审代码的领域匹配（例如：
```
go-patterns
```
、
```
python-patterns
```
、
```
code-review-patterns
```
）
KEY：简短的短横线命名标识符（例如：
```
reviewer-false-positive-unused-reexport
```
）
VALUE：1-2句话的具体、可操作的发现

步骤3：报告

已学习: [key] → [topic]
  [一行描述]

质量门控：仅记录具体、可操作的发现。「评审者有时会出错」不值得记录。「评审者标记fmt.Errorf包装但团队约定使用errors.New」值得记录。

门控条件：已记录学习内容（若无可用内容则跳过）。评审完成。

Trust Hierarchy

信任层级

Verification sources in order of trust:

Running code/tests -- highest trust
HTTP requests -- verify URLs, APIs
Grep/search results -- verify usage claims
Reading source -- understand context
Reviewer's word -- lowest trust (always verify)

验证来源的信任顺序：

运行代码/测试 —— 最高信任
HTTP请求 —— 验证URL、API
Grep/搜索结果 —— 验证使用主张
阅读源代码 —— 理解上下文
评审者的陈述 —— 最低信任（始终需要验证）

Examples

示例

Example 1: Mixed Valid and Invalid Comments

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

User says: "/pr-review-address-feedback your-org your-repo 42" Actions:

Fetch all comments from reviews, inline, and issue endpoints (FETCH)
Validate each: find that "unused import" is valid, but "future date URL" works fine (VALIDATE)
Present table showing 1 VALID, 1 INVALID (SUMMARIZE)
Fix the unused import, skip the URL comment (EXECUTE) Result: Only verified issues fixed, invalid feedback documented with evidence

用户输入: "/pr-review-address-feedback your-org your-repo 42" 操作流程:

从评审、行内和议题接口拉取所有评论（拉取阶段）
验证每条评论：发现「未使用的导入」有效，但「过期URL」仍可正常访问（验证阶段）
呈现表格，显示1个VALID、1个INVALID（总结阶段）
修复未使用的导入，跳过URL相关评论（执行阶段）结果: 仅修复经过验证的问题，无效反馈附带证据被记录

Example 2: Auto-Detected PR with Discussion Items

示例2：自动检测PR并包含需讨论项

User says: "/pr-review-address-feedback" (no arguments, on feature branch) Actions:

Detect owner/repo/PR from git remote and branch, fetch all comments (FETCH)
Validate each: "race condition" claim needs reproduction attempt (VALIDATE)
Present table with NEEDS-DISCUSSION item, ask user for guidance (SUMMARIZE)
Fix validated items, skip discussion items pending user input (EXECUTE) Result: User decides on ambiguous feedback, only confirmed issues addressed

用户输入: "/pr-review-address-feedback"（无参数，当前在特性分支）操作流程:

从git远程仓库和分支检测所有者/仓库/PR，拉取所有评论（拉取阶段）
验证每条评论：「竞态条件」主张需要复现尝试（验证阶段）
呈现包含NEEDS-DISCUSSION项的表格，向用户请求指导（总结阶段）
修复经过验证的项，跳过待讨论项等待用户输入（执行阶段）结果: 用户对模糊反馈做出决策，仅处理已确认的问题

Error Handling

错误处理

Error: "gh CLI Not Authenticated"

错误："gh CLI Not Authenticated"

Cause: GitHub CLI not logged in or token expired Solution:

Run
```
gh auth status
```
to check authentication state
If not authenticated, prompt user to run
```
gh auth login
```
Verify with
```
gh api user
```
before retrying

原因: GitHub CLI未登录或令牌过期解决方案:

运行
```
gh auth status
```
检查认证状态
若未认证，提示用户运行
```
gh auth login
```
重试前通过
```
gh api user
```
验证

Error: "PR Not Found or No Access"

错误："PR Not Found or No Access"

Cause: Wrong owner/repo/PR number, or repository is private without access Solution:

Verify PR exists:

gh api repos/{owner}/{repo}/pulls/{pr_number}

Check repo visibility and token scopes
If auto-detecting, verify remote URL and current branch has an open PR

原因: 所有者/仓库/PR编号错误，或仓库为私有且无访问权限解决方案:

验证PR是否存在：

gh api repos/{owner}/{repo}/pulls/{pr_number}

检查仓库可见性和令牌权限
若为自动检测，验证远程URL和当前分支是否有打开的PR

Error: "No Comments Found on PR"

错误："No Comments Found on PR"

Cause: PR has no review feedback yet, or all comments are from bots Solution:

Confirm PR exists and is open
Check if reviews are pending (requested but not submitted)
Report "No reviewer feedback found" and exit cleanly -- do not fabricate findings

原因: PR尚无评审反馈，或所有评论来自机器人解决方案:

确认PR存在且处于打开状态
检查是否有未提交的待处理评审
报告「未找到评审者反馈」并干净退出——不得编造发现结果

Anti-Patterns

反模式

Anti-Pattern 1: Fixing Before Validating

反模式1：未验证就修复

What it looks like: Reading reviewer comments and immediately editing code Why wrong: Reviewer may be wrong. Fixing unverified claims wastes time and can introduce bugs. Do instead: Complete Phase 2 validation for every comment before touching any code.

表现：读取评审者评论后立即编辑代码危害：评审者可能出错。修复未经验证的主张会浪费时间并可能引入bug。 正确做法：完成阶段2的所有评论验证后，再触碰任何代码。

Anti-Pattern 2: Trusting Claims Without Evidence

反模式2：无证据就信任主张

What it looks like: Accepting "this import is unused" without grepping for usage Why wrong: Reviewers often miss indirect usage, re-exports, or dynamic references. Do instead: Independently verify each claim using the verification tests table.

表现：未搜索代码就接受「此导入未使用」的主张危害：评审者常遗漏间接使用、重导出或动态引用。 正确做法：使用验证测试表格独立验证每条主张。

Anti-Pattern 3: Skipping the Summary Table

反模式3：跳过总结表格

What it looks like: Validating comments one at a time and fixing each immediately Why wrong: User loses the big picture. NEEDS-DISCUSSION items may change the approach to VALID ones. Do instead: Complete all validations, present the full summary table, then proceed to fixes.

表现：逐条验证评论并立即修复危害：用户失去全局视角。NEEDS-DISCUSSION项可能改变VALID项的处理方式。 正确做法：完成所有验证，呈现完整总结表格后再进行修复。

Anti-Pattern 4: Fetching Only One Comment Source

反模式4：仅拉取单一评论来源

What it looks like: Checking only

/pulls/{pr}/reviews

and missing inline or issue comments Why wrong: Claude and other tools often comment via

/issues/{pr}/comments

, which is a separate endpoint. Missing any source means missing feedback. Do instead: Always fetch from all three endpoints: reviews, pull comments, and issue comments.

表现：仅检查

/pulls/{pr}/reviews

而遗漏行内或议题评论危害：Claude和其他工具常通过

/issues/{pr}/comments

评论，这是独立的接口。遗漏任何来源都会错过反馈。 正确做法：始终从三个接口拉取：评审、拉取请求评论和议题评论。

Anti-Pattern 5: Downgrading NEEDS-DISCUSSION to VALID

反模式5：将NEEDS-DISCUSSION降级为VALID

What it looks like: Marking ambiguous feedback as VALID to avoid asking the user Why wrong: Acting on ambiguous feedback without user input may fix the wrong thing or introduce unintended behavior. Do instead: Classify honestly. Present NEEDS-DISCUSSION items to the user for their decision.

表现：将模糊反馈标记为VALID以避免询问用户危害：在无用户输入的情况下处理模糊反馈可能修复错误内容或引入意外行为。 正确做法：如实分类。将NEEDS-DISCUSSION项提交给用户决策。

References

参考资料

This skill uses these shared patterns:

Anti-Rationalization: Code Review - Review-specific rationalization prevention
Anti-Rationalization Core - Universal anti-rationalization patterns
Gate Enforcement - Phase transition rules
Verification Checklist - Pre-completion checks

该Skill使用以下共享模式：

Anti-Rationalization: Code Review - 评审专用的反合理化模式
Anti-Rationalization Core - 通用反合理化模式
Gate Enforcement - 阶段转换规则
Verification Checklist - 完成前检查项

Domain-Specific Anti-Rationalization

领域专用反合理化

Rationalization	Why It's Wrong	Required Action
"Reviewer is probably right"	Probably is not verified	Test the claim independently
"Small comment, just fix it"	Small fixes can break things	Validate first, even for trivial claims
"Already validated similar comment"	Each comment has unique context	Validate each comment individually
"No time for the summary table"	Summary prevents premature action	Always present the table before fixes

合理化行为	危害	必需操作
"评审者可能是对的"	"可能"不等于已验证	独立测试该主张
"评论很小，直接修复"	小修复也可能破坏代码	即使是小主张也需先验证
"已验证过类似评论"	每条评论都有独特上下文	单独验证每条评论
"没时间做总结表格"	总结可防止过早行动	修复前必须呈现表格