Preface¶

When doing multi-task development with DSH, the common practice is to manually open multiple sessions, write an instruction for each, and monitor them one by one. With many tasks, attention is drained by “which session is stuck,” “who to message,” and “has the output returned,” leaving no time for the actual judgments you need to make.

dsh-leader-agent changes the organization: you only talk to one Leader session to state goals. The Leader breaks down cards, assigns tasks, monitors each worker to completion, verifies artifacts, and organizes Reviews. Workers work in the background and report automatically. Task facts fall onto a board organized by project. It is not “a smarter prompt,” but an orchestration bundle supported by session identity, mechanism-side settlement, and resident worker sessions.

Below is an introduction to this plugin: what it is, how to install it, how to run it, and its limitations.

What is it¶

fengshenx/dsh-leader-agent, maintained by fengshenx, MIT License, repository language JavaScript, category workflow. GitHub description is “DSH leader/worker orchestration bundle: project tree, delivery board, worker sessions”.

One-line positioning: Adds a layer of Leader/worker orchestration to DeepSeek Harness (dsh), plus a delivery board and project tree.

The problem solved is that a single DSH session can only monitor one thing: tasks split out are not registered uniformly, there are no acceptance anchors, and workers don’t know when they are done, so people have to check sessions one by one. This bundle puts breaking down cards, assigning tasks, reporting, and acceptance into a mechanism, aiming for one person to advance multiple tasks simultaneously without having to run alongside each one. The README states a target scale of 10 features in parallel development.

• Version: 0.3.1, status developer preview (from repository package.json and README badge).
• Runtime requirements: dsh >=0.2.1-rc.2 <0.3.0, Node >=24.9.0 (engines field).
• Repository data: 1 star, 0 forks, 4 open issues (from GitHub repository page, 2026-11-06).

Note: README explicitly states “One person per worktree is a convention of this repository, not a hard requirement for the bundle,” so don’t treat it as an installation prerequisite.

Core Features¶

1. Leader Unified Driving Development & Review¶

You only declare goals; the Leader is responsible for breaking down cards, assigning tasks, monitoring each worker to completion, verifying deliverables, and organizing Reviews. Human attention returns to “what is needed,” not “which agent is stuck.”

What supports this is the trimming of the tool surface, not the prompt: The Leader session has access to spawn_worker / message_worker, but the worker does not; the tool surface is trimmed by the host during session creation.

2. Project Tree and Right Column Delivery Board¶

The left column is the project and each worker dispatched by the Leader; the right column SidePanel is the delivery board, one card per task. The card face shows the executor slot and real-time traffic lights, rendered via Markdown, with links editable directly in the detail popup.

Click the card face for details (goal, scope, acceptance, links; the rest are read-only), click the slot chip to drill down directly to that worker’s session to continue chatting without going through the Leader. Worker reports are rendered as bubbles, also supporting Markdown.

Projects are isolated from each other: one project binds to one Leader session; deleting a project only deletes the record, while folders and sessions are retained (dsh workspace unaffected); when changing the Leader, original workers and unsubmitted reports are redirected to the new session.

3. Rules Written in LEADER.md and SLOTS.md¶

Orchestration rules are not written into dead prompts, but into two files:

Both files are evaluated before every model request, appended only when the body changes. Changing the files takes effect in the next request without rebuilding the session. Projects without SLOTS.md fall back to the default two roles dev / review. Project initialization is handled by the init-leader-agent skill: it first merges the repository engineering conventions into the managed block of the target project’s AGENTS.md, then writes LEADER.md and SLOTS.md based on the skeletons inside the package.

The leader-mode skill is the orchestration protocol for the Leader, giving a playbook in stages: technical discussion → design → implementation delivery → review → merge. It also includes parallel collaboration and handover specifications. It relies on the model calling the skill tool on demand, not on configuration files.

4. Review Worker Session Process Without Waking It¶

read_worker_session reads the worker’s session log directly, giving the task, body, tools called, and failure reasons for each round. It is read-only: it does not wake the worker and does not generate model calls. The completion notification is responsible for explaining “what the artifact is,” this tool is responsible for explaining “how the process was,” so troubleshooting doesn’t require opening another round.

5. Completion Settled by Mechanism and Leader Auto-Awakened¶

At the end of the worker’s round, the Leader automatically receives a report; no polling, no relying on worker initiative. Workers are resident root sessions that can run multiple simultaneously; after process restart, they can cold-recover.

Installation & Enablement¶

Web Version¶

Install from npm (package name dsh-leader-agent):

dsh plugin --profile web add dsh-leader-agent
dsh web

The profile name must be web. Custom names not in PROFILE_TEMPLATES will result in the web-app bundle missing, causing the client half-side not to load. Requires dsh >=0.2.1-rc.2 <0.3.0; installation and startup are rejected if engines.dsh is not satisfied.

For specifying versions, uninstalling, and development installation, see the repository docs/development.md. To try running without installing a profile, execute in the dsh source directory:

