github-pr-workflow

1# GitHub Pull Request Workflow
2 
3Ship 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 
32Use this structure:
33…