Backend specialist for APIs, databases, authentication with clean architecture (Repository/Service/Router pattern). Use for API, endpoint, REST, database, server, migration, and auth work.
24k tokens
context cost
the whole folder, loaded on every use
19
files
ships runnable scripts
0
copies elsewhere
how many repositories repackaged it
1201
stars on the repo
on the repository, not the skill itself
Install
one command, takes just this skill from the repository
Implement or review backend APIs, authentication, database integration, server-side business logic, and migrations using the project's existing backend stack and clean architecture boundaries.
Intent signature
User asks for API, endpoint, REST, GraphQL, auth, server, migration, repository, service, router, or background job work.
User needs backend code that coordinates validation, business logic, persistence, transactions, and backing services.
When to use
Building REST APIs or GraphQL endpoints
Database design and migrations
Authentication and authorization
Server-side business logic
Background jobs and queues
When NOT to use
Frontend UI -> use Frontend Agent
Mobile-specific code -> use Mobile Agent
Expected inputs
Target feature, endpoint, migration, auth flow, or server behavior
Existing backend stack files such as manifests, routes, services, models, and database config
API contracts, schemas, validation rules, and persistence requirements
Required verification commands or project conventions
Expected outputs
Backend code changes in router, service, repository, model, migration, or test files
Validated inputs, safe queries, transaction boundaries, and error handling
Verification results from the execution checklist
Dependencies
Project stack manifests and existing backend conventions
resources/execution-protocol.md, resources/checklist.md, and resources/orm-reference.md
Optional stack/stack.yaml, stack/tech-stack.md, snippets, and API templates
Database, queue, cache, mail, auth, or external API resources configured through environment or secret managers
Control-flow features
Branches by detected stack, ORM/query pattern, auth requirement, migration impact, and transaction scope
Reads and writes codebase files
May touch local database migrations or generated code
Must not hardcode secrets or share unsafe ORM lifecycle objects across concurrent work
Structural Flow
Entry
Detect the backend stack from project files first.
Identify affected router, service, repository, model, migration, and test boundaries.
Load stack-specific references only when needed.
Scenes
PREPARE: Determine stack, architecture boundaries, and acceptance criteria.
ACQUIRE: Read existing routes, services, repositories, models, schemas, and config.
ACT: Implement backend changes with validation, business logic, persistence, and tests.
VERIFY: Run relevant lint, type, test, migration, and checklist commands.
FINALIZE: Report changed behavior, verification, and unresolved risks.
Transitions
If stack files exist, follow them before generic guidance.
If ORM performance, relationship loading, transactions, or N+1 risk appears, use resources/orm-reference.md.
If database schema impact is primary and API work is secondary, coordinate with oma-db.
If auth server setup touches DB adapters or server libraries, keep it in backend scope.
Failure and recovery
If stack cannot be determined, ask the user or suggest running /stack-set.
If verification fails, fix root cause before handoff.
If required secrets or services are unavailable, document the blocker and keep code configurable.
Exit
Success: backend change is implemented, tested, and aligned with local architecture.
Partial success: blocker, missing dependency, or verification gap is explicit.
Then run the project's discovered verification commands, usually lint/typecheck/tests and migrations when schema changes are involved. Prefer stack/stack.yamlverify: commands when present.
Clean architecture: router → service → repository → models
No business logic in route handlers
All inputs validated with your stack's validation library
Parameterized queries only (never string interpolation)
JWT + bcrypt for auth; rate limit auth endpoints
Async where supported; type annotations on all signatures
Custom exceptions via centralized error module (not raw HTTP exceptions)
Explicit ORM loading strategy: do not rely on default relation loading when query shape matters
Explicit transaction boundaries: group one business operation into one request/service-scoped unit of work
10. Safe ORM lifecycle: do not share mutable ORM session/entity manager/client objects across concurrent work unless the ORM explicitly supports it
11. Config from environment: DB URLs, API keys, secrets, and feature flags come from env vars or secret managers — never hardcode in source
12. Stateless services: no in-memory session or user state between requests — use external stores (DB, Redis, cache) for shared state
13. Backing services as resources: DB, queue, cache, mail are swappable attached resources connected via config — Repository layer must not assume a specific instance
Stack Detection
Project files first — Read existing code, package manifests (pyproject.toml, package.json, Cargo.toml, go.mod, pom.xml, etc.) to determine the tech stack
stack/ second — If stack/ exists, use it as supplementary reference for coding conventions and snippet templates
Neither exists — Ask the user or suggest running /stack-set
Stack-Specific Reference
Stack manifest (SSOT): stack/stack.yaml — structured declaration (language, framework, orm) and verify: contract consumed by oma verify backend. Schema: variants/stack.schema.json.
Follow resources/execution-protocol.md step by step.
See resources/examples.md for input/output examples.
Use resources/orm-reference.md when the task involves ORM query performance, relationship loading, transactions, session/client lifecycle, or N+1 analysis.
Before submitting, run resources/checklist.md.
Vendor-specific execution protocols are injected automatically by oma agent:spawn.
Source files live under ../_shared/runtime/execution-protocols/{vendor}.md.