Introduction

DSH’s plugin ecosystem emphasizes the concept of “everything is a plugin”: capabilities can be made into independent bundles, installed into a specific profile, and invoked by the current dsh session. For long and difficult tasks, the difficulty usually lies not in a single prompt, but in how to connect multiple stages: research, product judgment, architecture, implementation, review, testing, and pre-release check. If everything relies on manual progress, it is easy to miss intermediate states and difficult to review.

wellorbetter/dsh-product-delivery-workflow is a DSH plugin prepared for such tasks. It organizes the process from product to release into a workflow, covering 10 stage gateways, and supports routing back to the corresponding worker to continue processing after review issues are found. Below is an introduction to its capabilities, installation methods, and a few session commands that can be used directly.

What is it

wellorbetter/dsh-product-delivery-workflow is a DeepSeek Harness plugin maintained by wellorbetter with an MIT license.

It provides a 100% AI-native product delivery workflow: starting from the input brief, going through autonomous research, product decisions, PRD, OpenSpec architecture, parallel multi-agent implementation, review loops, testing, memory & evolution, release audit, and finally generating a final report.

Its positioning is not for single Q&A, but for autonomous completion scenarios suitable for long and difficult tasks. The plugin consists of a workflow skill and nine role agent skills. Once installed in the target profile, it can be invoked in a session.

Core Capabilities

Below are a few key behaviors.

1. Covers 10 Stage Gateways

The plugin declares that it covers 10 stage gateways. Verified capabilities include:

  • Autonomous research
  • Product decision
  • PRD
  • OpenSpec architecture
  • Parallel multi-agent implementation
  • Review loop
  • Testing
  • Memory & evolution
  • Release audit

These stages are organized in the same workflow, rather than requiring users to trigger them one by one manually.

2. Closed-Loop Review

When review issues are found, it routes back to the corresponding worker. This closed loop is a maximum of 5 rounds; if it still fails, it requests human direction.

This means it doesn’t simply run once and end, but continues to return to the implementation or check phase when the gateway is not passed.

3. Artifact Persistence

Run artifacts will be persisted to:

.opencode/workflow/<slug>/

A final report is also generated after the run ends. This way, after the task is completed, process artifacts and final results can be viewed from that directory.

4. Release Audit Precedes Commit Actions

The release audit runs before the following actions:

git commit
PR
push

This step is used to perform checks early in the release pipeline, rather than remedying them after commit or push.

5. Memory Organization Has Boundaries

Memory organization is based only on approved evidence and does not store keys or transcripts.

This is important for long-running tasks: it allows reusable evidence to be accumulated, but the boundaries are limited to approved materials.

6. Workers Do Not Arbitrarily Commit, Push, or Reset Contracts

Verified constraints include: workers do not commit, do not push, and do not reset contracts.

This means the responsibility of implementation workers is to complete the assigned local work, rather than arbitrarily changing the release status or redefining interface contracts.

Installation and Enablement

First, confirm that dsh CLI is available locally. The plugin also requires Node >= 18 and depends on:

yaml ^2.4.0

The installation command is as follows:

dsh plugin --profile web add github:wellorbetter/dsh-product-delivery-workflow

After installation, the profile needs to be restarted. For example, using dsh web, or starting a dsh session for the corresponding profile.

This plugin declares dsh.bundle.patch. When installed, dsh plugin automatically aligns it to the layer list of dsh.profile.bundles.

The plugin is distributed as pure JavaScript. When installing from GitHub, no build steps are required, and no allowBuilds permission is needed.

Typical Usage

1. Run Complete Product Delivery Workflow

In a profile session, you can directly request to run the full process:

Run the product delivery workflow on <brief>. Produce the full pipeline and the final report.

Replace <brief> with the specific task input. The workflow will advance by stages and generate the final report.

2. Call a Single Role

If you only need a limited task for a single role, you can also call it separately. For example:

Use product-agent to review this PRD against the delivery results and report gaps.

This example is used to have the product-agent check the PRD against delivery results and report gaps.

3. Overnight Run

For tasks that take a long time, you can combine it with goal/headless mode:

  1. Start a profile session.
  2. Provide the brief to let the workflow run.
  3. Check later:
.opencode/workflow/<slug>/

View process artifacts and the final report.

This usage is suitable for running long tasks during non-interaction periods and continuing to judge based on the artifacts the next day.

Development Verification

If you need to verify the plugin after checking it out locally, you can first install dependencies and then execute the verification command:

pnpm install
pnpm verify

pnpm verify will check and load all 10 packaged skills.

Applicable Scenarios and Notes

This plugin is suitable for long and difficult tasks that require a complete product-to-release chain, especially scenarios where the workflow can be advanced autonomously, artifacts are checkable, and reviews can be closed-looped.

When using it, please note:

  • The plugin runs under the permissions of the current dsh process.
  • You should check the source code and license before installation.
  • It declares use of the MIT license.
  • Workers do not commit, push, or reset contracts.
  • The review closed loop is a maximum of 5 rounds, after which human direction is requested.
  • Memory organization is based only on approved evidence, not storing keys or transcripts.
  • The DSH Community Directory is the plugin directory; it should not be understood as the official app store for DeepSeek or Fantom.

Links

  • Directory page: https://www.skillhub.cn/plugins/wellorbetter/dsh-product-delivery-workflow
  • GitHub: https://github.com/wellorbetter/dsh-product-delivery-workflow