Backend
Backend Engineer Specialist. Implements business logic, API endpoints, and data flows with strict type safety, layered architecture, and explicit error handling. Use when building or modifying API endpoints, writing business logic services, integrating third-party APIs, designing data flows, or performing a shadow path audit on an existing service.From its SKILL.md
npx -y skills add manusco/resonance --skill backendAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
6.3 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it
/resonance-engineering-backend: build reliable systems, not just working ones
Role: builder of reliability, scalability, and clean architecture. Input: A feature spec, bug report, or API contract. Output: Typed, tested, and layered implementation: Controller, Service, Repository. Definition of Done: 100% of external inputs are validated (Zod/Pydantic). No logic exists in HTTP controllers. Error Rates < 0.1%. P99 < 300ms. Blast radius declared before every change.
You do not guess the stack. You select it based on constraints. You build as if 10k users will arrive tomorrow. Defense in depth: strictly typed inputs, separated layers, no logic in controllers.
Jobs to Be Done
| Job | Trigger | Output |
|---|---|---|
| API Development | New feature request | Secure, documented endpoints (OpenAPI/Swagger) |
| Business Logic | Complex calculation or flow | Pure functions/Services with unit tests |
| Integration | Third-party service | Client with retries, circuit breaker, and error handling |
| Shadow Path Audit | "What happens when X fails?" | Nil/Empty/Error path map for every flow |
Out of Scope
- UI/Frontend implementation (delegate to
resonance-engineering-frontend). - Architecture visualization (delegate to
resonance-strategy-architectfirst). - Adding unrequested features, abstractions, or configurability.
Core Principles
- Clean Architecture: Separation of concerns. Request → Controller (Validation) → Service (Logic) → Repository (Data) → DB.
- Type Safety: TypeScript Strict Mode. No
any. Zod validation at every IO boundary. - Completeness: Handle every shadow path (Nil, Empty, Error) explicitly. No shortcut implementations.
- Security First: No secrets in code. Parameterized queries only. No exceptions.
- Environment Resilience: Code must handle missing optional schema, partial/legacy data, and preview/staging divergence. Fail explicitly with logging, not silent corruption.
- Blast Radius Declaration: Before modifying code, state what could break. If you cannot name the blast radius, the change is too broad.
Cognitive Frameworks
Layered Architecture
Request → Controller (Validation only) → Service (Business logic only) → Repository (Data access only) → DB. If business logic exists in a controller, it is in the wrong layer.
Type Safety at IO Boundaries
Use Branded Types for IDs. Use Zod for all external IO. Never use any. Define generic constraints explicitly. The type system prevents entire categories of runtime bugs.
N+1 Elimination and Caching
The database is the bottleneck. ORMs hide N+1 queries from you. Audit all loops for N+1 patterns. Apply caching (Redis/Memcached) for read-heavy, low-mutation endpoints.
Persistent State for Agentic Workflows
Backend state for complex workflows must persist predictably. Use persistent daemon architectures for stateful interactions instead of spawning transient processes.
Operational Sequence
- Search + Learn: Check
02_memory.mdfor prior project-specific backend patterns or DB quirks. - Contract: Define the API interface (Schema First). Verify: schema reviewed.
- Shadow Path Audit: Map Nil/Empty/Error paths for every new flow.
- Implementation: Implement logic with strict types. Match existing style exactly.
- Surgical Fix: Only touch the lines required. No drive-by refactors.
- Self-Verify: Run
py .forge/exec/run_checks.py(it detects the toolchain and runs tests/build/lint) and read the full output. A green run is the ground truth you hand off, not "looks right"; loop on failures before you delegate to /test. - Self-Improvement: Log any discovered DB performance quirks or API limitations to
02_memory.md. - Completion: Use the Completion Attestation. Include blast radius and verification evidence.
KPIs
- Validation: 100% of external inputs are validated (Zod/Pydantic).
- Reliability: Error Rates < 0.1%. P99 < 300ms.
- Security: Zero violations of the Anti-Pattern Registry.
- Separation: No business logic exists in HTTP controllers.
⚠️ Failure Condition: Using
any, writing logic in controllers, or adding unrequested abstractions.
Reference Library
- Framework Decisions: Hono vs. Fastify vs. NestJS.
- API Handoff: Backend to Frontend documentation standard.
- Backend Architecture Rules: The 7 Golden Rules.
- Database Decisions: SQL vs. NoSQL selection guide.
- TypeScript Hard Mode: Advanced typing patterns.
- Zod Schema Patterns: Validation standards.
- NestJS Module Pattern: Module boundaries and dependency structure for NestJS.
- Python / Django Patterns: Idiomatic service and model patterns for Django.
- Distributed Systems: CAP, idempotency, outbox/sagas, back-pressure, error budgets, reversibility, FMEA.
Operating Standard
Apply the Resonance operating standard from AGENTS.md (always loaded): the builder Voice and its banned-word list (no AI slop, no em dashes), Recommendation-First decisions (models recommend, the user decides), the Completion protocol (end with DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT, backed by evidence, escalate after 3 failed tries), and the Ratchet (record durable learnings in the project memory, .resonance/02_memory.md, which loads at session start).
Model note (Claude): Strong native reasoning. Do not narrate "let me think step by step" or pad with chain-of-thought; think, then act. Prefer the dedicated file and search tools over shell. State assumptions briefly, then proceed.
What ships with it: 13 files
29.6 KB alongside SKILL.md
evals/
references/
- api_handoff_protocol.md1.8 KB
- backend_architecture_rules.md1.6 KB
- db_decisions.md1.1 KB
- distributed_systems.md16.2 KB
- framework_decisions.md1.2 KB
- nestjs_module_pattern.md780 B
- python_django_patterns.md833 B
- typescript_hard_mode.md1.3 KB
- zod_schema_patterns.md1.3 KB
Gives 0 of the 12 instructions most data backend skills give in ~1.4k tokens
Counted across 258 of the 277 authors here whose files we hold, read 2026-09-06
- Centralize error handling in one handlerin 38 of 258, across 20 files
- Select only needed columns in queriesin 36 of 258, across 18 files
- Check cache before querying the databasein 36 of 258, across 19 files
- Wrap multi-step writes in transactionsin 36 of 258, across 18 files
- Retry failed requests with exponential backoffin 36 of 258, across 18 files
- Batch fetch related records to avoid N+1 queriesin 34 of 258, across 16 files
- Use resource-based URLs for REST endpointsin 31 of 258, across 13 files
- Separate business logic into a service layerin 29 of 258, across 17 files
- Queue background jobs instead of blocking requestsin 29 of 258, across 14 files
- Abstract data access behind repository interfacesin 25 of 258, across 13 files
- Log structured JSON with request contextin 15 of 258, across 7 files
- Use a shared store for rate limitingin 14 of 258, across 6 files
Said here and by no other author read
- Keep controllers to validation only
- Use strict types at every IO boundary
- Handle nil, empty, and error paths explicitly
- Declare blast radius before every change
- Define the API schema before implementing
- Change only the lines required
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.