Files
dotclaude/skills/pr-review/SKILL.md
T
Poshan Pandey 491a45dd43 Add dotclaude configuration files
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-26 17:16:27 -07:00

3.5 KiB

name, description, argument-hint, disable-model-invocation
name description argument-hint disable-model-invocation
pr-review Review code changes or a pull request — delegates to specialist agents for code quality, security, performance, and documentation. [PR number | staged | file path — or omit to auto-detect] true

Review code changes by delegating to specialist agents and synthesizing a unified report. Works with PRs, staged changes, or specific files.

Step 1: Determine Scope

Parse $ARGUMENTS to determine what to review:

  • PR number (e.g., 123 or #123): fetch with gh pr view $ARGUMENTS. This is the full PR review path (includes PR quality checks in Step 2).
  • No argument: try gh pr view to detect a PR for the current branch. If a PR exists, use it. If not, fall back to git diff --cached (staged), then git diff (unstaged).
  • staged: review git diff --cached. If nothing staged, fall back to git diff.
  • File path: review that specific file's current state.

If there are no changes to review, say so and stop.

Step 2: PR Quality Check (PR path only)

Skip this step if reviewing staged changes or a file — jump to Step 3.

When reviewing a PR, fetch and check:

  • PR title, description/body, author, base branch, head branch
  • gh pr diff $NUMBER for the full diff
  • gh pr checks $NUMBER for CI status
  • gh api repos/{owner}/{repo}/pulls/$NUMBER/comments for review comments

Review the PR itself before the code:

  • Title: descriptive and under 72 chars?
  • Description: explains the why? Includes a test plan? Flag if empty or template-only.
  • Size: count changed files and lines. Flag if >500 lines changed (suggest splitting).
  • Base branch: targeting the right branch?
  • CI status: passing, failing, or pending? If failing, note which checks — fix CI first.
  • Unresolved comments: list open review threads with file:line and comment text.

Step 3: Code Review (delegate to agents)

  1. Always: delegate the diff to @code-reviewer
  2. If security-sensitive code changed — auth, input handling, queries, tokens, session management, file path construction: delegate to @security-reviewer
  3. If performance-sensitive code changed — endpoints, DB queries, loops over collections, caching, connection management: delegate to @performance-reviewer. Skip if changes are only docs, config, tests, or static assets.
  4. If documentation changed — .md files, significant docstring/JSDoc changes, API docs: delegate to @doc-reviewer

Determine relevance by reading the diff content, not just file paths.

Step 4: Synthesize Report

For PR reviews:

## PR Review: #[number] — [title]

**Author**: [author] | **Base**: [base] → **Head**: [head] | **Changed**: [N files, +X/-Y lines]

### PR Quality
- Title: [ok / needs improvement]
- Description: [ok / missing test plan / empty]
- Size: [ok / large — consider splitting]
- CI: [passing / failing — list failures]
- Unresolved comments: [none / list]

### Code Review
#### Critical / High
- [Agent] File:Line — issue

#### Medium
- [Agent] File:Line — issue

#### Low
- [Agent] File:Line — issue

### Verdict
[Ready to merge / Needs changes — summarize blockers]

For non-PR reviews (staged/file):

## Review Summary

**Scope**: [staged changes / file path]
**Agents run**: [list]

### Critical / High
- [Agent] File:Line — issue

### Medium / Low
- [Agent] File:Line — issue

### Passed
- [areas with no issues]

Deduplicate findings that overlap between agents. Attribute each finding to the agent that found it.