★★ Pattern 001 A Claude Skill
MIT · v1.1.0

code-design-patterns

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 Gang of Four took the phrase “design pattern” from Christopher Alexander, whose 1977 book rated each of its 253 architectural patterns with asterisks — two where he believed the pattern was a true invariant, one where he was less sure, none where he suspected a better solution existed. This skill does the same thing to the software catalogue. Patterns are weighted by how often they are actually the right answer in production code, not by how famous they are.

01What gets installed

One folder. Nine 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 eight 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
104Patterns
21Anti‑patterns
30LLD problems
2,270Lines 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.

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