building-backendslisted

# building-backends This is the backbone skill for backend work. Read it before writing any server code — it sets the defaults and the non-negotiables so every service comes out consistent, then hands off to the specific skills for the detailed procedures. If a rule here conflicts with a local repo convention, the repo wins; if it conflicts with nothing, follow it. ## First, understand before you build - **Read the existing code before adding to it.** Match the repo's framework, error model, layering, naming, and test style. A "correct" pattern that fights the codebase is the wrong pattern. Introducing a second way to do something the repo already does is a defect, not an improvement. - **Clarify the contract, not the implementation.** Know the inputs, outputs, error cases, who calls it, and the consistency/latency expectations before choosing a design. Most backend rework comes from building the wrong contract fast. - **Prefer boring.** Proven, readable, obvious solutions over clever ones. The backend runs unattended at 3am; optimize for the on-call engineer who has to understand it half-asleep, not for elegance. ## Architecture — the rules - **Layer with dependencies pointing inward.** `transport (http) → services (use-cases) → domain (entities/rules)`, and `services → repositories (I/O) → domain`. The domain imports nothing outward and does no I/O. If an import arrow points the wrong way, the design is broken. - **Handlers orchestrate, services decide, repositories do I