version: "1.0.1" name: harness-work description: "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." description-en: "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." description-ja: "HAR:Plans.md タスクを1件から全並列チーム実行まで担当。実装して、実行して、全部やって、breezing、チーム実行、parallel、composer、コンポーザー、composer 2.5 で起動。プランニング・レビュー・リリース・セットアップには使わない。" kind: workflow purpose: "Execute Plans.md tasks end to end" trigger: "implement, execute, do everything, breezing, team run, parallel, composer, composer 2.5, composer mode, コンポーザー" shape: workflow role: executor pair: harness-review owner: harness-core since: "2026-05-05" allowed-tools: ["Read", "Write", "Edit", "Grep", "Glob", "Bash", "Task", "Monitor"] argument-hint: "[all] [task-number|range] [--codex] [--parallel N] [--no-commit] [--resume id] [--breezing] [--auto-mode] [--tdd-bypass]" user-invocable: true effort: high

Harness Work

Harness の統合実行スキル。 以下の旧スキルを統合:

• work — Plans.md タスクの実装（スコープ自動判断）
• impl — 機能実装（タスクベース）
• breezing — チームフル自動実行
• parallel-workflows — 並列ワークフロー最適化
• ci — CI 失敗時の復旧

Quick Reference

Execution Mode Auto Selection（フラグなし時の自動判定）

明示的なモードフラグ（--parallel, --breezing, --codex）がない場合、 対象タスク数に応じて最適なモードを自動選択する:

ルール

1. 明示フラグは常にオートモードを上書きする（--parallel N / --breezing / --codex はタスク数に関係なく強制）
2. `--codex` は明示時のみ発動。Codex CLI が未インストールの環境があるため、自動選択しない
3. --codex は他モードと組み合わせ可能: --codex --breezing → Codex + Breezing

Execution Backend Selection（実装バックエンド選択）

バックエンド（どのランタイムが実装するか）は、実行モード（トポロジー: solo / parallel / breezing）と直交する。

Codex 呼び出しのガバナンス詳細（禁止事項・verdict マッピング等）は references/codex-cli-only.md を参照。

run 開始時に resolver で 1 回だけ解決する。HARNESS_IMPL_BACKEND env を直接読んで backend を決めてはならない:

bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh"

precedence（高い順）: 明示フラグ（--backend / --cursor / --codex） > env > project file > user file > 既定 claude。プロジェクト設定はユーザースコープを上書きする。

Backend 既定（claude は意図された既定、警告は不正値 fallback 時のみ）

既定 backend は claude（Native subagent）。resolver の未設定 fallback も claude であり、正常に claude へ解決された場合に警告は出さない（2026-07-24 operator 裁定。フォーマットは breezing の Narration Rules「Backend 既定と per-run のフラット判断」と同一、cross-ref: skills/breezing/SKILL.md）。

• ⚠️ 警告を出すのは resolver が 不正値 fallback の stderr 警告を出した時だけ。banner 直後に 1 行、同一 run 内で繰り返さない
• Lead は作業内容・量に応じて per-run で backend をフラットに選んでよい。選ぶ時は resolver への明示 override（--backend <v> / --codex / --cursor）を使う
• composer / コンポーザー / composer 2.5 等の自然言語表現は --cursor と同じ intent として扱い、resolver に --backend cursor を明示 override で渡す（自然言語 backend trigger）

バックエンドは role-scoped: 解決済みバックエンドに従うのは実装（worker）ロールのみ。Reviewer / Advisor は常に brain（--host claude）固定（primary reviewer を cursor/codex に routing しない）。例外は fresh-context advisory pre-review のみ: diff を生成した session と会話状態を共有しない cursor review tier が advisory findings を出すことは許可、primary verdict（APPROVE | REQUEST_CHANGES）は brain のみが出す。

bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host cursor --role worker --field model
bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host claude --role reviewer --field model

