Preface¶

When multiple agents need to modify the same Git repository inside DeepSeek Harness (DSH), the common approaches are parallel sub-agents or Agent Teams: the former provides no worktree or merge gates, while the latter shares a task board and integration is often still wrapped up by humans. If you want to define “done” as a reviewable branch change with optional independent review and evidence gates—rather than a simple “it’s ready” in the conversation—you need a delivery protocol oriented toward repository changes.

dsh-tower (maintainer louifinn, npm package name dsh-tower, current release version 2.0.4, MIT license) is a multi-agent orchestration plugin for DSH: the session acts as a control tower, workers implement missions in isolated Git worktrees, and changes are merged into the baseline through scope and merge gates; review can be made mandatory in the configuration. Its design is inspired by the experimental Tower mode in Moonshot AI’s Kimi Code. This project is an independent implementation for DSH and is not affiliated with Moonshot AI. Community directory page: louifinn/dsh-tower; source code and documentation: GitHub.

What This Is¶

Tower turns an agent session into a small engineering team: the control tower handles planning and dispatch, workers write code and commit on independent branches and worktrees, and an optional reviewer performs read-only review; a pre-merge gate re-validates scope, branch freshness, task completion, review records, and worktree ownership, and only executes a --no-ff merge after it passes. Collaboration state (roster, inbox, findings, reviews, mission status) is persisted under .git/dsh-tower/ and can be resumed after a restart.

The repository root is the DSH bundle package root: package.json declares dsh.bundle.patch, and cordis.patch.yml is located at the root, conforming to the DSH plugin specification. It is classified as a workflow-type plugin.

Core Features¶

The following summarizes the capabilities already listed in the README, describing only the behaviors that explicitly appear in the documentation.

Tower Mode and Session Control¶

• /tower toggles session-level Tower mode: it narrows the tool surface and injects the Tower protocol; /tower on|off <instruction> forwards the instruction as the next user message to the model.
• By default, agents are allowed to enter or exit via tower_control with a reason; setting mode.allowAgentControl: false in the profile changes this to human-only control.
• While Tower mode is enabled, create_goal, update_goal(resume), todo_write, the Team task board, and spawn_teammate are rejected, and it is mutually exclusive with plan mode, to avoid two orchestration protocols driving the same session simultaneously.

Task Isolation and Roles¶

• Each mission uses an independent branch and Git worktree, and workers do not touch the main checkout.
• Workers cannot directly complete or abandon a mission or expand its scope; completion must go through the tower_complete evidence gate. The tower can abort a runaway agent with tower_interrupt or tower_send(interrupt:true).
• Optional mode.workspaceLock allows only one Tower session per repository; spawn.maxLiveWorkers, send.maxPerMinute, and similar options constrain concurrency and message storms.

Review and Merge Gates¶

• When review.requireReview: true, the reviewer gives a clean / merge conclusion against the current branch tip; review is optional by default.
• The pre-tower_merge gate validates scope, review records, and so on; when review is enabled globally, a single mission can use reviewPolicy: "none" with a reason to make a narrower exemption under gates.allowReviewExemption: true.
• Findings flow via tower_findings through open → triaged → fixed / wontfix; only the tower or a worker can change state, while reviewers are read-only.

Configuration, Error Codes, and Ops Tools¶

• The repository-level <git-common-dir>/dsh-tower/config.json can override review, merge, worktree, spawn, and other settings; precedence is code default < profile < repository config < tool arguments.
• Tool failures uniformly carry a [tower:<code>] prefix (e.g., mission-not-found, preset-missing, config-invalid).
• Version 2.x also provides verification and operations-oriented tools such as tower_test, tower_doctor, tower_batch, and tower_resource; it supports hot-reloading linked plugin code via /tower reload and tower_reload under HMR.

Components adopt an all-or-nothing approach: cordis.patch.yml inserts only a single tower-bundle group; when disabled, the Host, skills, and worker/reviewer presets are all disabled together.

Requirements¶

• DeepSeek Harness 0.2.1-rc.2 (see the repository’s COMPATIBILITY.md for details)
• Node.js 22+
• Git (worktrees are created locally, no network access required)

Installation and Activation¶

Install the published package into a DSH profile (Host plugins are loaded at DSH process startup, so restart DSH after installing or updating):

