What problem does it solve? Designing a DSH plugin without upfront decisions leads to wrong plugin forms, missing dependencies, broken lifecycle disposal, and untestable packages. This Skill turns a requested capability into explicit, evidence-backed package decisions before any code is written. ## Core Features & Use Cases - Plugin Form Selection: Decides between a function plugin (named exports name, inject, Config, apply) and a service plugin (default-exported Service subclass), and records package roles such as service definition, provider, consumer, or bundle. - Dependency & Configuration Design: Builds a dependency matrix covering Cordis access patterns, manifest entries, and test support, and defines validated Config fields with defaults, evidence, and fail-loud behavior. - Lifecycle, Invariant & Composition Planning: Names every owned registration and its disposal path, defines the ./invariant export, designs profile composition rows, and selects the smallest test tiers that prove behavior. - Use Case: When asked to add a new capability to DSH Web, use this Skill to produce a complete planning handoff—plugin form, dependency matrix, configuration schema, lifecycle ownership, invariant, bundle rows, and test plan—ready for the dsh-plugin-development implementation stage. ## Quick Start Use dsh-plugin-plan to design a standalone DSH plugin for my requested capability, covering its form, dependencies, configuration, invariant, composition, and test plan.
