メニュー
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
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SOC 職業分類に基づく
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/Blazemeter/claude-base --skill summarize-prコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
Use when a team wants to apply the Constraint Engineering guideline to a feature or repo — audits the current repo against an 8-item build checklist (spec-first, small checked steps, right-sized models, fast checks, an independent reviewer, isolated workspaces, hard safety rules, tracked outcomes), and generates copy-ready, stack-adapted template files. Trigger phrases — "apply constraint engineering", "help me write a spec for this feature", "audit this repo against the constraint engineering checklist", "set up an independent AI reviewer", "is this repo AI-SDLC S2 or S3 ready".
Produce a Design Rationale section for a design/spec/architecture artifact — justifying OOP/SOLID application, which design pattern(s) were considered and chosen (or why none applies), and which collection/data-structure was picked for each non-trivial data need, with the complexity/performance tradeoff that justifies it. Asks the developer clarifying questions when a structural choice (concurrency, cardinality, mutability, ordering, hot-path-vs-cold-path) is a genuine judgment call, rather than guessing. Language-agnostic — works for Java, Python, JavaScript/TypeScript, or any other stack. Use whenever a pipeline is about to lock in a design/spec for non-trivial work (new module, service, class hierarchy, data pipeline), or when a developer explicitly asks for a design/architecture review, "why this data structure", or "apply SOLID/design patterns here". Do NOT use for one-line fixes or purely mechanical changes with no structural decisions to make.
File or update a documentation-planning JIRA task for a customer-facing feature, using the documentation team's standard template. Idempotent create-or-update — safe to run early (draft a DOC-ready ticket from the specs/design to guide development) and again at finalize (reconcile the description against what was actually shipped). For FEATURE or USER-FACING work the skill first asks once whether the change needs customer-facing documentation, and only creates the ticket if it does. Also use when a developer explicitly asks to "create a doc task", "file a docs ticket", "DOC-ready ticket", "update the doc task", or hand work off to the documentation team. Do NOT use for pure refactors, internal-only fixes, or build/dependency chores.
| name | summarize-pr |
| description | 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 |
| allowed-tools | Bash(gh *), Read |
| effort | low |
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.
https://github.com/<org>/<repo>/pull/123.gh CLI installed and authenticated. If gh auth status fails, tell the user to run gh auth login and stop.gh token must have repo access.Resolve the PR identifier.
<org>/<repo> and number from /<org>/<repo>/pull/<n>.#<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.statusCheckRollup entry with conclusion != "SUCCESS" and not in ["SKIPPED", "NEUTRAL"] → name the check.mergeable == "CONFLICTING" → flag the merge conflict.Produce the summary in the exact format below.
## 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">
gh pr view JSON output to the user — extract the fields and present the summary above.….