| name | review-pr-lite |
| description | Review a pull request for code quality and security issues without using subagents. Use when the user wants a lighter-weight PR review in a single skill. |
target_pr = $ARGUMENTS
If target_pr is not provided, use the PR of the current branch.
Important: Do Not Switch the Local Branch
- Do NOT check out, switch, or otherwise move the local branch (e.g.,
git checkout, git switch, gh pr checkout).
- To inspect the PR's changes, use
git and gh commands that read remote state without moving the working tree. For example:
gh pr view $target_pr to read PR metadata and description.gh pr diff $target_pr to read the diff.gh pr view $target_pr --json files or gh api to list changed files.git fetch origin pull/<PR_NUMBER>/head:refs/remotes/origin/pr-<PR_NUMBER> and git diff origin/main...origin/pr-<PR_NUMBER> if a local read-only ref is needed.
Step 1: Gather PR Context
Run the following in parallel:
- Get the PR description and metadata via
gh pr view $target_pr (do not check out the PR locally).
- Get the PR diff via
gh pr diff $target_pr.
- If needed, inspect changed files individually for deeper context using
gh / git commands (e.g., gh api, git show) — without switching the local branch.
Step 2: Review the Changes
Review the PR directly in this skill without calling any subagents.
Focus on both of the following:
-
Code Review
- Bugs or behavioral regressions
- Incorrect assumptions or edge cases
- Missing or weak tests
- Maintainability issues that could cause near-term problems
-
Security Review
- Injection risks
- Auth/authz mistakes
- Secrets exposure
- Unsafe file, network, shell, or deserialization behavior
- Dependency or configuration changes that could weaken security
Step 3: Report Findings
Integrate all findings into one review result. Please output the PR number in the result so that the user can easily find the PR.
Reporting Rules
- Assign a severity level to each finding: low, mid, high, or critical.
- Assign a sequential number to each finding (e.g., #1, #2, #3, ...).
- Present findings first, ordered by severity.
- If no findings are discovered, explicitly state that no findings were found.
- Keep the summary brief and focused on risk and testing gaps.
Step 4: Check GitHub Actions Workflows
After completing the content review, check the status of the GitHub Actions workflows for $target_pr (for example, using gh pr checks or gh run list).
- Report the status of every workflow run to the user, including runs that are still in progress.
- For each failing workflow, also report:
- The likely cause of the failure (based on the relevant logs or job output).
- Candidate solutions or next steps to resolve it.
