breezing

Breezing — Team Execution Mode

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

Narration Rules (UX Contract)

The enemy is verbosity, not progress reporting. At startup, state the execution plan concisely, then begin execution. Readable progress reports are welcome. Only verbose repetition and empty preambles are prohibited.

Always emit at startup (banner + plan, 5 lines total max)

In the first response, show what and in what order before entering tool execution:

🚀 cursor / composer-2.5-fast / feat/hah-11-golden-rule-lint / Reviewer
Next:
1. resolve backend/model
2. delegate diff review to composer (read-only)
3. summarize the verdict in 3-5 lines → update Plans.md

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

Progress reports are allowed (within a readable range)

• A one-line status for the start/finish of each step (✓ backend=cursor / model=composer-2.5-fast)
• Intermediate results needed for a decision (pre-check highlights, resolved model, detected branch, etc.)
• A one-line reason for why a branch is taken (e.g. "Reviewer-only delegation: Worker already done via another path")

Prohibited (= verbosity)

• Rephrasing the same fact twice: do not re-explain later what you already said
• Empty preamble: lines like "let me check the usage" only — a declaration that is obvious from the tool call
• 3+ lines of recap: a long preamble that stretches out the conclusion. If context is needed, compress it to 1 line
• ★ Insight block during the startup sequence: Insight appears once only, in the final report

Violation example (verbose):

× "composer 2.5 mode" = delegate to Composer on the cursor backend, right? (rephrasing the interpretation)
× "Since the Reviewer stalled last time, escaping to another path makes sense" (3+ lines of recap)
× "Let me check the usage" → bash → "we can call it" (empty preamble + rephrasing the same fact twice)

Good example (concise + explicit plan):

🚀 cursor / composer-2.5-fast / feat/hah-11-golden-rule-lint / Reviewer
Next: resolve backend → delegate diff review to composer (read-only) → summarize verdict

Quick Reference

/breezing                       # ask for the scope (claude backend)
/breezing all                   # run all tasks to completion (claude backend)
/breezing 3-6                   # run tasks 3-6 to completion
/breezing --codex all           # delegate all tasks to the Codex CLI
/breezing --cursor              # cursor backend lean path (--no-discuss all by default)
/breezing --cursor --reviewer-only  # delegate only the Reviewer to cursor (Worker already done via another path)
/breezing composer 2.5 all      # natural-language trigger: treated as cursor backend
/breezing --parallel 2 all      # run all tasks to completion with 2-way parallelism
/breezing --no-discuss all      # run all tasks to completion, skipping plan discussion
/breezing --auto-mode all       # try the Auto Mode rollout in a compatible parent session

Options

Option	Description	Default
all	target all incomplete tasks	-
N or N-M	task number/range	-
--codex	delegate implementation to the Codex CLI	false
--cursor	cursor backend lean path (equivalent to HARNESS_IMPL_BACKEND=cursor). Skips Worker intervention / self_review / the sprint-contract 3-stage chain / Phase 0, and starts startup → delegation within 3 seconds	false
--reviewer-only	delegate only the Reviewer to an independent path (assumes Worker implementation is already done). Combine with --cursor to escape to Composer	false
--parallel N	number of parallel Implementers	auto
--no-commit	suppress auto-commit	false
--no-discuss	skip plan discussion	true by default with --cursor
--auto-mode	explicitly enable the Harness-side Auto Mode rollout. Different from --enable-auto-mode, which became unnecessary in CC 2.1.111	false

Natural Language Backend Triggers

composer / Composer with / composer 2.5 / composer mode are formally treated as triggers for the cursor backend. This is intent equivalent to --cursor; the Lead resolves the backend via resolve-impl-backend.sh. When resolving, pass --backend cursor as an explicit override so it takes priority over env / project / user file / default.

Example input	Interpretation	Execution path
with composer 2.5	cursor backend	Lead → cursor-companion.sh task --write --workspace <wt>
everything with composer	cursor backend	Lead → cursor-companion.sh task --write --workspace <wt>
composer mode	cursor backend	Lead → cursor-companion.sh task --write --workspace <wt>

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

CC 2.1.111 note: On Opus 4.7, you can literally use /effort xhigh. Use the built-in /ultrareview additionally only on explicit request; it does not replace the default review.

