system-designlisted

# System Design (orchestrator) Drive an open-ended design problem from a vague prompt to a justified, stress-tested architecture — **by reasoning, not by recalling a diagram.** This skill owns the *method* and the *routing*; the actual component recipes live in focused building-block skills it pulls in as needed. The single most important idea, from which everything here follows: > Do not memorize architectures; learn the forces that shape them. There is no > single correct solution — success depends on the assumptions you make explicit. A design that works for 1,000 users may fail at 1,000,000. Treat every architecture as a **hypothesis** that holds until a constraint changes, and be ready to redraw it calmly when one does. ## The reasoning loop Work this loop out loud. It is a loop, not a checklist — late steps routinely send you back to early ones, and that is the point. 1. **Clarify requirements** — turn the vague prompt into functional requirements, non-functional constraints, and an explicit *out of scope*. Scope to a few core features; say so. → skill `requirements-scoping` 2. **Estimate scale** — back-of-the-envelope QPS, storage, bandwidth, read/write ratio. Numbers decide the design; "high traffic" does not. → skill `back-of-the-envelope` 3. **Propose a high-level design** — sketch the boxes and arrows (clients, LB, services, stores, caches, queues, CDN) and the user-facing API. Get buy-in before going deep. → skill `api-design`, plus the bu