Introduction

The DSH bundle plugin dsh-code-pipeline is designed to dynamically inject stage subagent tools for the code-pipeline preset (PTC Code Mode pipeline), and to allow configuration of the model used by each stage subagent on the settings page.

The original code-pipeline preset statically pins the three dsh-tool-subagent lines (subagent_plan / subagent_impl / subagent_review) and each stage’s provider/model/persona/toolFilter directly in agent.cordis.yml. To change a model, you must edit the YAML and restart the session. This plugin listens for the agent/created event, registers tools in agent.ctx, and decouples model selection to read settings at runtime, enabling dynamic configuration without restarting the session.

Core Features

  1. Dynamic tool injection: Injects the three stage subagent tools into ROOT agents that compose the code-pipeline preset.
  2. Dynamic model configuration: Through the Settings → Code Pipeline page, configure each stage’s enabled, provider, model, reasoningEffort, and maxConcurrency in real time.
  3. Multi-round review reuse: Uses the pipeline_followup tool to reuse the same review subagent across multi-round review (plan → impl ↔ review), avoiding repeatedly passing context.
  4. Dispatch message persistence: When the main agent invokes a stage tool, the complete dispatch message (including diff, plan, etc.) is written to a system temporary file in one piece, avoiding context truncation.
  5. Background mode execution: Stage tools run by default in run_in_background mode, immediately returning a subagent ID while the subagent continues execution in an independent session.

Installation and Enablement

A one-line command is recommended for installation from the GitHub distribution.

dsh plugin --profile web add github:ErrorLst/dsh-code-pipeline
  • This command runs pnpm add github:ErrorLst/dsh-code-pipeline under the web profile, and automatically appends @dsh-external/dsh-code-pipeline to dsh.profile.bundles.
  • After a successful installation, restart dsh web to activate the plugin.
  • Auto-install the preset on first launch: The plugin checks $DSH_HOME/.agent-presets/code-pipeline; if it is missing, it automatically copies it from preset/code-pipeline/ inside the package (idempotent; if it already exists, it is skipped and never overridden).

Local development installation:

dsh plugin --profile web add link:<本仓库绝对路径>

Uninstallation:

dsh plugin --profile web remove @dsh-external/dsh-code-pipeline

Configuration and Usage

Settings Page Configuration

On the browser settings page, go to the “Code Pipeline” configuration:
* Provider/Model: The list comes from GET /dsh-code-pipeline/options; when unavailable, the corresponding fields are disabled and manual input is not allowed.
* Running status: Each stage card shows “currently running N / limit M”, with data from GET /dsh-code-pipeline/status (polled every 5 seconds).
* Subagent message delivery: Supports “fixed insertion” (default) and “fixed queueing” delivery methods. Fixed insertion uses steer semantics, allowing a running subagent to receive the message at the next model step; fixed queueing uses the native human-queue channel.

pipeline_followup Tool

When a stage subagent has already been dispatched and is running, requirement changes must use the pipeline_followup tool:
* Parameter child: Supports latest, a stage key (plan / impl / review), or a full subagentId.
* Parameter message: The requirement change text must be self-contained (the subagent does not have the current conversation context).
* Behavior: Calls the host native subagents.sendMessage. If the subagent is idle or has ended, it wakes a new turn; if it is running, the message is inserted at the next model step.

Manual Gate

After the Plan stage ends, the main agent presents the complete plan directly in the conversation as a Markdown reply, then ends the turn and waits for user input.
* Approval (e.g., approve, agree, ok): Proceed to the implementation stage.
* Other content: Treated as revision feedback, merged into the plan and re-presented (up to two rounds).

Multi-Round Review Reuse Protocol

Based on the prompt protocol, rounds after the first review reuse the same review subagent:
1. Round 1: Use subagent_review, which returns a subagentId.
2. Round 2 onward: Use pipeline_followup, pass that subagentId as child, and include the complete new diff, numbered issue handling notes, and the reply contract (APPROVED / CHANGES REQUIRED:) in message.
3. Note: From Round 2 onward, do not pass the plan or previous diffs; rely on the prefix cache inside the subagent session.

Limitations and Requirements

  • Subagent input box: The subagent’s own input box still queues (the host subagents.prompt hardcodes mode: 'continuable', and steering is disabled for subagent sessions in the input bar). To change requirements, use the main conversation → the agent calls pipeline_followup.
  • Review artifact persistence: Review artifacts may only be written to the system temporary directory ($env:TEMP). The main agent must not create files such as *.diff, .review_* in the project root or subdirectories.
  • Preset maintenance: The preset/code-pipeline directory is maintained with the project. After a plugin upgrade, if behavior does not match, check whether this directory is stale relative to the repository version.
  • Engine requirements: node >= 22.19.0, dsh >= 0.1.6-alpha.1.
  • License: MIT.

Summary

The dsh-code-pipeline plugin decouples tool registration from model selection, providing flexible pipeline configuration capabilities. Combined with pipeline_followup and the multi-round review reuse protocol, it can effectively manage context passing and change handling for long-running tasks. After installation, restart the session to use it.

GitHub Repository