aiskillstore/flow-receiving-review

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