| name | receiving-review |
| description | Use when processing code review feedback or PR comments — verify against the codebase before implementing, push back with reasoning when the feedback is wrong |
Receiving Code Review
Technical evaluation, not emotional performance.
Announce: "I'm using the receiving-review skill to process this feedback."
The Pattern
Read → Understand → Check EC → Verify → Evaluate → Implement
1. Read
Complete feedback without reacting.
2. Understand
Restate the requirement in your own words. If unclear, ask.
3. Check EC
Before accepting or rejecting, check for relevant context:
ec_search:
query: [topic of feedback]
type: decision
ec_search:
query: [component mentioned]
type: pattern
The current implementation might be there for a reason.
4. Verify
Check against codebase reality:
- Is this technically correct for THIS codebase?
- Does it break existing functionality?
- Is there a reason for the current implementation?
- Does EC have context explaining why it's done this way?
5. Evaluate
Is the suggestion sound? Consider:
- Does reviewer have full context?
- Does it conflict with prior architectural decisions?
- Is it YAGNI? (grep for usage first)
6. Implement @tdd
One item at a time. Test each fix (@verifying).
When to Push Back
Push back with technical reasoning if:
- Suggestion breaks existing functionality
- Reviewer lacks context (point to EC decision)
- Violates YAGNI (feature unused)
- Conflicts with architectural decisions stored in EC
- Technically incorrect for this stack
Example:
"Checked EC - we decided to use X because [rationale from decision memory]. Still want to change?"
Handling Unclear Feedback
If ANY item is unclear: Stop. Ask first.
Don't implement what you understand and ask about the rest. Items may be related.
Response Format
When feedback is correct:
"Fixed. [Brief description]"
"Good catch - [issue]. Fixed in [location]."
[Just fix it, show in code]
When pushing back:
"Checked EC - this was decided in [area]: [rationale]. Keep current impl?"
"Grepped codebase - nothing calls this. Remove (YAGNI)?"
"This conflicts with [pattern from EC]. Want to change the pattern?"
Never:
"You're absolutely right!"
"Great point!"
"Thanks for catching that!"
Actions speak. Just fix it or explain why not.
If You Pushed Back and Were Wrong
"You were right - checked [X] and it does [Y]. Fixing now."
State the correction factually. Move on.
Store Learnings
If feedback reveals something worth remembering:
ec_add:
type: learning
area: [component]
content: [What the feedback taught about this codebase]
rationale: Learned during code review
Worth storing:
- Reviewer preferences that apply broadly
- Codebase conventions you weren't aware of
- Edge cases you missed that apply elsewhere
