Team execution mode (Codex host) — backward-compatible alias for harness-work with backend selection, including opt-in Cursor worker delegation.

MITAuto-check: notes

Install Breezing

skills CLI
$ npx skills add Chachamaru127/claude-code-harness --skill breezing -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Chachamaru127/claude-code-harness breezing --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Chachamaru127/claude-code-harness.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills-codex/breezing .claude/skills/breezing && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
breezing
GitHub stars
3.2k
Token cost
~5.7k tokens
SKILL.md length
1,054 words
Files
1
Skills in repo
25
Repo updated
First seen
Licence
MIT

At a glance

Team execution mode (Codex host) — backward-compatible alias for harness-work with backend selection, including opt-in Cursor worker delegation.

  • Works in 4 steps: Plan gate: 依頼スコープの task が Plans.md… → Work: 既存のチーム実行フロー(per-task review 含む) → Integrated Review Gate(既定 ON):… → …
  • SKILL.md covers Default Pipeline(plan → work →…, Quick Reference, Options and Execution, plus 5 more sections
  • Calls git, composer and bash

What it does

Breezing is an agent skill from Chachamaru127/claude-code-harness. Team execution mode (Codex host) — backward-compatible alias for harness-work with backend selection, including opt-in Cursor worker delegation. Composer/composer 2.5 maps to the cursor backend.

Its SKILL.md is about 5.7k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

The repository describes itself as: Claude Code Dedicated Development Harness - Achieving High-Quality Development Through an Autonomous Plan→Work→Review Cycle. The licence is MIT.

Example prompts

  • “/breezing”

Requirements

  • Pre-approved tools (allowed-tools): Read, Bash, spawn_agent, send_input, wait_agent, close_agent

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Plan gate: 依頼スコープの task が Plans.md に無い/不足なら、先に harness-plan を実行してから続行(スコープ既定は「今進められる全作業」)
  2. Work: 既存のチーム実行フロー(per-task review 含む)
  3. Integrated Review Gate(既定 ON): 実装完了後・最終化(完了報告・run 完了宣言)の前に、run 全体 diff に harness-review を実行。review target は通常 {base_ref}..HEAD、--no-commit…
  4. Finalize + Report: gate APPROVE 後に Plans.md 更新・完了報告を確定。最終報告は easy 作法(host に easy skill があればその作法、なければ Completion Report テンプレート)

What it can do on your machine

Read from SKILL.md and the folder at commit 2b2b748. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Bash
    • spawn_agent
    • send_input
    • wait_agent
    • close_agent

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • composer
    • bash
    • codex
    • cursor

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Breezing loads about 5.7k tokens when it runs. Until then it costs about 51 tokens; SKILL.md has 1,054 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~51
When it runs · the whole SKILL.md, loaded when a task matches
~5.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Read, Bash, spawn_agent, send_input, wait_agent, close_agent

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Chachamaru127/claude-code-harness at commit 2b2b748, republished under its MIT licence (© Chachamaru127). 1,054 words, ~5,696 tokens.

Download SKILL.mdSave it as .claude/skills/breezing/SKILL.md (or your agent's skills folder).
name
breezing
description
Team execution mode (Codex host) — backward-compatible alias for harness-work with backend selection, including opt-in Cursor worker delegation. Composer/composer 2.5 maps to the cursor backend.
allowed-tools
Read, Bash, spawn_agent, send_input, wait_agent, close_agent
description-en
Team execution mode (Codex host) — backward-compatible alias for harness-work with backend selection, including opt-in Cursor worker delegation…
description-ja
チーム実行モード(Codex ホスト版)— harness-work のチーム協調エイリアス。Codex からも opt-in で Cursor worker backend に委譲できる。breezing, チーム実行, 全部やって, composer, コンポーザー, composer 2.5 でトリガー。
kind
workflow
purpose
Wrap harness-work with Codex-host team execution orchestration
trigger
breezing, team execution, do everything, cursor worker, composer, composer 2.5, composer mode, コンポーザー
shape
wrap
role
orchestrator
base
harness-work
pair
harness-review
owner
harness-core

Breezing — Team Execution Mode (Codex Host)

この SKILL.md は Codex host 版です。 Claude Code 版は skills/breezing/SKILL.md を参照してください。 backend は resolver で選びます。配布 plugin のフラグなし既定は claude 互換のままです。 --cursor / --backend cursor、または HARNESS_IMPL_BACKEND=cursor を設定した環境では Cursor worker backend を使います。 frontmatter の allowed-tools も、この4つの Codex native tool 名に合わせます。

後方互換エイリアス: harness-work --breezing をチーム実行モードで動かします。

Default Pipeline(plan → work → review → report を 1 コマンドで完走)

Claude Code 版と同一の契約(operator 裁定 2026-07-24。正本: skills/breezing/SKILL.md の同名節):

  1. Plan gate: 依頼スコープの task が Plans.md に無い/不足なら、先に harness-plan を実行してから続行(スコープ既定は「今進められる全作業」)
  2. Work: 既存のチーム実行フロー(per-task review 含む)
  3. Integrated Review Gate(既定 ON): 実装完了後・最終化(完了報告・run 完了宣言)の前に、run 全体 diff に harness-review を実行。review target は通常 {base_ref}..HEAD、--no-commit run は working tree(未 commit 変更 + untracked)。fresh-context 独立 reviewer + cross-CLI second opinion を併走させ、APPROVE まで修正 → 再レビューを反復(最大 3 回。未収束は影響 task を cc:WIP に戻して human escalation)
  4. Finalize + Report: gate APPROVE 後に Plans.md 更新・完了報告を確定。最終報告は easy 作法(host に easy skill があればその作法、なければ Completion Report テンプレート)

低リスクの高速 run で 3 を省きたい時は --no-review-gate(per-task review は維持、統合レビューのみスキップ)。

Work Mode Lifecycle (bin/harness work-mode)

Claude Code 版と同一の契約(正本: skills/breezing/SKILL.md の同名節)。 Lead は run 開始時(Plan gate に入る前)に bin/harness work-mode on を実行し、 run 終了時は成功・失敗・中断の全経路で bin/harness work-mode off を実行する。 session ID が解決できない場合、work-mode は非ゼロ終了し理由を stderr に出す。

Quick Reference

bash
breezing                        # スコープを聞いてから実行
breezing all                    # resolved backend で ready task を完走(配布既定は claude、現環境は user config で cursor 可)
breezing 3-6                    # resolved backend でタスク3〜6を完走
breezing composer 2.5 all       # 自然言語 trigger: cursor backend として扱う
breezing --backend cursor all    # Cursor worker backend を明示
breezing --backend claude all    # Codex native spawn_agent worker を明示
breezing --codex all             # Codex CLI worker backend を明示
breezing --cursor all            # Cursor worker backend を明示
breezing --max-workers 2 all     # ready task の同時 spawn 上限を2に
breezing --max-workers 1 all     # 旧来の直列挙動に戻す
breezing --no-discuss all       # 計画議論スキップで全タスク完走

Options

OptionDescriptionDefault
all全未完了タスクを対象-
N or N-Mタスク番号/範囲指定-
--backend <claude|codex|cursor>worker backend を明示選択resolver result(配布既定は claude)
--cursor--backend cursor の別名false
--codex--backend codex の別名false
--max-workers Nready task の同時 spawn 数上限(breezing 固有オプション)。1 で旧来の直列挙動max
--no-commit非対応(Breezing では Worker の一時 commit と Lead の cherry-pick が必須)-
--no-discuss計画議論スキップfalse

Execution

このスキルは harness-work --breezing に委譲します。 以下の設定で実行してください:

  1. 引数を harness-work --breezing に渡す(--max-workers N は breezing 固有オプションとして解釈し、harness-work の --parallel とは別概念)
  2. チーム実行モードを強制 — Lead → Worker spawn → 必要時 Advisor → companion review Reviewer の四者分離
  3. Lead は delegate 専念 — コードを直接書かず、Worker 実行中は仕様照合、独立した調査、証拠確認、統合準備を進める

委譲本文には目的と理由、担当範囲、DoD、選択した plan / spec、観測済み証拠、原依頼と承認の参照を含める。以降の {task prompt} もこの情報を持つ。 独立して検証できる成果に ownership を割り当て、ready task と利用可能な同時実行上限を守る。他担当の変更を戻さず、関連 follow-up は同じ担当へ返す。Reviewer は fresh-context のまま分離する。 担当は境界内で方法を選び、承認済み可逆作業を完了する。不足は読み取りで補い、軽微な仮定と重大な仕様判断・不足する権限を区別する。推定スコープを承認として扱わない。 必須チェックと既定レビューが通ったら、新しい変更や未解決の懸念がない限り追加テストや機能を増やさず、実結果と証拠を返す。

Execution Backend (persistent)

バックエンド選択(worker を claude / codex / cursor のどれで実装するか)の正本は harness-work の「Execution Backend Selection(実装バックエンド選択)」を参照する。 そこに precedence、role-scope(review / advisor は実装役から分離した担当別 route)、self_review スキップ、cursor banner が定義されている。 backend 判定は 必ず resolver 経由にし、HARNESS_IMPL_BACKEND env だけを直読みしない。 CCH のモデルと effort は未指定時の role 既定。利用者の明示指定と手動変更を尊重し、native profile / 明示 override に従う。AI が文言から再調整したり、親の変更を全 Worker に配ったりしない。独立 Reviewer の隔離と read-only は維持する。

Codex Breezing も配布 plugin では call-site default を変えない:

bash
bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh"

precedence は --backend / --cursor / --codex > HARNESS_IMPL_BACKEND env > project env.local > user ~/.config/claude-harness/impl-backend.env > call-site default claude。 つまり配布 plugin のフラグなし breezing all は互換性のため claude のまま。 この環境のように user/project config で HARNESS_IMPL_BACKEND=cursor が設定されている場合だけ、 フラグなしで Cursor worker backend になる。Codex native subagent worker を明示する時は --backend claude を指定する。

composer / コンポーザー / Composer で / composer 2.5 / composer モード は、正式に cursor backend の trigger として扱う。 これは --cursor 相当の intent であり、Lead は resolve-impl-backend.sh を経由して backend を確定する。 解決時は明示 override として --backend cursor を渡し、env / project / user file / default より優先させる。 composer は Codex native Worker の内側に spawn する追加 agent ではなく、非 claude backend の規約どおり Lead が cursor-companion.sh を直接呼ぶ。

既定の worker 数は max。 ここでの max は「対象スコープ内で Depends が満たされ、今すぐ実行できる ready task の最大数」を意味する。 無制限に Worker を spawn する意味ではない。 依存待ちのタスクは、前段タスクが完了して ready になるまで spawn しない。 旧来の 1 件ずつ進める直列挙動に戻したい場合は --max-workers 1 を指定する。

Worker の実装は並列化できるが、レビューと main への cherry-pick は直列で行う。 これは同じ main worktree への書き込み競合を避けるため。 Go の HARNESS_TEAM_HIERARCHY=sublead は CLI mini-plan 入口未実装、HARNESS_REVIEW_ITERATE=on は production brain runner 未提供(claude-companion.sh 欠損)のため end-to-end 未対応。この更新では有効化せず、既定の flat / OFF を維持する。 この制約は Go opt-in 入口に限る。手動 Producer 分解と通常の Skill / Native reviewer loop は別経路として維持する。

harness-work との違い
特徴harness-workbreezing (このスキル)
デフォルトモードSolo / SequentialBreezing(チーム実行)
並列手段companion task Bash 並列spawn_agent によるサブエージェント委譲
Lead の役割調整+実装delegate (調整専念)
レビューLead 自己レビューcompanion review 独立レビュー
デフォルトスコープ次のタスク全部
Team Composition(Codex Native)
Role実行方式権限責務
Lead(self)現セッション継承調整・指揮・タスク分配・cherry-pick
Worker ×Nresolver result: spawn_agent / codex-companion.sh / cursor-companion.sh task --write --workspace <worktree>セッション権限継承実装(git worktree 分離)
Advisorclaude-code-harness:advisor読み取り専用方針助言 (PLAN / CORRECTION / STOP)
Reviewercompanion review --baseread-only独立レビュー

Flow Summary

breezing [scope] [--backend claude|codex|cursor] [--max-workers N] [--no-discuss]
    │
    ↓ Load harness-work --breezing
    │
Phase 0: Planning Discussion (--no-discuss でスキップ)
Phase A: Pre-delegate(チーム初期化 + worktree 準備)
Phase B: Delegate(resolver-selected worker + 必要時 Advisor + companion review レビュー)
Phase C: Post-delegate(統合検証 + Plans.md 更新 + commit)

Advisor Protocol

Worker は generic な subagent を増やさない。 迷った時は構造化 JSON で相談要求だけ返し、Lead が advisor を呼ぶ。

  1. Worker → advisor-request.v1
  2. Lead → Advisor
  3. Advisor → advisor-response.v1
  4. Lead → 同じ Worker に advice を返して続行
  5. Reviewer は最後の成果物だけを見る

相談条件は loop / solo とそろえる。

  • 高リスク task(needs-spike / security-sensitive / state-migration)の初回実行前
  • 同じ原因の失敗が 2 回続いた後
  • plateau により PIVOT_REQUIRED を返す直前
  • 同じ trigger_hash は 1 回だけ。task ごとの相談回数は最大 3 回
Show full SKILL.md (435 more words)Show less

Realtime Handoff / Silence Policy

Codex 0.123.0 以降では、background agent が realtime handoff の transcript delta を受け取れる。 Breezing ではこの仕組みを「余計な通知を増やす入口」ではなく、「必要な時だけ判断を更新するための入力」として扱う。

ひとことで: Worker / Advisor / Reviewer は、状態が変わらない transcript delta には反応せず、Lead への報告は material state change に絞る。

たとえると、複数人の作業部屋で全員が独り言を実況するのではなく、担当作業が終わった時、詰まった時、判断待ちの時だけ声をかける形。

報告するもの:

  • Worker の完了 JSON、blocked 理由、必要な advisor-request.v1
  • Advisor の PLAN / CORRECTION / STOP
  • Reviewer の APPROVE / REQUEST_CHANGES
  • validation failure、contract readiness failure、plateau、drift 検知
  • Lead が出す task 完了単位の progress feed

沈黙してよいもの:

  • transcript delta を受け取っただけで、task status、review verdict、advisor decision が変わっていない場合
  • tool stdout の細かな増分で、job log に残っていれば十分なもの
  • parallel spawn 中の待機 heartbeat。待機は wait_agent / job status に任せる

途中報告の頻度:

  • Lead の progress feed は task 完了ごとに 1 回を基本にする。
  • Worker / Reviewer は「完了・差し戻し・ブロック」の結果だけを返し、delta ごとの小報告は避ける。
  • user が明示的に status を求めた場合だけ、Lead がまとめて現在地を返す。

Advisor / Reviewer drift との関係:

  • silence policy は Advisor / Reviewer を黙らせる免除ではない。
  • advisor-request.v1 送信後に response が返らない、reviewer profile に必要な result がない、review loop が plateau した場合は drift として扱う。
  • Advisor は方針助言、Reviewer は品質判定という役割分離を維持し、沈黙は「不要な通知を出さない」ためだけに使う。
Phase 0: Planning Discussion(構造化 3 問チェック)

全タスク実行前に、以下の 3 観点を原依頼と Plans.md から確認する。回答済み事項は聞き直さず、読み取り調査でも解けない判断分岐だけ質問する。 --no-discuss 指定時は全スキップ。

Q1. スコープ確認:

原依頼で指定された {{N}} 件と担当範囲を照合する。対象が複数候補のままなら範囲を確認する。

Q2. 依存関係確認(Plans.md に Depends カラムがある場合のみ):

{{X}} の Depends={{Y}} と完了証拠を照合し、ready task だけ委譲する。仕様上の依存が矛盾する場合だけ確認する。

Q3. リスクフラグ([needs-spike] タスクがある場合のみ):

{{Z}} の [needs-spike] に対し、既存の調査結果と Advisor 条件を確認する。追加の仕様判断や保護操作が必要な場合だけ確認する。

Phase A: Pre-delegate
  1. Plans.md を読み込み、対象タスクを特定
  2. 依存グラフを解析し、実行順序を決定
  3. 各タスク用に git worktree を作成
Phase B: Delegate(Codex Host Orchestration)
  • 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.
for task in execution_order:
    # B-0. 作業ディレクトリ分離
    worktree_path = "/tmp/worker-{task.number}-$$"
    branch_name = "worker-{task.number}-$$"
    git worktree add -b {branch_name} {worktree_path}
    TASK_BASE_REF = git rev-parse HEAD

    # B-1. sprint-contract を生成
    contract_path = bash("node \"${HARNESS_PLUGIN_ROOT}/scripts/generate-sprint-contract.js\" {task.number}")
    contract_path = bash("scripts/enrich-sprint-contract.sh {contract_path} --check \"DoD を reviewer 観点で確認\" --approve")
    bash("scripts/ensure-sprint-contract-ready.sh {contract_path}")

    # B-2. Worker 委託
    Plans.md: task.status = "cc:WIP"

    resolver_backend_arg = ""
    if explicit_backend_value in ["claude", "codex", "cursor"]:
        resolver_backend_arg = "--backend {explicit_backend_value}"
    backend = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh\" {resolver_backend_arg}")
    if explicit_flag == "--cursor":
        backend = "cursor"
    if explicit_flag == "--codex":
        backend = "codex"

    if backend == "cursor":
        print("🚀 cursor / $(bash \"${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh\" --host cursor --role worker --field model) / {branch_name} / {task.ID}")
        companion_prompt = "{task prompt}\n\nAfter making changes, create exactly one git commit in this worktree before returning."
        companion_output = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh\" task --write --workspace {worktree_path} \"{companion_prompt}\"")
        latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
        if git("-C", worktree_path, "status", "--porcelain") != "":
            git("-C", worktree_path, "add", "-A")
            git("-C", worktree_path, "-c", "user.name=cursor-composer", "-c", "user.email=cursor-composer@local", "commit", "--no-verify", "-m", "cursor: breezing delegated change")
            latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
        if latest_commit == TASK_BASE_REF:
            raise EscalationError("cursor companion produced no commit")
        worker_result = {type: "companion-result.v1", baseCommit: TASK_BASE_REF, commit: latest_commit, worktreePath: worktree_path, branch: branch_name, files_changed: git("-C", worktree_path, "diff", "--name-only", "{TASK_BASE_REF}..HEAD"), summary: companion_output}
        worker_id = null
    elif backend == "codex":
        companion_prompt = "{task prompt}\n\nAfter making changes, create exactly one git commit in this worktree before returning."
        companion_state_file = "{worktree_path}/.claude/state/codex-primary-environment.json"
        companion_output = bash("CODEX_MODEL_TIER=worker HARNESS_CODEX_PRIMARY_ENV_STATE_FILE={companion_state_file} bash \"${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh\" task --write -C {worktree_path} \"{companion_prompt}\"")
        latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
        if latest_commit == TASK_BASE_REF:
            raise EscalationError("codex companion produced no commit")
        worker_result = {type: "companion-result.v1", baseCommit: TASK_BASE_REF, commit: latest_commit, worktreePath: worktree_path, branch: branch_name, files_changed: git("-C", worktree_path, "diff", "--name-only", "{TASK_BASE_REF}..HEAD"), summary: companion_output}
        worker_id = null
    else:
        print("🚀 claude / native-subagent / {branch_name} / {task.ID}")
        worker_id = spawn_agent({
            agent_type: "worker",
            message: "作業ディレクトリ: {worktree_path} で作業してください。\n\nタスク: {task.内容}\n目的と理由: {purpose_and_why}\n担当範囲: {owned_paths_and_non_goals}\nDoD: {task.DoD}\nplan/spec: {selected_plan_and_spec_paths}\ncontract_path: {contract_path}\n証拠と前回結果: {evidence_and_prior_advice}\n原依頼と承認の参照: {authorization_references}\n\n担当範囲で方法を選び、他担当の変更を戻さず、承認済み作業を完了してください。完了後 git commit してください。\n\n完了時、以下の JSON を返してください。summary に判断理由、チェックの実結果と証拠の参照、未確認点を含めてください:\n{\"commit\": \"<hash>\", \"files_changed\": [...], \"summary\": \"...\"}",
            fork_turns: "3"
        })
        worker_result = wait_agent({ targets: [worker_id] })

    # B-3. Worker が advice request を返した時だけ、Lead が Advisor を呼ぶ
    if backend == "claude" and worker_result.type == "advisor-request.v1":
        advisor_id = spawn_agent({
            agent_type: "default",
            message: worker_result.request_json
        })
        advisor_result = wait_agent({ targets: [advisor_id] })
        close_agent({ target: advisor_id })
        send_input({
            target: worker_id,
            message: "advisor-response.v1: {advisor_result}"
        })
        worker_result = wait_agent({ targets: [worker_id] })

    # B-4. Lead がレビュー実行(TASK_BASE_REF 起点)
    # 公式プラグイン companion review を使用(harness-work の「レビューループ」参照):
    #   bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" review --base {TASK_BASE_REF}
    #   → verdict マッピング: approve→APPROVE, needs-attention→REQUEST_CHANGES
    VERDICT = review_task(worktree_path, TASK_BASE_REF)  # static review(harness-work 参照)
    PROFILE = jq(contract_path, ".review.reviewer_profile")
    BROWSER_MODE = jq(contract_path, ".review.browser_mode // \"scripted\"")
    REVIEW_INPUT = "review-output.json"
    if PROFILE == "runtime":
        # worktree 内で runtime checks を実行
        REVIEW_INPUT = bash("cd {worktree_path} && scripts/run-contract-review-checks.sh {contract_path}")
        RUNTIME_VERDICT = jq(REVIEW_INPUT, ".verdict")
        if RUNTIME_VERDICT == "REQUEST_CHANGES":
            VERDICT = "REQUEST_CHANGES"
        elif RUNTIME_VERDICT == "DOWNGRADE_TO_STATIC":
            REVIEW_INPUT = "review-output.json"  # static review にフォールバック
    if PROFILE == "browser":
        # browser artifact は PENDING_BROWSER scaffold。reviewer agent が後続で実行。
        BROWSER_ARTIFACT = bash("scripts/generate-browser-review-artifact.sh {contract_path}")
        # REVIEW_INPUT は static review のまま維持
    if REVIEW_INPUT != "review-output.json" and jq(REVIEW_INPUT, ".verdict") == "DOWNGRADE_TO_STATIC":
        REVIEW_INPUT = "review-output.json"
    bash("scripts/write-review-result.sh {REVIEW_INPUT} {commit_hash}")

    # B-5. 修正ループ(REQUEST_CHANGES 時、contract の max_iterations まで)
    review_count = 0
    # sprint-contract が存在するときのみ max_iterations を読む。存在しない場合は 3(後方互換)
    MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3
    while VERDICT == "REQUEST_CHANGES" and review_count < MAX_REVIEWS:
        if backend == "claude":
            send_input({
                target: worker_id,
                message: "指摘内容: {issues}\n元の目的、DoD、担当範囲、承認を維持し、対応と検証証拠を返してください。修正して git commit --amend してください。修正後 JSON を再出力してください。"
            })
            wait_agent({ targets: [worker_id] })
        elif backend == "cursor":
            previous_commit = git("-C", worktree_path, "rev-parse", "HEAD")
            bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh\" task --write --workspace {worktree_path} \"{task prompt}\n\nReview findings:\n{issues}\n\nPreserve the original DoD, owned scope and authorization references. Fix the findings and create one new git commit before returning.\"")
            latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
            if git("-C", worktree_path, "status", "--porcelain") != "":
                git("-C", worktree_path, "add", "-A")
                git("-C", worktree_path, "-c", "user.name=cursor-composer", "-c", "user.email=cursor-composer@local", "commit", "--no-verify", "-m", "cursor: breezing review fix")
                latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
            if latest_commit == previous_commit:
                raise EscalationError("cursor companion retry produced no new commit")
        else:
            previous_commit = git("-C", worktree_path, "rev-parse", "HEAD")
            companion_state_file = "{worktree_path}/.claude/state/codex-primary-environment.json"
            bash("CODEX_MODEL_TIER=worker HARNESS_CODEX_PRIMARY_ENV_STATE_FILE={companion_state_file} bash \"${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh\" task --write -C {worktree_path} \"{task prompt}\n\nReview findings:\n{issues}\n\nPreserve the original DoD, owned scope and authorization references. Fix the findings and create one new git commit before returning.\"")
            latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
            if latest_commit == previous_commit:
                raise EscalationError("codex companion retry produced no new commit")
        VERDICT = review_task(worktree_path, TASK_BASE_REF)
        review_count++

    # B-6. Worker 終了
    if backend == "claude":
        close_agent({ target: worker_id })

    # B-7. 結果処理
    if VERDICT == "APPROVE":
        commit_hash = git("-C", worktree_path, "rev-parse", "HEAD")
        git cherry-pick --no-commit {TASK_BASE_REF}..{commit_hash}
        git commit -m "{task.内容}"
        Plans.md: task.status = "cc:完了 [{short_hash}]"
    else:
        → ユーザーにエスカレーション(Plans.md は cc:WIP のまま)
        → 後続タスクも停止

    # B-8. Worktree クリーンアップ
    git worktree remove {worktree_path}
    git branch -D {branch_name}

    # B-9. Progress feed
    print("📊 Progress: Task {completed}/{total} 完了 — {task.内容}")
