code-design-patternslisted

# Code Design Patterns Patterns are a vocabulary for trade-offs, not a checklist to satisfy. The failure mode this skill exists to prevent is pattern-stuffing: producing a design with a Factory, a Singleton, and an Observer bolted on because those are the famous names, when the problem called for one interface and a function. The bar to clear: **every pattern in the output must be traceable to a specific, stated force in the requirements.** If you cannot name the force, remove the pattern. ## What this skill is and is not for **In scope:** the design of classes, modules, components and the boundaries between services — the level at which patterns, interfaces and contracts are the decision. **Out of scope, and worth saying so rather than half-answering:** capacity estimation and back-of- envelope maths, cluster and storage sizing, picking a database or broker product, network topology, CAP-theorem-shaped "design Twitter/YouTube" system design, algorithm and data-structure selection, and security auditing. "Design a rate limiter that works across ten nodes" is this skill — the patterns and the correctness argument. "How many nodes, and Redis or Cassandra?" is not; answer that from general knowledge, without pulling this workflow into it. The reason the line matters: a design question that gets the full workflow when it needed two sentences is the same waste as a pattern that gets added because it is famous. ## Workflow **Scale the ceremony to the question first.** The s