From dotnet
Measure and validate a modular monolith design in .NET 10 — afferent coupling (who calls into this module), efferent coupling (what this module calls out to), cohesion (do this module's types address one purpose). Names god modules (high efferent coupling everywhere) and false splits (two modules coupled tightly enough that they're one module pretending). One tool in the modular-monolith toolbox — reach for it to validate a design before implementation, or to re-evaluate one that has accumulated drift. Use when the user asks "is this design coherent", "should I split this module", "should I merge these two modules", "is this module doing too much", or any post-design validation question. Status: placeholder. Target stack: .NET 10 / C# 14.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dotnet:modular-coupling-cohesionThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **Status — placeholder.** Scaffolded; deep content to be written. For the working methodology today, use [`modular-monolith`](../modular-monolith/SKILL.md) — this skill is one tool in its toolbox.
Status — placeholder. Scaffolded; deep content to be written. For the working methodology today, use
modular-monolith— this skill is one tool in its toolbox.
A modular design is a hypothesis: the modules as drawn cohere internally and couple to each other in a way the team can live with. Validation makes the hypothesis testable. Without numbers — even rough ones — every disagreement about whether a module is too big, too entangled, or mis-shaped degrades into preference.
Coupling is not zero; that is an isolated module that does nothing. Coupling is informed: every cross-module edge has a reason, and the reason is named. Cohesion is the dual: the things this module owns address one purpose. The interesting failures live in the gap — a module with acceptable coupling counts and incoherent ownership (god module), or a module whose nominal split from another is contradicted by constant reach-across (false split).
Engineers on .NET 10 running design review on a modular monolith design before implementation, and engineers re-evaluating a design that has accumulated drift.
modular-design.modular-solid.DomainEvent inversionmodular-monolith — orchestrator; this skill is one tool in its toolboxmodular-design — produces the topology this skill measuresmodular-solid — surfaces public-surface issues this skill quantifies in coupling countsnpx claudepluginhub marafiq/dotnet-skillsCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.