What problem does it solve? Engineering teams often jump straight into writing design documents, CRDs, or controllers before the shape of an idea is settled, producing artifacts that must be argued down instead of filled in. This Skill structures the pre-design conversation so decisions about component ownership, desired state versus one-shot operations, and live-cluster impact are made before anything is written. ## Core Features & Use Cases - Path classification: Routes every idea into spike (finding reported in chat), bounded (short design then implementing skill), or architectural (handoff to design-doc then work-plan) paths. - Three gating questions: Forces decisions on which component owns the behavior (control plane, atlas-lib, operator, or CSI driver), whether the change is desired state or a one-shot operation, and what it does to a live cluster serving I/O. - Product-specific trap detection: Names common wrong ideas such as unnecessary CRDs, blocking reconcilers, duplicated helpers, and premature parallelization, with the reasoning for why each fails. - Use Case: When asked "can we add volume rebalancing to the operator," the Skill grounds the discussion in existing code, determines the control plane owns the mechanics, and hands a settled decision to the design-doc skill instead of drafting an operator design prematurely. ## Quick Start Ask the assistant to brainstorm whether a new feature idea belongs in the operator or the control plane before writing any design document.
