dsh-agent-lead

Running multiple AI agents on the same codebase invites a familiar mess: the main agent plans and edits at the same time, two subagents silently modify the same file, and acceptance checks turn into rubber-stamping. dsh-agent-lead's lead mode draws a hard line. Once you toggle /lead on, the orchestrator's write, edit, and str_replace_editor tools are blocked outright; it can only understand, decompose, dispatch, verify, and supervise. Every code change must flow through assign to a background subagent, and each dispatch pops up a model picker so you decide which model does the work and what it costs.

The plugin's heart is the scope territory contract combined with a four-step dispatch decision chain. Every subagent must declare a one-line responsibility summary and a list of file or directory paths upon creation, recorded in a per-session ledger. Before any dispatch the orchestrator must call lead_status to inspect the territory map; the system performs automatic path-overlap detection and rejects the assign call if two agents' paths collide, naming the conflict and suggesting alternatives. Six priority-ordered rules—single writer, rework goes to the original owner, independent review needs a fresh agent, same-domain work reuses existing agents, independent new domains spawn new ones, and contaminated agents retire—cover every routing decision from "should I create a new agent?" to "what does the full task brief look like?"

This is built for solo developers or small teams using dsh on medium-to-large multi-file changes who want disciplined orchestration without ceding control. If you are cost-sensitive about which model handles which subtask, already think in terms of work packages, and want an auditable, conflict-free pipeline between agents, lead mode turns your mental dispatch board into a concrete, tool-enforced workflow.