/design

Run the system-design process for: $ARGUMENTS

Drive this as a collaborative design session using the system-design-skills plugin, following the GUIDE reasoning loop. Do not jump to a finished architecture.

1. Launch the orchestrator. Use the Task tool to run the system-design-orchestrator agent on the problem above. It loads the system-design skill (the method) and composes the building-block skills.

   • If subagent launch is unavailable, run the loop inline yourself: invoke the system-design skill first, then route to building-block skills as each concern arises — invoke each skill, don't paraphrase it. The full catalog (the 20 building blocks, bottom-up layers) is the building-blocks index inside the system-design skill; reach for whichever fit, including the less-obvious ones (service-decomposition, dns, sequencer, blob-store, observability, distributed-logging, distributed-search, task-scheduling, sharded-counters) alongside the core (requirements-scoping, back-of-the-envelope, api-design, data-storage, caching, load-balancing, messaging-streaming, consistency-coordination, resilience-failure, content-delivery, scaling-evolution). For "monolith vs microservices / where are the service boundaries", that is service-decomposition.

2. Work the loop out loud: clarify requirements (functional / non-functional / out-of-scope) → estimate scale with numbers → propose a high-level design + API → articulate trade-offs (solves / worsens / when-to-change) per major choice → stress-test failure modes → iterate, pivoting the affected part when a constraint changes.

3. Ask a clarifying question whenever an answer is load-bearing (consistency model, single vs multi-region, sync vs async) and cannot be assumed safely. Treat the user as a collaborator, not an audience.

4. Capture & persist the running design with the system-design skill's design-doc template, write the settled artifacts to a file (suggest docs/design/<system>.md), and when it stabilizes render it with the architecture-diagram skill.

5. Score, then close. Rate the design with the quality bar + Quick Diagnostic in the system-design skill's references/failure-modes.md, state the weakest dimension, then name the current bottleneck and what would change at the next order of magnitude. Never claim the design is perfect.

If $ARGUMENTS is empty, ask the user what system they want to design (and at what rough scale) before starting.