receiving-code-review

Evaluate code review feedback by systematically reading all comments, understanding each suggestion against your codebase, verifying technical correctness, and assessing whether it aligns with your architecture before implementing. This prevents blind fixes and ensures quality.

When feedback is unclear, follow a clarification protocol: ask reviewers specific questions about ambiguous items, confirm your understanding of technical rationale, and verify suggestions against your actual codebase before proceeding. This prevents partial understanding and incorrect implementation.

Evaluate conflicting feedback by verifying it against your architectural decisions and codebase patterns. If justified, provide technically sound pushback with specific reasons why the suggestion conflicts with existing design, or negotiate a resolution that maintains consistency.

Yes. Provide reasoned pushback when suggestions are technically incorrect or conflict with architecture. Base your response on codebase reality and documented decisions, not preference, so reviewers understand your reasoning and can agree or escalate the decision.

Before implementing feedback, test proposed changes against your target codebase to verify correctness. After implementing, run test suites to catch regressions. This systematic verification ensures feedback improves code quality rather than introducing new issues.

Use systematic evaluation when feedback is unclear, technically questionable, or potentially conflicts with architecture. This process is essential in development workflows with complex pull requests or when reviewers may not have full codebase context.