Menu
Create a structured integration and review plan for a Pull Request
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Run comprehensive Rust code quality checks including compilation, linting, documentation, and tests. Use after completing code changes and before creating commits.
Enforce the "Clean Imports over Inline Absolute Paths" rule by removing inline crate:: prefixes and adding proper use statements.
Rules and guidelines for creating well-formatted commit messages, including 72-char limits, scope prefixes, and trailer blocks for tasks, PR closing, and attribution.
Zero-allocation string building strategies. Use when formatting strings, generating ANSI codes, or writing hot loops to avoid heap allocations and Formatter state machine overhead.
Run clippy linting, enforce comment punctuation rules, format code with cargo fmt, and verify module organization patterns. Use after code changes and before creating commits.
Standard for writing structured tracing logs behind debug flags.
| name | review-pr |
| description | Create a structured integration and review plan for a Pull Request |
Use this skill when the user runs the /review-pr <number> slash command or uses any of
these natural language triggers:
When triggered, you MUST follow these exact steps:
gh pr view <number> to read the PR description.gh pr diff <number> to see the exact code changes and files touched.task/pr-<number>-fix.md.prettier --write task/pr-<number>-fix.md to format the new file.antigravity-ide task/pr-<number>-fix.md to open the file for the user.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`
main
branch.