Breezing

Breezing — Team Execution Mode

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

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

/breezing は「計画 → 実装 → OK が出るまでレビュー → 報告」を 1 回の起動で完走する。 operator が /harness-plan や /harness-review を個別に指示する必要はない（operator 裁定 2026-07-24）。

1. Plan gate: 依頼スコープに対応する task が Plans.md に無い、または不足している場合、先に harness-plan を実行して task を生成してから続行する。既に plan がある場合はそのまま Phase 0 へ。plan 生成時のスコープは harness-plan の「スコープ既定: 今進められる全作業」に従う。
2. Work: 既存の Phase 0 → A → B（per-task review 含む）。
3. Integrated Review Gate（Phase D、既定 ON）: Phase B 完了後、Phase C の最終化（完了報告・run 完了宣言）より前に、run 全体の diff に harness-review を実行する。
   • review target: 通常 run は {base_ref}..HEAD。--no-commit run は commit range が空になりうるため、working tree（未 commit 変更 + untracked ファイル）を対象にする
   • fresh-context の独立 reviewer subagent（実装 Worker と会話状態を共有しない）と、bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" review --base "${base_ref}" の second opinion を併走させる
   • いずれかが REQUEST_CHANGES 相当 → 修正 → 再レビュー。APPROVE が出るまで反復する（最大 3 回）。未収束の場合は影響 task の marker を cc:WIP に戻し、human escalation で停止して findings と修正状況を報告する
   • primary verdict（APPROVE | REQUEST_CHANGES）は brain（claude host）が出す。role-scoped 制約は維持
4. Finalize + Report（Phase C）: gate の APPROVE を得てから Plans.md 更新・commit・完了報告を確定する。gate 未通過のまま run を「完了」として報告してはならない。最終報告は easy 作法で出す（host session に easy skill があれば invoke してその作法に従う。無ければ harness-work の Completion Report テンプレート）。

--reviewer-only / --no-commit 等の既存フラグは、この pipeline の該当段だけを動かす per-run override として働く。 低リスクの高速 run で Phase D を省きたい時は --no-review-gate を渡す（Phase B の per-task review は省かれない。省くのは run 全体 diff への統合レビューだけ）。

Work Mode Lifecycle (bin/harness work-mode)

R04/R05 の確認 skip が読む ctx.WorkMode は、HARNESS_WORK_MODE / ULTRAWORK_MODE env （skill から設定できない）か SQLite work_states 行のどちらかで立つ。bin/harness work-mode <on|off|status> が後者を書く唯一の入口（harness-work の「Work Mode Lifecycle」節が正本）。

• Lead は Plan gate に入る前（run 開始時）に bin/harness work-mode on を実行する。 --codex run では bin/harness work-mode on --codex を使う（R07 = Lead の直接 Write/Edit 禁止が同時に立つ）
• Lead は run 終了時、成功・失敗・中断の全経路で bin/harness work-mode off を実行する （backend が claude / codex / cursor のどれでも同じ規律。cursor fast path の session declare / --clear と同じ「run 境界で必ず対で呼ぶ」形）
• run 単位で 1 回のみ。task ごとに on/off しない
• session ID が解決できない場合は非ゼロ終了 + 理由が stderr に出る（無言で成功しない）

Breezing run state (breezing-active.json) — guardrail の file producer

Lead は run 開始時に .claude/state/breezing-active.json を書く。guardrail は このファイルを R07（codex mode）と R08（reviewer subagent 判定のスコープ）の file producer として読む（go/internal/guardrail/breezing_state.go）:

{"impl_mode": "codex", "started_at": "<ISO8601>"}

• impl_mode は --codex なら "codex"、それ以外は "claude" / "cursor"
• run 終了時（全経路）にこのファイルを削除する。残すと次の通常セッションでも R07/R08 のスコープ判定が生き続ける
• reviewer teammate（worktree spawn）には env HARNESS_BREEZING_ROLE=reviewer を spawn コマンドの環境に付ける。セッション内 reviewer subagent は CC が付与する agent_type で自動判定されるため追加作業は不要

