| name | review-pr |
| description | Create a structured integration and review plan for a Pull Request |
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 "
- "lets work on pr "
- "lets take a look at pr "
Workflow
When triggered, you MUST follow these exact steps:
- 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.
- 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).
- 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 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:
_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.