/breezing

name: breezing
description: "Team execution mode — backward-compatible alias for harness-work with team orchestration. Composer/composer 2.5 maps to the cursor backend."
description-ja: "チーム実行モード — harness-work のチーム協調エイリアス。breezing, チーム実行, 全部やって, composer, コンポーザー, composer 2.5 でトリガー。"
description-en: "Team execution mode — backward-compatible alias for harness-work with team orchestration. Composer/composer 2.5 maps to the cursor backend."
kind: workflow
purpose: "Wrap harness-work with team execution orchestration"
trigger: "breezing, team execution, do everything, composer, composer 2.5, composer mode, コンポーザー"
shape: wrap
role: orchestrator
base: harness-work
pair: harness-review
owner: harness-core
since: "2026-05-05"
allowed-tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob", "Task", "WebSearch", "Monitor"]
argument-hint: "[all|N-M|--codex|--cursor|--reviewer-only|--parallel N|--no-commit|--no-discuss|--no-review-gate|--auto-mode]"
user-invocable: true

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 直読みは引き続き禁止:

| 作業の性質 | 推奨 backend | 理由 | |---|---|---| | 通常の実装・修正・テスト（既定） | `claude` (native) | Worker 契約（`worker-report.v1` / self_review 5 件）が全部効く | | 大規模で独立性の高い一括実装、Claude 側 rate limit 回避 | `codex` | `breezing --codex` の companion が専用の worker route を解決して委譲する。Native Codex は managed custom agent を選択し、deep / review / advisor は各 role の route を維持する | | UI 大量生成、lean な高速委譲 | `cursor` | lean path（worktree 隔離 + Lead diff review） |

モデル 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` を `a