How do I install the Summarize Pr skill?

Run npx skillmds@latest add blazemeter/summarize-pr in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Summarize Pr safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Summarize Pr?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Summarize Pr free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Summarize Pr?

Blazemeter (@blazemeter) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Summarize Pr by blazemeter — Agent Skill

Name: Summarize Pr
Author: Blazemeter

Summarize Pr

Summarize a GitHub pull request — purpose, key changes, review state, CI status, and outstanding blockers. Use when the user pastes a PR URL (github.com/<org>/<repo>/pull/<n>), references a PR by number (e.g. "PR

Blazemeter cbc3cd6 2 files · 4.8 KB Updated Sep 17, 2026

File contents

summarize-pr

Produce a concise, structured summary of a GitHub pull request. The goal is to let the user decide what to do about the PR without opening the browser — purpose, scope, review state, blockers, recommendation.

When to use

User pastes a PR URL like https://github.com/<org>/<repo>/pull/123.
User refers to a PR by number — "summarize PR 123", "what's in 123", "is 123 ready".
User asks for the state of a PR they own or are reviewing.

When NOT to use

Reviewing a local diff or working tree — use a code-review skill.
Deep CI failure investigation — use a CI-investigation skill.
Non-GitHub PRs (GitLab merge requests, Bitbucket PRs).

Preconditions

gh CLI installed and authenticated. If gh auth status fails, tell the user to run gh auth login and stop.
For private repos, the user's gh token must have repo access.

Workflow

Resolve the PR identifier.
- Full URL → parse <org>/<repo> and number from /<org>/<repo>/pull/<n>.
- Bare #<n> or PR <n> → run gh repo view --json nameWithOwner -q .nameWithOwner to get current repo. If the user is not in a git repo, ask which repo they mean.

Fetch metadata in one call.

gh pr view <n> --repo <org>/<repo> --json \
  number,title,author,state,isDraft,mergeable,reviewDecision,additions,deletions,changedFiles,body,reviews,statusCheckRollup,comments,headRefName,baseRefName

Fetch the diff, bounded.
```
gh pr diff <n> --repo <org>/<repo> | head -500
```
If changedFiles > 30 or additions + deletions > 1500, skip the full diff — list filenames instead and call out the size.
Identify blockers.
- reviewDecision == "CHANGES_REQUESTED" → list each "REQUEST_CHANGES" review with its body.
- Any statusCheckRollup entry with conclusion != "SUCCESS" and not in ["SKIPPED", "NEUTRAL"] → name the check.
- Unresolved review threads → count them.
- mergeable == "CONFLICTING" → flag the merge conflict.
Produce the summary in the exact format below.

Output format

## PR #<num> — <title>

- **Author:** @<author> · **State:** <state><draft-tag> · **Branch:** `<head>` → `<base>`
- **Size:** +<additions>/-<deletions> across <N> files
- **Review:** <reviewDecision> · <N approvals> · <N changes requested> · <N unresolved threads>
- **CI:** <N passing> · <N failing> · <N pending>

## Purpose
<One paragraph from PR body, or "(empty)" if no description>

## Key changes
- <Bullet per meaningful change. Group small file edits. Reference exact file paths.>

## Outstanding concerns
<Numbered list of blockers. If none, write "None — this PR has no blocking issues.">

## Recommendation
<One of: "Ready to merge", "Needs <comma-separated blockers>", "Discussion needed", "Draft — not yet ready for review">

Notes

Don't paste the full gh pr view JSON output to the user — extract the fields and present the summary above.
Stick to verifiable facts from the API. Do not speculate about whether changes are "good" or "bad" — that's a code review, not a summary.
If the PR has > 30 files, mention the top 5 files by lines changed; don't enumerate all.
Truncate any single field longer than ~300 chars in the output, with ….

A code-review skill (different scope) — focuses on correctness of the diff, not the PR state.
A CI-investigation skill — drills into a specific failing check.

---name: summarize-prdescription: Summarize a GitHub pull request — purpose, key changes, review state, CI status, and outstanding blockers. Use when the user pastes a PR URL (github.com/<org>/<repo>/pull/<n>), references a PR by number (e.g. "PR---# summarize-prProduce a concise, structured summary of a GitHub pull request. The goal is to let the user decide *what to do about the PR* without opening the browser — purpose, scope, review state, blockers, recommendation.## When to use- User pastes a PR URL like `https://github.com/<org>/<repo>/pull/123`.- User refers to a PR by number — "summarize PR 123", "what's in 123", "is 123 ready".- User asks for the *state* of a PR they own or are reviewing.## When NOT to use- Reviewing a local diff or working tree — use a code-review skill.- Deep CI failure investigation — use a CI-investigation skill.- Non-GitHub PRs (GitLab merge requests, Bitbucket PRs).## Preconditions- `gh` CLI installed and authenticated. If `gh auth status` fails, tell the user to run `gh auth login` and stop.- For private repos, the user's `gh` token must have repo access.## Workflow1. **Resolve the PR identifier.** - Full URL → parse `<org>/<repo>` and number from `/<org>/<repo>/pull/<n>`. - Bare `#<n>` or `PR <n>` → run `gh repo view --json nameWithOwner -q .nameWithOwner` to get current repo. If the user is not in a git repo, ask which repo they mean.2. **Fetch metadata in one call.** ```bash gh pr view <n> --repo <org>/<repo> --json \ number,title,author,state,isDraft,mergeable,reviewDecision,additions,deletions,changedFiles,body,reviews,statusCheckRollup,comments,headRefName,baseRefName ```3. **Fetch the diff, bounded.** ```bash gh pr diff <n> --repo <org>/<repo> | head -500 ``` If `changedFiles` > 30 or `additions + deletions` > 1500, skip the full diff — list filenames instead and call out the size.4. **Identify blockers.** - `reviewDecision == "CHANGES_REQUESTED"` → list each "REQUEST_CHANGES" review with its body. - Any `statusCheckRollup` entry with `conclusion != "SUCCESS"` and not in `["SKIPPED", "NEUTRAL"]` → name the check. - Unresolved review threads → count them. - `mergeable == "CONFLICTING"` → flag the merge conflict.5. **Produce the summary** in the exact format below.## Output format```## PR #<num> — <title>- **Author:** @<author> · **State:** <state><draft-tag> · **Branch:** `<head>` → `<base>`- **Size:** +<additions>/-<deletions> across <N> files- **Review:** <reviewDecision> · <N approvals> · <N changes requested> · <N unresolved threads>- **CI:** <N passing> · <N failing> · <N pending>## Purpose<One paragraph from PR body, or "(empty)" if no description>## Key changes- <Bullet per meaningful change. Group small file edits. Reference exact file paths.>## Outstanding concerns<Numbered list of blockers. If none, write "None — this PR has no blocking issues.">## Recommendation<One of: "Ready to merge", "Needs <comma-separated blockers>", "Discussion needed", "Draft — not yet ready for review">```## Notes- Don't paste the full `gh pr view` JSON output to the user — extract the fields and present the summary above.- Stick to verifiable facts from the API. Do not speculate about whether changes are "good" or "bad" — that's a code review, not a summary.- If the PR has > 30 files, mention the top 5 files by lines changed; don't enumerate all.- Truncate any single field longer than ~300 chars in the output, with `…`.## Related- A code-review skill (different scope) — focuses on correctness of the diff, not the PR state.- A CI-investigation skill — drills into a specific failing check.

Frequently asked questions