backend が codex / cursor の場合、Lead は Worker agent を spawn せず companion を直接呼ぶ（Worker 介在なしトポロジー）。self_review ゲートはスキップし、Lead の diff レビューが唯一の品質ゲートになる。委託前に cursor backend banner を出力し、cherry-pick 前に contract grep 二段ゲート（test-support-claim-wording.sh / check-consistency.sh / validate-plugin.sh）を通す。Mode 1 の Producer → Sub-Lead → Composer 階層、review→iterate ループの詳細は references/backend-selection.md を参照。

オプション

Progressive Disclosure

実行依頼は、目的と理由、担当範囲、検証可能な DoD、選択した plan / spec、観測済み証拠、原依頼と適用される承認の参照を渡す。 以降の {task prompt} と companion のタスク本文にはこれらを含める。再試行でも元の範囲と条件を残し、追加の finding や advisor response だけで置き換えない。 方法は担当が選ぶ。承認済みの可逆作業を再確認で止めず、不足情報は契約と読み取り調査で回収する。軽微な仮定は明示し、重大な仕様判断や不足する権限に依存する操作だけ止める。 評価・相談だけの依頼から実装を開始しない。推定した変更範囲は保護操作の承認ではない。 独立して検証できる作業を、担当ファイルと同時実行上限を明記して委譲する。他担当の編集を戻さず、関連する follow-up は同じ担当へ返す。Lead も仕様調査や証拠照合を進める。 必須チェックと既定レビューを完了した後は、新しい変更、失敗、未解決の懸念がない限り追加テストや機能を増やさない。 完了報告は実際の差分と検証結果で支え、自己申告だけで完了を判定しない。理由と参照可能な証拠を返し、内部の思考過程は求めない。

まずこの本文で入口、自動選択、停止条件だけを確認する。詳細は必要になった時だけ読む。

重要停止条件

• Plans.md が旧フォーマットで DoD / Depends / Status を読めない時は停止する。
• 仕様が実装判断に影響するのに project spec SSOT が見つからない時は、先に仕様正本を作成/更新してから実装する。
• sprint-contract が required なのに ready でない時は実装に進まない。
• critical / major review finding が残っている時は完了にしない。
• テストを弱める、skip する、期待値を実装に合わせて緩める形では解決しない。
• helper script は host project の scripts/ ではなく ${HARNESS_PLUGIN_ROOT}/scripts/ から呼ぶ。
• 複数 Plans.md がある場合は、1 run の中で plan を切り替えない。必要なら --plan NAME を明示して新しい run を開始する。

自主停止の禁止 (140.3、2026-08-22 の release run で 2 回発生した停止パターンの再発防止)

以下は禁止行動。literal に列挙する (AUTOSTART pattern と同じ方式):

• background 待ちで turn を終えて停止しない (turn を終えると background 子プロセスは残らない)
• 「検証を待ちます」「確認します」「完了を待機します」で turn を終えない
• 待つなら同期実行 (foreground / Monitor) で待ち切る。待てないものは保留として報告し、次のタスクへ進む

Token Optimization (v2.1.69+): git 操作を伴わない軽量タスクでは

plugin settings の includeGitInstructions: false を有効にしてプロンプトトークンを削減できる。

Prompt Cache (CC 2.1.108+): 長めの実装や --resume を多用する作業では

ENABLE_PROMPT_CACHING_1H=1 を優先する。

スコープダイアログ（引数なし時）

直前の明示依頼や選択済み plan で対象が確定していれば、その範囲を使う。以下の確認は対象範囲が未決の場合だけ行う。

/harness-work
どこまでやりますか?
1) 次のタスク: Plans.md の次の未完了タスク → Solo で実行
2) 全部（推奨）: 残りのタスクをすべて完了 → タスク数で自動モード選択
3) 番号指定: タスク番号を入力（例: 3, 5-7）→ 件数で自動モード選択

引数ありなら即実行（対話スキップ）:

• /harness-work all → 全タスク、自動モード選択
• /harness-work 3-6 → 4件なので Breezing 自動選択

モデルごとの推論量