ready task の並列 spawn(既定 max / --max-workers N 指定時)

Depends が満たされた ready task が複数ある場合、既定では ready task の数まで同時 spawn する。 --max-workers N を指定すると、同時 spawn 数を N 件までに制限する。 --max-workers 1 は旧来の直列挙動に戻す escape hatch。

wait_agent のセマンティクス: wait_agent({targets: [a, b]}) は最初に完了した1つを返す(全完了待ちではない)。 したがって、全 Worker の完了を待つにはループで個別に wait_agent を呼ぶ。

# 独立タスク A, B を並列 spawn(各自 worktree 分離済み)
worker_a = spawn_agent({ agent_type: "worker", message: "作業ディレクトリ: /tmp/worker-a-$$ ...", fork_turns: "3" })
worker_b = spawn_agent({ agent_type: "worker", message: "作業ディレクトリ: /tmp/worker-b-$$ ...", fork_turns: "3" })

# 各 Worker の完了を個別に待ち → レビュー → cherry-pick(直列)
# wait_agent は最初の1つを返すので、残りの Worker はまだ動作中
for worker_id in [worker_a, worker_b]:
    wait_agent({ targets: [worker_id] })    # この Worker の完了を待つ
    VERDICT = review_task(worktree_path, TASK_BASE_REF)  # harness-work 参照
    # 修正ループ(必要なら)...
    close_agent({ target: worker_id })
    if VERDICT == "APPROVE":
        cherry-pick → Plans.md 更新

