One folder. Eleven reference files. Nothing to build.
Claude loads SKILL.md when the work involves class design,
refactoring or an LLD problem — then reads only the reference file that the problem's
forces point to. The other ten stay out of the context window.
Same prompt. A different engineer answering.
Asked to design a parking lot, here is what moves. The skill's
main job is not adding patterns — it is removing the ones nobody asked for and
catching the race condition underneath them.
- Singleton
ParkingLotManager, unexplained VehicleFactoryover classes that differ by one enum- Fees as
double; the clock called inline - Concurrency waved at — “add a lock”
- Patterns listed, never justified
- Nothing on how you would know it broke in production
- Axis of change named before a class is written
- Allocation and pricing split — they change for different reasons
- Claiming a spot is one atomic op: CAS, not check-then-act
Moneyvalue object;Clockinjected- Pattern ledger: force resolved, alternative rejected
- One metric per pattern, and what would page someone
Rated by how often it is actually the right answer.
Every pattern carries a real-codebase sighting — Spring's proxies,
Kubernetes' plugin interfaces, java.io's decorator chains — and, more usefully,
the conditions under which it is the wrong call.
Gang of Four, all 23
Intent, the force it resolves, where it shows up in code people ship — and the pairs everyone confuses: Strategy vs. State, Decorator vs. Proxy, Adapter vs. Facade.
Architecture & application
DI without a container, Repository without wrapping your ORM twice, ports & adapters, CQRS, event sourcing, result types, plugin systems, feature flags.
Concurrency
Worker pools, pipelines, fan-out/fan-in, actors, the single-writer principle, CAS, backpressure — plus the nine bugs reviewers actually look for.
Distributed & resilience
Circuit breakers, deadline budgets, retry budgets, hedged requests, bulkheads, five rate-limiting algorithms, sagas, the outbox, expand-contract migration.
Frontend components
Compound components, custom hooks, provider splitting, props getters, state reducers, error boundaries — and why eleven boolean props is a design bug.
Anti-patterns
Twenty-one smells with a detectable signature and the smallest first move. Including pattern-stuffing, which is the one this whole skill exists to prevent.
Operating a pattern
How to test and observe each family, RED and USE signals, and what each costs to run. A circuit breaker you cannot observe is a mystery-outage generator.
Persistence & data
Optimistic vs. pessimistic locking, unique constraints and conditional writes, isolation levels and write skew, aggregates as transaction boundaries, multi-tenant isolation, soft delete, schema change. A mutex protects nothing across instances.
API contracts
Error contracts, idempotent HTTP semantics, pagination, filtering, compatible evolution, versioning, deprecation, webhooks and contract tests — for boundaries whose consumers deploy on their own schedule.
It grades the design before it shows you.
Ten dimensions, scored 0–3. Below 20 and the skill revises rather than presents. Any single zero is a blocker — a beautifully factored design that loses data under concurrency is not a good design.
- 01Requirements fidelity
Requirements enumerated and traceable; ambiguities named rather than silently resolved.
- 02Responsibility allocation
Boundaries follow reasons for change, not merely topic similarity.
- 03Extensibility on the stated axis
Adding the likely variant touches two files or fewer — demonstrated, not claimed.
- 04Interface quality
Minimal, consumer-owned, hard to misuse. Illegal states unrepresentable.
- 05Pattern selection
Caps at 1 if any pattern cannot be traced to a stated requirement.
- 06Concurrency correctness
What is shared, what the atomic unit is, and no lock held across I/O.
- 07Failure handling
Partial failure reasoned about: what is idempotent, what compensates, what the caller sees.
- 08Testability & observability
Clock and randomness injected; and one metric per breaker, queue or cache, with what would page someone.
- 09Data modelling
Invariants enforced at construction; persistence shape not dictating domain shape.
- 10Trade-off communication
States what the design is bad at, and what the simpler version would have been.
Automatic red flags — cap the total at 20
- A Singleton that is not process-wide immutable config
- A Strategy or Factory interface with one implementation
- Check-then-act on a contended resource
- An unbounded queue, or unbounded thread creation
- Domain classes importing ORM or vendor types
- A remote call with no timeout
- Retry on a non-idempotent operation, no idempotency key
- Every class name ending in
ManagerorHelper - A breaker, queue or cache with no stated metric
- Writing to a database and a queue as two separate commits
Thirty problems, each with its trap.
For practice, for generating problems, and as ground truth when grading. Every entry carries the axis of change, the patterns that legitimately fit, the plausible wrong answer, and the follow-up probe that breaks a memorised one. Highlighted are the ten near-certain to appear.
Three steps. No dependencies.
Clone it
The skill is plain Markdown. Nothing to build, nothing to install, no runtime.
git clone https://github.com/00suryavanshi00/code-design-patterns.git
Drop it where Claude reads skills
Project scope or personal scope both work for Claude Code. For Claude.ai and Cowork, upload the folder from Settings → Capabilities → Skills.
# project scope cp -r code-design-patterns/skill/code-design-patterns .claude/skills/ # personal scope cp -r code-design-patterns/skill/code-design-patterns ~/.claude/skills/
Ask it something with a design in it
The skill triggers on class design, refactoring, architecture and LLD work — including when you never say the words “design pattern”.
“Design a rate limiter that works across 10 nodes.” “Review this OrderService — it's 400 lines.” “Should I use Visitor for my plugin node types?” “Grade my vending machine design out of 30.”
The things people actually ask.
What is code-design-patterns?
code-design-patterns is a free, open-source Claude Skill for software design
patterns. It is a folder of Markdown — one SKILL.md router plus eleven reference
files — that Claude loads automatically when the work involves class design, refactoring,
architecture or a low-level design problem. It covers 115 pattern entries, 21 anti-patterns, a
10-dimension evaluation rubric and 30 canonical LLD problems, and it is MIT licensed.
How do I install it in Claude Code?
Clone the repo and copy one folder into your skills directory — there is no build step and no runtime dependency:
git clone https://github.com/00suryavanshi00/code-design-patterns.git cp -r code-design-patterns/skill/code-design-patterns ~/.claude/skills/
Use .claude/skills/ inside a repo for project scope, or
~/.claude/skills/ for every project. For Claude.ai and Cowork, upload the folder
under Settings → Capabilities → Skills. A packaged single-file
.skill bundle is also available in the repo’s dist/ folder.
How is this different from just asking Claude about design patterns?
Claude already knows the catalogue. What it does not do reliably is decline to use
it — so designs arrive with a Singleton nobody asked for, a Factory wrapping
new, and an Observer with no subscribers, while the race condition in the
allocation path goes unmentioned. This skill inverts the default. Every pattern in the output
must trace to a specific, stated force in the requirements; if the force cannot be named, the
pattern is removed before you see it. Its main job is subtraction, not addition.
Which design patterns does it cover?
All 23 Gang of Four patterns — Strategy, Factory Method, Abstract Factory, Builder, Prototype, Singleton, Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Template Method and Visitor — plus architectural patterns (dependency injection, repository, hexagonal / ports-and-adapters, CQRS, event sourcing, result types, plugin systems, feature flags), concurrency patterns (worker pool, pipeline, fan-out/fan-in, actor, single-writer, compare-and-swap, backpressure), distributed-resilience patterns (circuit breaker, retry with budget, hedged requests, bulkhead, saga, transactional outbox, idempotency key, five rate-limiting algorithms, expand-contract migration) and frontend component patterns (compound components, custom hooks, provider splitting, props getters, state reducers, error boundaries), persistence patterns (optimistic and pessimistic locking, isolation levels, write skew, unique constraints, conditional writes, aggregates as transaction boundaries, multi-tenant isolation) and API contract patterns (idempotent HTTP semantics, error contracts, pagination, compatible evolution, versioning, deprecation, webhooks). 115 entries in total, across eleven reference files.
What are tiers, and why is Singleton in the bottom one?
Patterns are ranked by how often they are actually the right answer in production code, not by how famous they are — ★★ confident, ★ situational, · last resort. The idea is borrowed from Christopher Alexander’s A Pattern Language, the 1977 book the Gang of Four took the term “design pattern” from, which rated its 253 patterns the same way. Singleton sits in the bottom tier because in most codebases it is global mutable state with a nicer name, and passing the dependency explicitly is both simpler and testable.
What anti-patterns does it detect?
Twenty-one code smells, each with a detectable signature and the smallest first refactoring move — including pattern-stuffing, god object, anemic domain model, primitive obsession, feature envy, shotgun surgery, leaky abstraction, singleton abuse, premature abstraction, boolean-parameter explosion, check-then-act races, and writing to a database and a queue as two separate commits. Pattern-stuffing is the one the whole skill exists to prevent.
Does it help with LLD and machine-coding interviews?
Yes. It ships a bank of 30 canonical low-level design problems — parking lot, elevator system, vending machine, rate limiter, LRU cache, Splitwise, chess, ATM, URL shortener, message queue and more. Each entry carries the axis of change, the patterns that legitimately fit, the plausible wrong answer, and the follow-up probe that breaks a memorised one. You can use it to practise, to generate problems, or as ground truth when grading a design out of 30.
Does it work with Cursor, Codex, or other AI coding agents?
It is built and tested for Claude — Claude Code, Claude Desktop, Claude.ai and Cowork.
Because it is plain Markdown in the SKILL.md convention with zero dependencies and
no runtime, any agent that reads SKILL.md folders can load it as-is; the routing
front-matter is the only Claude-specific part, and it degrades to an ordinary heading
elsewhere.
Is it free?
Yes — MIT licensed, free for personal and commercial use, no account, no telemetry, no network calls. The source is on GitHub.
How does the 10-dimension rubric work?
Before a design is shown to you, Claude scores it against ten dimensions — each 0–3,
for a total out of 30 — covering requirement traceability, the named axis of change,
cohesion and coupling, concurrency correctness, failure handling, testability, observability,
cost, simplicity, and whether every pattern used was justified. Automatic red flags, such as a
pattern with no named force or a Manager class, cap the total at 20 no matter how
the rest scores.
Code that names its forces
A Pattern Language ends at 253. What follows is set in its conventions because it owes them everything: the word pattern, the rating on the catalogue, and the idea that a form is worth naming only when it resolves a conflict of forces. Christopher Alexander wrote his entries for the people who would live in the buildings, not for architects. That is the ambition here too.
A catalogue of named solutions is easy to memorise and hard to use well.
Once the names are known they get reached for because they are known, and the design bends around the name instead of the problem. Alexander guarded against this twice. Every one of his 253 entries opens with the forces in tension and turns on the word Therefore, so the form arrives as a resolution rather than as a preference. And he rated his own work: two asterisks where he believed the pattern was a true invariant of the problem, one where he was less certain, none where he suspected a better solution was still out there. A catalogue that presents everything as equally right has stopped thinking.
The Gang of Four took the word in 1994 and left most of the rest behind. Twenty-three patterns arrived flat and alphabetical, and a generation learned the names without the weights. Thirty years of Singletons followed.
Weight each pattern by how often it is genuinely the right answer, make the force the price of admission, and let the design keep only what it can justify. If you cannot name the force, remove the pattern.
Christopher Alexander, Sara Ishikawa and Murray Silverstein, A Pattern Language: Towns, Buildings, Construction, Oxford University Press, 1977. The 253 patterns are his. The tiers, the asterisks and the word Therefore on this page are borrowed with the debt stated. Read it before you read another catalogue.