Loading...
Loading...
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
npx skill4agent add zixun-github/aisdlc spec-receiving-code-reviewWhen receiving code review feedback:
1. Read: Read the feedback fully, don't rush to react
2. Understand: Paraphrase the requirements in your own words (or ask for clarification)
3. Verify: Check against the actual state of the codebase
4. Evaluate: Is this technically sound for the codebase?
5. Respond: Technical confirmation or justified objection
6. Implement: Implement item by item, test item by itemIf any item is unclear:
Stop - don't implement anything for now
Ask for clarification on the unclear items
Reason: Items may be related. Partial understanding = incorrect implementation.Collaborator: "Fix 1–6"
You understand 1, 2, 3, 6. 4, 5 are unclear.
❌ Wrong: Implement 1,2,3,6 now, ask about 4,5 later
✅ Correct: "I understand 1, 2, 3, 6. I need clarification on 4 and 5 before proceeding."Before implementing:
1. Check: Is this technically correct for the codebase?
2. Check: Will this break existing functionality?
3. Check: What's the reasoning for the current implementation?
4. Check: Will this work across all platforms/versions?
5. Check: Does the reviewer understand the full context?
If the suggestion seems wrong:
Object with technical reasoning
If verification is difficult:
State honestly: "I can't verify without [X]. Should I [investigate/ask/proceed]?"
If conflicting with prior collaborator decisions:
Stop first and discuss with the collaboratorIf the reviewer suggests "proper implementation":
Grep the codebase to find actual usage
If unused: "This interface is not being called. Should we remove it (YAGNI)?"
If used: Implement properlyFor multi-item feedback:
1. First clarify all unclear items
2. Then implement in this order:
- Blocking issues (breaks, security)
- Simple fixes (spelling, imports)
- Complex fixes (refactoring, logic)
3. Test each fix item by item
4. Verify no regressions✅ "Fixed. [Brief description of change]"
✅ "Good catch - [specific issue]. Fixed at [location]."
✅ [Directly fix and show in code]
❌ "You're absolutely right!"
❌ "Good point!"
❌ "Thanks for pointing that out!"
❌ "Thanks for [anything]"
❌ Any expression of gratitude✅ "You're right - I checked [X], and indeed [Y]. Implementing now."
✅ "Verified, you're correct. I initially misunderstood because [reason]. Fixing now."
❌ Long apologies
❌ Explaining why you objected
❌ Over-explaining| Mistake | Fix |
|---|---|
| Performative agreement | State requirements or take direct action |
| Blind implementation | Verify against codebase first |
| Batch implementation without testing | Item by item, test each item |
| Assuming reviewer is right | Check for breaks |
| Avoiding objection | Technical correctness > comfort |
| Partial implementation | Clarify all items first |
| Proceeding without verification | State limitations, ask for direction |