summarize-prs

Consolidates multiple GitHub pull requests into one plain-language completion report for non-engineers.

Updated Dec 25, 2021
One-click install
npx skills add https://github.com/kotahashihama/dotfiles --skill summarize-prs-kotahashihama
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: summarize-prs
Source: https://github.com/kotahashihama/dotfiles/tree/main/home/.claude/skills/summarize-prs
Command: npx skills add https://github.com/kotahashihama/dotfiles --skill summarize-prs-kotahashihama

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When several pull requests together resolve one issue, stakeholders outside engineering (QA, planners, issue reporters) cannot read PR descriptions or diffs. This Skill merges multiple PRs into a single prose report written in non-technical vocabulary, organized by symptom, cause, and fix rather than by PR number. ## Core Features & Use Cases - Cross-PR consolidation: Folds multiple PRs into one narrative grouped by screen, feature, or symptom type instead of PR boundaries. - Audience-adapted vocabulary: Translates internal code names into the on-screen names readers actually see, with adjustable depth via the --for option. - Diff-verified reporting: Cross-checks PR bodies against actual diffs using gh pr view and gh pr diff so the report reflects what really changed. - Use Case: After shipping three PRs that fix a card-display bug, generate one message for the issue reporter describing what was broken, why, and which screens and operations to verify. ## Quick Start Ask the assistant to write a completion report summarizing PRs 101, 102, and 103 for a non-engineer stakeholder.

Frequently Asked Questions about summarize-prs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I summarize multiple pull requests into one report?

Pass the PR numbers or URLs as arguments, and the Skill fetches each PR's body and diff with gh pr view and gh pr diff, then folds them into one prose report grouped by symptom or feature rather than by PR number.

How to write a bug fix report for non-engineers from GitHub PRs?

The Skill translates internal code names into the on-screen names readers recognize, structures the text as symptom, cause, and fix, and avoids headings, tables, and formatting that may not render in the destination tool.

Does this Skill post the report to Slack or issue trackers?

No, it never posts anything. It outputs copy-paste-ready text in the conversation, and the user decides the destination, recipients, and any mentions.

Can I adjust the report for a technical audience?

Yes, the --for option changes how far internal vocabulary is opened up. For engineers in the same domain the Skill is unnecessary, since the PR description itself already serves that audience.

Why does the Skill check diffs instead of trusting PR descriptions?

PR bodies can diverge from reality: described fixes may be missing from the diff, and unmentioned fixes may be present. Cross-checking both directions prevents reporting changes that did not happen or omitting ones that did.

When should I not use this PR summarization approach?

Do not use it to write PR descriptions for reviewers, to explain implementation details, or to list your own PRs for personal tracking. Those cases belong to dedicated update, explanation, and listing workflows.