system-design

Name: system-design
Author: proyecto26

54installs1forks

How to install system-design?

proyecto26/system-design-skills/system-design

$npx -y skills add proyecto26/system-design-skills --skill system-design

Installs into the current project.

Summary

This skill should be used when the user asks to "design a system", "design <a product>" (e.g. "design WhatsApp", "design a URL shortener", "design a news feed"), "high-level architecture for…", "how would you architect…", "system design interview", or wants to scope, diagram, and

Files · 1

View on GitHub

SKILL.md

1	# System Design (orchestrator)
2
3	Drive an open-ended design problem from a vague prompt to a justified,
4	stress-tested architecture — by reasoning, not by recalling a diagram. This
5	skill owns the method and the routing; the actual component recipes live in
6	focused building-block skills it pulls in as needed.
7
8	The single most important idea, from which everything here follows:
9
10	> Do not memorize architectures; learn the forces that shape them. There is no
11	> single correct solution — success depends on the assumptions you make explicit.
12
13	A design that works for 1,000 users may fail at 1,000,000. Treat every
14	architecture as a hypothesis that holds until a constraint changes, and be
15	ready to redraw it calmly when one does.
16
17	## The reasoning loop
18
19	Work this loop out loud. It is a loop, not a checklist — late steps routinely
20	send you back to early ones, and that is the point.
21
22	1. Clarify requirements — turn the vague prompt into functional
23	requirements, non-functional constraints, and an explicit out of scope.
24	Scope to a few core features; say so. → skill `requirements-scoping`
25	2. Estimate scale — back-of-the-envelope QPS, storage, bandwidth, read/write
26	ratio. Numbers decide the design; "high traffic" does not. → skill
27	`back-of-the-envelope`
28	3. Propose a high-level design — sketch the boxes and arrows (clients, LB,
29	services, stores, caches, queues, CDN) and the user-facing API. Get buy-in
30	before going deep. → skill `api-design`, plus the building blocks below.
31	4. Evaluate trade-offs — for every major choice, state what it solves, what
32	it worsens, and what would make you change it. Never name a tool without
33	this. → reference `tradeoff-framework.md`
34	5. Stress-test failure modes — find single points of failure, decide the
35	degradation story, plan recovery. Assume every component breaks. → skill
36	`resilience-failure`
37	6. Iterate / deep-dive — pick the most interesting or fragile component and
38	go deep; let new constraints ("what if writes 10×?", "lose a region?") drive
39	a redesign of the affected part.
40
41	These six steps are the same four activities the GUIDE names —
42	**ask refining questions → handle the data → discuss components → discuss
43	trade-offs** — with estimation and failure-testing made explicit. See
44	`references/reasoning-loop.md` for the full walk-through and time budgeting.
45
46	## Routing to building blocks
47
48	This plugin is a wiki of composable parts. As each concern comes up in the loop,
49	invoke the focused skill (via the Skill tool) rather than reconstructing its
50	recipe from memory — load it so the options, trade-off table, behavior under
51	stress, and cloud-provider variants come from the skill itself. That invocation
52	is how composition works at runtime: a bare skill name below is a skill to
53	trigger, not a file to read. Invoke each as its concern becomes active:
54
55	\| When the problem turns to… \| Use skill \|
56	\|---\|---\|
57	\| What features / constraints / scope? \| `requirements-scoping` \|
58	\| How many QPS, how much storage, how many servers? \| `back-of-the-envelope` \|
59	\| Endpoints, request/response, pagination, idempotency \| `api-design` \|
60	\| Monolith vs microservices, service boundaries, gateway, discovery \| `service-decomposition` \|
61	\| SQL vs NoSQL, schema, indexing, sharding, replication \| `data-storage` \|
62	\| What to cache, eviction, invalidation, hot keys \| `caching` \|
63	\| Distributing traffic, L4/L7, health checks \| `load-balancing` \|
64	\| Async work, queues vs streams, delivery guarantees \| `messaging-streaming` \|
65	\| CAP, consistency models, quorum, consensus, hashing \| `consistency-coordination` \|
66	\| Fault tolerance, circuit breakers, degradation, rate limiting \| `resilience-failure` \|
67	\| Static/media delivery, edge, geo-routing \| `content-delivery` \|
68	\| How the design evolves with 10×/100× growth \| `scaling-evolution` \|
69	\| How clients resolve the service, geo/failover routing \| `dns` \|
70	\| Unique IDs at scale (Snowflake/UUID/ticket) \| `sequencer` \|
71	\| Storing large/unstructured objects (images, video, files) \| `blob-store` \|
72	\| Metrics/logs/traces, health checks, SLOs, alerting \| `observability` \|
73	\| High-volume log collection/shipping/retention \| `distributed-logging` \|
74	\| Full-text search, inverted index, autocomplete \| `distributed-search` \|
75	\| Background / scheduled / recurring jobs \| `task-scheduling` \|
76	\| Counting likes/views at huge write rates \| `sharded-co

People who liked this also viewed

6 picks

Type

system-design

54installs1forks

View on GitHub

How to install system-design?

proyecto26/system-design-skills/system-design

$npx -y skills add proyecto26/system-design-skills --skill system-design

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# System Design (orchestrator)
2
3	Drive an open-ended design problem from a vague prompt to a justified,
4	stress-tested architecture — by reasoning, not by recalling a diagram. This
5	skill owns the method and the routing; the actual component recipes live in
6	focused building-block skills it pulls in as needed.
7
8	The single most important idea, from which everything here follows:
9
10	> Do not memorize architectures; learn the forces that shape them. There is no
11	> single correct solution — success depends on the assumptions you make explicit.
12
13	A design that works for 1,000 users may fail at 1,000,000. Treat every
14	architecture as a hypothesis that holds until a constraint changes, and be
15	ready to redraw it calmly when one does.
16
17	## The reasoning loop
18
19	Work this loop out loud. It is a loop, not a checklist — late steps routinely
20	send you back to early ones, and that is the point.
21
22	1. Clarify requirements — turn the vague prompt into functional
23	requirements, non-functional constraints, and an explicit out of scope.
24	Scope to a few core features; say so. → skill `requirements-scoping`
25	2. Estimate scale — back-of-the-envelope QPS, storage, bandwidth, read/write
26	ratio. Numbers decide the design; "high traffic" does not. → skill
27	`back-of-the-envelope`
28	3. Propose a high-level design — sketch the boxes and arrows (clients, LB,
29	services, stores, caches, queues, CDN) and the user-facing API. Get buy-in
30	before going deep. → skill `api-design`, plus the building blocks below.
31	4. Evaluate trade-offs — for every major choice, state what it solves, what
32	it worsens, and what would make you change it. Never name a tool without
33	this. → reference `tradeoff-framework.md`
34	5. Stress-test failure modes — find single points of failure, decide the
35	degradation story, plan recovery. Assume every component breaks. → skill
36	`resilience-failure`
37	6. Iterate / deep-dive — pick the most interesting or fragile component and
38	go deep; let new constraints ("what if writes 10×?", "lose a region?") drive
39	a redesign of the affected part.
40
41	These six steps are the same four activities the GUIDE names —
42	**ask refining questions → handle the data → discuss components → discuss
43	trade-offs** — with estimation and failure-testing made explicit. See
44	`references/reasoning-loop.md` for the full walk-through and time budgeting.
45
46	## Routing to building blocks
47
48	This plugin is a wiki of composable parts. As each concern comes up in the loop,
49	invoke the focused skill (via the Skill tool) rather than reconstructing its
50	recipe from memory — load it so the options, trade-off table, behavior under
51	stress, and cloud-provider variants come from the skill itself. That invocation
52	is how composition works at runtime: a bare skill name below is a skill to
53	trigger, not a file to read. Invoke each as its concern becomes active:
54
55	\| When the problem turns to… \| Use skill \|
56	\|---\|---\|
57	\| What features / constraints / scope? \| `requirements-scoping` \|
58	\| How many QPS, how much storage, how many servers? \| `back-of-the-envelope` \|
59	\| Endpoints, request/response, pagination, idempotency \| `api-design` \|
60	\| Monolith vs microservices, service boundaries, gateway, discovery \| `service-decomposition` \|
61	\| SQL vs NoSQL, schema, indexing, sharding, replication \| `data-storage` \|
62	\| What to cache, eviction, invalidation, hot keys \| `caching` \|
63	\| Distributing traffic, L4/L7, health checks \| `load-balancing` \|
64	\| Async work, queues vs streams, delivery guarantees \| `messaging-streaming` \|
65	\| CAP, consistency models, quorum, consensus, hashing \| `consistency-coordination` \|
66	\| Fault tolerance, circuit breakers, degradation, rate limiting \| `resilience-failure` \|
67	\| Static/media delivery, edge, geo-routing \| `content-delivery` \|
68	\| How the design evolves with 10×/100× growth \| `scaling-evolution` \|
69	\| How clients resolve the service, geo/failover routing \| `dns` \|
70	\| Unique IDs at scale (Snowflake/UUID/ticket) \| `sequencer` \|
71	\| Storing large/unstructured objects (images, video, files) \| `blob-store` \|
72	\| Metrics/logs/traces, health checks, SLOs, alerting \| `observability` \|
73	\| High-volume log collection/shipping/retention \| `distributed-logging` \|
74	\| Full-text search, inverted index, autocomplete \| `distributed-search` \|
75	\| Background / scheduled / recurring jobs \| `task-scheduling` \|
76	\| Counting likes/views at huge write rates \| `sharded-co

People who liked this also viewed

6 picks

Type