Long-session recommendation (CC 2.1.108+): When a session is expected to exceed 30 minutes, after resolving the plugin bundle root, run bash "${HARNESS_PLUGIN_ROOT}/scripts/enable-1h-cache.sh" to opt into the 1-hour prompt cache. This script appends export ENABLE_PROMPT_CACHING_1H=1 to env.local (idempotent). With the default 5-minute TTL cache, cache misses accumulate over a breezing session exceeding 1 hour and input token cost can be up to 12x, so explicitly opt in for long-running team execution. Codex CLI child processes (scripts/codex-companion.sh task --write, etc.) usually read ENABLE_PROMPT_CACHING_1H via env inheritance, but when CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 is enabled, a shell wrapper that explicitly keeps the export is needed. For details see docs/long-running-harness.md.

Execution

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

1. Pass the arguments to harness-work as-is
2. Force team execution mode — the three-way separation of Lead → Worker spawn → Reviewer spawn
3. The Lead focuses on delegation — it does not write code directly
4. Auto Mode is opt-in — --auto-mode is accepted as a rollout flag for a compatible parent session
5. Advisor only when needed — the Lead calls the advisor only when a Worker returns advisor-request.v1

Difference from harness-work

Feature	harness-work	breezing (this skill)
Parallel means	auto-split per needed count	role separation of Lead/Worker/Reviewer
Lead's role	coordinate + implement	delegate (coordination only)
Review	Lead self-review	independent Reviewer
Default scope	the next task	everything

Team Composition

Role	Agent Type	Mode	Responsibility
Lead	(self)	-	coordinate, direct, distribute tasks
Worker ×N	claude-code-harness:worker	bypassPermissions (current) / Auto Mode (follow-up)*	implement
Advisor	claude-code-harness:advisor	read-only	direction advice (PLAN / CORRECTION / STOP)
Reviewer	claude-code-harness:reviewer	bypassPermissions (current) / Auto Mode (follow-up)*	independent review

*When the parent session or frontmatter is bypassPermissions, that takes priority. Since the distribution template still uses bypassPermissions, Auto Mode is a follow-up rollout target, not the default behavior.

Codex Mode (--codex)

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

# Task delegation (writable)
bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write "task content"

# Via stdin (for large prompts)
CODEX_PROMPT=$(mktemp /tmp/codex-prompt-XXXXXX.md)
# write out the task content
cat "$CODEX_PROMPT" | bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write
rm -f "$CODEX_PROMPT"

Execution Backend (persistent)

When HARNESS_IMPL_BACKEND=cursor (set with bash "${HARNESS_PLUGIN_ROOT}/scripts/set-impl-backend.sh" cursor), cursor becomes the default worker backend without a per-run flag. The review / advisor roles stay fixed to Opus. For the authoritative source of backend selection (precedence, role-scope, self_review skip, cursor banner), see "Execution Backend Selection" in harness-work.

The Cursor Backend Fast Path below is a separate axis that enables an equivalent lean path via a per-run flag (--cursor); read it together with this section.

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

Enabled when --cursor is specified, or when env HARNESS_IMPL_BACKEND=cursor. The Lead calls cursor-companion.sh directly without inserting the Worker layer (Phase 85 SSOT, the Topology section of .claude/rules/cursor-cli-only.md).

Removed steps (savings compared with the claude backend)

Step	Reason for removal	Seconds saved
claude-code-harness:worker agent spawn	the cursor backend has no Worker intervention	5-30s
self_review 5-item gate	worker-report.v1 is not generated on cursor, so it is unnecessary	10-60s × retry
sprint-contract 3-stage chain (generate→enrich→ensure)	no contract needed if no Worker contract is needed	2-5s × N
Phase 0 Q1-Q3 interactive	--no-discuss all by default (the Lead reads Plans/Depends directly)	15-30s
Effort scoring	no ultrathink injection needed on the cursor backend	0.5-1s × N
Plans.md re-parse (per task)	in-session cache (short-circuited by mtime+hash)	3-8s

In total, shortens the time to start the first task's cursor delegation from a baseline of 15-35s to a target of 3-7s.

Default flow (cursor backend)

1. banner + execution plan (🚀 cursor / <model> / <branch> / <task> + 2-4 steps coming up, 5 lines total max, within 1 second)
2. parallel pre-check in 1 bash: git branch --show-current + cat VERSION + Plans.md tail + cursor-agent --version
3. resolve in 1 bash: bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh" + bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host cursor --role worker --field model
4. delegate immediately: bash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task --write --workspace <wt> "<task>"
5. the Lead diff-reviews the cursor output → cherry-pick → update Plans.md cc:done [hash]

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

