Answer Questions Before Code
REVIEW-ANSWER-QUESTIONS-BEFORE-CODE
Summary
Answer reviewer questions before or alongside the code changes that address them. This keeps intent, tradeoffs, and unresolved choices visible instead of burying the reasoning in a new patch.
Rule
Answer reviewer questions instead of only pushing new code.
Why
Review is a discussion about correctness, maintainability, and intent. A code push can fix the immediate diff while leaving the reviewer unsure whether the question was understood, whether an alternative was considered, or whether the remaining behavior is deliberate. That uncertainty often causes another round of review even when the code is now acceptable.
Answering the question makes the decision visible. Sometimes the answer is "changed as suggested." Sometimes it is a short explanation of why another approach was chosen. Either way, future readers can see the reasoning instead of inferring it from a later diff.
Helps
- Reduces repeated review rounds caused by unanswered concerns.
- Preserves design reasoning that would otherwise disappear into a patch update.
Limits
Do not turn every small nit into a long thread. For obvious mechanical fixes, a short acknowledgement or the code change itself can be enough. Use explicit answers when the reviewer asked about intent, tradeoffs, risk, behavior, API shape, or alternatives.
Agent Instruction
Answer reviewer questions before or with code updates so intent, tradeoffs, and remaining choices
are visible instead of buried in a new patch.Mechanisms
Supported by reply comments, review packets, PR description updates, inline follow-up notes, decision links, and handoffs that separate what changed from what was intentionally left unchanged.