Constructive Code Review

Review feedback changes the PR and teaches what matters. Vague feedback fails both goals: the contributor cannot act on it, and readers learn nothing. Mark each point's severity so minor suggestions do not stall the PR and real issues do not sound optional.

Every comment signals its own severity

State explicitly whether a comment is a blocker, a suggestion, or a question — don't make the contributor infer it from tone:

• Blocker: "this needs to change before merge, because ___."
• Suggestion: "consider ___" or "you might want to ___, but not blocking."
• Question: genuinely open — you don't yet know if there's a problem.

A review that's all blockers reads as gatekeeping; a review that's all soft suggestions on something that actually needs to change is a disservice to the contributor and the codebase. Say which one each comment is.