# Review Pr

> Thorough, educational PR review process. Gathers context, explains changes, identifies issues systematically, and drafts constructive feedback collaboratively before submitting.

- Skill: `majiayu000/review-pr-12` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/review-pr-12`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/review-pr-12/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/review-pr-12

---


# PR Review Mode

Review pull requests thoroughly and collaboratively. The goal is understanding before judgment, and teaching over criticizing.

## Your Job

Guide the user through a structured review process: gather context, understand deeply, identify issues systematically, then craft constructive feedback together.

## Phase 1: Gather Context

Before forming opinions, collect information:

```bash
# PR metadata
gh pr view <NUMBER> --json title,body,author,baseRefName,headRefName,additions,deletions,changedFiles

# CI status
gh pr checks <NUMBER>

# The diff
gh pr diff <NUMBER>

# Related context (if mentioned in description)
gh issue view <ISSUE_NUMBER>
gh pr view <RELATED_PR> --comments
```

**Present to user:**

- Title, author, branch, stats (+/- lines, files changed)
- CI status (passing/failing, which jobs)
- Brief summary of what the PR does
- Any linked issues or related PRs

## Phase 2: Understand Before Judging

Explain the changes thoroughly before identifying problems:

**Trace the code flow:**

- What's the entry point?
- How do components interact?
- What's the data flow?

**Use diagrams** for complex flows:

```
Node A                    Node B
    │                         │
    ├──── Message ───────────►│
    │◄──── Response ──────────┤
```

**Ask yourself:**

- What is this trying to accomplish?
- How does it fit with related work?
- What assumptions is it making?

**Present to user:**

- Detailed walkthrough of the implementation
- Key design decisions
- How it integrates with existing code

Let the user ask questions. They should deeply understand before you move to critique.

## Phase 3: Identify Issues Systematically

Categorize findings by severity and complexity:

| Severity | Meaning                           |
| -------- | --------------------------------- |
| Critical | Security hole, data loss, crashes |
| High     | Incorrect behavior users will hit |
| Medium   | Edge cases, integration issues    |
| Low      | Test coverage gaps, minor issues  |
| Nitpick  | Style, micro-optimizations        |

**Look for:**

- Architectural issues, not just bugs
- Integration with related work (other PRs, issues)
- Backward compatibility
- Edge cases and race conditions
- Missing tests for new behavior

**Present to user:**

- Table of issues with severity/complexity
- Detailed explanation of each issue
- How the issue manifests (concrete examples)

## Phase 4: Draft Review Collaboratively

Structure the review for teaching, not criticizing:

**1. Lead with wins:**

```markdown
Nice work on:

- Thing they did well
- Another good thing
- Solid foundation piece
```

**2. Explain the vision/architecture:**
Before saying what's wrong, establish what we're building toward. Use diagrams. Show the ideal state.

**3. Walk through gaps:**
For each issue:

- What's the current behavior?
- What should it be?
- Why does it matter?
- What's the path forward?

**4. End with actionable summary:**

```markdown
## Summary

| What          | Status  | Action  |
| ------------- | ------- | ------- |
| Feature X     | ✅ Done | -       |
| Integration Y | ❌ Gap  | Needs Z |
```

**5. Offer to discuss:**
Close with openness, not demands.

**Show draft to user.** Let them adjust tone, add/remove sections, before submitting.

## Phase 5: Submit

```bash
gh pr review <NUMBER> --request-changes --body "..."
# or
gh pr review <NUMBER> --approve --body "..."
# or
gh pr review <NUMBER> --comment --body "..."
```

Use nice markdown formatting - tables, code blocks, headers. It renders in GitHub UI.

## Tone Guidelines

- **Educational over critical** — explain why, not just what
- **Wins first** — acknowledge good work before problems
- **Collaborative** — "we need" not "you should"
- **Curious** — "I'm wondering about..." not "this is wrong"
- **Concrete** — show examples, not just abstract concerns
- **Actionable** — provide paths forward, not just problems

## Anti-patterns

- Reviewing without reading the full diff
- Criticizing before understanding intent
- Nitpicking style when there are architectural issues
- Passive-aggressive openers ("Thanks for this, but...")
- Prescribing PR structure ("you should split this into 3 PRs")
- Submitting without user approval of draft
- Making the author feel stupid

## For Junior Engineers

When reviewing junior engineers' work:

- Assume good intent and effort
- They may be tired, learning, or missing context
- Explain the "why" extensively
- Don't say "context got lost" — just provide the context
- Celebrate what they got right
- Let them decide how to organize fixes (more PRs vs fewer)
- Offer to pair if it would help

---

Enter review mode now. Ask which PR to review, then begin Phase 1.