Narration Rules (UX Contract)

敵は 冗長さ であって進捗報告ではない。起動時に実行計画を簡潔に明示してから実行を開始する。見やすい進捗報告は歓迎する。冗長な繰り返し・中身のない前置きだけを禁ずる。

起動時に必ず出すもの (banner + plan、合計 5 行以内)

最初の応答で、何を・どの順で進めるかを示してから tool 実行に入る:

🚀 cursor / composer-2.5-fast / feat/hah-11-golden-rule-lint / Reviewer
これから:
1. backend/model を resolve
2. composer に advisory findings を委譲 (read-only)
3. brain 一次レビューで verdict を確定 → 3-5 行要約 → Plans.md 更新

banner 1 行 (🚀 <backend> / <model> / <branch> / <task>) + 計画 2-4 行。1 秒以内に出し、即 Step 1 へ。

Backend 既定と per-run のフラット判断（2026-07-24 operator 裁定）

既定 backend は claude（Native subagent）。resolver の未設定 fallback も claude であり、これは罠ではなく意図された既定。 ⚠️ 警告は resolver が 不正値 fallback の stderr 警告を出した時だけ banner 直後に 1 行で出す（正常に claude へ解決された場合は出さない。同一 run 内で繰り返さない）。

Lead は run 単位で、作業内容・量からフラットに backend を選んでよい。選ぶ時は resolver への明示 override（--backend <v> / --codex / --cursor）を使う。env 直読みは引き続き禁止:

モデル ID は skill に書かない。bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host <backend> --role worker が正本。 CCH の role 値は未指定時の既定。利用者の明示指定と手動変更を尊重し、AI の推定で再調整せず、親の変更を全 Worker に配らない。native profile と Reviewer の隔離契約を維持する。 breezing --codex の companion 経路だけが bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host codex --role worker で 専用の worker route を解決する。max が返る場合は codex-companion.sh が公式 companion 1.0.6 の --effort max 非対応を吸収し、 raw codex exec の config override へ正規化する。Worker の write/sandbox intent は保持し、deep / review / advisor の role route を worker に流用しない。

Codex-native Breezing は管理済み .codex/agents/worker.toml を agent_type: worker で選択する。model / reasoning は custom agent 側で管理し、 skill から直接渡さない。bounded fork_turns: "3" は残してよいが、 [agents].default_subagent_* は全 subagent を retune するため設定しない。 この worker role は setup が user の $CODEX_HOME/agents/worker.toml または project の .codex/agents/worker.toml にコピーして初めて有効になる。Codex 0.148 の plugin manifest は native agent role を登録できず、plugin の install / cache / dist への収録だけでは有効化されない。 公式の Subagents 設定: https://learn.chatgpt.com/docs/agent-configuration/subagents?surface=app

進捗報告は出してよい (見やすい範囲で)

• 各ステップの開始・完了を 1 行ステータスで (✓ backend=cursor / model=composer-2.5-fast)
• 判断に必要な中間結果 (pre-check の要点、resolved model、検出した branch 等)
• なぜこの分岐を取るかの理由を 1 行で (例: 「Reviewer のみ委譲: Worker は別系統で完了済み」)

禁止 (= 冗長さ)

• 同じ事実の 2 回言い換え: 一度言ったことを後段で再説明しない
• 中身のない前置き: 「使い方を確認します」だけの行など、tool call で自明な宣言
• 3 行以上の経緯振り返り: 結論を引き伸ばす長い前置き。経緯が必要なら 1 行に圧縮
• 起動シーケンス中の ★ Insight ブロック: Insight は最終 report で 1 回のみ

Quick Reference