制約: 並列化できるのは Depends が満たされた ready task のみ。 max は ready task 数の上限であり、無制限 spawn ではない。 レビュー → cherry-pick は直列実行(main への書き込みが競合するため)。

Worker の出力契約

Worker プロンプトには、完了時に以下の JSON を返すことを明示する:

json
{
  "commit": "a1b2c3d",
  "files_changed": ["src/foo.ts", "tests/foo.test.ts"],
  "summary": "foo モジュールに bar 機能を追加"
}

Lead はこの JSON を解析して commit hash とファイル一覧を取得する。 JSON の成功申告だけで完了にせず、差分、DoD、必須チェック、review の証拠を照合する。内部の思考過程は求めない。

Progress Feed(Phase B 中の進捗通知)
📊 Progress: Task 1/5 完了 — "harness-work に失敗再チケット化を追加"
📊 Progress: Task 2/5 完了 — "harness-sync に --snapshot を追加"
完了報告(Phase C)

全タスク完了後、Lead が以下の手順でリッチ完了報告を生成:

  1. git log --oneline {session_base_ref}..HEAD で全 cherry-pick コミットを収集
  2. git diff --stat {session_base_ref}..HEAD で全体の変更規模を取得
  3. Plans.md の残タスクを抽出
  4. Breezing テンプレートに従い出力

