MD
Microservices Decomposition
🔵 Stable🕐 updated 2026-06-08
🔷 SkillSpec L3
pm-engineering
Design a microservices decomposition for a monolith or new system, defining service boundaries, ownership, communication patterns, and migration plan. Use when asked to decompose a monolith, define service boundaries, design a microservices architecture, or plan a strangler-fig migration. Produces a bounded context map, service inventory table, communication pattern decisions, data ownership matrix, migration roadmap, and risk register.
What to give it
▸System or domain description — what the system does, its core domain, and the key business processes it supports
▸Current architecture — monolith (describe the tech stack and rough module structure), partial services (list existing services), or greenfield
▸Team structure — number of teams, team names if known, and approximate team sizes; this drives service ownership
▸Performance and scalability requirements — any specific SLAs, load characteristics, or scaling constraints per domain area
▸Migration constraints — what cannot be rewritten all at once, hard deadlines, zero-downtime requirements, budget constraints
▸Integration points — external systems, third-party APIs, or legacy systems that cannot be changed
✅ The bar it holds itself to
Every skill in this library self-verifies — these are this skill's own quality checks, straight from its definition.
✓Bounded context map is an ASCII diagram with labeled relationships — not a prose description of the contexts
✓Every service in the inventory table has a named team owner and a clear single-sentence responsibility statement
✓Data ownership matrix assigns every key entity to exactly one owning service — no shared ownership
✓Communication pattern decisions explain WHY sync vs. async was chosen for each interaction type
✓If decomposing a monolith, the strangler fig migration plan has phases with durations, dependencies, and success criteria
✓Risk register addresses at minimum: data consistency, distributed transactions, and Conway's Law alignment
✓Organizational alignment section maps services to teams and identifies misalignments that need to be resolved
⚠️ What it refuses to do
Do not define service boundaries before completing the domain analysis — services derived without bounded context mapping will split the wrong things and couple the wrong things
Do not assign multiple teams as co-owners of a single service — shared ownership is no ownership; every service needs exactly one team accountable for it
Do not default to synchronous REST calls for all inter-service communication — using sync calls where async events would decouple services creates cascading failure modes
Do not propose more than one service per bounded context without a clear justification — over-decomposition (nanoservices) creates operational overhead that exceeds the decomposition benefit
Do not begin migration without deploying distributed tracing first — migrating without observability means flying blind when the first extraction causes a production incident
Install
npx pm-claude-skills add --agent claude # or codex · cursor · gemini · hermes
# or one-line MCP (every skill, any client):
claude mcp add pm-skills -- npx -y pm-claude-skills-mcpStart with
Related skills
🔌 Embed this skill
Drop this on your blog, docs, or site — it renders a "Run this skill" card:
<div data-pm-skill="microservices-decomposition"></div>
<script src="https://mohitagw15856.github.io/pm-claude-skills/embed.js" async></script>💬 Discussion
Microservices Decomposition is one of 1078 open-source professional AI agent skills — all SkillSpec L3.
Try them all in the browser · ⭐ Star on GitHub · Browse the full catalog