Run any Skill in Manus with one click

review-pr

Stars0

Forks0

UpdatedJune 11, 2026 at 07:13

Review a GitHub pull request from a link or PR number, using the linked Jira ticket and PR body for context. Use when: reviewing a PR, giving feedback on a pull request, code review of someone else's PR, looking over a PR.

Installation

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.

Run Skill in Manus

Source

lanesawyer

lanesawyer/ai-config

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	review-pr
description	Review a GitHub pull request from a link or PR number, using the linked Jira ticket and PR body for context. Use when: reviewing a PR, giving feedback on a pull request, code review of someone else's PR, looking over a PR.
argument-hint	PR link or number (e.g. https://github.com/org/repo/pull/123 or org/repo#123)

Review PR

Read a pull request and provide a focused code review. This is a review only — do not run tests, linters, formatters, or any static analysis. Read the code and reason about it.

Do not post anything to GitHub — no review, no comments, no approvals, no status changes. The output is for the user to read and evaluate themselves. Never write to the PR even if it seems convenient.

Step 1: Read the PR

Follow the read-pr skill, passing the argument (link, org/repo#123, or number) if one was given. This resolves the PR and fetches its title, body, branches, diff, and review threads.

Skim existing review comments for context so you don't duplicate points already raised.

Step 2: Get ticket context

Follow the jira-read-ticket skill, passing the PR title, body, and branch name so it can extract a Jira key. Use the resulting summary to judge whether the PR actually does what it's supposed to.

If jira-read-ticket finds no ticket, rely on the PR body alone for intent. Don't ask the user for a ticket — just note that context came only from the PR description.

Step 3: Review the code

Read the diff carefully and evaluate:

Correctness — bugs, logic errors, off-by-one, null/undefined handling, race conditions, incorrect edge-case behavior
Intent match — does the change actually satisfy the ticket / PR description? Anything missing or out of scope?
Clarity & maintainability — naming, structure, dead code, needless complexity
Reuse & consistency — duplicated logic, ignoring existing patterns or helpers in the codebase
Risk — security, data integrity, breaking changes, error handling

Read surrounding files when the diff alone doesn't give enough context to judge a change. Do not run any tooling.

Step 4: Write the review

Output a review organized by severity. Reference findings as path/to/file.ts:line.

## Review: <PR title> (#<number>)

**Context:** <one line — ticket key + what the PR is meant to do>

### 🔴 Blocking
- `src/foo.ts:42` — <issue and why it matters>

### 🟡 Should fix
- `src/bar.ts:17` — <issue and suggested change>

### 🔵 Nits / optional
- `src/baz.ts:5` — <minor suggestion>

### ✅ Looks good
- <brief note on what's done well, if anything stands out>

Omit any severity section that has no findings.
If nothing is blocking, say so clearly.
Do not post anything to GitHub under any circumstances — this is a review for the user to read and evaluate. If they later want it posted, they will explicitly ask.

More from this repository

same repository

setup-astro-repo

lanesawyer/ai-config

Scaffold a web repo with pnpm, Astro, and astro-bulma — plus Drizzle when the site needs a database — including package.json scripts for build/lint/test/fmt (and db:migrate when db-backed). Use when: setting up a new Astro project, scaffolding a web repo, initializing the standard web stack. Building block for create-website.

2026-07-100

add-ci-workflow

lanesawyer/ai-config

Add a GitHub Actions CI workflow running build, lint, test, and fmt checks with pnpm. Use when: adding CI, setting up GitHub Actions checks, adding a build/lint/test workflow. Building block for create-website.

2026-07-070

create-website

lanesawyer/ai-config

Create a new website end-to-end: Astro repo with pnpm/astro-bulma; GitHub Pages for static sites, or Turso + Fly.io when the site needs a database; GitHub Actions for CI and deploy. Use when: creating a new website, spinning up a new web project, new site, scaffolding a static or full-stack Astro project.

2026-07-060

fly-new-app

lanesawyer/ai-config

Create a new app on Fly.io for the current project without deploying it, generating fly.toml and a Dockerfile. Use when: creating a Fly.io app, setting up Fly hosting, fly launch. Building block for create-website.

2026-07-060

gh-pages-deploy-workflow

lanesawyer/ai-config

Add a GitHub Actions workflow that builds a static site and deploys it to GitHub Pages, with an optional custom domain. Use when: deploying a static site, GitHub Pages hosting, static site with a custom domain. Building block for create-website.

2026-07-060

fly-deploy-workflow

lanesawyer/ai-config

Add a GitHub Actions workflow that deploys to Fly.io on merge to main, with db migrations run as a Fly release_command. Use when: adding a deploy workflow, deploying on merge, setting up continuous deployment to Fly.io. Building block for create-website.

2026-07-060

name	review-pr
description	Review a GitHub pull request from a link or PR number, using the linked Jira ticket and PR body for context. Use when: reviewing a PR, giving feedback on a pull request, code review of someone else's PR, looking over a PR.
argument-hint	PR link or number (e.g. https://github.com/org/repo/pull/123 or org/repo#123)

Review PR

Read a pull request and provide a focused code review. This is a review only — do not run tests, linters, formatters, or any static analysis. Read the code and reason about it.

Step 1: Read the PR

Follow the read-pr skill, passing the argument (link, org/repo#123, or number) if one was given. This resolves the PR and fetches its title, body, branches, diff, and review threads.

Skim existing review comments for context so you don't duplicate points already raised.

Step 2: Get ticket context

Follow the jira-read-ticket skill, passing the PR title, body, and branch name so it can extract a Jira key. Use the resulting summary to judge whether the PR actually does what it's supposed to.

If jira-read-ticket finds no ticket, rely on the PR body alone for intent. Don't ask the user for a ticket — just note that context came only from the PR description.

Step 3: Review the code

Read the diff carefully and evaluate:

Correctness — bugs, logic errors, off-by-one, null/undefined handling, race conditions, incorrect edge-case behavior
Intent match — does the change actually satisfy the ticket / PR description? Anything missing or out of scope?
Clarity & maintainability — naming, structure, dead code, needless complexity
Reuse & consistency — duplicated logic, ignoring existing patterns or helpers in the codebase
Risk — security, data integrity, breaking changes, error handling

Read surrounding files when the diff alone doesn't give enough context to judge a change. Do not run any tooling.

Step 4: Write the review

Output a review organized by severity. Reference findings as path/to/file.ts:line.

## Review: <PR title> (#<number>)

**Context:** <one line — ticket key + what the PR is meant to do>

### 🔴 Blocking
- `src/foo.ts:42` — <issue and why it matters>

### 🟡 Should fix
- `src/bar.ts:17` — <issue and suggested change>

### 🔵 Nits / optional
- `src/baz.ts:5` — <minor suggestion>

### ✅ Looks good
- <brief note on what's done well, if anything stands out>

Omit any severity section that has no findings.
If nothing is blocking, say so clearly.
Do not post anything to GitHub under any circumstances — this is a review for the user to read and evaluate. If they later want it posted, they will explicitly ask.