review-follow-uplisted

# Review Follow-up Turn review comments on a pull request into landed changes. ## Collect the feedback Read every review thread, not just the top-level review summaries. Include threads marked resolved only if the user asks — a resolved thread usually means it is already handled. Sort each comment into one of three buckets and say which is which: - **Actionable** — a concrete change is being requested. - **Question** — the reviewer wants an explanation, not a diff. - **Note** — an observation with no change implied. ## Work the actionable ones Fix them in the code, not in the reply. Group related comments so you make one coherent change rather than several overlapping ones. If you disagree with a comment, say so to the user with your reasoning and let them decide. Do not silently skip it, and do not implement something you believe is wrong without flagging it. If a comment is ambiguous enough that two readings lead to different code, ask rather than guess. ## Reply Reply once per thread, after the change exists. State what you changed and where. Do not claim a comment is addressed until the code is actually written. Replies are outward-facing: show the user the text before posting. Before posting, re-read the thread and the current diff so the reply describes the change that actually exists. After posting, verify the reply is attached to the intended thread; do not resolve a thread unless the user requested it. ## Report List what you changed, what you answered