Module design

Skill yuri-semenenko/ai-engineering-workspace/codex/skills/module-design

Use when designing or reviewing a module or interface boundary, extracting a helper or wrapper, or deciding whether an abstraction is worth it. Favors deep modules, information hiding, and composition over speculative layering.From its SKILL.md

Install

npx -y skills add yuri-semenenko/ai-engineering-workspace --skill module-design

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

1.8 KB, 306 tokens by cl100k_base, as published. Nobody here has run it

Module Design

Shape modules so a small, stable interface hides substantial implementation. The unit of design is the interface a caller sees, not the code behind it. Add an abstraction only when it earns the indirection it introduces.

What a deep module looks like

Small interface, substantial body: much hidden behind little exposed. Depth is a property of the interface, not the line count.
Callers depend on what it does, never on how. A change to the implementation must not ripple outward.
The interface is the test surface. If it is hard to test without reaching inside, the boundary is wrong.

Design moves

Deletion test: if removing the module scatters its knowledge back into callers, it encapsulates nothing — inline it.
Adapter rule: one implementation behind an abstraction is a hypothetical seam; two is a real one. Add the interface when the second appears.
Inject dependencies and return results rather than reaching for globals or firing hidden side effects.
Push complexity down (absorb hard cases) instead of out (handing edge cases back to every caller).

Guardrails

Prefer composition of small functions over inheritance and framework hooks.
Refuse the shallow wrapper, the premature adapter, configuration-driven indirection no caller varies, and interfaces that leak internal types or state.
Present the simplest shape first and justify every layer against its indirection cost.
Distinct from architect (system-level decisions) and rfc: this is about one module's interface.

What ships with it: 1 file

181 B alongside SKILL.md

agents/

openai.yaml181 B

Gives 0 of the 12 instructions most design frontend skills give in 306 tokens

Counted across 1,169 of the 1,878 authors here whose files we hold, read 2026-08-07

Use CSS variables for color consistencyin 72 of 1169, across 23 files
Commit to one bold aesthetic direction before codingin 72 of 1169, across 27 files
Match implementation complexity to the aesthetic visionin 70 of 1169, across 20 files
Add atmospheric background effects and texturesin 57 of 1169, across 9 files
Use unexpected spatial compositions and layoutsin 56 of 1169, across 8 files
Implement real working codein 55 of 1169, across 7 files
Vary themes and aesthetics across different designsin 48 of 1169, across 7 files
Launch chromium in headless modein 47 of 1169, across 4 files
Close the browser when donein 47 of 1169, across 4 files
Run provided scripts with help flag firstin 47 of 1169, across 4 files
Wait for network idle statein 47 of 1169, across 4 files
Use descriptive selectors for elementsin 47 of 1169, across 4 files

Said here and by no other author read

add abstraction only when it earns its indirection
inline modules that encapsulate nothing
add interface only when a second implementation appears
inject dependencies and return results
push complexity down into the module
prefer composition of small functions over inheritance

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.