design-boundarieslisted

# Design component boundaries Use this skill to **separate** a feature or system, at design time, into components with distinct responsibilities and clean interfaces, partitioned by what changes independently. The output is a **component design**: what components exist, what each is responsible for, the interface each exposes, and which way the dependencies point — before any code commits the structure. Governing intuition: **draw boundaries along what changes independently, not along the nouns.** A component earns its existence by having one reason to change and hiding it behind a narrow interface; responsibilities that always change together belong in one component. Fewer cohesive components beat many anemic ones — resist the decomposition you have not earned. **Input**: the feature or system to structure — a requirements description, a spec, or a capability being added to an existing system (existing code is context, not the thing being split); if the target is an existing tangled code unit, hand off to `plan-split`. If no scope is given, ask what is being designed. **Boundary**: designs and plans — produces a target component structure; writes no code, scaffolds nothing, and picks no concrete framework. ## Workflow ### Phase 0: Frame the system and its forces Capture, before drawing any boundary: - **Purpose** — what the feature/system must do, in one or two sentences. - **Forces** — what is expected to **vary** independently (formats, providers, policies, UIs) ver