breezing

Breezing — Team Execution Mode

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

Default Pipeline (completes plan → work → review → report in a single command)

/breezing completes "plan → implement → review until OK → report" in a single invocation. The operator does not need to instruct /harness-plan や /harness-review individually (operator ruling 2026-07-24).

1. Plan gate: If the task corresponding to the request scope is not in Plans.md, or is insufficient, first run harness-plan to generate the task, then continue. If a plan already exists, proceed directly to Phase 0. When generating a plan, the scope follows harness-plan's "Default scope: all work that can be advanced now".
2. Work: The existing Phase 0 → A → B (including per-task review).
3. Integrated Review Gate (Phase D, ON by default): After Phase B completes,before Phase C finalization (completion report, run completion declaration), run harness-review on the diff for the entire run.
   • review target: for normal runs, {base_ref}..HEAD。--no-commit runs can have an empty commit range, sotarget the working tree (uncommitted changes + untracked files)
   • run a fresh-context independent reviewer subagent (which does not share conversational state with the implementation Worker) andbash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" review --base "${base_ref}" 's second opinion in parallel
   • If either is equivalent to REQUEST_CHANGES → fix → re-review.Iterate until APPROVE is issued(up to 3 times). If it does not converge, revert the marker of the affected task to cc:WIP and stop with human escalation to report the findings and fix status
   • primary verdict（APPROVE | REQUEST_CHANGES) is issued by the brain (claude host). Role-scoped constraints are maintained
4. Finalize + Report（Phase C）: After obtaining the gate's APPROVE, finalize the Plans.md update, commit, and completion report. Do not report a run as "complete" while the gate has not been passed. The final report is given in the easy convention (if the host session has the easy skill, invoke it and follow that convention. If not, harness-work Completion Report template).

