Harness Work (v3)
Harness v3 の統合実行スキル。 以下の旧スキルを統合:
work— Plans.md タスクの実装（スコープ自動判断）impl— 機能実装（タスクベース）breezing— チームフル自動実行parallel-workflows— 並列ワークフロー最適化ci— CI 失敗時の復旧
Quick Reference
| ユーザー入力 | モード | 動作 |
|---|---|---|
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 | breezing | チーム実行を強制 |
Execution Mode Auto Selection（フラグなし時の自動判定）
明示的なモードフラグ（--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
オプション
| オプション | 説明 | デフォルト |
|---|---|---|
all | 全未完了タスクを対象 | - |
N or N-M | タスク番号/範囲指定 | - |
--parallel N | 並列ワーカー数 | auto |
--sequential | 直列実行強制 | - |
--codex | Codex CLI で実装委託（明示時のみ、自動選択しない） | false |
--no-commit | 自動コミット抑制 | false |
--resume <id|latest> | 前回セッション再開 | - |
--breezing | Lead/Worker/Reviewer のチーム実行 | false |
--no-tdd | TDD フェーズスキップ | false |
--no-simplify | Auto-Refinement スキップ | false |
--auto-mode | Auto Mode rollout を明示。親セッションの permission mode が互換な場合のみ採用を検討 | false |
Token Optimization (v2.1.69+): git 操作を伴わない軽量タスクでは plugin settings の
includeGitInstructions: falseを有効にして プロンプトトークンを削減できる。
スコープダイアログ（引数なし時）
harness-work
どこまでやりますか?
1) 次のタスク: Plans.md の次の未完了タスク → Solo で実行
2) 全部（推奨）: 残りのタスクをすべて完了 → タスク数で自動モード選択
3) 番号指定: タスク番号を入力（例: 3, 5-7）→ 件数で自動モード選択
引数ありなら即実行（対話スキップ）:
harness-work all→ 全タスク、自動モード選択harness-work 3-6→ 4件なので Breezing 自動選択
Effort レベル制御（v2.1.68+, v2.1.72 簡素化）
Claude Code v2.1.68 で Opus 4.6 は medium effort (◐) がデフォルト。
v2.1.72 で max レベルが廃止され、3段階 low(○)/medium(◐)/high(●) に簡素化。
/effort auto でデフォルトにリセット可能。
複雑なタスクには ultrathink キーワードで high effort (●) を有効化する。
多要素スコアリング
タスク着手時に以下のスコアを合算し、閾値 3 以上で ultrathink を注入:
| 要素 | 条件 | スコア |
|---|---|---|
| ファイル数 | 変更対象 4 ファイル以上 | +1 |
| ディレクトリ | core/, guardrails/, security/ を含む | +1 |
| キーワード | architecture, security, design, migration を含む | +1 |
| 失敗履歴 | agent memory に同タスクの失敗記録あり | +2 |
| 明示指定 | PM テンプレートに ultrathink 記載あり | +3（自動採用） |
注入方法
スコア ≥ 3 の場合、Worker spawn prompt の冒頭に ultrathink を追加。
breezing モードでも同じロジックが適用される（harness-work が一本化して管理）。
実行モード詳細
Solo モード（1 件時の自動選択）
- Plans.md を読み込み、対象タスクを特定
- Plans.md が存在しない場合:
Plans.md が見つかりません。harness-plan create で作成してください。→ 停止 - ヘッダーに DoD / Depends カラムがない場合:
Plans.md が旧フォーマットです。harness-plan create で再生成してください。→ 停止 1.5. タスク背景確認（30 秒）: - タスクの「内容」と「DoD」から 目的（このタスクが解く課題）を 1 行で推論表示
git grep/Globで 影響範囲（変更が及ぶファイル/モジュール）を推論表示- 推論に自信がある場合: そのまま実装に進む（フロー遅延なし）
- 推論に自信がない場合: ユーザーに 1 問だけ確認（「この理解で合っていますか？」）
- Plans.md が存在しない場合:
- タスクを
cc:WIPに更新 - TDD フェーズ（
[skip:tdd]なし & テストFW存在時）: a. テストファイルを先に作成（Red） b. 失敗を確認 - コードを実装（Green）（Read/Write/Edit/Bash）
/simplifyで Auto-Refinement（--no-simplifyで省略可）git commitで自動コミット（--no-commitで省略可）- タスクを
cc:完了に更新（commit hash 付与）git log --oneline -1で直近の commit hash（短縮形 7 文字）を取得- Plans.md の Status を
cc:完了 [a1b2c3d]形式で更新 - commit がない場合（
--no-commit時）は hash なしでcc:完了のみ
- 失敗時の自動再計画（テスト/CI 失敗時のみ）:
- テスト実行結果を確認
- 失敗した場合: 修正タスク案を state に保存し、承認コマンド経由で Plans.md に追加（「失敗タスクの自動再チケット化」参照）
- 成功した場合: 次タスクへ進む
Parallel モード（2〜3 件時の自動選択 / --parallel N で強制）
[P] マーク付きタスクを N ワーカーで並列実行。
--parallel N で明示指定した場合は、タスク数に関係なくこのモードを使用。
同一ファイルへの書き込みが競合する場合は git worktree で分離。
Codex モード（--codex 明示時のみ）
TIMEOUT=$(command -v timeout || command -v gtimeout || echo "")
CODEX_PROMPT=$(mktemp /tmp/codex-prompt-XXXXXX.md)
# タスク内容を一意なテンポラリファイルに書き出し
# stdin 経由で渡す（"-" は公式 stdin 指定。ARG_MAX 超過を回避）
cat "$CODEX_PROMPT" | $TIMEOUT 120 codex exec - -a never -s workspace-write 2>>/tmp/harness-codex-$$.log
rm -f "$CODEX_PROMPT"
タスク内容を一意なテンポラリファイルに書き出し、stdin 経由で Codex CLI に委託。 並列実行時もパスが衝突せず、大きなプロンプトも ARG_MAX に制約されない。 結果を検証し、品質基準を満たさない場合は自力で修正。
Breezing モード（4 件以上で自動選択 / --breezing で強制）
Lead / Worker / Reviewer の役割分離でチーム実行する。
Codex では spawn_agent, wait, send_input, resume_agent, close_agent
を使った native subagent orchestration を前提にし、
古い TeamCreate / TaskCreate ベースの説明を採らない。
権限ポリシー:
- 現行の shipped default は
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 (task-worker agent) — 実装担当
└── Reviewer (code-reviewer agent) — レビュー担当
フロー:
- Lead: タスク分割と subagent への割り当て
- Worker: 実装 →
cc:完了 [hash]（直近 commit hash 付与） - Reviewer: コードレビュー → APPROVE / REQUEST_CHANGES
- REQUEST_CHANGES の場合: 修正タスクを作成 → 再実装
CI 失敗時の対応
CI が失敗した場合:
- ログを確認してエラーを特定
- 修正を実施
- 同一原因で 3 回失敗したら自動修正ループを停止
- 失敗ログ・試みた修正・残る論点をまとめてエスカレーション
失敗タスクの自動再チケット化
タスク完了後にテスト/CI が失敗した場合、修正タスク案を自動生成し、承認後に Plans.md へ反映する:
トリガー条件
| 条件 | アクション |
|---|---|
cc:完了 後にテスト失敗 | 修正タスク案を state に保存し、承認を待つ |
| CI 失敗（3回未満） | 修正を実施し、失敗カウントをインクリメント |
| CI 失敗（3回目） | 修正タスク案を提示 + エスカレーション |
修正タスクの自動生成
- 失敗原因を分類（syntax_error / import_error / type_error / assertion_error / timeout / runtime_error）
.claude/state/pending-fix-proposals.jsonlに修正タスク案を保存:- 番号: 元タスク番号 +
.fixサフィックス（例:26.1.fix） - 内容:
fix: [元タスク名] - [失敗原因カテゴリ] - DoD: テスト/CI が通ること
- Depends: 元タスク番号
- 番号: 元タスク番号 +
- ユーザーが
approve fix <task_id>を送ると Plans.md にcc:TODOで追加 reject fix <task_id>で提案を破棄。pending が1件だけのときはyes/noでも応答可能
関連スキル
harness-plan— 実行するタスクを計画するharness-sync— 実装と Plans.md を同期するharness-review— 実装のレビューharness-release— バージョンバンプ・リリース