effort は推論に使う量の指定。利用者の明示設定を優先し、未指定の担当は scripts/model-routing.sh の役割別設定を使う。 CCH のモデルと effort は未指定時の既定値であり、利用者の明示指定と手動変更を尊重する。AI が文言から再調整したり、親の変更を全 Worker へ配ったりしない。担当別 profile と独立 Reviewer の隔離契約は維持する。 Fable 5.1 の計画と相談は high。実装 worker と独立 reviewer は、それぞれの設定を使う。 複雑度スコアは見直しの判断材料であり、明示した推論量を自動変更する許可ではない。 free-text marker（旧 ultrathink）を spawn prompt に注入しない。

breezing モードでも同じロジックを適用する（harness-work が一本化して管理）。スコアリング内訳・lever の詳細は references/effort-routing.md を参照。

実行モード詳細

Harness helper script root

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 を前提にする。

Backend-resolved executor path (Solo / Parallel / Breezing)

Solo / Parallel / Breezing は同じ resolver result から実装 executor を選ぶ。 harness-work 3 --cursor や resolver 出力が cursor の run（project / user file 経由の default 含む）は、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_non_claude_companion_review_loop(worker_result)
else:
    run_native_solo_or_parallel()
 
def enter_non_claude_companion_review_loop(worker_result):
    # companion-result.v1 has no worker_id and no worker_result.self_review.
    # Do not use the Worker-only SendMessage/self_review loop for cursor/codex.
    latest_commit = worker_result.commit
    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 = 0
    MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3
    while verdict == "REQUEST_CHANGES" and review_count < MAX_REVIEWS:
        previous_commit = latest_commit
        if backend == "cursor":
            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.\"")
        else:
            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 backend == "cursor" and 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("{backend} companion retry produced no new commit")
        worker_result.commit = latest_commit
        worker_result.summary = companion_output
        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++
    if verdict == "APPROVE":
        git cherry-pick --no-commit {worker_result.baseCommit}..{worker_result.commit}

Parallel は task ごとにこの resolver path を適用する。 backend=cursor / codex の場合は native Worker spawn を使わず、task ごとに isolated companion worktree を作成して companion-result.v1 に正規化してから non-Claude companion 専用の range review / cherry-pick loop に入る。

Solo モード（1 件時の自動選択）

Plans.md 読み込みから cc:完了 [hash] までの 1〜17 ステップ完全版は references/execution-modes.md#solo-detailed-steps を参照。 要点: 仕様正本 preflight で spec SSOT の有無を確認し spec_path を Worker/Reviewer に渡す。plan-time 事前確認を適用し、 work 中の宣言済み事項起因 AskUserQuestion はゼロにする。TDD Red → sprint-contract → 実装 → レビューループ → commit → cc:完了 の順で進める。

Parallel モード（2〜3 件時の自動選択 / --parallel N で強制）

[P] マーク付きタスクを N ワーカーで並列実行。 --parallel N で明示指定した場合は、タスク数に関係なくこのモードを使用。

N は希望値で、実際の同時実行数は CC が決める（133.9、一次ソース確証済み）。CC は同時実行中の subagent を既定 20 に制限し（CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS、2.1.217）、超過分は待ち行列に 入るだけでエラーにはならない。ネストした spawn は既定で深さ 3 まで （CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH、2.1.219 で 1 → 3 に緩和）で、Lead（0）→ Worker（1）→ Worker が呼ぶ advisor（2）は収まる。これを超える階層は env で上げない限り静かに拒否される。 Harness 側はどちらの env も明示設定せず、CC の既定に従う。 同一ファイルへの書き込みが競合する場合は git worktree で分離。 各 task の実装 executor は Backend-resolved executor path に従う。 --parallel N --cursor、--backend cursor、または resolver 出力が cursor の場合、Parallel でも native Worker spawn ではなく task ごとの Cursor companion worktree を使う。

Codex モード（--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・構造化出力を提供する。 結果を検証し、品質基準を満たさない場合は自力で修正。

