charlieviettq Receiving code review
Mindset
- Reviewers surface risk you may have missed; treat feedback as input, not orders.
- Verify technical claims before changing code (read code, run tests).
Workflow
- Read fully — understand intent, not only the literal suggestion.
- Clarify — if feedback is vague, ask one focused question before partial implementation.
- Verify — reproduce issue or confirm the concern in code; do not assume the reviewer is correct.
- Prioritize — correctness and security before style.
- Respond — agree + fix, or disagree with evidence (snippet, test, spec).
- Batch related fixes; avoid drive-by changes outside review scope.
- Confirm — run verification before marking threads resolved.
When to push back
- Suggestion breaks API contract without migration plan.
- Fix is out of PR scope (offer follow-up issue).
- Reviewer assumption is wrong (show counter-evidence).
When to accept quickly
- Naming/clarity that matches project conventions.
- Missing tests for changed behavior.
- Security or data-handling gaps.
Anti-patterns
- Defensive replies without technical substance.
- Blindly applying every suggestion without understanding.
- Scope creep disguised as "while we're here".
- Implementing every comment without verifying technical accuracy.
Related
requesting-code-review, github-comment-triage, verify-before-done
Review handling patterns inspired by obra/superpowers (MIT).