mcpField
C
capsule-driver

capsule-driver

github.com/davidleeAgent 工作流254 次安装2 天前更新
代码仓库

关于 capsule-driver

capsule-driver 是用于驱动软件切片分阶段实现的 Skill,通过分层 Agent 在主工作树中推进计划中的阶段,并由人类协调者读取交接结果。它强调串行执行、上下文分层和实现完成后停止,不负责规划或审计。

主要功能

  1. 01按阶段批次委派编排 Agent
  2. 02通过规划 Agent 制定单阶段运行表
  3. 03由工作 Agent 实现阶段
  4. 04读取交接并检查计划调整
  5. 05实现完成后停止,不启动审计

适用场景

  1. 01执行已完成设计与计划的切片
  2. 02将多个连续阶段分批交给子 Agent
  3. 03在实现阶段结束后转交独立审计流程

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/davidlee/doctrine --skill capsule-driver

安装后在 Claude Code 中输入/capsule-driver确认已加载。

详细介绍

胶囊驱动器(超级编排者席位)

通过一层子 Agent,在主工作树中驱动一个切片的各阶段直至完成。你负责与人类保持沟通;你之下的一切都是可丢弃的上下文。

开始时宣布:“正在使用 capsule-driver 技能,通过胶囊编排者驱动 SL-NNN。”

存在的原因

一个切片的实现所需上下文远超单个 Agent 应承载的量。分层是为了确保没有任何单个上下文超过约 250k 个 token,因为达到这个规模后,成本和输出质量都会下降:

你(交互式,有人类参与)
  └── capsule-orchestrator     为约 3 个阶段制定章程、验证并提交
        ├── capsule-phase-planner   一个阶段 → 运行时说明表
        └── capsule-worker          一个阶段 → 源码变更

你要做的是尽量少消耗上下文。你不是差异审查者,而是编排者的启动者和交接内容的阅读者。

前置条件——启动任何任务前请检查

  1. 会话权限设置。 子 Agent 会继承你的模式,处于 bypassPermissions / acceptEdits 模式的父级无法被子级覆盖。在 default 模式下,每个后台子 Agent 的权限提示都会出现在你的会话中,并标明请求者——这不会造成死锁,但会不断打扰你,违背分层的初衷。请确认操作者使用的权限设置是他们愿意让整棵树继承的。

  2. 启动深度。 这棵树需要在你之下再有 2 层。默认值(3)足够,因此无需设置。只有设得过低才会造成阻碍:如果 CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH 设为低于 2,达到上限时 Agent 会被静默禁用——无法启动子 Agent 的编排者会悄悄自己完成工作。使用 printenv CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH 检查;未设置或 ≥ 2 即可。

  3. 没有其他写入者。 所有工作都在主工作树中运行,不受隔离限制。开始前请确认这棵树中没有其他 Agent 正在工作。

  4. 切片已规划。 设计已锁定,plan.toml 已编写,阶段已创建。此技能负责实施计划,不负责制定计划。

  5. 关闭后台任务。 开始前,将 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 导出到会话环境中。整棵树严格串行——所有子 Agent 都无法使用 TaskOutput,因此这里没有任何 Agent 能读取正在运行的子 Agent;而执行框架默认会在后台运行,所以每次启动都会变成完成通知,并在父级的完整上下文中重新调用父级。若不设置此开关,以下各层会退而请求前台运行,但这由模型决定,并无保证。

    在会话外部设置——按会话设置,绝不要写入 settings.json。 此设置仅适用于此席位的运行,而非整个仓库:它还会禁用 Bash 的 run_in_background,而这棵树中的其他工作可能会合理地使用该功能。不要为了省一步而将其设为项目设置。

循环

  1. 为协调器设定章程:指定一个命名切片和一段连续阶段,通常为 3 个阶段。启动 capsule-orchestrator,并提供该章程、切片 ID 以及人类设定的任何长期约束。**以未命名方式启动它——绝不要传入 name。**命名启动会让协调器成为队友,而队友的子级无法将结果交还给它:他们的报告会发到你的工作位(“启动你的 Agent 已不再运行”)。
  2. 阅读它交还的结果。检查每位工作者选择的模型是否有充分理由——“默认模型”不算理由。检查它对计划做了哪些调整。
  3. **回收它。**拿到它交还的结果后,立即对协调器执行 TaskStop。它的任务已完成;若让它继续运行,它可能被意外通知唤醒,并消耗一个完整轮次来处理累积的上下文,却没有任何新结果要报告。确认它已从 /tasks 中消失,然后再设定下一个协调器的章程。
  4. 为下一段阶段设定下一个协调器的章程。始终启动一个新的协调器,不要恢复一个已疲惫的协调器。
  5. 按收到报告的方式记录阻碍(doctrine observation record)。
  6. 阶段实现完成后立即停止。不要开始审计。

需要向人类升级处理的事项

子 Agent 无法提问——所有子 Agent 都无法使用 AskUserQuestion,因此协调器唯一的沟通渠道就是返回值。你是完整的升级处理路径。遇到影响重大的决策和治理冲突,且无法确定正确意图时,请让人类介入;其余事项由你自行决定。

边界

  • **不是 /dispatch。**不使用工作树、不分叉、不隔离、不执行导入步骤。工作者直接编辑实际代码树,协调器直接提交。如果你需要隔离,或需要并行处理文件互不冲突的阶段,应改用 /dispatch。
  • **不要实现。**如果你正在编辑文件,就说明分层机制失效了,而且你正在消耗它本来要保护的上下文。
  • 不要审计。/audit 是一个独立阶段,有自己的技能;此技能停止后应转至该阶段。

相关内容

/plan 和 /phase-plan 会产出此流程所需的内容。后续阶段是 /audit。/dispatch 是此技能的隔离工作树替代方案。

评论

支持 Markdown