review-pr

Review Pull Request

Answers the craft question: "is this code well-built?" Covers approach and simplicity, code quality, architecture, security, tests, and operational concerns as static inspection. It does not build or run the code (that is /verify-pr's conformance role) and does not judge whether the target is the right product (that is /validate-pr's validation role). Findings about whether the criteria are met go to /verify-pr; findings about whether the right problem is solved go to /validate-pr. Judging whether the chosen approach is the simplest and most changeable for this codebase is this skill's job (see Approach & Simplicity); the reviewer presumes the change is larger than the problem needs and must work to disprove it before approving. Approach-level notes arriving from /validate-pr or /verify-pr go there. Writes findings to a structured markdown file.

Prerequisites

• Apply the shared SDLC conventions in skills/sdlc/references/shared.md.
• Apply the shared evidence standard in ../sdlc/references/evidence.md: label every finding with a level in the form L<n> - <Name>. This review is static, so its ceiling is L2 - Ruled out; a claim that needs execution routes to /verify-pr (does the accepted behavior work?) or /adversarial-pr-review (does a plausible failure happen?).
• If no argument is provided, target the pull request from $PR_NUMBER (and $REPO).
• gh CLI authenticated with read access to the target repository
• git worktree available
• PR number ($1) identifying an open pull request

Skill attribution (GitHub)

Before posting to GitHub, read ../github-post-attribution/SKILL.md and append the footer for SKILL_DIR = review-pr.

Communication guidelines (outbound text)

Before composing any text posted or drafted on the user's behalf, apply communication-guidelines/SKILL.md.

Workflow

Fetch PR metadata + comments ($1)
            |
            v
  review.yaml scope?
  (same head -> stop, return state;
   pure rebase -> bump sha, stop;
   ancestor delta or contained
   tree-diff -> incremental;
   else -> full review)
            |
            v
  Create git worktree on PR branch
            |
            v
  Pre-Review Checklist
  (build, metadata, objective)
            |
            v
  Code Review Checklist
  (approach, quality, tests,
   architecture, ops, security, docs)
            |
            v
  Context-Specific Review
  (feature / bug fix / DB / API?)
            |
            v
  Update review.yaml findings
  Write review-pr.<sha>.md
  (report.md -> latest)
             |
             v
   Post review file
   as PR comment
   (gated by should-post-to-github)