dure run，只是提示词变成了”目标 + 内置的负责人简报”。负责人不写代码：它为每个工作项开一个 GitHub issue，为每个 issue 在专用 worktree 中启动一个工作者 Run，等待工作者，合并通过检查的 pull request，最后以一份报告收尾。工作者同样是普通的 Run，负责人交给它们的简报才使它们成为工作者。没有新增任何存储：计划在 GitHub 里，Run 在 Dure 里。
开始之前
- 一个已注册的项目（
dure projects list），其目录是带 GitHub 远程的 Git 检出，并且gh已用有权在该仓库创建 issue 和 pull request 的账号登录。 - 执行主机上已登录的提供商。示例使用 Claude Code。
- 使用 Claude 工作者时，先在该账号里信任一次项目目录。Claude Code 在账号首次打开某个目录时会显示目录信任提示，停在提示上的工作者还没有读到简报。信任项目根目录即可覆盖 Dure 在
<project>/.worktrees/下创建的 worktree。用同一账号在项目根目录打开一个 Claude 会话并接受提示，然后再启动负责人。 - 决定同时运行多少个工作者。默认是 3 个；其他上限写进目标里。
启动负责人
--lead 会在目标前面加上负责人简报；简报把智能体引向 dure skills get dure-lead，也就是随 CLI 一起分发的完整流程。其余部分与普通 Run 相同：--project 或 --path 选择项目，--space 决定面板位置，--json 返回回执。负责人只做读取并运行 gh 和 dure，所以可以留在项目根目录；拿到 worktree 的是工作者。bypass_approvals 让它运行这些命令时不必等待批准；若想在面板里逐条批准，省略它即可。
不启动任何东西、只阅读流程：
接下来会发生什么
一个三个 issue 的小例子：
工作者简报要求每个工作者：阅读自己的 issue，留在自己的 worktree 中，在行为所在的层级测试，针对默认分支开一个带
Closes #n 的 pull request，等待 CI，已知不稳定的作业只重跑一次，仓库规则允许时自行合并，最后以一条写明 pull request 的评论收尾。需要产品决策的工作者不会猜测，而是给 issue 打上 needs:founder 标签并停下。
合并前等待评审
默认情况下，每个工作者在 CI 变绿后自行合并自己的 pull request。若要在合并前评审每个 pull request，请用--merge-policy review 启动负责人：
lead:approved 标签。请求修改或留下评审意见后，负责人会把它们转给工作者，工作者推送修复后再次等待。只剩等待评审的 pull request 时，负责人会发布报告，把它们标为 awaiting review 并等待；评审完成后发一条消息，例如 dure send lead-onboarding "reviewed"，它就会合并已批准的 pull request。负责人从不自行批准 pull request 或给它加标签。如果目标要求合并前评审，不加该标志也会采用同一策略。
自己盯一盯
input_required 的工作者正停在首次运行的提示上：Claude 的目录信任提示，或在该工作者的 Codex 账户登录已失效时出现的 Codex 登录界面。它的 dure run 回执以 prompt_delivery_uncertain 结束并带有 startup_gate（workspace_trust 或 login）。简报已在代理内部排队，不能再次发送：按上面的说明信任目录，或在该工作者的面板里回答提示或登录，工作者就会自行继续。负责人会报告这一状态，而不是假设工作者已经开始。
阅读报告
dure runs resume 继续任意一个。
限制
- 一个负责人、一个项目、一个后端：负责人在自己运行的后端上启动工作者。
- 每个工作者都是一个完整的提供商会话；上限保护的是你的机器和账号额度，而不是正确性。
- 负责人不回答信任或权限提示，不在产品选项之间做选择，只有在目标明确要求且仓库允许时才以管理员权限合并。
- Dure 尚未记录哪个工作者负责哪个 issue；
lead:claimed标签和 pull request 就是共享的记录。