Prepare a pull request

A pull request should present one reviewable concern with evidence that matches its affected behavior.

Prepare the branch

Rebase on the current main branch before opening the pull request. Resolve conflicts by preserving current owners and contracts, then rerun checks affected by the resolution.

Inspect the commit list, full diff, untracked files, generated changes, and artifact paths. Do not include screenshots, traces, local configuration, secrets, or unrelated working-tree changes.

Write the description

Use these sections:

• What: one or two sentences describing the behavior change.
• Why: the problem or issue being resolved.
• How: only when the design is not apparent from the diff.
• Testing: exact commands and outcomes, plus tested and untested affected platforms.
• Evidence: for UI changes, screenshots of every new or changed state in the dark theme, on both desktop (1280×800) and mobile (390×844), captured against synthetic test data. Attach them to the pull request with gh pr comment <number> --attach './shot.png#Alt text' or by dragging them into the description, never as committed files.
• Notes: migrations, secrets handling, infrastructure, public API changes, limitations, or follow-ups.

Use Closes #123 when the pull request resolves an issue and Refs #123 for related work. Keep the title in Conventional Commit form.

Hand off honestly

Open the pull request as a draft and mark it ready only when it can be merged as it stands: every check is green, the review is finished, and nothing is pending. Return it to draft while new work is in progress. Call out failed, retried, skipped, and unavailable checks. Mention changes to migrations, security boundaries, infrastructure, configuration, or public APIs so reviewers can focus appropriately. Do not merge the pull request as part of preparation.

Read validate a change and branches and commits before publishing the branch.