Backend Architecture Orchestrator
The single entry skill for server-side work. It locates the task on the layer × concern
map and delegates to one of 8 specialist spokes. The cross-cutting model every backend shares
— the dependency-inversion boundary (domain → ports → adapters), the layering contract, the
API/transport conventions, and the runtime/tooling matrix — lives in backend-architecture-core;
read it before drawing a module boundary, designing an endpoint, or wiring an integration.
Routing map (intent → spoke)
Shape the architecture
- "How should I structure this service?" / boundaries, testability, decoupling →
hexagonal-architecture (model in backend-architecture-core)
- General server-side patterns — repository/service/controller layers, caching, background jobs, query optimization →
backend-patterns
- Framework-specific structure (NestJS modules, providers, guards, interceptors, DTO validation) →
nestjs-patterns
Design the API surface
- REST contracts — resource naming, status codes, pagination, filtering, versioning, error shapes, rate limiting →
api-design
- Add an outbound integration / provider that matches the repo's existing pattern →
api-connector-builder
- Expose tools/resources/prompts to an AI assistant (Model Context Protocol) →
mcp-server-patterns
Ship & remember why
- Deploy, containerize, CI/CD, health checks, rollback, production readiness →
deployment-patterns
- Record an architectural decision (context, alternatives, rationale) →
architecture-decision-records
Sibling clusters
- A pure DB query, indexing, migration, or engine-tuning ask →
databases-data. This cluster owns app-layer data patterns (repository, transactions via ports, API design over the data), not DB engine internals.
Standard Operating Flow
- Locate the task: which layer (domain → application → adapter → transport → deploy) and which concern.
- If it touches boundaries, the layering contract, or transport conventions, pull the model from
backend-architecture-core first — these are interlocking, not independent.
- Delegate to the spoke(s). Multi-step asks fan out in layer order (e.g. "build and ship a new integration" →
hexagonal-architecture (port) → api-connector-builder (adapter) → deployment-patterns).
- When a non-obvious trade-off is settled along the way, capture it via
architecture-decision-records.
- Return: chosen spoke(s), the boundary/contract changes implied, the deployment surface touched, and the next action.
Guardrails
See backend-architecture-core. In short: dependencies point inward — domain logic never
imports a framework, a driver, or an HTTP client; those live behind ports. Match the host repo's
existing pattern instead of inventing a second architecture. Validate every input at the
transport boundary; treat any new public-API contract, persisted schema, or outbound integration
as a deliberate change worth stating. The cluster's value is keeping business rules independent
of I/O — don't quietly leak infrastructure into the core.
Loading spokes on demand
To keep CLI startup context lean, this cluster's spokes are not separately registered as skills — only this orchestrator and its *-core are enumerated. When you route to a spoke named above, load it on demand by reading its file:
~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md (or skills/<spoke-name>/SKILL.md inside the skill-clusters repo).
1---2name: backend-architecture-orchestrator3description: Route a backend task to the right skill among 8 server-side specialists — architecture boundaries (hexagonal/ports-and-adapters), REST API design, HTTP connector building, NestJS structure, MCP servers, deployment/CI-CD, and decision records. USE WHEN a user is designing, building, integrating, or shipping a backend service but hasn't named the specific concern.4---56# Backend Architecture Orchestrator78The single entry skill for server-side work. It locates the task on the **layer × concern**9map and delegates to one of 8 specialist spokes. The cross-cutting model every backend shares10— the dependency-inversion boundary (domain → ports → adapters), the layering contract, the11API/transport conventions, and the runtime/tooling matrix — lives in `backend-architecture-core`;12read it before drawing a module boundary, designing an endpoint, or wiring an integration.1314## Routing map (intent → spoke)1516**Shape the architecture**17- "How should I structure this service?" / boundaries, testability, decoupling → `hexagonal-architecture` *(model in `backend-architecture-core`)*18- General server-side patterns — repository/service/controller layers, caching, background jobs, query optimization → `backend-patterns`19- Framework-specific structure (NestJS modules, providers, guards, interceptors, DTO validation) → `nestjs-patterns`2021**Design the API surface**22- REST contracts — resource naming, status codes, pagination, filtering, versioning, error shapes, rate limiting → `api-design`23- Add an outbound integration / provider that matches the repo's existing pattern → `api-connector-builder`24- Expose tools/resources/prompts to an AI assistant (Model Context Protocol) → `mcp-server-patterns`2526**Ship & remember why**27- Deploy, containerize, CI/CD, health checks, rollback, production readiness → `deployment-patterns`28- Record an architectural decision (context, alternatives, rationale) → `architecture-decision-records`2930## Sibling clusters3132- A pure DB query, indexing, migration, or engine-tuning ask → `databases-data`. This cluster owns app-layer data patterns (repository, transactions via ports, API design over the data), not DB engine internals.3334## Standard Operating Flow35361. Locate the task: which layer (domain → application → adapter → transport → deploy) and which concern.372. If it touches **boundaries, the layering contract, or transport conventions**, pull the model from `backend-architecture-core` first — these are interlocking, not independent.383. Delegate to the spoke(s). Multi-step asks fan out in layer order (e.g. "build and ship a new integration" → `hexagonal-architecture` (port) → `api-connector-builder` (adapter) → `deployment-patterns`).394. When a non-obvious trade-off is settled along the way, capture it via `architecture-decision-records`.405. Return: chosen spoke(s), the boundary/contract changes implied, the deployment surface touched, and the next action.4142## Guardrails4344See `backend-architecture-core`. In short: **dependencies point inward** — domain logic never45imports a framework, a driver, or an HTTP client; those live behind ports. Match the host repo's46existing pattern instead of inventing a second architecture. Validate every input at the47transport boundary; treat any new public-API contract, persisted schema, or outbound integration48as a deliberate change worth stating. The cluster's value is keeping business rules independent49of I/O — don't quietly leak infrastructure into the core.5051## Loading spokes on demand5253To keep CLI startup context lean, this cluster's spokes are **not** separately registered as skills — only this orchestrator and its `*-core` are enumerated. When you route to a spoke named above, **load it on demand** by reading its file:5455`~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md` (or `skills/<spoke-name>/SKILL.md` inside the skill-clusters repo).
Sheshiyer