/breezing                       # スコープを聞く（claude backend）
/breezing all                   # 全タスク完走（claude backend）
/breezing 3-6                   # タスク3〜6を完走
/breezing --codex all           # Codex CLI で全タスク委託
/breezing --cursor              # cursor backend lean path (--no-discuss all 既定)
/breezing --cursor --reviewer-only  # Reviewer のみ cursor に委譲（Worker は別系統で既完了）
/breezing composer 2.5 all      # 自然言語 trigger: cursor backend として扱う
/breezing --parallel 2 all      # 2並列で全タスク完走
/breezing --no-discuss all      # 計画議論スキップで全タスク完走
/breezing --auto-mode all       # 互換な親セッションで Auto Mode rollout を試す

Brief Composer v0

argument-hint のどれにも一致しない自由文入力は bash scripts/breezing-brief.sh classify "<args>" で structured / free-text を判定する。 free-text は 3〜7 個の subtasks に分解した brief-card.v1 カードをユーザーに提示し、breezing-brief.sh confirm <yes|no> <card.json> で確定する。 分解ロジック・schema・DISPATCH 契約の詳細は references/lean-path-detail.md を参照。

Options

--parallel N と CC 側の実キャップ（133.9、一次ソース確証済み）

--parallel N は Harness 側の希望値であって、実際に同時に走る数は CC が決める。 CC は同時実行中の subagent を既定 20 に制限する（CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS、2.1.217）。 20 を超える N を渡しても超過分は待ち行列に入るだけで、エラーにはならない。 つまり --parallel 40 は「40 並列」ではなく「20 並列 + 待ち」になる。

ネストした spawn は既定で深さ 3 まで（CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH、2.1.219 で 1 → 3 に緩和）。 Lead（深さ 0）→ Worker / Reviewer（1）→ Worker が呼ぶ advisor 等（2）は収まる。 Mode 1 の Producer → Sub-Lead → Composer も 3 段以内。 これを超える階層を設計するときは、env で上げない限り静かに spawn が拒否されることを前提にする。

どちらも Harness 側は env を明示設定しない（CC の既定に従う）。変えたい場合は run の env で渡す。

Natural Language Backend Triggers

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 は Claude Worker の内側に spawn する追加 agent ではない。 非 claude backend のトポロジーに従い、Lead が Worker agent を挟まずに cursor-companion.sh を直接呼ぶ。

CC 2.1.111 note: Opus 4.7 では literal に /effort xhigh が使える。 built-in /ultrareview は明示要求時だけ追加で使い、既定レビューは置き換えない。

長時間セッション推奨 (CC 2.1.108+): セッション長が 30 分を超える見込みの場合、plugin bundle root 解決後に bash "${HARNESS_PLUGIN_ROOT}/scripts/enable-1h-cache.sh" を実行して 1 時間 prompt cache を opt-in すること。 このスクリプトは env.local に export ENABLE_PROMPT_CACHING_1H=1 を追記する (冪等)。 5 分 TTL の既定キャッシュでは breezing の 1 時間超セッションで cache miss が累積し input token コストが最大 12 倍になりうるため、長時間 team 実行では明示的に opt-in する。 Codex CLI 子プロセス (scripts/codex-companion.sh task --write 等) は通常 env 継承で ENABLE_PROMPT_CACHING_1H を読むが、CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 が有効な場合は 明示的に export を維持する shell wrapper が必要。詳細は docs/long-running-harness.md を参照。

Execution

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

1. 引数をそのまま harness-work に渡す
2. チーム実行モードを強制 — Lead → Worker spawn → Reviewer spawn の三者分離
3. Lead は delegate 専念 — コードを直接書かず、Worker 実行中は仕様照合、独立した調査、証拠確認、統合準備を進める
4. Auto Mode は opt-in 扱い — --auto-mode は互換な親セッションでの rollout 用フラグとして受け付ける
5. Advisor は必要時のみ — Worker が advisor-request.v1 を返した時だけ Lead が advisor を呼ぶ

