aiskillstore 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:
- Understand the feedback
- Verify it's correct
- 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