> Review a Site Kit GitHub pull request end-to-end against the project's conventions and quality rubric. Use when the user asks to review, critique, or give feedback on a pull request by number (e.g. "review PR #12345", "review pull request 12345", "/review-pr 12345") in the google/site-kit-wp repo.
npx skills add https://github.com/google/site-kit-wp --skill review-pr
Review pull request #$ARGUMENTS (if no number was given, ask for one) by following the
project's shared playbook. Do not reimplement the procedure here — read and follow the
playbook, which is the single source of truth shared with the other AI tools.
docs/context/workflow/review-pr.md and follow every step: fetch thePR data, read the linked issue, load only the relevant docs/context/{js,php} convention
docs (per the scope map), inspect the changed files, judge against the checklist, and produce
the structured review.
gh pr view $ARGUMENTS --json number,title,body,author,baseRefName,headRefName,files,additions,deletions,commitsand gh pr diff $ARGUMENTS in parallel. Stop and ask the user if the PR is missing or the
diff is empty.
.github/PULL_REQUEST_TEMPLATE.md) links itunder "Addresses issue: - #<number>". Extract that number, run
gh issue view <number> --json title,body,labels, and parse its Acceptance criteria,
Implementation Brief, and Test Coverage — this is the spec the PR must satisfy. If no issue
is linked, note it and review conventions + code quality only.
docs/context/workflow/review-checklist.md — requirementsadherence (against the issue) first, then conventions, code quality, and verification —
citing the context file + section for every deviation.
Adherence → Principles Compliance → Code Quality → Security → Performance → Test Coverage →
Nits → Verdict).
on GitHub unless the user explicitly asks.
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping
Comprehensive GitHub code review with AI-powered swarm coordination
Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
Use this skill to review code. It supports both local changes (staged or working tree) and remote Pull Requests (by ID or URL). It focuses on correctness, maintainability, and adherence to project standards.
Refactor bloated AGENTS.md, CLAUDE.md, or similar agent instruction files to follow progressive disclosure principles. Splits monolithic files into organized, linked documentation.
Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits.
Take google/review-pr from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.