horizon67 Responding to Review Feedback
Verify review feedback against the relevant code, requirements, tests, or design decisions before acting on it. Preserve the connection between each comment and its disposition; related comments may share one fix.
Decide how to respond
Inspect the relevant code and surrounding impact, then classify each item as one of the following:
Will address: The feedback is valid and a change can resolve the problem.Will not address: The feedback is factually incorrect, conflicts with established requirements, or would cause more harm than benefit. State the concrete evidence.Needs clarification: Required information about behavior, requirements, or scope is missing. State exactly what needs clarification.
Use these dispositions to make decisions clear, without requiring a table or a separate approval step before implementing already-requested fixes. Keep items with different decisions distinguishable.
Take action
When the user requests fixes, continue through implementation and relevant validation for the accepted items. Resolve failures caused by those changes. If an item needs clarification, ask for the missing information while continuing independent fixes.
When the user asks only for an assessment or response plan, do not change the code. Present the decisions instead. Do not make changes merely to accommodate an item classified as Will not address; return the verified facts and reasoning.
Report each item's actual outcome, validation, and any unresolved question or execution blocker; do not leave implemented items described only as Will address or describe blocked fixes as complete. Update decisions when new evidence warrants it.
GitHub operations
Distinguish reading review comments from writing to GitHub. Reply, submit a review, resolve a conversation, edit a comment, or otherwise change GitHub state only when the user explicitly asks.
When replying on GitHub, respond concisely to each item based on what was actually verified or changed. Do not add review discussion or a response to the reviewer as a source-code comment. Add a code comment only when future readers need it to understand the code itself.