autocoder/.claude/commands/review-pr.md

description

description
Review pull requests

Pull request(s): $ARGUMENTS

• If no PR numbers are provided, ask the user to provide PR number(s).
• At least 1 PR is required.

TASKS

1. Retrieve PR Details

   • Use the GH CLI tool to retrieve the details (descriptions, diffs, comments, feedback, reviews, etc)

2. Assess PR Complexity

   After retrieving PR details, assess complexity based on:

   • Number of files changed
   • Lines added/removed
   • Number of contributors/commits
   • Whether changes touch core/architectural files

   Complexity Tiers

   Simple (no deep dive agents needed):

   • ≤5 files changed AND ≤100 lines changed AND single author
   • Review directly without spawning agents

   Medium (1-2 deep dive agents):

   • 6-15 files changed, OR 100-500 lines, OR 2 contributors
   • Spawn 1 agent for focused areas, 2 if changes span multiple domains

   Complex (up to 3 deep dive agents):

   • 15 files, OR >500 lines, OR >2 contributors, OR touches core architecture

   • Spawn up to 3 agents to analyze different aspects (e.g., security, performance, architecture)

3. Analyze Codebase Impact

   • Based on the complexity tier determined above, spawn the appropriate number of deep dive subagents
   • For Simple PRs: analyze directly without spawning agents
   • For Medium PRs: spawn 1-2 agents focusing on the most impacted areas
   • For Complex PRs: spawn up to 3 agents to cover security, performance, and architectural concerns

4. PR Scope & Title Alignment Check

   • Compare the PR title and description against the actual diff content
   • Check whether the PR is focused on a single coherent change or contains multiple unrelated changes
   • If the title/description describe one thing but the PR contains significantly more (e.g., title says "fix typo in README" but the diff touches 20 files across multiple domains), flag this as a scope mismatch
   • A scope mismatch is a merge blocker — recommend the author split the PR into smaller, focused PRs
   • Suggest specific ways to split the PR (e.g., "separate the refactor from the feature addition")
   • Reviewing large, unfocused PRs is impractical and error-prone; the review cannot provide adequate assurance for such changes

5. Vision Alignment Check

   • Read the project's README.md and CLAUDE.md to understand the application's core purpose
   • Assess whether this PR aligns with the application's intended functionality
   • If the changes deviate significantly from the core vision or add functionality that doesn't serve the application's purpose, note this in the review
   • This is not a blocker, but should be flagged for the reviewer's consideration

6. Safety Assessment

   • Provide a review on whether the PR is safe to merge as-is
   • Provide any feedback in terms of risk level

7. Improvements

   • Propose any improvements in terms of importance and complexity

8. Merge Recommendation

   • Based on all findings, provide a clear merge/don't-merge recommendation
   • If all concerns are minor (cosmetic issues, naming suggestions, small style nits, missing comments, etc.), recommend merging the PR and note that the reviewer can address these minor concerns themselves with a quick follow-up commit pushed directly to master
   • If there are significant concerns (bugs, security issues, architectural problems, scope mismatch), recommend not merging and explain what needs to be resolved first

9. TLDR

   • End the review with a ## TLDR section
   • In 3-5 bullet points maximum, summarize:
     • What this PR is actually about (one sentence)
     • The key concerns, if any (or "no significant concerns")
     • Verdict: MERGE / MERGE (with minor follow-up) / DON'T MERGE with a one-line reason
   • This section should be scannable in under 10 seconds