
Modular Decomposition
FreeStreamline your monolith into modular components effectively.
Free · Opens the source repo
What Modular Decomposition does
The Modular Decomposition skill is designed to assist developers in breaking down monolithic applications into more manageable, modular components. This skill runs a structured analysis pipeline consisting of five distinct patterns, each focusing on a specific aspect of the decomposition process. By executing this skill, users can identify and size components, detect common domain logic, analyze module coupling, and group components into domain-aligned units. This methodical approach ensures that the resulting architecture is not only cleaner but also more aligned with business needs.
Each pattern in the pipeline is documented in detail within the bundled references, allowing users to follow along and understand the implications of each step. The process begins with identifying and sizing components, which serves as a foundation for subsequent analyses. As the user progresses through the pipeline, they will uncover shared domain logic and hierarchy issues, which can significantly impact the modularization effort. The final step involves grouping components into candidate services, with an optional focus on Domain-Driven Design (DDD) principles to ensure that the resulting services align with business contexts.
This skill is particularly beneficial for teams looking to modernize their legacy applications or improve the maintainability of their codebases. It provides a clear, actionable framework for addressing common challenges associated with monolithic architectures, such as duplicated logic and tightly coupled components. By utilizing this skill, teams can achieve a more organized and efficient development process, setting the stage for future enhancements and scalability.
When to use it
Use this skill when you need to analyze a monolith for potential modularization, focusing on component sizing, duplication detection, and service grouping.
When not to use it
This skill is not suitable for creating phased extraction roadmaps or full legacy migration strategies; for those needs, consider using decomposition-planning-roadmap or legacy-migration-planner instead.
What you can build with it
Analyzing a Monolith for Modularization
A team wants to refactor their large monolithic application. They run the full decomposition analysis to identify components and their relationships.
Detecting Duplicated Logic
After a code audit, a developer uses the skill to find duplicated domain logic across modules, helping to streamline the codebase.
Grouping Components with DDD
A project manager requests to group components into services based on business domains, utilizing the DDD lens provided by the skill.
How to install Modular Decomposition
View source1. Install with the skills CLI
npx skills add tech-leads-club/agent-skills/modular-decomposition --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by tech-leads-clubModular Decomposition
This skill runs the Patterns 1–5 analysis pipeline before service extraction. Each pattern is plain markdown under references/; load the file for that step and execute it against the user’s codebase.
How to Use
Quick start (what users can say)
- Full pipeline: “Run modular decomposition Patterns 1 through 5 on this repo,” “Analyze this monolith for splitting—inventory, coupling, and domain grouping.”
- Single early step: “Identify and size components here,” “Find duplicated domain logic across modules,” “Analyze coupling between our packages.”
- With DDD lens: “Group components into domains and check bounded contexts,” “Use DDD strategic design on this codebase before we group services.”
If the user only wants extraction order, phases, or migration roadmap after analysis exists, use decomposition-planning-roadmap instead. If they need a full legacy migration plan (strangler fig, research, multi-stack), use legacy-migration-planner as well or instead of this skill when that is the primary ask.
How the agent should run it
- Scope: Confirm the task is structural analysis (inventory → coupling → grouping), not roadmap authoring. If unclear, ask once whether they want the full ordered pipeline or a subset.
- Order: Run patterns 1 → 2 → 3 → 4 → 5 in that order. Do not skip a step unless the user explicitly limits scope; if they do, state which patterns were skipped and how that limits later conclusions.
- Load references: For each pattern, open the matching
references/pattern-NN-*.mdfile and follow its instructions. Use the optional*-quick-reference.mdfor the same number when a short checklist is enough. - Carry context forward: Reuse outputs from earlier patterns in later ones (e.g. component inventory from Pattern 1 informs coupling in 4 and grouping in 5). Reference concrete paths, modules, or tables from previous steps.
- Domain language (Pattern 5): If subdomains or bounded contexts need grounding beyond structure, read
references/domain-analysis.mdbefore or alongside Pattern 5. Optionally openreferences/domain-analysis-quick-reference.mdorreferences/domain-analysis-examples.mdfor condensed rules or illustrations. - Deliver: Produce clear, actionable findings per pattern or one consolidated report—always tied to evidence from the repository (files, dependencies, metrics), not generic advice.
Usage examples
Example 1 — Full pipeline
User: "We're going to split this monolith—run the full decomposition analysis (Patterns 1–5)."
Agent: Execute patterns 1→5 in order, loading each references/pattern-NN-*.md, preserving outputs between steps, then summarize cross-cutting recommendations.
Example 2 — Coupling after inventory
User: "We already have a rough module list—focus on coupling (Pattern 4) and then domain grouping (Pattern 5)."
Agent: If no prior inventory exists in the thread, either run Pattern 1 briefly or derive an explicit module list from the repo before 4 and 5. State any assumptions.
Example 3 — DDD before grouping
User: "Map bounded contexts and language, then group components into domains."
Agent: Read references/domain-analysis.md (and optional quick reference/examples) in parallel with or immediately before Pattern 5; align Pattern 5 groupings with linguistic boundaries where evidence supports it.
Prerequisites
- Complete Pattern N before starting Pattern N+1 unless the user explicitly narrows scope. Later patterns depend on earlier results (for example, inventory and structure inform coupling and grouping).
- If business vocabulary, subdomains, or bounded contexts are uncertain, use
references/domain-analysis.mdbefore or alongside Pattern 5 (see Bounded contexts below).
Ordered workflow (Patterns 1–5)
| Step | Pattern | Primary reference |
|---|---|---|
| 1 | Identify and size components | references/pattern-01-identify-and-size.md (optional: pattern-01-identify-and-size-quick-reference.md) |
| 2 | Common domain detection | references/pattern-02-common-domain.md (optional: pattern-02-common-domain-quick-reference.md) |
| 3 | Flattening / hierarchy | references/pattern-03-flattening.md (optional: pattern-03-flattening-quick-reference.md) |
| 4 | Coupling analysis | references/pattern-04-coupling.md |
| 5 | Domain identification and grouping | references/pattern-05-domain-grouping.md (optional: pattern-05-domain-grouping-quick-reference.md) |
Pattern 6 — planning and extraction
Pattern 6 (create domain services / extraction) is not duplicated here. After Pattern 5, switch to decomposition-planning-roadmap for phased extraction order, milestones, and migration-style planning. For full legacy migration strategy (strangler-fig, cross-stack rewrites, research-heavy plans), optionally use legacy-migration-planner in addition.
Bounded contexts and DDD strategic design
- Patterns 1–4 focus on structural inventory, duplication, hierarchy, and coupling between parts of the codebase.
- Pattern 5 produces candidate groupings aligned with solution-space boundaries (which components belong together as services).
- Strategic DDD (subdomains, bounded contexts, ubiquitous language) is covered in
references/domain-analysis.md, with optionaldomain-analysis-quick-reference.mdanddomain-analysis-examples.md. Use it when you need to validate or refine boundaries against business language, not only folder structure.
Frequently asked questions about Modular Decomposition
Similar skills
React Composition Patterns
Streamline your React component architecture with proven patterns.
Pester Should Migration
Easily convert Pester v5 assertions to v6 syntax.
Radix to Base UI Migration
Seamlessly migrate React components from Radix UI to Base UI.
Migrate Next.js to Vinext
Seamlessly transition your Next.js projects to Vinext.
WinUI 3 Migration Guide
Streamline your UWP to WinUI 3 migration process.
Refactor
Enhance code maintainability without altering behavior.
