Flow Receiving Review - 处理代码审查反馈

The Iron Law

VERIFY FEEDBACK BEFORE IMPLEMENTING - DON'T BLINDLY AGREE

Overview

When receiving code review feedback, maintain technical rigor. Reviewers can be wrong. Your job is to:

1. Understand the feedback
2. Verify it's correct
3. Then implement (or push back)

The Process

Step 1: Understand the Feedback

For each comment:
  1. Read completely - don't skim
  2. Identify the concern:
     - Is it a bug?
     - Is it a style preference?
     - Is it a performance issue?
     - Is it a security concern?
  3. If unclear → ASK for clarification
     - "Could you elaborate on why X is problematic?"
     - "What specific scenario does this address?"

Step 2: Verify the Feedback

Before implementing ANY change:
  1. Is the feedback technically correct?
     - Does the suggested change actually fix the issue?
     - Could it introduce new problems?

  2. Does it align with project standards?
     - Check Constitution
     - Check existing patterns

  3. Is there evidence?
     - Can you reproduce the issue?
     - Does the suggested fix work?

If feedback seems wrong:
  → Don't silently disagree
  → Don't blindly implement
  → Respond with your analysis

Step 3: Respond Appropriately

If feedback is correct:
  → Acknowledge: "Good catch, fixing now"
  → Implement the fix
  → Verify the fix works

If feedback is unclear:
  → Ask: "Could you clarify what you mean by X?"
  → Don't guess the intent

If feedback seems incorrect:
  → Explain your reasoning
  → Provide evidence
  → "I considered X, but Y because Z. What do you think?"

If feedback is a preference (not a bug):
  → Discuss trade-offs
  → Defer to project standards if they exist

Rationalization Prevention

Excuse	Reality
"Reviewer knows better"	Reviewers make mistakes. Verify.
"Just do what they say"	Blind compliance = poor code.
"Don't want to argue"	Technical discussion ≠ argument.
"It's faster to just change it"	Wrong changes waste more time.
"They'll reject if I push back"	Good reviewers appreciate rigor.

Red Flags - STOP

If you find yourself:

• Implementing changes you don't understand
• Agreeing with feedback you think is wrong
• Not asking clarifying questions
• Making changes without verifying they work

STOP. Understand first. Verify second. Implement third.

Response Templates

Agreeing with Feedback

Good catch! You're right that [issue]. I've updated [file] to [fix].
Verified by running [test/command].

Asking for Clarification

I want to make sure I understand correctly. Are you suggesting [interpretation]?
If so, I'm wondering about [concern]. Could you elaborate?

Respectfully Disagreeing

I considered [suggestion], but I went with [current approach] because:
1. [Reason 1]
2. [Reason 2]

The trade-off is [X]. What do you think about [alternative]?

Requesting Evidence

I'm having trouble reproducing [issue]. Could you share:
- Steps to reproduce
- Expected vs actual behavior
- Environment details

Integration with flow-review

This skill is used in

/flow-review

when processing reviewer feedback:

After receiving review:
  1. Load this skill
  2. Process each comment using the 3-step process
  3. Respond appropriately
  4. Track changes in EXECUTION_LOG.md

Cross-Reference

• flow-review.md - Two-stage review command
• spec-reviewer.md - Spec compliance agent
• code-quality-reviewer.md - Quality review agent

---

[PROTOCOL]: 变更时更新此头部，然后检查 CLAUDE.md