github-pr-workflow

Topics in the source

• GitHub Pull Request Workflow
• When to use
• When not to use
• Branch hygiene before opening
• PR title
• PR body
• Verification evidence
• Replying to review comments

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. 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). 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. 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. Imperative mood, under 70 characters. Lead with the user-visible change, not the file touched. Allow CSV export from reports table beats Update repor

This is an excerpt. Refer to the complete source and its current requirements.