# Review Pr

> Create a structured integration and review plan for a Pull Request

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

---


# PR Review and Integration Workflow

Use this skill when the user runs the `/review-pr <number>` slash command or uses any of
these natural language triggers:

- "lets review pr <number>"
- "lets work on pr <number>"
- "lets take a look at pr <number>"

## Workflow

When triggered, you MUST follow these exact steps:

1. **Information Gathering**
   - Run `gh pr view <number>` to read the PR description.
   - Run `gh pr diff <number>` to see the exact code changes and files touched.
2. **Task File Generation**
   - Create a new markdown task file at `task/pr-<number>-fix.md`.
   - The file MUST follow the template structure below, organizing the PR into distinct,
     actionable chunks (phases/headings).
3. **Format & Present**
   - Automatically run `prettier --write task/pr-<number>-fix.md` to format the new file.
   - Run `antigravity-ide task/pr-<number>-fix.md` to open the file for the user.
   - Ask the user to **manually review and explicitly approve** the plan before any
     implementation begins.

## Task File Template

> **Canonical Example:** See [task/done/pr-455-fix.md](../../../../task/done/pr-455-fix.md) for a complete, canonical example of a well-written PR review task file.

When creating `task/pr-<number>-fix.md`, structure it exactly like this:

```md
_Task: PR <number> Integration (<short description>)_

# User Story & Context

## Problem

[Describe the user-facing problem that this PR is attempting to solve. What triggers the
bug?]

## Root Cause

[Describe the underlying technical root cause. Why is this happening in the codebase?]

## Expected Behavior

[Describe what the expected behavior should be after the fix.]

# Overview

[Brief summary of the PR, author, and what problem it solves.]

# Implementation Plan

We will process each of the action items iteratively using the following loop:

1. **Implementation:** Write the specific code changes for the current heading.
2. **Local Testing:** Run `./check.fish --check` and, where applicable, test
   functionality.
3. **Mandatory Manual Review:** You (the user) will manually review the specifically
   touched files before the heading is marked as checked `[x]`.

_(Once all headings are successfully implemented and checked off, we will proceed to final
verification and cleanup.)_

## Phase 1: [Name of first distinct fix/feature]

[Brief context of the problem and the specific fix.]

- _Context:_ [Why this change is needed.]
- _The Fix:_ [What the code actually does.]
- _File(s) Touched:_ [List the files.]

## Phase 2: [Name of next fix/feature...]

...

## Final Verification & Cleanup

- [ ] Verify full test suite coverage using `./check.fish --full`.
- [ ] When ready to merge, invoke the `/merge-pr` slash command to push the changes,
      optionally update the author, and cleanly merge to `main`.
- [ ] Update the current meta-task (e.g. `task/prepare-vX.Y.Z-meta-task.md`) to check off
      PR #<number>.
- [ ] **Mandatory manual review:** Verify every file modified in this task for correct
      implementation and ensure no regressions.
  - [ ] `path/to/modified_file_1.rs`
  - [ ] `path/to/modified_file_2.rs`
  - [ ] `task/prepare-vX.Y.Z-meta-task.md`
```

## Critical Rules

- Do NOT merge or apply the PR automatically. The purpose of this workflow is to rewrite
  or cherry-pick the fixes systematically while validating them against the current `main`
  branch.
- Break down the PR diff into logical, self-contained action items rather than just one
  giant block.

