Installs into .claude/skills of the current project.
Are you the author of Receiving Feedback?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/yuchi-chang-receiving-feedback)
---
name: receiving-feedback
description: Use when receiving code review comments, reviewer suggestions, or technical corrections — before implementing any of them
---
# Receiving Review Feedback
Feedback is input to evaluate, not orders to execute. Verify before implementing; technical correctness over social comfort.
## The pattern
1. Read all the feedback before reacting to any of it.
2. Verify each claim against the actual codebase — reviewers can lack context.
3. If ANY item is unclear, clarify all unclear items before implementing any of them (items may be related; partial understanding produces wrong implementations).
4. Implement in order: blocking issues → simple fixes → complex fixes. Test each one separately.
## No performative agreement
Never "You're absolutely right!" / "Great point!". Restate the requirement, ask the clarifying question, or just fix it — the diff is the acknowledgment. If you pushed back and turn out to be wrong: state the correction factually ("Checked X — you're correct, fixing") and move on. No apology spiral.
## When to push back
- The suggestion breaks existing functionality or violates platform/version constraints
- The reviewer lacks context the current code depends on
- YAGNI: asked to "implement X properly" → grep for actual usage first; if nothing calls it, propose removing it instead
- It conflicts with an architectural decision the user already made → surface the conflict, don't silently comply
Push back with evidence (code, tests, grep output), not defensiveness.
## GitHub
Reply to inline review comments in their thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level PR comment.
