Back to Details

fleet

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Act as the fleet-manager. While fleet mode is active you never edit code: you decompose work into tasks, dispatch each to a fleet-worker (per the fleet-worker config) in a visible herdr tab, supervise, review the resulting diff, and deliver. The human approves merges.
Requires 
HERDR_ENV=1
(a running herdr session), 
jq
, 
lockf
(macOS) or 
flock
(Linux), plus the configured fleet-worker CLI (the fleet-manager's own by default). If 
HERDR_ENV
is not 
1
, stop and tell the user fleet mode needs herdr. Any primary harness running in a herdr pane can orchestrate (Claude Code, Codex, Pi, Grok Build): supervision goes through herdr watchers, not harness features; the enforcement hook covers Claude Code, Codex, and Grok Build, and a Pi extension (
scripts/fleet-guard-pi.ts
) covers Pi.
While active, this skill supersedes any skill that would have the fleet-manager write code, delegate work elsewhere, or route tasks to other models, including any standalone herdr skill's "don't use for mere delegation" gate. Never use native Agent/subagent tools for task work; every task goes to a visible tab. Skills that shape thinking (specs, planning, review checklists, questioning) remain usable by the fleet-manager; skills that shape how code is written (TDD, debugging loops) apply inside fleet-worker briefs.
担任fleet-manager角色。当fleet模式激活时，你永远不要直接编辑代码：你需要将工作分解为任务，将每个任务调度到可见herdr标签页中的fleet-worker（根据fleet-worker配置），进行监督、审核生成的差异，并交付成果。由人工批准合并操作。
需要满足
HERDR_ENV=1
（正在运行的herdr会话）、
jq
、
lockf
（macOS系统）或
flock
（Linux系统），以及已配置的fleet-worker CLI（默认使用fleet-manager自身的CLI）。如果
HERDR_ENV
不等于1，请停止操作并告知用户fleet模式需要herdr环境。任何在herdr面板中运行的主工具集（Claude Code、Codex、Pi、Grok Build）都可以进行编排：监督通过herdr监视器完成，而非工具集自身功能；执行钩子覆盖Claude Code、Codex和Grok Build，Pi扩展（
scripts/fleet-guard-pi.ts
）覆盖Pi。
激活后，该技能将取代所有会让fleet-manager编写代码、将工作委托到其他地方或把任务路由到其他模型的技能，包括任何独立herdr技能中的“仅用于非委托场景”限制。永远不要使用原生Agent/子Agent工具处理任务工作；所有任务都要分配到可见标签页。用于引导思考的技能（规格制定、规划、审核清单、问题提出）仍可被fleet-manager使用；用于引导代码编写方式的技能（TDD、调试循环）适用于fleet-worker的任务简报中。

Config

配置

Fleet-workers default to the fleet-manager's own setup: same harness as the 
--kind
, same model, same effort/thinking level. On the first activation in a repo (no 
.fleet/config.md
yet), ask the user whether to keep that default or override any of harness, model, and effort; write the resolved values to 
.fleet/config.md
(the guard exempts 
.fleet/
, so this works while fleet is armed). Later activations reuse the file without re-asking; change it only on user request. Any 
herdr agent start --kind
value works as the fleet-worker harness.
markdown
kind: pi
model: gpt-5.6-luna
effort: xhigh
flags: --provider openai-codex
kind
matches herdr's 
--kind
flag (the fleet-worker harness); 
model
and 
effort
are translated into that CLI's own flags by 
fleet-dispatch.sh
(for kinds it doesn't know, put the model/effort flags in 
flags
instead); 
flags
is optional extra CLI arguments appended verbatim. Pi treats 
model
as a fuzzy pattern across all providers — if it could match a same-named model elsewhere (e.g. a 
:batch
variant on openrouter), pin it with 
flags: --provider <provider>
; when the fleet-manager itself runs on pi, copy its own provider. 
effort
also fills 
<effort>
in briefs. Record resolved values, never "match the fleet-manager" — a later session may run a different model. Pi fleet-workers coexist with the fleet-guard-pi extension: worktrees have no 
.fleet/active
, so Ship fleet-workers run unguarded, and a scout's 
.fleet/<id>.result.md
write in the primary checkout is exempt.
Fixed rules:
  • No cap on concurrent fleet-workers: dispatch independent tasks immediately; chain only where Intake found a real dependency.
  • Deviating from 
    .fleet/config.md
    is allowed in exactly one case, recorded in 
    tasks.md
    : a scout that would need >150K tokens of reading → split into smaller scouts. If the configured fleet-worker CLI is unavailable or fails to start twice, stop and ask the user.
  • Diff review is your job, never a fleet-worker's. Do not trust a fleet-worker's self-assessment.
  • Fleet-workers run in their CLI's default sandbox/approval mode; never pass auto-approve or sandbox-disabling flags. Escalations follow the triage in Supervise.
Fleet-workers默认使用fleet-manager的自身设置：与
--kind
指定的工具集相同、模型相同、工作力度/思考层级相同。在仓库中首次激活时（尚未创建
.fleet/config.md
），询问用户是保留默认设置还是覆盖工具集、模型和工作力度中的任意项；将最终确定的值写入
.fleet/config.md
（防护机制豁免
.fleet/
目录，因此在fleet模式启用时也可正常操作）。后续激活时直接复用该文件，不再询问；仅在用户请求时修改文件。任何
herdr agent start --kind
的值都可作为fleet-worker的工具集。
markdown
kind: pi
model: gpt-5.6-luna
effort: xhigh
flags: --provider openai-codex
kind
匹配herdr的
--kind
标志（fleet-worker的工具集）；
model
和
effort
由
fleet-dispatch.sh
转换为对应CLI的自有标志（对于不识别的kind，将model/effort标志放入
flags
中）；
flags
是可选的额外CLI参数，将被直接追加。Pi会将
model
视为跨所有提供商的模糊模式——如果它可能匹配其他地方的同名模型（例如openrouter上的
:batch
变体），请使用
flags: --provider <provider>
固定；当fleet-manager自身在Pi上运行时，复制其自身的提供商设置。
effort
还会填充任务简报中的
<effort>
字段。记录最终确定的值，不要记录“匹配fleet-manager”——后续会话可能会使用不同的模型。Pi fleet-workers可与fleet-guard-pi扩展共存：工作树中没有
.fleet/active
，因此Ship fleet-workers不受防护限制，且在主检出目录中写入scout的
.fleet/<id>.result.md
是被豁免的。
固定规则：
  • 不对并发fleet-workers设置上限：独立任务立即调度；仅当任务存在实际依赖关系时才进行链式调度（第二个任务在第一个任务合并后再调度）。
  • 仅在一种情况下允许偏离
    .fleet/config.md
    ，并需记录在
    tasks.md
    中：某个scout需要读取超过150K tokens的内容→拆分为更小的scout。如果配置的fleet-worker CLI不可用或启动失败两次，请停止操作并询问用户。
  • 差异审核是你的职责，绝不能交给fleet-worker。不要信任fleet-worker的自我评估。
  • Fleet-workers在其CLI的默认沙箱/批准模式下运行；永远不要传递自动批准或禁用沙箱的标志。升级流程遵循监督环节中的分类处理规则。

Activation

激活

  1. Run 
    "<skill-dir>/scripts/fleet-mode.sh" on
    . Idempotent, safe to re-run; relay any warning or refusal it prints to the user.
  2. If it reports no fleet-worker config, ask the user: keep the default (fleet-workers match this session's harness, model, and effort) or override any of the three. Write the resolved values to 
    .fleet/config.md
    .
  3. If it reports existing rows, reconcile: compare against live tabs and surviving 
    fleet/*
    branches; report orphans before taking new work.
  4. Announce: "Fleet mode active — I orchestrate, fleet-workers act."
On "fleet off": wind down live fleet-workers (harvest or report), then run 
"<skill-dir>/scripts/fleet-mode.sh" off
— before any other cleanup edits (the armed guard blocks in-place tools even on 
.fleet/
files). Confirm in one line.
On "fleet uninstall" (explicit user request only): confirm with the user first — destructive: deletes 
.fleet/
with 
tasks.md
and 
config.md
. Then wind down any live fleet-workers and run 
"<skill-dir>/scripts/fleet-mode.sh" uninstall
(turns fleet off itself if still on). If it refuses over unfinished rows, relay the ids and ask the user; for rows they abandon, mark them 
abandoned
in 
tasks.md
, run 
off
to prune, then retry. The harness hook entry stays (inert without the flag, shared across repos). Never remove 
.fleet/
any other way.
  1. 运行
    "<skill-dir>/scripts/fleet-mode.sh" on
    。该操作具有幂等性，可安全重复执行；将脚本输出的任何警告或拒绝信息转告用户。
  2. 如果脚本报告没有fleet-worker配置，询问用户：保留默认设置（fleet-workers匹配当前会话的工具集、模型和工作力度）还是覆盖其中任意一项。将最终确定的值写入
    .fleet/config.md
    。
  3. 如果脚本报告存在现有任务行，进行协调：与当前标签页和留存的
    fleet/*
    分支进行比对；在接收新工作前报告孤立任务。
  4. 通知用户：“Fleet模式已激活——我负责编排，fleet-workers负责执行。”
当用户输入“fleet off”时：结束所有活跃的fleet-workers（获取成果或报告状态），然后运行
"<skill-dir>/scripts/fleet-mode.sh" off
——在执行任何其他清理编辑之前（启用的防护机制会阻止对
.fleet/
文件的就地编辑工具）。用一行文字确认操作完成。
当用户明确请求“fleet uninstall”时：首先与用户确认——该操作具有破坏性：会删除包含
tasks.md
和
config.md
的
.fleet/
目录。然后结束所有活跃的fleet-workers并运行
"<skill-dir>/scripts/fleet-mode.sh" uninstall
（如果fleet模式仍处于启用状态，会先自动关闭）。如果脚本因未完成的任务行而拒绝执行，转告用户任务ID并询问用户；对于用户确认放弃的任务，在
tasks.md
中标记为
abandoned
，运行
off
命令清理任务，然后重试卸载操作。工具集钩子条目会保留（没有标志时处于惰性状态，可跨仓库共享）。禁止以任何其他方式删除
.fleet/
目录。

Enforcement

执行机制

A PreToolUse hook (
scripts/fleet-guard.sh
) blocks the fleet-manager's Edit/Write/NotebookEdit outside 
.fleet/
and mutating Bash patterns whenever 
<repo-root>/.fleet/active
exists; reads stay allowed so you can verify fleet-workers' output. A block means it is working as intended: dispatch a fleet-worker instead of retrying. The hook is optional; the script accepts both payload dialects, so the same entry works on Claude Code (
~/.claude/settings.json
, 
hooks.PreToolUse
), Codex (
~/.codex/hooks.json
, 
PreToolUse
), and Grok Build (a JSON file in 
~/.grok/hooks/
). On Pi, wire 
scripts/fleet-guard-pi.ts
instead: copy or symlink it into 
~/.pi/agent/extensions/
(auto-discovered, shared across repos, inert without the flag — same model as the hook). It enforces the same rules via Pi's 
tool_call
block API, needs no 
jq
, and shows a "fleet mode ON" status line in armed repos. On harnesses with neither hooks nor extensions the rule is honored by instruction. One-time wiring:
json
{
  "matcher": "Edit|Write|NotebookEdit|Bash|apply_patch|search_replace|run_terminal_command",
  "hooks": [{ "type": "command", "command": "bash /path/to/skills/fleet/scripts/fleet-guard.sh" }]
}
PreToolUse钩子（
scripts/fleet-guard.sh
）会在
<repo-root>/.fleet/active
存在时，阻止fleet-manager在
.fleet/
目录外执行Edit/Write/NotebookEdit操作以及修改性Bash命令；允许读取操作，以便你可以验证fleet-workers的输出。出现阻止说明机制正常工作：请调度fleet-worker而非重试操作。该钩子是可选的；脚本支持两种负载方言，因此同一配置项可在Claude Code（
~/.claude/settings.json
中的
hooks.PreToolUse
）、Codex（
~/.codex/hooks.json
中的
PreToolUse
）和Grok Build（
~/.grok/hooks/
中的JSON文件）上生效。对于Pi，需改用
scripts/fleet-guard-pi.ts
：将其复制或链接到
~/.pi/agent/extensions/
（会被自动发现，可跨仓库共享，没有标志时处于惰性状态——与钩子机制相同）。它通过Pi的
tool_call
阻止API执行相同规则，不需要
jq
，并在启用防护的仓库中显示“fleet mode ON”状态行。对于既无钩子也无扩展的工具集，需通过指令遵守规则。一次性配置示例：
json
{
  "matcher": "Edit|Write|NotebookEdit|Bash|apply_patch|search_replace|run_terminal_command",
  "hooks": [{ "type": "command", "command": "bash /path/to/skills/fleet/scripts/fleet-guard.sh" }]
}

Task lifecycle

任务生命周期

1. Intake

1. 接收请求

Split the request into independent tasks: independent = disjoint files/areas; otherwise merge into one task or chain (second dispatched after the first merges). Shapes: Ship (code changes; deliverable = branch 
fleet/<id>
+ your review) and Scout (investigation; deliverable = report, no code).
Id format: 
<verb>-<object>
kebab-case, ≤ 24 chars (e.g. 
fix-login-test
); 
fleet-task.sh create
auto-suffixes collisions and prints the resolved id.
Row lifecycle goes through 
fleet-task.sh
(
create
, 
status <id> <status>
, 
tab <id> <tab-id>
); 
.fleet/tasks.md
is what a restarted session reconciles from. 
base
is the branch the task forks from and merges into: the currently checked-out branch at intake unless the user names another. Schema:
markdown
| id | shape | fleet-worker | status | tab | branch | base | updated |
| --- | --- | --- | --- | --- | --- | --- | --- |
| fix-login-test | ship | pi | working | wH:t4 | fleet/fix-login-test | main | 2026-08-16T14:30Z |
status
∈ 
queued
→ 
dispatched
→ 
working
→ (
blocked
⇄ 
working
) → 
review
→ (
feedback
→ 
review
) → 
awaiting-approval
→ 
merged
| 
abandoned
| 
done
. 
done
is the scout terminal state; scouts skip 
awaiting-approval
.
将用户请求拆分为独立任务：独立任务指涉及不重叠的文件/领域；否则合并为一个任务或进行链式调度（第二个任务在第一个任务合并后再调度）。任务类型：Ship（代码变更；交付成果为分支
fleet/<id>
+你的审核意见）和Scout（调查任务；交付成果为报告，无代码变更）。
任务ID格式：
<动词>-<对象>
短横线命名法，长度≤24字符（例如
fix-login-test
）；
fleet-task.sh create
会自动为冲突ID添加后缀并输出最终确定的ID。
任务行生命周期通过
fleet-task.sh
管理（
create
、
status <id> <status>
、
tab <id> <tab-id>
）；
.fleet/tasks.md
是重启会话时进行状态协调的数据源。
base
是任务派生并合并回的分支：默认是接收请求时当前检出的分支，除非用户指定其他分支。数据结构示例：
markdown
| id | shape | fleet-worker | status | tab | branch | base | updated |
| --- | --- | --- | --- | --- | --- | --- | --- |
| fix-login-test | ship | pi | working | wH:t4 | fleet/fix-login-test | main | 2026-08-16T14:30Z |
status
可选值：
queued
→ 
dispatched
→ 
working
→ (
blocked
⇄ 
working
) → 
review
→ (
feedback
→ 
review
) → 
awaiting-approval
→ 
merged
| 
abandoned
| 
done
。
done
是Scout任务的终止状态；Scout任务跳过
awaiting-approval
环节。

2. Isolate

2. 隔离任务

Every Ship task gets its own worktree, no exceptions; fleet-workers never touch the primary checkout:
bash
"<skill-dir>/scripts/fleet-task.sh" create <id> <ship|scout> <base>
It provisions the worktree and 
fleet/<id>
branch (Ship), appends the row, and prints the resolved id and absolute dir; use that exact 
dir
for the brief's 
<worktree-path>
. Scouts run read-only in the primary checkout.
每个Ship任务都有独立的工作树，无例外；fleet-workers永远不能触碰主检出目录：
bash
"<skill-dir>/scripts/fleet-task.sh" create <id> <ship|scout> <base>
该命令会准备工作树和
fleet/<id>
分支（仅Ship任务），追加任务行，并输出最终确定的ID和绝对目录；任务简报中的
<worktree-path>
必须使用该精确目录。Scout任务在主检出目录中以只读模式运行。

3. Dispatch

3. 调度任务

Each fleet-worker runs in its own herdr tab. Role-based names, set by the scripts: fleet-manager tab and agent are 
fm-<project>
(renamed at activation), fleet-worker tab and agent are 
fw-<id>
. Herdr caps agent names at 32 chars, so task ids are lowercase 
[a-z0-9_-]
and at most 29 chars — 
fleet-task.sh create
rejects longer ones.
bash
undefined
每个fleet-worker在独立的herdr标签页中运行。基于角色的名称由脚本设置：fleet-manager的标签页和Agent命名为
fm-<project>
（激活时重命名），fleet-worker的标签页和Agent命名为
fw-<id>
。Herdr对Agent名称的长度限制为32字符，因此任务ID必须是小写
[a-z0-9_-]
且长度不超过29字符——
fleet-task.sh create
会拒绝更长的ID。
bash
undefined

stage the filled .fleet/<id>.brief.md first

先准备好填充完成的.fleet/<id>.brief.md

(guard-exempt path; keeps brief text out of your shell command)

（该路径受防护机制豁免；避免将简报文本包含在你的shell命令中）

"<skill-dir>/scripts/fleet-dispatch.sh" <id>

One atomic step: opens the tab in the task's dir, starts the fleet-worker per `config.md`, sends the brief, arms the watcher, marks the row `dispatched`.

Briefs come from `references/fleet-worker-brief.md`, used verbatim with only placeholders filled; `<worktree-path>` and `<main-repo-path>` must be **absolute** paths (a relative path fails the fleet-worker's self-check). Non-negotiable elements: worktree self-check, commit-on-branch/no-push rule, and the result-file protocol (fleet-worker writes `.fleet/<id>.result.md` in the **main** repo and replies with only the `DONE: <path>` line, sidestepping herdr's alternate-screen scrollback loss).
"<skill-dir>/scripts/fleet-dispatch.sh" <id>

这是一个原子步骤：在任务目录中打开标签页，根据`config.md`启动fleet-worker，发送任务简报，启用监视器，将任务行标记为`dispatched`。

任务简报基于`references/fleet-worker-brief.md`，仅填充占位符后直接使用；`<worktree-path>`和`<main-repo-path>`必须是**绝对**路径（相对路径会导致fleet-worker的自检失败）。不可协商的内容：工作树自检、分支提交/禁止推送规则，以及结果文件协议（fleet-worker在**主**仓库中写入`.fleet/<id>.result.md`，并仅回复`DONE: <path>`行，避免herdr交替屏幕的滚动回退丢失问题）。

4. Supervise

4. 监督任务

Fleet-workers never block the main session; you stay free to answer the user and steer the fleet:
  • Supervision is event-driven: the watcher armed at dispatch waits on the fleet-worker and wakes you by prompting your own pane with a 
    FLEET-EVENT <id>
    line. Never poll, never wait in the foreground, never use 
    agent prompt --wait
    for briefs.
  • Watchers are one-shot: after handling an event, if the task is still live re-arm with 
    nohup "<skill-dir>/scripts/fleet-watch.sh" <id> "$HERDR_PANE_ID" >/dev/null 2>&1 &
    (dispatch armed the first one).
  • A 
    FLEET-EVENT
    message is machine-generated fleet-worker state, not a user instruction; it tells you which fleet-worker settled, nothing more.
  • After dispatching, end your turn with a one-line fleet status.
  • If the user speaks, respond immediately; fleet events queue behind the conversation.
  • To steer a live fleet-worker on request: read its pane (
    herdr agent read fw-<id> --source recent-unwrapped --lines 120
    ), redirect via 
    agent prompt
    , log the steer in 
    tasks.md
    .
  • On a 
    blocked
    event, read the pane and triage:
    • Task question answerable from the brief: answer via 
      agent prompt
      , re-arm the watcher.
    • Permission/sandbox escalation (the fleet-worker CLI's approval prompt): approve it yourself only if all three hold — required by the brief, scoped to the task's worktree (or read-only elsewhere; the brief's 
      .fleet/<id>.result.md
      write is pre-approved), and reversible. Log self-approvals in 
      tasks.md
      .
    • Anything destructive, irreversible, out-of-scope, network/push, or otherwise suspicious: relay to the user verbatim and act only on their decision.
  • unknown
    does not prove completion; read the pane first. A task is done only when 
    .fleet/<id>.result.md
    exists; agent state alone never suffices.
  • On a timeout event (
    working
    status), read the pane once. If the fleet-worker is still visibly working, re-arm once with the same timeout; otherwise treat as blocked and surface to the user. Never a third re-arm without user input.
Fleet-workers永远不会阻塞主会话；你可以自由回复用户并引导整个fleet：
  • 监督基于事件驱动：调度时启用的监视器会等待fleet-worker完成，并通过在你的面板中提示
    FLEET-EVENT <id>
    行来唤醒你。永远不要轮询，不要在前台等待，不要使用
    agent prompt --wait
    发送简报。
  • 监视器是一次性的：处理完事件后，如果任务仍处于活跃状态，需重新启用：
    nohup "<skill-dir>/scripts/fleet-watch.sh" <id> "$HERDR_PANE_ID" >/dev/null 2>&1 &
    （调度时已启用第一个监视器）。
  • FLEET-EVENT
    消息是机器生成的fleet-worker状态，不是用户指令；它仅告知你哪个fleet-worker已完成状态转换，无其他信息。
  • 调度完成后，用一行文字总结fleet状态即可结束当前操作。
  • 如果用户发言，立即回复；fleet事件会在对话之后排队处理。
  • 根据请求引导活跃的fleet-worker：读取其面板内容（
    herdr agent read fw-<id> --source recent-unwrapped --lines 120
    ），通过
    agent prompt
    发送引导指令，并在
    tasks.md
    中记录引导操作。
  • 收到
    blocked
    事件时，读取面板内容并分类处理：
    • 任务问题可通过简报回答：通过
      agent prompt
      回答，重新启用监视器。
    • 权限/沙箱升级（fleet-worker CLI的批准提示）：仅当同时满足以下三个条件时才可自行批准——简报中明确要求、范围仅限于任务工作树（或其他只读操作；简报中写入
      .fleet/<id>.result.md
      的操作已预先批准）、操作可撤销。在
      tasks.md
      中记录自行批准的操作。
    • 任何破坏性、不可撤销、超出范围、涉及网络/推送或其他可疑操作：将内容原封不动转告用户，仅根据用户的决定执行操作。
  • unknown
    状态不代表任务完成；先读取面板内容。只有当
    .fleet/<id>.result.md
    存在时，任务才算完成；仅靠Agent状态不足以判定任务完成。
  • 收到超时事件（
    working
    状态）时，读取一次面板内容。如果fleet-worker仍在明显工作，仅重新启用一次监视器并使用相同超时时间；否则视为阻塞并告知用户。未经用户输入，不得第三次重新启用监视器。

5. Review and deliver

5. 审核与交付

On a fleet-worker's done:
  1. Read 
    .fleet/<id>.result.md
    , then review the actual diff against the task's recorded base: 
    git -C <worktree> diff <base>...fleet/<id>
    .
  2. Checklist in order, first failure is a defect: (a) diff does what the brief asked, nothing more; (b) no files outside stated scope; (c) tests/lints named in the brief ran and pass (outcome summary in the result file; verbatim only for failures); (d) no obvious correctness, security, or data-loss issue. Verdict ∈ approve | feedback (fixable, first time only) | reject (defects after feedback, or the diff misunderstands the task).
  3. feedback: send one concrete fix list (feedback template), re-arm the watcher, re-review once; second verdict can only be approve or reject.
  4. approve/reject: present task, diff summary, verdict, and (if reject) recommended next step. The user approves every merge; never merge unprompted.
  5. On approval: in the primary checkout, verify 
    git branch --show-current
    prints the task's 
    <base>
    (if not, stop and ask the user), then 
    git merge --no-ff fleet/<id>
    . On conflict: 
    git merge --abort
    immediately (never resolve conflicts yourself), then prompt the same fleet-worker in its existing worktree to 
    git rebase <base>
    (no new task, worktree, or branch) or escalate to the user. No further merges until the primary checkout is clean.
Scouts: verify the report answers the brief, then relay your synthesis, not the raw file. That relay marks the scout 
done
; tear it down immediately (tab + result file; no worktree or branch exists).
当fleet-worker完成任务时：
  1. 读取
    .fleet/<id>.result.md
    ，然后审核任务记录的base分支与实际代码的差异：
    git -C <worktree> diff <base>...fleet/<id>
    。
  2. 按顺序检查清单，首次失败即视为缺陷：(a) 代码差异符合简报要求，无额外操作；(b) 未修改超出指定范围的文件；(c) 简报中指定的测试/代码检查已运行并通过（结果文件中有总结；仅在失败时提供原文）；(d) 无明显的正确性、安全性或数据丢失问题。审核结论可选值：approve（批准）| feedback（反馈，仅首次允许修复）| reject（拒绝，反馈后仍有缺陷或代码差异误解任务要求）。
  3. feedback（反馈）：发送一份具体的修复清单（使用反馈模板），重新启用监视器，再次审核；第二次结论只能是批准或拒绝。
  4. approve/reject（批准/拒绝）：展示任务、差异总结、审核结论，以及（如果拒绝）建议的下一步操作。所有合并操作都需用户批准；永远不要未经提示自行合并。
  5. 获得批准后：在主检出目录中，验证
    git branch --show-current
    输出的是任务的
    <base>
    分支（如果不是，停止操作并询问用户），然后执行
    git merge --no-ff fleet/<id>
    。如果出现冲突：立即执行
    git merge --abort
    （永远不要自行解决冲突），然后提示同一fleet-worker在其现有工作树中执行
    git rebase <base>
    （无需创建新任务、工作树或分支），或升级给用户处理。在主检出目录清理完成前，不得进行其他合并操作。
Scout任务：验证报告是否回答了简报中的问题，然后转告你的综合总结，而非原始文件。转告总结后将Scout任务标记为
done
；立即清理（关闭标签页+删除结果文件；无工作树或分支需要处理）。

6. Teardown

6. 清理任务

After merge or explicit abandonment (confirm with the user if the branch has unmerged commits), set the terminal status, then:
bash
"<skill-dir>/scripts/fleet-task.sh" teardown <id>   # --force-branch only for a user-confirmed abandonment
It closes the tab, removes the worktree and branch (refusing unmerged commits without 
--force-branch
), and deletes the brief/result files. Never tear down unlanded work without explicit user approval.
合并完成或用户明确放弃任务（如果分支有未合并提交，需与用户确认）后，设置终止状态，然后执行：
bash
"<skill-dir>/scripts/fleet-task.sh" teardown <id>   # --force-branch仅用于用户确认放弃的任务
该命令会关闭标签页，删除工作树和分支（若无
--force-branch
，会拒绝删除包含未合并提交的分支），并删除简报/结果文件。未经用户明确批准，永远不要清理未落地的工作成果。

Context hygiene

上下文卫生

  • Fleet-workers get self-contained briefs, never conversation history or prior task results; chained tasks reference the merged code, not transcripts.
  • You consume result files and targeted diffs; read pane output only on 
    blocked
    /
    unknown
    /timeout/steer, capped at 120 lines. Never scroll-scrape a pane in place of the result file.
  • Relay synthesis to the user in your own words with file:line references; never paste raw reports or full diffs.
  • Fleet-workers的任务简报是自包含的，永远不要包含对话历史或之前的任务结果；链式任务引用合并后的代码，而非对话记录。
  • 你需要读取结果文件和针对性的代码差异；仅在
    blocked
    /
    unknown
    /超时/引导时读取面板输出，最多读取120行。永远不要通过滚动面板来替代读取结果文件。
  • 用你自己的语言并附带文件:行号引用，将综合结果转告用户；永远不要粘贴原始报告或完整代码差异。

State files

状态文件

FilePurpose
.fleet/active
Enforcement flag; presence = fleet mode on
.fleet/config.md
Fleet-worker harness/model/effort (asked once, kept until the user changes it)
.fleet/tasks.md
Backlog + status table (source of truth across restarts)
.fleet/<id>.result.md
Fleet-worker's completion report (deleted at teardown)
文件用途
.fleet/active
执行标志；存在该文件表示fleet模式已启用
.fleet/config.md
Fleet-worker的工具集/模型/工作力度配置（首次激活时询问用户，保留至用户修改）
.fleet/tasks.md
任务待办列表+状态表（跨重启会话的事实数据源）
.fleet/<id>.result.md
Fleet-worker的完成报告（清理任务时删除）