From dotnet
Inventory candidate modules in a .NET 10 modular monolith — name them, draw the dependency graph, decide module physicality (.csproj vs folder vs namespace). One tool in the modular-monolith toolbox — reach for it to decide what the modules ARE and what they are called. Use when the user asks "how should I split this into modules", "what should this module be called", "should this be a separate project", or any topology-shaping question. Status: placeholder — uses the orchestrator's working summary until deep content is written. Target stack: .NET 10 / C# 14 / ASP.NET Core MVC 10.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dotnet:modular-designThe 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.
Modular design starts with a list. Without a written inventory of candidate modules and the dependencies between them, every later decision (where DDD earns rent, how to slice features, what crosses a boundary) is made against imagined topology. The first artifact a design produces is a map: module names, what each module owns, which other modules each one calls.
Naming and physicality are the two hard parts. Names compress the design's intent into a single word that downstream code, tests, and conversation will inherit; bad names cost forever. Physicality — .csproj vs folder vs namespace — trades build-time isolation for friction; the right level depends on team size, enforcement strategy, and whether modules need to build independently.
Engineers on .NET 10 in the planning phase of a new feature area or a legacy modernization carve-out, working in C# 14.
modular-ddd-classifier artifact when modernizing from .NET 4.8 source.Common, Shared, Utils, Manager, Helper).csproj vs folder vs namespace; when each pays for itselfmodular-shared-language consumes from this artifactmodular-monolith — orchestrator; this skill is one tool in its toolboxmodular-shared-language — aligns terms across the modules this skill namesmodular-ddd-classifier — produces the legacy-mining artifact this skill consumes when modernizingmodular-coupling-cohesion — validates the topology this skill producesnpx 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.