system-designlisted

End-to-end system design for real codebases and greenfield problems. Use when the user asks to design or architect a system, map or reverse-engineer an existing architecture, review a design doc/PR/ADR, plan a migration, scaling evolution or service split, choose technologies (SQL vs NoSQL, Kafka vs SQS, cache strategy, sharding), size infrastructure (servers, QPS, storage, cost), or practice system design interviews. Also fires on oblique asks such as "is Postgres enough?", "will this hold at 10x?", "should we split this service?", "write an ADR", "capacity plan for peak", "our DB falls over at peak". Covers capacity math, failure-mode stress testing, right-sizing against over-engineering, cost estimation, distributed-systems fundamentals, and LLM-era infrastructure (RAG, vector search, model serving). Produces ADR-style design docs with Mermaid diagrams, architecture maps, scored reviews, and migration plans. NOT for UI/visual/CSS/logo design, single-query database tuning, or DevOps pipeline debugging.
DAAS2/system-design-skill · ★ 1 · AI & Automation · score 75

Install: claude install-skill DAAS2/system-design-skill

# System Design Design, map, review, and evolve software systems the way a staff engineer does: numbers first, trade-offs explicit, failures walked, complexity justified. This skill works on both greenfield problems and real codebases. ## Operating principles 1. **Numbers before architecture.** No component enters a design until scale is estimated. Run `scripts/botec.py` and cite the output. A design with no capacity math is an opinion. 2. **Explicit non-goals.** Every design states what it deliberately does not handle. Scope creep is the silent killer. 3. **Every choice names its trade-off.** Format: "X because Y; the cost is Z; revisit when W." A choice presented without a cost is a red flag. 4. **Stress-test before shipping.** Walk the failure injections in `references/stress-tests.md` before finalizing. Designs fail in production, not on the whiteboard. 5. **Right-size, never scale-theater.** Match architecture to actual scale using the tier table in `references/cost.md`. Kafka for 5k users is a bug, not a design. 6. **Ground in the codebase.** When a repository exists, read it before designing. As-is reality beats imagined greenfield. 7. **Artifacts, not chat.** Persist outputs as markdown files (design docs, maps, reviews, plans) so teams can review and diff them. ## Step 0: Detect mode Classify the request, then follow the matching procedure. When ambiguous, ask one clarifying question or infer from context (codebase present → map/review/evolve likely; no codebase