dsh plugin --profile web add dsh-tower

It can also be installed via the plugin manager inside DSH:

plugin_manager({ action: "install_bundle", target: "dsh-tower" })

For development, install from GitHub or link a local checkout:

dsh plugin --profile web add github:louifinn/dsh-tower
dsh plugin --profile <profile> add <absolute path to this repository>

Use remove_bundle to uninstall; the package name is dsh-tower.

Known conflict: Do not install it together with the third-party package dsh-plugins-tower; the loader-name conflict between the two may cause this package to be loaded twice. tower_doctor’s loader-conflicts can check for this.

The plugin accesses local Git and the filesystem with the permissions of the current DSH process; read the source code and the MIT license before installing to confirm that it meets your security and compliance requirements.

Typical Usage¶

First install the environment and restart DSH, then enter Tower mode in a session and invoke tools according to the mission lifecycle. The README quick-start example is as follows (replace the paths with your repository root):

/tower on

tower_init      repoRoot=D:\work\repo
tower_plan      repoRoot=D:\work\repo missions=[{"title":"Feature A","scope":["src/a/**"],"tasks":["implement","commit"],"kind":"build"}]
tower_spawn     repoRoot=D:\work\repo missionId=M1 role=worker
# worker implements and commits inside the worktree, then calls tower_complete
tower_spawn     repoRoot=D:\work\repo missionId=M1 role=reviewer   # enable review.requireReview:true first if independent review is required
tower_preflight repoRoot=D:\work\repo missionId=M1
tower_merge     repoRoot=D:\work\repo missionId=M1
tower_teardown  repoRoot=D:\work\repo

/tower off

Small changes typically require only one worker round; add a reviewer when independent review is needed. For a more complete example, see the repository’s docs/examples/first-mission.md; for tool parameters, see docs/reference/tools.md.

Common Slash Commands¶

Profile Configuration Snippet¶

The Tower section can be configured in a DSH profile (excerpt from a README example):

- id: tower
  name: 'dsh-tower'
  config:
    mode:
      allowAgentControl: true
      autoPauseGoal: true
      denyTools: [create_goal, todo_write, team_task_create, team_task_update, team_task_reopen, spawn_teammate]
    review:
      requireReview: false
      maxRoundsPerReviewer: 5
    merge:
      timeoutMs: 900000
    worktrees:
      root: ''
    spawn:
      workerPreset: tower-worker
      reviewerPreset: tower-reviewer
      maxDepth: 1

The bundled cordis.patch.yml also enables mode.workspaceLock, send.interruptDefault, init.autoGitInit, and so on by default; for all keys and default values, see docs/reference/config.md.

Use Cases and Caveats¶

Good for:

• A feature or refactor that can be split into 2–8 missions with clear, independently reviewable scopes;
• Migrations with dependency ordering that require branch freshness and scope constraints;
• Repository changes that require auditable merges and test evidence (independent review can be enabled as needed);
• Work spanning multiple days that requires restoring state from .git/dsh-tower/.

Not suitable for: a one-line hotfix to a single file, requirements still being explored, open-ended research, many tiny independent tasks, interactive UI pairing, or cross-repository work. Rule of thumb: if you would not open a PR for it, Tower is probably overkill.

Comparison with other modes (summarized from the README): ordinary parallel sub-agents are cheap and flexible but offer no worktree or merge gates; Agent Teams suit cross-cutting decisions but lack hard Git-isolation gates; the Ralph loop suits iterative search but has no mission contract; Workflow suits batch pipelines but does not do branch isolation. They can be combined by phase—for example, use Workflow/Team to analyze first, then use Tower to execute repository changes.

An optional Web UI is shipped with the npm package under ui-bundle/; after installing, point plugin_manager at the corresponding directory and restart DSH. The DSH ecosystem philosophy is “everything is a plugin”; community directories such as skillhub.cn are independent sites and have no official affiliation with DeepSeek / High-Flyer.

Conclusion¶

dsh-tower converges multi-agent collaboration into a delivery protocol of “a small number of missions + worktree isolation + optional review + merge gates,” making it well suited to turning repository changes into a recoverable, auditable workflow in DSH. For further information, see the plugin directory page and the GitHub repository.