메뉴
Team execution mode — backward-compatible alias for harness-work with team orchestration. Composer/composer 2.5 maps to the cursor backend.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/whyzsm/tiny-agents --skill breezing명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
Single-Agent T-MAX Java backend architecture and engineering rule package. Use when Codex must design, implement, review, or diagnose T-MAX backend services involving Java 8, Spring Boot, Kylin, MyBatis XML, TiDB/MySQL, Apollo/Nacos, Feign, AnePageHelper, ResponseResult/DataGridResult, UEP export, Redis, RabbitMQ, or Maven multi-module repositories. Routes one Agent through repository intake, architecture decisions, API/data contracts, implementation diagnosis, quality/security review, and bounded evidence loops while keeping builds, tests, live calls, commits, and pushes as separate authority boundaries.
Create polished consulting-style single-file HTML research reports from messy business notes, screenshots, metrics, and iterative user feedback. Use this skill whenever the user asks for a 咨询风/艾瑞咨询风/研究报告/汇报报告/HTML报告, wants business or AI landing-practice material turned into a management-facing report, asks to add charts/diagrams, or asks to update report metrics and keep the whole HTML report consistent.
Audit HarmonyOS applications for AppGallery/AGC release readiness, including Huawei UX/HMI controls, system-feature integrations, and performance gates for multi-input interaction, latency, frame rate, content display, memory, and CPU. Use when users ask for 鸿蒙上架自检、应用市场审核、AGC发布前检查、控件/系统特性/人机交互/签名/隐私/权限/截图/性能核对或 release 包门禁, especially for Stage-model projects with module.json5, build-profile.json5, hvigorw, and local-first data constraints.
SOC 직업 분류 기준
| 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|--auto-mode] |
| user-invocable | true |
後方互換エイリアス:
harness-workをチーム実行モードで動かします。
敵は 冗長さ であって進捗報告ではない。起動時に実行計画を簡潔に明示してから実行を開始する。見やすい進捗報告は歓迎する。冗長な繰り返し・中身のない前置きだけを禁ずる。
最初の応答で、何を・どの順で進めるかを示してから tool 実行に入る:
🚀 cursor / composer-2.5-fast / feat/hah-11-golden-rule-lint / Reviewer
これから:
1. backend/model を resolve
2. composer に diff レビューを委譲 (read-only)
3. verdict を 3-5 行で要約 → Plans.md 更新
banner 1 行 (🚀 <backend> / <model> / <branch> / <task>) + 計画 2-4 行。1 秒以内に出し、即 Step 1 へ。
✓ backend=cursor / model=composer-2.5-fast)違反例 (冗長):
× 「composer 2.5 使うモード」= cursor backend で Composer に委託、ですね（と解釈の言い換え）
× 「前回 Reviewer が止まったので別系統に逃がすのは理にかなっています」（3 行以上の振り返り）
× 「使い方を確認します」 → bash → 「呼べます」（中身のない前置き + 同じ事実の 2 回言い換え）
正常例 (簡潔 + 計画明示):
🚀 cursor / composer-2.5-fast / feat/hah-11-golden-rule-lint / Reviewer
これから: backend resolve → composer に diff レビュー委譲 (read-only) → verdict 要約
/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
| Option | Description | Default |
|---|---|---|
all | 全未完了タスクを対象 | - |
N or N-M | タスク番号/範囲指定 | - |
--codex | Codex CLI で実装委託 | false |
--cursor | cursor backend lean path (HARNESS_IMPL_BACKEND=cursor 相当)。Worker 介在 / self_review / sprint-contract 3 段チェーン / Phase 0 を skip し、起動 → 委譲を 3 秒以内に開始する | false |
--reviewer-only | Reviewer のみ独立系統に委譲（Worker 実装は既完了前提）。--cursor と併用で Composer に逃がす | false |
--parallel N | Implementer 並列数 | auto |
--no-commit | 自動コミット抑制 | false |
--no-discuss | 計画議論スキップ | --cursor で true 既定 |
--auto-mode | Harness 側の Auto Mode rollout を明示。CC 2.1.111 で不要になった --enable-auto-mode とは別物 | false |
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 2.5 で | cursor backend | Lead → cursor-companion.sh task --write --workspace <wt> |
コンポーザーで全部 | cursor backend | Lead → cursor-companion.sh task --write --workspace <wt> |
composer モード | cursor backend | Lead → cursor-companion.sh task --write --workspace <wt> |
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を参照。
このスキルは harness-work に委譲します。 以下の設定で harness-work を実行してください:
harness-work に渡す--auto-mode は互換な親セッションでの rollout 用フラグとして受け付けるadvisor-request.v1 を返した時だけ Lead が advisor を呼ぶharness-work との違い| 特徴 | harness-work | breezing (このスキル) |
|---|---|---|
| 並列手段 | 必要数に応じた自動分割 | Lead/Worker/Reviewer の役割分離 |
| Lead の役割 | 調整+実装 | delegate (調整専念) |
| レビュー | Lead 自己レビュー | 独立 Reviewer |
| デフォルトスコープ | 次のタスク | 全部 |
| Role | Agent Type | Mode | 責務 |
|---|---|---|---|
| Lead | (self) | - | 調整・指揮・タスク分配 |
| Worker ×N | claude-code-harness:worker | bypassPermissions（現行） / Auto Mode（follow-up）* | 実装 |
| Advisor | claude-code-harness:advisor | 読み取り専用 | 方針助言 (PLAN / CORRECTION / STOP) |
| Reviewer | claude-code-harness:reviewer | bypassPermissions（現行） / Auto Mode（follow-up）* | 独立レビュー |
*親セッションまたは frontmatter が
bypassPermissionsの場合はそちらが優先される。配布テンプレートは現在もbypassPermissionsを使うため、Auto Mode は follow-up の rollout 対象であり、既定挙動ではない。
--codex)公式プラグイン codex-plugin-cc 経由で Codex CLI にすべての実装を委託するモード:
# タスク委託（書き込み可能）
bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write "タスク内容"
# stdin 経由（大きなプロンプト向け）
CODEX_PROMPT=$(mktemp /tmp/codex-prompt-XXXXXX.md)
# タスク内容を書き出し
cat "$CODEX_PROMPT" | bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write
rm -f "$CODEX_PROMPT"
HARNESS_IMPL_BACKEND=cursor（bash "${HARNESS_PLUGIN_ROOT}/scripts/set-impl-backend.sh" cursor で設定）にすると、
per-run フラグなしで cursor が既定の worker バックエンドになる。review / advisor ロールは Opus に固定したまま。
バックエンド選択の正本（precedence、role-scope、self_review スキップ、cursor banner）は
harness-work の「Execution Backend Selection（実装バックエンド選択）」を参照する。
下の Cursor Backend Fast Path は per-run フラグ (--cursor) で同等の lean path を有効化する別軸であり、本節と併読する。
--cursor / lean mode)--cursor 指定時、または env HARNESS_IMPL_BACKEND=cursor の時に有効。Worker 層を介在させず Lead が直接 cursor-companion.sh を呼ぶ（Phase 85 SSOT、.claude/rules/cursor-cli-only.md Topology 節）。
| Step | 削除理由 | 節約秒数 |
|---|---|---|
claude-code-harness:worker agent spawn | cursor backend は Worker 介在なし | 5-30s |
| self_review 5 件ゲート | worker-report.v1 が cursor では生成されないため不要 | 10-60s × retry |
| sprint-contract 3 段チェーン (generate→enrich→ensure) | Worker 契約不要なら contract 不要 | 2-5s × N |
| Phase 0 Q1-Q3 interactive | --no-discuss all 既定 (Plans/Depends は Lead が直読み) | 15-30s |
| Effort スコアリング | cursor backend では ultrathink 注入不要 | 0.5-1s × N |
| Plans.md re-parse (per task) | session 内 cache (mtime+hash で短絡) | 3-8s |
合計 baseline 15-35s → target 3-7s で 1 タスク目の cursor 委譲開始までを短縮。
🚀 cursor / <model> / <branch> / <task> + これから進める 2-4 step、合計 5 行以内、1 秒以内)git branch --show-current + cat VERSION + Plans.md tail + cursor-agent --versionbash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh" + bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host cursor --role worker --field modelbash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task --write --workspace <wt> "<task>"cc:done [hash] 更新--cursor --reviewer-only) — read = leanWorker 実装は既完了（別系統 = claude / Codex で済んだ）、Reviewer のみ独立系統 (Composer) で回したい時の lean path。read-only 委譲なので worktree 不要・cherry-pick 不要・Lead diff review 不要:
🚀 cursor / composer-2.5-fast / review + 「これから: diff レビューを composer に委譲 → verdict 要約」bash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task "diff レビュー: <base_ref>..HEAD" — --write も --workspace も付けない
--write 未指定で default --mode ask (hard read-only stop) になる (cursor-companion.sh の workspace guard は --write 時のみ発火)dual_review.cursor_verdict に advisory として格納cc:done [hash] を Lead が更新read mode で省略できるもの: 専用 .git worktree / Lead diff review / cherry-pick / worker-report.v1 / self_review 5 件。
read mode でも保持必要: .cursorignore / egress allowlist (*.cursor.sh) / permissions.json (best-effort)。詳細は .claude/rules/cursor-cli-only.md 「Read mode delegation (lean path)」節を参照。
用途:
Cursor は依然 internal-compatible tier（Phase 87 / PR #174 で promotion）。supported public claim は CI-gated workflow smoke 充足まで継続 gate。--cursor lean path は support tier を昇格させない。
Bootstrap route: .cursor/AGENTS.md + .cursor-plugin/plugin.json。
Verification:
bash tests/test-cursor-adapter-candidate.sh
bash tests/test-support-claim-wording.sh
breezing [scope] [--codex] [--parallel N] [--no-discuss] [--auto-mode]
│
↓ Load harness-work with team mode
│
Phase 0: Planning Discussion (--no-discuss でスキップ)
Phase A: Pre-delegate（チーム初期化）
Phase B: Delegate（Worker 実装 + 必要時 Advisor + Reviewer レビュー）
Phase C: Post-delegate（統合検証 + Plans.md 更新 + commit）
Worker は generic な subagent を増やさない。 迷った時は構造化 JSON で相談要求だけ返し、Lead が advisor を呼ぶ。
advisor-request.v1advisor-response.v1相談条件は loop / solo とそろえる。
needs-spike / security-sensitive / state-migration）の初回実行前PIVOT_REQUIRED を返す直前trigger_hash は 1 回だけ。task ごとの相談回数は最大 3 回Lead は Worker のタスク完了ごとに、以下のフォーマットで進捗を出力する:
📊 Progress: Task {completed}/{total} 完了 — "{task_subject}"
出力例:
📊 Progress: Task 1/5 完了 — "harness-work に失敗再チケット化を追加"
📊 Progress: Task 2/5 完了 — "harness-sync に --snapshot を追加"
📊 Progress: Task 3/5 完了 — "breezing にプログレスフィードを追加"
設計意図: breezing は長時間実行になることが多い。 ユーザーがターミナルをチラ見した時に「今どこまで進んでいるか」が一目で分かるようにする。 task-completed.sh フックが systemMessage で同等の情報を出力するため、Lead の出力と補完し合う。
Codex 0.123.0 の realtime handoff では、background agent が transcript delta を受け取り、必要ない時は明示的に沈黙できる。
Breezing の progress feed はこの前提に合わせ、通知を「作業の節目」に絞る。
報告するもの:
REQUEST_CHANGESPLAN / CORRECTION / STOPAPPROVE / REQUEST_CHANGES沈黙してよいもの:
頻度は「task 完了ごとに 1 回」を基本にする。 heartbeat を増やして安心感を作るのではなく、status / log / drift 検知に責務を分ける。 ただし Advisor request 未応答、Reviewer result 未到着、plateau 直前の警告は silence 対象にしない。
長時間実行コマンドを監視する時は、ポーリング (Read で定期的にファイル末尾を読む) ではなく Monitor ツール を使用する。Monitor はバックグラウンドプロセスの stdout 各行を逐次通知として Lead に届けるため、polling より低レイテンシかつ低トークン消費で状況を把握できる。
適用例:
go test ./... -v の実行中進捗監視gh run watch による GitHub Actions 進捗追跡npm run build --watch / vite build --watch のビルドエラー即時検知codex-companion.sh status <job-id> での Codex job 完了検知docker-compose logs -f / kubectl logs -f のデプロイログ追跡使い分けの判断基準:
| 対象 | Monitor 使う? | 理由 |
|---|---|---|
| Agent (Worker / Reviewer) の完了監視 | 不要 | Agent 層が自前で完了通知する |
run_in_background: true で投げた shell process | 推奨 | stdout 各行を逐次通知で拾える |
短時間の一発コマンド (go test 1 回実行) | 不要 | 通常の Bash tool 実行で十分 |
| 長時間 tail / watch / stream 系コマンド | 推奨 | polling より効率的 |
Breezing Lead での典型パターン:
Lead:
Task(Worker1, ...) ← Agent 完了待ち (Monitor 不要)
Task(Worker2, ...) ← 同上
Bash(run_in_background, "gh run watch --exit-status")
Monitor(tailCommand="...") ← CI 失敗を即時検知 → Worker に修正指示
これにより Lead が「Worker 完了 → CI 失敗検知 → 修正指示」の反応速度を上げられる。
Breezing モードでもレビューは Codex exec 優先 → 内部 Reviewer フォールバック の統一ポリシーに従う。
詳細は harness-work の「レビューループ」セクションを参照。
worker-report.v1 (self_review 5 件) を Lead に返却self_review[].verified と evidence を機械検証。1 件でも verified:false or evidence:"" なら Reviewer を spawn せず Worker に自動差し戻し（同一セッション内 最大 2 回、3 回目で escalate）MAX_REVIEWS 回。MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3）cc:完了 [{hash}] に更新全タスク完了後、Lead が以下の手順でリッチ完了報告を生成する:
git log --oneline {base_ref}..HEAD で全 cherry-pick コミットを収集git diff --stat {base_ref}..HEAD で全体の変更規模を取得cc:TODO / cc:WIP 残タスクを抽出harness-work の「完了報告フォーマット」の Breezing テンプレートに従い出力生成者は Lead。Worker や hook ではない。Lead が Phase C で git + Plans.md を読んで生成する。
全タスク実行前に、以下の 3 問で計画の健全性を確認する。
--no-discuss 指定時は全スキップ。
Q1. スコープ確認:
「{{N}} 件のタスクを実行します。スコープは適切ですか？」
多すぎる場合は優先度（Required > Recommended > Optional）で絞り込みを提案。
Q2. 依存関係確認（Plans.md に Depends カラムがある場合のみ）:
「タスク {{X}} は {{Y}} に依存しています。実行順序は合っていますか？」
Depends カラムを読み取り、依存チェーンを表示。循環依存があればエラー。
Q3. リスクフラグ（[needs-spike] タスクがある場合のみ）:
「タスク {{Z}} は [needs-spike] です。先に spike しますか？」
spike 未完了の [needs-spike] タスクがある場合、spike を先行実行するか確認。
3 問とも問題なければ、Phase A に進む（合計 30 秒で完了する設計）。
同一 /breezing 起動内で蓄積された Reviewer の universal gotchas を次 Worker の briefing 冒頭に自動注入する。同一セッション内のみ有効（セッション終了で破棄、session-memory には書かない）。
# Phase A 開始時に Lead プロセスの in-memory 配列を初期化
universal_violations = [] # List[str] — このセッション内で蓄積
# Phase B で Worker を spawn する直前、briefing 冒頭に注入:
def build_worker_briefing(task, contract_path):
header = ""
if universal_violations:
header = (
"🚨 同一セッションで既に検出された universal 違反（再発禁止）:\n"
+ "\n".join(f"- {v}" for v in universal_violations)
+ "\n\n"
)
return header + f"タスク: {task.内容}\nDoD: {task.DoD}\ncontract_path: {contract_path}\nmode: breezing"
# Reviewer が review-result.v1 を返した後、Lead が scope="universal" のみ抽出して累積:
for update in reviewer_result.memory_updates:
# 後方互換: 文字列は task-specific 扱い → 無視
if isinstance(update, str):
continue
if update.get("scope") == "universal":
universal_violations.append(update["text"])
方針: 過剰設計回避のため、session-memory や decisions.md への永続化は行わない。Lead プロセスの in-memory 配列に保持するだけで、/breezing セッション終了時に破棄する（issue #87 本文の方針）。
Plans.md に Depends カラムがある場合（v2 フォーマット）、依存グラフに従ってタスクを実行する:
- のタスクを先に実行。独立タスクが複数あれば並列 spawn 可能注意: 各タスクの「Worker 完了→レビュー→cherry-pick」は逐次処理。 並列化できるのは独立タスク（Depends が
-）の Worker spawn 部分のみ。
Codex では native subagent を使う。
代表的な制御面は spawn_agent, wait, send_input, resume_agent, close_agent。
Claude Code vs Codex の通信 API（SSOT:
team-composition.mdの API マッピング表）:
- Claude Code:
SendMessage(to: agentId, message: "...")で Worker に修正指示- Codex:
resume_agent(agent_id)で Worker を再開 →send_input(agent_id, "...")で指示送信harness-work の擬似コードは Claude Code 構文で記述。Codex 環境では上記に読み替えること。
harness-work — 単一タスクからチーム実行まで（本体）harness-sync — 進捗同期harness-review — コードレビュー（breezing 内で自動起動）