A lean path for when the Worker implementation is already done (finished via another path = claude / Codex) and you want only the Reviewer run on an independent path (Composer). Since it is a read-only delegation, no worktree, no cherry-pick, no Lead diff review:

1. banner + plan: 🚀 cursor / composer-2.5-fast / review + "Next: delegate diff review to composer → summarize verdict"
2. bash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task "diff review: <base_ref>..HEAD" — add neither --write nor --workspace
   • the companion defaults to --mode ask (hard read-only stop) when --write is unspecified (the workspace guard of cursor-companion.sh fires only with --write)
   • on the cursor side, file writes and command execution are disabled; no worktree isolation needed
3. the Lead interprets the cursor output (equivalent to REQUEST_CHANGES / APPROVE) and stores it as advisory in dual_review.cursor_verdict
4. take the primary verdict from the Opus reviewer. cursor alone does not finalize APPROVE (consistent with the invariant rule in harness-work/SKILL.md "the backend that implemented must not review its own output")
5. if APPROVE, the Lead updates Plans.md cc:done [hash]

Removable in read mode: dedicated .git worktree / Lead diff review / cherry-pick / worker-report.v1 / self_review 5 items. Must keep even in read mode: .cursorignore / egress allowlist (*.cursor.sh) / permissions.json (best-effort). For details see the "Read mode delegation (lean path)" section of .claude/rules/cursor-cli-only.md.

Uses:

• An escape hatch when the Reviewer stalls due to an Anthropic-side server rate limit
• When the Worker is done and only the Reviewer is offloaded to another path
• A manual fallback when a Codex review fails auth

Cursor adapter support claim

Cursor is still internal-compatible tier (promoted in Phase 87 / PR #174). The supported public claim remains gated until the CI-gated workflow smoke is satisfied. The --cursor lean path does not promote the support 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 (skipped with --no-discuss)
Phase A: Pre-delegate (team initialization)
Phase B: Delegate (Worker implements + Advisor when needed + Reviewer reviews)
Phase C: Post-delegate (integration verification + Plans.md update + commit)

Advisor Protocol

The Worker does not add generic subagents. When in doubt, it returns only a structured-JSON consultation request, and the Lead calls the advisor.

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

Consultation conditions align with loop / solo.

• Before the first run of a high-risk task (needs-spike / security-sensitive / state-migration)
• After the same cause of failure happened twice
• Just before returning PIVOT_REQUIRED due to a plateau
• The same trigger_hash only once. The max consultations per task is 3

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} done — "{task_subject}"

Output example:

📊 Progress: Task 1/5 done — "add failure re-ticketing to harness-work"
📊 Progress: Task 2/5 done — "add --snapshot to harness-sync"
📊 Progress: Task 3/5 done — "add a progress feed to breezing"

Design intent: breezing often runs for a long time. Make it possible to tell at a glance "how far it has progressed" when the user glances at the terminal. The task-completed.sh hook outputs equivalent info via systemMessage, complementing the Lead's output.

Silence Policy (organizing notifications for long runs)

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

What to report:

• task completion, blocked, validation failure, review REQUEST_CHANGES
• the Advisor's PLAN / CORRECTION / STOP
• the Reviewer's APPROVE / REQUEST_CHANGES
• advisor / reviewer drift, plateau, contract readiness failure
• a summary when the user explicitly asks for status

What may stay silent:

• when it merely received a transcript delta and no verdict or status changed
• minor increments of tool stdout, where the log is sufficient
• heartbeats while parallel Workers are waiting

Keep the frequency to "once per task completion" as the baseline. Rather than adding heartbeats for reassurance, split the responsibility into status / log / drift detection. However, do not make the following silence targets: an unanswered Advisor request, an undelivered Reviewer result, or a warning just before a plateau.

Monitor Tool Usage Guide (CC 2.1.98+)

When monitoring a long-running command, use the Monitor tool rather than polling (periodically reading the tail of a file with Read). Monitor delivers each stdout line of a background process to the Lead as an incremental notification, so you can grasp the situation with lower latency and lower token consumption than polling.

Application examples:

