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

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

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

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 "${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 独立レビュー
デフォルトスコープ	次のタスク	全部

Team Composition（Codex Native）

Role	実行方式	権限	責務
Lead	(self)	現セッション継承	調整・指揮・タスク分配・cherry-pick
Worker ×N	resolver result: spawn_agent / codex-companion.sh / cursor-companion.sh task --write --workspace <worktree>	セッション権限継承	実装（git worktree 分離）
Advisor	harness:advisor	読み取り専用	方針助言 (PLAN / CORRECTION / STOP)
Reviewer	companion review --base	read-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 回

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 を返すことを明示する:

{
  "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 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 明示時のみ

Related Skills

• harness-work — 単一タスクからチーム実行まで（本体）
• harness-sync — 進捗同期
• harness-review — コードレビュー