code-review

name	code-review
description	Use when the user asks to review a pull request, leave review comments, decide between approve / request changes / comment, or resolve conversations on someone else's PR. Triggers on phrases like "review this PR", "leave a code review", "approve or request changes", "review someone's PR", "resolve this conversation", "PR review comments", "comment on the PR".

Code review

Code review has two goals at Serokell: spreading knowledge (so the bus factor stays high) and catching bugs before merge. Use this skill whenever you act as reviewer on a PR or MR.

When to review

• After opening your own PR, review at least two other open PRs in the repo. If fewer than two are open, review all of them. This keeps reviews evenly distributed.
• It is your responsibility to get your own changes merged — ping reviewers if they go silent.
• Start with PRs where your review was explicitly requested. Use https://github.com/pulls/review-requested on GitHub.
• Within that, review old PRs first. Don't cherry-pick by topic interest — older PRs accumulate review debt.

How to review

• Ask questions liberally. If a piece of code isn't obvious to you, ask. It's the author's job to explain everything they did. It is your job to learn from the code and ensure the repo keeps only high-quality code.
• Check the commit history, not just the diff. Each commit should satisfy the policy in the committing-work skill (one problem, Problem/Solution body, signed, no within-PR fix-ups by merge time).
• If you are satisfied with the code changes but the commit history is messy, request changes (not approve) and say specifically that the code is fine but history needs cleanup — otherwise the author may merge with messy history.
• If your review wasn't requested and you don't think it should have been, remove yourself and request a review from a more appropriate person.
• If your review wasn't requested but you want a chance to review the PR before it is merged, request a review from yourself.

Verdict choice

Three GitHub / GitLab verdicts: approve, request changes, comment.

• Use approve when you're confident the PR is mergeable as-is (or trusting the author to fix tiny nits after).
• Use request changes when you want changes made before merge.
• Use comment only when you genuinely have neither approve nor request-changes confidence — for example, when raising a question you can't yet judge.

Comment hygiene

• When the issue raised by your comment is addressed (e.g. requested change made, question answered), you (the reviewer) mark the conversation as resolved — not the author.
• You may also mark another reviewer's conversation as resolved, but only if you are 100% confident it has been resolved.
• Every time you look at the PR (e.g. after the author addresses feedback), check for stale comments of yours that are no longer relevant and resolve them.

Last reviewer shortcut

If you are the last reviewer whose review was requested, all the comments are minor and indisputable, and they can be addressed quickly: it is acceptable to make the fixes yourself, push, and approve in one step.

Merging

After all reviewers approve and CI is green, the PR is mergeable. Either the author or a reviewer merges (see the pull-requests skill for merge mode). Generally let the author merge — they may want to polish history first.

See also

• pull-requests skill — opening / updating / merging PRs.
• committing-work skill — commit history expectations.