receiving-code-reviewlisted

Evaluate incoming review feedback technically before acting on it: read all items, restate or ask about anything unclear before implementing any of them, verify each suggestion against the actual codebase, push back with evidence when a suggestion is wrong for this code, and skip performative agreement entirely. Use when processing review comments from a human or an automated reviewer, when feedback seems technically questionable or context-blind, when a reviewer proposes 'implementing properly' something nothing calls (grep usage first, propose removal), or when a reply is about to start with 'you're absolutely right'. Order of work: clarify everything, then blocking issues, simple fixes, complex fixes — testing each individually; a pushback that turns out wrong gets a one-line factual correction, not an apology. Not for performing a review of someone else's change (/code-review or review-panel) and not for triaging accumulated feedback reports into a backlog (feedback-triage).
grimaldost/craft-collection · ★ 2 · Code & Development · score 68

Install: claude install-skill grimaldost/craft-collection

# Receiving Code Review Review reception is technical evaluation, not emotional performance. This is a **flexible** skill with two firm rules: nothing is implemented while any item is still unclear, and agreement is expressed by acting, not by performing enthusiasm. ## The response pattern 1. **Read** the complete feedback without reacting to it. 2. **Understand** — restate each requirement in your own words, or ask. 3. **Verify** each suggestion against the actual codebase, not against how plausible it sounds. 4. **Evaluate**: technically sound for this codebase, this stack, this platform support matrix? 5. **Respond** with a technical acknowledgment or a reasoned pushback. 6. **Implement** one item at a time, testing each before the next. ## Why not "you're absolutely right" Performative agreement carries no information — it doesn't show the requirement was understood, and it reads as reflexive deference rather than evaluation. When feedback is correct, the strong response is the fix and a factual note of what changed: "Good catch — the loop was N+1; fixed in repo.ts." When it's wrong, the strong response is evidence. Gratitude phrases substitute for both. ## Unclear items block everything Feedback items are often related; implementing the understood subset bakes in a wrong reading of the rest. With six items and two unclear, the move is: "Items 1, 2, 3, 6 are clear. Before I start, two questions on 4 and 5" — not implementing four and circling back. ## Source