• Monitoring progress during go test ./... -v
• Tracking GitHub Actions progress via gh run watch
• Immediate build-error detection for npm run build --watch / vite build --watch
• Detecting Codex job completion with codex-companion.sh status <job-id>
• Tracking deploy logs with docker-compose logs -f / kubectl logs -f

Criteria for choosing:

Target	Use Monitor?	Reason
Completion monitoring of an Agent (Worker / Reviewer)	No	the Agent layer notifies completion itself
A shell process thrown with run_in_background: true	Recommended	each stdout line can be picked up via incremental notification
A short one-shot command (running go test once)	No	a normal Bash tool execution is enough
Long-running tail / watch / stream commands	Recommended	more efficient than polling

Typical pattern in the Breezing Lead:

Lead:
  Task(Worker1, ...)           ← waiting for Agent completion (Monitor not needed)
  Task(Worker2, ...)           ← same
  Bash(run_in_background, "gh run watch --exit-status")
  Monitor(tailCommand="...")   ← detect CI failure immediately → instruct the Worker to fix

This lets the Lead speed up its "Worker done → detect CI failure → instruct fix" reaction.

Review Policy (unified across all modes)

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

• The Worker implements and commits inside a worktree → returns worker-report.v1 (self_review 5 items) to the Lead
• self_review gate (before Reviewer spawn): the Lead mechanically verifies self_review[].verified and evidence. If even one is verified:false or evidence:"", it does not spawn the Reviewer and auto-sends back to the Worker (up to 2 times within the same session, escalate on the 3rd)
• The Lead reviews via Codex exec (120s timeout, fallback: Reviewer agent)
• REQUEST_CHANGES → the Lead instructs the Worker to fix via SendMessage, and the Worker amends (up to MAX_REVIEWS times. MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3)
• APPROVE → the Lead cherry-picks to main → updates Plans.md to cc:完了 [{hash}]

Completion Report (Phase C — generated by the Lead)

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

1. Collect all cherry-pick commits with git log --oneline {base_ref}..HEAD
2. Get the overall change size with git diff --stat {base_ref}..HEAD
3. Extract remaining cc:TODO / cc:WIP tasks from Plans.md
4. Output following the Breezing template of the "Completion Report Format" in harness-work

The generator is the Lead, not the Worker or a hook. The Lead reads git + Plans.md in Phase C and generates it.

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

Before running all tasks, confirm the plan's soundness with the following 3 questions. All are skipped when --no-discuss is specified.

Q1. Scope check:

"I will run {{N}} tasks. Is the scope appropriate?"

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

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

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

Read the Depends column and show the dependency chain. Error on a circular dependency.

Q3. Risk flag (only when there is a [needs-spike] task):

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

When there is an incomplete-spike [needs-spike] task, confirm whether to run the spike first.

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

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

Auto-inject the Reviewer's universal gotchas accumulated within the same /breezing launch at the top of the next Worker's briefing. Valid only within the same session (discarded at session end; not written to session-memory).

# Initialize the Lead process's in-memory array at the start of Phase A
universal_violations = []  # List[str] — accumulated within this session

# Just before spawning a Worker in Phase B, inject at the top of the briefing:
def build_worker_briefing(task, contract_path):
    header = ""
    if universal_violations:
        header = (
            "🚨 universal violations already detected in this session (do not recur):\n"
            + "\n".join(f"- {v}" for v in universal_violations)
            + "\n\n"
        )
    return header + f"Task: {task.content}\nDoD: {task.DoD}\ncontract_path: {contract_path}\nmode: breezing"

# After the Reviewer returns review-result.v1, the Lead extracts only scope="universal" and accumulates:
for update in reviewer_result.memory_updates:
    # Backward compat: a string is treated as task-specific → ignore
    if isinstance(update, str):
        continue
    if update.get("scope") == "universal":
        universal_violations.append(update["text"])

Policy: to avoid over-engineering, do not persist to session-memory or decisions.md. Just keep it in the Lead process's in-memory array and discard it at the end of the /breezing session (the policy of issue #87's body).

Task Assignment Based on the Dependency Graph

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

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

Note: each task's "Worker done → review → cherry-pick" is sequential. Only the Worker-spawn part of independent tasks (Depends is -) can be parallelized.

Codex Native Orchestration

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

Claude Code vs Codex communication APIs (SSOT: the API mapping table in team-composition.md):

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

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

Related Skills

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