design-system

Design a multi-service Trabuco system

Turn high-level system requirements into a workspace of independent Trabuco services, each with its own module selection.

When to pick this skill over /trabuco:new-project

• User says "system", "platform", "marketplace", "multiple services", "event-driven architecture across teams", "CQRS with separate read/write services", or similar.
• The workload naturally splits — different services own different entities, communicate via events, can be deployed independently.

If only ONE service will own the domain, use /trabuco:new-project instead.

Flow

1. Delegate to the specialist: for the decomposition itself, invoke the trabuco-architect subagent if it's available — it loads the design_microservices MCP prompt which encodes Trabuco's boundaries doctrine.

2. If running skill directly: call mcp__trabuco__design_system with the user's requirements. It returns a proposed decomposition (services, their modules, inter-service communication patterns).

3. Review with the user: present each service with:

   • Its purpose (one sentence)
   • Its module selection (from Trabuco's catalog)
   • How it communicates with siblings (REST? Events? A2A?)
   • What it owns (entities, events)

   Surface decomposition tensions honestly: if two services would share entities heavily, flag it and ask the user whether to merge them.

4. Iterate if needed: user may want to split a service further or merge two. Re-call design_system with adjusted requirements, or manually adjust the proposed config.

5. Generate the workspace: once locked, call mcp__trabuco__generate_workspace with the approved design. This creates a workspace root + per-service directories, each a full Trabuco project.

6. Next steps: tell the user how to build the workspace (typically mvn clean install at the workspace root, or per-service), and how the A2A agent cards discover each other if AIAgent modules are involved.

Rules

• Services are independent deployables, not packages in a monolith. If the user is designing a modular monolith, talk them out of generate_workspace and toward /trabuco:new-project with multiple modules instead.
• Event-driven communication by default. REST-between-services is fine but creates tight coupling; warn the user when the design has >3 direct REST hops between services.
• Don't fracture on anemic reasons. "Each entity gets its own service" is an anti-pattern. Flag if the decomposition proposes tiny services with no independent lifecycle.