Agent skill · writing content · paperclipai
github-pr-workflow
Prepare a GitHub pull request from a feature branch — branch hygiene, commit shape, title/body, verification notes, screenshots for UI work, and replies to review comments.
Why this skill is useful
Provides a structured approach to crafting GitHub pull requests, detailing specific formatting and content requirements that enhance clarity and review efficiency.
What it needs
About 3k tokens when loaded. Last updated 2026-08-07. 75,771 stars on the source repository.
What this skill does
GitHub Pull Request Workflow Ship a PR a reviewer can land without follow-up clarifying questions. The aim is high signal in the title and body, evidence the change works, and clean replies when feedback comes in. When to use You are about to open a PR for a change that is functionally complete. A reviewer left comments and you need to respond and push fixes. A PR has been open more than a day and needs to be brought back into shape (stale conflicts, missing description, missing verification). When not to use The change is not yet functionally complete. Finish the work first; draft PRs that bounce on review are noise. The repository uses a non-GitHub forge. Adjust to that forge's conventions; do not force GitHub-isms. Branch hygiene before opening Rebase or merge from the target base so the diff is current. Squash WIP commits into reviewable units. Prefer one commit per logical change; do not force one-commit-per-PR if the work is genuinely multi-step. Confirm tests, typecheck, and lint pass locally. Note any deliberate skips in the PR body. Remove debug prints, commented-out code, and TODO markers that are not tracked. PR title Imperative mood, under 70 characters. Lead with the user-visible change, not the file touched. Allow CSV export from reports table beats Update reports.tsx. If the repo uses an issue prefix convention (PAP-1234:, [security]), follow it. No trailing period. PR body Use this structure: Skip the Risk and rollback section only for clearly trivial PRs (typos, docs). Verification evidence Tests passing in CI is necessary, not sufficient. Reviewers also need to know the change behaves correctly end to end. For UI work, include screenshots of the golden path and one edge case. Tag dark and light mode if the project supports both. For migrations, include a dry-run plan and reversal steps. For performance changes, include a before/after measurement, not adjectives. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills paperclipai/github-pr-workflow