| name | adopt-pattern |
| description | Use when a developer wants to apply a low-level, systems, or concurrency design pattern in their own code, drawing on the Battle-Tested Patterns catalog of 46 production-proven patterns. Triggers three ways: they name a pattern (ring buffer, circuit breaker, actor model, LRU cache, rate limiter, trie, bloom filter, WAL, semaphore, ...); they describe a problem one solves without naming it (fixed-size buffer that overwrites the oldest entry, cascading failures across services, throttling requests, deduplicating identical strings, ordering events without wall-clock time, snapshot isolation, prefix search, set membership without storing every key, ...); or they ask which pattern fits a problem or how two related patterns differ. |
Adopt a Pattern
Overview
The Battle-Tested Patterns catalog documents 46 patterns, each in a GitHub
source doc (URLs in the catalog below) with a When to Use / When NOT to Use /
Related Patterns decision guide, a Production Proof table of real source
links, and a multi-language Implementation. Those doc pages are the source
of truth — fetch the relevant one rather than relying on memory. This skill
routes a developer's problem to the right pattern and then drives a disciplined
adoption into their codebase; it does not reproduce the pattern content here.
Two principles do the work:
- A pattern is only worth adopting if it fits — the common failure is
reaching for a named pattern that doesn't match the problem; the fit-gate
catches that before any code is written.
- A pattern adopted without a durable test for its invariant is not done —
a correct-looking implementation that leaves no regression test lets the
invariant rot on the next edit. The verify step leaves that test behind.
When to use
- A developer names a pattern and wants it in their code.
- A developer describes a problem (see the catalog cues) without naming a pattern.
- A developer asks "which pattern fits?" or "X vs Y — which?".
When NOT to use: general feature work with no pattern in play, or a problem
no catalog entry matches (say so plainly rather than forcing a fit).
Workflow
Work the four steps in order. Do not skip the fit-gate.
1. Match
Map the problem to candidate patterns using the catalog below. If the developer
named a pattern, still confirm it against the cue. If a problem matches several
(e.g. "throttle requests" → Rate Limiter, Semaphore, Backpressure), keep 2–3
candidates for the fit-gate.
2. Fit-gate
Fetch only the candidate patterns' doc pages (the Doc URL in the catalog)
and focus on When to Use, When NOT to Use, and Related Patterns.
- If the pattern fits, continue to step 3.
- If
When NOT to Use describes the developer's situation, stop and steer
to the better-fit pattern named in Related Patterns. Explain why in one or
two sentences.
- If nothing fits, say so. Do not adopt a pattern to satisfy the request.
Do not fetch all 46 docs. Fetch the 1–3 you are actually deciding between.
3. Adapt
Read the chosen doc's Implementation (in the developer's language) and skim
Production Proof for how real systems shape it. Then write it into their
codebase — match their naming, types, error handling, and module boundaries.
- Adapt, do not copy-paste. The reference impl is a teaching version; production
code needs the project's conventions and edge-case handling.
- Carry over the invariants the doc calls out (e.g. a ring buffer's overwrite-on-
full rule, a circuit breaker's half-open probe). Those are the point.
4. Verify — leave a durable invariant test
This is where adoption is won or lost: a capable agent will usually pick the
right pattern and implement it correctly, then "confirm it works" with a
throwaway check and move on — leaving nothing that protects the invariant on the
next edit.
Write a focused test as a committed file in the developer's own project and
runner that exercises the pattern's defining behavior — use the doc's Exercises
and Challenge Questions as a checklist of cases (the boundary conditions, not
the happy path). Run it. An inline or throwaway check does not count. A pattern
adopted without a durable test for its invariant is not done.
Pattern catalog
Each row links to the pattern's doc source on GitHub — fetch it during the fit-gate.
(Maintainers: this block is generated; see the skill's source repo.)
46 patterns. Match the developer's problem to a row, then fetch only that pattern's doc URL.
🧠 Data Structures
⚡ Concurrency
🏗️ Systems
♻️ Memory
🔄 Behavioral
Common mistakes
- Skipping the fit-gate because the developer named a pattern. Named ≠ correct
— confirm against
When NOT to Use first.
- Copy-pasting the reference implementation verbatim. It teaches the shape; it
is not drop-in production code.
- Loading many pattern docs at once. Match from the catalog cues, then open
only the 1–3 candidates.
- Choosing by familiarity ("I know LRU") instead of fit. Check
Related Patterns — the better tool is often one row away.
- Declaring done without a test for the pattern's invariant.
Example
Developer: "Downloads are hammering the API — I want to cap it at 5 in flight."
- Match — "cap concurrent access" → candidates: Semaphore, Rate Limiter,
Backpressure.
- Fit-gate — the Semaphore doc's
When to Use directly lists "control
access to a fixed number of resources" and "limit concurrent network
requests" — a concurrency cap, which is what the developer asked for. Rate
Limiter's When to Use governs rate over time (API rate limiting, traffic
shaping), a different axis. → Semaphore.
- Adapt — port the doc's TypeScript semaphore into their download module,
wrapping the fetch call in
acquire()/release() with their existing
error/cleanup handling so a failed download always releases its permit.
- Verify — test that with the cap at 5 and 20 queued downloads, no more than
5 run concurrently and all 20 eventually complete.