modular-design-principles
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 exe
npx skills add tech-leads-club/agent-skills --skill modular-design-principles --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# 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. --- ## The ten principles | # | Principle | Intent | |---|-----------|--------| | 1 | **Well-defined boundaries** | A small, stable **public surface**; everything else is intern
- What to load
- Layered mental model
- The ten principles
- Typical violations (stated abstractly)
- Creating a bounded context (workflow)
- When to split or merge
- Six-criteria test (favor split when several are true)
- When to merge or not split yet
- Decision prompts (short)
- Sub-units inside a bounded context
- Architecture compliance pass
- Dependency and API signals
- Persistence and data signals
- Operational signals
What does the modular-design-principles skill do?
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 exe
How do I install it?
Run `npx skills add tech-leads-club/agent-skills --skill modular-design-principles --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From tech-leads-club/agent-skills, a repository with 4,983 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.