[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C4QJ4BPK9YP4T7TJSC96X1":3,"skill-same:01M6C4QJ4BPK9YP4T7TJSC96X1":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6C4QJ4BPK9YP4T7TJSC96X1","breezing",null,"Team execution mode — backward-compatible alias for harness-work with team orchestration. Composer\u002Fcomposer 2.5 maps to the cursor backend.","Chachamaru127\u002Fclaude-code-harness","Chachamaru127","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F96473544?v=4","01M6C4N084DDDEK9SJPGFG9H9M","Chachamaru","01M6C4N0CCNFST9P8C7EJNVH42",3208,"MIT","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fopencode\u002Fskills\u002Fbreezing\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"orchestration","harness","execution","team","work","cursor","execution mode","backend","maps","alias","composer","team execution","with","mode","for","2026-11-10 10:12:30",false,"---\nname: breezing\ndescription: \"Team execution mode — backward-compatible alias for harness-work with team orchestration. Composer\u002Fcomposer 2.5 maps to the cursor backend.\"\n---\n\n# Breezing — Team Execution Mode\n\n> **後方互換エイリアス**: `harness-work` をチーム実行モードで動かします。\n\n## Default Pipeline（plan → work → review → report を 1 コマンドで完走）\n\n`\u002Fbreezing` は「計画 → 実装 → OK が出るまでレビュー → 報告」を 1 回の起動で完走する。\noperator が `\u002Fharness-plan` や `\u002Fharness-review` を個別に指示する必要はない（operator 裁定 2026-07-24）。\n\n1. **Plan gate**: 依頼スコープに対応する task が Plans.md に無い、または不足している場合、先に `harness-plan` を実行して task を生成してから続行する。既に plan がある場合はそのまま Phase 0 へ。plan 生成時のスコープは harness-plan の「スコープ既定: 今進められる全作業」に従う。\n2. **Work**: 既存の Phase 0 → A → B（per-task review 含む）。\n3. **Integrated Review Gate（Phase D、既定 ON）**: Phase B 完了後、**Phase C の最終化（完了報告・run 完了宣言）より前に**、run 全体の diff に `harness-review` を実行する。\n   - review target: 通常 run は `{base_ref}..HEAD`。`--no-commit` run は commit range が空になりうるため、**working tree（未 commit 変更 + untracked ファイル）を対象にする**\n   - fresh-context の独立 reviewer subagent（実装 Worker と会話状態を共有しない）と、`bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fcodex-companion.sh\" review --base \"${base_ref}\"` の second opinion を併走させる\n   - いずれかが REQUEST_CHANGES 相当 → 修正 → 再レビュー。**APPROVE が出るまで反復する**（最大 3 回）。未収束の場合は影響 task の marker を `cc:WIP` に戻し、human escalation で停止して findings と修正状況を報告する\n   - primary verdict（`APPROVE | REQUEST_CHANGES`）は brain（claude host）が出す。role-scoped 制約は維持\n4. **Finalize + Report（Phase C）**: gate の APPROVE を得てから Plans.md 更新・commit・完了報告を確定する。gate 未通過のまま run を「完了」として報告してはならない。最終報告は easy 作法で出す（host session に `easy` skill があれば invoke してその作法に従う。無ければ `harness-work` の Completion Report テンプレート）。\n\n`--reviewer-only` \u002F `--no-commit` 等の既存フラグは、この pipeline の該当段だけを動かす per-run override として働く。\n低リスクの高速 run で Phase D を省きたい時は `--no-review-gate` を渡す（Phase B の per-task review は省かれない。省くのは run 全体 diff への統合レビューだけ）。\n\n### Work Mode Lifecycle (`bin\u002Fharness work-mode`)\n\nR04\u002FR05 の確認 skip が読む `ctx.WorkMode` は、`HARNESS_WORK_MODE` \u002F `ULTRAWORK_MODE` env\n（skill から設定できない）か SQLite `work_states` 行のどちらかで立つ。`bin\u002Fharness work-mode \u003Con|off|status>`\nが後者を書く唯一の入口（`harness-work` の「Work Mode Lifecycle」節が正本）。\n\n- Lead は Plan gate に入る前（run 開始時）に `bin\u002Fharness work-mode on` を実行する。\n  `--codex` run では `bin\u002Fharness work-mode on --codex` を使う（R07 = Lead の直接\n  Write\u002FEdit 禁止が同時に立つ）\n- Lead は run 終了時、**成功・失敗・中断の全経路**で `bin\u002Fharness work-mode off` を実行する\n  （backend が `claude` \u002F `codex` \u002F `cursor` のどれでも同じ規律。cursor fast path の\n  `session declare` \u002F `--clear` と同じ「run 境界で必ず対で呼ぶ」形）\n- run 単位で 1 回のみ。task ごとに on\u002Foff しない\n- session ID が解決できない場合は非ゼロ終了 + 理由が stderr に出る（無言で成功しない）\n\n### Breezing run state (`breezing-active.json`) — guardrail の file producer\n\nLead は run 開始時に `.claude\u002Fstate\u002Fbreezing-active.json` を書く。guardrail は\nこのファイルを R07（codex mode）と R08（reviewer subagent 判定のスコープ）の\nfile producer として読む（`go\u002Finternal\u002Fguardrail\u002Fbreezing_state.go`）:\n\n```json\n{\"impl_mode\": \"codex\", \"started_at\": \"\u003CISO8601>\"}\n```\n\n- `impl_mode` は `--codex` なら `\"codex\"`、それ以外は `\"claude\"` \u002F `\"cursor\"`\n- run 終了時（全経路）にこのファイルを削除する。残すと次の通常セッションでも\n  R07\u002FR08 のスコープ判定が生き続ける\n- reviewer teammate（worktree spawn）には env `HARNESS_BREEZING_ROLE=reviewer` を\n  spawn コマンドの環境に付ける。セッション内 reviewer subagent は CC が付与する\n  `agent_type` で自動判定されるため追加作業は不要\n\n## Narration Rules (UX Contract)\n\n敵は **冗長さ** であって進捗報告ではない。**起動時に実行計画を簡潔に明示してから実行を開始する**。見やすい進捗報告は歓迎する。冗長な繰り返し・中身のない前置きだけを禁ずる。\n\n### 起動時に必ず出すもの (banner + plan、合計 5 行以内)\n\n最初の応答で、何を・どの順で進めるかを示してから tool 実行に入る:\n\n```\n? cursor \u002F composer-2.5-fast \u002F feat\u002Fhah-11-golden-rule-lint \u002F Reviewer\nこれから:\n1. backend\u002Fmodel を resolve\n2. composer に advisory findings を委譲 (read-only)\n3. brain 一次レビューで verdict を確定 → 3-5 行要約 → Plans.md 更新\n```\n\nbanner 1 行 (`? \u003Cbackend> \u002F \u003Cmodel> \u002F \u003Cbranch> \u002F \u003Ctask>`) + 計画 2-4 行。1 秒以内に出し、即 Step 1 へ。\n\n### Backend 既定と per-run のフラット判断（2026-07-24 operator 裁定）\n\n既定 backend は **`claude`（Native subagent）**。resolver の未設定 fallback も `claude` であり、これは罠ではなく意図された既定。\n⚠️ 警告は resolver が **不正値 fallback** の stderr 警告を出した時だけ banner 直後に 1 行で出す（正常に `claude` へ解決された場合は出さない。同一 run 内で繰り返さない）。\n\nLead は run 単位で、作業内容・量からフラットに backend を選んでよい。選ぶ時は resolver への明示 override（`--backend \u003Cv>` \u002F `--codex` \u002F `--cursor`）を使う。env 直読みは引き続き禁止:\n\n| 作業の性質 | 推奨 backend | 理由 |\n|---|---|---|\n| 通常の実装・修正・テスト（既定） | `claude` (native) | Worker 契約（`worker-report.v1` \u002F self_review 5 件）が全部効く |\n| 大規模で独立性の高い一括実装、Claude 側 rate limit 回避 | `codex` | `breezing --codex` の companion が専用の worker route を解決して委譲する。Native Codex は managed custom agent を選択し、deep \u002F review \u002F advisor は各 role の route を維持する |\n| UI 大量生成、lean な高速委譲 | `cursor` | lean path（worktree 隔離 + Lead diff review） |\n\nモデル ID は skill に書かない。`bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fmodel-routing.sh\" --host \u003Cbackend> --role worker` が正本。\nCCH の role 値は未指定時の既定。利用者の明示指定と手動変更を尊重し、AI の推定で再調整せず、親の変更を全 Worker に配らない。native profile と Reviewer の隔離契約を維持する。\n`breezing --codex` の companion 経路だけが `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fmodel-routing.sh\" --host codex --role worker` で\n専用の `worker` route を解決する。`max` が返る場合は\n`codex-companion.sh` が公式 companion 1.0.6 の `--effort max` 非対応を吸収し、\nraw `codex exec` の config override へ正規化する。Worker の write\u002Fsandbox\nintent は保持し、deep \u002F review \u002F advisor の role route を worker に流用しない。\n\nCodex-native Breezing は管理済み `.codex\u002Fagents\u002Fworker.toml` を\n`agent_type: worker` で選択する。model \u002F reasoning は custom agent 側で管理し、\nskill から直接渡さない。bounded `fork_turns: \"3\"` は残してよいが、\n`[agents].default_subagent_*` は全 subagent を retune するため設定しない。\nこの worker role は setup が user の `$CODEX_HOME\u002Fagents\u002Fworker.toml` または\nproject の `.codex\u002Fagents\u002Fworker.toml` にコピーして初めて有効になる。Codex 0.148 の\nplugin manifest は native agent role を登録できず、plugin の install \u002F cache \u002F dist\nへの収録だけでは有効化されない。\n公式の Subagents 設定: https:\u002F\u002Flearn.chatgpt.com\u002Fdocs\u002Fagent-configuration\u002Fsubagents?surface=app\n\n### 進捗報告は出してよい (見やすい範囲で)\n\n- 各ステップの開始・完了を 1 行ステータスで (`✓ backend=cursor \u002F model=composer-2.5-fast`)\n- 判断に必要な中間結果 (pre-check の要点、resolved model、検出した branch 等)\n- なぜこの分岐を取るかの理由を 1 行で (例: 「Reviewer のみ委譲: Worker は別系統で完了済み」)\n\n### 禁止 (= 冗長さ)\n\n- **同じ事実の 2 回言い換え**: 一度言ったことを後段で再説明しない\n- **中身のない前置き**: 「使い方を確認します」だけの行など、tool call で自明な宣言\n- **3 行以上の経緯振り返り**: 結論を引き伸ばす長い前置き。経緯が必要なら 1 行に圧縮\n- **起動シーケンス中の ★ Insight ブロック**: Insight は最終 report で 1 回のみ\n\n## Quick Reference\n\n```bash\n\u002Fbreezing                       # スコープを聞く（claude backend）\n\u002Fbreezing all                   # 全タスク完走（claude backend）\n\u002Fbreezing 3-6                   # タスク3〜6を完走\n\u002Fbreezing --codex all           # Codex CLI で全タスク委託\n\u002Fbreezing --cursor              # cursor backend lean path (--no-discuss all 既定)\n\u002Fbreezing --cursor --reviewer-only  # Reviewer のみ cursor に委譲（Worker は別系統で既完了）\n\u002Fbreezing composer 2.5 all      # 自然言語 trigger: cursor backend として扱う\n\u002Fbreezing --parallel 2 all      # 2並列で全タスク完走\n\u002Fbreezing --no-discuss all      # 計画議論スキップで全タスク完走\n\u002Fbreezing --auto-mode all       # 互換な親セッションで Auto Mode rollout を試す\n```\n\n## Brief Composer v0\n\nargument-hint のどれにも一致しない自由文入力は `bash scripts\u002Fbreezing-brief.sh classify \"\u003Cargs>\"` で `structured` \u002F `free-text` を判定する。\n`free-text` は 3〜7 個の subtasks に分解した `brief-card.v1` カードをユーザーに提示し、`breezing-brief.sh confirm \u003Cyes|no> \u003Ccard.json>` で確定する。\n分解ロジック・schema・`DISPATCH` 契約の詳細は [references\u002Flean-path-detail.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Flean-path-detail.md) を参照。\n\n## Options\n\n| Option | Description | Default |\n|--------|-------------|---------|\n| `all` | 全未完了タスクを対象 | - |\n| `N` or `N-M` | タスク番号\u002F範囲指定 | - |\n| `--codex` | Codex CLI で実装委託 | false |\n| `--cursor` | cursor backend lean path（per-run 明示 override。resolver 出力が `cursor` のときと同等）。Worker 介在 \u002F self_review \u002F sprint-contract 3 段チェーン \u002F Phase 0 を skip し、起動 → 委譲を 3 秒以内に開始する | false |\n| `--reviewer-only` | Reviewer のみ独立系統に委譲（Worker 実装は既完了前提）。`--cursor` と併用で Composer に逃がす | false |\n| `--parallel N` | Implementer 並列数 | auto |\n| `--no-commit` | 自動コミット抑制 | false |\n| `--no-discuss` | 計画議論スキップ | `--cursor` で true 既定 |\n| `--no-review-gate` | Phase D（Integrated Review Gate）をスキップ。Phase B の per-task review は維持 | false |\n| `--auto-mode` | Harness 側の Auto Mode rollout を明示。CC 2.1.111 で不要になった `--enable-auto-mode` とは別物 | false |\n\n### `--parallel N` と CC 側の実キャップ（133.9、一次ソース確証済み）\n\n`--parallel N` は Harness 側の希望値であって、実際に同時に走る数は CC が決める。\n**CC は同時実行中の subagent を既定 20 に制限する**（`CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`、2.1.217）。\n20 を超える N を渡しても超過分は待ち行列に入るだけで、エラーにはならない。\nつまり `--parallel 40` は「40 並列」ではなく「20 並列 + 待ち」になる。\n\n**ネストした spawn は既定で深さ 3 まで**（`CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH`、2.1.219 で 1 → 3 に緩和）。\nLead（深さ 0）→ Worker \u002F Reviewer（1）→ Worker が呼ぶ advisor 等（2）は収まる。\nMode 1 の Producer → Sub-Lead → Composer も 3 段以内。\nこれを超える階層を設計するときは、env で上げない限り**静かに spawn が拒否される**ことを前提にする。\n\nどちらも Harness 側は env を明示設定しない（CC の既定に従う）。変えたい場合は run の env で渡す。\n\n## Natural Language Backend Triggers\n\n`composer` \u002F `コンポーザー` \u002F `Composer で` \u002F `composer 2.5` \u002F `composer モード` は、正式に `cursor backend` の trigger として扱う。\nこれは `--cursor` 相当の intent であり、Lead は `resolve-impl-backend.sh` を経由して backend を確定する。\n解決時は明示 override として `--backend cursor` を渡し、env \u002F project \u002F user file \u002F default より優先させる。\n\n| 入力例 | 解釈 | 実行経路 |\n|---|---|---|\n| `composer 2.5 で` | `cursor backend` | Lead → `cursor-companion.sh task --write --workspace \u003Cwt>` |\n| `コンポーザーで全部` | `cursor backend` | Lead → `cursor-companion.sh task --write --workspace \u003Cwt>` |\n| `composer モード` | `cursor backend` | Lead → `cursor-companion.sh task --write --workspace \u003Cwt>` |\n\n`composer` は Claude Worker の内側に spawn する追加 agent ではない。\n非 `claude` backend のトポロジーに従い、Lead が Worker agent を挟まずに `cursor-companion.sh` を直接呼ぶ。\n\n> **CC 2.1.111 note**:\n> Opus 4.7 では literal に `\u002Feffort xhigh` が使える。\n> built-in `\u002Fultrareview` は明示要求時だけ追加で使い、既定レビューは置き換えない。\n\n> **長時間セッション推奨 (CC 2.1.108+)**:\n> セッション長が 30 分を超える見込みの場合、plugin bundle root 解決後に\n> `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fenable-1h-cache.sh\"` を実行して 1 時間 prompt cache を opt-in すること。\n> このスクリプトは `env.local` に `export ENABLE_PROMPT_CACHING_1H=1` を追記する (冪等)。\n> 5 分 TTL の既定キャッシュでは breezing の 1 時間超セッションで cache miss が累積し\n> input token コストが最大 12 倍になりうるため、長時間 team 実行では明示的に opt-in する。\n> Codex CLI 子プロセス (`scripts\u002Fcodex-companion.sh task --write` 等) は通常 env 継承で\n> `ENABLE_PROMPT_CACHING_1H` を読むが、`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1` が有効な場合は\n> 明示的に export を維持する shell wrapper が必要。詳細は\n> [`docs\u002Flong-running-harness.md`](..\u002F..\u002Fdocs\u002Flong-running-harness.md) を参照。\n\n## Execution\n\n**このスキルは `harness-work` に委譲します。** 以下の設定で `harness-work` を実行してください:\n\n1. **引数をそのまま `harness-work` に渡す**\n2. **チーム実行モードを強制** — Lead → Worker spawn → Reviewer spawn の三者分離\n3. **Lead は delegate 専念** — コードを直接書かず、Worker 実行中は仕様照合、独立した調査、証拠確認、統合準備を進める\n4. **Auto Mode は opt-in 扱い** — `--auto-mode` は互換な親セッションでの rollout 用フラグとして受け付ける\n5. **Advisor は必要時のみ** — Worker が `advisor-request.v1` を返した時だけ Lead が advisor を呼ぶ\n\n委譲本文には原依頼の目的と理由、担当ファイルと除外範囲、DoD、選択した plan \u002F spec、実測や失敗履歴、承認の参照を含める。companion の `\u003Ctask>` も省略しない。\n担当はその境界内で方法を選び、承認済み可逆作業を完了する。軽微な不足は読み取り調査と明示した仮定で補い、仕様や権限の未決事項だけ依存する操作を止める。\n独立して検証できる成果ごとに ownership を分け、ready task と利用可能な同時実行上限の範囲で委譲する。関連 follow-up は同じ担当へ返し、他担当の編集を戻さない。\n実装担当の再利用と、fresh-context の独立 Reviewer を混同しない。必要なレビューとチェックが通ったら、追加の機能や根拠のない再検証を増やさず結果を返す。\n\n### Plan-time 事前確認の扱い\n\nBreezing run 開始時は、Lead が `harness-work` と同じ preapproval preflight を実行する。\n\n- 各 task の開始時、task worktree の `.claude\u002Fstate\u002Factive-task.json` に `{\"phase\":\"\u003Cphase>\",\"task\":\"\u003Ctask>\"}` を原子的に書く。task 終了時は成功、失敗、停止の全経路で削除する。\n- `.claude\u002Fstate\u002Fplan-preapprovals.json` があれば `scripts\u002Fplan-preapproval.sh validate` で v2 を validate する。v1 は既存記録の読み取り互換として受け付ける。\n- 実行対象 task の `decision: approved` 事項だけを宣言済みとして扱い、Worker briefing に渡す。\n- `secret-read` は `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fplan-preapproval.sh\" apply-secret-allow \"$PROJECT_ROOT\"` で project config `.claude-code-harness.config.json` の `runtimefloor.secretAllow` に per-run 反映し、108.2 の project config floor と接続する。\n- R12 の `ask` は、同じ phase\u002Ftask、期限内、使用回数内で、`external-send` と実行コマンドが一致する v2 承認だけが抑制する。明示 `deny` と runtime floor は抑制しない。\n- 宣言済み事項では途中停止せず、work 中の宣言済み事項起因 `AskUserQuestion` はゼロにする。確認は plan 承認時の 1 回のみ。\n- 記録に無い未計画の secret-read \u002F 外部送信 \u002F 破壊的操作は従来どおり runtime floor \u002F ask で停止する。安全網を狭めない。\n\n### `harness-work` との違い\n\n| 特徴 | `harness-work` | `breezing` (このスキル) |\n|------|-----------------|------------------------|\n| 並列手段 | 必要数に応じた自動分割 | **Lead\u002FWorker\u002FReviewer の役割分離** |\n| Lead の役割 | 調整+実装 | **delegate (調整専念)** |\n| レビュー | Lead 自己レビュー | **独立 Reviewer** |\n| デフォルトスコープ | 次のタスク | **全部** |\n\n### Team Composition\n\n| Role | Agent Type | Mode | 責務 |\n|------|-----------|------|------|\n| Lead | (self) | - | 調整・指揮・タスク分配 |\n| Worker ×N | `harness:worker` | `bypassPermissions`（現行） \u002F Auto Mode（follow-up）* | 実装 |\n| Advisor | `harness:advisor` | 読み取り専用 | 方針助言 (`PLAN` \u002F `CORRECTION` \u002F `STOP`) |\n| Reviewer | `harness:reviewer` | `bypassPermissions`（現行） \u002F Auto Mode（follow-up）* | 独立レビュー |\n\n> *親セッションまたは frontmatter が `bypassPermissions` の場合はそちらが優先される。配布テンプレートは現在も `bypassPermissions` を使うため、Auto Mode は follow-up の rollout 対象であり、既定挙動ではない。\n\n### Mode 1 — Sub-Lead 階層と review→iterate（opt-in）\n\nGo orchestrator 経路（`harness work --team`）の **Producer → Sub-Lead → Composer** は、`HARNESS_TEAM_HIERARCHY=sublead` の CLI mini-plan 入口が未実装のため未対応。この更新では有効化せず、通常は既定の flat で実行する。\nこれは Go の opt-in 入口の制約であり、Lead が手動で担当を分解する Producer トポロジーを無効にするものではない。\n\nGo の `HARNESS_REVIEW_ITERATE=on` も、production brain runner が要求する `claude-companion.sh` が未提供のため end-to-end 未対応。この更新で有効化せず既定 OFF を維持する。\n通常の Skill \u002F Native reviewer loop は別経路であり、既定の review gate と反復上限を維持する。Go opt-in の設計境界は `harness-work` の `references\u002Fbackend-selection.md` を参照する。\n\n- If you grep the same symbol twice in the same session, switch to harness_ast_search.\n- For a bugfix where homologous implementations appear across multiple modules, run harness_ast_search to find all implementations before editing.\n- 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.\n\n### Codex Mode (`--codex`)\n\n公式プラグイン `codex-plugin-cc` 経由で Codex CLI にすべての実装を委託するモード:\n\nこの `--codex` は companion 経路であり、専用 `worker` route を解決して実装を委託する。\n公式 companion 1.0.6 が `--effort max` を拒否するため、router が `max` を返す場合は\nHarness の `codex-companion.sh` が raw `codex exec` の config override へ変換する。\nレビュー・助言・deep 判断は、それぞれの role-scoped route を使う。Native Codex\nBreezing の managed custom-agent 選択とは別経路である。\n\n```bash\n# タスク委託（書き込み可能）\nCODEX_MODEL_TIER=worker bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fcodex-companion.sh\" task --write \"タスク内容\"\n\n# stdin 経由（大きなプロンプト向け）\nCODEX_PROMPT=$(mktemp \u002Ftmp\u002Fcodex-prompt-XXXXXX.md)\n# タスク内容を書き出し\ncat \"$CODEX_PROMPT\" | CODEX_MODEL_TIER=worker bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fcodex-companion.sh\" task --write\nrm -f \"$CODEX_PROMPT\"\n```\n\n### Execution Backend (persistent)\n\nbackend 判定は **必ず resolver 経由**。`HARNESS_IMPL_BACKEND` env を直接読んで backend を決めてはならない。\nenv \u002F `--cursor` per-run flag \u002F project `env.local` \u002F user file を\n`bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fresolve-impl-backend.sh\"` で precedence 解決し、その出力を backend として使う\n（env unset でも project \u002F user file から拾える）。永続 default を変えたい場合は\n`bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fset-impl-backend.sh\" \u003Cclaude|codex|cursor> [--user]` で project \u002F user file に書き込み、\nrun 開始時に resolver が解決する（現行の operator 既定はユーザースコープで `claude`）。review \u002F advisor ロールは brain に固定したまま。\nバックエンド選択の正本（precedence、role-scope、self_review スキップ、cursor banner）は\n`harness-work` の「Execution Backend Selection（実装バックエンド選択）」を参照する。\n\n下の Cursor Backend Fast Path は per-run フラグ (`--cursor`) を resolver への明示 override として lean path を有効化する別軸であり、本節と併読する。\n\n### Cursor Backend Fast Path (`--cursor` \u002F lean mode)\n\n`bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fresolve-impl-backend.sh\"` の出力が `cursor` のときに有効\n（`--cursor` は resolver への明示 override として precedence 最上位）。Worker 層を介在させず Lead が直接 `cursor-companion.sh` を呼ぶ（Phase 85 SSOT、`.claude\u002Frules\u002Fcursor-cli-only.md` Topology 節）。\n\ncursor backend は Worker agent spawn \u002F self_review 5 件ゲート \u002F sprint-contract 3 段チェーン \u002F Phase 0 interactive \u002F effort スコアリングを省略し、baseline `15-35s` → target `3-7s` で 1 タスク目の委譲を開始する。節約内訳の全表は\n[references\u002Flean-path-detail.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Flean-path-detail.md) を参照。\n\n#### 既定 flow（cursor backend）\n\n1. **banner + 実行計画** (`? cursor \u002F \u003Cmodel> \u002F \u003Cbranch> \u002F \u003Ctask>` + これから進める 2-4 step、合計 5 行以内、1 秒以内)\n   - run 全体で 1 回だけ、まだ実行していなければ `bin\u002Fharness work-mode on`（R04\u002FR05 の確認 skip を有効化。詳細は「Work Mode Lifecycle」節）\n2. **1 bash で並列 pre-check**: `git branch --show-current` + `cat VERSION` + `Plans.md tail` + `cursor-agent --version`\n3. **1 bash で resolve**: `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fresolve-impl-backend.sh\"` + `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fmodel-routing.sh\" --host cursor --role worker --field model`\n4. **即 委譲**: `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fcursor-companion.sh\" task --write --workspace \u003Cwt> \"\u003Ctask>\"`\n   - 委譲開始時に `bin\u002Fharness session declare --task \u003Ctask-id>` で共有 presence に作業宣言（他セッションから task 番号で逆引き可能になる）\n5. cursor 出力を Lead が diff レビュー → cherry-pick → Plans.md `cc:done [hash]` 更新\n   - 更新後 `bin\u002Fharness session declare --clear` で presence の task 宣言を解除\n   - run 全体が終わる時（成功・失敗・中断いずれでも）は `bin\u002Fharness work-mode off` を忘れない\n\n#### Reviewer-only mode (`--cursor --reviewer-only`) — read = lean\n\nWorker 実装は既完了（別系統 = claude \u002F Codex で済んだ）、advisory pre-review を Composer に出してもらう lean path。read-only 委譲なので **worktree 不要・cherry-pick 不要・cursor 出力の取り込みレビュー不要**（cursor は新たな diff を生まないため）。ただし対象 diff への **brain 一次レビュー（primary verdict）は省略しない**:\n\n1. banner + 計画: `? cursor \u002F composer-2.5-fast \u002F review` + 「これから: composer に advisory findings を委譲 → brain 一次レビューで verdict 確定」\n2. `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fcursor-companion.sh\" task \"diff レビュー: \u003Cbase_ref>..HEAD\"` — **`--write` も `--workspace` も付けない**\n   - companion は `--write` 未指定で default `--mode ask` (hard read-only stop) になる (cursor-companion.sh の workspace guard は `--write` 時のみ発火)\n   - cursor 側はファイル書込・コマンド実行が disabled、worktree 隔離不要\n3. cursor 出力 (REQUEST_CHANGES \u002F APPROVE 相当) を Lead が解釈し、`dual_review.cursor_verdict` に advisory として格納\n4. **primary verdict は brain reviewer から取る**。cursor 単独では APPROVE を確定しない (spec.md Execution Backend Contract の self-review scope 契約 = 「diff を生成した同一コンテキストは自分の出力をレビューしない」と整合)。この lean path 自体が fresh-context advisory pre-review であり、委譲先 cursor session は実装 worker と会話状態を共有しないこと\n5. **brain 一次レビュー**: Lead が cursor advisory findings を入力として対象 diff を自ら検分し、verdict（`APPROVE | REQUEST_CHANGES`）を出す。brain reviewer が利用不能（rate limit 等）の間は verdict を確定せず、タスクを `cc:wip` のままユーザー判断へ渡す（cursor advisory のみで `cc:done` にしない）\n6. brain の APPROVE 後に Plans.md `cc:done [hash]` を Lead が更新\n\nread mode で省略できるもの: 専用 `.git` worktree \u002F cursor 出力の取り込みレビュー \u002F cherry-pick \u002F `worker-report.v1` \u002F self_review 5 件。**省略不可**: 対象 diff への brain 一次レビュー（verdict 確定）。\nread mode でも保持必要: `.cursorignore` \u002F egress allowlist (`*.cursor.sh`) \u002F permissions.json (best-effort)。詳細は `.claude\u002Frules\u002Fcursor-cli-only.md` 「Read mode delegation (lean path)」節を参照。\n\n**用途**（rate limit 時の前倒し集約 \u002F Reviewer だけ別系統に分散 \u002F Codex review auth 失敗時の fallback、詳細は [references\u002Flean-path-detail.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Flean-path-detail.md)）。\n\n#### Cursor adapter support claim\n\nCursor は `supported` tier（H8 pin: live H4 2026-07-17 + H7 release-preflight fail-closed）。FS jail なし — containment は harness-side（`docs\u002FCURSOR_INTEGRATION.md`）。`--cursor` lean path 自体は tier を昇格させない。\n\nBootstrap route: `.cursor\u002FAGENTS.md` + `.cursor-plugin\u002Fplugin.json`。\n\nVerification:\n\n```bash\nbash tests\u002Ftest-cursor-adapter-candidate.sh\nbash tests\u002Ftest-support-claim-wording.sh\n```\n\n## Flow Summary\n\n```\nbreezing [scope] [--codex] [--parallel N] [--no-discuss] [--auto-mode]\n    │\n    ↓ Load harness-work with team mode\n    │\nPhase 0: Planning Discussion (--no-discuss でスキップ)\nPhase A: Pre-delegate（チーム初期化）\nPhase B: Delegate（Worker 実装 + 必要時 Advisor + Reviewer レビュー）\nPhase C: Post-delegate（統合検証 + Plans.md 更新 + commit）\n```\n\n## Advisor Protocol\n\nWorker は generic な subagent を増やさない。\n迷った時は構造化 JSON で相談要求だけ返し、Lead が advisor を呼ぶ。\n\n1. Worker → `advisor-request.v1`\n2. Lead → Advisor\n3. Advisor → `advisor-response.v1`\n4. Lead → 同じ Worker に advice を返して続行\n5. Reviewer は最後の成果物だけを見る\n\n相談条件は loop \u002F solo とそろえる。\n\n- 高リスク task（`needs-spike` \u002F `security-sensitive` \u002F `state-migration`）の初回実行前\n- 同じ原因の失敗が 2 回続いた後\n- plateau により `PIVOT_REQUIRED` を返す直前\n- 同じ `trigger_hash` は 1 回だけ。task ごとの相談回数は最大 3 回\n\n### Progress Feed（Phase B 中の進捗通知）\n\nLead は Worker のタスク完了ごとに、以下のフォーマットで進捗を出力する:\n\n```\n? Progress: Task {completed}\u002F{total} 完了 — \"{task_subject}\"\n```\n\n**出力例**:\n```\n? Progress: Task 1\u002F5 完了 — \"harness-work に失敗再チケット化を追加\"\n? Progress: Task 2\u002F5 完了 — \"harness-sync に --snapshot を追加\"\n? Progress: Task 3\u002F5 完了 — \"breezing にプログレスフィードを追加\"\n```\n\n> **設計意図**: breezing は長時間実行になることが多い。\n> ユーザーがターミナルをチラ見した時に「今どこまで進んでいるか」が一目で分かるようにする。\n> task-completed.sh フックが systemMessage で同等の情報を出力するため、Lead の出力と補完し合う。\n\n### Silence Policy（長時間実行の通知整理）\n\nCodex `0.123.0` の realtime handoff では、background agent が transcript delta を受け取り、必要ない時は明示的に沈黙できる。\nBreezing の progress feed はこの前提に合わせ、通知を「作業の節目」に絞る。\n\n報告するもの:\n\n- task 完了、blocked、validation failure、review `REQUEST_CHANGES`\n- Advisor の `PLAN` \u002F `CORRECTION` \u002F `STOP`\n- Reviewer の `APPROVE` \u002F `REQUEST_CHANGES`\n- advisor \u002F reviewer drift、plateau、contract readiness failure\n- user が明示的に status を求めた時の要約\n\n沈黙してよいもの:\n\n- transcript delta を受け取っただけで、判定や status が変わっていない時\n- tool stdout の細かな増分で、log に残っていれば十分な時\n- 並列 Worker の待機中 heartbeat\n\n頻度は「task 完了ごとに 1 回」を基本にする。\nheartbeat を増やして安心感を作るのではなく、status \u002F log \u002F drift 検知に責務を分ける。\nただし Advisor request 未応答、Reviewer result 未到着、plateau 直前の警告は silence 対象にしない。\n\n### Monitor ツール活用ガイド (CC 2.1.98+)\n\n`run_in_background: true` で投げた長時間 shell process（`gh run watch`、build --watch 等）は、ポーリングではなく **Monitor ツール**で stdout を逐次通知として拾う。Agent (Worker\u002FReviewer) の完了監視や短時間の一発コマンドには不要。\n使い分け表・典型パターンは [references\u002Fmonitor-and-learning.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fmonitor-and-learning.md) を参照。\n\n### 自主停止の禁止 (140.3、2026-08-22 の release run で 2 回発生した停止パターンの再発防止)\n\n以下は禁止行動。literal に列挙する (AUTOSTART pattern と同じ方式):\n\n- background 待ちで turn を終えて停止しない (turn を終えると background 子プロセスは残らない)\n- 「検証を待ちます」「確認します」「完了を待機します」で turn を終えない\n- 待つなら同期実行 (foreground \u002F Monitor) で待ち切る。待てないものは保留として報告し、次のタスクへ進む\n\n### Review Policy（全モード統一）\n\nBreezing モードでもレビューは **Codex exec 優先 → 内部 Reviewer フォールバック** の統一ポリシーに従う。\n詳細は `harness-work` の「レビューループ」セクションを参照。\n\n- Worker が worktree 内で実装・commit → `worker-report.v1` (self_review 5 件) を Lead に返却\n- **self_review ゲート (Reviewer spawn 前)**: Lead が `self_review[].verified` と `evidence` を機械検証。1 件でも `verified:false` or `evidence:\"\"` なら Reviewer を spawn せず Worker に自動差し戻し（同一セッション内 最大 2 回、3 回目で escalate）\n- `verified:true` や非空の文章だけを実証と扱わず、参照先の差分、失敗出力、必須チェック結果を照合する。判断理由と証拠を求め、内部の思考過程は求めない\n- Lead が Codex exec でレビュー（120s タイムアウト、フォールバック: Reviewer agent）\n- REQUEST_CHANGES → Lead が SendMessage で Worker に修正指示、Worker が amend（最大 `MAX_REVIEWS` 回。`MAX_REVIEWS = read_contract(contract_path, \".review.max_iterations\") or 3`）\n- APPROVE → **Lead** が main に cherry-pick → Plans.md を `cc:完了 [{hash}]` に更新\n\n### 完了報告（Phase C — Lead が生成）\n\n全タスク完了後、**Lead** が以下の手順でリッチ完了報告を生成する:\n\n1. `git log --oneline {base_ref}..HEAD` で全 cherry-pick コミットを収集\n2. `git diff --stat {base_ref}..HEAD` で全体の変更規模を取得\n3. Plans.md の `cc:TODO` \u002F `cc:WIP` 残タスクを抽出\n4. `harness-work` の `Completion Report Output Contract` と `references\u002Fcompletion-report.md` の Breezing テンプレートに従い出力\n\n> **生成者は Lead**。Worker や hook ではない。Lead が Phase C で git + Plans.md を読んで生成する。\n\n### Phase 0: Planning Discussion（構造化 3 問チェック）\n\n全タスク実行前に、スコープ（Q1）・依存関係（Q2、Depends カラムがある時のみ）・リスクフラグ（Q3、`[needs-spike]` がある時のみ）の 3 観点を、原依頼と Plans.md から確認する（合計 30 秒設計）。回答済み事項は聞き直さず、読み取り調査でも解けない判断分岐だけ質問する。時間経過を承認として扱わない。\n`--no-discuss` 指定時は全スキップ。3 問の具体文言と判定ロジックは [references\u002Flean-path-detail.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Flean-path-detail.md) を参照。\n\n### Universal Violations Injection（セッション内 Worker 間の学習伝播）\n\n同一 `\u002Fbreezing` 起動内で蓄積された Reviewer の universal gotchas を次 Worker の briefing 冒頭に自動注入する。**同一セッション内のみ有効**（セッション終了で破棄、`session-memory` には書かない）。実装（in-memory 配列 + briefing 注入コード）は\n[references\u002Fmonitor-and-learning.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fmonitor-and-learning.md) を参照。\n\n### 依存グラフに基づくタスク割り当て\n\nPlans.md に Depends カラムがある場合（v2 フォーマット）、`Depends` が `-` の独立タスクを先に並列 spawn し、各 Worker 完了後に Lead がレビュー→cherry-pick する（harness-work Phase B 参照）。依存元が main に入ったら、それに依存していたタスクを次に実行し、全タスク完了まで繰り返す。逐次処理なのは「Worker 完了→レビュー→cherry-pick」で、並列化できるのは独立タスクの Worker spawn 部分のみ。詳細は [references\u002Flean-path-detail.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Flean-path-detail.md) を参照。\n\n## Codex Native Orchestration\n\nCodex では native subagent を使う。\n代表的な制御面は `spawn_agent`, `wait`, `send_input`, `resume_agent`, `close_agent`。\n\n> **Claude Code vs Codex の通信 API**（SSOT: `team-composition.md` の API マッピング表）:\n> - Claude Code: `SendMessage(to: agentId, message: \"...\")` で Worker に修正指示\n> - Codex: `resume_agent(agent_id)` で Worker を再開 → `send_input(agent_id, \"...\")` で指示送信\n>\n> harness-work の擬似コードは Claude Code 構文で記述。Codex 環境では上記に読み替えること。\n\n## Related Skills\n\n- `harness-work` — 単一タスクからチーム実行まで（本体）\n- `harness-sync` — 進捗同期\n- `harness-review` — コードレビュー（breezing 内で自動起動）\n","# Breezing — Team Execution Mode\n\n> **後方互換エイリアス**: `harness-work` をチーム実行モードで動かします。\n\n## Default Pipeline（plan → work → review → report を 1 コマンドで完走）\n\n`\u002Fbreezing` は「計画 → 実装 → OK が出るまでレビュー → 報告」を 1 回の起動で完走する。\noperator が `\u002Fharness-plan` や `\u002Fharness-review` を個別に指示する必要はない（operator 裁定 2026-07-24）。\n\n1. **Plan gate**: 依頼スコープに対応する task が Plans.md に無い、または不足している場合、先に `harness-plan` を実行して task を生成してから続行する。既に plan がある場合はそのまま Phase 0 へ。plan 生成時のスコープは harness-plan の「スコープ既定: 今進められる全作業」に従う。\n2. **Work**: 既存の Phase 0 → A → B（per-task review 含む）。\n3. **Integrated Review Gate（Phase D、既定 ON）**: Phase B 完了後、**Phase C の最終化（完了報告・run 完了宣言）より前に**、run 全体の diff に `harness-review` を実行する。\n   - review target: 通常 run は `{base_ref}..HEAD`。`--no-commit` run は commit range が空になりうるため、**working tree（未 commit 変更 + untracked ファイル）を対象にする**\n   - fresh-context の独立 reviewer subagent（実装 Worker と会話状態を共有しない）と、`bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fcodex-companion.sh\" review --base \"${base_ref}\"` の second opinion を併走させる\n   - いずれかが REQUEST_CHANGES 相当 → 修正 → 再レビュー。**APPROVE が出るまで反復する**（最大 3 回）。未収束の場合は影響 task の marker を `cc:WIP` に戻し、human escalation で停止して findings と修正状況を報告する\n   - primary verdict（`APPROVE | REQUEST_CHANGES`）は brain（claude host）が出す。role-scoped 制約は維持\n4. **Finalize + Report（Phase C）**: gate の APPROVE を得てから Plans.md 更新・commit・完了報告を確定する。gate 未通過のまま run を「完了」として報告してはならない。最終報告は easy 作法で出す（host session に `easy` skill があれば invoke してその作法に従う。無ければ `harness-work` の Completion Report テンプレート）。\n\n`--reviewer-only` \u002F `--no-commit` 等の既存フラグは、この pipeline の該当段だけを動かす per-run override として働く。\n低リスクの高速 run で Phase D を省きたい時は `--no-review-gate` を渡す（Phase B の per-task review は省かれない。省くのは run 全体 diff への統合レビューだけ）。\n\n### Work Mode Lifecycle (`bin\u002Fharness work-mode`)\n\nR04\u002FR05 の確認 skip が読む `ctx.WorkMode` は、`HARNESS_WORK_MODE` \u002F `ULTRAWORK_MODE` env\n（skill から設定できない）か SQLite `work_states` 行のどちらかで立つ。`bin\u002Fharness work-mode \u003Con|off|status>`\nが後者を書く唯一の入口（`harness-work` の「Work Mode Lifecycle」節が正本）。\n\n- Lead は Plan gate に入る前（run 開始時）に `bin\u002Fharness work-mode on` を実行する。\n  `--codex` run では `bin\u002Fharness work-mode on --codex` を使う（R07 = Lead の直接\n  Write\u002FEdit 禁止が同時に立つ）\n- Lead は run 終了時、**成功・失敗・中断の全経路**で `bin\u002Fharness work-mode off` を実行する\n  （backend が `claude` \u002F `codex` \u002F `cursor` のどれでも同じ規律。cursor fast path の\n  `session declare` \u002F `--clear` と同じ「run 境界で必ず対で呼ぶ」形）\n- run 単位で 1 回のみ。task ごとに on\u002Foff しない\n- session ID が解決できない場合は非ゼロ終了 + 理由が stderr に出る（無言で成功しない）\n\n### Breezing run state (`breezing-active.json`) — guardrail の file producer\n\nLead は run 開始時に `.claude\u002Fstate\u002Fbreezing-active.json` を書く。guardrail は\nこのファイルを R07（codex mode）と R08（reviewer subagent 判定のスコープ）の\nfile producer として読む（`go\u002Finternal\u002Fguardrail\u002Fbreezing_state.go`）:\n\n```json\n{\"impl_mode\": \"codex\", \"started_at\": \"\u003CISO8601>\"}\n```\n\n- `impl_mode` は `--codex` なら `\"codex\"`、それ以外は `\"claude\"` \u002F `\"cursor\"`\n- run 終了時（全経路）にこのファイルを削除する。残すと次の通常セッションでも\n  R07\u002FR08 のスコープ判定が生き続ける\n- reviewer teammate（worktree spawn）には env `HARNESS_BREEZING_ROLE=reviewer` を\n  spawn コマンドの環境に付ける。セッション内 reviewer subagent は CC が付与する\n  `agent_type` で自動判定されるため追加作業は不要\n\n## Narration Rules (UX Contract)\n\n敵は **冗長さ** であって進捗報告ではない。**起動時に実行計画を簡潔に明示してから実行を開始する**。見やすい進捗報告は歓迎する。冗長な繰り返し・中身のない前置きだけを禁ずる。\n\n### 起動時に必ず出すもの (banner + plan、合計 5 行以内)\n\n最初の応答で、何を・どの順で進めるかを示してから tool 実行に入る:\n\n```\n? cursor \u002F composer-2.5-fast \u002F feat\u002Fhah-11-golden-rule-lint \u002F Reviewer\nこれから:\n1. backend\u002Fmodel を resolve\n2. composer に advisory findings を委譲 (read-only)\n3. brain 一次レビューで verdict を確定 → 3-5 行要約 → Plans.md 更新\n```\n\nbanner 1 行 (`? \u003Cbackend> \u002F \u003Cmodel> \u002F \u003Cbranch> \u002F \u003Ctask>`) + 計画 2-4 行。1 秒以内に出し、即 Step 1 へ。\n\n### Backend 既定と per-run のフラット判断（2026-07-24 operator 裁定）\n\n既定 backend は **`claude`（Native subagent）**。resolver の未設定 fallback も `claude` であり、これは罠ではなく意図された既定。\n⚠️ 警告は resolver が **不正値 fallback** の stderr 警告を出した時だけ banner 直後に 1 行で出す（正常に `claude` へ解決された場合は出さない。同一 run 内で繰り返さない）。\n\nLead は run 単位で、作業内容・量からフラットに backend を選んでよい。選ぶ時は resolver への明示 override（`--backend \u003Cv>` \u002F `--codex` \u002F `--cursor`）を使う。env 直読みは引き続き禁止:\n\n| 作業の性質 | 推奨 backend | 理由 |\n|---|---|---|\n| 通常の実装・修正・テスト（既定） | `claude` (native) | Worker 契約（`worker-report.v1` \u002F self_review 5 件）が全部効く |\n| 大規模で独立性の高い一括実装、Claude 側 rate limit 回避 | `codex` | `breezing --codex` の companion が専用の worker route を解決して委譲する。Native Codex は managed custom agent を選択し、deep \u002F review \u002F advisor は各 role の route を維持する |\n| UI 大量生成、lean な高速委譲 | `cursor` | lean path（worktree 隔離 + Lead diff review） |\n\nモデル ID は skill に書かない。`bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fmodel-routing.sh\" --host \u003Cbackend> --role worker` が正本。\nCCH の role 値は未指定時の既定。利用者の明示指定と手動変更を尊重し、AI の推定で再調整せず、親の変更を全 Worker に配らない。native profile と Reviewer の隔離契約を維持する。\n`breezing --codex` の companion 経路だけが `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fmodel-routing.sh\" --host codex --role worker` で\n専用の `worker` route を解決する。`max` が返る場合は\n`codex-companion.sh` が公式 companion 1.0.6 の `--effort max` 非対応を吸収し、\nraw `codex exec` の config override へ正規化する。Worker の write\u002Fsandbox\nintent は保持し、deep \u002F review \u002F advisor の role route を worker に流用しない。\n\nCodex-native Breezing は管理済み `.codex\u002Fagents\u002Fworker.toml` を\n`agent_type: worker` で選択する。model \u002F reasoning は custom agent 側で管理し、\nskill から直接渡さない。bounded `fork_turns: \"3\"` は残してよいが、\n`[agents].default_subagent_*` は全 subagent を retune するため設定しない。\nこの worker role は setup が user の `$CODEX_HOME\u002Fagents\u002Fworker.toml` または\nproject の `.codex\u002Fagents\u002Fworker.toml` にコピーして初めて有効になる。Codex 0.148 の\nplugin manifest は native agent role を登録できず、plugin の install \u002F cache \u002F dist\nへの収録だけでは有効化されない。\n公式の Subagents 設定: https:\u002F\u002Flearn.chatgpt.com\u002Fdocs\u002Fagent-configuration\u002Fsubagents?surface=app\n\n### 進捗報告は出してよい (見やすい範囲で)\n\n- 各ステップの開始・完了を 1 行ステータスで (`✓ backend=cursor \u002F model=composer-2.5-fast`)\n- 判断に必要な中間結果 (pre-check の要点、resolved model、検出した branch 等)\n- なぜこの分岐を取るかの理由を 1 行で (例: 「Reviewer のみ委譲: Worker は別系統で完了済み」)\n\n### 禁止 (= 冗長さ)\n\n- **同じ事実の 2 回言い換え**: 一度言ったことを後段で再説明しない\n- **中身のない前置き**: 「使い方を確認します」だけの行など、tool call で自明な宣言\n- **3 行以上の経緯振り返り**: 結論を引き伸ばす長い前置き。経緯が必要なら 1 行に圧縮\n- **起動シーケンス中の ★ Insight ブロック**: Insight は最終 report で 1 回のみ\n\n## Quick Reference\n\n```bash\n\u002Fbreezing                       # スコープを聞く（claude backend）\n\u002Fbreezing all                   # 全タスク完走（claude backend）\n\u002Fbreezing 3-6                   # タスク3〜6を完走\n\u002Fbreezing --codex all           # Codex CLI で全タスク委託\n\u002Fbreezing --cursor              # cursor backend lean path (--no-discuss all 既定)\n\u002Fbreezing --cursor --reviewer-only  # Reviewer のみ cursor に委譲（Worker は別系統で既完了）\n\u002Fbreezing composer 2.5 all      # 自然言語 trigger: cursor backend として扱う\n\u002Fbreezing --parallel 2 all      # 2並列で全タスク完走\n\u002Fbreezing --no-discuss all      # 計画議論スキップで全タスク完走\n\u002Fbreezing --auto-mode all       # 互換な親セッションで Auto Mode rollout を試す\n```\n\n## Brief Composer v0\n\nargument-hint のどれにも一致しない自由文入力は `bash scripts\u002Fbreezing-brief.sh classify \"\u003Cargs>\"` で `structured` \u002F `free-text` を判定する。\n`free-text` は 3〜7 個の subtasks に分解した `brief-card.v1` カードをユーザーに提示し、`breezing-brief.sh confirm \u003Cyes|no> \u003Ccard.json>` で確定する。\n分解ロジック・schema・`DISPATCH` 契約の詳細は [references\u002Flean-path-detail.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Flean-path-detail.md) を参照。\n\n## Options\n\n| Option | Description | Default |\n|--------|-------------|---------|\n| `all` | 全未完了タスクを対象 | - |\n| `N` or `N-M` | タスク番号\u002F範囲指定 | - |\n| `--codex` | Codex CLI で実装委託 | false |\n| `--cursor` | cursor backend lean path（per-run 明示 override。resolver 出力が `cursor` のときと同等）。Worker 介在 \u002F self_review \u002F sprint-contract 3 段チェーン \u002F Phase 0 を skip し、起動 → 委譲を 3 秒以内に開始する | false |\n| `--reviewer-only` | Reviewer のみ独立系統に委譲（Worker 実装は既完了前提）。`--cursor` と併用で Composer に逃がす | false |\n| `--parallel N` | Implementer 並列数 | auto |\n| `--no-commit` | 自動コミット抑制 | false |\n| `--no-discuss` | 計画議論スキップ | `--cursor` で true 既定 |\n| `--no-review-gate` | Phase D（Integrated Review Gate）をスキップ。Phase B の per-task review は維持 | false |\n| `--auto-mode` | Harness 側の Auto Mode rollout を明示。CC 2.1.111 で不要になった `--enable-auto-mode` とは別物 | false |\n\n### `--parallel N` と CC 側の実キャップ（133.9、一次ソース確証済み）\n\n`--parallel N` は Harness 側の希望値であって、実際に同時に走る数は CC が決める。\n**CC は同時実行中の subagent を既定 20 に制限する**（`CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`、2.1.217）。\n20 を超える N を渡しても超過分は待ち行列に入るだけで、エラーにはならない。\nつまり `--parallel 40` は「40 並列」ではなく「20 並列 + 待ち」になる。\n\n**ネストした spawn は既定で深さ 3 まで**（`CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH`、2.1.219 で 1 → 3 に緩和）。\nLead（深さ 0）→ Worker \u002F Reviewer（1）→ Worker が呼ぶ advisor 等（2）は収まる。\nMode 1 の Producer → Sub-Lead → Composer も 3 段以内。\nこれを超える階層を設計するときは、env で上げない限り**静かに spawn が拒否される**ことを前提にする。\n\nどちらも Harness 側は env を明示設定しない（CC の既定に従う）。変えたい場合は run の env で渡す。\n\n## Natural Language Backend Triggers\n\n`composer` \u002F `コンポーザー` \u002F `Composer で` \u002F `composer 2.5` \u002F `composer モード` は、正式に `cursor backend` の trigger として扱う。\nこれは `--cursor` 相当の intent であり、Lead は `resolve-impl-backend.sh` を経由して backend を確定する。\n解決時は明示 override として `--backend cursor` を渡し、env \u002F project \u002F user file \u002F default より優先させる。\n\n| 入力例 | 解釈 | 実行経路 |\n|---|---|---|\n| `composer 2.5 で` | `cursor backend` | Lead → `cursor-companion.sh task --write --workspace \u003Cwt>` |\n| `コンポーザーで全部` | `cursor backend` | Lead → `cursor-companion.sh task --write --workspace \u003Cwt>` |\n| `composer モード` | `cursor backend` | Lead → `cursor-companion.sh task --write --workspace \u003Cwt>` |\n\n`composer` は Claude Worker の内側に spawn する追加 agent ではない。\n非 `claude` backend のトポロジーに従い、Lead が Worker agent を挟まずに `cursor-companion.sh` を直接呼ぶ。\n\n> **CC 2.1.111 note**:\n> Opus 4.7 では literal に `\u002Feffort xhigh` が使える。\n> built-in `\u002Fultrareview` は明示要求時だけ追加で使い、既定レビューは置き換えない。\n\n> **長時間セッション推奨 (CC 2.1.108+)**:\n> セッション長が 30 分を超える見込みの場合、plugin bundle root 解決後に\n> `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fenable-1h-cache.sh\"` を実行して 1 時間 prompt cache を opt-in すること。\n> このスクリプトは `env.local` に `export ENABLE_PROMPT_CACHING_1H=1` を追記する (冪等)。\n> 5 分 TTL の既定キャッシュでは breezing の 1 時間超セッションで cache miss が累積し\n> input token コストが最大 12 倍になりうるため、長時間 team 実行では明示的に opt-in する。\n> Codex CLI 子プロセス (`scripts\u002Fcodex-companion.sh task --write` 等) は通常 env 継承で\n> `ENABLE_PROMPT_CACHING_1H` を読むが、`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1` が有効な場合は\n> 明示的に export を維持する shell wrapper が必要。詳細は\n> [`docs\u002Flong-running-harness.md`](..\u002F..\u002Fdocs\u002Flong-running-harness.md) を参照。\n\n## Execution\n\n**このスキルは `harness-work` に委譲します。** 以下の設定で `harness-work` を実行してください:\n\n1. **引数をそのまま `harness-work` に渡す**\n2. **チーム実行モードを強制** — Lead → Worker spawn → Reviewer spawn の三者分離\n3. **Lead は delegate 専念** — コードを直接書かず、Worker 実行中は仕様照合、独立した調査、証拠確認、統合準備を進める\n4. **Auto Mode は opt-in 扱い** — `--auto-mode` は互換な親セッションでの rollout 用フラグとして受け付ける\n5. **Advisor は必要時のみ** — Worker が `advisor-request.v1` を返した時だけ Lead が advisor を呼ぶ\n\n委譲本文には原依頼の目的と理由、担当ファイルと除外範囲、DoD、選択した plan \u002F spec、実測や失敗履歴、承認の参照を含める。companion の `\u003Ctask>` も省略しない。\n担当はその境界内で方法を選び、承認済み可逆作業を完了する。軽微な不足は読み取り調査と明示した仮定で補い、仕様や権限の未決事項だけ依存する操作を止める。\n独立して検証できる成果ごとに ownership を分け、ready task と利用可能な同時実行上限の範囲で委譲する。関連 follow-up は同じ担当へ返し、他担当の編集を戻さない。\n実装担当の再利用と、fresh-context の独立 Reviewer を混同しない。必要なレビューとチェックが通ったら、追加の機能や根拠のない再検証を増やさず結果を返す。\n\n### Plan-time 事前確認の扱い\n\nBreezing run 開始時は、Lead が `harness-work` と同じ preapproval preflight を実行する。\n\n- 各 task の開始時、task worktree の `.claude\u002Fstate\u002Factive-task.json` に `{\"phase\":\"\u003Cphase>\",\"task\":\"\u003Ctask>\"}` を原子的に書く。task 終了時は成功、失敗、停止の全経路で削除する。\n- `.claude\u002Fstate\u002Fplan-preapprovals.json` があれば `scripts\u002Fplan-preapproval.sh validate` で v2 を validate する。v1 は既存記録の読み取り互換として受け付ける。\n- 実行対象 task の `decision: approved` 事項だけを宣言済みとして扱い、Worker briefing に渡す。\n- `secret-read` は `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fplan-preapproval.sh\" apply-secret-allow \"$PROJECT_ROOT\"` で project config `.claude-code-harness.config.json` の `runtimefloor.secretAllow` に per-run 反映し、108.2 の project config floor と接続する。\n- R12 の `ask` は、同じ phase\u002Ftask、期限内、使用回数内で、`external-send` と実行コマンドが一致する v2 承認だけが抑制する。明示 `deny` と runtime floor は抑制しない。\n- 宣言済み事項では途中停止せず、work 中の宣言済み事項起因 `AskUserQuestion` はゼロにする。確認は plan 承認時の 1 回のみ。\n- 記録に無い未計画の secret-read \u002F 外部送信 \u002F 破壊的操作は従来どおり runtime floor \u002F ask で停止する。安全網を狭めない。\n\n### `harness-work` との違い\n\n| 特徴 | `harness-work` | `breezing` (このスキル) |\n|------|-----------------|------------------------|\n| 並列手段 | 必要数に応じた自動分割 | **Lead\u002FWorker\u002FReviewer の役割分離** |\n| Lead の役割 | 調整+実装 | **delegate (調整専念)** |\n| レビュー | Lead 自己レビュー | **独立 Reviewer** |\n| デフォルトスコープ | 次のタスク | **全部** |\n\n### Team Composition\n\n| Role | Agent Type | Mode | 責務 |\n|------|-----------|------|------|\n| Lead | (self) | - | 調整・指揮・タスク分配 |\n| Worker ×N | `harness:worker` | `bypassPermissions`（現行） \u002F Auto Mode（follow-up）* | 実装 |\n| Advisor | `harness:advisor` | 読み取り専用 | 方針助言 (`PLAN` \u002F `CORRECTION` \u002F `STOP`) |\n| Reviewer | `harness:reviewer` | `bypassPermissions`（現行） \u002F Auto Mode（follow-up）* | 独立レビュー |\n\n> *親セッションまたは frontmatter が `bypassPermissions` の場合はそちらが優先される。配布テンプレートは現在も `bypassPermissions` を使うため、Auto Mode は follow-up の rollout 対象であり、既定挙動ではない。\n\n### Mode 1 — Sub-Lead 階層と review→iterate（opt-in）\n\nGo orchestrator 経路（`harness work --team`）の **Producer → Sub-Lead → Composer** は、`HARNESS_TEAM_HIERARCHY=sublead` の CLI mini-plan 入口が未実装のため未対応。この更新では有効化せず、通常は既定の flat で実行する。\nこれは Go の opt-in 入口の制約であり、Lead が手動で担当を分解する Producer トポロジーを無効にするものではない。\n\nGo の `HARNESS_REVIEW_ITERATE=on` も、production brain runner が要求する `claude-companion.sh` が未提供のため end-to-end 未対応。この更新で有効化せず既定 OFF を維持する。\n通常の Skill \u002F Native reviewer loop は別経路であり、既定の review gate と反復上限を維持する。Go opt-in の設計境界は `harness-work` の `references\u002Fbackend-selection.md` を参照する。\n\n- If you grep the same symbol twice in the same session, switch to harness_ast_search.\n- For a bugfix where homologous implementations appear across multiple modules, run harness_ast_search to find all implementations before editing.\n- 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.\n\n### Codex Mode (`--codex`)\n\n公式プラグイン `codex-plugin-cc` 経由で Codex CLI にすべての実装を委託するモード:\n\nこの `--codex` は companion 経路であり、専用 `worker` route を解決して実装を委託する。\n公式 companion 1.0.6 が `--effort max` を拒否するため、router が `max` を返す場合は\nHarness の `codex-companion.sh` が raw `codex exec` の config override へ変換する。\nレビュー・助言・deep 判断は、それぞれの role-scoped route を使う。Native Codex\nBreezing の managed custom-agent 選択とは別経路である。\n\n```bash\n# タスク委託（書き込み可能）\nCODEX_MODEL_TIER=worker bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fcodex-companion.sh\" task --write \"タスク内容\"\n\n# stdin 経由（大きなプロンプト向け）\nCODEX_PROMPT=$(mktemp \u002Ftmp\u002Fcodex-prompt-XXXXXX.md)\n# タスク内容を書き出し\ncat \"$CODEX_PROMPT\" | CODEX_MODEL_TIER=worker bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fcodex-companion.sh\" task --write\nrm -f \"$CODEX_PROMPT\"\n```\n\n### Execution Backend (persistent)\n\nbackend 判定は **必ず resolver 経由**。`HARNESS_IMPL_BACKEND` env を直接読んで backend を決めてはならない。\nenv \u002F `--cursor` per-run flag \u002F project `env.local` \u002F user file を\n`bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fresolve-impl-backend.sh\"` で precedence 解決し、その出力を backend として使う\n（env unset でも project \u002F user file から拾える）。永続 default を変えたい場合は\n`bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fset-impl-backend.sh\" \u003Cclaude|codex|cursor> [--user]` で project \u002F user file に書き込み、\nrun 開始時に resolver が解決する（現行の operator 既定はユーザースコープで `claude`）。review \u002F advisor ロールは brain に固定したまま。\nバックエンド選択の正本（precedence、role-scope、self_review スキップ、cursor banner）は\n`harness-work` の「Execution Backend Selection（実装バックエンド選択）」を参照する。\n\n下の Cursor Backend Fast Path は per-run フラグ (`--cursor`) を resolver への明示 override として lean path を有効化する別軸であり、本節と併読する。\n\n### Cursor Backend Fast Path (`--cursor` \u002F lean mode)\n\n`bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fresolve-impl-backend.sh\"` の出力が `cursor` のときに有効\n（`--cursor` は resolver への明示 override として precedence 最上位）。Worker 層を介在させず Lead が直接 `cursor-companion.sh` を呼ぶ（Phase 85 SSOT、`.claude\u002Frules\u002Fcursor-cli-only.md` Topology 節）。\n\ncursor backend は Worker agent spawn \u002F self_review 5 件ゲート \u002F sprint-contract 3 段チェーン \u002F Phase 0 interactive \u002F effort スコアリングを省略し、baseline `15-35s` → target `3-7s` で 1 タスク目の委譲を開始する。節約内訳の全表は\n[references\u002Flean-path-detail.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Flean-path-detail.md) を参照。\n\n#### 既定 flow（cursor backend）\n\n1. **banner + 実行計画** (`? cursor \u002F \u003Cmodel> \u002F \u003Cbranch> \u002F \u003Ctask>` + これから進める 2-4 step、合計 5 行以内、1 秒以内)\n   - run 全体で 1 回だけ、まだ実行していなければ `bin\u002Fharness work-mode on`（R04\u002FR05 の確認 skip を有効化。詳細は「Work Mode Lifecycle」節）\n2. **1 bash で並列 pre-check**: `git branch --show-current` + `cat VERSION` + `Plans.md tail` + `cursor-agent --version`\n3. **1 bash で resolve**: `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fresolve-impl-backend.sh\"` + `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fmodel-routing.sh\" --host cursor --role worker --field model`\n4. **即 委譲**: `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fcursor-companion.sh\" task --write --workspace \u003Cwt> \"\u003Ctask>\"`\n   - 委譲開始時に `bin\u002Fharness session declare --task \u003Ctask-id>` で共有 presence に作業宣言（他セッションから task 番号で逆引き可能になる）\n5. cursor 出力を Lead が diff レビュー → cherry-pick → Plans.md `cc:done [hash]` 更新\n   - 更新後 `bin\u002Fharness session declare --clear` で presence の task 宣言を解除\n   - run 全体が終わる時（成功・失敗・中断いずれでも）は `bin\u002Fharness work-mode off` を忘れない\n\n#### Reviewer-only mode (`--cursor --reviewer-only`) — read = lean\n\nWorker 実装は既完了（別系統 = claude \u002F Codex で済んだ）、advisory pre-review を Composer に出してもらう lean path。read-only 委譲なので **worktree 不要・cherry-pick 不要・cursor 出力の取り込みレビュー不要**（cursor は新たな diff を生まないため）。ただし対象 diff への **brain 一次レビュー（primary verdict）は省略しない**:\n\n1. banner + 計画: `? cursor \u002F composer-2.5-fast \u002F review` + 「これから: composer に advisory findings を委譲 → brain 一次レビューで verdict 確定」\n2. `bash \"${HARNESS_PLUGIN_ROOT}\u002Fscripts\u002Fcursor-companion.sh\" task \"diff レビュー: \u003Cbase_ref>..HEAD\"` — **`--write` も `--workspace` も付けない**\n   - companion は `--write` 未指定で default `--mode ask` (hard read-only stop) になる (cursor-companion.sh の workspace guard は `--write` 時のみ発火)\n   - cursor 側はファイル書込・コマンド実行が disabled、worktree 隔離不要\n3. cursor 出力 (REQUEST_CHANGES \u002F APPROVE 相当) を Lead が解釈し、`dual_review.cursor_verdict` に advisory として格納\n4. **primary verdict は brain reviewer から取る**。cursor 単独では APPROVE を確定しない (spec.md Execution Backend Contract の self-review scope 契約 = 「diff を生成した同一コンテキストは自分の出力をレビューしない」と整合)。この lean path 自体が fresh-context advisory pre-review であり、委譲先 cursor session は実装 worker と会話状態を共有しないこと\n5. **brain 一次レビュー**: Lead が cursor advisory findings を入力として対象 diff を自ら検分し、verdict（`APPROVE | REQUEST_CHANGES`）を出す。brain reviewer が利用不能（rate limit 等）の間は verdict を確定せず、タスクを `cc:wip` のままユーザー判断へ渡す（cursor advisory のみで `cc:done` にしない）\n6. brain の APPROVE 後に Plans.md `cc:done [hash]` を Lead が更新\n\nread mode で省略できるもの: 専用 `.git` worktree \u002F cursor 出力の取り込みレビュー \u002F cherry-pick \u002F `worker-report.v1` \u002F self_review 5 件。**省略不可**: 対象 diff への brain 一次レビュー（verdict 確定）。\nread mode でも保持必要: `.cursorignore` \u002F egress allowlist (`*.cursor.sh`) \u002F permissions.json (best-effort)。詳細は `.claude\u002Frules\u002Fcursor-cli-only.md` 「Read mode delegation (lean path)」節を参照。\n\n**用途**（rate limit 時の前倒し集約 \u002F Reviewer だけ別系統に分散 \u002F Codex review auth 失敗時の fallback、詳細は [references\u002Flean-path-detail.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Flean-path-detail.md)）。\n\n#### Cursor adapter support claim\n\nCursor は `supported` tier（H8 pin: live H4 2026-07-17 + H7 release-preflight fail-closed）。FS jail なし — containment は harness-side（`docs\u002FCURSOR_INTEGRATION.md`）。`--cursor` lean path 自体は tier を昇格させない。\n\nBootstrap route: `.cursor\u002FAGENTS.md` + `.cursor-plugin\u002Fplugin.json`。\n\nVerification:\n\n```bash\nbash tests\u002Ftest-cursor-adapter-candidate.sh\nbash tests\u002Ftest-support-claim-wording.sh\n```\n\n## Flow Summary\n\n```\nbreezing [scope] [--codex] [--parallel N] [--no-discuss] [--auto-mode]\n    │\n    ↓ Load harness-work with team mode\n    │\nPhase 0: Planning Discussion (--no-discuss でスキップ)\nPhase A: Pre-delegate（チーム初期化）\nPhase B: Delegate（Worker 実装 + 必要時 Advisor + Reviewer レビュー）\nPhase C: Post-delegate（統合検証 + Plans.md 更新 + commit）\n```\n\n## Advisor Protocol\n\nWorker は generic な subagent を増やさない。\n迷った時は構造化 JSON で相談要求だけ返し、Lead が advisor を呼ぶ。\n\n1. Worker → `advisor-request.v1`\n2. Lead → Advisor\n3. Advisor → `advisor-response.v1`\n4. Lead → 同じ Worker に advice を返して続行\n5. Reviewer は最後の成果物だけを見る\n\n相談条件は loop \u002F solo とそろえる。\n\n- 高リスク task（`needs-spike` \u002F `security-sensitive` \u002F `state-migration`）の初回実行前\n- 同じ原因の失敗が 2 回続いた後\n- plateau により `PIVOT_REQUIRED` を返す直前\n- 同じ `trigger_hash` は 1 回だけ。task ごとの相談回数は最大 3 回\n\n### Progress Feed（Phase B 中の進捗通知）\n\nLead は Worker のタスク完了ごとに、以下のフォーマットで進捗を出力する:\n\n```\n? Progress: Task {completed}\u002F{total} 完了 — \"{task_subject}\"\n```\n\n**出力例**:\n```\n? Progress: Task 1\u002F5 完了 — \"harness-work に失敗再チケット化を追加\"\n? Progress: Task 2\u002F5 完了 — \"harness-sync に --snapshot を追加\"\n? Progress: Task 3\u002F5 完了 — \"breezing にプログレスフィードを追加\"\n```\n\n> **設計意図**: breezing は長時間実行になることが多い。\n> ユーザーがターミナルをチラ見した時に「今どこまで進んでいるか」が一目で分かるようにする。\n> task-completed.sh フックが systemMessage で同等の情報を出力するため、Lead の出力と補完し合う。\n\n### Silence Policy（長時間実行の通知整理）\n\nCodex `0.123.0` の realtime handoff では、background agent が transcript delta を受け取り、必要ない時は明示的に沈黙できる。\nBreezing の progress feed はこの前提に合わせ、通知を「作業の節目」に絞る。\n\n報告するもの:\n\n- task 完了、blocked、validation failure、review `REQUEST_CHANGES`\n- Advisor の `PLAN` \u002F `CORRECTION` \u002F `STOP`\n- Reviewer の `APPROVE` \u002F `REQUEST_CHANGES`\n- advisor \u002F reviewer drift、plateau、contract readiness failure\n- user が明示的に status を求めた時の要約\n\n沈黙してよいもの:\n\n- transcript delta を受け取っただけで、判定や status が変わっていない時\n- tool stdout の細かな増分で、log に残っていれば十分な時\n- 並列 Worker の待機中 heartbeat\n\n頻度は「task 完了ごとに 1 回」を基本にする。\nheartbeat を増やして安心感を作るのではなく、status \u002F log \u002F drift 検知に責務を分ける。\nただし Advisor request 未応答、Reviewer result 未到着、plateau 直前の警告は silence 対象にしない。\n\n### Monitor ツール活用ガイド (CC 2.1.98+)\n\n`run_in_background: true` で投げた長時間 shell process（`gh run watch`、build --watch 等）は、ポーリングではなく **Monitor ツール**で stdout を逐次通知として拾う。Agent (Worker\u002FReviewer) の完了監視や短時間の一発コマンドには不要。\n使い分け表・典型パターンは [references\u002Fmonitor-and-learning.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fmonitor-and-learning.md) を参照。\n\n### 自主停止の禁止 (140.3、2026-08-22 の release run で 2 回発生した停止パターンの再発防止)\n\n以下は禁止行動。literal に列挙する (AUTOSTART pattern と同じ方式):\n\n- background 待ちで turn を終えて停止しない (turn を終えると background 子プロセスは残らない)\n- 「検証を待ちます」「確認します」「完了を待機します」で turn を終えない\n- 待つなら同期実行 (foreground \u002F Monitor) で待ち切る。待てないものは保留として報告し、次のタスクへ進む\n\n### Review Policy（全モード統一）\n\nBreezing モードでもレビューは **Codex exec 優先 → 内部 Reviewer フォールバック** の統一ポリシーに従う。\n詳細は `harness-work` の「レビューループ」セクションを参照。\n\n- Worker が worktree 内で実装・commit → `worker-report.v1` (self_review 5 件) を Lead に返却\n- **self_review ゲート (Reviewer spawn 前)**: Lead が `self_review[].verified` と `evidence` を機械検証。1 件でも `verified:false` or `evidence:\"\"` なら Reviewer を spawn せず Worker に自動差し戻し（同一セッション内 最大 2 回、3 回目で escalate）\n- `verified:true` や非空の文章だけを実証と扱わず、参照先の差分、失敗出力、必須チェック結果を照合する。判断理由と証拠を求め、内部の思考過程は求めない\n- Lead が Codex exec でレビュー（120s タイムアウト、フォールバック: Reviewer agent）\n- REQUEST_CHANGES → Lead が SendMessage で Worker に修正指示、Worker が amend（最大 `MAX_REVIEWS` 回。`MAX_REVIEWS = read_contract(contract_path, \".review.max_iterations\") or 3`）\n- APPROVE → **Lead** が main に cherry-pick → Plans.md を `cc:完了 [{hash}]` に更新\n\n### 完了報告（Phase C — Lead が生成）\n\n全タスク完了後、**Lead** が以下の手順でリッチ完了報告を生成する:\n\n1. `git log --oneline {base_ref}..HEAD` で全 cherry-pick コミットを収集\n2. `git diff --stat {base_ref}..HEAD` で全体の変更規模を取得\n3. Plans.md の `cc:TODO` \u002F `cc:WIP` 残タスクを抽出\n4. `harness-work` の `Completion Report Output Contract` と `references\u002Fcompletion-report.md` の Breezing テンプレートに従い出力\n\n> **生成者は Lead**。Worker や hook ではない。Lead が Phase C で git + Plans.md を読んで生成する。\n\n### Phase 0: Planning Discussion（構造化 3 問チェック）\n\n全タスク実行前に、スコープ（Q1）・依存関係（Q2、Depends カラムがある時のみ）・リスクフラグ（Q3、`[needs-spike]` がある時のみ）の 3 観点を、原依頼と Plans.md から確認する（合計 30 秒設計）。回答済み事項は聞き直さず、読み取り調査でも解けない判断分岐だけ質問する。時間経過を承認として扱わない。\n`--no-discuss` 指定時は全スキップ。3 問の具体文言と判定ロジックは [references\u002Flean-path-detail.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Flean-path-detail.md) を参照。\n\n### Universal Violations Injection（セッション内 Worker 間の学習伝播）\n\n同一 `\u002Fbreezing` 起動内で蓄積された Reviewer の universal gotchas を次 Worker の briefing 冒頭に自動注入する。**同一セッション内のみ有効**（セッション終了で破棄、`session-memory` には書かない）。実装（in-memory 配列 + briefing 注入コード）は\n[references\u002Fmonitor-and-learning.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Fmonitor-and-learning.md) を参照。\n\n### 依存グラフに基づくタスク割り当て\n\nPlans.md に Depends カラムがある場合（v2 フォーマット）、`Depends` が `-` の独立タスクを先に並列 spawn し、各 Worker 完了後に Lead がレビュー→cherry-pick する（harness-work Phase B 参照）。依存元が main に入ったら、それに依存していたタスクを次に実行し、全タスク完了まで繰り返す。逐次処理なのは「Worker 完了→レビュー→cherry-pick」で、並列化できるのは独立タスクの Worker spawn 部分のみ。詳細は [references\u002Flean-path-detail.md](${CLAUDE_SKILL_DIR}\u002Freferences\u002Flean-path-detail.md) を参照。\n\n## Codex Native Orchestration\n\nCodex では native subagent を使う。\n代表的な制御面は `spawn_agent`, `wait`, `send_input`, `resume_agent`, `close_agent`。\n\n> **Claude Code vs Codex の通信 API**（SSOT: `team-composition.md` の API マッピング表）:\n> - Claude Code: `SendMessage(to: agentId, message: \"...\")` で Worker に修正指示\n> - Codex: `resume_agent(agent_id)` で Worker を再開 → `send_input(agent_id, \"...\")` で指示送信\n>\n> harness-work の擬似コードは Claude Code 構文で記述。Codex 環境では上記に読み替えること。\n\n## Related Skills\n\n- `harness-work` — 単一タスクからチーム実行まで（本体）\n- `harness-sync` — 進捗同期\n- `harness-review` — コードレビュー（breezing 内で自動起動）\n",{"name":5,"description":7},"main","c2304c325d4432f51d632e0586d886767b0f41ea","opencode\u002Fskills\u002Fbreezing",305,"https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness","https:\u002F\u002Fgithub.com\u002FChachamaru127","https:\u002F\u002Fcanai.jp\u002F","Going all-in on the AI business from April 2025\r\nOSS release: 3k Stars\r\nAI adoption starting with \"I want\"\r\nAX Support | Tokenomics | AISDR |","2026-11-11 17:18:34",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add Chachamaru127\u002Fclaude-code-harness --skill breezing",{"tool":59,"command":60},"bunx","bunx skills add Chachamaru127\u002Fclaude-code-harness --skill breezing",{"tool":62,"command":63},"pnpm","pnpm dlx skills add Chachamaru127\u002Fclaude-code-harness --skill breezing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fopencode\u002Fskills\u002Fbreezing\u002FSKILL.md",true,[67,73],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Flean-path-detail.md","REFERENCE","参考文档",5258,"https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fopencode\u002Fskills\u002Fbreezing\u002Freferences\u002Flean-path-detail.md",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fmonitor-and-learning.md",3755,"https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fopencode\u002Fskills\u002Fbreezing\u002Freferences\u002Fmonitor-and-learning.md",[78,94,103,122,150,176],{"skillNo":79,"name":80,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":86,"publishedAt":39},"01M6C4VZCJB9EN3KZXGNARAF6P","escape-skill","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fzz-review-escape\u002FSKILL.md",[83],{"categoryNo":84,"categoryName":85,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[87,88,89,90,91,92,93],"escape skill","escape","Tools","false","true","path","quoted",{"skillNo":95,"name":96,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":39},"01M6C4VYAJW332S5R2MM3RNE0G","zz-review-empty","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fzz-review-empty\u002FSKILL.md",[],[100,101,102,90,91],"review","zz review empty","empty",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":110,"publishedAt":39},"01M6C4VWW4GNAZ2680GY04S3EW","session-send","This skill should be used when the user asks to notify other session, requests a session handoff, says tell other agent, or needs a cross-session message.","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fskills\u002Fsession-send\u002FSKILL.md",[109],{"categoryNo":84,"categoryName":85,"taxonomyType":21,"taxonomyTypeDesc":22},[111,112,113,114,115,116,117,118,119,120,121],"session","session send","send","handoff","session handoff","Bash","user","message","notify","requests","when",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":39},"01M6C4VSMYH6XQGR087HQ9Y7HT","memory","Manage SSOT, memory, and cross-tool memory search. Guardian of decisions.md and patterns.md. Use when user mentions memory, SSOT, decisions.md, patterns.md, merging, migration, SSOT promotion, sync memory, save learnings, memory search, harness-mem, past decisions, or record this. Do NOT load for: implementation work, reviews, ad-hoc notes, or in-session logging.","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fskills\u002Fmemory\u002FSKILL.md",[128],{"categoryNo":84,"categoryName":85,"taxonomyType":21,"taxonomyTypeDesc":22},[124,130,131,132,25,133,134,135,116,136,137,28,138,139,140,141,117,111,142,143,144,145,146,147,148,91,149,38,121],"MCP","sync","notes","search","memory search","guardian","migrate","tool","decisions","read","write","edit","use","migration","manage","do","learnings","promotion","reviews","load",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":39},"01M6C4VQ3507BV9XRX4BDSES6J","maintenance","File cleanup and archiving. Tidies up bloated Plans.md, session-log.md, old logs, and state files. Trigger: \u002Fmaintenance, cleanup, archive, organize, split session-log. Do NOT load for: implementation, review, release, new feature development.","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fskills\u002Fmaintenance\u002FSKILL.md",[],[152,100,157,158,159,160,161,162,163,116,164,165,139,140,141,166,111,167,168,169,145,170,171,172,173,174,91,149,38,175],"development","cleanup","run","release","state","file","logs","archive","grep","new feature","up","log","files","feature","plans","trigger","整理","split","new",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":194,"publishedAt":39},"01M6C4VK473YJ872RNMBYK7P4R","japanese-writing-drafter","Detect when the operator corrects the agent's Japanese phrasing mid-conversation (rewrites a sentence, calls out a style problem, says 'this wording is bad, say it like X instead') and draft a pending writing-rule proposal into ~\u002F.claude\u002Fwriting-lint\u002Fproposals.jsonl for later human review. This skill is the ONLY writer of proposals.jsonl — it never edits rules.jsonl and never sets status to anything but pending. Promotion to rules.jsonl only happens via the human-run scripts\u002Fwriting-rule-approve.sh. Use when user mentions writing-rule proposal, 表現を直して, 文体を直して, その言い方はNG, writing lint 提案, 指摘をルール化して. Do NOT load for: approving or rejecting proposals (use scripts\u002Fwriting-rule-approve.sh), listing pending proposals (use scripts\u002Fwriting-rule-list.sh), or scanning text against the existing dictionary (the writinglint engine \u002F PostToolUse hook does that).","https:\u002F\u002Fgithub.com\u002FChachamaru127\u002Fclaude-code-harness\u002Fblob\u002Fmain\u002Fskills\u002Fjapanese-writing-drafter\u002FSKILL.md",[182,185,188,189],{"categoryNo":183,"categoryName":184,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":186,"categoryName":187,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":84,"categoryName":85,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":190,"categoryName":191,"taxonomyType":192,"taxonomyTypeDesc":193},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[195,196,197,100,198,159,199,200,116,201,202,203,204,139,205,206,142,207,208,209,210,211,212,213,214,215,216,217,218,219,121,220],"writing","japanese writing drafter","japanese","status","lint","operator","提案","text","engine","Rules","list","proposals","never","only","scanning","say","human review","later","conversation","writer","human","scripts","problem","proposal","jsonl","listing"]