Skip to main content Skills Marketplace Descubra e explore skills de IA criadas pela comunidade.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Mostrar detalhes do prompt Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
npx skills add https://github.com/whyzsm/tiny-agents --skill breezingO comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.
Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.
Baixar Zip Baixando... Mais deste repositório tech-tmax-backend-architect-team 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.
harmonyos-app-store-self-check 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.
Ocupações relacionadas SOC
Baseado na classificação ocupacional SOC
Explorador de arquivos
2 arquivos 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
Breezing — Team Execution Mode
後方互換エイリアス : harness-work をチーム実行モードで動かします。
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 に diff レビューを委譲 (read-only)
3. verdict を 3-5 行で要約 → Plans.md 更新
banner 1 行 (🚀 <backend> / <model> / <branch> / <task>) + 計画 2-4 行。1 秒以内に出し、即 Step 1 へ。
進捗報告は出してよい (見やすい範囲で)
各ステップの開始・完了を 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 回のみ
違反例 (冗長):
× 「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 要約
Quick Reference
/breezing
/breezing all
/breezing 3-6
/breezing --codex all
/breezing --cursor
/breezing --cursor --reviewer-only
/breezing composer 2.5 all
/breezing --parallel 2 all
/breezing --no-discuss all
/breezing --auto-mode all
Options Option Description Default all全未完了タスクを対象 - N or N-Mタスク番号/範囲指定 - --codexCodex CLI で実装委託 false --cursorcursor backend lean path (HARNESS_IMPL_BACKEND=cursor 相当)。Worker 介在 / self_review / sprint-contract 3 段チェーン / Phase 0 を skip し、起動 → 委譲を 3 秒以内に開始する false --reviewer-onlyReviewer のみ独立系統に委譲（Worker 実装は既完了前提）。--cursor と併用で Composer に逃がす false --parallel NImplementer 並列数 auto --no-commit自動コミット抑制 false --no-discuss計画議論スキップ --cursor で true 既定--auto-modeHarness 側の Auto Mode rollout を明示。CC 2.1.111 で不要になった --enable-auto-mode とは別物 false
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 2.5 でcursor backendLead → cursor-companion.sh task --write --workspace <wt> コンポーザーで全部cursor backendLead → cursor-companion.sh task --write --workspace <wt> composer モードcursor backendLead → 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
Execution このスキルは harness-work に委譲します。 以下の設定で harness-work を実行してください:
引数をそのまま harness-work に渡す チーム実行モードを強制 — Lead → Worker spawn → Reviewer spawn の三者分離Lead は delegate 専念 — コードを直接書かないAuto Mode は opt-in 扱い — --auto-mode は互換な親セッションでの rollout 用フラグとして受け付けるAdvisor は必要時のみ — Worker が advisor-request.v1 を返した時だけ Lead が advisor を呼ぶ
harness-work との違い特徴 harness-workbreezing (このスキル)並列手段 必要数に応じた自動分割 Lead/Worker/Reviewer の役割分離 Lead の役割 調整+実装 delegate (調整専念) レビュー Lead 自己レビュー 独立 Reviewer デフォルトスコープ 次のタスク 全部
Team Composition Role Agent Type Mode 責務 Lead (self) - 調整・指揮・タスク分配 Worker ×N claude-code-harness:workerbypassPermissions（現行） / Auto Mode（follow-up）*実装 Advisor claude-code-harness:advisor読み取り専用 方針助言 (PLAN / CORRECTION / STOP) Reviewer claude-code-harness:reviewerbypassPermissions（現行） / Auto Mode（follow-up）*独立レビュー
*親セッションまたは frontmatter が bypassPermissions の場合はそちらが優先される。配布テンプレートは現在も bypassPermissions を使うため、Auto Mode は follow-up の rollout 対象であり、既定挙動ではない。
Codex Mode (--codex) 公式プラグイン codex-plugin-cc 経由で Codex CLI にすべての実装を委託するモード:
bash "${HARNESS_PLUGIN_ROOT} /scripts/codex-companion.sh" task --write "タスク内容"
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 "
Execution Backend (persistent) 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 Backend Fast 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 backend と比べて節約） Step 削除理由 節約秒数 claude-code-harness:worker agent spawncursor 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 委譲開始までを短縮。
既定 flow（cursor backend）
banner + 実行計画 (🚀 cursor / <model> / <branch> / <task> + これから進める 2-4 step、合計 5 行以内、1 秒以内)1 bash で並列 pre-check : git branch --show-current + cat VERSION + Plans.md tail + cursor-agent --version1 bash で resolve : bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh" + bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host cursor --role worker --field model即 委譲 : bash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task --write --workspace <wt> "<task>"cursor 出力を Lead が diff レビュー → cherry-pick → Plans.md cc:done [hash] 更新
Reviewer-only mode (--cursor --reviewer-only) — read = lean Worker 実装は既完了（別系統 = claude / Codex で済んだ）、Reviewer のみ独立系統 (Composer) で回したい時の lean path。read-only 委譲なので worktree 不要・cherry-pick 不要・Lead diff review 不要 :
banner + 計画: 🚀 cursor / composer-2.5-fast / review + 「これから: diff レビューを composer に委譲 → verdict 要約」
bash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task "diff レビュー: <base_ref>..HEAD" — --write も --workspace も付けない
companion は --write 未指定で default --mode ask (hard read-only stop) になる (cursor-companion.sh の workspace guard は --write 時のみ発火)
cursor 側はファイル書込・コマンド実行が disabled、worktree 隔離不要
cursor 出力 (REQUEST_CHANGES / APPROVE 相当) を Lead が解釈し、dual_review.cursor_verdict に advisory として格納
primary verdict は Opus reviewer から取る 。cursor 単独では APPROVE を確定しない (harness-work/SKILL.md「実装したバックエンドが自分の出力をレビューしてはならない」不変ルールと整合)APPROVE なら Plans.md 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)」節を参照。
Anthropic 側 server rate limit で Reviewer が止まった時の逃げ道
Worker 完了済みで Reviewer だけ別系統に分散
Codex review が auth 失敗した時の manual fallback
Cursor adapter support claim 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。
bash tests/test-cursor-adapter-candidate.sh
bash tests/test-support-claim-wording.sh
Flow Summary 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）
Advisor Protocol Worker は generic な subagent を増やさない。
迷った時は構造化 JSON で相談要求だけ返し、Lead が advisor を呼ぶ。
Worker → advisor-request.v1
Lead → Advisor
Advisor → advisor-response.v1
Lead → 同じ Worker に advice を返して続行
Reviewer は最後の成果物だけを見る
高リスク task（needs-spike / security-sensitive / state-migration）の初回実行前
同じ原因の失敗が 2 回続いた後
plateau により PIVOT_REQUIRED を返す直前
同じ trigger_hash は 1 回だけ。task ごとの相談回数は最大 3 回
Progress Feed（Phase B 中の進捗通知） 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 の出力と補完し合う。
Silence Policy（長時間実行の通知整理） Codex 0.123.0 の realtime handoff では、background agent が transcript delta を受け取り、必要ない時は明示的に沈黙できる。
Breezing の progress feed はこの前提に合わせ、通知を「作業の節目」に絞る。
task 完了、blocked、validation failure、review REQUEST_CHANGES
Advisor の PLAN / CORRECTION / STOP
Reviewer の APPROVE / REQUEST_CHANGES
advisor / reviewer drift、plateau、contract readiness failure
user が明示的に status を求めた時の要約
transcript delta を受け取っただけで、判定や status が変わっていない時
tool stdout の細かな増分で、log に残っていれば十分な時
並列 Worker の待機中 heartbeat
頻度は「task 完了ごとに 1 回」を基本にする。
heartbeat を増やして安心感を作るのではなく、status / log / drift 検知に責務を分ける。
ただし Advisor request 未応答、Reviewer result 未到着、plateau 直前の警告は silence 対象にしない。
Monitor ツール活用ガイド (CC 2.1.98+) 長時間実行コマンドを監視する時は、ポーリング (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 より効率的
Lead:
Task(Worker1, ...) ← Agent 完了待ち (Monitor 不要)
Task(Worker2, ...) ← 同上
Bash(run_in_background, "gh run watch --exit-status")
Monitor(tailCommand="...") ← CI 失敗を即時検知 → Worker に修正指示
これにより Lead が「Worker 完了 → CI 失敗検知 → 修正指示」の反応速度を上げられる。
Review Policy（全モード統一） Breezing モードでもレビューは Codex exec 優先 → 内部 Reviewer フォールバック の統一ポリシーに従う。
詳細は harness-work の「レビューループ」セクションを参照。
Worker が worktree 内で実装・commit → worker-report.v1 (self_review 5 件) を Lead に返却
self_review ゲート (Reviewer spawn 前) : Lead が self_review[].verified と evidence を機械検証。1 件でも verified:false or evidence:"" なら Reviewer を spawn せず Worker に自動差し戻し（同一セッション内 最大 2 回、3 回目で escalate）Lead が Codex exec でレビュー（120s タイムアウト、フォールバック: Reviewer agent）
REQUEST_CHANGES → Lead が SendMessage で Worker に修正指示、Worker が amend（最大 MAX_REVIEWS 回。MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3）
APPROVE → Lead が main に cherry-pick → Plans.md を cc:完了 [{hash}] に更新
完了報告（Phase C — Lead が生成） 全タスク完了後、Lead が以下の手順でリッチ完了報告を生成する:
git log --oneline {base_ref}..HEAD で全 cherry-pick コミットを収集git diff --stat {base_ref}..HEAD で全体の変更規模を取得Plans.md の cc:TODO / cc:WIP 残タスクを抽出
harness-work の「完了報告フォーマット」の Breezing テンプレートに従い出力
生成者は Lead 。Worker や hook ではない。Lead が Phase C で git + Plans.md を読んで生成する。
Phase 0: Planning Discussion（構造化 3 問チェック） 全タスク実行前に、以下の 3 問で計画の健全性を確認する。
--no-discuss 指定時は全スキップ。
「{{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 秒で完了する設計）。
Universal Violations Injection（セッション内 Worker 間の学習伝播） 同一 /breezing 起動内で蓄積された Reviewer の universal gotchas を次 Worker の briefing 冒頭に自動注入する。同一セッション内のみ有効 （セッション終了で破棄、session-memory には書かない）。
universal_violations = []
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"
for update in reviewer_result.memory_updates:
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 フォーマット）、依存グラフに従ってタスクを実行する:
Depends が - のタスク を先に実行。独立タスクが複数あれば並列 spawn 可能各 Worker 完了後、Lead がレビュー→cherry-pick（harness-work Phase B 参照）
依存元タスクが main に cherry-pick されたら、そのタスクに依存していたタスクを次に実行
全タスクが完了するまで繰り返す
注意 : 各タスクの「Worker 完了→レビュー→cherry-pick」は逐次処理。
並列化できるのは独立タスク（Depends が -）の Worker spawn 部分のみ。
Codex Native Orchestration 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 環境では上記に読み替えること。
Related Skills
harness-work — 単一タスクからチーム実行まで（本体）harness-sync — 進捗同期harness-review — コードレビュー（breezing 内で自動起動） 