System design
Designs services, APIs, and data models from requirements. Use when designing a new service, API, or data model, or when doing system design for a greenfield or major new capability. Do not use for a small local design choice inside an existing module (use architecture).From its SKILL.md
npx -y skills add IcodeNet/agent-skills --skill system-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.5 KB, 274 tokens by cl100k_base, as published. Nobody here has run it
System Design
Turn requirements into a coherent design: boundaries, contracts, data, and failure modes.
Workflow
- Requirements — functional goals, non-functionals (latency, consistency, tenancy, offline), explicit non-goals.
- Context — actors, existing systems, trust boundaries. Sketch a simple topology.
- Contracts — public APIs/events first (schemas, errors, versioning). See
references/design-checklist.md. - Data — entities, ownership, consistency model, migrations story.
- Failure & scale — timeouts, retries/idempotency, backpressure, authn/z, observability.
- Options — 2 approaches with trade-offs; pick one; list open questions.
- Hand off — ADRs for major decisions; implementation slices that are testable.
Constraints
- Design for operability (health, logs, metrics) not only happy path.
- Prefer boring technology that fits the existing stack unless requirements force otherwise.
- Do not over-design for hypothetical scale.
Verification
- Requirements and non-goals written
- Topology + trust boundaries clear
- API/data contracts sketched
- Failure modes and auth addressed
- Decision + open questions recorded
What ships with it: 1 file
654 B alongside SKILL.md
references/
- design-checklist.md654 B