receiving-code-review

Read the complete feedback without reacting, restate each requirement in your own words, verify it against the codebase, then respond with technical acknowledgment or reasoned pushback. Implement items one at a time and test each fix individually.

Stop and ask for clarification before implementing anything. Review items are often related, so partial understanding leads to wrong implementations. Clarify all unclear items first, then proceed with the full picture.

Push back when a suggestion breaks existing functionality, violates YAGNI for unused features, is technically incorrect for your stack, or when the reviewer lacks full context. Use technical reasoning and reference working tests or code, not defensiveness.

No. External feedback is a suggestion to evaluate, not an order. Check whether it is technically correct for your codebase, breaks existing functionality, works across platforms, and whether the reviewer understands the full context before implementing.

Clarify unclear items first, then address blocking issues like breaks and security problems, followed by simple fixes like typos and imports, and finally complex changes like refactoring. Test each fix individually and verify no regressions.