Pull Request Guide

Before you open a PR

• make the scope small enough to review in one pass
• link the issue, bug report, or problem statement
• confirm whether the change affects API shape, UI behavior, docs, or env setup

Required context

Every solid PR should explain:

• what changed
• why it changed
• what operators or users need to know
• how it was verified

Include these when relevant

• screenshots or recordings for UI changes
• curl or request examples for API changes
• env or deployment notes for self-hosting changes
• migration notes if routes, settings, or docs slugs changed

Verification checklist

• build the affected app or service
• verify any changed routes manually
• update docs or README when user-facing behavior changes
• call out anything you could not verify locally

Review quality

Prefer a PR that is easy to trust:

• coherent commit history
• no unrelated formatting churn
• clear file ownership
• no stale generated references left behind