dsh_workflow: Bringing a Governable and Recoverable Workflow Layer to DeepSeek Harness
icetomoyo/dsh_workflow
Bring a workflow layer to DeepSeek Harness that is generable, saveable, governable, observable, and resumable, upgrading one-shot multi-agent orchestration.
Upgrade DeepSeek Harness's one-shot multi-agent scheduling into a generatable, saveable, governable, observable, and recoverable Workflow layer, letting teams reuse processes, persist evidence, and control costs.
dsh plugin --profile web add github:icetomoyo/dsh_workflow- Category
- Workflow & Automation
- Platform
- DSH-Plugin
- Author
- icetomoyo
- Distribution
- Plugin
dsh_workflow Key Features
dsh_workflow Repository
dsh_workflow Repo Summary
DSH Workflow is an official bundle-form DSH plugin for DeepSeek Harness, maintained by omdsh-dev under the MIT license, last updated in 2026-08. It upgrades DSH's one-shot multi-agent scheduling into a Workflow layer that is generatable, saveable, governable, observable, and recoverable, solving the pain of repeatedly describing task decomposition, concurrency, verification, and aggregation in every session. Core capabilities include versioned capsules, durable run graphs, pause/resume, rerun/continue, cost tracking, tiered approvals, and capability-only VM, fully benchmarking KodaX's workflow design.
What core features does the DSH Workflow DSH plugin support?
DSH Workflow provides three model-callable tools: workflow_list to discover built-in, pattern, project, and personal workflows; run_workflow to run named workflows, scout-then-author from natural language, or execute restricted inline workflows; and workflow_manage to view, pause, resume, stop, rerun, continue, save, rename, revise, delete, and clean up. It also offers /workflow slash commands such as /workflow list, /workflow create, /workflow review, and /workflow runs. The execution model benchmarks KodaX, supporting versioned dsh.workflow v1 capsules (manifest, source, intent, inputs, requires, provenance), and enforces provider/model/concurrency/budget constraints via manifest + preflight + runtime hard limits.
How to install and configure DSH Workflow?
Requires Node.js >=22.19 and a compatible DSH snapshot. Install with:
dsh plugin --profile web add github:icetomoyo/dsh_workflow
After installation, verify the bundle is in the profile composition tree with dsh --profile web --dump-config, expecting id: dsh-external-workflow. Restart the DSH profile and use /workflow commands in sessions.
How does DSH Workflow integrate with DeepSeek Harness's existing mechanisms?
DSH Workflow does not replace DSH's native front-end workflow tool; instead, it adds a higher-level process product layer. It deeply integrates DSH's Cordis, ctx.subagents, Session, background jobs, approvals, commands, and tool mechanisms, chaining model routing, sub-agent providers, tool permissions, approvals, session logs, background jobs, and UI events into a complete loop. For example, /workflow create immediately ends command processing and hands the workflow intent to the main agent; the user's raw query enters the Session as a real user message, contributing to title generation and appearing in the workspace, while the internal authoring contract is passed as a separate folded plugin context without polluting the title or user bubble.
What governance and security mechanisms does DSH Workflow provide?
DSH Workflow offers capability-only VM, JSON boundaries, deterministic guards, and tiered approvals to prevent generated scripts from exceeding privileges or being non-reproducible. approvalMode: always and trusted-local workflow approvals remain. For inline workflows, the plugin performs pre-launch smoke validation before starting any real sub-agents; if fields are invalid (e.g., modelHint not fast | balanced | deep), it returns precise errors and retains the one-time authorization for the main agent to correct and retry. Internal relays, subsequent direct user messages, or repeated valid calls cannot reuse authorization.
How does DSH Workflow achieve persistence and recoverability?
Parallel results no longer scatter across sessions; run graphs, events, artifacts, result summaries, and costs are durably persisted. After interruption, you can rerun from a run snapshot or use effect cache to continue unfinished parts. /workflow show defaults to the latest run, and /workflow stop stops the current active run. Workflow launches and run_workflow return { runId, status, jobId? } immediately without blocking the turn; subcommands that support waiting explicitly pass --wait (tool parameter wait: true) to wait for the terminal state.