breezing

Breezing — Team Execution Mode

向后兼容别名：本技能会以团队执行模式运行 harness-work。

Quick Reference

breezing                        # 先确认范围，再执行
breezing all                    # 跑完 Plans.md 里的全部任务
breezing 3-6                    # 跑完任务 3 到 6
breezing --codex all            # 通过 Codex CLI 跑完全部任务
breezing --parallel 2 all       # 用 2 并行跑完全部任务
breezing --no-discuss all       # 跳过计划讨论，直接全量执行
breezing --auto-mode all        # 在兼容的父会话里尝试 Auto Mode rollout

Options

Option	Description	Default
all	作用于全部未完成任务	-
N or N-M	指定任务编号 / 范围	-
--codex	委托 Codex CLI 实现	false
--parallel N	Implementer 并行数	auto
--no-commit	禁止自动提交	false
--no-discuss	跳过计划讨论	false
--auto-mode	显式启用 Auto Mode rollout。仅在父会话 permission mode 兼容时考虑采用	false

Execution

本技能会委托给 harness-work。 请按以下设置执行 harness-work：

1. 把参数原样传给 harness-work
2. 强制使用团队执行模式 —— Lead → Worker spawn → Reviewer spawn 的三方分离
3. Lead 只负责委派与协调 —— 不直接写代码
4. Auto Mode 仅作为 opt-in —— --auto-mode 只作为兼容父会话中的 rollout 标志

与 harness-work 的区别

特点	harness-work	breezing（本技能）
并行方式	按需要自动拆分	Lead / Worker / Reviewer 角色分离
Lead 的职责	协调 + 实现	delegate（专注协调）
评审	Lead 自评	独立 Reviewer
默认范围	下一个任务	全部

Team Composition

Role	Agent Type	Mode	职责
Lead	(self)	-	协调、指挥、任务分配
Worker ×N	claude-code-harness:worker	bypassPermissions（当前） / Auto Mode（后续）*	实现
Reviewer	claude-code-harness:reviewer	bypassPermissions（当前） / Auto Mode（后续）*	独立评审

*如果父会话或 frontmatter 已经指定 bypassPermissions，则以其为准。当前分发模板仍然使用 bypassPermissions，因此 Auto Mode 仍是后续 rollout 目标，不是默认行为。

Codex Mode (--codex)

通过官方插件 codex-plugin-cc 把全部实现工作委托给 Codex CLI 的模式：

# 委托任务（允许写入）
bash scripts/codex-companion.sh task --write "任务内容"

# 通过 stdin（适合较大的 prompt）
CODEX_PROMPT=$(mktemp /tmp/codex-prompt-XXXXXX.md)
# 写入任务内容
cat "$CODEX_PROMPT" | bash scripts/codex-companion.sh task --write
rm -f "$CODEX_PROMPT"

Flow Summary

breezing [scope] [--codex] [--parallel N] [--no-discuss] [--auto-mode]
    │
    ↓ Load harness-work with team mode
    │
Phase 0: Planning Discussion（用 `--no-discuss` 可跳过）
Phase A: Pre-delegate（团队初始化）
Phase B: Delegate（Worker 实现 + Reviewer 评审）
Phase C: Post-delegate（集成验证 + 更新 Plans.md + commit）

Progress Feed（Phase B 中的进度通知）

Lead 会在每个 Worker 完成任务时，以如下格式输出进度：

📊 Progress: Task {completed}/{total} 完成 — "{task_subject}"

出力例:

📊 Progress: Task 1/5 完成 — "为 harness-work 增加失败补票"
📊 Progress: Task 2/5 完成 — "为 harness-sync 增加 --snapshot"
📊 Progress: Task 3/5 完成 — "为 breezing 增加进度播报"

设计意图：breezing 经常是长时间运行的。 我们希望用户扫一眼终端时，就能立刻知道“做到哪了”。 由于 task-completed.sh hook 也会通过 systemMessage 输出同类信息，因此两者会相互补足。

Review Policy（所有模式统一）

即使在 Breezing 模式下，评审仍然遵循 优先用 Codex exec → 回退到内部 Reviewer 的统一策略。 详见 harness-work 中的“评审循环”章节。

• Worker 在 worktree 中实现并提交 → 把结果返回给 Lead
• Lead 用 Codex exec 执行评审（120s 超时，回退为 Reviewer agent）
• 若为 REQUEST_CHANGES → Lead 通过 SendMessage 指示 Worker 修复，Worker 执行 amend（最多 3 次）
• 若为 APPROVE → Lead cherry-pick 到 main，并把 Plans.md 更新为 cc:完了 [{hash}]

完成汇报（Phase C — 由 Lead 生成）

所有任务完成后，Lead 按以下步骤生成完整的完成汇报：

1. 用 git log --oneline {base_ref}..HEAD 收集所有 cherry-pick commit
2. 用 git diff --stat {base_ref}..HEAD 获取整体变更规模
3. 提取 Plans.md 中剩余的 cc:TODO / cc:WIP 任务
4. 按 harness-work 中“完成汇报格式”的 Breezing 模板输出

生成者是 Lead。不是 Worker，也不是 hook。由 Lead 在 Phase C 中读取 git + Plans.md 后生成。

Phase 0: Planning Discussion（结构化 3 问检查）

在执行全部任务之前，通过以下 3 个问题确认计划是否健康。 如果指定 --no-discuss，则全部跳过。

Q1. 范围确认:

“将执行 {{N}} 个任务。当前范围合适吗？”

如果任务过多，就按优先级（Required > Recommended > Optional）建议缩小范围。

Q2. 依赖关系确认（仅当 Plans.md 有 Depends 列时）:

“任务 {{X}} 依赖 {{Y}}。执行顺序正确吗？”

读取 Depends 列并展示依赖链；如果存在循环依赖，则报错。

Q3. 风险标记（仅当存在 [needs-spike] 任务时）:

“任务 {{Z}} 带有 [needs-spike]。要先做 spike 吗？”

如果存在尚未完成 spike 的 [needs-spike] 任务，就先确认是否要优先执行 spike。

如果这 3 个问题都没有问题，就进入 Phase A（设计目标是在 30 秒内完成）。

基于依赖图的任务分配

如果 Plans.md 有 Depends 列（v2 格式），就按依赖图执行任务：

1. 先执行 Depends 为 - 的任务。如果有多个独立任务，就可以并行 spawn
2. 每个 Worker 完成后，由 Lead 执行 review → cherry-pick（参见 harness-work Phase B）
3. 当依赖源任务被 cherry-pick 到 main 后，再执行依赖它的任务
4. 重复以上步骤，直到所有任务完成

注意: 每个任务的“Worker 完成 → review → cherry-pick”仍是串行流程。 能并行的只有独立任务（Depends 为 -）的 Worker spawn 部分。

Codex Native Orchestration

在 Codex 中使用原生 subagent。 常用控制面包括 spawn_agent、wait、send_input、resume_agent、close_agent。

Claude Code vs Codex 的通信 API（SSOT: team-composition.md 里的 API 映射表）:

• Claude Code: 用 SendMessage(to: agentId, message: "...") 给 Worker 下发修正指令
• Codex: 先用 resume_agent(agent_id) 恢复 Worker，再用 send_input(agent_id, "...") 发送指令

harness-work 中的伪代码是按 Claude Code 语法写的；在 Codex 环境中请按上面的方式理解。

Related Skills

• harness-work — 从单任务到团队执行的主体技能
• harness-sync — 進捗同期
• harness-review — 代码评审（在 breezing 中自动启动）