dsh-work-crew
DSH 插件：把任务派给本机的豆包 / WorkBuddy / ZCode / Qoder，用任务板与产物锁组织一支有纪律的 AI 班组。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:yxyusage/dsh-work-crew#f115f01dcd8105b9836b1ccee169813c10a930b7Work Crew 以 dsh-work-crew 发布，当前版本为 0.10.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
One prompt. A working team.
一个指令。一支有纪律的本机 AI 班组。
简体中文 · English
dsh-work-crew is a DeepSeek Harness plugin that turns the AI apps already
installed on your machine — Doubao, WorkBuddy, ZCode, Qoder — into a crew with a task board.
DSH stays the orchestrator. It does not write your code itself; it plans, dispatches, enforces locks, collects receipts and keeps the books. The crew does the typing.
One model reviewing its own work is the weakest link in every AI coding session:
| Failure | What the crew does instead |
|---|---|
| Self-review blind spot — the model checks its own output | A different model reviews it; the implementer never signs off on itself |
| Concurrent edits — writing and reviewing the same file at once | Artifact locks: write:landing:hero and read:landing cannot overlap in time |
| Lost progress — who is waiting for whom, asked again next session | A task board on disk (.dsh-team/) with dependencies, locks and timeline |
# from GitHub
dsh plugin --profile desktop add github:yxyusage/dsh-work-crew
# from a local checkout
dsh plugin --profile desktop add "E:\path\to\dsh-work-crew"
Then fully quit DSH (tray → Quit) and reopen it.
team_init → create .dsh-team/ (mission, roles, board, outbox)
team_add_task → title, worker, dependsOn, write/read locks, expect
team_dispatch → builds a brief, enforces locks, sends it (queues when busy)
team_collect → wait for receipts; takes taskIds, returns whoever finishes first
team_status → board: who is running, what is queued, which locks are held
A typical plan:
T1 implement hero WorkBuddy write:landing:hero
T2 review landing Doubao read:landing ← waits for T1 (write×read)
T3 product discussion Doubao — ← runs in parallel with T1
T4 docs Qoder write:docs dependsOn: [T1, T2]
| Tool | When to use |
|---|---|
team_init | first time in a project; records reference dirs and required docs |
team_status | who runs what, queue depth, last activity, held locks |
team_add_task | declare worker, dependencies, locks, deadline, expected artifacts |
team_dispatch | send a brief; takes taskIds to dispatch several in one step; queues when a worker is busy |
team_collect | wait for receipts: taskIds returns whoever finishes first |
team_reassign | move a task to another worker, keeping brief and history |
team_reopen | a false completion → back to running, without re-sending |
team_resubmit | artifacts now exist → re-check expect instead of re-dispatching |
team_release | close a task (refuses done while expected artifacts are missing) |
team_split_html | split a single-file page into html/css/js so three workers can edit in parallel |
team_shot | screenshot to a file, path only — device emulation for mobile widths |
team_workers | status / preflight / restart / ping |
| id | App | Good at | Debug port |
|---|---|---|---|
workbuddy | WorkBuddy | implementing, running commands, verifying builds | 9332 |
doubao | Doubao | visual review, ideas, reading screenshots | 9331 |
zcode | ZCode | implementation / second opinion (limited free quota) | 9334 |
qoder | Qoder | implementation / read-only audits (VS Code family) | 9335 |
--remote-debugging-port and types into its chat box.
Windows can stay offscreen; nothing steals your mouse.@@END@@ sentinel.
No guessing from text stillness..dsh-team/outbox/<id>.md and reply with one line.
The body never enters the orchestrator's context — that is where the token savings come from.landing covers landing:hero; siblings (hero, meta) run in parallel.queued, no locks, no timeout) and promotes it when the
current one is collected.deadlineMin (default 45) flags a stalled task; at twice the budget it is blocked and its locks released.expect paths must exist before a task counts as done; the outbox file is added automatically.Use team_shot — it already avoids both traps and returns only a path:
team_shot { "target": "index.html", "out": "shots/mobile-390.png", "width": 390, "mobile": true }
Trap 1 — capturing mid-animation. A headless shot without a virtual clock lands on the fade-in, so the page looks
half-transparent. team_shot emulates prefers-reduced-motion: reduce and waits for the layout to settle.
Trap 2 — resizing the window instead of emulating the device. --window-size=390,844 sets the window, but the
layout keeps the desktop viewport (~980px), so the shot is a cropped desktop page. That reads as "the layout overflows"
and sends a reviewer chasing a bug that does not exist. Device emulation is the only honest mobile shot, and
team_shot checks scrollWidth for you: if it equals the viewport, the layout is fine.
Six checks stand between "the model says it is done" and "the task is done":
| Guard | What it does |
|---|---|
review: true | The reviewer gets requirement + git diff + rubric only. It is told not to read the implementer's report — a reviewer that inherits the author's narrative inherits the author's blind spots. |
| Snapshot review | The changed files are copied to .dsh-team/snapshots/<id>/ and the reviewer reads the copy, so the review takes no read lock and the next implementation starts immediately. Diffing starts from the implementer's recorded baseCommit, so committed work still shows up. |
verify: "pnpm build" | The acceptance command runs in the project before the task may close. A red build blocks the task; no green build, no done. |
risk: "high" | High-risk work (auth, payments, CI, secrets, installers) never self-approves: collecting it only reports "awaiting approval" until a human re-collects with confirm: true. |
rubric.md + review round counter | team_init writes the project's acceptance rubric; every review carries it. From the 4th review of the same artifact, the brief asks whether the plan is wrong instead of requesting another patch list. |
crossCheck: true | After a review, a second reviewer gets the findings and votes on each one: holds / false positive / not enough evidence. Only confirmed issues survive. |
"Make it look good" produces nothing. "Look at this, apply it like so, ship when these three rules hold" changes the output.
team_knowledge ships curated references; the matching ones are injected into the brief automatically — authors do not have to remember to ask.
| Entry | What it enforces | Source |
|---|---|---|
de-ai-slop | no purple gradients, no three-card hero, no emoji icons, real content instead of filler | anti-slop checklist |
frontend-ui | component structure and the four states (default/hover/focus/disabled) | shadcn AI Elements |
motion | shared-element transitions, 120–360 ms, transform/opacity only, reduced-motion fallback | smooth-option-switcher |
empty-states | why it is empty, what to do now, what you will get | Carbon patterns |
typography-color | modular scale, 16–18px body, 4.5:1 contrast, no pure black | type-scale |
copywriting | verbs on buttons, examples instead of adjectives, no judgement | NN/g microcopy |
a11y | keyboard path, visible focus, button semantics | web.dev a11y |
Beyond the interface, the same mechanism covers backend and review work:
| Entry | What it enforces | Source |
|---|---|---|
api-design | plural resources, RFC 9457 errors, idempotent writes | Google AIP |
backend-patterns | 12-factor, when splitting a service is justified | microservices.io |
sql-data | index by query, read the plan before touching indexes | use-the-index-luke |
testing | test pyramid, regression test per bug | Fowler |
code-review | five things to look at, two grades of comment | Google eng-practices |
security | server-side validation, auth at every entry, secrets out of logs | OWASP Top 10 |
observability | structured logs, metrics, actionable alerts | OpenTelemetry |
technical-writing | one page, one purpose (tutorial/how-to/reference/explanation) | Diátaxis |
web-performance | measure first: LCP/INP/CLS | HPBN |
Matching: explicit tags on the task win; otherwise keywords in the title and brief decide. The worker matters too —
Doubao is held to design/motion, Qoder to security/structure, ZCode to copy/docs, WorkBuddy to implementation. At most 4
entries, each rendered as link + how to use + what not to do + 3 rules.
And the loop closes at review time: a review task receives the checklist the implementer was given, up to 8 rules,
each to be judged done / not done (with location) / not applicable. That turns "check it" into findings you can act on.
Project-specific entries go in .dsh-team/knowledge/<id>.md and override built-ins by id:
team_knowledge { "action": "add", "id": "brand-guide", "title": "品牌规范", "tags": ["frontend","color"],
"url": "https://...", "use": "配色只从这 5 个色里选", "avoid": "自创渐变",
"rules": ["主色 #1f6feb，只用于主按钮", "正文色 #0f1115 / #e6e8eb"] }
flowchart TB
A["team_add_task<br/>tags · locks · expect · verify · risk"] --> B{"能否并行？<br/>不同文件 / 不同 worker"}
B -- 是 --> C["team_dispatch taskIds<br/>一次派多个"]
B -- 否 --> D["team_dispatch"]
C --> E["简报 = 需求 + diff + 参考资料 + 对照清单"]
D --> E
E --> F["worker 干活<br/>正文写 outbox/<id>.md · 聊天只回 DONE"]
F --> G{"收单闸门"}
G -- 控制台报错 / 溢出 --> H["blocked 打回"]
G -- expect 缺失 --> H
G -- verify 命令失败 --> H
G -- 知识库机械规则 --> H
G -- 全部通过 --> I["评审：快照 + 对照清单逐条判"]
I --> J{"通过？"}
J -- 否 --> K["修复任务<br/>按文件并行"]
K --> F
J -- 是 --> L["team_bundle 合并单文件<br/>自动复检"]
L --> M["交付"]
Four gates stand between "the model says done" and done: artifacts exist (expect), the build passes (verify),
the page actually runs (console errors + overflow + mechanical gates), and a reviewer judges the same checklist the
implementer was given. Any failure blocks the task instead of passing it downstream.
Measured on a real run (18 tasks, one landing page). Method: UTF-8 3 bytes per Chinese character, 1 token ≈ 1.5 characters.
| Quantity | Measured | Why it matters |
|---|---|---|
| Worker output kept on disk | 115,188 bytes in 17 outbox files ≈ 25.6k tokens | With chat delivery this enters the orchestrator's context and is re-sent on every later step |
| Briefs sent to workers | 57,864 bytes ≈ 12.9k tokens | Sent over CDP straight into the apps — never touches the orchestrator's context |
| Average single output | 6,776 bytes ≈ 1.5k tokens | One read costs more than the whole dispatch brief |
| Dispatch calls | 8 calls for 18 tasks (taskIds batch) | ~10 fewer steps than one call per task |
| Collect calls | 10 calls for 18 tasks (taskIds batch) | Whoever finishes first returns; no polling loop |
| Restarts | 1 call for four apps (restart all) | Was 4 steps, each re-sending the conversation |
| Screenshots | path only, image never read | Each image read costs ~1–2k tokens and stays in context |
The arithmetic that matters: a step costs context size × 1. Keeping 25.6k tokens of worker prose out of the context saves that amount on every subsequent step. Over a 40-step run that is roughly a million token-equivalents of context traffic that never happens (mostly cache reads — cheap, but not free).
What it costs: each dispatch carries ~800 bytes of references plus a ~2k-token checklist to the worker. That is paid to the worker's API, not to the orchestrator.
team_workers {"action":"restart","worker":"doubao"}), which is also the fix when a port goes stale.spec version and
team_workers {"action":"ping"} tells you whether the chain still works.team_reassign.--remote-debugging-port and --remote-debugging-pipe.index.js tools + the /dsh-work-crew/state route for the panel
lib/team.js board, locks, briefs, roles, queue
lib/cdp.js CDP sessions, launch, typing, reading, completion rules
client.js sidebar panel (React, conversation.composer.dock)
locale/ zh + en metadata
MIT