org-delegate: ワーカー派遣
作業をワーカーClaudeに委譲する。窓口はタスク分解と派遣ペイロード生成だけ行い、
ペイン起動・指示送信はディスパッチャーに委託する。これにより窓口のロック時間を最小化する。
本 SKILL のスコープ: 派遣の「初動」(タスク特定 → 派遣ペイロード生成 → ディスパッチャーへの DELEGATE 受け渡し → ワーカー起動後の挨拶 → 進捗・完了報告受信時の ack と REVIEW 遷移) のみ。以下は別スキル / reference に分離している:
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 の使用を許可してよい（推奨）:
- 実装中に設計判断が残る: 事前 design review で固定しきれない決定（実測しないと決められない契約・未知の移植先制約など）が実装フェーズに持ち越される
- 敵対的検証の価値が高い: 「テストが緑でも守っていない」型の欠陥が出やすい性質（ガード・封印・契約 battery 等の enforcement 実装）
- 所有排他で切れる並列構造: 独立サブタスクに分割でき、ファイル所有を排他にした並列レーンで実時間短縮が出る規模
量が多いだけの機械的タスク（設計固定済みの移植・定型変換）は、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 は使わない:
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 になる）- 「Select model」のピッカーが出る（下端に
Enter to set as default · s to use this session only · Esc to cancel）。カーソルは現在のモデルの行から始まる。行の並びはモデル一覧次第なので、キーを決め打ちの回数で送らず、↑↓ を送るたびに mcp__org-broker__inspect_pane で確かめて、カーソル（❯）が Opus の行に来たら止める
mcp__org-broker__send_keys(target="worker-{task_id}", text="s") を送る（Enter ではない。Enter は人間のユーザー既定モデルまで書き換える）- 「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) を送る
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: プロジェクト名前解決（窓口が実行）
ユーザーの依頼からプロジェクトを特定する:
registry/projects.md を読む。未生成なら python3 tools/ensure_projects_registry.py（Windows native は py -3 ...）でテンプレートから生成してから読む（Issue #811 で operator-local な生成ファイルになった。通常は /org-start の Step 0 が生成済みなのでこの分岐には入らない。既存ファイルは上書きされないので実行は無害）- 依頼に含まれるキーワードから該当プロジェクトを特定する（通称・プロジェクト名・説明から照合）
- 特定できた場合はそのパスを使う
- 特定できない場合は登録済みプロジェクトの通称一覧を提示し、選ばせる
- 新規プロジェクトの場合:
- パスをユーザーに確認する
- 通称・説明・よくある作業例を推定し、ユーザーに確認してから
registry/projects.md に追記する
Step 0.5: work-skill 検索（窓口が実行）
タスク分解の前に、関連する既存の work-skill がないか検索する。マッチした work-skill はワーカーへの指示に参考情報として含める。
.claude/skills/ 配下の全 SKILL.md ファイルを列挙する- 各 SKILL.md の frontmatter (
type / description / triggers) をタスク内容と照合する。org- プレフィックスは組織運営スキルなので検索対象外
- 関連性があれば候補に含める（完全一致は不要、複数マッチは関連度順に全て）
マッチした場合:
- 人間に「関連 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 から回し直す）:
- コミット済みベースの存在確認:
--target の file existence は常に確認する。line existence は、行番号付きレビュー指摘 / パッチを入力に持つ委譲のみ検証する。live tree の未コミット変更を編集ベースとする委譲は不成立（worker の worktree / clone はコミット済みベースから切られるため対象が見えない）— commit してから委譲し直す
- 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 への追加依頼の境界」は要約）:
- 追加依頼は元タスクのスコープ内に限る: brief で示した範囲内の補足・修正指示のみ追送する。スコープ外の別件は同 worker に投入せず、Step 0 から本 SKILL を回し直してディスパッチャー経由で別 worker を派遣する
- worker のスコープ拡張提案は escalation 経由: 窓口は一次承認せず
/org-escalation を発動する
- 窓口は 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)
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 を参照している）。
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 回目以降は状態を変えない）。
- ワーカーへ ack を返す（
.claude/skills/org-delegate/references/ack-template.md の「Codex 往復上限での停止 ack」節）。ワーカーの報告がまだ届いていなければ、ack で残指摘と自己評価の報告を求める
.state/workers/worker-{task_id}.md の Progress Log に拒否（used / allowed）と残指摘の要旨を追記する。現在値は python3 tools/codex_round_cap.py status --task-id <task_id> で確かめる- 窓口が次のどれかを選ぶ:
許可回数を増やせるのは窓口だけで、ワーカーからは書けない（許可回数は窓口側 .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 によりブロックされる（スコープ逸脱）。介入はあくまで「指示の再送」で行うこと。