Contributing

Development Workflow

1. Create a feature branch off staging
2. Make your changes
3. Test locally with pnpm dev
4. Run pnpm lint and pnpm format before pushing
5. Open a PR against staging

Branch Naming

Use a prefix that describes the type of change:

Prefix	Use for
feature/	New functionality (e.g. feature/review-photos)
fix/	Bug fixes (e.g. fix/map-zoom-reset)
chore/	Refactors, deps, config (e.g. chore/upgrade-next)

Scoping Your Work

On GitHub, the Pull Request is the unit of review (not individual commits). Each PR should focus on one concern — a single feature, bug fix, or refactor.

• Aim for PRs under ~300 lines changed. Smaller PRs get reviewed faster and are less likely to introduce bugs.
• If a task is large, break it into sequential PRs that each make sense on their own.
• It's fine to have multiple commits within a PR — they'll be squashed on merge.

Commit Messages

Write short, imperative summaries:

Add accessibility score to place card
Fix map marker click handler on mobile
Update Drizzle config for PostGIS types

If the "why" isn't obvious, add a blank line and a short body explaining context.