system-design-skills

Run the bottom-up system-design workflow on a problem — clarify, estimate, design with building blocks, weigh trade-offs, stress-test, and diagram. Great for design questions and system-design interview practice.

Use this agent to drive a system-design problem end to end — from a vague prompt to a justified, stress-tested architecture — using the bottom-up building-block skills and the GUIDE reasoning loop. Trigger it for open-ended design problems ("design X"), system-design interview practice, or architecture reviews, especially when the work spans several components (storage + caching + messaging + resilience). Examples: <example> Context: The user wants a full design worked through, not a single component answer. user: "Design a URL shortener that handles 10k writes/sec and billions of reads." assistant: "I'll use the system-design-orchestrator agent to run the full reasoning loop — clarify, estimate, high-level design, trade-offs, failure modes — pulling in the data-storage, caching, and back-of-the-envelope skills as needed." <commentary>Open-ended, multi-component design → the orchestrator runs the loop and composes building-block skills rather than answering ad hoc.</commentary> </example> <example> Context: Interview-style practice with curveballs. user: "Let's do a system design interview — design WhatsApp, then we'll scale it." assistant: "I'll launch the system-design-orchestrator agent; it runs the collaborative loop, narrates trade-offs as solves/worsens/when-to-change, and pivots when you change the constraints." <commentary>The session is a collaborative design dialogue with constraint changes — exactly what the orchestrator and GUIDE are built for.</commentary> </example> <example> Context: A single, narrow component question — orchestrator is NOT needed. user: "What cache eviction policy should I use for a session store?" assistant: "That's a single-component question — I'll use the caching skill directly rather than the full orchestrator." <commentary>Do NOT invoke the orchestrator for one-part questions; trigger the specific building-block skill instead.</commentary> </example>

This skill should be used when the user needs to "design the API", do "endpoint design", pin down a "request/response shape", choose a "pagination" strategy (cursor vs offset), add an "idempotency key" to a write, plan "API versioning", an "error contract", or pick between "REST vs gRPC vs GraphQL" or "WebSocket vs polling". Use it whenever a design has reached the interface — the concrete request, response, primary access path, and how clients page, retry, and version — even if the user only said "the boxes talk to each other".

This skill should be used when a system design needs a diagram — "draw the architecture", "diagram this system", "show the components", "make an architecture/infrastructure/topology diagram", or visualizing boxes-and-arrows, data flow, regions, or failure paths for a design. It generates a self-contained dark-theme HTML + SVG diagram (with PNG/PDF export). Use it whenever the `system-design` orchestrator or a building block reaches the "draw it" step, even if the user doesn't say "diagram".

This skill should be used when the user needs to "estimate QPS", "back-of-the-envelope" (BOTEC) numbers, "how much storage / bandwidth", "how many servers", "peak load", "capacity planning", or wants the standard latency / throughput / availability numbers to ground a design (latency table, QPS rates, powers of two, nines). Use it whenever a design decision hinges on scale — convert any "high traffic" / "huge data" phrase into concrete numbers before choosing components, even if the user doesn't say "estimate".

This skill should be used when the user wants a "blob store" or "object storage", names "S3" or an S3-compatible store, needs to "store images / video / files", asks about "multipart upload" or "resumable upload", "signed / presigned URLs", "media storage", "unstructured data at scale", object "versioning", storage "tiering" (hot/cold/archive), or "erasure coding" vs replication for durability. Use it whenever a design must hold large unstructured objects (photos, video, backups, logs, ML datasets) and serve them cheaply and durably, even if the user just says "where do we put the files".

This skill should be used when the user asks about a "caching strategy", "cache invalidation", "what to cache", "read-through vs write-through vs write-back", "cache eviction" (LRU/LFU/TTL), "Redis vs Memcached", "stale reads", or hits "thundering herd", "cache stampede", "cache penetration", or "hot key" problems. Use it whenever a design is read-heavy or a datastore is overloaded by reads, even if the user doesn't say "cache".