breezing

# 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 | 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 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 | `claude-code-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\": \"...\"}",