Write commit messages and PR descriptions that follow a consistent team convention: imperative subject under 72 characters, explain what changed and why (not how), branch-naming prefixes (feature/fix/chore), and one logical change per PR. Use when the user asks to "write a commit message for this", "draft a PR description", or is about to open a PR. Do NOT use to decide WHETHER a change should be split into multiple PRs on code-quality grounds — use code-review for that judgment.

# PR & commit conventions Write commit messages and PR descriptions to one consistent team convention. ## When to use - "Write a commit message for this", "draft a PR description", or the user is about to open a PR and wants the message/description drafted from the diff or a description of the change. ## Do NOT use for - Deciding whether a diff should be split into multiple PRs — that's a code-review judgment call, not a formatting one. ## Commit message convention - **Subject line:** imperative mood, under 72 characters. "Fix webhook retry bug", not "Fixed a bug where webhooks would sometimes retry" or "Fixes webhook retry". - **Body (optional):** explain *what* changed and *why* — not *how*. The diff already shows how; the message should carry context the diff can't: the bug's symptom, the tradeoff made, the ticket/issue it closes. - One logical change per commit where practical. A commit that mixes a feature and an unrelated cleanup makes `git log` and `git bisect` less useful for everyone later. ## Branch naming - `feature/short-description` — new functionality. - `fix/short-description` — bug fixes. - `chore/short-description` — deps, config, docs, tooling. - All lowercase, kebab-case, no spaces. ## PR description convention - **Title:** same imperative-mood, <72-char convention as a commit subject. - **Summary:** 1-3 bullets on what changed and why — the reviewer should understand the change's purpose before reading a single line of diff. - **Test plan:** how this was verified — manual steps, new/updated tests, or both. A PR with no test plan is a PR asking the reviewer to guess. - One logical change per PR — same reasoning as commits, at a coarser grain. If the diff does two unrelated things, say so and offer to split it. ## Examples **Commit message:** ``` Fix Stripe webhook silently swallowing payment_failed events payment_failed events returned 200 without updating subscription status, so failed payments never surfaced. Now updates status and logs the event. ``` **PR title:** `Add tier-based expiry for public documents` **PR summary:** - Public documents now expire based on the publisher's tier (anon 24h, free-account 72h, Pro 30d, Pro Plus permanent) instead of never expiring. - Expiry is computed at publish time and enforced by a nightly cron sweep. **Test plan:** added Vitest coverage for the tier-to-expiry mapping; manually published one doc per tier and confirmed the stored expiry matches.