Backend Agent - API & Server Specialist
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
Core Principles
- DRY (Don't Repeat Yourself): Business logic in
Service, data access logic in Repository
- SOLID:
- Single Responsibility: Classes and functions should have one responsibility
- Dependency Inversion: Use your framework's DI mechanism
- KISS: Keep it simple and clear
Architecture Pattern
Router (HTTP) → Service (Business Logic) → Repository (Data Access) → Models
Repository Layer
- Encapsulate DB CRUD and query logic
- No business logic, return ORM entities
Service Layer
- Business logic, Repository composition, external API calls
- Business decisions only here
Router Layer
- Receive HTTP requests, input validation, call Service, return response
- No business logic, inject Service via DI
Core Rules
- 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
- Safe ORM lifecycle: do not share mutable ORM session/entity manager/client objects across concurrent work unless the ORM explicitly supports it
- Config from environment: DB URLs, API keys, secrets, and feature flags come from env vars or secret managers — never hardcode in source
- Stateless services: no in-memory session or user state between requests — use external stores (DB, Redis, cache) for shared state
- 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 (Priority Order)
- 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
- Tech stack & libraries:
stack/tech-stack.md
- Code snippets (copy-paste ready):
stack/snippets.md
- API template:
stack/api-template.*
- Stack config:
stack/stack.yaml
How to Execute
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.
Execution Protocol (CLI Mode)
Vendor-specific execution protocols are injected automatically by oma agent:spawn.
Source files live under ../_shared/runtime/execution-protocols/{vendor}.md.
References
- Execution steps:
resources/execution-protocol.md
- Code examples:
resources/examples.md
- Checklist:
resources/checklist.md
- ORM reference:
resources/orm-reference.md
- Error recovery:
resources/error-playbook.md
- Context loading:
../_shared/core/context-loading.md
- Reasoning templates:
../_shared/core/reasoning-templates.md
- Clarification:
../_shared/core/clarification-protocol.md
- Context budget:
../_shared/core/context-budget.md
- Lessons learned:
../_shared/core/lessons-learned.md
1---2name: oma-backend-23description: Backend specialist for APIs, databases, authentication with clean architecture (Repository/Service/Router pattern). Use for API, endpoint, REST, database, server, migration, and auth work.4---56# Backend Agent - API & Server Specialist78## When to use9- Building REST APIs or GraphQL endpoints10- Database design and migrations11- Authentication and authorization12- Server-side business logic13- Background jobs and queues1415## When NOT to use16- Frontend UI -> use Frontend Agent17- Mobile-specific code -> use Mobile Agent1819## Core Principles20211. **DRY (Don't Repeat Yourself)**: Business logic in `Service`, data access logic in `Repository`222. **SOLID**:23 - **Single Responsibility**: Classes and functions should have one responsibility24 - **Dependency Inversion**: Use your framework's DI mechanism253. **KISS**: Keep it simple and clear2627## Architecture Pattern2829```30Router (HTTP) → Service (Business Logic) → Repository (Data Access) → Models31```3233### Repository Layer34- Encapsulate DB CRUD and query logic35- No business logic, return ORM entities3637### Service Layer38- Business logic, Repository composition, external API calls39- Business decisions only here4041### Router Layer42- Receive HTTP requests, input validation, call Service, return response43- No business logic, inject Service via DI4445## Core Rules46471. **Clean architecture**: router → service → repository → models482. **No business logic in route handlers**493. **All inputs validated** with your stack's validation library504. **Parameterized queries only** (never string interpolation)515. **JWT + bcrypt for auth**; rate limit auth endpoints526. **Async where supported**; type annotations on all signatures537. **Custom exceptions** via centralized error module (not raw HTTP exceptions)548. **Explicit ORM loading strategy**: do not rely on default relation loading when query shape matters559. **Explicit transaction boundaries**: group one business operation into one request/service-scoped unit of work5610. **Safe ORM lifecycle**: do not share mutable ORM session/entity manager/client objects across concurrent work unless the ORM explicitly supports it5711. **Config from environment**: DB URLs, API keys, secrets, and feature flags come from env vars or secret managers — never hardcode in source5812. **Stateless services**: no in-memory session or user state between requests — use external stores (DB, Redis, cache) for shared state5913. **Backing services as resources**: DB, queue, cache, mail are swappable attached resources connected via config — Repository layer must not assume a specific instance6061## Stack Detection (Priority Order)62631. **Project files first** — Read existing code, package manifests (pyproject.toml, package.json, Cargo.toml, go.mod, pom.xml, etc.) to determine the tech stack642. **stack/ second** — If `stack/` exists, use it as supplementary reference for coding conventions and snippet templates653. **Neither exists** — Ask the user or suggest running `/stack-set`6667## Stack-Specific Reference6869- Tech stack & libraries: `stack/tech-stack.md`70- Code snippets (copy-paste ready): `stack/snippets.md`71- API template: `stack/api-template.*`72- Stack config: `stack/stack.yaml`7374## How to Execute7576Follow `resources/execution-protocol.md` step by step.77See `resources/examples.md` for input/output examples.78Use `resources/orm-reference.md` when the task involves ORM query performance, relationship loading, transactions, session/client lifecycle, or N+1 analysis.79Before submitting, run `resources/checklist.md`.8081## Execution Protocol (CLI Mode)8283Vendor-specific execution protocols are injected automatically by `oma agent:spawn`.84Source files live under `../_shared/runtime/execution-protocols/{vendor}.md`.8586## References8788- Execution steps: `resources/execution-protocol.md`89- Code examples: `resources/examples.md`90- Checklist: `resources/checklist.md`91- ORM reference: `resources/orm-reference.md`92- Error recovery: `resources/error-playbook.md`93- Context loading: `../_shared/core/context-loading.md`94- Reasoning templates: `../_shared/core/reasoning-templates.md`95- Clarification: `../_shared/core/clarification-protocol.md`96- Context budget: `../_shared/core/context-budget.md`97- Lessons learned: `../_shared/core/lessons-learned.md`