メニュー
Review GitHub pull requests for correctness, design quality, test coverage, security, performance, and backward compatibility. Use when reviewing PRs, when asked to review code changes, or when the user mentions "review PR", "code review", or "check this PR".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
Reference for what GitHub issue/PR labels mean in this workspace (S-triage, S-needs-scope, S-impl, prio-p0-critical, A-dev-tools, and others under My Labels). Use when the user asks what a label means, which label to apply, or how to add missing labels to a repo with `gh label create --force`. Secondary: bootstrap labels on a new repo that does not have them yet.
Writes clear pull request descriptions from the current branch diff against a base branch. Defaults to `main`, but supports `dev` or any other user-specified comparison branch. Use when the user asks for a PR description, pull request summary, or a markdown write-up for changes against a base branch.
Troubleshoot, document, and operate Tailscale Serve for local development previews, HTTPS `.ts.net` URLs, MagicDNS, admin-console HTTPS certificate setup, WSL or localhost proxy targets, phone testing over a tailnet, and curl/OpenSSL diagnosis of Serve TLS failures. Use when a user says Tailscale Serve, `tailscale serve`, `.ts.net`, MagicDNS, HTTPS certs, SSL protocol error, TLS alert, Funnel versus Serve, localhost preview, Next.js preview over Tailscale, or sharing a dev server with a phone or another tailnet device.
Query and reconcile Sai perps data across live Perp, Oracle, and SLP Vault contracts; Sai Keeper GraphQL; DexPal REST; sai-keeper Postgres; and referral records. Use for markets, open interest, fees, trades, vault health, oracle prices, REST statistics, database-backed metrics, referral ownership or history, trading-credit balances, app/indexer behavior, or mismatches between chain, APIs, databases, sheets, and operator records. Keep mutations and private operator workflows in sai-ops.
Prefer the nearest relevant `justfile` as the default command surface for build, test, lint, format, run, deploy, and repo automation workflows. Use when a repo or subproject has a `justfile`, or when the user mentions `just`, `justfile`, recipes, or Makefile-to-just migration.
| name | gh-pr-review |
| description | Review GitHub pull requests for correctness, design quality, test coverage, security, performance, and backward compatibility. Use when reviewing PRs, when asked to review code changes, or when the user mentions "review PR", "code review", or "check this PR". |
Review pull requests with emphasis on what automated checks usually miss: correctness, design quality, security, backward compatibility, test adequacy, maintainability, concurrency risks, and performance regressions.
If the user invokes /gh-pr-review with no arguments, do not perform a review.
Ask what they want reviewed:
What would you like me to review?
- A PR number or URL, for example
/gh-pr-review 12345- A local branch, for example
/gh-pr-review branch
The user provides a PR number or URL:
/gh-pr-review 12345
/gh-pr-review https://github.com/org/repo/pull/12345
For a detailed review with line-specific comments:
/gh-pr-review 12345 detailed
Use gh CLI to fetch PR data:
# Get PR details
gh pr view <PR_NUMBER> --json title,body,author,baseRefName,headRefName,files,additions,deletions,commits
# Get the diff
gh pr diff <PR_NUMBER>
# Get PR comments and reviews
gh pr view <PR_NUMBER> --json comments,reviews
Review changes in the current branch that are not in main:
/gh-pr-review branch
/gh-pr-review branch detailed
Use git commands to understand branch changes:
# Get current branch name
git branch --show-current
# Get list of changed files compared to main
git diff --name-only main...HEAD
# Get full diff compared to main
git diff main...HEAD
# Get commit log for the branch
git log main..HEAD --oneline
# Get diff stats
git diff --stat main...HEAD
For local branch reviews:
When invoked from a GitHub PR automation, PR metadata may already be injected into the prompt. Detect this mode by the presence of structured PR context, PR body, comments, or review comments in the prompt.
The prompt may already contain:
Use git commands to get the diff and commit history. The base branch name is in
the prompt context, for example PR Branch: <head> -> <base> or a baseBranch
field.
# Get the full diff against the base branch
git diff origin/<baseBranch>...HEAD
# Get diff stats
git diff --stat origin/<baseBranch>...HEAD
# Get commit history for this PR
git log origin/<baseBranch>..HEAD --oneline
# If the base branch ref is not available, fetch it first
git fetch origin <baseBranch> --depth=1
Do not use gh CLI commands in this mode if the action environment only
provides git and injected PR metadata.
For medium or large PRs, spawn sub-agents to investigate independent areas: changed subsystems, expected test locations, public API callers, security surfaces, or unfamiliar infrastructure. Ask each sub-agent to return concise evidence and file references, not a full review.
Before finalizing, fact-check each reported issue. For every non-obvious claim, re-read the relevant code or ask a sub-agent to verify it as valid, invalid, or needs rewording. Drop invalid issues and reword unclear ones.
Before reviewing, build a clear picture of what changed and why:
Evaluate each meaningful changed line against the checklist below. Prioritize bugs and risks over style preferences.
Backward compatibility matters for public APIs, persisted data, configuration, wire protocols, CLI behavior, migrations, user-visible behavior, and stable integrations.
Check for:
When unsure, ask:
Write findings as concrete requests. Each finding should include the affected file or behavior, why it matters, and what change would resolve it.
Recommend one of:
Missing tests for new behavior or bug fixes normally means Request Changes.
Structure reviews like this. Omit sections where there are no problems to report. Do not write "No concerns" or affirmative filler.
## PR Review: #<number>
<!-- Or for local branch reviews: -->
## Branch Review: <branch-name> (vs main)
### Summary
What the PR does in one sentence, followed by the overall verdict.
### Correctness
[Problems only]
### Design And Maintainability
[Problems only]
### API And Compatibility
[Problems only]
### Testing
[Problems only]
### Security
[Problems only]
### Concurrency And Reliability
[Problems only]
### Performance
[Problems only]
### Observability And Operations
[Problems only]
### Recommendation
**Approve** / **Request Changes** / **Needs Discussion**
[Brief justification focused on what blocks approval, if anything]
Only include this section if the user requests a detailed or in-depth review. Do not repeat observations already made in other sections. Use it for additional file-specific feedback that does not fit the categorized sections.
### Specific Comments
- `src/module.ts:42` - This branch does not handle an empty result set, so the caller receives a success response with incomplete data.
- `test/module.test.ts:100-105` - Add a regression test for the error path introduced by this change.
When reviewing, consult project files for context rather than relying on memory. Common examples include:
README.md, CONTRIBUTING.md, CLAUDE.md,
AGENTS.md, or .cursor/rules/.