Check out CLAUDE.md for additional context on project file structure and general feature development.
Read the Backend Code Quality Guide for any change under backend/, and check your work against it before reporting the task done. Features, refactors, bug fixes, and reviews all count.
It is a short, deliberately non-exhaustive floor: error messages users can understand (and no pointless 500s), validation on every API input, correct pagination when calling third-party APIs, no deadlock conditions on a small connection pool, and REST-aligned API interfaces.
Treat that list as a summary of the guide's current contents, not as a condition for reading it. A change that does not look like any of those topics still gets checked, because the guide grows and because the items apply in places they are not obviously about (a bug fix that adds a query inside an existing transaction, a refactor that moves a third-party list call).
Some of it needs judgment rather than a mechanical check. The deadlock rules cannot be caught by testing one request at a time. And a design that breaks REST should be raised with the author, with the conforming alternative proposed, rather than implemented silently or quietly "fixed" (some deviations are deliberate).
When writing or editing documentation in docs/, follow the Documentation Style Guide. It covers writing for users (not implementers), Mintlify component usage, cross-referencing, page structure, and more.
When building frontend UI, follow DESIGN.md for the v3 design system — colors, typography, components, and voice.
- Never create a GitHub issue.
- When creating a pull request, use and fully complete the repository's
.github/pull_request_template.mdtemplate.