关于 capsule-driver
capsule-driver 是用于驱动软件切片分阶段实现的 Skill,通过分层 Agent 在主工作树中推进计划中的阶段,并由人类协调者读取交接结果。它强调串行执行、上下文分层和实现完成后停止,不负责规划或审计。
主要功能
- 01按阶段批次委派编排 Agent
- 02通过规划 Agent 制定单阶段运行表
- 03由工作 Agent 实现阶段
- 04读取交接并检查计划调整
- 05实现完成后停止,不启动审计
适用场景
- 01执行已完成设计与计划的切片
- 02将多个连续阶段分批交给子 Agent
- 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 一个阶段 → 源码变更
你要做的是尽量少消耗上下文。你不是差异审查者,而是编排者的启动者和交接内容的阅读者。
前置条件——启动任何任务前请检查
-
会话权限设置。 子 Agent 会继承你的模式,处于
bypassPermissions/acceptEdits模式的父级无法被子级覆盖。在default模式下,每个后台子 Agent 的权限提示都会出现在你的会话中,并标明请求者——这不会造成死锁,但会不断打扰你,违背分层的初衷。请确认操作者使用的权限设置是他们愿意让整棵树继承的。 -
启动深度。 这棵树需要在你之下再有 2 层。默认值(3)足够,因此无需设置。只有设得过低才会造成阻碍:如果
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH设为低于 2,达到上限时Agent会被静默禁用——无法启动子 Agent 的编排者会悄悄自己完成工作。使用printenv CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH检查;未设置或 ≥ 2 即可。 -
没有其他写入者。 所有工作都在主工作树中运行,不受隔离限制。开始前请确认这棵树中没有其他 Agent 正在工作。
-
切片已规划。 设计已锁定,
plan.toml已编写,阶段已创建。此技能负责实施计划,不负责制定计划。 -
关闭后台任务。 开始前,将
CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1导出到会话环境中。整棵树严格串行——所有子 Agent 都无法使用TaskOutput,因此这里没有任何 Agent 能读取正在运行的子 Agent;而执行框架默认会在后台运行,所以每次启动都会变成完成通知,并在父级的完整上下文中重新调用父级。若不设置此开关,以下各层会退而请求前台运行,但这由模型决定,并无保证。在会话外部设置——按会话设置,绝不要写入
settings.json。 此设置仅适用于此席位的运行,而非整个仓库:它还会禁用 Bash 的run_in_background,而这棵树中的其他工作可能会合理地使用该功能。不要为了省一步而将其设为项目设置。
循环
- 为协调器设定章程:指定一个命名切片和一段连续阶段,通常为 3 个阶段。启动
capsule-orchestrator,并提供该章程、切片 ID 以及人类设定的任何长期约束。**以未命名方式启动它——绝不要传入name。**命名启动会让协调器成为队友,而队友的子级无法将结果交还给它:他们的报告会发到你的工作位(“启动你的 Agent 已不再运行”)。 - 阅读它交还的结果。检查每位工作者选择的模型是否有充分理由——“默认模型”不算理由。检查它对计划做了哪些调整。
- **回收它。**拿到它交还的结果后,立即对协调器执行
TaskStop。它的任务已完成;若让它继续运行,它可能被意外通知唤醒,并消耗一个完整轮次来处理累积的上下文,却没有任何新结果要报告。确认它已从/tasks中消失,然后再设定下一个协调器的章程。 - 为下一段阶段设定下一个协调器的章程。始终启动一个新的协调器,不要恢复一个已疲惫的协调器。
- 按收到报告的方式记录阻碍(
doctrine observation record)。 - 阶段实现完成后立即停止。不要开始审计。
需要向人类升级处理的事项
子 Agent 无法提问——所有子 Agent 都无法使用 AskUserQuestion,因此协调器唯一的沟通渠道就是返回值。你是完整的升级处理路径。遇到影响重大的决策和治理冲突,且无法确定正确意图时,请让人类介入;其余事项由你自行决定。
边界
- **不是
/dispatch。**不使用工作树、不分叉、不隔离、不执行导入步骤。工作者直接编辑实际代码树,协调器直接提交。如果你需要隔离,或需要并行处理文件互不冲突的阶段,应改用/dispatch。 - **不要实现。**如果你正在编辑文件,就说明分层机制失效了,而且你正在消耗它本来要保护的上下文。
- 不要审计。
/audit是一个独立阶段,有自己的技能;此技能停止后应转至该阶段。
相关内容
/plan 和 /phase-plan 会产出此流程所需的内容。后续阶段是 /audit。/dispatch 是此技能的隔离工作树替代方案。