dsh-multitask

The Multitask "shock absorber" mode for DeepSeek Harness — the main conversation never touches your codebase.

English · 中文 · Design notes and measured evidence · MIT License

A work mode for DeepSeek Harness（DSH） in which the main conversation does exactly three things: understand what you asked for, turn it into task briefs, and report back what the Subagents concluded. Every piece of process data — file contents, command output, build logs, search results, dead ends — is digested inside a Subagent's context and never enters the main one. The main conversation therefore holds only high-value information.

This is a mechanism, not a prompt asking the model to behave. Once the mode is selected, the main conversation (the coordinator) genuinely has a narrower tool surface: the tools that would drag in process data — writing files, running commands, searching the web — are not in its visible set. It cannot call them, so it cannot pollute its own context. A Subagent (worker) is the opposite: it gets the full tool surface, does the work, and returns only its conclusion.

Zero runtime dependencies. No changes to DSH source.

At a glance: How it differs from other modes What the coordinator keeps (a whitelist): Read-only checks — read grep glob file_info Delegation — subagent subagent_fork subagent_ptc subagent_minimal Subagent control — send_message interrupt_agent list_agents Result retrieval — job_list job_output job_kill Orchestration — workflow Interaction and self-management — ask_user_question todo_write create_goal get_goal update_goal exit_plan_mode present skill

Anything not on that list is withheld by default — write, edit, pwsh, web_search, web_fetch, read_image, ssh_*, task_board_*, plugin_manager, and so on. The rule is a complement: withheld = currently visible − kept. Any tool the host adds later is therefore also withheld from the coordinator by default, with no change needed in this plugin.

The read-only tools are kept on purpose: the coordinator is meant to verify a Subagent's claims independently instead of trusting them blindly. Mode isolation: it only narrows its own sessions

The narrowing is applied only to sessions whose live preset binding is this preset. A session belonging to another mode in the same workspace keeps its own tool roster and is not touched — so you can run several modes side by side without them eating each other's tools.

Switching a session out of the mode lifts the restriction again, and switching into it before the first turn narrows it before the first request is even made.

presetId is that ownership key. If you change it to install variants side by side, each variant narrows only its own sessions; and if it no longer matches the registered preset id, no session is narrowed at all — the mode can look installed while quietly doing nothing.

When ownership cannot be read, the guard prefers not to narrow rather than risk narrowing a neighbour's session. The cost of a registry hiccup is therefore one possibly un-narrowed turn, never a broken neighbouring mode. Installation From the published package (recommended)