This article is derived from the plugin's already-indexed fields (wiki / faq / compatibility_json / readme), not freshly generated by AI. Source field is noted at the end of each section.

Quick start

dsh_workflow

— source: plugin_wiki.wiki_content

Install & verify

dsh plugin --profile web add github:icetomoyo/dsh_workflow

Run the command above in your DSH Web Profile. Then enable the plugin in the plugin list.

— source: plugins.install

Key points

• id: dsh-external-workflow
• workflow_list：发现 built-in、pattern、项目和个人 workflow；无效条目会报告但不会执行。
• run_workflow：运行命名 workflow、从自然语言 scout-then-author，或执行受限 inline workflow。
• workflow_manage：查看、暂停、恢复、停止、重跑、续跑、保存、改名、修订、删除和清理。
• 版本化 dsh.workflow v1 capsule：manifest、source、intent、inputs、requires、provenance。

— source: plugin_wiki.readme_en (fallback readme_raw)

FAQ

What is the difference between this plugin and the built-in workflow tool in DSH?

The native workflow tool is suitable for one-off foreground parallel tasks; this plugin is a higher-level process product layer, supporting named saving, reuse, pause/resume, replay from snapshot, resume, audit evidence and cost records. It is injected via Cordis bundle patch, coexisting with the native tool without replacing it.

Does it require manual configuration after installation?

It works out of the box. All configurations have default values (see CONFIGURATION.md), common adjustments are changing approval mode, concurrency limit, model layer routing, or extending the read-only tool whitelist.

Can the generated scripts access the host machine?

By default, no. Generated scripts run in a QuickJS WebAssembly isolated heap, only calling the host through a JSON capability bridge; imports, process, files, shell, network, timers, and non-JSON values are rejected by static policy. Trusted local .ts still has host permissions and requires explicit approvalMode control.

How do I run the built-in code review?

Enter /workflow review in the session to automatically capture the current Git scope (defaults to comparing main/master/develop, falls back to uncommitted changes if missing) and start the scoped-review built-in workflow; use --risk, --requirement, --test-evidence, --wait and other parameters to control behavior.

Will workflows be exposed to model invocation?

Yes. The plugin registers three DSH tools: workflow_list (discovery), run_workflow (run/generate/inline), and workflow_manage (lifecycle management). The model will automatically invoke them in appropriate scenarios, rather than relying solely on user manual /workflow commands.

Where is persisted data stored?

Written to .dsh/workflow-runs/<run-id>/ directory by default, containing run.json, events.jsonl, immutable workflow.workflow.json snapshot, results/ (effect cache) and artifacts/. Saved named workflows are stored in project's .dsh/workflows/ or personal $DSH_HOME/workflows/.

Will data be left behind after uninstallation?

Commands and tools will stop registering, but data already written to project's .dsh/workflow-runs/ and .dsh/workflows/ directories will remain. Use /workflow prune or delete directories directly for cleanup.

— source: plugin_wiki.faq_json

Compatibility

• DSH: 0.0.1-rc.2
• Node: >=22.19.0

— source: plugin_wiki.compatibility_json

Pitfalls

Review the upstream repo before installing. This guide is auto-derived from indexed fields and may lag the latest release. If anything contradicts the official docs, treat the upstream source as authoritative.

— source: general rule