parallel-ops

Parallel Ops 是一个路由（router）技能，不直接承担具体执行工作，而是用于在并行或循环型智能体工作中，判断哪一项技能应当负责当前任务。资料指出，围绕这个空间的六个技能单靠名称难以区分，因此该路由器负责“跨技能族发现”：阅读其决策表，跳转到需要的那个技能，然后停止继续阅读。

用途与定位

当用户面对“并行或循环的智能体工作”但不确定归属时，Parallel Ops 提供决策表进行分流。它覆盖的范围按资料描述包括：并行代理、扇出工作、委派给 worker、过夜运行、定时循环、落地分支等。

决策表要点

资料给出的决策逻辑如下：

若希望并行子任务由当前会话自身的提供方和模型层级在进程内运行：使用 native Workflow 工具 / Agent 子代理（isolation: worktree），而不是某个 fleet 技能，因为不需要专门技能。
若由比当前会话更便宜的“大脑”执行工作（如 GLM、Haiku，或 Opus 下的 Sonnet）——无论是单个子任务还是整个扇出——且所有 worker 使用同一种大脑类型：使用 fleet-worker。资料明确说明，当每个 worker 运行相同大脑时，fleetflow 属于过度配置。
若在一次运行中针对不同工作类别使用不同“大脑”，或在 verify 时实现跨提供方分歧（例如 Codex 或 Grok 反驳 GLM）：使用 fleetflow。资料说明它位于自有仓库 0xDarkMatter/fleetflow，挂载在 ~/.claude/skills/fleetflow；fleet-worker 每次运行只运行一种大脑类型（可以是任意提供方，但不能混合）；fleetflow 也是 Grok（xAI）worker 的归属地——它使用自有二进制，而不是 claude -p 大脑。
若工作按计划跨会话重复（cron、routine、无人值守的 tick）：使用 loop-ops。资料说明 iterate 是一个连续会话，而不是调度。
若在一次连续会话中（即使是很长的过夜会话）驱动一个机械指标达到目标：使用 iterate。资料说明 loop-ops 是会话周边的调度器，而不是会话本身。
若需要落地/合并并行工作产生的分支：使用 fleet-ops。资料称其为上述所有产生分支路线的终点（进程内子代理和提示词编写不产生分支）。
若在一波工作之后进行清理：包括哪些已落地、竞争通道、过期 worktree 与分支、归档已完成的会话：使用 fleet-ops fleet sweep。资料说明仅 fleet prune 只能移除可证明已完成的树，而 sweep 会把其余部分转化为后续行动；fleetflow 自身的 .fleetflow/ 运行仍由其 ff-sweep 处理。
若编写静态专家代理提示词文件（不是运行时 worker）：使用 spawn。资料注明列出它只是为了捕捉与“spawn workers”的名称冲突。

两个经典重叠的判定规则

资料给出两条决胜规则：

“许多文件、便宜模型”属于大脑经济学，而不是数量问题：更便宜的大脑 → fleet-worker；自身大脑 → native。
“过夜运行直到 X”属于会话形态，而不是时长问题：一次连续运行 → iterate；跨会话的定时重入 → loop-ops。

易混淆的两个维度

资料指出两个会让冷启动代理困惑的维度：

Spawn 与 land。fleet-worker 和 fleetflow 会派生 worker 并产生分支；fleet-ops 通过测试门控队列落地这些分支。每个产生分支的路径最终都归到 fleet-ops，无论它是如何被派生的——代理团队、后台代理、claude -p worker 或人工。
内层循环与外层循环。iterate 是内层循环：一个会话、一个指标、以 git 作为记忆、运行到停止条件。loop-ops 是外层循环：调度器与风险层级纪律，决定何时以及是否在无人值守下触发一次运行（内层循环或其他）。

组合链

资料给出的组合链为：

iterate（内层循环）→ loop-ops（外层循环 / 调度器） ↓ fleet-worker / fleetflow（派生 worker） ↓ fleet-ops（落地分支）

资料同时强调：并非每个任务都会使用整条链——大多数任务恰好只使用其中一环。应先阅读决策表；只有当任务确实跨越 spawn + land 或内层 + 外层时，才进行组合。

技能介绍