Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →nwave-ai/nw-sd-framework
4-step system design framework with back-of-envelope estimation, scaling ladder, and common pitfalls
Passed 21 of 24 test cases with the skill, and 16 of 24 without it.
and 2 more in the full report
5 fixed16 passed either way3 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
In the standard 9-step infrastructure scaling ladder, what is the very first component introduced to handle web traffic, and what is the ninth component introduced for global redundancy?
| Checked | Without skill | With skill |
|---|---|---|
| Load balancer is positioned as step 1 in the scaling sequence. | Missed | Passed |
| Multiple data centers is positioned as step 9 in the scaling sequence. | Passed | Passed |
The instructions your model reads when the skill loads.
Every system design follows this structure. Skipping steps is the top mistake.
Narrow an impossibly broad question into a tractable problem.
Ask about: users and scale | most important features | read/write ratio | non-functional requirements (latency, availability, consistency) | existing infrastructure | special constraints (mobile-first, offline, regulatory)
Produce: functional requirements (3-5 bullets) | non-functional requirements (scale, latency, availability, consistency model) | capacity estimation (QPS, storage, bandwidth)
Red flags if skipped: designing a system nobody asked for | over-engineering for imaginary scale | missing critical constraints (GDPR, real-time)
Sketch the big picture. Validate before diving deep.
Do: draw architecture diagram (clients, servers, databases, caches, queues) | define API contract (REST/GraphQL/gRPC -- key endpoints) | design data model (entities, relationships, access patterns) | walk through 1-2 core use cases end-to-end | get buy-in: "Does this make sense before I go deeper?"
API patterns: RESTful for CRUD-heavy | GraphQL for flexible client queries | gRPC for internal service-to-service | WebSocket/SSE for real-time
Data model: SQL vs NoSQL based on access patterns, not hype | denormalization trade-offs | partitioning key selection (directly impacts scalability)
Go deep on 2-3 components.
Choose: most technically challenging | most interesting trade-offs | bottleneck components (highest load, most failure-prone)
Depth means: specific algorithms (consistent hashing, Bloom filters) | failure modes and handling | scaling strategy per component | data flow with edge cases | monitoring and operational concerns
Cover: summarize design in 2-3 sentences | identify known bottlenecks | what you'd improve with more time | operational concerns (monitoring, alerting, deployment) | future enhancements
Avoid: introducing entirely new components at this stage | second-guessing your design
test cases passed, vs 16 / 24 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.