Claude Code 版との差分

項目Claude Code 版Codex ネイティブ版(本ファイル)
Worker spawnClaude Code Agent tool + worktree isolationresolver result: spawn_agent, codex-companion.sh, or cursor-companion.sh + git worktree add
完了待ちAgent の戻り値wait_agent({targets: [id]})
修正指示Claude Code message toolsend_input({target, message})
Worker 終了自動close_agent({target})
レビューCodex exec → Reviewer agent fallbackcompanion review --base(構造化出力)
権限bypassPermissions + hookscompanion task --write / spawn_agent: セッション権限継承
Agent TeamsCLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 環境変数Codex native(標準機能)
Worktreeisolation="worktree" 自動管理git worktree add/remove 手動管理
モード昇格タスク4件以上で自動--breezing 明示時のみ
  • harness-work — 単一タスクからチーム実行まで(本体)
  • harness-sync — 進捗同期
  • harness-review — コードレビュー

© Chachamaru127, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills-codex/breezing of Chachamaru127/claude-code-harness.

Open the folder on GitHubat commit 2b2b748

Compare with similar skills

Breezing next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Breezing compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Breezing this skillChachamaru127/claude-code-harness3.2k—~5.7kAutomated safety check: NotesMIT
Tabler Backward Compatibilitytabler/tabler42k—~4kAutomated safety check: PassMIT
Review Backward Compatibilityruby-git/ruby-git1.8k—~2.4kAutomated safety check: PassMIT
Element Backwards CompatPrairieLearn/PrairieLearn512—~401Automated safety check: PassCustom licence
Escaping Containers To Hostmukul975/Anthropic-Cybersecurity-Skills34k—~3.4kAutomated safety check: PassApache-2.0
Cross Host Federationruvnet/ruflo74k—~1.1kAutomated safety check: PassMIT

