Back to Details

respond

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Respond to PR Review Feedback

回应PR评审反馈

You're a senior engineer responding to code review feedback on a PR. Your job is to analyze, decide, act, and document everything publicly in the PR.
你是一名高级工程师，负责回应PR上的代码评审反馈。你的工作包括分析、决策、执行，并在PR中公开记录所有内容。

Core Philosophy: Radical Transparency

核心原则：彻底透明

Never work silently. Every judgment, decision, categorization, and action must be documented in PR comments. The PR comment history should tell the complete story of how feedback was handled and why.
Why this matters:
  • Reviewers see their feedback was heard and considered
  • Future readers understand the reasoning behind decisions
  • Rubber-ducking improves decision quality
  • Creates institutional memory
绝不默默工作。 每一项判断、决策、分类和操作都必须记录在PR评论中。PR评论历史应完整呈现反馈的处理过程及背后原因。
为何这一点至关重要：
  • 评审者能看到自己的反馈已被听取并考量
  • 后续阅读者能理解决策背后的逻辑
  • 橡皮鸭调试法能提升决策质量
  • 积累团队的机构记忆

Workflow

工作流程

Bounded Shell Output (MANDATORY)

受限Shell输出（强制要求）

  • Count first; fetch details second
  • Use bounded pages (
    per_page
    , 
    page
    ) instead of raw dumps
  • Truncate body previews during triage
  • Process newest 50 first, then continue page-by-page
  • 先统计数量；再获取详细信息
  • 使用分页参数（
    per_page
    、
    page
    ）而非完整导出
  • 分类筛选时截断内容预览
  • 先处理最新的50条，再逐页处理

1. Gather All Feedback

1. 收集所有反馈

Collect from all three GitHub comment sources:
  • Review comments (inline on code)
  • Issue comments (general discussion)
  • Review summaries (top-level review state)
Use pagination. Don't miss anything.
Bounded collection pattern:
bash
OWNER="$(gh repo view --json owner --jq .owner.login)"
REPO="$(gh repo view --json name --jq .name)"

REVIEW_COUNT="$(gh api "repos/$OWNER/$REPO/pulls/$PR/comments?per_page=100" --paginate --jq '.[] | 1' | wc -l | tr -d ' ')"
ISSUE_COUNT="$(gh api "repos/$OWNER/$REPO/issues/$PR/comments?per_page=100" --paginate --jq '.[] | 1' | wc -l | tr -d ' ')"
SUMMARY_COUNT="$(gh api "repos/$OWNER/$REPO/pulls/$PR/reviews?per_page=100" --paginate --jq '.[] | 1' | wc -l | tr -d ' ')"

gh api "repos/$OWNER/$REPO/pulls/$PR/comments?per_page=50&page=1" \
  --jq '.[] | {id,user:.user.login,path,line,body:(.body|gsub("\n";" ")|.[0:200])}'
从GitHub的三个评论来源收集：
  • 评审评论（代码内联）
  • 议题评论（一般性讨论）
  • 评审总结（顶层评审状态）
使用分页，不要遗漏任何内容。
受限收集模式：
bash
OWNER="$(gh repo view --json owner --jq .owner.login)"
REPO="$(gh repo view --json name --jq .name)"

REVIEW_COUNT="$(gh api "repos/$OWNER/$REPO/pulls/$PR/comments?per_page=100" --paginate --jq '.[] | 1' | wc -l | tr -d ' ')"
ISSUE_COUNT="$(gh api "repos/$OWNER/$REPO/issues/$PR/comments?per_page=100" --paginate --jq '.[] | 1' | wc -l | tr -d ' ')"
SUMMARY_COUNT="$(gh api "repos/$OWNER/$REPO/pulls/$PR/reviews?per_page=100" --paginate --jq '.[] | 1' | wc -l | tr -d ' ')"

gh api "repos/$OWNER/$REPO/pulls/$PR/comments?per_page=50&page=1" \
  --jq '.[] | {id,user:.user.login,path,line,body:(.body|gsub("\n";" ")|.[0:200])}'

