Preface¶

The session lifecycle of DSH is independent: work done in Session A is unknown to Session B by default; tasks completed by sub-agents cannot be carried over to the next session. To continue previous work, one must rely on a human re-explaining the context or copying the to-do list into some external tool. dsh-task-relay moves this external tool into a plugin: a cross-session task relay board based on a persistent queue, plus a session handoff summary.

Below is an introduction to the positioning, tools, installation methods, and typical usage of this plugin. The information is based on the YaoleWu/dsh-task-relay repository README and GitHub repository metadata.

What is it¶

dsh-task-relay is maintained by YaoleWu, MIT licensed, written in TypeScript, currently with 2 stars on GitHub, and categorized under workflow. It provides two things:

• A cross-session shared task queue where any session (including sub-agents) can push, claim, complete, or cancel tasks;
• A session handoff summary that records progress and to-dos when a session ends and is read when a new session starts.

It does not connect to the network or execute external commands; data is stored in a local JSON file. The plugin is positioned as a pure utility plugin, registering 7 tools for session invocation.

Seven Tools¶

An overview of the tools in the README is as follows:

Task states flow between open, claimed, and done. Cancellation handles based on the current state. Claiming and completing have session ownership checks to prevent other sessions from tampering.

Installation and Enablement¶

The installation commands given in the README are as follows:

# Install to web profile
dsh plugin --profile web add github:LeslieWylie/dsh-task-relay

# Install to headless profile
dsh plugin --profile headless add github:LeslieWylie/dsh-task-relay

Or append a bundle declaration in cordis.yml:

- id: task-relay
  name: 'dsh-task-relay'

One thing to note: the owner in the README is LeslieWylie, but the current repository is actually located at YaoleWu/dsh-task-relay. It is recommended to confirm that the GitHub path is resolvable before installation, or rely on the actual commands shown on the directory and repository pages.

If you want to specify a different path after enabling, add config.root to the bundle line:

- id: task-relay
  name: 'dsh-task-relay'
  config:
    root: '~/.dsh/task-relay-staging'

There is also cordis.patch.yml inside the repository, used as a DSH bundle patch.

Typical Usage¶

Cross-Session Task Relay¶

Session A pushes a task:

task_push title="Fix Login Page Bug" priority="high" tags=["bug","frontend"]
→ { "id": "T1723647600000-1", "title": "Fix Login Page Bug", "status": "open", ... }

Session B views and claims it:

task_list status="open" priority="high"
→ Total 1 task, showing 1
task_claim id="T1723647600000-1"
→ { "id": "T1723647600000-1", "status": "claimed", "claimedBy": "session-b", ... }

Session B writes back the result after completion:

task_done id="T1723647600000-1" result="Fixed, commit abc123"
→ { "id": "T1723647600000-1", "status": "done", "result": "Fixed, commit abc123", ... }

This chain does not require both sessions to be online simultaneously; once the queue is persisted, the next claimant can pick it up.

Session Handoff¶

Write a summary when the session ends:

handoff_write summary="Completed development of Feature A, remaining Features B and C to be done. Feature B frontend components are scaffolded, backend API needs to get interface docs from session-x's handoff."
→ { "sessionId": "session-a", "summary": "...", "openTasks": 2, ... }

Read the summary when a new session starts:

handoff_read
→ Total 3 handoff summaries, showing the most recent 5

handoff_write returns a count of openTasks, and handoff_read can be retrieved by session ID or the most recent N entries.

Data Storage and Boundaries¶

The queue file is located by default at $HOME/.dsh/task-relay/queue.json. Writing uses a temp file + rename atomic write to avoid data corruption caused by the process being killed midway. Directory permissions are 700, so other users cannot read it.

Input validation is done at the source code level: title 200 characters, description 4000 characters, summary 2000 characters, and tags up to 10. Validation logic is concentrated in src/invariant.ts, storage in src/store.ts, and tool definitions in src/tools.ts. There are 18 unit tests covering the storage layer, 8 covering tool registration and execution, and an additional tests/boot.test.mjs that runs against the actual cordis registry.

The lib/ build artifacts are also committed to the repository. The README explains the reason: pnpm, for security reasons, defaults to refusing to execute build scripts for git dependencies. Installation from GitHub fails if the package entry lib/index.js does not exist, so tsc artifacts must be submitted together. The cost is that the build artifacts may become out of sync with the source code; boot.test.mjs and CI rebuild separately and compare, reporting an error if they are out of sync.

Applicability and Notes¶

Suitable usage scenarios are: breaking long tasks into multiple sessions for relay, handoff of intermediate artifacts between sub-agents, and leaving a searchable work log for subsequent sessions. The positioning as a pure utility plugin also means it is unsuitable for scenarios requiring online collaboration or permission isolation—all data is under the local home directory.

A few reminders:

• The plugin operates files with the permissions of the current DSH process; before installing, read the source code once to confirm that the caller has access to ~/.dsh/task-relay/;
• The license is MIT, please check the LICENSE text before commercial use;
• The peer dependency range is written somewhat convolutedly, @deepseek-ai/dsh-tools is limited to >=0.0.1-rc.1 <0.1.0 || >=0.1.0-rc.1 <0.2.0-0. The reason is the semver pre-release version matching rules; writing it directly as >=0.0.1-rc.1 <0.2.0 would not match the current 0.1.0-rc.6;
• The directory page is a community independent site with no official affiliation with DeepSeek / Huafan, plugin information is based on the repository.

Conclusion¶

The value of dsh-task-relay lies in compressing the cross-session scheduling cost to a few tool calls: task_push for dispatch, task_claim for claiming, task_done for writing back, and handoff_write for handoff, plus local atomic persistence and input validation. The number of stars is still small, the source code size is limited, and the interfaces are clear. It is worth trying when cross-session relay is needed.

Directory page: https://www.skillhub.cn/plugins/YaoleWu/dsh-task-relay
Repository: https://github.com/YaoleWu/dsh-task-relay