Modular Design Principles
Technology-agnostic guidance for modular systems: bounded contexts, clear boundaries...
Install
npx skills add tech-leads-club/agent-skills --skill modular-design-principles -g -a claude-code -y- Repository
- tech-leads-club/agent-skills7.1k
- Category
- Design
- Updated
- 3d ago
- License
- See repository
- Context cost
- Mediumabout 2,840 tokens
- Runs scripts
- No, instructions only
What it does
Technology-agnostic guidance for modular systems: bounded contexts, clear boundaries, composability, state isolation, explicit contracts, failure containment, scaffolding workflows, split/merge criteria, sub-units inside a context, and compliance review signals. Use when designing or reviewing module structure, service boundaries, package layout, cross-cutting dependencies, "how should we split this?", modularity assessments, coupling between domains, greenfield context design, or architecture discussions without assuming a specific framework, language, or repository layout. Do NOT use for executing the full Patterns 1, 5 repo decomposition pipeline or per-pattern inventories (use modular-decomposition), phased extraction roadmaps as the main deliverable (use decomposition-planning-roadmap), or end-to-end legacy migration strategy (use legacy-migration-planner).
Modular Design Principles
Use this skill when reasoning about structure and boundaries in any codebase. It intentionally avoids framework names, folder conventions, and tooling, map principles to your stack locally.
What to load
| Task | Where |
|---|---|
| Principles table + violations + workflows (this file) | SKILL.md |
| Per-principle definition, agent rules, abstract examples | references/principles.md |
Layered mental model
- Composition roots (applications, hosts, runners): wire modules together; keep orchestration thin.
- Modules / bounded contexts: cohesive units of behavior and data ownership; each should be understandable and testable on its own.
- Shared kernels (use sparingly): only stable, truly cross-cutting concepts; resist turning them into a grab-bag of “everything everyone needs.”
How you physically lay this out (mono repo, multi repo, packages, libraries) is a delivery choice, not the definition of modularity. The principles below still apply.
