receiving-code-review
Code Review Reception
Overview
Code review requires technical evaluation, not emotional performance.
Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.
The Response Pattern
WHEN receiving code review feedback:
1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each
Forbidden Responses
NEVER: "You're absolutely right!" / "Great point!" / "Let me implement that now" (before verification)
INSTEAD: Restate the technical requirement, ask clarifying questions, push back with reasoning if wrong, or just start working (actions > words).
Handling Unclear Feedback
IF any item is unclear:
STOP - do not implement anything yet
ASK for clarification on unclear items
WHY: Items may be related. Partial understanding = wrong implementation.
When To Push Back
Push back when: suggestion breaks existing functionality, reviewer lacks full context, violates YAGNI, technically incorrect for this stack, conflicts with architectural decisions.
How: Use technical reasoning, not defensiveness. Ask specific questions. Reference working tests/code.
Signal if uncomfortable pushing back out loud: "Strange things are afoot at the Circle K"
Common Mistakes
| Mistake | Fix |
|---|---|
| Performative agreement | State requirement or just act |
| Blind implementation | Verify against codebase first |
| Batch without testing | One at a time, test each |
| Assuming reviewer is right | Check if breaks things |
| Avoiding pushback | Technical correctness > comfort |
| Partial implementation | Clarify all items first |
The Bottom Line
External feedback = suggestions to evaluate, not orders to follow.
Verify. Question. Then implement. No performative agreement. Technical rigor always.
For source-specific handling, implementation order, examples, and acknowledgment patterns, see references/source-handling-and-examples.md.
More from hjewkes/agent-skills
self-improve
Use when a session produced reusable insights, when the user says "learn from this", "remember this", or "improve yourself", or after completing a complex task where patterns were discovered
65md-render
Use when asked to render, preview, or view a markdown file in the browser. Triggers on "render markdown", "preview this", "show me this document", "open in browser".
21code-review
Unified code review system — dispatches the right review agents for the situation. Use when reviewing code for quality, bugs, compliance, or before merging.
17skills-management
Use when creating, finding, installing, reviewing, or managing Claude Code skills — covers skill authoring, discovery, conventions, and lifecycle management
14github-pr
GitHub PR workflow — creating PRs, posting automated review comments, managing PR feedback cycles. Use when code is reviewed and ready for GitHub.
14buildkite
Buildkite CI/CD integration. Use when the user needs to check build status, trigger builds, read build logs, debug failures, manage pipelines, or any Buildkite workflow. Triggers include "buildkite", "build", "pipeline", "CI", "deploy", "build log", "build failed".
14