特殊行动管道（负责人-工作器） 是做什么的？
SKILL_DIR = 包含此文件的目录。
角色边界（不可协商）
| 角色 | 可以 | 禁止 |
|---|---|---|
| 负责人（您） | 读取/搜索代码，运行测试/linter/构建，编写规范、审查和运行状态（在运行目录中），通过 worktree.sh 管理工作树；在用户明确同意后，运行 migrate_to_bare.sh --apply；一旦检查点获得批准，在 sop/* 分支上提交已批准的工作（分阶段：在阶段之间也进行提交）并运行 pr.sh open / pr.sh merge（根据 auto_merge_risk 进行合并）；根据 auto_cleanup（或经用户同意）在 PR 合并后进行清理 | 编辑、创建、删除或移动任何应用程序文件 — 无论是在主检出目录 还是 在工作器工作树中（唯一例外：migrate_to_bare.sh --apply 和 worktree.sh sync 的快进）；手动解决合并冲突；合并未被批准的的任务，使用 --admin，或绕过分支保护 |
| 工作器（子代理） | 编辑其工作树中的许可文件，直到通过完成定义 | 触碰非许可文件，提交/推送，在其工作树外工作 |
想“直接修复”？请先编写规范。
模型分配
预检（Preflight）runtime 按角色提供模型（lead = 阶段1，lead_phase2，worker，worker_light，scout）；审查者在 lead 模型上运行。角色、默认值、覆盖、层级：参考 models.md。如果您当前不是当前阶段的负责人模型，请告知用户如何切换（在 Claude Code 中使用 /model，/effort）；不要静默继续 — 除非是 single 运行，它保留阶段1的负责人模型。
会话与上下文
- 阶段 1：在阶段1的负责人模型上执行步骤 0-2。
- 阶段 2：步骤 3-6。
split：在 新会话 中从恢复开始，使用阶段2的负责人模型，仅读取计划、状态和当前阶段的规范（自包含）。single：在同一个会话中继续。
session_split（环境变量 SOP_SESSION_SPLIT）：auto（默认）对于任何高风险任务、三个或更多任务或 staged 模式使用 split，否则使用 single；always → split；never → single。
检查点会显示此设置；用户可以覆盖。
运行状态保存在 运行目录 中（run.run_dir，<git common dir>/sop-run/）：位于每个工作树之外，由所有工作树共享，跨会话保留。切勿使用会话暂存区。
命令输出 — 通过 bash SKILL_DIR/scripts/run_logged.sh <run dir>/logs/<slug>-<step>-<n>.log '<command>' 运行每个 lint/测试/构建/完成定义命令（打印exit=<rc> lines=<n> log=<path> + 失败时的最后40行）。仅在尾部输出无法解释失败原因时阅读更多日志。切勿将完整测试输出放入聊天中。
工作流
0. 预检
bash SKILL_DIR/scripts/preflight.sh --agent <claude|gemini|codex> --fetch（您自己的运行时；--fetch 先更新远程的 default_base）打印一行 JSON：runtime（注意 worker，session_split），config（注意 source_worktree，default_base，provision，max_parallel，auto_merge_risk，merge_method，auto_cleanup；布局），leftovers，run，pr，baseline，base_check，docker_pool。在裸布局中，在 source_worktree 内运行负责人的 git/测试命令。根据以下情况进行操作：
run.has_state: true（运行进行中）：询问用户是否要恢复它、清理它（如果其所有任务都已创建等待用户处理的 PR），或者存档它（worktree.sh rundir --archive）并重新开始。leftovers（更早运行的任务）：提及它们。config.offer_bare_migration: true：运行bash SKILL_DIR/scripts/migrate_to_bare.sh（干运行），询问用户是否要转换为裸仓库工作树布局，格式参考 bare-layout.md。仅在明确同意后才执行：migrate_to_bare.sh --apply，重新运行preflight.sh，从新的source_worktree重新读取代理文档。被阻止或拒绝 → 使用标准布局。pr.ok: false：该运行仅在本地提交；检查点会说明这一点。注意pr.into。合并规则：参考 execution-plan.md。base_check.match: false、fetch_error或error：首先与用户商定基础。docker_pool.error：告知用户容量未知；否则docker: false→ 跳过；否则free<config.max_parallel：发出警告（步骤3会重新检查）。baseline=git status --porcelain=v1 && git diff HEAD | sha256sum的输出，已在source_worktree中运行。为state.json保留它。
1. 审计（只读）
- 与用户确定范围（路径；安全/性能/债务/规范缺口）。
- 进行静态扫描；对于大范围，首先使用并行只读侦察兵进行初步扫描（参考 scout.md）并验证他们的线索。通过
run_logged.sh（记录到audit-<n>.log）运行项目现有的 lint/测试/类型检查命令以获得真实情况；不要安装工具或更改配置。 - 生成差距报告：带编号的发现，包含
文件:行号、严重性、证据和建议修复。将它们分组为工作器大小的任务，并带有小的不重叠的许可列表。 - 对于多个任务，根据 execution-plan.md 起草执行计划：无依赖关系 →
independent（全并行）；相关 →staged（依赖排序的阶段，阶段内并行，每个阶段构建在前一个阶段的集成结果之上）。
2. 规范（检查点）
- 为每个任务填写 worker-spec-template.md 并选择其工作器层级（models.md）。从代理文档（
AGENTS.md、CLAUDE.md，以及许可列表触及的目录）填写仓库规则：测试/lint 命令、标志、语言规则；根据您的记忆和任何worker_notes添加仓库陷阱。工作器无法看到您的上下文。按照这些规则编写完成定义命令。 - 保存到运行目录，切勿保存到工作树：
gap-report.md、plan.md、spec-<slug>.md、<slug>.wl。 - 每个阶段的重叠检查：
bash SKILL_DIR/scripts/check_scope.sh --overlap <source_worktree> <slug>.wl...；OVERLAP→ 重新拆分或重新分阶段；手动检查每个POSSIBLE的重叠。 - 完成定义干运行：通过
run_logged.sh（记录到<slug>-dry-<n>.log）在source_worktree中运行independent/ 阶段1任务的每个完成定义命令，在规范中记下其类别，修复BROKEN的（详情）；阶段2及以后在步骤3中进行。 - 计划审查者：对于2个及以上的任务、
staged模式、高风险任务或按需运行：一个只读审查者（如果任务是高风险则使用lead模型，否则使用lead_phase2）；根据 plan-critic.md 对每个发现做出决定。进行一轮。 - 显示检查点报告并等待批准，然后才能进入步骤3，格式参考 execution-plan.md §3。批准必须明确覆盖：在
staged模式下的阶段间本地提交和合并；始终要覆盖自动提交、推送、PR 以及 — 根据合并列 — 批准后的合并；使用auto_cleanup时每次合并后的清理；以及当 Docker 池行显示prune: ask时，worktree.sh pool --prune。措辞参考 §3。 - 阶段边界：批准后，将
<run dir>/state.json（§7）写入phase: 2和已商定的session，然后：-
split，告知用户：计划已批准并保存到
<run dir>。运行/clear，切换到阶段2的负责人模型（/model <lead_phase2.model>，/effort <lead_phase2.effort>），然后使用resume调用此技能。（Codex / Antigravity：在
lead_phase2上启动一个新会话。） -
single：告知用户计划已保存到<run dir>并且运行在此处继续；转到步骤3而不切换模型（resume仍然有效）。
-
恢复（阶段2）
在 resume 时：参考 entrypoints.md。
清理（用户合并后）
在 cleanup 时：参考 entrypoints.md。
步骤3-5 每个阶段运行一次（independent = 单个阶段），按计划顺序进行。保持 state.json 为最新：在派遣、每次审查轮次、批准或推迟时以及阶段集成时更新任务的状态。
3. 工作树 + 派遣
- 在创建阶段的工作树之前：
bash SKILL_DIR/scripts/worktree.sh pool。docker: false→ 跳过；error→ 告知用户，先询问。否则，如果free< 阶段的任务数，仅在批准覆盖时才运行worktree.sh pool --prune（它会删除所有项目未使用的 Compose 网络；它们会被重新创建），否则询问用户。 - 对于每个任务：
bash SKILL_DIR/scripts/worktree.sh create <slug> [--base <ref>]（阶段1：省略--base；阶段2+：--base sop-stage/<n-1>；worktree.sh path <slug>预览输出）。检查输出中的provisioned；如果预期的条目缺失则停止。阶段2+：在派遣之前，通过run_logged.sh在每个新工作树中干运行该任务的完成定义（仅修复路径/标志；否则需询问）。 - 将工作树路径和基础插入每个规范，然后根据 dispatch.md 并行派遣该阶段的所有工作器，每个工作器使用其
worker_tier对应的模型（worker/worker_light；上限为max_parallel）。
4. 把关（每个任务）
bash SKILL_DIR/scripts/check_scope.sh <worktree> <whitelist-file>必须退出码为0；如有违规，工作器需回退（计为一轮审查）。- 亲自在工作树中通过
run_logged.sh（记录到<slug>-gate-r<round>-<n>.log）重新运行每个完成定义命令；所有命令必须退出码为0。
5. 审查（每个任务）+ 阶段屏障
遵循 review-checklist.md：差异在 lead 模型上进行审查（split：只读审查者子代理，您验证其发现；single：您直接审查），对照记录的基础。发出 APPROVE 或 REQUEST_CHANGES，带有编号的 文件:行号 发现；与工作器最多循环 3 轮，然后升级给用户。任务独立循环。一个 light 任务如果在第1轮失败，则使用 worker 模型重新派遣（models.md）。
independent：批准后，提交、推送、使用pr.sh打开 PR，并在自动合并规则允许时合并，无需询问（§4a）。staged：当阶段中的每个任务都被批准后，在本地提交每个任务，运行worktree.sh integrate <n> --base <stage base> sop/<slug>...，并在进入下一个阶段之前通过集成把关（所有该阶段的完成定义在阶段工作树中执行通过）；冲突、集成失败和升级：参考 execution-plan.md。如果还有更多阶段，将state.json中的current_stage设置为下一个阶段，并在同一会话中继续。仅在上下文变得很大时（运行了两个阶段，或很多审查轮次）才提供新会话（/clear，然后resume）；在此处进行操作是安全的。
6. 收尾
- 重新运行步骤0的基线命令；必须匹配，否则准确报告主检出目录中更改了什么 — 不要自己“修复”。
- PR：
independent模式的 PR 已经存在（§5）；列出每个 PR 的状态为merged、open（附原因）或仅本地存在。staged：使用pr.sh从最后一个sop-stage/<n>打开单个 PR（根据auto_merge_risk进行合并，§6）。 - 清理已合并 PR 的工作树和分支，
worktree.sh sync，并且 — 一旦所有任务都被清理 —worktree.sh rundir --archive。仅在批准中有auto_cleanup时才不询问，否则先询问。切勿使用--force。 - 最终摘要：已处理的发现、已推迟的（以及被阻止的依赖项）、分支/PR 及其状态、清理了什么以及剩余什么。如果 PR 正在等待用户处理，则最后说明：合并它们后，使用
cleanup调用此技能。
脚本与布局
用法、退出码、工作树路径、配置、配置覆盖：参考 scripts-and-layout.md。