dsh-crew — 把一次任务交给一支角色小队：产品经理就在你的会话里，评审员只有只读工具，只有它能动 git

[stuarthu]

非官方项目，由社区成员独立开发与维护。

仓库：https://github.com/stuarthu/dsh-crew · npm 包名：dsh-crew（0.4.3）· MIT 许可

它是什么

dsh-crew 把一次任务交给一支小队来做。你自己的 dsh 会话变成 产品经理，也是唯一跟你说话的角色。它先写清「做完」的标准，等你确认，再叫 架构师 做设计、工程师 写代码、代码 / 安全 / 文档评审员 和 测试 做检查。调研员 会先在仓库里找答案，所以你只会被问文件回答不了的问题。

dsh plugin --profile tui add dsh-crew   # 或 --profile web

重启 dsh，开会话时选 Crew 这个预设。

分成两半，因为工具不住在 profile 里

dsh 把模型能看见的工具放在预设（agent preset）里，不放在 profile 里。所以这个插件分成两半：

哪一半	放在哪	为什么
产品经理的规矩	宿主这边（你的 profile）	它不需要任何工具，所以在任何预设的会话里都成立
各角色的工具	随插件装上的 crew 预设	子代理启动时，允许 / 禁止清单是按预设来核对的，名字必须和工具在同一处

crew 预设就是 dsh 自带的 standard，去掉 subagent、subagent_fork、workflow、ralph 和产品类子代理，换成小队角色。在这个预设里，能起代理的只有小队角色这一条路。

为什么小队是平的

dsh 有三条硬规矩：消息只能发给 直接的下级；下级只向 直接的上级 汇报；两个下级之间 完全不能 通话。所以只有产品经理起代理，每个角色都是它的直接下级，角色之间靠磁盘上的文件交接，而不是聊天。要是让架构师去起工程师，产品经理就再也联系不到工程师了。

评审员用「允许清单」，是两次实测逼出来的

角色不是产品经理粘过去的一段提示词，而是用 @deepseek-ai/dsh-tool-subagent 做出来的真工具，人设就是那个下级自己的系统提示词。评审员手上只有 read、glob、grep。之前用「禁止清单」的时候，发生了两件事：

1. 禁掉 write 和 edit 之后，它用 echo hello > file 照样把文件建出来了 —— 命令行本身就是一个写文件的工具。
2. 把命令行也禁掉，它自己报上来的工具单子里还列着 workflow、ralph 和一组控制桌面的 MCP 工具，每一个都是出口。

禁止清单说不出一个环境里还没装的东西，允许清单不需要说。每个角色工具还带着 maxDepth: 1，所以小队的下级不能再起下级。

只有产品经理动 git

host/git-guard.js 会看每个代理（产品经理也一样）发出的每一条命令，这些一律拒绝：推 main / master / trunk / develop / HEAD 或者不写分支名；推标签、删远端分支、--mirror、--all、强推；npm / pnpm / yarn / bun publish、npm dist-tag、gh release create；推向一个看起来会自动发包的仓库；还有任何碰到那个批准文件的命令 —— 代理不能自己批准自己。

别的分支要推，得你亲手建一个一次性的文件（touch ~/.dsh/crew/push-ok），一推就被删掉。每一次推之前产品经理都会问你，改完再推也要再问一次。

说句实话：它读的是命令的字面文本，是一根很结实的安全带，不是一道锁死的门 —— 藏在脚本文件里的命令还是可能溜过去。真正的关卡还是 dsh 自己的审批弹窗。

已知粗糙的地方

每个角色工具显示出来的，都是 dsh 通用的那句委派说明，因为 dsh-tool-subagent 没有「按行单独写说明」的设置。要是现在已经有办法做到，欢迎告诉我。

也欢迎聊聊升级预设这条路：新版本会整个替换掉预设文件夹，把你改过的文件留成 agent.cordis.yml.bak —— 能用，但不好看。

[zoahdev]

这条帖子值得单独提炼一个原则：允许清单 > 禁止清单。

你"禁掉 write/edit 却被 echo > file 绕过、禁掉命令行又漏出 workflow/ralph/MCP"的两次实测，本质是沙箱哲学在 agent 编排层的重现——禁止清单说不全一个环境里还没装的东西，允许清单不需要说。这和 dsh 自己的沙箱同源：windows-acl runner 的 fail-closed（#3207）、特权方法白名单（#3210）都是允许清单。建议把这条经验写进插件 README 的"设计原则"，它会成为其他编排类插件的教材。

另外两点：

1. "文本安全带，不是锁死的门"的诚实声明值得点赞——它和 Privileged RPCs behind a reverse proxy: accept verified proxy identity (Tailscale-User-Login) as operator equivalence — and a Host-passthrough finding #3210/webServer middleware layer (ctx.webServer.use): a request-level seam so plugins can guard /api #3186 讨论的同一原则一致：命令字面检查是 policy 不是 security boundary，真正的关卡是 dsh 的审批弹窗。你的 push-ok 一次性文件 + 每次推前询问的设计是"人肉确认"在编排层的正确形态。

2. dsh-tool-subagent 没有按角色单独写说明的设置——这是一个真实的 API 缺口，属于 out-of-tree 接缝家族（Remote contribution registry for out-of-tree Host plugins #3167 Remote 注册 / [Proposal] Session event registration for out-of-tree plugins — unknown event types refuse resume (dsh-click/observed|action crashes rc.6/rc.7) #3191 会话事件）。建议单独开一帖或在 Remote contribution registry for out-of-tree Host plugins #3167 里挂一笔，让官方知道"子代理工具的 per-role 描述"也是社区需要的 surface。

flat crew 的设计理由（dsh 层级硬规矩 → 角色间靠文件交接）逻辑自洽，安全边界的取舍都摆在了明面上，质量很高。