Cursor モード（adapter candidate、自動選択しない）

Cursor host では .cursor/AGENTS.md と .cursor-plugin/plugin.json が bootstrap route。Cursor は candidate のまま — supported claim は禁止。

• Solo / Parallel: Task tool または .cursor/agents/worker.md subagent
• Breezing: Worker 並列は non-overlapping file groups のみ;

Reviewer / cherry-pick / Advisor は core どおり直列

• Multitask / background agents: smoke target のみ。Claude Agent Teams parity

を主張しない

bash scripts/model-routing.sh --host cursor --role worker --format json
bash tests/test-cursor-adapter-candidate.sh

Explicit Task/subagent model が routed default より優先。

Breezing モード（4 件以上で自動選択 / --breezing で強制）

Lead / Worker / Advisor / Reviewer の役割分離でチーム実行する。 Codex では spawn_agent, wait, send_input, resume_agent, close_agent を使った native subagent orchestration を前提にする。 Cursor では Task/subagent/background agents へ mapping するが、 review/cherry-pick の直列責務は core 側に残す（adapter smoke target）。

権限ポリシー: 現行の shipped default は bypassPermissions。--auto-mode は互換な親セッション向けの opt-in rollout フラグ。 permissions.defaultMode や agent frontmatter の permissionMode には未文書化の autoMode 値を書かない。

Lead (this agent)
├── Worker (task-worker agent) — 実装担当
├── Advisor (claude-code-harness:advisor) — 方針助言
└── Reviewer (code-reviewer agent) — レビュー担当

Phase A（準備: Plans.md 読み込み・依存解決・plan-preapproval 適用・effort スコアリング・sprint-contract 生成）→ Phase B（各タスク: Worker spawn → 必要時 Advisor → self_review ゲート → レビューループ → APPROVE で trunk へ cherry-pick）→ Phase C（統合: commit log 集計・リッチ完了報告・Plans.md 最終確認）の 3 段構成。 完全版の pseudocode（B-1〜B-7 の逐次手順含む）は references/execution-modes.md#breezing-phase-detail を参照。

Active task scope

各タスクの preapproval preflight より前に、対象 worktree の .claude/state/active-task.json へ {"phase":"<phase>","task":"<task>"} を 原子的に書く。Go guardrail はこのファイルを現在スコープの正本として読む。 タスク終了時は成功、失敗、停止のどの経路でも削除する。環境変数 HARNESS_ACTIVE_PHASE / HARNESS_ACTIVE_TASK は、state ファイルが存在しない host の fallback に限る。

Parallel / Breezing ではタスクごとの worktree に書く。同じ worktree の active-task.json を複数タスクで共有しない。

Work Mode Lifecycle (bin/harness work-mode)

R04（project root 外への書き込み）/ R05（危険な rm）の確認 skip は ctx.WorkMode に依存するが、これを立てる経路は 2 つとも実効しない状態だった: HARNESS_WORK_MODE / ULTRAWORK_MODE env は skill / hook から設定する手段がなく、 state.SetWorkState（SQLite work_states 行）も呼び出し元が皆無だった。 bin/harness work-mode <on|off|status> がこの SQLite 経路を書く唯一の入口になる。

• Lead は run 開始時（Phase A 開始前、solo 実行では最初の実装アクション前）に

bin/harness work-mode on を実行する。--codex run では bin/harness work-mode on --codex（R07 = Lead の直接 Write/Edit 禁止が同時に立つ）

• Lead は run 終了時、成功・失敗・中断の全経路で bin/harness work-mode off を実行する。

active-task.json と同じ「終了時はどの経路でも後始末する」規律を適用する

• run 単位（Phase A〜C を通じて 1 回）であり、active-task.json のようなタスクごとの

書き込みではない。子 worktree で個別に on/off しない

• session ID の解決順は --session-id フラグ → HARNESS_SESSION_ID env

