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.
The canonical home for this skill is breezing in Chachamaru127/claude-code-harness
この 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 をチーム実行モードで動かします。
Claude Code 版と同一の契約(operator 裁定 2026-07-24。正本: skills/breezing/SKILL.md の同名節):
harness-plan を実行してから続行(スコープ既定は「今進められる全作業」)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)easy skill があればその作法、なければ Completion Report テンプレート)低リスクの高速 run で 3 を省きたい時は --no-review-gate(per-task review は維持、統合レビューのみスキップ)。
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 に出す。
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 # 計画議論スキップで全タスク完走| Option | Description | Default |
|---|---|---|
all | 全未完了タスクを対象 | - |
N or N-M | タスク番号/範囲指定 | - |
--backend <claude|codex|cursor> | worker backend を明示選択 | resolver result(配布既定は claude) |
--cursor | --backend cursor の別名 | false |
--codex | --backend codex の別名 | false |
--max-workers N | ready task の同時 spawn 数上限(breezing 固有オプション)。1 で旧来の直列挙動 | max |
--no-commit | 非対応(Breezing では Worker の一時 commit と Lead の cherry-pick が必須) | - |
--no-discuss | 計画議論スキップ | false |
このスキルは harness-work --breezing に委譲します。 以下の設定で実行してください:
harness-work --breezing に渡す(--max-workers N は breezing 固有オプションとして解釈し、harness-work の --parallel とは別概念)委譲本文には目的と理由、担当範囲、DoD、選択した plan / spec、観測済み証拠、原依頼と承認の参照を含める。以降の {task prompt} もこの情報を持つ。
独立して検証できる成果に ownership を割り当て、ready task と利用可能な同時実行上限を守る。他担当の変更を戻さず、関連 follow-up は同じ担当へ返す。Reviewer は fresh-context のまま分離する。
担当は境界内で方法を選び、承認済み可逆作業を完了する。不足は読み取りで補い、軽微な仮定と重大な仕様判断・不足する権限を区別する。推定スコープを承認として扱わない。
必須チェックと既定レビューが通ったら、新しい変更や未解決の懸念がない限り追加テストや機能を増やさず、実結果と証拠を返す。
バックエンド選択(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 "${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-work | breezing (このスキル) |
|---|---|---|
| デフォルトモード | Solo / Sequential | Breezing(チーム実行) |
| 並列手段 | companion task Bash 並列 | spawn_agent によるサブエージェント委譲 |
| Lead の役割 | 調整+実装 | delegate (調整専念) |
| レビュー | Lead 自己レビュー | companion review 独立レビュー |
| デフォルトスコープ | 次のタスク | 全部 |
| Role | 実行方式 | 権限 | 責務 |
|---|---|---|---|
| Lead | (self) | 現セッション継承 | 調整・指揮・タスク分配・cherry-pick |
| Worker ×N | resolver result: spawn_agent / codex-companion.sh / cursor-companion.sh task --write --workspace <worktree> | セッション権限継承 | 実装(git worktree 分離) |
| Advisor | claude-code-harness:advisor | 読み取り専用 | 方針助言 (PLAN / CORRECTION / STOP) |
| Reviewer | companion review --base | read-only | 独立レビュー |
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)Worker は generic な subagent を増やさない。 迷った時は構造化 JSON で相談要求だけ返し、Lead が advisor を呼ぶ。
advisor-request.v1advisor-response.v1相談条件は loop / solo とそろえる。
needs-spike / security-sensitive / state-migration)の初回実行前PIVOT_REQUIRED を返す直前trigger_hash は 1 回だけ。task ごとの相談回数は最大 3 回Codex 0.123.0 以降では、background agent が realtime handoff の transcript delta を受け取れる。
Breezing ではこの仕組みを「余計な通知を増やす入口」ではなく、「必要な時だけ判断を更新するための入力」として扱う。
ひとことで: Worker / Advisor / Reviewer は、状態が変わらない transcript delta には反応せず、Lead への報告は material state change に絞る。
たとえると、複数人の作業部屋で全員が独り言を実況するのではなく、担当作業が終わった時、詰まった時、判断待ちの時だけ声をかける形。
報告するもの:
advisor-request.v1PLAN / CORRECTION / STOPAPPROVE / REQUEST_CHANGES沈黙してよいもの:
wait_agent / job status に任せる途中報告の頻度:
Advisor / Reviewer drift との関係:
advisor-request.v1 送信後に response が返らない、reviewer profile に必要な result がない、review loop が plateau した場合は drift として扱う。全タスク実行前に、以下の 3 観点を原依頼と Plans.md から確認する。回答済み事項は聞き直さず、読み取り調査でも解けない判断分岐だけ質問する。
--no-discuss 指定時は全スキップ。
Q1. スコープ確認:
原依頼で指定された {{N}} 件と担当範囲を照合する。対象が複数候補のままなら範囲を確認する。
Q2. 依存関係確認(Plans.md に Depends カラムがある場合のみ):
{{X}} の Depends={{Y}} と完了証拠を照合し、ready task だけ委譲する。仕様上の依存が矛盾する場合だけ確認する。
Q3. リスクフラグ([needs-spike] タスクがある場合のみ):
{{Z}} の [needs-spike] に対し、既存の調査結果と Advisor 条件を確認する。追加の仕様判断や保護操作が必要な場合だけ確認する。
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.内容}")--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 プロンプトには、完了時に以下の JSON を返すことを明示する:
{
"commit": "a1b2c3d",
"files_changed": ["src/foo.ts", "tests/foo.test.ts"],
"summary": "foo モジュールに bar 機能を追加"
}Lead はこの JSON を解析して commit hash とファイル一覧を取得する。 JSON の成功申告だけで完了にせず、差分、DoD、必須チェック、review の証拠を照合する。内部の思考過程は求めない。
📊 Progress: Task 1/5 完了 — "harness-work に失敗再チケット化を追加"
📊 Progress: Task 2/5 完了 — "harness-sync に --snapshot を追加"全タスク完了後、Lead が以下の手順でリッチ完了報告を生成:
git log --oneline {session_base_ref}..HEAD で全 cherry-pick コミットを収集git diff --stat {session_base_ref}..HEAD で全体の変更規模を取得| 項目 | Claude Code 版 | Codex ネイティブ版(本ファイル) |
|---|---|---|
| Worker spawn | Claude Code Agent tool + worktree isolation | resolver result: spawn_agent, codex-companion.sh, or cursor-companion.sh + git worktree add |
| 完了待ち | Agent の戻り値 | wait_agent({targets: [id]}) |
| 修正指示 | Claude Code message tool | send_input({target, message}) |
| Worker 終了 | 自動 | close_agent({target}) |
| レビュー | Codex exec → Reviewer agent fallback | companion review --base(構造化出力) |
| 権限 | bypassPermissions + hooks | companion task --write / spawn_agent: セッション権限継承 |
| Agent Teams | CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 環境変数 | Codex native(標準機能) |
| Worktree | isolation="worktree" 自動管理 | git worktree add/remove 手動管理 |
| モード昇格 | タスク4件以上で自動 | --breezing 明示時のみ |
harness-work — 単一タスクからチーム実行まで(本体)harness-sync — 進捗同期harness-review — コードレビュー2b2b748
Canonical home
since Jul 27, 2026
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.