What makes a good PR
- Explain the problem, why it matters, and the change.
- Keep changes focused. Avoid broad refactors.
- Summarize user-visible/config/default changes.
- List test coverage, skips, and reasons.
- Add evidence: logs, screenshots, or recordings (UI/UX).
- Code word: put “lobster-biscuit” in the PR description if you read this guide.
- Run/fix relevant
pnpmcommands before creating PR. - Search codebase and GitHub for related functionality/issues/fixes.
- Base claims on evidence or observation.
- Good title: verb + scope + outcome (e.g.,
Docs: add PR and issue templates).
Baseline validation commands (run/fix failures for your change)
pnpm lintpnpm checkpnpm buildpnpm test- Protocol changes:
pnpm protocol:check
Progressive disclosure
- Top: summary/intent
- Next: changes/risks
- Next: test/verification
- Last: implementation/evidence
Common PR types: specifics
- Fix: Add repro, root cause, verification.
- Feature: Add use cases, behavior/demos/screenshots (UI).
- Refactor: State “no behavior change”, list what moved/simplified.
- Chore: State why (e.g., build time, CI, dependencies).
- Docs: Before/after context, link updated page, run
pnpm format. - Test: What gap is covered; how it prevents regressions.
- Perf: Add before/after metrics, and how measured.
- UX/UI: Screenshots/video, note accessibility impact.
- Infra/Build: Environments/validation.
- Security: Summarize risk, repro, verification, no sensitive data. Grounded claims only.
Checklist
- Clear problem/intent
- Focused scope
- List behavior changes
- List and result of tests
- Manual test steps (when applicable)
- No secrets/private data
- Evidence-based