DSH Plugin MarketA community catalog for DeepSeek Harness plugins

dsh-flow

Verified Skills & agents ★ 35 0.0.1

DeepSeek Harness 的统一智能体画布:需求时间轴 + 多智能体团队层级编排一图呈现,成员立绘、按说话者编织的对话链、任务依赖 DAG,团队数据自有化存储。

What it is

DeepSeek Harness 的统一智能体画布:需求时间轴 + 多智能体团队层级编排一图呈现,成员立绘、按说话者编织的对话链、任务依赖 DAG,团队数据自有化存储。

How to install

Run this in the DSH web profile, then refresh the page.

$ dsh plugin --profile web add dsh-flow@0.0.1

DSH versions accepted

Undeclared

Author and traction

rootkiller6788 · ★ 35 · Updated 2026-10-06

About this plugin

dsh-flow

中文 · English

What stalls long or complex work is usually not "not enough tools". It is that the executor cannot be swapped, the state has no source of truth, and the boundaries have no assertions — a task that has run for hours crashes once and cannot say how far it got; changing how work is executed means changing the core, and so does adding a kind of team source.

dsh-flow solves all three at the level of kernel shape: rules/ is a pure core (no IO, no ctx), execution and sources are declared seams, and kernel.js is the single composition root that decides which implementation this deployment attaches.

It and dsh-agent-teams are two kernel shapes: the same capability surface, the opposite internal shape. That opposition is where this document starts.

= 22.19.0"> Two kernel shapes

In the host's own words, the difference is whether a plugin divides its own internals into services. The host frames this as "everything is a plugin" and "Plugins, not loop changes", which in code comes down to the core / seam split: A seam comprises three roles — Service Definition / Provider / Consumer — and is only complete with all three. In dsh-flow they line up plainly: runner/interface.js is the definition, manual.js and subagents.js are the two Providers, and tools/ is the Consumer.

ctx.flowTeamSources has the same three roles but the Providers sit in a registry rather than behind a pick, because those implementations genuinely coexist. The picture above is flowRunner, the seam where exactly one may be live.

Both are DSH plugins, and both attach to seams the host provides — the difference is whether the plugin has seams of its own. Once the functionality is split into core and seam, "add another way to execute" is adding a Provider and "add another kind of team source" is one register() call; on a flat src/, that work is changing the core.

So this is an opposition, not an absorption: the capability surfaces can be aligned (the 13 tools map one to one to agent_teams_*, and the 31 differential checks in pnpm test:diff guard that line), but the two kernel shapes cannot give the same set of guarantees.

Here is that other plane, read out of its source rather than its README. It provides no service of its own — ctx.provide appears zero times — and state.ts does the job our store/ layer does, without a layer to sit in:

Similar plugins