settled-reach/whatsinagame/templates/.claude/skills/pr-review/SKILL.md

name, description, user-invocable, allowed-tools

name	description	user-invocable	allowed-tools
pr-review	Review a branch diff with team-appropriate agents before merge. Use when the user says "review pr", "review this PR", "review this branch", or invokes /pr-review. Spawns reviewers matched to the branch type in parallel. Reports approve/reject with inline comments.	true	Bash, Read, Grep, Glob, Task

PR Review Skill

Multi-agent review of a branch diff against main. Reviewer composition depends on the branch type. All reviewers must approve for a clean review.

Workflow

1. Determine the branch

If the user provided a branch name as argument, use it. Otherwise use the current branch (git branch --show-current). If on main, ask the user which branch to review.

To list open PRs, use the git host CLI matching your project (see CLAUDE.md):

# GitHub: gh pr list --state open
# Gitea: tea pr list --login <login> --repo <owner/repo> --state open --output simple
# GitLab: glab mr list --state opened

Fetch remote branches first:

git fetch --all

2. Determine reviewer team

Map the branch name to a reviewer set. Use the branch prefix (before any / or - suffix) to classify:

Branch type	Branches	Reviewers
code	server, client, backend, frontend, ci, or unknown	QA Engineer (code quality) + Architect (architectural consistency)
content	content, copy, docs	QA Engineer (formatting) + Content Author (voice, tone) + Domain Expert (consistency)
visual	visual, design, art	QA Engineer (file organization) + Visual Designer (art direction)
audio	audio, sound	QA Engineer (file organization) + Audio Designer (atmosphere, feedback)

If the branch name doesn't match any known type, default to code reviewers.

3. Generate the diff and read source files

git log --oneline main..<branch>
git diff main...<branch> --stat

If the diff is empty, report "No changes to review" and stop.

Exclude generated/vendor files from the review diff. Common exclusions:

• Lock files (auto-generated)
• Vendor directories
• Generated UID/cache files
• Binary database backups

For large diffs (>1000 lines of source), provide source files rather than raw diff to reviewers — cleaner context, better reviews. Read files with git show origin/<branch>:<path> and include them in the prompt.

IMPORTANT — agent tool access: Not all reviewer agents have Bash access. For agents without Bash, you MUST read the source files yourself (via git show origin/<branch>:<path>) and paste the file contents directly into the agent prompt. Read references/reviewer-profiles.md for which agents can and cannot read branches.

4. Spawn reviewers in parallel

Use the Task tool to spawn all reviewers simultaneously in a single message.

Read references/reviewer-profiles.md for the full per-branch-type reviewer specifications (agent types, models, prompt focus areas). Match the branch type from step 2 to the corresponding section.

All reviewers: request structured verdict: APPROVE or REQUEST_CHANGES with file-specific comments.

5. Present results

Format the combined review as a table per reviewer:

## Review: <branch> -> main  (type: code|content|visual|audio)

### <Reviewer Name> (<Focus>): [APPROVE | REQUEST_CHANGES]
[Summary]
| # | File | Severity | Issue |
|---|------|----------|-------|
| 1 | path:line | critical/warning/suggestion | description |

### <Reviewer Name> (<Focus>): [APPROVE | REQUEST_CHANGES]
...

### Verdict: [APPROVED | CHANGES REQUESTED]

The overall verdict is APPROVED only if all reviewers approve.

Prompt template for reviewers

Use this structure when constructing the agent prompts (adapt as needed):

Review the following {branch_type} branch diff for merge into main.

Branch: {branch}
Branch type: {branch_type} (code|content|visual|audio)
Commits:
{commit_log}

Diff stats:
{diff_stat}

[Source files or diff here — exclude vendor/generated code]

Your review focus: {focus_area}

Respond with:
1. Verdict: APPROVE or REQUEST_CHANGES
2. Summary: 2-3 sentence overall assessment
3. Comments: List of specific issues, each with:
   - File path and approximate location
   - Severity: critical / warning / suggestion
   - Description of the issue
If no issues found, say APPROVE with a brief positive summary.

6. Posting results

After presenting results to the user, post the review as a PR comment using the git host CLI matching your project (see CLAUDE.md):

# GitHub: gh pr comment <number> --body "$(cat /tmp/review.md)"
# Gitea: tea comment --login <login> --repo <owner/repo> <number> "$(cat /tmp/review.md)"
# GitLab: glab mr comment <number> --message "$(cat /tmp/review.md)"

Write the review body to a temp file first, then pass via $(cat) to avoid issues with multi-line strings in CLI arguments.

Tips from practice

• Vendor code: Explicitly note vendor code in the prompt so reviewers focus on project code.
• Large PRs: For PRs touching many files, provide file-by-file source code rather than a single massive diff. Reviewers give better feedback.
• Multiple PRs: When reviewing several PRs, spawn all reviewers in one parallel batch. This is faster than sequential.
• Architect reads decisions: Always tell the architect reviewer to read the relevant decisions/*.md files — this grounds the review in project-specific architectural choices.
• Binary files: Exclude binary files from the diff. Note them in the prompt as "also changed" if relevant.