委譲本文には原依頼の目的と理由、担当ファイルと除外範囲、DoD、選択した plan / spec、実測や失敗履歴、承認の参照を含める。companion の <task> も省略しない。 担当はその境界内で方法を選び、承認済み可逆作業を完了する。軽微な不足は読み取り調査と明示した仮定で補い、仕様や権限の未決事項だけ依存する操作を止める。 独立して検証できる成果ごとに ownership を分け、ready task と利用可能な同時実行上限の範囲で委譲する。関連 follow-up は同じ担当へ返し、他担当の編集を戻さない。 実装担当の再利用と、fresh-context の独立 Reviewer を混同しない。必要なレビューとチェックが通ったら、追加の機能や根拠のない再検証を増やさず結果を返す。

Plan-time 事前確認の扱い

Breezing run 開始時は、Lead が harness-work と同じ preapproval preflight を実行する。

• 各 task の開始時、task worktree の .claude/state/active-task.json に {"phase":"<phase>","task":"<task>"} を原子的に書く。task 終了時は成功、失敗、停止の全経路で削除する。
• .claude/state/plan-preapprovals.json があれば scripts/plan-preapproval.sh validate で v2 を validate する。v1 は既存記録の読み取り互換として受け付ける。
• 実行対象 task の decision: approved 事項だけを宣言済みとして扱い、Worker briefing に渡す。
• secret-read は bash "${HARNESS_PLUGIN_ROOT}/scripts/plan-preapproval.sh" apply-secret-allow "$PROJECT_ROOT" で project config .claude-code-harness.config.json の runtimefloor.secretAllow に per-run 反映し、108.2 の project config floor と接続する。
• R12 の ask は、同じ phase/task、期限内、使用回数内で、external-send と実行コマンドが一致する v2 承認だけが抑制する。明示 deny と runtime floor は抑制しない。
• 宣言済み事項では途中停止せず、work 中の宣言済み事項起因 AskUserQuestion はゼロにする。確認は plan 承認時の 1 回のみ。
• 記録に無い未計画の secret-read / 外部送信 / 破壊的操作は従来どおり runtime floor / ask で停止する。安全網を狭めない。

harness-work との違い

Team Composition

*親セッションまたは frontmatter が bypassPermissions の場合はそちらが優先される。配布テンプレートは現在も bypassPermissions を使うため、Auto Mode は follow-up の rollout 対象であり、既定挙動ではない。

Mode 1 — Sub-Lead 階層と review→iterate（opt-in）

Go orchestrator 経路（harness work --team）の Producer → Sub-Lead → Composer は、HARNESS_TEAM_HIERARCHY=sublead の CLI mini-plan 入口が未実装のため未対応。この更新では有効化せず、通常は既定の flat で実行する。 これは Go の opt-in 入口の制約であり、Lead が手動で担当を分解する Producer トポロジーを無効にするものではない。

Go の HARNESS_REVIEW_ITERATE=on も、production brain runner が要求する claude-companion.sh が未提供のため end-to-end 未対応。この更新で有効化せず既定 OFF を維持する。 通常の Skill / Native reviewer loop は別経路であり、既定の review gate と反復上限を維持する。Go opt-in の設計境界は harness-work の references/backend-selection.md を参照する。

• 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.

Codex Mode (--codex)

公式プラグイン codex-plugin-cc 経由で Codex CLI にすべての実装を委託するモード:

この --codex は companion 経路であり、専用 worker route を解決して実装を委託する。 公式 companion 1.0.6 が --effort max を拒否するため、router が max を返す場合は Harness の codex-companion.sh が raw codex exec の config override へ変換する。 レビュー・助言・deep 判断は、それぞれの role-scoped route を使う。Native Codex Breezing の managed custom-agent 選択とは別経路である。

# タスク委託（書き込み可能）
CODEX_MODEL_TIER=worker bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write "タスク内容"

# stdin 経由（大きなプロンプト向け）
CODEX_PROMPT=$(mktemp /tmp/codex-prompt-XXXXXX.md)
# タスク内容を書き出し
cat "$CODEX_PROMPT" | CODEX_MODEL_TIER=worker bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write
rm -f "$CODEX_PROMPT"