code-design-patterns
★★ Pattern 254 A Claude Skill
MIT · v1.2.0

code-design-patterns

A Claude Skill for software design patterns — 115 pattern entries, 21 anti-patterns, a 10-dimension design rubric and 30 low-level design problems, in plain Markdown. Works in Claude Code, Claude Desktop and any agent that reads SKILL.md.


Claude already knows the pattern 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.

Therefore

Give Claude the forces, the tiers, and a rubric it must score itself against — so that every pattern in the output traces back to a stated requirement, and the ones that cannot get deleted before you ever see them.

★★ Strategy Behavioural
Force

An algorithm or policy must vary, independently of the code that uses it.

Seen in

Kubernetes scheduler plugins. Sorting comparators. Retry policies. Pricing and allocation rules.

Not this when

The strategy has no state and the language has first-class functions — pass the function. A one-method interface is a function with paperwork.

$ git clone https://github.com/00suryavanshi00/code-design-patterns.git && cp -r code-design-patterns/skill/code-design-patterns ~/.claude/skills/

Prefer a single file? Grab the packaged .skill and drop it straight into your skills folder.

★★ ★ ·

The stars are a confidence rating, not decoration. They are Christopher Alexander's: in A Pattern Language he marked a pattern with two asterisks where he believed it was a true invariant of the problem, one where he was less sure, and none where he suspected a better solution was still out there. This skill rates the software catalogue the same way, by how often a pattern is actually the right answer in production code rather than by how famous it is. The debt is paid in full at the end of the page.

01What gets installed

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.

code-design-patterns/ ├── SKILL.md workflow · tiers · routing └── references/ ├── 01-gof-catalog 23 patterns, with sightings ├── 02-modern-application DI · repository · hexagonal · CQRS ├── 03-concurrency pools · single-writer · CAS · backpressure ├── 04-distributed-resilience breakers · hedging · outbox · idempotency ├── 05-frontend-patterns compound components · hooks · boundaries ├── 06-antipatterns 21 smells + first refactoring move ├── 07-evaluation-rubric 10 dimensions, scored /30 ├── 08-lld-question-bank 30 problems · traps · probes ├── 09-operability test · observe · cost · RED & USE ├── 10-persistence locking · isolation · tenancy └── 11-api-contract idempotent HTTP · versioning · webhooks
115Pattern entries
21Anti‑patterns
30LLD problems
2,990Lines of skill
02What actually changes

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.

Without the skill
  • Singleton ParkingLotManager, unexplained
  • VehicleFactory over 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
With the skill
  • 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
  • Money value object; Clock injected
  • Pattern ledger: force resolved, alternative rejected
  • One metric per pattern, and what would page someone
03The catalogue

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.

★★ Confident reach for these freely
StrategyFactory MethodBuilder AdapterDecoratorObserver StateTemplate MethodCommand IteratorFacadeComposite ProxyDependency InjectionRepository Middleware chainWorker PoolCircuit Breaker Retry + budgetExpand-contractCache-asideIdempotency Key Value Object
★ Situational right in specific conditions — suspicious otherwise
Abstract FactoryChain of Responsibility VisitorMediatorBridge MementoFlyweightObject Pool SpecificationNull ObjectUnit of Work CQRSEvent SourcingSaga ActorBulkheadOutbox Leader ElectionHedged RequestsSingle-writer
· Doubtful usually a smell — needs an unusually good justification
SingletonPrototypeInterpreter Service LocatorAnemic Domain Model Double-checked lockingDual writes
Ref 01

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.

Ref 02

Architecture & application

DI without a container, Repository without wrapping your ORM twice, ports & adapters, CQRS, event sourcing, result types, plugin systems, feature flags.

Ref 03

Concurrency

Worker pools, pipelines, fan-out/fan-in, actors, the single-writer principle, CAS, backpressure — plus the nine bugs reviewers actually look for.

Ref 04

Distributed & resilience

Circuit breakers, deadline budgets, retry budgets, hedged requests, bulkheads, five rate-limiting algorithms, sagas, the outbox, expand-contract migration.

Ref 05

Frontend components

Compound components, custom hooks, provider splitting, props getters, state reducers, error boundaries — and why eleven boolean props is a design bug.

Ref 06

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.

Ref 09

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.

Ref 10

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.

Ref 11

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.

04The evaluator

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.

Design scorecard— / 30
  • 01
    Requirements fidelity

    Requirements enumerated and traceable; ambiguities named rather than silently resolved.

  • 02
    Responsibility allocation

    Boundaries follow reasons for change, not merely topic similarity.

  • 03
    Extensibility on the stated axis

    Adding the likely variant touches two files or fewer — demonstrated, not claimed.

  • 04
    Interface quality

    Minimal, consumer-owned, hard to misuse. Illegal states unrepresentable.

  • 05
    Pattern selection

    Caps at 1 if any pattern cannot be traced to a stated requirement.

  • 06
    Concurrency correctness

    What is shared, what the atomic unit is, and no lock held across I/O.

  • 07
    Failure handling

    Partial failure reasoned about: what is idempotent, what compensates, what the caller sees.

  • 08
    Testability & observability

    Clock and randomness injected; and one metric per breaker, queue or cache, with what would page someone.

  • 09
    Data modelling

    Invariants enforced at construction; persistence shape not dictating domain shape.

  • 10
    Trade-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 Manager or Helper
  • A breaker, queue or cache with no stated metric
  • Writing to a database and a queue as two separate commits
05The question bank

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.

01Parking Lot
02Elevator System
03Vending Machine
04Rate Limiter
05LRU / LFU Cache
06Notification System
07Library Management
08Splitwise
09Movie Ticket Booking
10Chess
11Logging Framework
12ATM
13Ride-Hailing Dispatch
14Food Delivery
15Cart & Checkout
16Digital Wallet
17Message Queue
18URL Shortener
19Task Scheduler
20KV Store with TTL
21Custom HashMap
22Text Editor + Undo
23Board Game Engine
24Inventory Management
25Hotel Booking
26Social Media Feed
27Chat Application
28File System Metadata
29Payment Gateway Layer
30Feature Flag Service
06Install

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.”
07Questions

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.

254 ★★

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.

FORCE FORCE FORCE FORM DESIGN
Every entry in the book ends in a diagram. This one is the whole rule: the forces come first, and a form is what resolves them.
Therefore

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.