Enforce Backend Development Standards

This skill defines a non-negotiable backend architecture doctrine plus a risk-scoring gate for evaluating whether a change is safe to build. The Backend Feasibility & Risk Index (BFRI) scores a proposed change across five dimensions (1-5 each): Architectural Fit (does it follow routes -> controllers -> services -> repositories?), Business Logic Complexity, Data Risk (does it touch critical data paths or transactions?), Operational Risk (does it affect auth, billing, messaging, or infra?), and Testability. The formula BFRI = (Architectural Fit + Testability) - (Complexity + Data Risk + Operational Risk) produces a score from -10 to +10: 6-10 is Safe (proceed), 3-5 is Moderate (add tests and monitoring), 0-2 is Risky (refactor or isolate first), and below 0 is Dangerous (redesign before writing any code).

The core architecture doctrine is treated as non-negotiable: layered architecture is mandatory (routes only route, controllers coordinate while services decide business logic), all controllers extend a shared BaseController, all errors go to Sentry, unifiedConfig is the only allowed configuration source, and all external input must be validated with Zod. It also prescribes a canonical directory structure, strict naming conventions, dependency injection rules, Prisma and repository patterns, mandatory asyncErrorWrapper for async error handling, required observability/monitoring instrumentation, and required test coverage.

Seven anti-patterns trigger immediate rejection: business logic in routes, skipping the service layer, direct Prisma calls in controllers, missing validation, using process.env directly instead of unifiedConfig, console.log instead of Sentry, and untested business logic.

Use this when writing or reviewing backend code in a codebase that follows this layered routes-controllers-services-repositories doctrine, scoring new features or changes with BFRI before building, and rejecting code that hits one of the seven hard anti-patterns.

Not the right skill for codebases using a fundamentally different architecture pattern (this doctrine is specific and opinionated, not a general backend guide), or for frontend-only changes with no backend logic involved.

Inputs: a proposed backend feature or change, scored across the five BFRI dimensions.

Outputs: a BFRI score with a clear proceed/add-tests/refactor/redesign verdict, code following the mandatory layered architecture (BaseController, Sentry error reporting, unifiedConfig, Zod validation, asyncErrorWrapper), and rejection of any code matching the seven hard anti-patterns.

Sentry (error reporting), Zod (input validation), Prisma (repository layer), a unifiedConfig module, asyncErrorWrapper utility, BaseController base class.

Backend developers and reviewers working in a codebase enforcing this specific layered architecture doctrine who need a risk-scoring gate (BFRI) and a hard anti-pattern checklist before shipping changes.