service-ownership-boundaries

What problem does it solve?

It prevents outages, slow incident response, and architectural thrash caused by mismatched service boundaries—where technical interfaces and organizational ownership no longer line up.

Core Features & Use Cases

• Bounded-context mapping: Identify where the domain model and lifecycle actually belong so a service boundary reflects a single conceptual context.
• Conway alignment (forward and reverse): Evaluate whether your service architecture matches the team structure (or explicitly adjust either team or architecture).
• Split vs. merge decisions: Recommend whether to split or merge services based on cognitive load, deploy cadence, scaling shape, and operational isolation.
• Ownership vs. maintenance: Distinguish who designs and who keeps systems running to avoid “paged-but-unknown” ownership failures.
• Orphan service triage: Detect and correct services that nobody truly owns, turning tail risks into accountable, runnable ownership.
• Chatty boundary detection: Flag cross-service call patterns that indicate overly granular boundaries or poor protocols, then suggest boundary/protocol fixes.

Quick Start

Use the service-ownership-boundaries skill to analyze an incident where pages went to the wrong team and recommend the most likely ownership and boundary fixes for the services involved.