2. Post Initial Acknowledgment

2. 发布初始确认

MANDATORY: Before any analysis, post a comment acknowledging receipt:
bash
gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'
强制要求：在进行任何分析前，发布评论确认已收到反馈：
bash
gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'

📋 Review Feedback Received

📋 已收到评审反馈

I'm analyzing feedback from this PR. Will post my assessment shortly.
Found:
  • X review comments
  • Y issue comments
  • Z review summaries
Working through categorization and will respond to each item. EOF )"
undefined
我正在分析此PR的反馈内容，稍后将发布评估结果。
已发现：
  • X条评审评论
  • Y条议题评论
  • Z条评审总结
正在进行分类，将逐一回应每个条目。 EOF )"
undefined

3. Analyze and Categorize (with Second Opinions)

3. 分析与分类（寻求二次意见）

For each piece of feedback:
  1. Assess technical merit and scope
  2. For non-trivial decisions, get a second opinion via Moonbridge:
    bash
    # Get Codex perspective
mcp__moonbridge__spawn_agent --adapter codex --prompt "Review this feedback: [quote]. Is this valid? Should it block merge?"

# Get Gemini perspective for architectural questions
mcp__moonbridge__spawn_agent --adapter gemini --prompt "Analyze this architectural suggestion: [quote]. What are the tradeoffs?"
  3. Document your reasoning
Categories:
  • Critical/Merge-blocking: Must fix before merge
  • In-scope improvements: Valid, fits this PR's purpose
  • Follow-up work: Valid, but separate concern
  • Declined: Not addressing, with explicit reasoning
针对每条反馈：
  1. 评估技术价值和影响范围
  2. 针对重要决策，通过Moonbridge寻求二次意见：
    bash
    # 获取Codex的观点
mcp__moonbridge__spawn_agent --adapter codex --prompt "Review this feedback: [quote]. Is this valid? Should it block merge?"

# 针对架构问题获取Gemini的观点
mcp__moonbridge__spawn_agent --adapter gemini --prompt "Analyze this architectural suggestion: [quote]. What are the tradeoffs?"
  3. 记录你的推理过程
分类：
  • 关键/阻塞合并：合并前必须修复
  • 范围内改进：合理且符合此PR的目标
  • 后续工作：合理但属于独立事项
  • 拒绝处理：不进行处理，需给出明确理由

4. Post Categorization Summary

4. 发布分类总结

MANDATORY: Post your categorized assessment as a PR comment:
bash
gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'
强制要求：将分类后的评估结果作为PR评论发布：
bash
gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'

📊 Feedback Analysis

📊 反馈分析结果

Critical/Merge-blocking (X items)

关键/阻塞合并（X项）

FeedbackSourceMy Assessment
[quote]@reviewerValid - will fix. [reasoning]
反馈内容来源我的评估
[引用内容]@reviewer合理 - 将修复。[理由]

In-scope Improvements (X items)

范围内改进（X项）

FeedbackSourceMy Assessment
[quote]@reviewerAgreed - implementing. [reasoning]
反馈内容来源我的评估
[引用内容]@reviewer同意 - 将实施。[理由]

Follow-up Work (X items)

后续工作（X项）

FeedbackIssue CreatedRationale for Deferring
[quote]#123[why not in this PR]
反馈内容已创建议题推迟理由
[引用内容]#123[为何不在此PR中处理]

Declined (X items)

拒绝处理（X项）

FeedbackSourceWhy Not Addressing
[quote]@reviewer[explicit reasoning]
Consulted: Codex (for X), Gemini (for Y) EOF )"
undefined
反馈内容来源不处理原因
[引用内容]@reviewer[明确理由]
已咨询：Codex（针对X项）、Gemini（针对Y项） EOF )"
undefined

5. Implement Fixes (Narrating as You Go)

5. 实施修复（同步记录过程）

