decomposelisted

# Service Decomposition: $ARGUMENTS `$ARGUMENTS` names the candidate boundary ("billing", "the notifications module") or is empty = survey the whole system for extraction candidates and verdict each. ## Principle A service boundary is not a code-quality tool — it is an **organizational and operational** tool that happens to involve code. Splitting a process buys independent deploys, independent scaling, and failure isolation; it pays for them with network partial-failure, the loss of cross-boundary transactions, contract versioning, and an operational floor per service. Messy code is never a driver: **a mess cut in two is two messes joined by a network**. The governing rule is **extract the seam before the service**. Every good service boundary must first exist and hold as a clean in-process module boundary — own interface, own data access, no reach-ins. If the boundary can't be drawn inside one process, the network will not draw it for you. This is `core.md`'s door rule: extraction is a heavy, nearly-one-way door, but **modularization is how you change the door** — a proven in-process seam makes later extraction cheap and is worth having even if you never extract. So the default verdict is always the modular monolith, and extraction must argue its way past it. This skill **decides and records** — it does not restructure. Execution routes out (Phase 4). ## Phase 0 — Load profile **Tooling preflight — one call, before step 1.** Some tools this skill relies on are **defe