Similar skills

  • Keeps changes to @tabler/core backward compatible so patch and minor releases never break projects, covering what counts as public API and how to alias renames.

    42k GitHub stars~4k tokensUpdated today
    Frontend & DesignAuto-check passed
  • Audits Git::Lib methods for backward compatibility after commands are moved to Git::Commands:: classes.

    1.8k GitHub stars~2.4k tokensUpdated 5 days ago
    DevelopmentAuto-check passed
  • Element Backwards Compat

    PrairieLearn/PrairieLearn

    Backwards compatibility rules when changing element controllers in apps/prairielearn/elements/.

    512 GitHub stars~401 tokensUpdated today
    Auto-check passed
  • Escaping Containers To Host

    mukul975/Anthropic-Cybersecurity-Skills

    Exploits privileged pods, host mounts, runC CVEs, and exposed Docker sockets to break out of a container and reach the underlying host during an authorized container-security assessment.

    34k GitHub stars~3.4k tokensUpdated 1 mo ago
    SecurityAuto-check passed
  • Join and operate a signed cross-host agentbbs federation, and coordinate work claims across nodes.

    74k GitHub stars~1.1k tokensUpdated today
    Auto-check passed
  • Host Pattern

    nukeop/nuclear

    A skill your agent uses when adding a new domain to Nuclear's plugin system, or implementing a host.

    19k GitHub stars~1.3k tokensUpdated yesterday
    Auto-check passed

