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