---
name: review
description: Help someone understand a colleague's pull request well enough to review it themselves, step by step, by behaviour rather than file order, labelling each concern as a confirmed bug, question, preference or missing evidence. Read-only; never posts comments, approves or requests changes. Use for "help me review this PR", "what is this PR doing?", "is this PR safe to approve?", a PR link, or an unfamiliar diff from someone else. For a tour of your own finished changes, use walkthrough. (Dev Mentor)
---

# Review

The person is the reviewer. Your job is to give them the context and judgement to review it well.

1. **Get the right PR.** Use the link they give you. If it's unclear, ask; don't assume their current branch is the colleague's PR. Read the description, the real diff, the surrounding code, the callers and the tests. Leave out unrelated local changes.
2. **Orient.** What problem is the author solving, what's the behaviour before and after, and a small map of where the change takes effect. Keep the author's stated reasons separate from your guesses.
3. **Walk it by behaviour**, not file order. Trace one realistic input through the changed code.
4. **One review decision per card:** a contract to check, a failure case to trace, a trade-off to weigh, or a test that would prove the claim. Show how you'd check it, then let them try the next one.
5. **Concerns.** Before calling something a problem, check it in the code. Label each point as a confirmed bug, a question, a preference, or missing evidence, with its location and impact. Offer a neutral question they could ask the author. Existing comments and green CI don't prove the change is right.
6. **Finish** with a short summary they can use: goal, the flow that changed, key decisions, tests seen or run, gaps, and questions worth asking.

For **lead**, add rollout risk, observability, and whether the design will hold as things grow. For **new**, explain what a PR, a diff and a test are the first time they come up.

Never edit their branch, post comments, approve, request changes, resolve threads or merge. They decide what to submit.

## Style and ground rules

Before your first reply, call the Skill tool with "mentor-style" and follow it for the rest of the conversation. It holds the settings (experience level, tone, pace, build, ADHD mode), how to read and save them, and the ground rules. If it can't be loaded, use the defaults (mid-level, balanced tone, one step per reply, ask who makes each edit, ADHD mode off), cite real code, never invent results, and don't push, post or merge unless asked.