Vague comments create work without giving direction. Each comment below follows the same shape: what you noticed, why it matters, what to check or change. Copy the closest match, adjust the specifics, and paste it directly into the PR.
How to Use These Comments
These aren't meant to be pasted verbatim into every review — they're a starting shape. Swap in the actual variable, function, or file name, and the comment goes from generic to specific in a few seconds. Specific is what makes a review comment actionable instead of just a delay.
For the framework behind writing comments like these, pair this list with AI Code Review.
Correctness and Logic
"What happens here if `user` is null? I don't see a guard before this property access, and the caller doesn't guarantee it's set."
"Double check the boundary here — should this be `<` or `<=`? The current condition excludes the last item in the list."
"This catch block swallows the error without logging or re-throwing. If this fails in production, we'll have no signal it happened."
"This assumes `items` is always an array. Where is that guaranteed upstream? If it can be undefined, this will throw."
"This looks like it duplicates what `formatCurrency()` already does in `utils/format.ts`. Worth reusing it instead, so both stay in sync?"
Security
"This value comes straight from the request body and goes into the query below. Can we validate/sanitize it before it's used?"
"This checks the user's role before rendering the button, but I don't see the same check on the API route itself. Can we confirm the server enforces this too?"
"This log line includes the full request object — does that include the password/token field? Worth redacting before this ships."
"Is this key meant to be committed? If it's a real credential, let's move it to environment config and rotate it."
"This grants access to the whole resource rather than the specific record the user owns. Can we scope this down?"
Tests and Coverage
"Can we add a test that fails on the old code and passes on this fix? Without it, this bug can silently come back."
"All the new tests cover the success case. Can we add one for the failure/timeout case too?"
"This test checks that a specific internal function was called, rather than the outcome a user would see. Would asserting on the visible result make it more resilient to refactors?"
"This test depends on real time (`Date.now()`), which can make it flaky. Can we inject or mock the clock instead?"
"The description mentions this handles duplicate submissions, but I don't see a test for that case — can we add one?"
Scope and Readability
"This PR is titled as a bug fix, but it also refactors the neighboring component. Can we split that into a separate PR?"
"This helper is only called from one place right now. Would inlining it make the flow easier to follow until there's a second caller?"
"`data2` doesn't tell me what this holds — could we name it after what it represents, like `pendingOrders`?"
"What does `86400` represent here? A named constant (`SECONDS_PER_DAY`) would save the next reader a lookup."
"The description summarizes the intent, but I don't see what specifically changed in behavior. Could you add a one-line before/after?"
Observability and Rollback
"If this step fails in production, what will tell us? Worth adding a log line with enough context to debug without reproducing locally."
"This touches the payment flow — how would we disable or revert this quickly if it misbehaves after merge?"
"Should this ship behind a feature flag, given it changes default behavior for existing users?"
"This changes what counts as a successful request — does the existing dashboard/alert threshold still make sense?"
"I see the forward migration, but what's the rollback step if we need to revert after this is already in production?"
Conclusion
None of these comments are complicated. What makes them useful is specificity: they name the exact line or behavior, explain the risk in one clause, and point at a concrete next step. That's the difference between a comment that gets acted on and one that gets a shrug.
Pair this list with AI Code Review for the underlying review workflow, The AI Code Ownership Checklist for what to check before merge, and AI PR Review Checklist Template to make the standard stick across a whole team.