DSH provides an official workflow tool for large-scale multi-agent orchestration, but lacks a ready-made template library. The dsh-workflow-templates plugin includes 12 reusable workflow orchestration script templates and provides four tools for the model: list, search, run, and validate, along with static validation of the template format. The plugin aligns with the official tool-workflow contract, but does not impose stricter limitations than officially valid scripts (for example, it allows computed return values such as return 1), aiming to lower the barrier to writing orchestration scripts.

Core Features

The plugin provides four core tools for managing, retrieving, and invoking templates.

  • wf_template_list: Lists the template directory, supports filtering by domain (domain) or tag (tag), and outputs a template list in Markdown format.
  • wf_template_search: Searches by keyword, matching names, tags, descriptions, domains, and parameter names, and annotates the matching rationale.
  • wf_template_run: Reads the template content and generates a three-parameter starting point (meta, script, args) for invoking the official workflow tool, along with guidance for filling in parameters. It only outputs the invocation starting point and does not automatically execute the template script.
  • wf_template_validate: Checks the format validity of a template, including mandatory META fields, the final return expression structure, and script hook usage, aligning with the official tool-workflow contract.

Installation and Configuration

The plugin is organized as a Cordis plugin package. After installing dependencies and building it, mount it via cordis.yml.

1. Install Dependencies and Build

npm install
npm run build        # tsc → lib/

2. Mount the Plugin

Add the following entry to DSH’s configuration file (for example, cordis.yml). The plugin supports two mounting modes:

  • Published mode (recommended): Use the bare package name.
    - insert:
        - id: workflow-templates
          name: 'dsh-workflow-templates'
          config:
            workflowToolName: workflow
  • Development mode: Use a relative path to mount the source directly (local development/testing only).
    - insert:
        - id: workflow-templates
          name: './src/index.ts'
          config:
            workflowToolName: workflow

3. Configuration Options

Key Default Description
workflowToolName workflow Official workflow tool name; it must match the toolName in host configuration, otherwise visibility detection may report false positives.
templatesDir templates/ in the package Absolute path that overrides the template directory.

Usage

Use wf_template_list to view all templates, or use wf_template_search to find a specific keyword.

  • Filter by domain: wf_template_list domain=security
  • Filter by tag: wf_template_list tag=release
  • Keyword search: wf_template_search docker

2. Generate an Invocation Starting Point

When you need to execute a workflow, use wf_template_run. It does not run the script directly; instead, it outputs an invocation starting point (meta/script/args) compliant with the official workflow tool specification for further execution by the model or user.

// 示例：调用 wf_template_run 生成 workflow 起点
// wf_template_run pr-deep-review

3. Validate a Template

Before modifying or writing a template, use wf_template_validate for static checking. It reports errors (E) or warnings (W), for example missing required name/description, or usage of non-official hooks.

// 示例：校验模板格式
// wf_template_validate templates/security/dep-vuln-sweep.js

Template Contract and Validation Rules

The plugin includes a built-in validator that ensures templates comply with the official tool-workflow contract, but is not stricter than the official contract.

  • META fields: name and description are required. tags, args, and phases are optional extensions; if missing, only a warning is issued.
  • REQUIRED_REASON: Optional field used to declare why execution must go through the official workflow tool; if missing, only a warning is issued.
  • Script hooks: Only official hooks (agent/pipeline/parallel/phase/log) are allowed. Module statements (import/export/require) are prohibited.
  • Final Return: The script must end with return <expression>, with no JSON literal restriction; computed return values are allowed.

Notes and Permissions

  • Usage boundary: Use only when the model/user explicitly requests a workflow or large-scale multi-agent orchestration. Simple delegation tasks should not use the workflow tool.
  • Execution mechanism: The plugin does not automatically execute template scripts; it only outputs the invocation starting point. Execution authority rests with the official workflow tool.
  • Permissions: The plugin only has permissions to read templates and render output; it does not write files or call external services.
  • Development dependency: In development mode, it depends on an adjacent dsh-src checkout (using a link: dependency); ensure the directory layout is <parent>/dsh-src.