org-delegate: ワーカー派遣

作業をワーカーClaudeに委譲する。窓口はタスク分解と派遣ペイロード生成だけ行い、 ペイン起動・指示送信はディスパッチャーに委託する。これにより窓口のロック時間を最小化する。

本 SKILL のスコープ: 派遣の「初動」(タスク特定 → 派遣ペイロード生成 → ディスパッチャーへの DELEGATE 受け渡し → ワーカー起動後の挨拶 → 進捗・完了報告受信時の ack と REVIEW 遷移) のみ。以下は別スキル / reference に分離している:

• ワーカー起動・指示送信・状態記録の手順 → .dispatcher/references/spawn-flow.md (ディスパッチャー専属)
• ユーザー承認後の push / PR / CI 監視 / レビュー指摘ループ / マージ後クローズ → .claude/skills/org-pull-request/SKILL.md
• ワーカーからの判断仰ぎ / スコープ拡張 / ブロッカーのエスカレーション → .claude/skills/org-escalation/SKILL.md
• ack 文面の最低 3 要素・種別ごとの例文 → .claude/skills/org-delegate/references/ack-template.md (single SoT)

state-db cutover (M4, Issue #267 / #284): 構造化セクションの write は 必ず StateWriter.transaction() 経由で行う。post-commit hook が .state/org-state.md / .state/org-state.json を DB から自動再生成し、update_run_status('<task_id>', 'completed') 呼び出しは .state/workers/worker-<task_id>.md を .state/workers/archive/ へ自動 move する。markdown 直接編集は drift_check が検出する。events は DB の events テーブルが SoT (tools/journal_append.sh / .py は DB ルーティング済み)。DB 不在時は python3 -m tools.state_db.importer --db .state/state.db --rebuild --no-strict（Windows は py -3 -m ...） で構築する。

輸送層（transport）両系: 本スキルのツール参照は mcp__org-broker__*（org-broker）で書いてあり、active transport が既定面ならそのまま従えばよい（引数形・セマンティクスは両系同一で、手順の論理は変わらない）。輸送層で手順が変わるのは 受信モデル / spawn 儀式 / エラー分岐 の 3 点だけで、opt-in 側の輸送層は削除せず切戻しの安全装置として常時有効。両系の読み替え規則・契約の批准経緯・broker 固有エラーコードの一覧は .claude/skills/org-delegate/references/transport-duality.md を参照（上記 3 分岐に入るまで読む必要はない。コード一覧は .claude/skills/org-delegate/references/renga-error-codes.md）。

窓口とディスパッチャーの役割分担

工程	担当
プロジェクト名前解決	窓口
work-skill 検索	窓口
タスク分解 / 派遣ペイロード生成	窓口 (gen_delegate_payload.py)
DELEGATE 送信	窓口（ここで窓口は解放される）
ペイン起動・ピア待ち・指示送信・状態記録	ディスパッチャー (.dispatcher/references/spawn-flow.md)
窓口への派遣完了報告	ディスパッチャー
ワーカーからの進捗/完了/escalation 報告の受信	窓口
ワーカー完了時のペインクローズ	ディスパッチャー（窓口から CLOSE_PANE 依頼）

レーン選択判定（窓口が実行）

委譲前チェックリストに入る前に、まず このタスクをどのレーンで回すか を判定する。タスクルーティングは 2 レーン制で、原則（実作業は全てワーカーに委譲する）は維持しつつ、極小タスクに限った軽量レーンを例外に持つ。軽量レーンと ultracode 武装の条件は本節が正本（root CLAUDE.md は要約とポインタだけを持つ）。導入時のパイロット実績は .claude/skills/org-delegate/references/rationale.md §8。

レーン	発動条件	処理経路
軽量レーン（subagent 直処理）	以下を 全て 満たす: 推定工数 S 以下 / 単一ファイル級 / 判断仰ぎ想定なし / 日またぎなし	窓口が自身のセッションで Agent tool（isolation="worktree"、背景実行）を呼んで直処理。本 SKILL（org-delegate）の以降の手順には進まない（本節は routing 判定のみ。subagent 起動は窓口本体の文脈で行うため、本 skill の allowed-tools に Agent は不要）
重量レーン（ワーカー派遣）	軽量条件を 1 つでも満たさない、または下記いずれかに該当	本 SKILL を Step 0 から回し、ディスパッチャー経由でワーカーを派遣

重量レーンへ必ず倒すケース（軽量条件を一部満たしても優先）:

• 判断境界がある／escalation が想定される
• 日をまたぐ／その場で完結しない
• 常駐監視が要る（長時間の進捗追跡・介入判定が必要）

迷ったら重量レーンに倒す（軽量レーンは「明らかに極小」のときだけ）。

軽量レーンを選んだ場合の必須条件（省略不可）:

• 前景（同期）の Agent 起動は hook が deny する。代わりに背景で起動する（入力スキーマに run_in_background があるハーネスでだけ true を渡す）
• subagent 内で Codex レビューを in-loop で回し、Blocker/Major ゼロまで修正する（検証深度 full と同等のゲート）
• push・PR・merge の人間ゲートは従来どおり維持する（subagent が自動で push / PR / merge してはならない）

この節は routing 判定だけを担う。軽量レーンを選んだら委譲前チェックリスト〜Step 5 には進まず、窓口本体の文脈で Agent 直処理に移る。重量レーンを選んだ場合のみ、以下を続ける。

重量レーンの brief 強化（ultracode）: ultracode（multi-agent workflow）の許可は工数ラベル (S/M/L) では判定しない（工数は人間労働の代理指標で、AI ワーカーにとっての難しさとズレる）。重量レーンのうち以下のいずれかを満たすタスクでは、ワーカーに ultracode の使用を許可してよい（推奨）:

1. 実装中に設計判断が残る: 事前 design review で固定しきれない決定（実測しないと決められない契約・未知の移植先制約など）が実装フェーズに持ち越される
2. 敵対的検証の価値が高い: 「テストが緑でも守っていない」型の欠陥が出やすい性質（ガード・封印・契約 battery 等の enforcement 実装）
3. 所有排他で切れる並列構造: 独立サブタスクに分割でき、ファイル所有を排他にした並列レーンで実時間短縮が出る規模

量が多いだけの機械的タスク（設計固定済みの移植・定型変換）は、L 級でも非武装を既定とする。背景には週間 rate limit の資源管理もある（構造が正当化しない増幅を既定にしない）。

ガード・hook 実装タスクは ultracode を許可しない（分類器の締め出し対策、Issue #1153）: 上記基準 2 に当たっても、deny 規則・hook・封印など禁止対象のコマンド字面を会話に多く持ち込むタスク（例: push / 再帰削除を止める hook の修正）では ultracode を許可しない。auto-mode の安全分類器が会話内容に反応して Workflow 起動を拒否し、以降は無関係な Bash まで全拒否される事例が出ている（#1133 のワーカー）。brief の --impl-guidance には、禁止対象の字面を会話に大量展開せず file:line・テスト名で参照するよう 1 行添える。締め出されたワーカー（Bash が内容に関係なく全拒否される）は、言い換えでの再試行をさせず、窓口がワーカーペインに /clear を打鍵（text と Enter の別送）してから再開指示（CLAUDE.local.md / CLAUDE.md を読み直し、git log で進捗を確かめて続行）を送って復帰させる。

許可する場合、窓口は gen_delegate_payload.py の --impl-guidance "<text>" で brief に許可を明記する（例: --impl-guidance "本タスクは実装中に設計判断が残るため ultracode の使用を許可する。ultracode は実装と Codex 前のセルフレビュー収束に使い、最終の Codex ゲートは従来どおり維持する" — 理由は上記 3 基準のうち該当するものを書く）。この文言は worker brief（既定 CLAUDE.md、claude-org 自己編集タスクは CLAUDE.local.md）の「実装ガイダンス」にレンダリングされ、dispatcher はここを読んで武装要否を判定する（.dispatcher/references/spawn-flow.md 3-5a）。

強い権限の事前許可文言を workflow の agent プロンプトに書かせない（重要）: ultracode を許可しても、dangerouslyDisableSandbox / --dangerously-skip-permissions 等の強い権限を事前に許可する文言を workflow の agent() プロンプト本文に書き込ませない（窓口の --impl-guidance にもそうした事前許可文言を載せない）。安全分類器が該当 agent 呼び出しを silent block し、workflow が原因不明のまま停滞する事故になる。どうしても強い権限が要る段がある場合は、その agent の成否を明示確認（戻り値 / 失敗検知でブロックを検出）し、block 時のリカバリ手段（当該段を通常権限で再実行する / worker 本体で手動実行する等）を workflow に組み込むよう brief で促す。

brief 文言は「許可の宣言」であって武装ではない: 窓口の brief 許可は必要条件にすぎず、発動条件は dispatcher の send_keys kickoff（機構の正本は .dispatcher/references/spawn-flow.md 3-5a）。

gen_delegate_payload.py の専用フラグ化はスコープ外（許可は --impl-guidance の brief 文言、武装は dispatcher の send_keys が担う分担で足りる）。位置づけ: ultracode は実装と Codex 前のセルフレビュー収束に使う前段であって、最終 Codex ゲート（別モデルによる独立レビュー、Blocker / Major ゼロ）の置き換えではない。軽量レーン（subagent 直処理）では ultracode を許可しない。重量レーンでも上記 3 基準をいずれも満たさないタスクは許可しない（サイズの大小ではなく判断密度・検証性質・並列構造で判定する）。

段別モデル指定（推奨）: ultracode workflow を許可するタスクでは、workflow の段ごとにモデルを使い分けるよう brief で促してよい。機械的なファンアウト段（定型置換・多数ファイルへの同一変換・単純収集など判断を伴わない並列作業）は agent(..., {model: 'sonnet'}) で Sonnet に振ってコスト・速度を最適化し、判断・検証・統合の段（レビュー・設計判断・adversarial verify・synthesis）はセッションモデル（ワーカーのセッションモデル。既定 sonnet、モデル: opus 指定時は opus）を継承させて品質を確保する。粒度は Workflow tool の agent() opts.model で制御する（段別注記は .dispatcher/references/spawn-flow.md 3-5a と一致させる）。

重量レーンのワーカーモデル選定（既定 sonnet）: ワーカーの spawn model は既定 sonnet。Codex レビューの往復上限はワーカーの外（PreToolUse フックと tools/codex_round_cap.py）で強制されるので、Sonnet が収束しなくても上限で止まり、窓口がその時点で上げ方を決められる。Opus にするかを決めるのは窓口だけで（ディスパッチャーもワーカーも決めない）、条件は次のいずれか:

• (a) Codex 往復上限での拒否（CODEX_ROUND_DENIED）の後に、窓口が Opus へ上げると決めたとき（下記「ディスパッチャーから CODEX_ROUND_DENIED を受けたとき」）
• (b) ワーカーが手に余ると申し出たとき（モデルの昇格だけなら窓口が決める。申し出にスコープ拡張や方針変更が含まれるときは、その部分を /org-escalation で人間に上げる）
• (c) 人間が指定したとき
• (d) ガード・封印・契約などの強制機構を実装するタスク（「テストが緑でも守っていない」型の欠陥が出やすい）

(c)(d) は派遣時に決まるので、send_plan.json の DELEGATE 本文に モデル: opus の 1 行を足してからディスパッチャーへ送る（tools/gen_delegate_payload.py に model 用のフラグは無く、生成された本文にこの行は出ない）。ディスパッチャーはこの行が無ければ sonnet で spawn し、opus 以外の値は窓口へ差し戻す（spawn 側の SoT は .dispatcher/references/spawn-flow.md 3-2）。

spawn 後の Opus 昇格（(a)(b)）: ワーカーペインは閉じず、窓口が同じペインでモデルを切り替える（作り直さない。会話の文脈はそのまま残る）。手順は実走で確かめたもので、盲目 Enter は使わない:

1. mcp__org-broker__send_keys(target="worker-{task_id}", text="/model")（引数なし）→ mcp__org-broker__inspect_pane で入力欄に載ったことを確認 → mcp__org-broker__send_keys(target="worker-{task_id}", enter=true) を単独で別送（text と Enter の同一呼び出しは貼り付け吸収で未送信 draft になる）
2. 「Select model」のピッカーが出る（下端に Enter to set as default · s to use this session only · Esc to cancel）。カーソルは現在のモデルの行から始まる。行の並びはモデル一覧次第なので、キーを決め打ちの回数で送らず、↑↓ を送るたびに mcp__org-broker__inspect_pane で確かめて、カーソル（❯）が Opus の行に来たら止める
3. mcp__org-broker__send_keys(target="worker-{task_id}", text="s") を送る（Enter ではない。Enter は人間のユーザー既定モデルまで書き換える）
4. 「Switch model?」の確認ダイアログ（次の応答が遅くなる・履歴を読み直す旨の説明と、1. Yes, switch to Opus … / 2. No, go back の選択肢）が出る。mcp__org-broker__inspect_pane でカーソルが Yes にあることを確かめてから mcp__org-broker__send_keys(target="worker-{task_id}", enter=true) を送る
5. mcp__org-broker__inspect_pane で「Set model to Opus … for this session only」の表示と、ヘッダのモデル表示が Sonnet から Opus に変わったことを確かめる

切り替わったら記録を残し、ワーカーへ続行を指示する:

bash tools/journal_append.sh worker_model_set task=<task_id> model=opus reason=promotion:<cap_denied|worker_request|human|enforcement>

/model opus の直打ちやピッカーでの Enter は使わない。どちらもそのセッションだけでなく、人間のユーザー既定モデル（~/.claude/settings.json の model）まで書き換え、人間が手で起動するセッションや model を明示せずに起動される窓口に波及する。s（このセッションだけ）なら既定は変わらない（実走で settings.json の mtime と値が不変であることを確認済み）。ピッカー・ダイアログ・画面が上記と違うときは Esc で抜けて即興で続けない。切り替わりを確認できないときだけ、ワーカーを作り直す（ペインを閉じて モデル: opus 行付きで派遣し直す）。作り直しは作業中の文脈を失うので、人間に諮ってから行う。

試行期間の記録: タスクごとの使用モデル・昇格の有無と理由・Codex 往復回数は events に残る（state DB に model 列は無い）。spawn 時のモデルはディスパッチャーが worker_model_set（reason=default|delegate_line）を、昇格は窓口が上記の worker_model_set（reason=promotion:<cause>）を書き、往復回数は codex_round_started の行数で数える。

Codex 往復上限の既定外指定は派遣時に CLI で設定する: 上限（既定 3）はフックが events から読むので、brief の --impl-guidance に別の上限（例: 「Codex 往復の上限は 5 ラウンド」）を書いても、それだけでは効かない。既定外の上限を指示するタスクでは、窓口が apply の直後（delegate_sent 記帳後）に ja root で設定する:

python3 tools/codex_round_cap.py set --task-id <task_id> --allowed <N|unlimited> --reason "<brief で指定した理由>"

現在値は python3 tools/codex_round_cap.py status --task-id <task_id> で確かめられる。許可回数を書けるのは窓口だけで、ワーカーからは書けない（.state/ はワーカーのサンドボックス外）。

ワーカーに設計レビューを頼むとき: ワーカーは codex を直接実行できないので、brief で着手前の設計レビューを求める場合も、ワーカーは bash "$CLAUDE_ORG_PATH/tools/codex_review_gate.sh" --design <file> だけで回す（設計を書いたファイルのパスを渡す）。設計レビューは差分レビューとは別枠で数え、タスクごとに 1 回固定（set では変わらない）。差分レビューの許可回数（既定 3）は減らない。2 回目の設計レビューは CODEX_ROUND_DENIED（mode=design）で拒否される。

委譲前チェックリスト（窓口が実行）

タスク分解に入る前に、依頼内容を以下の観点で確認する。該当する場合はユーザーに聞き返す。

チェック項目	確認すべき状況	例
曖昧な用語・略語	ツール名・サービス名・略語が複数の意味を持ちうる場合	「gog」→ Google OAuth? gog CLI?
OS固有の前提条件	OS別の成果物を作る場合、デフォルト設定の明示が必要	Mac=zsh、Windows=py -3、パス区切り

• 曖昧な用語がある場合: 「○○は△△のことですか？」とユーザーに確認してから進める
• OS別タスクの場合: ペイロード生成時に、OS固有の前提条件をワーカーへの指示に含める
• pin 管理された内部パッケージ（claude-org-runtime 等）のバグ疑いを委譲する前に: 当日の /org-start Block C2 の runtime drift check が clean（exit 0）だったかを確認する。drift 検出（exit 1）や「PyPI 未確認」（exit 2 = sandbox 内実行等で PyPI に届かず）だった場合は、既に upstream で修正済みのバグを古い venv で踏んでいる可能性があるので、まず venv upgrade + pin 窓 bump で最新化し、それでも再現するかを確認してから委譲する（既修正バグへの phantom dispatch を防ぐ）。pin ラグはセッション定数なので確認は org-start 時 1 回で足り、委譲ごとの再チェックは不要（背景は .claude/skills/org-delegate/references/rationale.md §2）

incorporation / sync 系タスクの初手チェックリスト

ソース（review 結果 / 別ブランチ / 別リポジトリの状態）を destination に取り込む incorporation / sync 系タスクでは、ソース commit が destination の現状から N コミット以上進んでいる場合、selective merge（cherry-pick / 必要 hunk のみ apply）を初手として検討する。byte 一致 cp は Codex iterative review fix を機械的に上書きするリスクがある。

観点	チェック	アクション
ソースと destination の乖離	git log <source>..<destination> / git log <destination>..<source> で双方向に確認	双方向に diverge があれば cp 禁止、selective merge を採用
destination 側の追加修正	destination ブランチで Codex review fix / Blocker fix が積まれていないか	積まれている場合は cp で機械的に上書きしないこと（cherry-pick or hunk 単位の apply）

背景の事故は .claude/skills/org-delegate/references/rationale.md §3。ワーカーへの brief で「初手 cp 禁止 / 取り込み戦略を明示」を要求する。

並列委譲で同一ファイルを編集するケースの brief 事前文言

複数 worker を並列派遣し、それらが同一ファイル（特に同一領域）を編集することが brief 組み立て時点で分かっている場合、gen_delegate_payload.py の --impl-guidance に次の趣旨の文言をあらかじめ入れる:

並走タスク {parallel_task_id} が同じファイル {path} を編集中。窓口が merge 順序の続報を送るので、その続報を受けてから base upstream（通常 origin/main）へ rebase して完了報告すること

運用上の注意 2 点:

• 窓口の続報は merge 順序の決定だけでは送らない。先行 PR が merge され base upstream に反映されたことを確認してから後続 worker に送る（順序決定直後に送ると、先行変更を含まない upstream へ rebase してしまい conflict 防止が成立しない）
• rebase 先と適用範囲: 完了報告前の rebase は検証深度 full のタスクに限る。PR のベースが origin/main 以外なら、rebase 先は実際の base upstream（例 origin/<統合用ブランチ>）に読み替える。描画される brief テンプレート（tools/templates/worker_brief_*.md）にはこの規定が無いので、必要なら上の文言にあわせて --impl-guidance に書く

事後の追指示でも救えるが、brief 段階で入れておけば窓口→worker の 1 往復が減り、integration point conflict を事前に防げる（実例と効果は .claude/skills/org-delegate/references/rationale.md §4）。

Step 0: プロジェクト名前解決（窓口が実行）

ユーザーの依頼からプロジェクトを特定する:

1. registry/projects.md を読む。未生成なら python3 tools/ensure_projects_registry.py（Windows native は py -3 ...）でテンプレートから生成してから読む（Issue #811 で operator-local な生成ファイルになった。通常は /org-start の Step 0 が生成済みなのでこの分岐には入らない。既存ファイルは上書きされないので実行は無害）
2. 依頼に含まれるキーワードから該当プロジェクトを特定する（通称・プロジェクト名・説明から照合）
3. 特定できた場合はそのパスを使う
4. 特定できない場合は登録済みプロジェクトの通称一覧を提示し、選ばせる
5. 新規プロジェクトの場合:
   • パスをユーザーに確認する
   • 通称・説明・よくある作業例を推定し、ユーザーに確認してから registry/projects.md に追記する

Step 0.5: work-skill 検索（窓口が実行）

タスク分解の前に、関連する既存の work-skill がないか検索する。マッチした work-skill はワーカーへの指示に参考情報として含める。

1. .claude/skills/ 配下の全 SKILL.md ファイルを列挙する
2. 各 SKILL.md の frontmatter (type / description / triggers) をタスク内容と照合する。org- プレフィックスは組織運営スキルなので検索対象外
3. 関連性があれば候補に含める（完全一致は不要、複数マッチは関連度順に全て）

マッチした場合:

• 人間に「関連 work-skill を見つけました: {skill-name} — 参考情報として含めます」と通知する
• gen_delegate_payload.py 呼び出しの --knowledge フラグに work-skill の SKILL.md パスを渡す。Stage 2 brief renderer がそのパスを [references].knowledge として CLAUDE.md / CLAUDE.local.md に埋め込む。複数マッチは --knowledge <path1> --knowledge <path2> のように繰り返す
• ワーカーへの指示（instruction-template）にも参考スキルの存在を明記する

work-skill の手順をそのままコピーしない。参考情報として提示し、ワーカーが判断する。

Step 0.6: release-class タスクの pre-fetch（窓口が実行）

以下 3 条件のいずれかに該当する場合のみ、gen_delegate_payload.py apply の 前に 対象プロジェクトの local main を git fetch origin + git pull --ff-only origin main で更新する:

• task description / commit-prefix / planned branch に release, release/, vX.Y.Z 等のリリース昇格語を含む
• 対象ファイルに CHANGELOG.md 昇格 / __about__.__version__ / pyproject.toml の version bump 等を含む
• task_id に release を含む（例: runtime-0-1-10-release）

通常タスクでは実行しない。worker は素の git fetch はできるが、git pull（local main の fast-forward）と git -C <path> fetch は deny されている（tools/org_extension_schema.json の worker 既定ロールの allow / deny）。そのため local main を進める仕事は窓口に残る。fast-forward できない（non-ff）ときは派遣せず人間に報告する。実行コマンド・Pattern B との切り分けは .claude/skills/org-delegate/references/release-pre-fetch.md を一次参照。

Step 0.7 / 1 / 1.5 / 2: 1 コマンドで派遣ペイロードを生成（Issue #283）

Step 0.7 (gitignore 事前チェック) / Step 1 (Pattern 判定) / Step 1.5 (ワーカーディレクトリ準備 + role 決定 + settings 生成) / Step 2 (DELEGATE 本文組み立て) は tools/gen_delegate_payload.py が一括で行う。窓口の責務はタスク特定 (Step 0)・work-skill 検索 (Step 0.5)・対象ファイルの抽出・depth 判断のみ。

dispatch 前検証チェック（Step 0.7 付随・窓口が手動で実行）

以下 2 点は gen_delegate_payload.py が検証しないため、preview の前に窓口が手動で確認する。満たせない場合はその委譲を dispatch 不成立とし、apply に進まない（原因を窓口側で解消するかユーザーに上げてから Step 0 から回し直す）:

1. コミット済みベースの存在確認: --target の file existence は常に確認する。line existence は、行番号付きレビュー指摘 / パッチを入力に持つ委譲のみ検証する。live tree の未コミット変更を編集ベースとする委譲は不成立（worker の worktree / clone はコミット済みベースから切られるため対象が見えない）— commit してから委譲し直す
2. org 挙動変更時の契約 grep: org の挙動（cadence / lifecycle / 責務境界）を変える委譲では docs/contracts/ を挙動キーワード（loop / cadence / curator / close 等）で grep し、ヒットした契約の cited source（.dispatcher/CLAUDE.md, .dispatcher/references/worker-monitoring.md 等）まで辿る。ヒットは --target に入れず（edit scope 汚染）、--knowledge / --impl-guidance で brief に運ぶ

判定基準・コマンド例・grep キーワードの詳細は .claude/skills/org-delegate/references/delegate-flow-details.md §1.5 を一次参照。

標準フロー (推奨)

# 1. preview: 完全に非破壊。DELEGATE 本文と作成予定ファイル一覧だけを確認する
#    （Mac/Linux は python3、Windows native は py -3。末尾の「Windows native 版」を参照）
python3 tools/gen_delegate_payload.py preview \
    --task-id <task-id> --project-slug <slug> \
    --target <path>... --description "<desc>" \
    --verification-depth full

# 1.5. Step 1.7 gate: preview 出力で Codex design review トリガー条件を評価
#      該当する場合のみ codex exec で design review を実行し、要約を
#      --impl-guidance または --knowledge で apply に渡す（下節 Step 1.7 参照）

# 2. apply: CLAUDE.md/CLAUDE.local.md 配置 + claude-org-runtime settings generate 実行
#    + send_plan.json 出力 を先に済ませ、最後に state.db へ runs.status='queued' 予約と
#    T1 の delegate_sent イベントを同一トランザクションで記録する (Issue #928)
python3 tools/gen_delegate_payload.py apply \
    --task-id <task-id> --project-slug <slug> \
    --target <path>... --description "<desc>" \
    --verification-depth full

# 3. apply 出力の send_plan.json を MCP 呼び出しにコピペ
#    cat <worker_dir>/send_plan.json
#    → mcp__org-broker__send_message(to_id="dispatcher", message=<message>)

Windows native 版（Git Bash。PowerShell では行末の \ を ` に替える。1.5 と 3 は同じ）:

py -3 tools/gen_delegate_payload.py preview \
    --task-id <task-id> --project-slug <slug> \
    --target <path>... --description "<desc>" \
    --verification-depth full

py -3 tools/gen_delegate_payload.py apply \
    --task-id <task-id> --project-slug <slug> \
    --target <path>... --description "<desc>" \
    --verification-depth full

apply は T1 を丸ごと 記録する: runs.status='queued' の予約と delegate_sent イベントを同一トランザクションで commit するので、窓口が手で journal_append を打つ必要はない（打つと二重記録になるので打たないこと）。Active Work Items への active 化はディスパッチャー T2 (docs/contracts/delegation-lifecycle-contract.md) なので本 skill では触らない。

• delegate_sent は「送信直前の委譲確定記録」であって送達証明ではない。実際に届いてワーカーが立ったことは T2 の worker_spawned が証明する。
• apply が途中で失敗した場合は予約もイベントも残らない（生成物を全て作り終えてから最後に commit するため）。同じ task_id でそのまま再実行してよい。
• 予約済み (queued) の task_id への再 apply は「まだ送っていない委譲の作り直し」として通り、delegate_sent は重複記録されない。queued 以外（in_use / review / completed / failed / suspended / abandoned）の run に対する apply は fail loud で止まる — 別の仕事は新しい task_id で委譲する。
• 再 apply で project / pattern / branch / worker_dir が予約と食い違う場合も fail loud で止まる。予約済み run は次の layout 解決で「使用中」と数えられるため、同じコマンドを打ち直しただけでも別 pattern に倒れることがある（例: Pattern A → B）。黙って予約を付け替えると記録済み delegate_sent の dir と食い違うので拒否する。新しい task_id を使うか、既存予約を先に解放すること。
• 失敗が上記いずれにも当たらない場合はキューを残したまま Secretary に判断を仰ぐこと。

よく使うフラグ

• --mode edit|audit (default edit): claude-org 上の 読み取り専用 監査タスクは --mode audit を明示する
• --branch <name>: planned_branch を上書き。default は feat/<task-id> (description に "fix"/"bug"/"修正" を含むと fix/<task-id>)
• --base-ref <branch>: worktree の起点ブランチを単発で上書き (Issue #808)。既定は registry/projects.md の base_branch 列、それも空欄なら origin/HEAD。優先順位は --base-ref > base_branch 列 > origin/HEAD。プロジェクトの常態（例 develop に feature を溜める）は列に書き、本フラグは hotfix を main から切る等の逸脱時のみ使う。値はブランチ名（origin/develop 表記も可）。origin に存在しないブランチを指定した apply は既定ブランチへ黙って落ちず fail loud で止まる。解決結果は preview --json の summary.base_branch / summary.base_ref と DELEGATE 本文の「ベース:」行に出る。この値は後続の gh pr create --base の既定でもある（.claude/skills/org-pull-request/SKILL.md 2b-i）ので、起点とマージ先は常に一致する
• --commit-prefix "<prefix>": 省略時は project_slug の頭部から推論 (例: claude-org-ja → feat(claude):)
• --closes-issue N / --refs-issues N1 N2: 「Closes #N」「Refs #N1 #N2」を brief に埋め込む
• --impl-target <path> / --impl-guidance "<text>" / --knowledge <path>: optional な [implementation] / [references] セクション
• --fix / --assumption "<前提>=<確かめ方>=<結果>"（何度でも指定可）: 不具合の修正を任せるときは --fix を付け、修正が正しいための前提を言葉にして、確かめた手順と結果を添える。--fix では 1 つ以上が必須で、修正が頼る仕組み（イベント・関数・設定）を書いている側の file:line を結果に入れる（読む側の定義だけでは仕組みの実在を示さない）。例: --assumption "worker_closed がクローズ時に記録される=grep -rn worker_closed tools/=書く側は tools/<writer>.py:<行>"。結果・確かめ方が空や「なし」「未確認」は拒否され、結果中の file:line は apply 時にベースのリポジトリでファイルと行の実在を確かめ、無ければ何も書かずに止まる。書いた前提は brief の「実装ガイダンス」に描画され、ワーカーは作業中にそれが崩れたら窓口へ報告する
• --placement same_tab|background_tab (default same_tab) / --report-target <id>: worker を背景タブに置く派遣（spawn-flow 3-1d の例外経路）でのみ使う。peer 名は送信者と同じタブ内でしか解決しないため、背景タブの worker は既定の to_id="secretary" に届かず完了報告が沈黙で落ちる。--placement background_tab は --report-target に窓口ペインの数値 pane id（list_peers で確認）を要求し、brief の報告先と DELEGATE 本文の報告先行を同じ数値 id で生成する。数値でない値・--report-target 欠落は apply 前に fail loud で止まる。既定の同一タブ派遣ではどちらも渡さない（渡さなければ生成物は従来と 1 バイトも変わらない）。ディスパッチャーが 3-1d の条件を満たせず同一タブ経路に倒した場合、その brief は流用できない（背景タブ前提の報告先・報告規律が焼き込まれている）。差し戻しを受けたら --placement 無しで apply をやり直して brief を再生成する
• --skip-settings: claude-org-runtime settings generate をスキップ (CLI 未導入環境向け)
• --from-toml <path>: 既存 worker_brief.toml を入力にする。CLI フラグは TOML を上書きする

Pattern / role / branch の判定詳細

判定ロジック (Pattern A vs B vs C / gitignored サブモード / role 表 / planned_branch / DELEGATE 本文の必須行) は .claude/skills/org-delegate/references/delegate-flow-details.md 参照。self-edit タスクの特例（Issue #289、pattern_variant='live_repo_worktree'）は .claude/skills/org-delegate/references/claude-org-self-edit.md §3 参照。

対象ファイル抽出

「対象ファイル」は窓口がタスク説明から抽出する（依頼文・Issue 本文・ユーザー発話の中で明示されたパス。機械的判定はしない）。対象ファイルが特定できないタスク（純粋な調査、対象パス未定の新規作成など）は --target を渡さなくてよい。

標準経路が想定外の出力を返した場合

標準経路 (gen_delegate_payload.py apply) が想定外の出力 (Pattern 誤判定 / resolver エラー / brief 不整合 等) を返した場合、Secretary は 手動で同じ作業を再現してはならない。resolver のバグとして Issue を切り、当該タスクの delegation は resolver が直るまで pause する。手作業 fallback は skill のスコープ外。CLI 未導入環境では --skip-settings フラグに限定する。

Step 1.7: Codex design review trigger（窓口が実行）

apply の前に Codex design review を実施するか判定する。以下のいずれかに該当する場合のみ実行:

• 推定工数 ≥ 3h
• 新規 module / 新規 tool 導入
• ファイル変更 ≥ 3 件
• docs/contracts/ 配下の契約ドキュメント参照
• 監視ロール（dispatcher / curator 等）への blocking wait 追加、または org の lifecycle（spawn / close / cadence / 常駐とオンデマンドの切替）の変更。ファイル変更が 1 件でも発動する

トリガー判定の詳細表・codex exec コマンド・review 要約の --impl-guidance / --knowledge への組み込み手順は references/codex-design-review.md を一次参照。

Step 3 / 4: ワーカー起動・指示送信・状態記録（ディスパッチャーが実行）

詳細手順 (3-1 balanced split / 3-1c SPLIT_CAPACITY_EXCEEDED escalate / 3-2 spawn / 3-3 pane_started / 3-3b channel approve / 3-4 list_peers / 3-5 instruction send / 3-6 順次起動 / Step 4 状態記録 / Worker Directory Registry) は .dispatcher/references/spawn-flow.md を一次参照する。窓口は触らない。

ディスパッチャーは派遣完了時に窓口へ DELEGATE_COMPLETE を返す。

Step 5: 進捗管理（窓口が実行）

窓口 → worker のメッセージング規約（1 worker = 1 task = 1 scope）

窓口から既存 worker へ送る全 message は「1 worker = 1 task = 1 scope」の原則に従う。3 rule は本節が正本（root CLAUDE.md「worker への追加依頼の境界」は要約）:

1. 追加依頼は元タスクのスコープ内に限る: brief で示した範囲内の補足・修正指示のみ追送する。スコープ外の別件は同 worker に投入せず、Step 0 から本 SKILL を回し直してディスパッチャー経由で別 worker を派遣する
2. worker のスコープ拡張提案は escalation 経由: 窓口は一次承認せず /org-escalation を発動する
3. 窓口は worker 作業を代行しない: ファイル編集・commit・テスト等を窓口側 worktree で手を出さず、追加依頼として worker に戻すか別 worker を派遣する

方針を途中で変えたとき: 計測方法・タスク内の範囲・手順を途中で変えたときは、何が変わったか、brief のどこが無効になったか、そこから完了報告までに何をすればよいかを 1 通のメッセージにまとめて送る（worker は窓口が後から決めたことを知らないので、変更だけを送ると古い brief のまま進んでしまう）。メッセージの内容が brief と食い違うときは、どちらを優先するかをメッセージに明記する。

違反事例と guard / CI 実装の扱いは .claude/skills/org-delegate/references/rationale.md §5。

DELEGATE_COMPLETE 受信時

ディスパッチャーから派遣完了報告を受け取ったら、各ワーカーに挨拶メッセージを送る:

mcp__org-broker__send_message(
  to_id="worker-{task_id}",
  message="窓口です。{task_id} の作業をお願いしています。完了・進捗・ブロック、全ての報告は `to_id=\"secretary\"` で org-broker 送信してください。"
)

