Define a custom Copilot Chat mode instead of re-explaining your workflow every session

Define a custom Copilot Chat mode as a single markdown file, ready to save at
.github/chatmodes/pr-reviewer.chatmode.md. The filename fixes the mode's name in the chat mode picker, so name the
file for exactly how you want it to read in that dropdown.

MODE PURPOSE
Review a diff for correctness, test coverage, and scope creep, and produce a structured verdict — never propose or apply an edit.

TOOLS THIS MODE NEEDS, AND ONLY THESE
Read, Grep, and a Bash pattern scoped to git diff and git log only — no Edit, no Write, no unrestricted Bash.

MODEL FOR THIS MODE
the strongest reasoning-oriented model available in the picker, since review quality matters more than latency here

STRUCTURE THE FILE AS
1. YAML frontmatter with: description (one sentence, shown in the mode picker, so someone choosing
   between modes can tell them apart without opening the file), tools (an explicit list — do not
   grant edit or terminal access to a mode whose whole point is read-only review), and model (set
   to the strongest reasoning-oriented model available in the picker, since review quality matters more than latency here if this mode's work is well suited to a specific model rather than whatever
   the main conversation happens to be using).
2. Below the frontmatter, a system-prompt body addressed directly to Copilot, stating the one
   thing this mode does, the tone or level of detail it should default to, and what it should
   refuse to do even if asked mid-conversation to step outside that scope.
3. An explicit statement of what this mode will not do, matched to what a user might otherwise
   expect from a general chat mode — a review mode should say plainly that it will not also fix
   what it finds, so switching into review mode does not silently produce edits nobody asked this
   mode for.

SCOPE OF THIS FILE
Say whether this mode belongs in this repository's .github/chatmodes/ directory, where every
collaborator with this repo open gets it automatically, or in a personal user-profile location
that only you see — a team-wide review mode belongs in the repo; a personal shorthand you find
useful but have not checked whether the rest of the team would want belongs in your own profile
until you have.

CONSTRAINTS
- Do not build one mode that tries to cover two different jobs by switching behavior based on
  phrasing — if Review a diff for correctness, test coverage, and scope creep, and produce a structured verdict — never propose or apply an edit. is really two jobs, say so and propose two mode files instead of
  one mode that behaves inconsistently depending on how it is asked.
- If this mode overlaps with an existing one in chatmodes/ currently has plan.chatmode.md (planning only) and explain.chatmode.md (teaching-oriented explanations)., name the overlap and say
  whether the two should merge or whether the boundary between them needs to be sharper.
- Keep the body's tone instruction concrete and checkable — not 'be helpful and concise' but a
  stated default such as 'lead every response with the verdict, then the reasoning, never the
  reverse.'

OUTPUT
The complete file content, frontmatter and body, ready to paste as-is. After it, one sentence on
what a user in this mode still has to switch to a different mode to do.