← ClaudeAtlas

craft-backendlisted

The Craftsman standard for building and reviewing backend code — API routes/endpoints, rate-limiting middleware on routes, request validation, the authentication boundary, service/business logic, error handling, third-party integrations, and background jobs. Use this WHENEVER the work touches the server side in any form: adding or reviewing a route, validating input, authenticating a request, tracing a 500, writing a service layer, wiring an integration, or enqueueing or handling a job (job scheduling configuration → see craft-infra). Trigger even when the user only says "add an endpoint", "validate this input", "why is this returning 500", or "secure this route" without naming a framework. Owns in-app route rate-limit *middleware* (mount order, keying, 429); abuse-defense *policy* (login/brute-force) → craft-security; platform/edge capacity throttling → craft-infra; LLM spend/token limits on model routes → craft-ai. Authorization *policy* (per-resource authZ, IDOR/tenant scoping) and secrets belong to craft-
atifgul99/craftsman-marketplace · ★ 1 · API & Backend · score 65
Install: claude install-skill atifgul99/craftsman-marketplace
# Backend Craft This skill encodes one engineer's standard for building reliable, secure backend code, applied the same way across every repo. The **method and opinions** live here; the **specifics** (which framework, which ORM, which auth provider, which error envelope shape) are discovered from the target repo — never hardcoded, never assumed. ## Operating principle — discover before you build Every repo already has conventions. Spend two minutes reading what exists so you extend the patterns rather than introduce a second style: - `package.json` / lockfile → what framework is in use (Next.js API routes, Express, Fastify, NestJS, Hono)? - Grep for an existing route handler, a validation call, and an error-response helper — understand the shape before adding to it. - Grep for the auth layer (Clerk, NextAuth, JWT middleware, session cookie) and find where tenant or user context is resolved. - Find the error-response helper or the established error envelope — every new route should return the same shape. State what you found, then propose the smallest set of additions that fits cleanly into those patterns. ## The request lifecycle (build in this order) 1. **Auth & context** — authenticate the caller and resolve tenant/user context before touching anything else. A request that isn't authenticated or can't be scoped to the right tenant must be rejected immediately, not after a DB round-trip. See `references/auth.md`. **`auth.md` owns authN/context only —