（SessionStart hook が CLAUDE_ENV_FILE 経由で export する実 session_id）→ .claude/state/last-session-id.json（鮮度 2 時間以内）。旧 .claude/state/session.json の内部 ID は guardrail が受け取る ID と一致しない ため受理されない。解決できない場合 work-mode は非ゼロ終了し理由を stderr に出す（無言で成功しない）

Advisor Protocol（全モード共通）

Advisor は「実装者」でも「レビュー担当」でもない。迷った時だけ、実行役が次の一歩を決めるための相談役として入る。

1. Worker は generic な subagent を増やさず、必要時だけ advisor-request.v1 を返す
2. Lead が advisor を 1 回だけ呼ぶ
3. Advisor は PLAN / CORRECTION / STOP のどれかを返す
4. Lead はその advice（advisor-response.v1）を同じ Worker に返して続行させる
5. Reviewer は最後の成果物だけを見る。advisor の返答に APPROVE / REQUEST_CHANGES を出さない

solo 実行では親セッション自身が Lead を兼ねる（自分で実装し、自分で advisor に相談し、最後は独立レビューに回す）。 相談条件・budget は breezing と同じで、task ごとの相談回数は最大 3 回。STOP はその場で止まり、ユーザー判断へ上げる。review artifact のゲートは飛ばさない。

Sprint Contract と PR Closeout

sprint-contract は「このタスクを何で合格にするか」を機械可読にする契約ファイル（既定: .claude/state/contracts/<task-id>.sprint-contract.json、generate-sprint-contract.js で生成）。 runtime_validation の LSP/AST ワークフロー方針:

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

spec_path / lane / stage / research_evidence / tdd_red_log / review_artifact / pr_closeout のフィールド仕様と、 review APPROVE 後の PR title/body 組み立て（harness-pr-closeout.sh、既定 dry-run）の詳細は references/sprint-contract.md を参照。

CI 失敗時の対応

CI が失敗した場合:

1. ログを確認してエラーを特定
2. 修正を実施
3. 同一原因で 3 回失敗したら自動修正ループを停止
4. 失敗ログ・試みた修正・残る論点をまとめてエスカレーション

失敗タスクの自動再チケット化

タスク完了後にテスト/CI が失敗した場合、修正タスク案を自動生成し、承認後に Plans.md へ反映する。 トリガー条件・生成フォーマット・承認コマンド（approve fix <task_id> / reject fix <task_id>）の詳細は references/failure-reticketing.md を参照。

レビューループ

実装完了後に自動実行される品質検証ステージ。全モード共通（Solo / Parallel / Breezing）で統一的に適用される。 優先順位（Codex exec → 内部 Reviewer agent フォールバック）、APPROVE / REQUEST_CHANGES 判定基準（critical/major のみが verdict に影響）、 verdict マッピング、修正ループ（MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3）の完全版は references/review-loop.md を参照。

Completion Report Output Contract

<!-- harness-work-completion-output-contract:start --> Before rendering a Solo, forced single-task Parallel, or Breezing completion report:

1. Resolve the active locale with the shared 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.

1. Unset, invalid, and resolved en render the English template.
2. Only resolved ja renders the Japanese template.
3. Japanese input alone does not select the Japanese template.
4. Read references/completion-report.md and render exactly one template for

the selected mode and locale.

1. Keep machine-readable status and review values in English, and never mix

English and Japanese labels in one report. <!-- harness-work-completion-output-contract:end -->

進捗の可視化（非エンジニア向け）

タスク実行中は harness-progress が進捗の件数と drift alert を 1 枚の HTML にまとめる。 PostToolUse hook で自動再生成されるため、発注者は呼び方を覚えずに最新の進捗ボードを見られる （posttool-progress-regen.sh が最大 1 分に 1 回再生成）。

関連スキル

• harness-plan — 実行するタスクを計画する
• harness-sync — 実装と Plans.md を同期する
• harness-review — 実装のレビュー
• harness-release — バージョンバンプ・リリース
• harness-progress — 進捗ボード HTML（非エンジニア向け、実行中に自動再生成）