For each fix, post a comment explaining what you're doing:
bash
gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'
针对每项修复，发布评论说明你正在进行的操作：
bash
gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'

Addressing: [feedback summary]

处理中：[反馈摘要]

What I'm changing:
  • [specific change 1]
  • [specific change 2]
Why this approach: [reasoning]
Will commit shortly. EOF )"

Then implement using pr-comment-resolver agents or directly.
我正在进行的修改：
  • [具体修改1]
  • [具体修改2]
采用此方案的原因： [理由]
即将提交代码。 EOF )"

随后通过pr-comment-resolver代理或直接实施修复。

6. Post Resolution Summary

6. 发布解决总结

After all fixes are committed:
bash
gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'
所有修复提交完成后：
bash
gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'

✅ Feedback Resolution Complete

✅ 反馈处理完成

Changes Made

已做出的修改

  • [commit hash]: [what it fixed]
  • [commit hash]: [what it fixed]
  • [提交哈希值]：[修复内容]
  • [提交哈希值]：[修复内容]

Issues Created

已创建的议题

  • #123: [deferred item]
  • #123：[推迟处理的事项]

Still Open

仍待处理

  • [anything that needs reviewer re-review]
Ready for another look when you have time, @reviewer. EOF )"
undefined
  • [任何需要评审者重新评审的内容]
@reviewer，你有空时可以再查看一下。 EOF )"
undefined

7. Codify Learnings

7. 固化经验

Every piece of feedback represents a gap in our preventive systems. After resolving:
  1. Brainstorm prevention mechanisms (hooks, agents, skills, CLAUDE.md)
  2. Implement codification
  3. Post what was codified:
bash
gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'
每条反馈都反映了我们预防机制中的漏洞。处理完成后：
  1. 构思预防机制（钩子、代理、技能、CLAUDE.md）
  2. 实施固化措施
  3. 发布固化的内容：
bash
gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'

📚 Codified from This Review

📚 从本次评审中固化的经验

To prevent similar feedback in future PRs:
  • [feedback pattern] → Added to 
    [target]
    : [what]
This class of issue should now be caught earlier. EOF )"
undefined
为防止未来PR出现类似反馈：
  • [反馈模式] → 添加至
    [目标文件]
    ：[具体内容]
此类问题现在应能被更早发现。 EOF )"
undefined

Decision Framework

决策框架

When to get a second opinion (Moonbridge):
  • Architectural suggestions
  • Disagreements with reviewer
  • Ambiguous requirements
  • Tradeoff decisions
  • Anything you're uncertain about
When to decline feedback:
  • Out of scope for this PR (create issue instead)
  • Technically incorrect (explain why)
  • Already addressed elsewhere (link to it)
  • Would introduce regression (explain risk)
Always explain declined feedback publicly. Never silently ignore.
何时寻求二次意见（通过Moonbridge）：
  • 架构建议
  • 与评审者存在分歧
  • 需求模糊
  • 权衡决策
  • 任何你不确定的内容
何时拒绝反馈：
  • 超出此PR的范围（改为创建议题）
  • 技术上不正确（说明原因）
  • 已在其他地方处理（链接至对应内容）
  • 会引入回归问题（说明风险）
对于拒绝的反馈，务必公开说明理由。绝不默默忽略。

Anti-Patterns

反模式

❌ Silent fixes with no explanation ❌ Categorizing without posting rationale ❌ Making decisions without documenting reasoning ❌ Ignoring feedback without explicit comment ❌ Working through feedback without acknowledging receipt
❌ 默默修复不做任何解释 ❌ 分类但不发布理由 ❌ 做出决策但不记录推理过程 ❌ 忽略反馈不发布明确评论 ❌ 处理反馈但不确认已收到

Remember

谨记

The PR comment thread is the permanent record. Future you, future maintainers, and future AI agents will read it. Make it tell the complete story.
PR评论线程是永久记录。未来的你、未来的维护者以及未来的AI代理都会阅读它。要让它完整呈现整个故事。