--reviewer-only / --no-commit and other existing flags work as per-run overrides that run only the corresponding stage of this pipeline. If you want to omit Phase D in a low-risk fast run, pass --no-review-gate (Phase B's per-task review is not omitted. Only the integrated review of the entire run diff is omitted).

Work Mode Lifecycle (bin/harness work-mode)

The R04/R05 confirmation skip is set by either the ctx.WorkMode は、HARNESS_WORK_MODE / ULTRAWORK_MODE env (cannot be set from a skill) work_states SQLite row.bin/harness work-mode <on|off|status> Is the only entry point that writes the latter (harness-work 's "Work Mode Lifecycle" section is authoritative).

• Before entering the Plan gate (at run start), the Lead runs bin/harness work-mode on . --codex In run bin/harness work-mode on --codex is used (R07 = the Lead's direct Write/Edit prohibition also applies at the same time)
• At run end, the Leadon all paths—success, failure, and interruption—で bin/harness work-mode off runs (the same discipline regardless of whether the backend is claude / codex / cursor . Same form as the cursor fast path's session declare / --clear "always call as a pair at run boundaries")
• Only once per run. Do not turn it on/off per task
• If the session ID cannot be resolved, exit non-zero + the reason is output to stderr (do not succeed silently)

Breezing run state (breezing-active.json) — guardrail の file producer

The Lead writes .claude/state/breezing-active.json at run start. The guardrail reads this file as the file producer for R07 (codex mode) and R08 (reviewer subagent determination scope) (go/internal/guardrail/breezing_state.go）:

{"impl_mode": "codex", "started_at": "<ISO8601>"}

• impl_mode は --codex if "codex", otherwise "claude" / "cursor"
• delete this file at run end (all paths). If left behind, the R07/R08 scope determination remains active even in the next normal session
• For reviewer teammate (worktree spawn), env HARNESS_BREEZING_ROLE=reviewer to the spawn command's environment. Within the session, the reviewer subagent is auto-determined by the agent_type that CC assigns, so no additional work is needed

Narration Rules (UX Contract)

The enemy is verbosity , not progress reporting.At startup, briefly state the execution plan and then begin execution. Easy-to-read progress reports are welcome. Only verbose repetition and content-free preambles are forbidden.

What must always be output at startup (banner + plan, 5 lines or fewer total)

In the first response, indicate what will be done and in what order before entering tool execution:

🚀 cursor / composer-2.5-fast / feat/hah-11-golden-rule-lint / Reviewer
これから:
1. backend/model を resolve
2. composer に advisory findings を委譲 (read-only)
3. brain 一次レビューで verdict を確定 → 3-5 行要約 → Plans.md 更新

banner 1 line (🚀 <backend> / <model> / <branch> / <task>) + plan 2-4 lines. Output within 1 second, then immediately go to Step 1.

Backend default and per-run flat determination (2026-07-24 operator ruling)

The default backend is claude（Native subagent）. The resolver's unset fallback is also claude , and this is not a trap but the intended default. ⚠️ Output the warning in 1 line immediately after the banner only when the resolver emits the stderr warning for invalid value fallback (do not output it when it is normally resolved to claude . Do not repeat it within the same run).

The Lead may choose the backend flatly per run based on the nature and volume of the work. When choosing, use an explicit override to the resolver (--backend <v> / --codex / --cursor). Reading env directly is still forbidden:

Nature of work	Recommended backend	Reason
Normal implementation, fixes, tests (default)	claude (native)	The Worker contract (worker-report.v1 / 5 self_review items) all take effect
Large-scale, highly independent batch implementation, avoiding Claude-side rate limits	codex	The deep tier can be delegated at xhigh (model is resolved by model-routing.sh )
Mass UI generation, lean high-speed delegation	cursor	lean path (worktree isolation + Lead diff review)

Do not write model IDs in the skill.bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host <backend> --role worker is the source of truth.

Progress reports may be output (within an easy-to-read range)

• The start and completion of each step as a 1-line status (✓ backend=cursor / model=composer-2.5-fast)
• Intermediate results needed for decisions (key points of pre-check, resolved model, detected branch, etc.)
• The reason for taking this branch in 1 line (e.g., "Delegate only Reviewer: Worker already completed in a separate line")

Forbidden (= verbosity)

• Restating the same fact twice in different words: Do not re-explain something already stated later
• Empty preamble: A line that only says "I will check the usage", etc., a self-evident declaration by tool call
• Recap of the process in 3 or more lines: A long preamble that drags out the conclusion. If the process is needed, compress it to 1 line
• ★ Insight block during the startup sequence: Insight only once in the final report

Example (violation → normal):

× 「composer 2.5 使うモード」= cursor backend で Composer に委託、ですね（解釈の言い換え、中身のない前置き）
○ 🚀 cursor / composer-2.5-fast / feat/hah-11-golden-rule-lint / Reviewer
  これから: backend resolve → composer に advisory findings 委譲 (read-only) → brain 一次レビューで verdict 確定

Quick Reference

/breezing                       # スコープを聞く（claude backend）
/breezing all                   # 全タスク完走（claude backend）
/breezing 3-6                   # タスク3〜6を完走
/breezing --codex all           # Codex CLI で全タスク委託
/breezing --cursor              # cursor backend lean path (--no-discuss all 既定)
/breezing --cursor --reviewer-only  # Reviewer のみ cursor に委譲（Worker は別系統で既完了）
/breezing composer 2.5 all      # 自然言語 trigger: cursor backend として扱う
/breezing --parallel 2 all      # 2並列で全タスク完走
/breezing --no-discuss all      # 計画議論スキップで全タスク完走
/breezing --auto-mode all       # 互換な親セッションで Auto Mode rollout を試す

Brief Composer v0

Free-text input that does not match any argument-hint bash scripts/breezing-brief.sh classify "<args>" で structured / free-text is determined. free-text is decomposed into 3–7 subtasks and presented to the user as brief-card.v1 cards, then confirmed withbreezing-brief.sh confirm <yes|no> <card.json> . For details of the decomposition logic, schema, andDISPATCH contract, see references/lean-path-detail.md .

Options

Option	Description	Default
all	Target all incomplete tasks	-
N or N-M	Task number/range specification	-
--codex	Implementation delegated to Codex CLI	false
--cursor	cursor backend lean path (explicit per-run override. Equivalent to when resolver output is cursor ). Skips Worker mediation / self_review / sprint-contract 3-stage chain / Phase 0, and starts startup → delegation within 3 seconds	false
--reviewer-only	Delegate only Reviewer to an independent lineage (assuming Worker implementation is already complete).--cursor Used together with this to offload to Composer	false
--parallel N	Implementer parallelism count	auto
--no-commit	Suppress automatic commit	false
--no-discuss	Skip plan discussion	--cursor defaults to true with
--no-review-gate	Skip Phase D (Integrated Review Gate). Keep Phase B per-task review	false
--auto-mode	Explicitly specify Harness-side Auto Mode rollout. Distinct from --enable-auto-mode , which became unnecessary in CC 2.1.111	false

--parallel N and the actual cap on the CC side (133.9, confirmed with a primary source)

--parallel N is the desired value on the Harness side, and CC decides how many actually run concurrently. CC limits concurrently running subagents to 20 by default（CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, 2.1.217). Even if you pass N exceeding 20, the excess simply enters the queue and does not error. In other words, --parallel 40 becomes "20 parallel + waiting" rather than "40 parallel".

Nested spawn defaults to depth 3（CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH, relaxed from 1 → 3 in 2.1.219). Lead (depth 0) → Worker / Reviewer (1) → advisor called by Worker, etc. (2) fits within this. Mode 1's Producer → Sub-Lead → Composer is also within 3 levels. When designing a hierarchy exceeding this, unless raised via env, assume thatspawn is silently rejected.

In both cases, the Harness side does not explicitly set env (it follows CC's defaults). If you want to change it, pass it via the run's env.

Natural Language Backend Triggers

composer / コンポーザー / Composer で / composer 2.5 / composer モード is officially treated as a trigger for cursor backend . This is an intent equivalent to --cursor , and the Lead confirms the backend via resolve-impl-backend.sh . When resolving, pass --backend cursor as an explicit override, giving it priority over env / project / user file / default.

Input example	Interpretation	execution path
composer 2.5 で	cursor backend	Lead → cursor-companion.sh task --write --workspace <wt>
コンポーザーで全部	cursor backend	Lead → cursor-companion.sh task --write --workspace <wt>
composer モード	cursor backend	Lead → cursor-companion.sh task --write --workspace <wt>

composer is not an additional agent spawned inside the Claude Worker. Non- claude Following the backend topology, the Lead directly calls cursor-companion.sh without going through a Worker agent.

CC 2.1.111 note: In Opus 4.7, literal /effort xhigh can be used. built-in /ultrareview is used additionally only when explicitly requested, and does not replace the default review.

Long session recommended (CC 2.1.108+): If the session length is expected to exceed 30 minutes, after resolving the plugin bundle root, bash "${HARNESS_PLUGIN_ROOT}/scripts/enable-1h-cache.sh" run to opt in to the 1-hour prompt cache. This script appends env.local に export ENABLE_PROMPT_CACHING_1H=1 (idempotent). With the default 5-minute TTL cache, cache misses accumulate in breezing sessions exceeding 1 hour, and input token costs can increase up to 12x, so explicitly opt in for long team runs. Codex CLI child processes (scripts/codex-companion.sh task --write etc.) normally inherit env and ENABLE_PROMPT_CACHING_1H read, but ifCLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 is enabled, a shell wrapper that explicitly maintains the export is required. For details, see docs/long-running-harness.md .

Execution

This skill delegates to harness-work . With the following settings, harness-work run:

1. Pass arguments as-is to harness-work pass arguments as-is to harness-work
2. Force team execution mode — three-way separation of Lead → Worker spawn → Reviewer spawn
3. Lead focuses 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 compatible parent sessions
5. Advisor only when needed — Worker が advisor-request.v1 The Lead calls the advisor only when

Handling of Plan-time pre-confirmation

At the start of a Breezing run, the Lead executes the same preapproval preflight as harness-work .

• At the start of each task, the task worktree's .claude/state/active-task.json に {"phase":"<phase>","task":"<task>"} is written atomically. At task end, it is deleted on all paths: success, failure, and stop.
• .claude/state/plan-preapprovals.json If there is scripts/plan-preapproval.sh validate , validate v2 with
• Only the decision: approved items of the task to be executed are treated as declared and passed to the Worker briefing.
• secret-read は bash "${HARNESS_PLUGIN_ROOT}/scripts/plan-preapproval.sh" apply-secret-allow "$PROJECT_ROOT" で project config .claude-code-harness.config.json の runtimefloor.secretAllow is reflected per-run in , and connected with the 108.2 project config floor.
• R12 の ask suppresses only v2 approvals that match the execution command withexternal-send , within the same phase/task, within the deadline, and within the usage count. Explicit deny and runtime floor are not suppressed.
• Do not stop midway for declared items, and reduce declared-item-induced AskUserQuestion during work to zero. Confirmation is only once at plan approval.
• Unplanned secret-read / external transmission / destructive operations that are not in the record are stopped by the runtime floor / ask as before. Do not narrow the safety net.

harness-work Difference from

Features	harness-work	breezing (this skill)
Parallel means	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
Advisor	claude-code-harness:advisor	Read-only	Policy advice (PLAN / CORRECTION / STOP)
Reviewer	claude-code-harness:reviewer	bypassPermissions(current) / Auto Mode (follow-up)*	Independent review

*If the parent session or frontmatter is bypassPermissions , that takes precedence. Because the distribution template still uses bypassPermissions , Auto Mode is subject to follow-up rollout and is not the default behavior.

Mode 1 — Sub-Lead hierarchy and review→iterate (opt-in)

In the Go orchestrator path (harness work --team), in addition to Breezing's Lead/Worker/Reviewer three-way separation, Producer → Sub-Lead → Composer 's Mode 1 hierarchy can be layered on as opt-in. The Lead (Producer = fixed to Claude Code) delegates lanes to Sub-Leads, and Sub-Leads use orchestrator-spawned headless CLI (same backend as the Lead) to build mini-plans, while implementation is aggregated per lane by Composer 2.5 (cursor backend) with companion-result.v1 .HARNESS_TEAM_HIERARCHY=sublead Enabled with (default OFF).

On the quality side, HARNESS_REVIEW_ITERATE=on can wrap worker output in a review→iterate loop. After fresh-context parallel advisory + cross-CLI review, brain-only verdict is passed through, and if the DoD is not met, a refinement task is re-submitted to the same worktree,iterating until OK(withHARNESS_REVIEW_ITERATE_MAX as the upper limit; non-convergence results in human escalation). For details of wiring and contracts, the sections "Mode 1 — Producer → Sub-Lead → Composer hierarchy" and "review→iterate loop" in harness-work are the authoritative source.

• If you grep the same symbol twice in the same session, switch to harness_ast_search.
• For a bugfix where homologous implementations appear across multiple modules, run harness_ast_search to find all implementations before editing.
• Only when changed files include .ts or .tsx, the DoD requires zero new harness_lsp_diagnostics errors; if the harness MCP is not connected or the changed file types are not eligible, treat diagnostics as not-configured and non-blocking.

Codex Mode (--codex)

Official plugin codex-plugin-cc A mode that delegates all implementation to Codex CLI via:

# タスク委託（書き込み可能）
bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write "タスク内容"

# stdin 経由（大きなプロンプト向け）
CODEX_PROMPT=$(mktemp /tmp/codex-prompt-XXXXXX.md)
# タスク内容を書き出し
cat "$CODEX_PROMPT" | bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write
rm -f "$CODEX_PROMPT"

Execution Backend (persistent)

Backend determination is always via the resolver。HARNESS_IMPL_BACKEND Do not read the env directly to determine the backend. Resolve precedence with env / --cursor per-run flag / project env.local / user file を bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh" and use its output as the backend (even if env is unset, it can be picked up from the project / user file). If you want to change the persistent default, bash "${HARNESS_PLUGIN_ROOT}/scripts/set-impl-backend.sh" <claude|codex|cursor> [--user] write to the project / user file with, and the resolver resolves it at run start (the current operator default is at user scope with claude). The review / advisor role remains fixed to brain. The authoritative source for backend selection (precedence, role-scope, self_review skip, cursor banner) is harness-work refer to "Execution Backend Selection".

The Cursor Backend Fast Path below is a separate axis that enables the lean path by using the per-run flag (--cursor) as an explicit override to the resolver, and should be read alongside this section.

Cursor Backend Fast Path (--cursor / lean mode)

bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh" output is cursor enabled when (--cursor is the highest precedence as an explicit override to the resolver). The Lead directly calls cursor-companion.sh without involving the Worker layer (Phase 85 SSOT,.claude/rules/cursor-cli-only.md Topology section).

The cursor backend omits Worker agent spawn / self_review 5-item gate / sprint-contract 3-stage chain / Phase 0 interactive / effort scoring, and starts the first task delegation with baseline 15-35s → target 3-7s The full table of savings breakdown is in references/lean-path-detail.md .

Default flow (cursor backend)

1. banner + execution plan (🚀 cursor / <model> / <branch> / <task> + the next 2-4 steps, within 5 lines total, within 1 second)
   • Only once for the entire run, if not yet executed, bin/harness work-mode on(enables skipping R04/R05 confirmation. For details, see the "Work Mode Lifecycle" section)
2. Parallel pre-check with 1 bash: git branch --show-current + cat VERSION + Plans.md tail + cursor-agent --version
3. 1 bash で resolve: bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh" + bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host cursor --role worker --field model
4. Immediate delegation: bash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task --write --workspace <wt> "<task>"
   • At delegation start, bin/harness session declare --task <task-id> declares the work in shared presence (making it reverse-lookupable by task number from other sessions)
5. The Lead diff-reviews the cursor output → cherry-pick → Plans.md cc:done [hash] update
   • After updating, bin/harness session declare --clear clears the presence task declaration
   • When the entire run ends (whether success, failure, or interruption), don't forget bin/harness work-mode off don't forget

Reviewer-only mode (--cursor --reviewer-only) — read = lean

Worker implementation is already complete (done via a separate line = claude / Codex), a lean path that has Composer produce an advisory pre-review. Since it is a read-only delegation, no worktree needed, no cherry-pick needed, no review needed to incorporate cursor output(because cursor does not produce a new diff). However, for the target diff, do not omit the brain primary review (primary verdict):

1. banner + plan: 🚀 cursor / composer-2.5-fast / review + "Next: delegate advisory findings to composer → finalize verdict with brain primary review"
2. bash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task "diff レビュー: <base_ref>..HEAD" — --write も --workspace also do not attach
   • companion は --write unspecified, default --mode ask (hard read-only stop) (cursor-companion.sh's workspace guard fires only when --write )
   • On the cursor side, file writing and command execution are disabled, no worktree isolation needed
3. The Lead interprets the cursor output (equivalent to REQUEST_CHANGES / APPROVE), anddual_review.cursor_verdict stores it as advisory in
4. The primary verdict is obtained from the brain reviewer. Cursor alone does not finalize APPROVE (consistent with the self-review scope contract in spec.md Execution Backend Contract = "the same context that generated the diff does not review its own output"). This lean path itself is a fresh-context advisory pre-review, and the delegated cursor session must not share conversation state with the implementation worker
5. brain first review: Lead uses cursor advisory findings as input to inspect the target diff themselves and issue a verdict (APPROVE | REQUEST_CHANGES). While the brain reviewer is unavailable (rate limit, etc.), do not finalize the verdict, and hand the task to the user for judgment while it remains cc:wip (do not make it cc:done based on cursor advisory alone)
6. After brain's APPROVE, Lead updates Plans.md cc:done [hash] Lead updates

What can be omitted in read mode: dedicated .git worktree / review of incorporating cursor output / cherry-pick / worker-report.v1 / 5 self_review items.Cannot be omitted: brain first review of the target diff (verdict finalization). Must be retained even in read mode: .cursorignore / egress allowlist (*.cursor.sh) / permissions.json (best-effort). For details, see .claude/rules/cursor-cli-only.md section "Read mode delegation (lean path)".

Purpose(advance consolidation during rate limit / distribute only the Reviewer to a separate system / fallback when Codex review auth fails; for details, see references/lean-path-detail.md）。

Cursor adapter support claim

Cursor は supported tier (H8 pin: live H4 2026-07-17 + H7 release-preflight fail-closed). No FS jail — containment is harness-side (docs/CURSOR_INTEGRATION.md）。--cursor the lean path itself does not promote the tier.

Bootstrap route: .cursor/AGENTS.md + .cursor-plugin/plugin.json。

Verification:

bash tests/test-cursor-adapter-candidate.sh
bash tests/test-support-claim-wording.sh

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 実装 + 必要時 Advisor + Reviewer レビュー）
Phase C: Post-delegate（統合検証 + Plans.md 更新 + commit）

Advisor Protocol

Workers do not add generic subagents. When in doubt, return only a consultation request in structured JSON, and the Lead calls the advisor.

1. Worker → advisor-request.v1
2. Lead → Advisor
3. Advisor → advisor-response.v1
4. Lead → returns advice to the same Worker and continues
5. Reviewer looks only at the final artifact

Consultation conditions align with loop / solo.

• Before the first execution of a high-risk task (needs-spike / security-sensitive / state-migration)
• After the same cause of failure occurs twice in a row
• Due to plateau, immediately before returning PIVOT_REQUIRED just before returning
• The same trigger_hash only once. Maximum of 3 consultations per task

Progress Feed (progress notification 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 tell 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.

Silence Policy (organizing notifications for long-running execution)

Codex 0.123.0 In the realtime handoff, the background agent receives transcript deltas and can explicitly stay silent when not needed. Breezing's progress feed aligns with this premise and limits notifications to "milestones of the work."

Things to report:

• task completion, blocked, validation failure, review REQUEST_CHANGES
• Advisor の PLAN / CORRECTION / STOP
• Reviewer の APPROVE / REQUEST_CHANGES
• advisor / reviewer drift、plateau、contract readiness failure
• A summary when the user explicitly requests status

Things that may remain silent:

• When only a transcript delta was received and the judgment or status has not changed
• When the fine-grained increments of tool stdout are sufficient if left in the log
• Heartbeat while waiting for parallel Workers

The basic frequency is "once per task completion." Rather than increasing heartbeats to create a sense of reassurance, separate responsibilities into status / log / drift detection. However, unanswered Advisor requests, unreceived Reviewer results, and warnings immediately before a plateau are not subject to silence.

Monitor Tool Usage Guide (CC 2.1.98+)

run_in_background: true long-running shell processes launched with (gh run watch, build --watch, etc.) are not polled but instead Monitor toolcaptures stdout as sequential notifications. Not needed for Agent (Worker/Reviewer) completion monitoring or short one-shot commands. For the usage table and typical patterns, see references/monitor-and-learning.md .

Review Policy (unified across all modes)

Even in Breezing mode, reviews follow the unified policy of Codex exec first → internal Reviewer fallback . For details, see the "Review Loop" section in harness-work .

• Worker implements and commits in the worktree → worker-report.v1 (5 self_review items) returned to Lead
• self_review gate (before Reviewer spawn): Lead が self_review[].verified と evidence is machine-verified. If even 1 item is verified:false or evidence:"" , the Reviewer is not spawned and the task is automatically sent back to the Worker (max 2 times within the same session, escalated on the 3rd)
• Lead reviews with Codex exec (120s timeout, fallback: Reviewer agent)
• REQUEST_CHANGES → Lead sends correction instructions to Worker via SendMessage, Worker amends (max MAX_REVIEWS times.MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3）
• APPROVE → Lead が main に cherry-pick → Plans.md を cc:完了 [{hash}] updated to

Completion report (Phase C — generated by Lead)

After all tasks are complete,Lead generates a 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 scale with
3. Plans.md の cc:TODO / cc:WIP extract remaining tasks
4. harness-work の Completion Report Output Contract と references/completion-report.md output according to the Breezing template in

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

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

Before executing all tasks, confirm the soundness of the plan with 3 questions: scope (Q1), dependencies (Q2, only when there is a Depends column), and risk flags (Q3, only when there is[needs-spike] ) (designed to take 30 seconds total). --no-discuss When specified, all are skipped. For the specific wording of the 3 questions and the decision logic, see references/lean-path-detail.md .

Universal Violations Injection (learning propagation between Workers within a session)

Within the same /breezing automatic injection of Reviewer's universal gotchas accumulated during startup into the beginning of the next Worker's briefing.Valid only within the same session(discarded when the session ends,session-memory not written to). Implementation (in-memory array + briefing injection code) is references/monitor-and-learning.md see.

Task assignment based on the dependency graph

If Plans.md has a Depends column (v2 format),Depends が - spawn the independent tasks in parallel first, and after each Worker completes, the Lead reviews and cherry-picks (see harness-work Phase B). Once the dependency source is merged into main, execute the tasks that depended on it next, and repeat until all tasks are complete. What is sequential is "Worker completion → review → cherry-pick", and what can be parallelized is only the Worker spawn portion for independent tasks. For details, see references/lean-path-detail.md .

Codex Native Orchestration

In Codex, use native subagents. The main control surfaces are 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: "...") instruct the Worker to make corrections
• Codex: resume_agent(agent_id) resume the Worker → send_input(agent_id, "...") send instructions

The harness-work pseudocode is written in Claude Code syntax. In a 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)