| name | code-review |
| description | Review code changes in local diffs, staged changes, the current branch PR, or a specific GitHub PR URL. Use when asked to review a PR, review local changes, inspect a diff, check Copilot review comments, or decide whether changes are ready to merge. Gathers PR context, comments, linked issues, and changed files; checks correctness, security, reliability, docs, and tests.
|
Code Review
Use this skill for code reviews of local changes, staged changes, recent commits,
current-branch PRs, or explicit GitHub PR URLs.
Default behavior: review and report findings. Do not post GitHub review comments,
PR comments, issue comments, or review approvals unless the user explicitly asks.
If posting prose on GitHub, load and apply the writing-voice skill first.
Review modes
First determine which mode applies.
Mode A โ PR URL provided
If the user provided a GitHub PR URL, review that remote PR only. The PR may be
for a different repo than the current directory. Skip local diff gathering.
Use gh for GitHub data. Read references/github-pr-context.md for the full PR
context workflow.
Mode B โ No PR URL
If no PR URL was provided, review local changes and check whether the current
branch has an open PR.
Prefer review targets in this order:
- staged diff:
git diff --cached
- working tree diff:
git diff
- last commit:
git diff HEAD~1
If a current-branch PR exists, include PR title, body, comments, review comments,
and linked issue context in the review.
Required context gathering
Before reviewing:
- Identify the repo, branch, and review mode.
- Read the full diff, not only the stat.
- For changed files with large diffs or unclear surrounding context, read the
full file.
- If a PR exists, read the PR body, conversation comments, inline review
comments, and linked issues.
- If the user asks to process Copilot comments, read
references/copilot-review.md and follow that workflow.
Do not review from a summary alone when source files are available.
Review checklist
Read references/checklist.md and apply it to each changed file. Focus on real
issues that matter for the codebase:
- correctness
- security
- reliability
- maintainability
- performance, only when clearly relevant
- docs
- tests
Do not invent problems. If the diff is clean, say so.
Output format
Organize findings by severity:
๐ด Must fix
Issues that will cause bugs, security vulnerabilities, or data loss.
๐ก Should fix
Issues that hurt reliability, readability, or maintainability.
๐ก Suggestions
Optional improvements: style nits, minor simplifications, better naming.
โ
What looks good
Briefly note what is well done: good tests, clear error handling, clean naming,
or a simple design.
๐ค Copilot comments addressed
If a Copilot review was processed, summarize how many comments were addressed,
which were fixed, which were dismissed, and why.
๐ PR context
If a PR exists, note whether the changes address PR feedback and linked issue
requirements. Flag any PR comments or issue requirements not yet addressed.
๐ Docs
Say whether docs need updates. If the changes introduce new features, config, or
behavior changes without docs, flag that specifically.
๐งช Tests
Summarize test coverage. List specific code paths or files that need tests but
do not have them.
For each finding:
- quote the relevant code or cite file + line range
- explain what goes wrong concretely
- suggest a fix when possible
Publishing reviews or comments
If the user asks you to post comments or a GitHub review:
- Draft the review text first.
- Load and apply the
writing-voice skill and curated profile.
- Ask for confirmation before publishing unless the user explicitly asked you to
post/publish/submit.
- Use
gh, preferably with --body-file for anything longer than one sentence.
Never post @copilot review this; request Copilot through the reviewer flow in
references/copilot-review.md.