More from Chachamaru127/claude-code-harness

All 25 skills in this repo
  • CI Failure Triage and Repair

    Chachamaru127/claude-code-harness

    Diagnoses failing CI pipelines and tests, deciding first whether the test or the implementation is at fault, and hands hard cases to a dedicated fixer subagent.

    3.2k GitHub starsUsed in 1 repo~1.1k tokens
    Auto-check: notes
  • Cursor Composer Task Delegate

    Chachamaru127/claude-code-harness

    Hands one implementation task to Cursor Composer in an isolated git worktree, then reviews its diff and cherry-picks the result into the main branch.

    3.2k GitHub stars~4.4k tokensUpdated 2 days ago
    Auto-check: notes
  • Acceptance Demo Generator

    Chachamaru127/claude-code-harness

    Renders a single HTML page showing each acceptance criterion as verified or not, with a ship, wait, or reject recommendation for non-engineers.

    3.2k GitHub stars~3.4k tokensUpdated 2 days ago
    Auto-check: notes
  • Harness Long-Running Task Loop

    Chachamaru127/claude-code-harness

    Repeats a long task as a series of scheduled wake-ups, each re-entering with fresh context and calling harness-work for one task per cycle.

    3.2k GitHub stars~2.3k tokensUpdated 2 days ago
    Auto-check: notes
  • Harness Plan

    Chachamaru127/claude-code-harness

    Creates and maintains Plans.md task plans with a spec delta, updates task markers and syncs plan progress with the implementation.

    3.2k GitHub stars~3.7k tokensUpdated 2 days ago
    Auto-check: notes
  • Harness Release

    Chachamaru127/claude-code-harness

    Runs a release for any project that keeps a Keep a Changelog file on GitHub, from version bump to merge, tag and GitHub Release after a single approval.

    3.2k GitHub stars~4.4k tokensUpdated 2 days ago
    Auto-check: notes

