patterns
Skill1 starsChanged 6 days agoMITView on GitHub
Use when structuring or restructuring code: designing a feature or module, refactoring, choosing an architecture or layering, deciding between patterns (repository, strategy, factory, observer, state machine, dependency injection), or when asked "how should I structure this?" or "is this a good design?".
15 other projects use a version of this.
Adopted by
Most recently taken up by
- anthropics/claude-plugins-officialtheir own version, first seen Nov 8, 2026
- nklisch/skilltaptheir own version, first seen Nov 8, 2026
- tizonai/hyperuitheir own version, first seen Oct 9, 2026
- nklisch/krometrailtheir own version, first seen Sep 30, 2026
- ai-analyst-lab/ai-analysttheir own version, first seen Sep 10, 2026
- eklavyagoyal/wingmantheir own version, first seen Sep 10, 2026
Used with
Projects with it also use setup.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
VercelSkillsetup
Set up Vercel CLI and project configuration. Use when the user says "set up Vercel", "configure Vercel", "link to Vercel", or "vercel init".
Also in 3 projects that use this
Other versions15 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 15
- anthropics/claude-plugins-official★ 46ksame name
- ai-analyst-lab/ai-analyst★ 304same name
- nklisch/claude-code-modes★ 116same name
- mycelium-hq/ai-brain-starter★ 50same name
- jmylchreest/aide★ 19same name
- zllovesuki/cloudflare-agent-skills★ 9same name
- nklisch/skills★ 8same name
- nklisch/skilltap★ 7same name
- Lukasbrujula/claude-code-framework★ 4same name
- nklisch/krometrail★ 3same name
5 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 5 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 11 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Read how the codebase already solves this kind of problem, and follow it unless it's the problem.
- Distinctive: line 16
Start from the simplest code that works: functions and data.
- Distinctive: line 17
Prefer composition over inheritance, and small interfaces owned by their consumer.
- Distinctive: line 25
Keep side effects (IO, time, randomness) at the edges and pass their results in, so the core stays pure and testable.
- Distinctive: line 42
Keep state as local as possible.
“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Design patterns
Patterns are answers to specific pressures. Name the pressure first; if it isn't there, the plain version is the right design. Recommend, explain the tradeoff in a sentence, and match what the codebase already does.
How to decide
- Read how the codebase already solves this kind of problem, and follow it unless it's the problem.
- Start from the simplest code that works: functions and data. Add structure only for a pressure you can point to: a second implementation that exists now, a test that can't be written, a change that keeps touching the same five files.
- Prefer composition over inheritance, and small interfaces owned by their consumer.
- Say what the design costs: indirection, files, concepts to learn.
Architecture
- Layers: presentation (UI, controllers) → domain/application (use cases, rules) → data (repositories, clients). Dependencies point inward; the domain imports nothing from the outer layers.
- Organize by feature (
auth/,tags/) before organizing by layer, once a project has more than a handful of features. - Dependency injection through constructors. A DI framework only when the project already uses one or the wiring has outgrown a composition root.
- Keep side effects (IO, time, randomness) at the edges and pass their results in, so the core stays pure and testable.
Patterns worth knowing, and their signal
| Pattern | Use when | Not when |
| Repository | data access must be swappable or faked, or several sources (cache + network) sit behind one source of truth | one simple query used in one place |
| Strategy | several interchangeable algorithms chosen at runtime | there's one algorithm and a hypothetical second one |
| Factory | construction is complex, conditional, or must hide the concrete type | a constructor call says it all |
| Adapter | wrapping a third-party API so its types don't leak into your code | the API is already yours |
| Observer / streams | many consumers react to changes (Flow, Combine, signals, events) | one caller can just call a function |
| State machine | an object moves through states with rules about transitions (auth, connections, game sessions) | two booleans would do, and will stay two |
| Result / sealed outcomes | callers must handle distinct failure cases | the failure is a bug and should throw |
| Builder | many optional parameters in a language without named or default arguments | Kotlin, Swift, TypeScript: use named/default parameters |
Frontend state
- Keep state as local as possible; lift it only to the nearest common owner.
- Server state (fetched data) is a cache, not app state: use the framework's query/cache layer rather than copying it into a store.
- One source of truth per piece of state, with derived values computed, not stored.
API design
- Model the domain, not the database. Resource-oriented REST with consistent naming, or RPC when operations don't map to resources.
- Version the contract explicitly once there are external consumers; never break a published shape silently.
- Validate at the boundary, return typed errors with stable codes, and paginate every list.
Red flags to call out
God classes and "Manager"/"Helper" grab-bags, interfaces with exactly one implementation and no test seam, inheritance deeper than two levels, singletons holding mutable state, abstractions named for patterns instead of the domain (AbstractFactoryProvider), and speculative generality.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.