breezing

Breezing — Team Execution Mode

Backward-compatible alias: harness-work runs in team execution mode.

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	Targets all incomplete tasks	-
N or N-M	Specify task number/range	-
--codex	Delegate implementation to Codex CLI	false
--parallel N	Implementer parallelism count	auto
--no-commit	Suppress automatic commits	false
--no-discuss	Skip planning discussion	false
--auto-mode	Explicitly states Auto Mode rollout. Consider adopting only if the parent session's permission mode is compatible	false

Execution

This skill harness-work delegates to. Execute harness-work with the following settings:

1. Pass arguments as-is harness-work to.
2. Force team execution mode — Three-way separation of Lead → Worker spawn → Reviewer spawn
3. Lead focuses solely on delegation — Does not write code directly
4. Auto Mode is treated as opt-in — --auto-mode is accepted as a flag for rollout in a compatible parent session

harness-work Differences from

Features	harness-work	breezing (this skill)
Parallelization method	Automatic splitting according to required count	Lead/Worker/Reviewer role separation
Lead's role	Coordination + implementation	delegate (coordination only)
Review	Lead self-review	Independent Reviewer
Default scope	Next task	All

Team Composition

Role	Agent Type	Mode	Responsibilities
Lead	(self)	-	Coordination, direction, task distribution
Worker ×N	claude-code-harness:worker	bypassPermissions(current) / Auto Mode (follow-up)*	Implementation
Reviewer	claude-code-harness:reviewer	bypassPermissions(current) / Auto Mode (follow-up)*	Independent review

*If the parent session or frontmatter is bypassPermissions , that takes precedence. Since distribution templates still currently use bypassPermissions , Auto Mode is a follow-up rollout target and is not the default behavior.

Codex Mode (--codex)

Mode that delegates all implementation to Codex CLI:

# プロンプトは stdin パイプで渡す（ARG_MAX 対策）
CODEX_PROMPT=$(mktemp /tmp/codex-prompt-XXXXXX.md)
# タスク内容を書き出し
cat "$CODEX_PROMPT" | ${TIMEOUT:+$TIMEOUT 120} codex exec - --sandbox workspace-write --full-auto 2>>/tmp/harness-codex-$$.log
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 (progress notifications during Phase B)

The Lead outputs progress in the following format each time a Worker completes a task:

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

Output example:

📊 Progress: Task 1/5 完了 — "harness-work に失敗再チケット化を追加"
📊 Progress: Task 2/5 完了 — "harness-sync に --snapshot を追加"
📊 Progress: Task 3/5 完了 — "breezing にプログレスフィードを追加"

Design intent: breezing often becomes a long-running execution. Make it so that when the user glances at the terminal, they can see at a glance "how far things have progressed." Since the task-completed.sh hook outputs equivalent information via systemMessage, it complements the Lead's output.

Review Policy (unified across all modes)

Even in Breezing mode, review follows Codex exec preferred → internal Reviewer fallback of the unified policy. For details, see harness-work refer to the "Review Loop" section.

• Worker implements and commits in the worktree → returns the result to Lead
• Lead reviews with Codex exec (120s timeout, fallback: Reviewer agent)
• REQUEST_CHANGES → Lead sends correction instructions to Worker via SendMessage, Worker amends (up to 3 times)
• APPROVE → Lead が main に cherry-pick → Plans.md を cc:完了 [{hash}] update to

Completion report (Phase C — generated by Lead)

After all tasks are complete,Lead generates the rich completion report using the following steps:

1. git log --oneline {base_ref}..HEAD collect all cherry-pick commits with
2. git diff --stat {base_ref}..HEAD get the overall change size with
3. Plans.md の cc:TODO / cc:WIP extract remaining tasks
4. harness-work output according to the Breezing template in the "Completion Report Format" of

The generator is Lead. Not a Worker or a hook. Lead generates it in Phase C by reading git + Plans.md.

Phase 0: Planning Discussion (structured 3-question check)

Before executing all tasks, verify the soundness of the plan with the following 3 questions. --no-discuss When specified, skip all.

Q1. Scope confirmation:

"{{N}} tasks will be executed. Is the scope appropriate?"

If there are too many, propose narrowing down by priority (Required > Recommended > Optional).

Q2. Dependency confirmation(only when Plans.md has a Depends column):

"Task {{X}} depends on {{Y}}. Is the execution order correct?"

Read the Depends column and display the dependency chain. If there is a circular dependency, error.

Q3. Risk flags（[needs-spike] (only when there are tasks):

"Task {{Z}} is [needs-spike]. Should we spike it first?"

When there are tasks with incomplete spike [needs-spike] confirm whether to run the spike first.

If all 3 questions are fine, proceed to Phase A (designed to complete in 30 seconds total).

Task assignment based on the dependency graph

If Plans.md has a Depends column (v2 format), execute tasks according to the dependency graph:

1. Depends が - tasks ofexecute first. If there are multiple independent tasks, parallel spawn is possible
2. After each Worker completes, Lead reviews → cherry-picks (see harness-work Phase B)
3. Once a dependency task has been cherry-picked to main, execute the tasks that depended on it next
4. Repeat until all tasks are complete

Note: For each task, "Worker completes → review → cherry-pick" is processed sequentially. Only the Worker spawn part of independent tasks (whose Depends is -) can be parallelized.

Codex Native Orchestration

For Codex, use native subagents. The representative control surface is spawn_agent, wait, send_input, resume_agent, close_agent。

Claude Code vs Codex communication API（SSOT: team-composition.md API mapping table):

• Claude Code: SendMessage(to: agentId, message: "...") send correction instructions to Worker with
• Codex: resume_agent(agent_id) resume the Worker with → send_input(agent_id, "...") send instructions with

The harness-work pseudocode is written in Claude Code syntax. In the Codex environment, read it as described above.

Related Skills

• harness-work — from a single task to team execution (main body)
• harness-sync — progress synchronization
• harness-review — code review (automatically launched within breezing)