Preface¶

The philosophy of DSH is “everything is a plugin”. The problem is that when a vague product idea enters the session, the model usually starts writing code directly: a single-file MVP, just to get it running first. Whether anyone will actually pay for this requirement, whether the supporting open-source repository can be used commercially, or whether deployment will blow up costs with internet fees and token bills, is rarely handled in advance. The result is a large number of “dead on launch” self-indulgent projects. The plugin introduced below specializes in handling this: first do requirement verification and business calculation, then talk about technical selection and ticket breakdown, with checkpoints set throughout the process. If stuck, stop.

What is this¶

The plugin cunzailv/shangyeruanjiankaifa, categorized as “Workflow” on the SkillHub directory page, maintained by cunzailv, has 0 current stars, and the license is MIT. It is simultaneously a DSH plugin and a set of skills named project-development-planner. Its core positioning is to install the discipline of “requirement first, business closed-loop bottom, open source foundation start, three armies collaboration, safety and compliance both heavy” into the session, pushing the vague idea in hand into a implementable engineering ticket.
The plugin does not write underlying code, but acts as an Orchestrator: unifying control over the three armies of commercial strategy and risk control, R&D and AI engineering, and commercial operations growth and data, totaling 12专职 roles, each role working in an independent context to avoid the “writing code and testing it yourself” loophole.
The difference between this and simply pasting a methodological document in the chat is that stage checkpoints and output templates are solidified within the package resources, and stage progression requires you to explicitly reply “Confirm”; the model cannot run ahead.

Core Features¶

1. Seven-Stage Stage Gates. Stage 0 verifies requirements and value propositions; Stage 1 business model and unit economics (\(LTV > 3 \times CAC\)); Stage 2 PRD and page flows; Stage 3 open-source scaffold selection and secondary development planning; Stage 4 system contracts, data models, and compliance; Stage 5 AI agent pipelines and Prompt evaluation; Stage 6 ticket breakdown and deployment. After each stage outputs a standard document, it forces a pause for your confirmation.
2. Verified Open Source Base Libraries. Built-in 38 high-frequency GitHub repositories, verified one by one for stars, licenses, and archive status, locking onto which layer to borrow based on “Project Type -> Audience Scenario -> Product Form”. Three-vote veto for AGPL/GPL contagion, custom commercial restrictions, and archived repositories. The README states bluntly: the 165k-star stable-diffusion-webui is AGPL-3.0, and the 145k-star ComfyUI is GPL-3.0; putting them directly into a closed-source product is a disaster.
3. Multiple Choice Interaction. Built-in “Design Style Dictionary” and “Feature Block Library”. The model gives Plan A / Plan B instead of asking you to fill out a spec sheet; when planning technical implementation, it also suggests mounting specific skills like ui-ux-pro-max or architecture-designer.
4. Out-of-the-Box Package Resources. Seven reference manuals and three stage templates take effect with the package, no need to manually copy them elsewhere:

references/tech-stack-matrix.md            # Technical stack matching reference
references/github-open-source-cases.md     # Verification results of 38 open-source repositories
references/economics-formulas.md           # Financial formulas like LTV:CAC
references/project-type-strategies.md      # Differentiation strategies for Greenfield / Brownfield / AI Transformation
assets/stage-0-template.md                 # Stage 0 report template
assets/prd-template.md                     # Stage 2 PRD template

Installation and Enablement¶

The official npm package name is dsh-business-planner, and the npm badge at the top of the README points to https://www.npmjs.com/package/dsh-business-planner. The declared runtime environment in the repository’s package.json is as follows, please note the version constraints:

"engines": {
  "dsh": ">=0.2.1-rc.2"
}

The package is an ESM package ("type": "module"), files contains index.js, SKILL.md, references/, assets/. The logic of index.js is straightforward: parses the frontmatter of SKILL.md to get name and description, registers the body to ctx.skills, and points resourceBase to the package root directory, so relative paths like references/xxx.md or assets/xxx.md in the body can be parsed directly without spreading files to the user directory. I could not verify the original text for the installation command: the README has an “Installation and Quick Start” chapter, but this time the document was truncated in the middle multiple times during the crawl, and the original command line text for that chapter could not be obtained, so I am not posting it. Please refer to the installation chapter of the repository README and do not splice the installation command yourself based on the package name. After installation, enter in the dialogue box:

/project-development-planner

to wake it up. The README also describes a “Master Planner” entry in the left sidebar, where 7-stage progress, checkpoint outputs, and reference documents are visible at a glance; progress is saved to local localStorage.

Typical Usage¶

1. After starting the Skill, you first describe the product conception in plain language. If the description is vague, do not ask “what features do you want”, but directly give 3 product directions for you to choose, for example “Do you want to make a document tool similar to Notion, or an image generation tool similar to Midjourney”. The selection basis is in references/feature-modules.md and references/design-styles.md.
2. The Skill will ask for the project type: New project (Greenfield), Secondary development or refactoring (Brownfield), Traditional project AI transformation (AI Transformation). The three types follow the differentiated strategies in references/project-type-strategies.md, for example Strangler pattern, Sidecar solution.
3. When entering Stage 3 for open-source selection, the specification requires reading references/github-open-source-cases.md, taking out 2-3 verified cases (one primary, one backup), writing clearly for each candidate “which layer to reuse / which layer to write yourself / whether the license can be used commercially / last commit time / main risks / decision”, and explicitly excluding AGPL, GPL contagion, and archived repositories.
4. After the checkpoint output of each stage is completed, the Skill will explicitly prompt you to wait for confirmation: “Please reply ‘Confirm’ or select the option you prefer (e.g., A or B), to proceed to the next stage.” It will not enter the next stage before receiving confirmation.

Applicable Scenarios and Notes¶

Suitable for people with specific product ideas in hand who want to go through requirement verification, unit economics, and license compliance first, and then break the results into tickets; it can also be used as a means to add discipline to AI planning processes in a team. A few reminders:

• Permission Boundaries. The plugin runs with the permissions of the current dsh process. Before installing, read the source code and license once to ensure it meets your environment requirements, then turn on permissions.
• Version Alignment. engines.dsh requires >=0.2.1-rc.2; versions below this may not load. Before upgrading dsh, check if the plugin package has a matching update.
• Data Timeliness. The stars, licenses, and archive status of the 38 open-source repositories are scraped from the GitHub API, as of 2026-11-05. Star counts do not equal commercial viability; you need to verify yourself before reusing.
• Source Nature. The SkillHub directory page is a community site and has no official affiliation with DeepSeek / SynthFlow; it is just a listing page on a community directory.
• Positioning Boundaries. This set of things manages up to Stage 6 ticket breakdown and does not implement code. The open-source solutions in Stage 3 and the compliance checklist in Stage 4 still ultimately require you or your team to accept them.

Overall, its value lies in making “think clearly before acting” a hard constraint within the session, rather than acting as a code generator. The directory page is at https://www.skillhub.cn/plugins/cunzailv/shangyeruanjiankaifa, and the source code is at https://github.com/cunzailv/shangyeruanjiankaifa.