HAR: Execute Plans.md tasks from single task to full parallel team run. Trigger: implement, execute, do everything, breezing, team run, parallel, composer, composer 2.5. Do NOT load for: planning, review, release, setup.
The canonical home for this skill is harness-work in Chachamaru127/claude-code-harness
Harness の統合実行スキル。 以下の旧スキルを統合:
work — Plans.md タスクの実装(スコープ自動判断)impl — 機能実装(タスクベース)breezing — チームフル自動実行parallel-workflows — 並列ワークフロー最適化ci — CI 失敗時の復旧| ユーザー入力 | モード | 動作 |
|---|---|---|
harness-work | auto | タスク数で自動判定(下記参照) |
harness-work all | auto | 全未完了タスクを自動モードで実行 |
harness-work 3 | solo | タスク3だけ即実行 |
harness-work --parallel 5 | parallel | 5ワーカーで並列実行(強制) |
harness-work --codex | codex | Codex CLI に委託(明示時のみ) |
harness-work --breezing all | breezing | resolved backend でチーム実行(配布既定は claude、user/project default で cursor 可) |
harness-work --breezing --backend cursor all | breezing | Cursor worker backend を明示してチーム実行 |
harness-work --breezing --backend claude all | breezing | Codex native subagent worker を明示してチーム実行 |
harness-work --breezing | breezing | チーム実行を強制 |
harness-work 3 --plan roadmap | solo | named Plans の roadmap からタスク3を実行 |
明示的なモードフラグ(--parallel, --breezing, --codex)がない場合、
対象タスク数に応じて最適なモードを自動選択する:
| 対象タスク数 | 自動選択モード | 理由 |
|---|---|---|
| 1 件 | Solo | オーバーヘッド最小。直接実装が最速 |
| 2〜3 件 | Parallel(Task tool) | Worker 分離のメリットが出始める閾値 |
| 4 件以上 | Breezing | Lead 調整 + Worker 並列 + Reviewer 独立の三者分離が効果的 |
--parallel N → Parallel モード(タスク数に関係なく)--breezing → Breezing モード(タスク数に関係なく)--codex → Codex モード(タスク数に関係なく)--codex は明示時のみ発動。Codex CLI が未インストールの環境があるため、自動選択しない--codex は他モードと組み合わせ可能: --codex --breezing → Codex + Breezingバックエンド(どのランタイムが実装するか)は、トポロジー(実行モード: solo / parallel / breezing)と直交する。 トポロジーが「何ワーカーで・どう分割して回すか」を決めるのに対し、バックエンドは「実装の手を誰が動かすか」を決める。 この契約は host-neutral であり(spec.md「Execution Backend Contract」)、Codex host から harness を駆動しても Claude Code から駆動しても同じに振る舞う。
| backend | 実装の担い手 | 委託コマンド |
|---|---|---|
claude(global fallback) | Codex native subagent(spawn_agent) | spawn_agent で worker を spawn |
codex | Codex CLI | bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write "<prompt>" |
cursor | cursor-agent(model composer-2.5-fast) | bash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task --write --workspace <worktree> "<prompt>" |
run 開始時に 1 回だけ解決する。backend 判定は 必ず resolver 経由にし、HARNESS_IMPL_BACKEND env だけを直読みして判定しない:
bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh"precedence(高い順): --backend <v> / --cursor / --codex フラグ > HARNESS_IMPL_BACKEND 環境変数 > プロジェクト env.local の同名行 > ユーザー ~/.config/claude-harness/impl-backend.env の同名行 > call-site default。
明示フラグ(--backend / --cursor / --codex)は env / file / default を常に上書きする。プロジェクト設定はユーザースコープを上書きする。
Codex host の --breezing / breezing も配布 plugin では call-site default を変えない。
フラグなしは resolve-impl-backend.sh の結果に従い、未設定時の fallback は claude。
Cursor を既定にしたい環境は HARNESS_IMPL_BACKEND=cursor を env / project env.local / user-scope config に設定する。
明示的に Cursor を使う場合は --backend cursor / --cursor、Codex native subagent worker へ戻す場合は --backend claude を渡す。
モデル名の正本は
model-routing.sh。本ドキュメント中のcomposer-2.5-fastは参照値であり、実解決はbash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host cursor --role worker --field modelに従う(drift 防止)。
ユーザーが composer / コンポーザー / Composer で / composer 2.5 / composer モード と言った場合は、cursor backend 指定として扱う。
これは --cursor と同じ intent だが、backend の確定値は必ず resolve-impl-backend.sh で解決する。
解決時は明示 override として --backend cursor を渡し、env / project / user file / default より優先させる。
Lead は composer を Codex native Worker 内の追加 agent と解釈せず、非 claude backend の規約どおり Worker agent を挟まずに cursor-companion.sh を直接呼ぶ。
バックエンドは role-scoped。解決済みバックエンドを使うのは実装(worker)ロールだけ。 Reviewer と Advisor は実装役から分離し、担当ごとのモデルを解決する。Claude の計画と相談は Fable 5.1/high を既定にする。 Reviewer を cursor / codex バックエンドに routing しない(実装したバックエンドが自分の出力をレビューしてはならない)。
claude バックエンドの self_review ゲートbackend が codex または cursor の場合、worker-report.v1 も self_review 配列も生成されない。
そのため Lead は self_review ゲートをスキップし、Lead の diff レビューを唯一の品質ゲートとする(既存の codex path と同じ扱い)。
backend が cursor のとき、Lead は委託前に次の 1 行 banner を必ず出力する:
⚠️ cursor backend: model=composer-2.5-fast / R01-R13 ガードレールは cursor-agent 内部に適用されない / 出力は Lead レビューまで untrustedcursor の write 委託は専用 .git を持つ worktree 内で実行し、Lead が main へ cherry-pick する(cherry-pick 経路で R01-R13 が適用される)。
ガバナンス詳細は .claude/rules/cursor-cli-only.md を参照。
| オプション | 説明 | デフォルト |
|---|---|---|
all | 全未完了タスクを対象 | - |
N or N-M | タスク番号/範囲指定 | - |
--parallel N | 並列ワーカー数 | auto |
--sequential | 直列実行強制 | - |
--codex | Codex CLI で実装委託(明示時のみ、自動選択しない) | false |
--backend <claude|codex|cursor> | 明示バックエンド選択(worker ロールのみ適用、precedence 最上位) | resolver result(未設定時は claude) |
--cursor | cursor backend(--backend cursor の別名) | false |
--plan NAME | plans/manifest.json の named plan を使う | active/default |
--no-commit | 自動コミット抑制 | false |
--resume <id|latest> | 前回セッション再開 | - |
--breezing | Lead/Worker/Reviewer のチーム実行 | false |
--no-tdd | TDD フェーズスキップ | false |
--tdd-bypass | 緊急時だけ TDD 強制を bypass。HARNESS_TDD_BYPASS_REASON または明示理由を audit に残す | false |
--no-simplify | Auto-Refinement スキップ | false |
--auto-mode | Auto Mode rollout を明示。親セッションの permission mode が互換な場合のみ採用を検討 | false |
実行依頼は、目的と理由、担当範囲、検証可能な DoD、選択した plan / spec、観測済み証拠、原依頼と適用される承認の参照を渡す。
以降の {task prompt} と companion のタスク本文にはこれらを含める。再試行でも元の範囲と条件を残し、追加の finding や advisor response だけで置き換えない。
方法は担当が選ぶ。承認済みの可逆作業を再確認で止めず、不足情報は契約と読み取り調査で回収する。軽微な仮定は明示し、重大な仕様判断や不足する権限に依存する操作だけ止める。
評価・相談だけの依頼から実装を開始しない。推定した変更範囲は保護操作の承認ではない。
独立して検証できる作業を、担当ファイルと同時実行上限を明記して委譲する。他担当の編集を戻さず、関連する follow-up は同じ担当へ返す。Lead も仕様調査や証拠照合を進める。
必須チェックと既定レビューを完了した後は、新しい変更、失敗、未解決の懸念がない限り追加テストや機能を増やさない。
完了報告は実際の差分と検証結果で支え、自己申告だけで完了を判定しない。理由と参照可能な証拠を返し、内部の思考過程は求めない。
まずこの本文で入口、自動選択、停止条件だけを確認する。 詳細は必要になった時だけ読む。
| 詳細 | 参照 |
|---|---|
| Codex native Solo / Parallel / Breezing の具体手順 | references/execution-modes.md |
| companion review、Reviewer fallback、AI Residuals、修正ループ | references/review-loop.md |
| 完了報告の生成 | references/completion-report.md |
| テスト/CI 失敗時の再チケット化 | references/failure-reticketing.md |
| 仕様正本チェックの基準 | docs/plans/spec-ssot.md |
Plans.md が旧フォーマットで DoD / Depends / Status を読めない時は停止する。scripts/ ではなく ${HARNESS_PLUGIN_ROOT}/scripts/ から呼ぶ。--plan NAME を明示して新しい run を開始する。Token Optimization (v2.1.69+): git 操作を伴わない軽量タスクでは plugin settings の
includeGitInstructions: falseを有効にして プロンプトトークンを削減できる。
直前の明示依頼や選択済み plan で対象が確定していれば、その範囲を使う。以下の確認は対象範囲が未決の場合だけ行う。
harness-work
どこまでやりますか?
1) 次のタスク: Plans.md の次の未完了タスク → Solo で実行
2) 全部(推奨): 残りのタスクをすべて完了 → タスク数で自動モード選択
3) 番号指定: タスク番号を入力(例: 3, 5-7)→ 件数で自動モード選択引数ありなら即実行(対話スキップ):
harness-work all → 全タスク、自動モード選択harness-work 3-6 → 4件なので Breezing 自動選択effort はモデルの推論強度を選ぶ正式なノブ。generic な standard / review route は
low(○)/medium(◐)/high(●)/xhigh を使う。Breezing の implementation worker は
managed worker route の設定をそのまま使い、skill から effort を上書きしない。
/effort auto は generic route の既定へ戻す操作であり、worker route の max 契約を
xhigh へ静かに置換してはならない。
CCH のモデルと effort は未指定時の既定値であり、利用者の明示指定と手動変更を尊重する。native profile / 明示 override を正とし、AI が文言から再調整したり、親の変更を全 Worker へ配ったりしない。独立 Reviewer の隔離と read-only は維持する。
「浅い推論」を観測したら prompt で回避せず、対象 role の中央 routing 設定を確認する。
そのため複雑タスクの強化は free-text marker(旧 ultrathink)を spawn prompt に注入する方式を廃止し、
複雑度スコアは担当設定を見直す判断材料に限る。skill は利用者の明示 effort を変更せず、未指定の managed worker には配布既定の max を使う。
タスク着手時に以下のスコアを合算する。
| 要素 | 条件 | スコア |
|---|---|---|
| ファイル数 | 変更対象 4 ファイル以上 | +1 |
| ディレクトリ | core/, guardrails/, security/ を含む | +1 |
| キーワード | architecture, security, design, migration を含む | +1 |
| 失敗履歴 | agent memory に同タスクの失敗記録あり | +2 |
| 明示指定 | PM テンプレートに effort: high / effort: xhigh(旧 ultrathink も互換受理)記載あり | +3(自動採用) |
スコアから effort tier を escalation signal として決める(ultrathink 等の marker 文字列を spawn prompt に 書かない)。
設定を確認する面は次の 2 つ。スコアは設定変更の承認にはならない:
/effort: 利用者が明示した推論量を保持する。複雑度の推定だけで host が /effort high / /effort xhigh を設定しない。.codex/agents/worker.toml、companion は専用 worker route を使う。利用者が明示・手動変更した設定を尊重する。以下のスコア表は見直し候補であり、配布既定 max や明示設定を自動変更しない。| スコア | code-risk(core/guardrails/security/architecture/migration を含む) | 見直し候補 |
|---|---|---|
| 0-2 | 不問 | medium 候補(managed worker route は保持) |
| ≥ 3 | なし | high |
| ≥ 3 | あり | xhigh |
breezing モードでも同じロジックを適用する(harness-work が一本化して管理)。
Harness が同梱する helper script は、作業対象プロジェクトの scripts/ ではなく、必ず plugin bundle root から呼ぶ。
HARNESS_PLUGIN_ROOT="${HARNESS_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}"
if [ -z "$HARNESS_PLUGIN_ROOT" ] && [ -n "${CLAUDE_SKILL_DIR:-}" ]; then
probe="$(cd "${CLAUDE_SKILL_DIR}" && pwd)"
while [ "$probe" != "/" ] && [ ! -d "$probe/scripts" ]; do
probe="$(cd "$probe/.." && pwd)"
done
[ -d "$probe/scripts" ] && HARNESS_PLUGIN_ROOT="$probe"
fi以降の node "${HARNESS_PLUGIN_ROOT}/scripts/..." / bash "${HARNESS_PLUGIN_ROOT}/scripts/..." は、この解決済み root を前提にする。
Solo / Parallel / Breezing は同じ resolver result から実装 executor を選ぶ。
harness-work 3 --cursor と user/project HARNESS_IMPL_BACKEND=cursor は、1 件タスクでも local Read/Write/Edit/Bash に fall through してはいけない。
resolver_backend_arg = ""
if explicit_backend_value in ["claude", "codex", "cursor"]:
resolver_backend_arg = "--backend {explicit_backend_value}"
backend = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh\" {resolver_backend_arg}")
if explicit_flag == "--cursor":
backend = "cursor"
if explicit_flag == "--codex":
backend = "codex"
if topology in ["solo", "parallel"] and backend in ["cursor", "codex"]:
BASE_REF = git("rev-parse", "HEAD")
WT_ID = "{task.number}-$(date +%Y%m%d-%H%M%S)-$$"
worktree_path = ".claude/worktrees/{backend}-{WT_ID}"
worktree_branch = "{backend}-work/{WT_ID}"
bash("mkdir -p .claude/worktrees && git worktree add -b {worktree_branch} {worktree_path} {BASE_REF}")
companion_prompt = "{task prompt}\n\nAfter making changes, create exactly one git commit in this worktree before returning."
if backend == "cursor":
companion_output = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh\" task --write --workspace {worktree_path} \"{companion_prompt}\"")
else:
companion_state_file = "{worktree_path}/.claude/state/codex-primary-environment.json"
companion_output = bash("CODEX_MODEL_TIER=worker HARNESS_CODEX_PRIMARY_ENV_STATE_FILE={companion_state_file} bash \"${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh\" task --write -C {worktree_path} \"{companion_prompt}\"")
latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
if backend == "cursor" and git("-C", worktree_path, "status", "--porcelain") != "":
git("-C", worktree_path, "add", "-A")
git("-C", worktree_path, "-c", "user.name=cursor-composer", "-c", "user.email=cursor-composer@local", "commit", "--no-verify", "-m", "cursor: delegated change")
latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
if latest_commit == BASE_REF:
raise EscalationError("{backend} companion produced no commit")
worker_result = {type: "companion-result.v1", baseCommit: BASE_REF, commit: latest_commit, worktreePath: worktree_path, branch: worktree_branch, files_changed: git("-C", worktree_path, "diff", "--name-only", "{BASE_REF}..HEAD"), summary: companion_output}
enter_shared_review_loop(worker_result)
else:
run_native_solo_or_parallel()Parallel は task ごとにこの resolver path を適用する。
backend=cursor / codex の場合は native Worker spawn を使わず、task ごとに isolated companion worktree を作成して companion-result.v1 に正規化してから共通 review / cherry-pick loop に入る。
harness-plan create --ci を自動呼び出し → Plans.md を生成して続行Plans.md が旧フォーマットです。harness-plan create で再生成してください。 → 停止cc:TODO で自動追記
git grep / Glob で 影響範囲(変更が及ぶファイル/モジュール)を推論表示docs/spec/00-project-spec.md, docs/ARCHITECTURE.md, docs/HANDOFF.md, docs/oem/PROJECT_COMPASS.md, docs/specs/)docs/spec/00-project-spec.md を作るspec_path または spec_skip_reason を含めるcc:WIP に更新[skip:tdd] なし & テストFW存在時):
a. テストファイルを先に作成(Red)
b. 失敗を確認
c. bash "${HARNESS_PLUGIN_ROOT}/scripts/log-tdd-red.sh" で .claude/state/tdd-red-log/<task-id>.jsonl に FAIL 証跡を残す。script が利用できない環境では、literal な failing test output を worker-report の self_review evidence に添付する
d. --tdd-bypass を使う場合は、HARNESS_TDD_BYPASS=1 と HARNESS_TDD_BYPASS_REASON="<理由>" を明示し、TDD を省略した理由を sprint-contract / worker-report に残すnode "${HARNESS_PLUGIN_ROOT}/scripts/generate-sprint-contract.js" <task-id> で sprint-contract.json を生成bash "${HARNESS_PLUGIN_ROOT}/scripts/enrich-sprint-contract.sh" で加え、bash "${HARNESS_PLUGIN_ROOT}/scripts/ensure-sprint-contract-ready.sh" で approved を確認needs-spike / security-sensitive / state-migration)は、初回実行前に 1 回だけ相談するPIVOT_REQUIRED を返した時は、ユーザーへ止めて投げる前に 1 回だけ相談するadvisor-response.v1 で受け取り、PLAN は進め方の組み替え、CORRECTION は局所修正、STOP は即エスカレーションとして扱うtrigger_hash では 1 回しか相談しない。task ごとの相談回数は最大 3 回claude: local / native Read/Write/Edit/Bash path で実装cursor / codex: 上記 companion worktree path で実装し、companion-result.v1 を共通 review loop に渡す/simplify で Auto-Refinement(--no-simplify で省略可)sprint-contract.json の reviewer_profile が runtime の場合は bash "${HARNESS_PLUGIN_ROOT}/scripts/run-contract-review-checks.sh" を実行MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3)bash "${HARNESS_PLUGIN_ROOT}/scripts/write-review-result.sh" で review artifact を正規化して保存(browser profile は --browser-result を渡し、browser_verdict == PENDING_BROWSER の時は static verdict を採用)git commit で自動コミット(--no-commit で省略可)cc:完了 に更新(commit hash 付与)git log --oneline -1 で直近の commit hash(短縮形 7 文字)を取得cc:完了 [a1b2c3d] 形式で更新--no-commit 時)は hash なしで cc:完了 のみCompletion Report Output Contract と references/completion-report.md を参照)--parallel N で強制)[P] マーク付きタスクを N ワーカーで並列実行。
--parallel N で明示指定した場合は、タスク数に関係なくこのモードを使用。
同一ファイルへの書き込みが競合する場合は git worktree で分離。
各 task の実装 executor は Backend-resolved executor path に従う。
--parallel N --cursor、--backend cursor、または default HARNESS_IMPL_BACKEND=cursor の場合、Parallel でも native Worker spawn ではなく task ごとの Cursor companion worktree を使う。
--codex 明示時のみ)公式プラグイン codex-plugin-cc の companion 経由で Codex CLI にタスクを委託する。
# タスク委託(書き込み可能・worktree 分離)
BASE_REF="$(git rev-parse HEAD)"
WT_ID="codex-$(date +%Y%m%d-%H%M%S)-$$"
WORKTREE_PATH=".claude/worktrees/${WT_ID}"
git worktree add -b "codex-work/${WT_ID}" "$WORKTREE_PATH" "$BASE_REF"
CODEX_MODEL_TIER=worker HARNESS_CODEX_PRIMARY_ENV_STATE_FILE="$WORKTREE_PATH/.claude/state/codex-primary-environment.json" \
bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write -C "$WORKTREE_PATH" \
"タスク内容。完了前にこの worktree で exactly one git commit を作成してください。"
# stdin 経由(大きなプロンプト向け)
CODEX_PROMPT=$(mktemp /tmp/codex-prompt-XXXXXX.md)
# タスク内容を書き出し
cat "$CODEX_PROMPT" | CODEX_MODEL_TIER=worker HARNESS_CODEX_PRIMARY_ENV_STATE_FILE="$WORKTREE_PATH/.claude/state/codex-primary-environment.json" \
bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write -C "$WORKTREE_PATH"
rm -f "$CODEX_PROMPT"
# Lead review 後に承認されたら range を取り込む
git -C "$WORKTREE_PATH" diff "$BASE_REF..HEAD"
WORKTREE_HEAD="$(git -C "$WORKTREE_PATH" rev-parse HEAD)"
git cherry-pick --no-commit "$BASE_REF..$WORKTREE_HEAD"companion は App Server Protocol 経由で Codex と通信し、 Job 管理・thread resume・構造化出力を提供する。 結果を検証し、品質基準を満たさない場合は自力で修正。
--breezing で強制)Lead / Worker / Advisor / Reviewer の役割分離でチーム実行する。
Codex host の Breezing は resolver result に従う。配布 plugin のフラグなし fallback は claude なので、
spawn_agent, wait_agent, send_input, close_agent を使った Codex native subagent orchestration が互換既定。
--backend cursor / --cursor、または user/project config の HARNESS_IMPL_BACKEND=cursor がある時だけ
cursor-companion.sh で Cursor worker に委託する。
古い TeamCreate / TaskCreate ベースの説明は採らない。
Go opt-in の HARNESS_TEAM_HIERARCHY=sublead は CLI mini-plan 入口未実装、HARNESS_REVIEW_ITERATE=on は production brain runner 未提供のため未対応。この更新では有効化せず既定 flat / OFF を維持する。通常の Skill / Native loop と手動 Producer 分解は別経路である。
権限ポリシー:
bypassPermissions--auto-mode は互換な親セッション向けの opt-in rollout フラグとして扱うpermissions.defaultMode や agent frontmatter の permissionMode には未文書化の autoMode 値を書かないCC v2.1.69+: nested teammates はプラットフォーム側で禁止されるため、 Worker/Reviewer プロンプトには冗長な nested 防止文言を追加しない。
Lead (this agent)
├── Worker (resolver result: Codex native spawn_agent / codex-companion / cursor-companion) — 実装担当
├── Advisor (claude-code-harness:advisor) — 方針助言
└── Reviewer (code-reviewer agent) — レビュー担当Phase A: Pre-delegate(準備):
docs/spec/00-project-spec.md または既存 spec を実装前に更新node "${HARNESS_PLUGIN_ROOT}/scripts/generate-sprint-contract.js" で sprint-contract.json を生成bash "${HARNESS_PLUGIN_ROOT}/scripts/enrich-sprint-contract.sh" で Reviewer 観点を加え、bash "${HARNESS_PLUGIN_ROOT}/scripts/ensure-sprint-contract-ready.sh" で未承認なら停止Phase B: Delegate(Worker spawn → 必要時 Advisor → レビュー → cherry-pick):
各タスクについて以下を逐次実行する(依存順):
API 注記: 以下は Codex native の subagent API 構文で記述する。 backend=
claudeの時だけspawn_agent(...),send_input(...),wait_agent(...),close_agent(...)をそのまま使う。 backend=cursor/codexの時は Worker agent を spawn せず、Lead が companion を直接呼ぶ。 Claude Code 向けのサブエージェント構文やメッセージ送信構文は混ぜない。
for task in execution_order:
# B-0. backend 解決(配布 fallback は claude、user/project default で cursor 可)
resolver_backend_arg = ""
if explicit_backend_value in ["claude", "codex", "cursor"]:
resolver_backend_arg = "--backend {explicit_backend_value}"
backend = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh\" {resolver_backend_arg}")
if explicit_flag == "--cursor":
backend = "cursor"
if explicit_flag == "--codex":
backend = "codex"
# B-1. sprint-contract を生成
contract_path = bash("node \"${HARNESS_PLUGIN_ROOT}/scripts/generate-sprint-contract.js\" {task.number}")
contract_path = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/enrich-sprint-contract.sh\" {contract_path} --check \"DoD を reviewer 観点で確認\" --approve")
bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/ensure-sprint-contract-ready.sh\" {contract_path}")
# B-2. Worker 委託(worktree 分離)
Plans.md: task.status = "cc:WIP" # 着手時に更新(未着手タスクは cc:TODO のまま)
if backend == "cursor":
BASE_REF = git("rev-parse", "HEAD")
WT_ID = "{task.number}-$(date +%Y%m%d-%H%M%S)-$$"
worktree_path = ".claude/worktrees/cursor-{WT_ID}"
worktree_branch = "cursor-work/{WT_ID}"
bash("mkdir -p .claude/worktrees && git worktree add -b {worktree_branch} {worktree_path} {BASE_REF}")
print("🚀 cursor / $(bash \"${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh\" --host cursor --role worker --field model) / {branch} / {task.number}")
companion_prompt = "{task prompt}\n\nAfter making changes, create exactly one git commit in this worktree before returning."
companion_output = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh\" task --write --workspace {worktree_path} \"{companion_prompt}\"")
latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
if git("-C", worktree_path, "status", "--porcelain") != "":
git("-C", worktree_path, "add", "-A")
git("-C", worktree_path, "-c", "user.name=cursor-composer", "-c", "user.email=cursor-composer@local", "commit", "--no-verify", "-m", "cursor: delegated change")
latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
if latest_commit == BASE_REF:
raise EscalationError("cursor companion produced no commit")
worker_result = {type: "companion-result.v1", baseCommit: BASE_REF, commit: latest_commit, worktreePath: worktree_path, branch: worktree_branch, files_changed: git("-C", worktree_path, "diff", "--name-only", "{BASE_REF}..HEAD"), summary: companion_output}
worker_id = null
elif backend == "codex":
BASE_REF = git("rev-parse", "HEAD")
WT_ID = "{task.number}-$(date +%Y%m%d-%H%M%S)-$$"
worktree_path = ".claude/worktrees/codex-{WT_ID}"
worktree_branch = "codex-work/{WT_ID}"
bash("mkdir -p .claude/worktrees && git worktree add -b {worktree_branch} {worktree_path} {BASE_REF}")
companion_prompt = "{task prompt}\n\nAfter making changes, create exactly one git commit in this worktree before returning."
companion_state_file = "{worktree_path}/.claude/state/codex-primary-environment.json"
companion_output = bash("CODEX_MODEL_TIER=worker HARNESS_CODEX_PRIMARY_ENV_STATE_FILE={companion_state_file} bash \"${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh\" task --write -C {worktree_path} \"{companion_prompt}\"")
latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
if latest_commit == BASE_REF:
raise EscalationError("codex companion produced no commit")
worker_result = {type: "companion-result.v1", baseCommit: BASE_REF, commit: latest_commit, worktreePath: worktree_path, branch: worktree_branch, files_changed: git("-C", worktree_path, "diff", "--name-only", "{BASE_REF}..HEAD"), summary: companion_output}
worker_id = null
else:
print("🚀 claude / native-subagent / {branch} / {task.number}")
worker_id = spawn_agent({
agent_type: "worker",
message: "タスク: {task.内容}\n目的と理由: {purpose_and_why}\n担当範囲: {owned_paths_and_non_goals}\nDoD: {task.DoD}\nplan_path: {selected_plan_path}\ncontract_path: {contract_path}\nspec_path: {spec_path}\nspec_skip_reason: {spec_skip_reason}\n証拠と前回結果: {evidence_and_prior_advice}\n原依頼と承認の参照: {authorization_references}\nmode: breezing\n\n担当範囲で方法を選び、他担当の変更を戻さず、承認済み作業を完了してください。作業は分離 worktree で行い、完了後に git commit してください。\n完了時は {commit, worktreePath, branch, files_changed, summary} を返し、summary に判断理由、チェックの実結果と証拠の参照、未確認点を含めてください。",
fork_turns: "3"
})
worker_result = wait_agent({ targets: [worker_id] })
# worker_result には {commit, worktreePath, branch, files_changed, summary} が含まれる
# backend=cursor/codex では Lead が companion stdout を companion-result.v1 に正規化する。
# B-3. Worker が advice request を返した時だけ、Lead が Advisor を呼ぶ
if backend == "claude" and worker_result.type == "advisor-request.v1":
advisor_id = spawn_agent({
message: worker_result.request_json,
agent_type: "default"
})
advisor_result = wait_agent({ targets: [advisor_id] })
close_agent({ target: advisor_id })
send_input({
target: worker_id,
message: "advisor-response.v1: {advisor_result}"
})
worker_result = wait_agent({ targets: [worker_id] })
# B-4. Lead がレビュー実行(Codex exec 優先)
if backend == "claude":
diff_text = git("-C", worker_result.worktreePath, "show", worker_result.commit)
else:
diff_text = git("-C", worker_result.worktreePath, "diff", "{worker_result.baseCommit}..HEAD")
verdict = codex_exec_review(diff_text) or reviewer_agent_review(diff_text)
profile = jq(contract_path, ".review.reviewer_profile")
review_input = "review-output.json"
if profile == "runtime":
review_input = bash("cd {worker_result.worktreePath} && bash \"${HARNESS_PLUGIN_ROOT}/scripts/run-contract-review-checks.sh\" {contract_path}")
runtime_verdict = jq(review_input, ".verdict")
if runtime_verdict == "REQUEST_CHANGES":
verdict = "REQUEST_CHANGES"
elif runtime_verdict == "DOWNGRADE_TO_STATIC":
pass # runtime 検証コマンドなし → static verdict をそのまま使う
browser_result = ""
if profile == "browser":
# browser artifact から route / browser_mode / execution_instructions を再利用して browser runner を起動する。
browser_artifact = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/generate-browser-review-artifact.sh\" {contract_path}")
browser_result = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/browser-review-runner.sh\" {browser_artifact}")
browser_verdict = jq(browser_result, ".browser_verdict")
if browser_verdict == "REQUEST_CHANGES":
verdict = "REQUEST_CHANGES"
elif browser_verdict == "APPROVE" and verdict != "REQUEST_CHANGES":
verdict = "APPROVE"
# browser_verdict == PENDING_BROWSER のときは static verdict を維持する
# review_input が DOWNGRADE_TO_STATIC の場合は static review 結果を使う
if review_input != "review-output.json" and jq(review_input, ".verdict") == "DOWNGRADE_TO_STATIC":
review_input = "review-output.json" # static review の結果にフォールバック
bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/write-review-result.sh\" {review_input} {latest_commit} --browser-result {browser_result}")
# B-5. 修正ループ(REQUEST_CHANGES 時、contract の max_iterations まで)
review_count = 0
# sprint-contract が存在するときのみ max_iterations を読む。存在しない場合は 3(後方互換)
MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3
latest_commit = worker_result.commit
while verdict == "REQUEST_CHANGES" and review_count < MAX_REVIEWS:
if backend == "claude":
send_input({
target: worker_id,
message: "指摘内容: {issues}\n元の目的、DoD、担当範囲、承認を維持し、対応と検証証拠を返してください。修正して amend してください"
})
# Worker が修正 → amend → 更新された commit hash を返す
updated_result = wait_agent({ targets: [worker_id] })
latest_commit = updated_result.commit
elif backend == "cursor":
previous_commit = latest_commit
companion_output = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh\" task --write --workspace {worker_result.worktreePath} \"{task prompt}\n\nReview findings:\n{issues}\n\nPreserve the original DoD, owned scope and authorization references. Fix the findings and commit the result.\"")
latest_commit = git("-C", worker_result.worktreePath, "rev-parse", "HEAD")
if git("-C", worker_result.worktreePath, "status", "--porcelain") != "":
git("-C", worker_result.worktreePath, "add", "-A")
git("-C", worker_result.worktreePath, "-c", "user.name=cursor-composer", "-c", "user.email=cursor-composer@local", "commit", "--no-verify", "-m", "cursor: review fix")
latest_commit = git("-C", worker_result.worktreePath, "rev-parse", "HEAD")
if latest_commit == previous_commit:
raise EscalationError("cursor companion retry produced no new commit")
worker_result.commit = latest_commit
worker_result.summary = companion_output
else:
previous_commit = latest_commit
companion_state_file = "{worker_result.worktreePath}/.claude/state/codex-primary-environment.json"
companion_output = bash("CODEX_MODEL_TIER=worker HARNESS_CODEX_PRIMARY_ENV_STATE_FILE={companion_state_file} bash \"${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh\" task --write -C {worker_result.worktreePath} \"{task prompt}\n\nReview findings:\n{issues}\n\nPreserve the original DoD, owned scope and authorization references. Fix the findings and commit the result.\"")
latest_commit = git("-C", worker_result.worktreePath, "rev-parse", "HEAD")
if latest_commit == previous_commit:
raise EscalationError("codex companion retry produced no new commit")
worker_result.commit = latest_commit
worker_result.summary = companion_output
if backend == "claude":
diff_text = git("-C", worker_result.worktreePath, "show", latest_commit)
else:
diff_text = git("-C", worker_result.worktreePath, "diff", "{worker_result.baseCommit}..HEAD")
verdict = codex_exec_review(diff_text) or reviewer_agent_review(diff_text)
review_count++
# B-6. Worker 終了
if backend == "claude":
close_agent({ target: worker_id })
# B-7. APPROVE → trunk に cherry-pick(feature ブランチ経由)
# Worker の Branch Guard により trunk HEAD は動かず、commit は feature ブランチ上にある想定
if verdict == "APPROVE":
TRUNK=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||' || echo "main")
git checkout "$TRUNK" # safety: 既に trunk なら no-op
# feature ブランチの commit が既に trunk にある(Branch Guard 失敗時のフォールバック)か確認
if git("merge-base", "--is-ancestor", latest_commit, "HEAD"):
pass # 既に trunk 上 — cherry-pick 不要(再入防止)
else:
if backend == "claude":
git cherry-pick --no-commit {latest_commit} # feature branch → trunk
else:
git cherry-pick --no-commit {worker_result.baseCommit}..{latest_commit} # companion range → trunk
git commit -m "{task.内容}"
# Worker の worktree を remove してから feature ブランチを削除
if worker_result.worktreePath:
git worktree remove {worker_result.worktreePath} --force
if worker_result.branch and worker_result.branch not in ["main", "master"] and worker_result.branch != TRUNK:
git branch -D {worker_result.branch}
Plans.md: task.status = "cc:完了 [{hash}]"
# auto-checkpoint 記録(冪等性ガード (c))
# Plans.md 書き換え直後に呼ぶ。失敗しても fail-open(|| true)でループを止めない
HASH=$(git rev-parse --short HEAD)
REVIEW_RESULT_PATH=".claude/state/review-results/${task.number}.review-result.json"
bash "${HARNESS_PLUGIN_ROOT}/scripts/auto-checkpoint.sh" \
"${task.number}" "${HASH}" "${contract_path}" "${REVIEW_RESULT_PATH}" \
|| true # fail-open: harness-mem 未起動環境でも継続
else:
→ ユーザーにエスカレーション
# B-8. Progress feed
print("📊 Progress: Task {completed}/{total} 完了 — {task.内容}")bin/harness work-mode)Claude Code 版と同一の契約(正本: skills/harness-work/SKILL.md の同名節)。
R04/R05 の確認 skip が読む ctx.WorkMode は SQLite work_states 行でのみ立てられる
(HARNESS_WORK_MODE / ULTRAWORK_MODE env は skill から設定できない)。
Lead は Phase A 開始前(solo 実行では最初の実装アクション前)に bin/harness work-mode on を実行し、
run 終了時は成功・失敗・中断の全経路で bin/harness work-mode off を実行する。run 単位で 1 回のみ。
session ID が解決できない場合、work-mode は非ゼロ終了し理由を stderr に出す。
Advisor は「実装者」でも「レビュー担当」でもない。 迷った時だけ、実行役が次の一歩を決めるための相談役として入る。
advisor-request.v1 を返すPLAN / CORRECTION / STOP のどれかを返すsolo 実行では親セッション自身が Lead を兼ねる。 つまり「自分で実装し、自分で advisor に相談し、最後は独立レビューに回す」形になる。
STOP はその場で止まり、ユーザー判断へ上げるsprint-contract は「このタスクを何で合格にするか」を機械でも人でも同じ意味で読める形にする小さな契約ファイルです。
既定の保存先は .claude/state/contracts/<task-id>.sprint-contract.json です。
node "${HARNESS_PLUGIN_ROOT}/scripts/generate-sprint-contract.js" 32.1.1生成物には次を含めます。
checks: DoD を分解した確認項目non_goals: 今回やらないことruntime_validation: test, lint, typecheck などの検証コマンド
browser_validation: browser reviewer が残すべき UI フロー検証項目browser_mode: scripted または exploratoryroute: browser reviewer が playwright / agent-browser / chrome-devtools のどれを使うかrisk_flags: needs-spike, security-sensitive, ux-regression などreviewer_profile: static, runtime, browserPhase C: Post-delegate(統合・報告):
Completion Report Output Contract と references/completion-report.md の Breezing テンプレート)を出力CI が失敗した場合:
タスク完了後にテスト/CI が失敗した場合、修正タスク案を自動生成し、承認後に Plans.md へ反映する:
| 条件 | アクション |
|---|---|
cc:完了 後にテスト失敗 | 修正タスク案を state に保存し、承認を待つ |
| CI 失敗(3回未満) | 修正を実施し、失敗カウントをインクリメント |
| CI 失敗(3回目) | 修正タスク案を提示 + エスカレーション |
.claude/state/pending-fix-proposals.jsonl に修正タスク案を保存:
.fix サフィックス(例: 26.1.fix)fix: [元タスク名] - [失敗原因カテゴリ]approve fix <task_id> を送ると Plans.md に cc:TODO で追加reject fix <task_id> で提案を破棄。pending が1件だけのときは yes / no でも応答可能実装完了後(ステップ 5 の後)に自動実行される品質検証ステージ。 全モード共通(Solo / Parallel / Breezing)で統一的に適用される。 Parallel モードでは各 Worker が step 10(外部レビュー受付)として同じループを実行する。
1. Codex exec(優先)
↓ codex コマンドが存在しない or タイムアウト(120s)
2. 内部 Reviewer agent(フォールバック)レビュアーには以下の閾値基準を渡し、この基準のみで verdict を判定させる。
基準外の改善提案は recommendations として返すが、verdict には影響しない。
| 重要度 | 定義 | verdict への影響 |
|---|---|---|
| critical | セキュリティ脆弱性、データ損失リスク、本番障害の可能性 | 1 件でも → REQUEST_CHANGES |
| major | 既存機能の破壊、仕様との明確な矛盾、テスト不通過 | 1 件でも → REQUEST_CHANGES |
| minor | 命名改善、コメント不足、スタイル不統一 | verdict に影響しない |
| recommendation | ベストプラクティス提案、将来の改善案 | verdict に影響しない |
重要: minor / recommendation のみの場合は 必ず APPROVE を返すこと。 「あったほうが良い改善」は REQUEST_CHANGES の理由にならない。
タスク開始時の HEAD を BASE_REF として保持し、その ref との差分をレビュー対象にする。
公式プラグイン codex-plugin-cc の companion review を使用する。
# タスク開始時に base ref を記録(Step 2 の cc:WIP 更新前に実行)
BASE_REF=$(git rev-parse HEAD)
# ... 実装完了後 ...
# 公式プラグインの構造化レビューを実行
bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" review --base "${BASE_REF}"
REVIEW_EXIT=$?verdict マッピング(公式プラグイン → Harness 形式):
公式プラグインは review-output.schema.json 準拠の構造化出力を返す。
Harness の verdict 形式への変換ルール:
| 公式 plugin | Harness | verdict 影響 |
|---|---|---|
approve | APPROVE | - |
needs-attention | REQUEST_CHANGES | - |
findings[].severity: critical | critical_issues[] | 1件でも → REQUEST_CHANGES |
findings[].severity: high | major_issues[] | 1件でも → REQUEST_CHANGES |
findings[].severity: medium/low | recommendations[] | verdict に影響しない |
AI Residuals スキャンは引き続き bash "${HARNESS_PLUGIN_ROOT}/scripts/review-ai-residuals.sh" で実行し、
companion review の結果と合わせて最終 verdict を判定する。
# AI Residuals スキャン(companion review と並行実行可能)
AI_RESIDUALS_JSON="$(bash "${HARNESS_PLUGIN_ROOT}/scripts/review-ai-residuals.sh" --base-ref "${BASE_REF}" 2>/dev/null || echo '{"tool":"review-ai-residuals","scan_mode":"diff","base_ref":null,"files_scanned":[],"summary":{"verdict":"APPROVE","major":0,"minor":0,"recommendation":0,"total":0},"observations":[]}')"Codex exec が使えない場合(command -v codex が失敗、または exit code ≠ 0):
Agent tool: subagent_type="reviewer"
prompt: "対象変更を read-only でレビューしてください。原依頼と目的: {request_and_purpose}。担当範囲: {review_scope}。仕様とDoD: {spec_path_and_contract_path}。検証証拠: {evidence_paths}。判定基準: critical/major → REQUEST_CHANGES、minor/recommendation のみ → APPROVE。diff: {git diff ${BASE_REF}}。自己申告ではなく現物に照らし、指摘の場所、発生条件、影響、根拠を返してください。"Reviewer agent は Read-only(Write/Edit/Bash 無効)で安全にレビューを実行する。
review_count = 0
# sprint-contract が存在するときのみ max_iterations を読む。存在しない場合は 3(後方互換)
contract_path = get_sprint_contract_path() # 例: .claude/state/contracts/<task-id>.sprint-contract.json
MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3
while verdict == "REQUEST_CHANGES" and review_count < MAX_REVIEWS:
1. レビュー指摘を解析(critical / major のみ対象)
2. 各指摘に対して修正を実装
3. 再度レビューを実行(同じ判定基準・同じ優先順位)
review_count++
if review_count >= MAX_REVIEWS and verdict != "APPROVE":
→ ユーザーにエスカレーション
→ 「MAX_REVIEWS 回修正しましたが以下の critical/major 指摘が残っています」+ 指摘一覧を表示
→ ユーザー判断を待つ(続行 / 中断)Breezing モードでは Lead がレビューループを実行する(上記 Phase B 参照):
send_input で Worker に修正指示し、wait_agent で再応答を待つ → Worker が amendMAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3 回まで)cc:完了 [{hash}] に更新Before rendering a Solo, forced single-task Parallel, or Breezing completion report:
get_harness_locale function from
${HARNESS_PLUGIN_ROOT}/scripts/config-utils.sh. Pass an explicit session or
user language as its optional argument; otherwise keep the resolver priority
of project i18n.language, CLAUDE_CODE_HARNESS_LANG, then default en.en render the English template.ja renders the Japanese template.references/completion-report.md and render exactly one template for
the selected mode and locale.harness-plan — 実行するタスクを計画するharness-sync — 実装と Plans.md を同期するharness-review — 実装のレビューharness-release — バージョンバンプ・リリース2b2b748
Canonical home
since Jul 27, 2026
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.