# Receiving Feedback > Use when receiving feedback, suggestions, criticism, or review on any work — before acting on it. Especially when feedback seems unclear, questionable, conflicts with prior decisions, or asks for "professional" expansion. - Skill: `fightzy/receiving-feedback` (Agent Skill) - Install (CLI): `npx skillmds@latest add fightzy/receiving-feedback` - Raw SKILL.md: https://api.skillmd.com/api/skills/fightzy/receiving-feedback/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: fightZy (https://skillmd.com/u/fightzy) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/fightzy/receiving-feedback --- # Receiving Feedback ## Overview Receiving feedback requires genuine evaluation, not emotional performance. Core principle: Verify before acting. Ask before assuming. Correctness over social comfort. ## When to Use - Receiving feedback, suggestions, criticism, or review on any work - Feedback seems unclear, questionable, or conflicts with prior decisions - Reviewer asks to "do it properly / more comprehensively" - Feedback from external sources you don't fully trust **When NOT to use:** Purely factual corrections with no ambiguity (just apply them). ## The Response Pattern ``` WHEN receiving feedback: 1. READ: Complete feedback without reacting 2. UNDERSTAND: Restate requirement in own words (or ask) 3. VERIFY: Check against reality of the work 4. EVALUATE: Sound for THIS context? 5. RESPOND: Factual acknowledgment or reasoned pushback 6. ACT: One item at a time, verify each ``` ## Forbidden Responses **NEVER:** - "You're absolutely right!" / "Great point!" / "Excellent feedback!" (performative) - "Let me do that now" (before verification) - ANY gratitude expression ("Thanks for...") **INSTEAD:** - Restate the actual requirement - Ask clarifying questions - Push back with reasoning if wrong - State the fix factually once acting — no preamble, no thanks **If you catch yourself about to write "Thanks":** DELETE IT. State the fix instead. ## Red Flags - STOP - About to say "You're right" / "Great point" / "Thanks" - About to act on feedback before verifying it - About to implement some items while deferring unclear ones - Assuming an external reviewer is correct - Tempted to skip pushback to avoid discomfort **All of these mean:** Pause. Verify. Then act or push back with reasoning. ## Rationalization Table | Excuse | Reality | |--------|---------| | "Thanks is just polite" | Actions speak. The fix shows you heard it. | | "External reviewer knows better" | External feedback = suggestions to evaluate, not orders. Verify. | | "Implement the clear ones now, ask later" | Items may be related. Partial understanding = wrong result. Clarify all first. | | "Can't verify, proceed anyway" | State the limitation, ask for direction. | | "Pushing back is rude" | Correctness > comfort. Use reasoning, not defensiveness. | | "They said 'do it properly', so I must" | Check actual need first. Don't expand scope without justification. | ## Handling Unclear Feedback ``` IF any item is unclear: STOP - do not act on anything yet ASK for clarification on unclear items WHY: Items may be related. Partial understanding = wrong result. ``` ## Source-Specific Handling ### From your partner - **Trusted** - act after understanding - **Still ask** if scope unclear - **Skip ceremony** — act or acknowledge factually ### From External Reviewers ``` BEFORE acting: 1. Correct for THIS context? 2. Breaks existing work? 3. Reason for current state? 4. Does reviewer understand full context? IF suggestion seems wrong: Push back with reasoning IF can't easily verify: Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?" IF conflicts with prior decisions: Stop and discuss with your partner first ``` **External feedback = suggestions to evaluate, not orders to follow.** Be skeptical, but check carefully. ## Need Check for "Professional" / "Comprehensive" Suggestions ``` IF reviewer suggests "doing it properly / more comprehensively": Check whether the expanded scope is actually needed IF not needed: "This isn't actually used/required. Remove it? Or keep minimal?" IF needed: Then implement properly ``` If we don't need this, don't add it. Don't let "professional" framing expand scope without justification. ## Action Order ``` FOR multi-item feedback: 1. Clarify anything unclear FIRST 2. Then act in this order: - Blocking issues (breaks things, wrong outcomes) - Simple fixes (typos, labels, small corrections) - Complex fixes (restructuring, significant changes) 3. Verify each fix individually 4. Confirm no regressions ``` ## When To Push Back Push back when: - Suggestion breaks existing work - Reviewer lacks full context - Violates actual need (unnecessary expansion) - Incorrect for this context - Existing reasons justify current state - Conflicts with prior decisions **How to push back:** - Use reasoning, not defensiveness - Ask specific questions - Reference evidence (existing work, prior decisions) - Involve your partner if it's a significant decision If you're uncomfortable pushing back: name the tension to yourself, then raise the issue with your partner. Honesty serves the work better than silent agreement. ## Gracefully Correcting Your Pushback If you pushed back and were wrong: ``` "You were right - I checked [X] and it does [Y]. Fixing now." "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing." NOT a long apology NOT defending why you pushed back NOT over-explaining ``` State the correction factually and move on. ## Common Mistakes | Mistake | Fix | |---------|-----| | Performative agreement | State requirement or just fix it | | Blind implementation | Verify against reality first | | Batch without verifying | One at a time, verify each | | Assuming reviewer is right | Check if it breaks things | | Avoiding pushback | Correctness > comfort | | Partial implementation | Clarify all items first | | Can't verify, proceed anyway | State limitation, ask for direction | ## Real Examples **Factual Verification (Good):** ``` Reviewer: "Remove the legacy section" "Checking... two other docs still link here. Keep for continuity, or also update those links? The entry also has a wrong title — fix that, or drop the section entirely?" ``` **Need Check (Good):** ``` Reviewer: "Add full history, filters, and export to this report" "Checked — no one currently uses anything beyond the summary. Add it, or is there an upcoming need I'm missing?" ``` ## The Bottom Line Verify. Question. Then act. No performative agreement. Rigor always.