receiving-code-review
starsforks
How to install receiving-code-review?
heymegabyte/claude-skills/receiving-code-review
$npx -y skills add heymegabyte/claude-skills --skill receiving-code-reviewUse 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
SKILL.md
| 1 | # Receiving Code Review |
| 2 | |
| 3 | Feedback is suggestions to evaluate, not orders to follow. **Verify before implementing, ask before assuming** — technical correctness over social comfort. Verify against the codebase the same way `[[verification-loop]]` gates deploys: evidence before action. |
| 4 | |
| 5 | ## Response pattern |
| 6 | |
| 7 | 1. Read the full feedback without reacting. |
| 8 | 2. Restate each item in your own words — or ask if unclear. |
| 9 | 3. Verify against codebase reality; evaluate if it's sound for THIS stack. |
| 10 | 4. Acknowledge technically, or push back with reasoning. |
| 11 | 5. Implement one item at a time, testing each. |
| 12 | |
| 13 | ## No performative agreement |
| 14 | |
| 15 | - Never "You're absolutely right!" / "Great point!" / "Thanks for catching that!" — any gratitude or praise. |
| 16 | - Never "Let me implement that" before verifying. |
| 17 | - Instead: restate the requirement, ask, push back, or just start working. The code shows you heard it. |
| 18 | - Catch yourself typing "Thanks" or "You're right" → delete it, state the fix. |
| 19 | |
| 20 | ## Unclear feedback → stop |
| 21 | |
| 22 | - If ANY item is unclear, implement NOTHING yet — items may be related; partial understanding ships the wrong fix. |
| 23 | - Ask only about the unclear ones: "Understand 1,2,3,6. Need clarification on 4 and 5 before proceeding." |
| 24 | |
| 25 | ## Source-specific |
| 26 | |
| 27 | - **From your partner** — trusted; implement after understanding, ask if scope unclear, skip to action. |
| 28 | - **From external reviewers** — skeptical but careful. Before implementing, check: correct for THIS codebase? breaks existing behavior? reason the current code exists? works on all target platforms/versions? does the reviewer have full context? |
| 29 | - Can't verify → say so: "Can't verify without [X]. Investigate, ask, or proceed?" |
| 30 | - Conflicts with a prior architectural decision → stop and discuss with your partner first. |
| 31 | |
| 32 | ## YAGNI check |
| 33 | |
| 34 | - Reviewer says "implement it properly" → grep for real usage first. |
| 35 | - Unused → "Nothing calls this endpoint. Remove it (YAGNI)?" Used → implement properly. |
| 36 | |
| 37 | ## Implementation order |
| 38 | |
| 39 | 1. Clarify everything unclear first. |
| 40 | 2. Then: blocking (breaks/security) → simple (typos/imports) → complex (refactor/logic). |
| 41 | 3. Test each fix individually; verify no regressions. |
| 42 | |
| 43 | ## Push back when |
| 44 | |
| 45 | - Suggestion breaks existing functionality, violates YAGNI, is wrong for this stack, ignores legacy/compat reasons, lacks full context, or conflicts with a partner architectural call. |
| 46 | - How: technical reasoning not defensiveness; cite working tests/code; ask specific questions; escalate to partner if architectural. |
| 47 | - Uncomfortable pushing back? Name the tension and raise the issue anyway — honesty is the value. |
| 48 | |
| 49 | ## Acknowledging |
| 50 | |
| 51 | - Correct feedback → "Fixed. [what changed]" or "Good catch — [issue]. Fixed in [location]." No thanks. |
| 52 | - You pushed back and were wrong → "You were right — checked [X], it does [Y]. Fixing." No apology, no over-explaining. |
| 53 | |
| 54 | ## GitHub threads |
| 55 | |
| 56 | Reply inline in the comment thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level PR comment. |
| 57 | |
| 58 | **Verify. Question. Then implement.** |
| 59 | |
| 60 | ## Rationalizations — stop, these are wrong |
| 61 | |
| 62 | | Excuse | Reality | |
| 63 | |---|---| |
| 64 | | "Reviewer is more senior" | Senior reviewers make mistakes. Verify technically. | |
| 65 | | "I'll just apply it and move on" | Blind agreement ships bugs the reviewer didn't catch. | |
| 66 | | "The feedback is obviously right" | Obvious things are often wrong. Open the code. | |
| 67 | | "Pushing back is rude" | Shipping bad code is rude. Push back with evidence. | |
| 68 | |
| 69 | **Red Flags — STOP and re-read the code yourself:** agreeing without opening a file · "they probably checked" · gratitude instead of verification · applying feedback you don't understand. |
| 70 | |
| 71 | <!-- budget: ~63 --> |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
