← ClaudeAtlas

codebase-designlisted

Deep-module design for choosing a small, testable interface at a clean seam. Use when the design question is a module's interface, seam, depth, or test surface, or when another skill needs these terms. NOT diff review (`review`) or requirement discovery (`grill`).
panda850819/verbs · ★ 5 · Web & Frontend · score 77
Install: claude install-skill panda850819/verbs
# Codebase Design Design **deep modules**: a lot of behaviour behind a small interface, placed at a clean seam, testable through that interface. The aim is leverage for callers, locality for maintainers, and testability for everyone. Use these terms exactly — consistent language is the point. ## Glossary - **Module** — anything with an interface and an implementation; deliberately scale-agnostic (a function, class, package, or tier-spanning slice). _Avoid_: unit, component, service. - **Interface** — everything a caller must know to use the module correctly: the type signature, plus invariants, ordering constraints, error modes, required configuration, and performance characteristics. _Avoid_: API, signature (type surface only). - **Implementation** — what's inside the module. - **Depth** — leverage at the interface: how much behaviour a caller (or test) can exercise per unit of interface learned. Deep = small interface, lots behind it; shallow = interface nearly as complex as the implementation. - **Seam** _(Michael Feathers)_ — a place where behaviour can be altered without editing in that place; where a module's interface lives. Placing the seam is its own design decision, distinct from what goes behind it. _Avoid_: boundary (collides with DDD's bounded context). - **Adapter** — a concrete thing satisfying an interface at a seam. Names the role it fills, not the substance inside. - **Leverage** — what callers get from depth: one implementation pays