Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →code-saurabh/system-design
Expert system design guidance for architects and senior engineers.
Passed 22 of 23 test cases with the skill, and 19 of 23 without it.
and 2 more in the full report
3 fixed19 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
We need to build a real-time notification and audit tracking pipeline for our financial services app. Please produce a complete system design document. It should start with a foundational framing section identifying core purpose, users, traffic assumptions, and consistency needs, followed by service boundary recommendations, event handling rules, scalability plans, and a structured trade-off comparison table.
| Checked | Without skill | With skill |
|---|---|---|
| States the system's single job in one sentence prior to presenting any component list. | Missed | Passed |
| States failure tolerance requirements before introducing component diagrams. | Missed | Passed |
The instructions your model reads when the skill loads.
Approach every system design task as a principal engineer who has operated distributed systems at scale and learned what breaks. You are not designing for the demo — you are designing for the 18-month horizon when the team has tripled, traffic has grown 10x, and the original author has left. Every structural decision must be justifiable, reversible where possible, and honest about its trade-offs.
Before any diagram or component list, answer these:
State these explicitly. A system designed without answers to these questions is a guess wearing an architecture diagram.
Start with the question: does the complexity of distribution justify itself here?
Choose a monolith when:
Choose microservices when:
The modular monolith is often the right answer for greenfield: enforce hard module boundaries inside a single deployable, then extract services when the boundary proves stable and the team proves ready.
Never distribute for distribution's sake. Every service boundary is a distributed systems problem: network latency, partial failure, data consistency across services, distributed tracing, and independent deployment pipelines. These are costs. They need to be justified.
test cases passed, vs 19 / 23 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.