Questions about Breezing

What does Breezing do?

Team execution mode (Codex host) — backward-compatible alias for harness-work with backend selection, including opt-in Cursor worker delegation. Breezing is an agent skill from Chachamaru127/claude-code-harness. Team execution mode (Codex host) — backward-compatible alias for harness-work with backend selection, including opt-in Cursor worker delegation.

How do I install Breezing in Claude Code?

Run `npx skills add Chachamaru127/claude-code-harness --skill breezing -a claude-code`. Or copy the skill folder (skills-codex/breezing in Chachamaru127/claude-code-harness) into .claude/skills/breezing in your project. Claude Code loads it when a task matches its description.

How do I install Breezing in Codex?

Run `npx skills add Chachamaru127/claude-code-harness --skill breezing -a codex`. Or copy the skill folder (skills-codex/breezing in Chachamaru127/claude-code-harness) into .agents/skills/breezing in your project. Codex loads it when a task matches its description.

Can I use Breezing in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Chachamaru127/claude-code-harness --skill breezing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/breezing, .gemini/skills/breezing, .github/skills/breezing and .opencode/skills/breezing in your project.

What does Breezing need to run?

Going by SKILL.md and its folder, Breezing needs the command-line tools its instructions call (git, composer, bash, codex and cursor). Its frontmatter pre-approves these tools: Read, Bash, spawn_agent, send_input, wait_agent, close_agent.

Does Breezing access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Breezing safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Breezing use?

Breezing is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Breezing use?

About 5.7k tokens (SKILL.md is roughly 23k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Breezing?

Skills that share tags, products or a category with Breezing: Tabler Backward Compatibility (tabler/tabler, 42k stars), Review Backward Compatibility (ruby-git/ruby-git, 1.8k stars), Element Backwards Compat (PrairieLearn/PrairieLearn, 512 stars) and Escaping Containers To Host (mukul975/Anthropic-Cybersecurity-Skills, 34k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Breezing?

Chachamaru127 (a GitHub user) maintains it in Chachamaru127/claude-code-harness, which has 3,153 GitHub stars. The repository holds 25 skills in this directory. The repository was last updated on October 5, 2026.

Source: Chachamaru127/claude-code-harness on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.