github-pr-workflow
starsforks
How to install github-pr-workflow?
getpaperclipai/paperclip/github-pr-workflow
$npx -y skills add getpaperclipai/paperclip --skill github-pr-workflowPrepare 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.
SKILL.md
| 1 | # GitHub Pull Request Workflow |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | ## When to use |
| 6 | |
| 7 | - You are about to open a PR for a change that is functionally complete. |
| 8 | - A reviewer left comments and you need to respond and push fixes. |
| 9 | - A PR has been open more than a day and needs to be brought back into shape (stale conflicts, missing description, missing verification). |
| 10 | |
| 11 | ## When not to use |
| 12 | |
| 13 | - The change is not yet functionally complete. Finish the work first; draft PRs that bounce on review are noise. |
| 14 | - The repository uses a non-GitHub forge. Adjust to that forge's conventions; do not force GitHub-isms. |
| 15 | |
| 16 | ## Branch hygiene before opening |
| 17 | |
| 18 | - Rebase or merge from the target base so the diff is current. |
| 19 | - 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. |
| 20 | - Confirm tests, typecheck, and lint pass locally. Note any deliberate skips in the PR body. |
| 21 | - Remove debug prints, commented-out code, and `TODO` markers that are not tracked. |
| 22 | |
| 23 | ## PR title |
| 24 | |
| 25 | - Imperative mood, under 70 characters. |
| 26 | - Lead with the user-visible change, not the file touched. `Allow CSV export from reports table` beats `Update reports.tsx`. |
| 27 | - If the repo uses an issue prefix convention (`PAP-1234:`, `[security]`), follow it. |
| 28 | - No trailing period. |
| 29 | |
| 30 | ## PR body |
| 31 | |
| 32 | Use this structure: |
| 33 | |
| 34 | ```md |
| 35 | ## Summary |
| 36 | - 1–3 bullets describing what changed and why. |
| 37 | |
| 38 | ## Implementation notes |
| 39 | - Anything non-obvious in the diff: trade-offs, dropped alternatives, gotchas. |
| 40 | - Migration or config implications. |
| 41 | |
| 42 | ## Verification |
| 43 | - The exact commands or steps you ran. |
| 44 | - Screenshots or short clips for UI changes (required if pixels moved). |
| 45 | - Edge cases you exercised by hand. |
| 46 | |
| 47 | ## Risk and rollback |
| 48 | - What breaks if this is reverted, and how to revert cleanly. |
| 49 | ``` |
| 50 | |
| 51 | Skip the `Risk and rollback` section only for clearly trivial PRs (typos, docs). |
| 52 | |
| 53 | ## Verification evidence |
| 54 | |
| 55 | - Tests passing in CI is necessary, not sufficient. Reviewers also need to know the change behaves correctly end to end. |
| 56 | - For UI work, include screenshots of the golden path and one edge case. Tag dark and light mode if the project supports both. |
| 57 | - For migrations, include a dry-run plan and reversal steps. |
| 58 | - For performance changes, include a before/after measurement, not adjectives. |
| 59 | |
| 60 | ## Replying to review comments |
| 61 | |
| 62 | - Reply on every comment, even with just "fixed in <commit-sha>" — silent fixes leave the reviewer guessing. |
| 63 | - Push fixes as new commits while review is active; do not amend during review unless the reviewer agrees. |
| 64 | - If you disagree with feedback, say so with one sentence of rationale and let the reviewer decide. Don't escalate over comments. |
| 65 | - Re-request review explicitly after pushing changes. |
| 66 | |
| 67 | ## Merge checklist |
| 68 | |
| 69 | - All required checks green. |
| 70 | - All review comments resolved. |
| 71 | - PR title/body still accurate (update if scope changed mid-review). |
| 72 | - Linked issue moves to `in_review` or `done` per project convention. |
| 73 | - Delete the branch after merge unless it is a long-lived integration branch. |
| 74 | |
| 75 | ## Anti-patterns |
| 76 | |
| 77 | - PR description that says "see commits". Reviewers should not need to read the log. |
| 78 | - Mixing refactor and behavior change in the same PR with no separation in the body. |
| 79 | - "Address feedback" commits that bundle unrelated edits. One commit per round of feedback is fine; one commit for everything in flight is not. |
| 80 | - Force-pushing during active review without telling the reviewer. |
People who liked this also viewed
6 picksType
- caveman-commitUltra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. UsSkillsJul 2026
- git-guardrails-claude-codeSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- setup-pre-commitSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- resolving-merge-conflictsSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackSkillsJul 2026
- finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanupSkillsJul 2026