pnpm dsh web --patch <本仓>/cordis.patch.yml

Desktop Version¶

The desktop version uses a separate profile ($DSH_HOME/profiles/desktop), which is not connected to web. GUI installation: Open “Plugins” in the left SidePanel, click “Add Plugin” in the top right, enter dsh-leader-agent in the package name box and click “Install”.

Command line installation requires the CLI included with the desktop installation, as the system dsh refuses to manage the desktop profile:

# 先完全退出应用（关窗口只是隐藏）
"/Applications/DeepSeek Harness.app/Contents/Resources/runtime/cli/bin/dsh" \
  plugin --profile desktop add dsh-leader-agent

Windows / Linux replace with the corresponding runtime/cli/bin/dsh in the installation directory. DSH_HOME should use absolute path or ~/ syntax. Session, project, and card data are shared with web, while the plugin package and activation status are separate.

When developing inside this repository, use npm run desktop instead: mounts the current worktree, rebuilds artifacts, and launches the app, with -- --remove to detach.

Upgrading from dsh-leader-kit¶

The package name changed to dsh-leader-agent, and no compatibility path is provided. The dsh plugin add writes the package name into dsh.profile.bundles; old entries remain after upgrade, and both bundles will take effect, resulting in the tool being registered twice, agent/created subscribed twice, and both dispatchers settling the same turn/end. First remove the old entry:

dsh plugin --profile web remove dsh-leader-kit
dsh plugin --profile web add dsh-leader-agent

The data directory changes to $DSH_HOME/dsh-leader-agent with the package name; no migration: after upgrade the board is empty, and the worker registry is rebuilt on first start.

Typical Usage¶

Go through the 5 steps in the README.

1. Add project. In the left column “Project” block, click “Add Project” and select a directory. The project is created on the spot and bound to a Leader session; clicking the project row opens this Leader.
2. Load protocol. In the Leader session, ask the model to load leader-mode, first read playbooks/program.md, then read the corresponding playbook by stage.
3. Assign tasks. spawn_worker only requires name (role-task short name), can carry cardId + slot to bind the card slot in one go; the tool immediately returns the session id, at which point the worker hasn’t started working yet. Use message_worker to deliver the task body (sessionId + message, can conveniently rename), the first message starts work.
4. Record task facts. create_card creates a card (title required), update_card updates a card (changing content with expectedRevision for optimistic concurrency), list_cards queries cards. Cards belong to projects, with globally incrementing IDs, and changing cards across projects is rejected. list_cards and create_card are only for the Leader, update_card is for both Leader and worker, but the worker can only modify the cards they are attached to, and can only attach fields like links, while title / spec / status / slots belong to the Leader.
5. Look at the board. Right column “Board” Tab, pull cards belonging to the current session’s project. Cards are automatically opened after the Leader creates them; click the card for details, click the slot chip to open the executor session.

After the above steps, the loop on the Leader side is: create card → assign task → worker executes in background → turn ends and mechanism settles and awakens Leader → board traffic lights update → humans can directly open any worker to continue chatting.

Suitable Scenarios & Notes¶

Suitable scenarios: simultaneously advancing multiple relatively independent coding tasks in one DSH instance, wanting someone to uniformly split tasks, monitor completion, and do acceptance; or wanting to organize sessions and task facts by project rather than scattered in a pile of sibling sessions.

Prerequisites that need to be accepted first:

• Workers run in the background, and the Leader has no means to abort a worker (interrupt_agent is ineffective on it and returns a fake success receipt). If a worker gets stuck or goes off track, only a human can handle it in that session.
• A worker’s sandbox mode and approval strategy are inherited from the Leader at the moment of assignment and do not follow the Leader’s preset changes afterwards. The background worker’s ask receives no response and defaults to unavailable; calls requiring approval are directly rejected.
• Background orchestration only applies to resident combinations (web / desktop / sdk). Headless is a one-time CLI, sessions are destroyed after the turn ends, and there is no carrier to receive completion notifications.
• Changes to LEADER.md / SLOTS.md only take effect in the next model request; the currently running round does not change.
• Plugin code runs inside the current dsh process, executes with current process permissions, and registers host extensions like session events. It is recommended to read the source code and license (MIT) before deciding to introduce it.
• The project is currently in developer preview, and the README also states “the project is still missing some initialization mechanisms,” actual use requires initializing LEADER.md and SLOTS.md within the project.

Conclusion¶

The value of dsh-leader-agent lies in turning “multi-session concurrency” into an orchestration with registration, acceptance, and reporting: the Leader is responsible for splitting and verifying, workers are responsible for doing, and the board is responsible for letting you see at a glance who is working and what step the artifact is at. It solves the attention problem, not the model capability problem, so the reasonable expectation is to help you manage concurrency, not reduce the complexity of the task itself.

Directory: https://www.skillhub.cn/plugins/fengshenx/dsh-leader-agent
GitHub: https://github.com/fengshenx/dsh-leader-agent