dsh-module-driven-develop

Shipping a mid-size service is rarely a problem of writing one clever function; it is a problem of breaking requirements into pieces small enough for a single agent to own, and then making those pieces actually work together. dsh-module-driven-develop encodes exactly that discipline: it recursively decomposes any requirement into a module tree whose leaves are independent and small enough for one sub-agent to design and implement on its own, while a main agent handles orchestration, topological scheduling, integration, and debugging. You do not manually decide who writes what or in what order; the protocol handles all of it.

The design document is treated as the single source of truth, and the plugin enforces that rule strictly. When a module design is revised, the old code is not patched; it is archived, the module directory is wiped, and everything is regenerated from the new design. Requirement changes follow the same principle: a dedicated change-analyst sub-agent traces the dependency graph to locate every affected module, each module agent decides whether the change must propagate further down to its children, and the whole chain redesigns, regenerates, and re-integrates. This no-patch policy may feel heavy, but it eliminates the subtle drift that accumulates from incremental edits. In the bundled auth-service demo, the result is 169 passing tests and 15 clean HTTP smoke checks, with every design decision, delegation batch, and delivery report recorded under .mdd/.

This plugin fits well if you are doing real development in DeepSeek Harness and your requirements span multiple modules and agents. Rather than firing one large prompt and hoping for coherence, you get a structured workflow with design documents, topological build batches, integration logs, and a full audit trail. It is especially useful when requirements evolve over time, because the regeneration-first approach keeps the codebase aligned with the latest design instead of layering patches on top of patches.