github-pr-workflow

Prepares GitHub pull requests with clean branches, structured descriptions, and review replies.

Updated Jun 16, 2026
One-click install
npx skills add https://github.com/adamtpang/summon.company --skill github-pr-workflow-adamtpang
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: github-pr-workflow
Source: https://github.com/adamtpang/summon.company/tree/main/packages/skills-catalog/catalog/bundled/software-development/github-pr-workflow
Command: npx skills add https://github.com/adamtpang/summon.company --skill github-pr-workflow-adamtpang

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Pull requests often stall because of messy commit history, vague titles, missing verification evidence, or unanswered review comments. This Skill guides you through preparing a GitHub pull request that a reviewer can land without follow-up clarifying questions. ## Core Features & Use Cases - Branch Hygiene: Rebase onto the target base, squash WIP commits into reviewable units, and confirm tests, typecheck, and lint pass before opening. - Structured PR Body: Enforces a Summary, Implementation notes, Verification, and Risk/rollback template, with screenshots required for UI changes. - Review Comment Handling: Reply to every comment, push fixes as new commits during active review, and re-request review explicitly. - Use Case: You finished a feature adding CSV export to a reports table. Use this Skill to squash your commits, write an imperative title, document verification steps with screenshots, and respond to reviewer feedback until merge. ## Quick Start Help me prepare a GitHub pull request for my current feature branch, including the title, body, and verification notes.

Frequently Asked Questions about github-pr-workflow

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

FAQPage Schema
How do I write a good GitHub pull request description?

Structure the PR body with Summary, Implementation notes, Verification, and Risk and rollback sections. Include the exact commands you ran, screenshots for UI changes, and revert steps so reviewers can land the change without follow-up questions.

How should I respond to code review comments on GitHub?

Reply to every comment, even with just "fixed in <commit-sha>", so reviewers are not left guessing. Push fixes as new commits during active review rather than amending, and re-request review explicitly after pushing changes.

What should a pull request title look like?

Use imperative mood under 70 characters, leading with the user-visible change rather than the file touched. Follow any issue prefix convention the repo uses, such as PAP-1234:, and omit trailing periods.

When should I not open a pull request?

Do not open a PR when the change is not yet functionally complete, since draft PRs that bounce on review create noise. Also avoid forcing GitHub conventions onto repositories hosted on non-GitHub forges.

Should I squash commits before opening a pull request?

Squash WIP commits into reviewable units, preferring one commit per logical change. Do not force one commit per PR when the work is genuinely multi-step, and remove debug prints and untracked TODO markers first.