Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add yuri-semenenko/ai-engineering-workspace --skill module-designgit clone --depth 1 https://github.com/yuri-semenenko/ai-engineering-workspaceWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/yuri-semenenko/ai-engineering-workspace/module-design)<a href="https://agentmods.dev/skills/yuri-semenenko/ai-engineering-workspace/module-design"><img src="https://agentmods.dev/badge/skills/yuri-semenenko/ai-engineering-workspace/module-design/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/yuri-semenenko/ai-engineering-workspace/module-design"><img src="https://agentmods.dev/badge/skills/yuri-semenenko/ai-engineering-workspace/module-design.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.01001 |
| Opus 5.5 | $0.00000 | $0.00400 |
| Sonnet 5.5 | $0.00000 | $0.00200 |
| Haiku 4.5 | $0.00000 | $0.00100 |
Grade A, and why
module-design scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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. Favor composition and explicit data flow; add an abstraction only when it earns the indirection it introduces.
Rationalizations
| Rationalization | Rebuttal |
|---|---|
| "I'll wrap it now so it's easy to swap later." | One implementation is a hypothetical seam. Wrap it when the second arrives, not before. |
| "More layers means cleaner separation." | Layers are cost. A layer that only forwards calls adds surface without hiding anything. |
| "The interface should expose everything, just in case." | A wide interface leaks the implementation and freezes it. Expose what the caller needs; hide how. |
| "It's more flexible with a config object or a strategy." | Configurable indirection is complexity you pay for on every read. Flexibility no caller uses is dead weight. |
What a deep module looks like
- Small interface, substantial body. The value is the ratio: much hidden behind little exposed. Depth is a property of the interface, not the line count.
- Information hiding. Callers depend on what it does, never on how. A change to the implementation must not ripple outward.
- The interface is the test surface. A small, honest interface is the natural seam to test through. If it is hard to test without reaching inside, the boundary is wrong.
Design moves
- Deletion test. If you removed the module, would its knowledge scatter back into callers? If nothing leaks, it was not encapsulating anything — inline it.
- Adapter rule. One implementation behind an abstraction is a hypothetical seam; two is a real one. Introduce the interface when the second appears, not in anticipation of it.
- Inject dependencies, return results. Prefer functions that take what they need and return a value over ones that reach for globals or fire hidden side effects. Testability follows for free.
- Push complexity down, not out. A module earns its keep by absorbing hard cases so callers do not repeat them. A module that hands its edge cases back to every caller is shallow.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 56 lines · 0 tokens per session scan A 4ca974089e7a
module-design is a skill published in the GitHub repository yuri-semenenko/ai-engineering-workspace (4 stars, last pushed 1mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,001 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
spec-kitty-charter-doctrine
Run charter interview, generation, context, and sync workflows for project governance in Spec Kitty 3.x. Access doctrine artifacts programmatically via DoctrineService. Resolve agent profiles. Load action-scoped governance context iteratively, not all at once. Triggers: "interview for charter", "generate charter"…
110-java-maven-best-practices
Use when you need to review, improve, or troubleshoot a Maven pom.xml file — including dependency management with BOMs, plugin configuration, version centralization, multi-module project structure, build profiles, or any situation where you want to align your Maven setup with industry best practices. This should…
128-java-generics
Use when you need to review, improve, or refactor Java code for generics quality — including avoiding raw types, applying the PECS (Producer Extends Consumer Super) principle for wildcards, using bounded type parameters, designing effective generic methods, leveraging the diamond operator, understanding type erasure…
322-frameworks-spring-boot-testing-integration-tests
Use when you need to write or improve integration tests — including Testcontainers with @ServiceConnection, @DataJdbcTest persistence slices, TestRestTemplate or MockMvcTester for HTTP, data isolation, and container lifecycle management for Spring Boot 4.0.x. This should trigger for requests such as Review Java code…
422-frameworks-quarkus-testing-integration-tests
Use when you need to write or improve integration tests for Quarkus — including @QuarkusTest, Dev Services for automatic container provisioning, Testcontainers via QuarkusTestResourceLifecycleManager, WireMock for external HTTP stubs, @QuarkusIntegrationTest for black-box testing against packaged artifacts, REST…
521-frameworks-micronaut-testing-unit-tests
Use when you need to write unit tests for Micronaut applications — Mockito-first with @ExtendWith(MockitoExtension.class), @MicronautTest with @MockBean, HttpClient @Client(/) assertions, @Property overrides, @ParameterizedTest, and Test vs IT naming. For framework-agnostic Java use @131-java-testing-unit-testing.…