.claude/ 編集タスクの send_keys 事前承認（root .claude/** self-edit のみ）: 委譲対象に claude-org root の .claude/** が含まれる場合（.dispatcher/ / .curator/、worker dir 生成物の .claude/settings.local.json は対象外）、窓口は上記挨拶の送信に続けて python3 tools/self_edit_approval.py send --task {task_id} --file <対象ファイル>... を 1 回実行する（broker 実走時のみ --target %N を足す: 論理名 worker-{task_id} は tmux から引けないので list_panes で読んだ pane id を渡す。足りなければ打鍵前に exit 2 で止まるので、承認が届いたと誤解することは無い）（承認文の text 送信 → 着弾確認 → Enter 単独送信 → submit 確認を内部で順に行い、どの段でも検証できなければ exit 10 で停止し、成功時のみ self_edit_approval_sent を記帳する）。承認文の必須 3 要素（対象ファイル列挙 + task_id + 「窓口経由のユーザー承認」の明記）はツールが組み立てる。mcp__org-broker__send_keys を手で 3 段打たない（Enter 落としで承認文が draft 滞留し worker が待機し続ける。Issue #956。詳細は .claude/skills/org-delegate/references/rationale.md §7）。worker 側は編集前にこの承認入力の存在を確認し、無ければ編集せず窓口に要求する（ハンドシェイク固定で deadlock / 空打ちを防止）。承認を送らずに派遣したケースは python3 tools/self_edit_approval.py audit で事後検出できる。スコープ境界・背景（2 層ガード）・承認文テンプレート・worker brief 必須文言は .claude/skills/org-delegate/references/claude-org-self-edit.md §5 を一次参照。

ワーカーからのメッセージ受信時

Canonical event flow（途中段階を飛ばしてはならない）:

worker → Secretary peer message
  1. ack to worker (全 message 共通で必須。dead-lock 防止)
  2. update Progress Log + DB (run.status / events / pending-decisions register)
  3. report to user           (完了 / escalation / blocker のみ。進捗報告は不要)
  4. wait for user approval before push/PR
  5. CI watch / next instruction → [`.claude/skills/org-pull-request/SKILL.md`](../org-pull-request/SKILL.md)

• ack の最低内容と種別ごとの例文は .claude/skills/org-delegate/references/ack-template.md を参照。ack ≠ user 承認: git push / gh pr create / /pr-watch-pane は user の明示的 OK 後にのみ発行
• 2 → 3 の順序は「内部状態を先に整合させてから user に報告する」原則

0. 判断仰ぎ・スコープ拡張・ブロッカー（最優先で識別）

→ .claude/skills/org-escalation/SKILL.md を発動する。Secretary は一次承認しない。

1. 進捗報告（完了以外の中間ハンドオフ報告すべて — 進捗・rebase 報告・依頼 等）

本サブセクションは「進捗」という語に限らず、完了報告 (2a) / 判断仰ぎ・ブロッカー (0) / plan・prep 引き渡し以外の worker→secretary peer message 全種（進捗共有・rebase 完了報告・確認依頼等の中間ハンドオフ報告）に適用する。plan / prep の引き渡しは専用 kind（plan_delivered / prep_delivered、docs/journal-events.md）で記帳する既存フローのままとし、worker_reported に付け替えない（design-flow 消費側は専用 kind を参照している）。

• worker へ ack を返す（.claude/skills/org-delegate/references/ack-template.md の「進捗報告 ack」節。Progress Log 追記より前）。進捗報告は user に上げない・承認待ちもしない
• .state/workers/worker-{task_id}.md の Progress Log に追記
• DB の events テーブルへ worker_reported を必ず追記する（省略不可、Issue #699）:

  bash tools/journal_append.sh worker_reported worker=worker-{task_id} task={task_id} summary="<要約>"
  

  payload key は event catalog（docs/journal-events.md の worker_reported 行: worker, task, summary）に合わせる。kind は worker_reported に統一（worker_progress 等の別名を使わない）。記帳漏れは正常稼働中の worker を silent dead-lock と誤検知させる（dispatcher の PANE_OUTPUT_WITHOUT_PEER_MSG 判定は events テーブルの worker_reported 痕跡を SQL で参照するため。.dispatcher/references/worker-monitoring.md Step 5.2、実例は .claude/skills/org-delegate/references/rationale.md §6）

2a. 完了報告

• worker へ ack を返す（.claude/skills/org-delegate/references/ack-template.md の「完了報告 ack」節。受信直後・dead-lock 防止で他の状態更新より前に）
• DB 経由で run を REVIEW に遷移（markdown 直接編集禁止）。下の python3 -c / py -3 -c は .state/state.db と tools を相対パスで開くので、ja root を cwd にして実行する（tools/journal_append.sh 等の tool は repo root を自分で解決するので cwd を問わない）:

  # Mac/Linux
  python3 -c "
  from pathlib import Path
  from tools.state_db import connect
  from tools.state_db.writer import StateWriter
  conn = connect('.state/state.db')
  with StateWriter(conn, claude_org_root=Path('.')).transaction() as w:
      w.update_run_status('<task_id>', 'review')
  "
  # Windows native（Git Bash / PowerShell）
  py -3 -c "
  from pathlib import Path
  from tools.state_db import connect
  from tools.state_db.writer import StateWriter
  conn = connect('.state/state.db')
  with StateWriter(conn, claude_org_root=Path('.')).transaction() as w:
      w.update_run_status('<task_id>', 'review')
  "
  

• DB の events テーブルにイベント追記 (bash tools/journal_append.sh ...)
• dispatcher へ完了受領を通知（監視抑止、Issue #658）: worker ack と上記状態更新（REVIEW 遷移・events 追記）を終えた後、best-effort・非 blocking で dispatcher へ WORKER_COMPLETION_NOTED を送る。dispatcher はこれを /loop 3m の通常 check_messages で受けて worker-idle-state.json の completion_reported_at に反映し、PANE_OUTPUT_WITHOUT_PEER_MSG 検知（完了報告済み worker の正常な review 待ち idle を silent dead-lock と誤判定する false positive、.dispatcher/references/worker-monitoring.md Step 5.2）を抑止する。これは「完了判定」ではなく「監視抑止用の受領通知」（完了遷移 T4 は secretary の責務、dispatcher は自分で完了を判定しない）。dispatcher 応答を待たない（blocking wait は T4 の human review 移行に新しい停止点を作るため禁止）。本文に task_id と received_at（ISO-8601 UTC）を含める:

  mcp__org-broker__send_message(to_id="dispatcher", message="WORKER_COMPLETION_NOTED: worker-<task_id> (task_id=<task_id>, received_at=<ISO-8601 UTC>)")
  

  対の解除は T6 再指示時の WORKER_REOPENED（.claude/skills/org-pull-request/SKILL.md 2c）。minimal / full どちらの完了報告でも送る（silent dead-lock 抑止は検証深度に依らない）
• 人間向け理解サマリを承認提示の土台にし永続化する（検証深度 full 限定）: full モード完了報告には worker が「人間向け理解サマリ」（(1) 最重要の変更点 N 個、(2) 要確認ファイル / hunk、(3) 設計判断と理由）を含める（スキーマの正本はワーカーに描画される brief テンプレート tools/templates/worker_brief_normal.md、自己編集タスクは tools/templates/worker_brief_self_edit.md の「人間向け理解サマリ」節）。窓口は自分でコードを精読せず、このサマリをユーザーへの承認提示の土台にする（必要なら業務言語に整える）。受領したサマリは .state/workers/worker-{task_id}.md の Progress Log に Human Understanding Summary: 見出し + 直下の fenced code block でそのまま追記する（merge 承認時に再掲する元。full 完了報告が複数回ある場合は最新ブロックを正とする）。PR 作成時は PR 本文にも要約を載せてよい。full でサマリが欠落していたら通常の review feedback として同ペインの worker に補完を依頼する（.claude/skills/org-pull-request/SKILL.md 2c の review-feedback 手順で扱う）。これは手順レイヤの完了報告フォーマット拡張であり、contract（T4 worker_completed）の遷移条件は変えない。minimal の 1 行 done: 報告にはサマリは付かない
• awaiting_user 通知の emit（Issue #28）: 人間への報告 → 承認待ち停止に入る直前で、attention watcher に「Secretary が user の判断待ちで停止する」ことを知らせる:

  bash tools/journal_append.sh notify_sent kind=awaiting_user task_id=<task_id> gate=worker_completed note="<PR/Issue 等の短い文脈>"
  

  claude-org-runtime の attention classifier がこの 1 行を secretary_awaiting_user (default severity urgent) として拾い、画面前にユーザーが居ない場合でもビープで気付ける。CLAUDE.md「secretary が user の判断を待っている状態を通知する」節を参照
• 結果を人間に報告し、ペインを閉じず承認待ちで停止。承認なしで push/PR を発行すると worker / user 双方への protocol 違反

2b / 2c. ユーザー承認後・レビュー指摘・マージ後クローズ

→ .claude/skills/org-pull-request/SKILL.md を発動する。

• 再指示時の監視フラグ解除（Issue #658）: 完了報告済み（§2a で dispatcher へ WORKER_COMPLETION_NOTED 送信済み）の worker に、review feedback / CI 失敗の追指示を送るときは、追指示の前に dispatcher へ WORKER_REOPENED: worker-<task_id> (task_id=<task_id>, reopened_at=<ISO-8601 UTC>) を best-effort・非 blocking で送り、completion_reported_at を clear させる。再指示は secretary→worker 直送で dispatcher が経路上に居ないため、この明示解除が無いと dispatcher の PANE_OUTPUT_WITHOUT_PEER_MSG 検知が sticky skip のままレビュー修正中の本物の silent dead-lock を見逃す。操作 SoT は .claude/skills/org-pull-request/SKILL.md 2c

ディスパッチャーから CODEX_ROUND_DENIED を受けたとき

ワーカーが Codex レビューの許可回数（既定 3、窓口が tools/codex_round_cap.py set で変えた値があればそれ）を使い切った後に、4 回目のレビューゲートを呼ぶと、PreToolUse フック（.hooks/block-codex-over-cap.sh）が拒否して events テーブルに codex_round_denied を書く。ディスパッチャーはこれを見回りで拾い、CODEX_ROUND_DENIED: worker-<task_id> (task_id=<task_id>, used=<n>, allowed=<m>) [relay] を窓口へ中継する（.dispatcher/references/worker-monitoring.md Step 5.25）。ワーカー自身も拒否を受けて残指摘と自己評価を報告して停止する。2 回目の設計レビュー（--design）が拒否されたときは中継が CODEX_ROUND_DENIED: worker-<task_id> (task_id=<task_id>, mode=design, used=<n>, allowed=1) [relay] になる。設計レビューは 1 回固定で set では増えないので、この場合は下記 (a)〜(c) ではなく、ワーカーに実装を続けさせるか、設計の再確認が要るなら人間に上げる。次の手を決めるのは窓口で、ディスパッチャーもワーカーも決めない。同じ拒否について中継とワーカー報告の両方、または [relay] の重複が届いても、1 件として扱う（2 回目以降は状態を変えない）。

1. ワーカーへ ack を返す（.claude/skills/org-delegate/references/ack-template.md の「Codex 往復上限での停止 ack」節）。ワーカーの報告がまだ届いていなければ、ack で残指摘と自己評価の報告を求める
2. .state/workers/worker-{task_id}.md の Progress Log に拒否（used / allowed）と残指摘の要旨を追記する。現在値は python3 tools/codex_round_cap.py status --task-id <task_id> で確かめる
3. 窓口が次のどれかを選ぶ:
   • (a) Opus へ上げて続ける: 上記「spawn 後の Opus 昇格」の手順で同じペインを Opus に切り替え（worker_model_set ... reason=promotion:cap_denied を記録）、許可回数を増やしてからワーカーへ続行を指示する:

     python3 tools/codex_round_cap.py set --task-id <task_id> --allowed <N> --reason "Opus へ昇格して続行"
     

     --allowed は通算の許可回数（使用済みを含む）なので、used より大きい値にする
   • (b) 人間に上げる: /org-escalation の流れで残指摘とワーカーの自己評価を提示し、判断を仰ぐ。人間が許可回数の追加を承認したら (a) と同じ set を実行してからワーカーへ伝える
   • (c) 止めて残指摘のまま提示する: 残りが Minor / Nit 中心、または指摘が収束せず設計の問題と見える場合は、追加のレビューをさせず、完了報告（2a）と同じ扱いで残指摘付きのまま人間へ提示する

許可回数を増やせるのは窓口だけで、ワーカーからは書けない（許可回数は窓口側 .state/state.db の events にあり、ワーカーのサンドボックスと境界フックの外）。ワーカーが自分で上限を回避しようとした（codex の直接実行・ゲートの別経路呼び出し）跡を見つけたら、それも人間に報告する。

ワーカー監視と介入判定（窓口が実行）

派遣後、ワーカーが深掘り・過剰検証ループに入っていないか定期的に確認する。介入トリガー（いずれか 1 つ以上該当したら mcp__org-broker__inspect_pane で状況確認）:

• 同一タスクで 30 分超経過、かつ同じフェーズ（実装 / レビュー / 検証）に 3 回目以降入っている
• 1 時間以上進捗報告なしで静穏（入力待ちでもなく、progress ログも出ない）
• (codex を使っている場合) Codex セルフレビューが許可回数の最後のラウンドに入っても収束の気配がない（許可回数を超える 4 ラウンド目以降はフックが拒否し、CODEX_ROUND_DENIED が中継されるので、そちらは上記「ディスパッチャーから CODEX_ROUND_DENIED を受けたとき」で扱う）

介入手順: inspect_pane で画面確認 → 深掘りと判断したら send_keys(target="worker-{task_id}", keys=["Escape"]) で中断 → send_message で tight な修正指示を送る (例「検証深度 minimal に切り替え。Codex レビュー・追加テスト禁止。done: {commit SHA} {ファイル名} の 1 行だけ返してください」)。

窓口が自らワーカーの worktree で commit を代行することは auto-mode classifier によりブロックされる（スコープ逸脱）。介入はあくまで「指示の再送」で行うこと。