DSH Plugin Scaffold

Problem

DSH plugin development often gets stuck between shape selection, build validation, and release rollback. A team may start writing src/ before deciding whether the plugin should be pure, bundle, or bundle-client. It may work locally, but after publishing it fails with plugin tree failed to load or slot entry crashed. These issues are usually not just unfamiliar APIs; they come from missing a consistent constraint across goals, capability surface, build validation, and final installation checks.

How It Works

The skill structures DSH plugin development into 7 stages, each with a clear output and decision gate:

• Stage 0: Define goals and capability surface. Determine the normalized plugin name, one-sentence goal, capability surface (tools, services, HTTP routes, browser UI, root layout, skill, MCP, static assets, etc.), and target profile, defaulting to web.
• Stage 1: Choose the plugin shape. Map the capability surface to --kind pure, bundle, or bundle-client, and decide distribution and package manager. If replacing the default web shell root layout, register ctx.slots.register({ name: 'root' }) during implementation.
• Stage 2: Generate the scaffold. Run the scaffold, enter the generated directory, verify the skeleton works, and record the Stage 0/1 decisions in docs/plugin-plan.md.
• Stage 3: Implement the business logic. Generate only the files required by the chosen shape, such as src/index.ts or src/client/index.ts. Use ctx.effect() for tools, routes, services, or events and return a cleanup disposer. Do not hand-edit lib/; after changing src/, run pnpm run bundle.
• Stage 4: Local validation. Run build, gates, package-content checks, install smoke tests, and browser validation in order. Business bugs return to implementation; shape or contract errors return to shape selection.
• Stages 5/6: Release preparation and final validation. Initialize a real git remote, replace README placeholder refs, commit lib/ artifacts, add UI screenshots, then publish via git push or npm publish based on the chosen distribution. The final acceptance must reinstall from the final distribution source and restart web, confirming no load failures, no slot crashes, and behavior matching the original goal.

Boundaries

• Best for engineering work that follows the DSH contract, Cordis build model, and web shell distribution model.
• If diagnosing a narrow issue such as “why did mount fail,” do not rerun the full process; consult the relevant section in references/ for contracts, gotchas, or validation.
• The process enforces decision gates: do not advance before the capability surface is complete, the shape is fixed, the scaffold is verified, or local smoke validation passes.