組織を起動する。前回の状態を読み込んでブリーフィングし、 ディスパッチャーペインを起動する。ClaudeCode起動直後に1回実行する。
「起動して」「スタート」「始めて」等でも発動。
中文简介正在准备中。当前显示原文说明。
安装前可以查看交给 AI 代理的指令内容。
ClaudeCode起動後に最初に実行するスキル。前回の状態復元とディスパッチャー起動を行う。
キュレーターは起動しない: worker クローズ時の閾値チェックでディスパッチャーがオンデマンド起動する （
.dispatcher/references/pane-close.mdStep 5）。 org-start では curator の identity をStateWriter.CLEARで明示クリアする（Block D-5）。 curator 不在（null）が正常系である。設計メモ・経緯は.claude/skills/org-start/references/rationale.md。
前提: この Claude は
renga --layout opsで起動された窓口ペイン内で動作している。RENGA_SOCKET/RENGA_PANE_ID環境変数が継承されているので、mcp__renga-peers__*MCP ツール 14 種（spawn_pane/spawn_claude_pane/close_pane/focus_pane/list_panes/new_tab/send_message/list_peers/set_summary/check_messages/inspect_pane/poll_events/send_keys/set_pane_identity）でペイン操作・ピア通信・画面スクレイプ・lifecycle event 購読・raw キー入力まですべてカバーできる（renga 0.18.0+ で導入された構造。現行 org の renga transport サポート下限は 2.0.0）。 ただしこの 14 種はタブ scope が一様ではない（pane 制御 / Group B / messaging / 例外）。分類の正本はdocs/contracts/backend-interface-contract.mdT-§cap / T-§4.2、要約は.claude/skills/org-start/references/rationale.md。state DB 前提:
.state/state.dbが唯一の SoT。 read 経路は DB のみ、構造化セクション (Status / Dispatcher / Curator / Worker Directory Registry / Active Work Items / Resume Instructions) の write 経路はStateWriter.transaction()経由（post-commit hook が.state/org-state.mdを DB から自動再生成、markdown 直接編集禁止 — drift_check が検出する）。free-form ノート（学び / Pending Lead 等） はnotes/配下に保存する。 DB が無い場合はpython3 -m tools.state_db.importer --db .state/state.db --root . --rebuild --no-strictで構築する。
輸送層（transport）両系 — 既定
renga/ opt-inbroker: 本スキルのmcp__renga-peers__*呼び出しは 既定renga（ORG_TRANSPORT無設定）で書いてあり、そのまま従えばよい（既定挙動は不変）。ORG_TRANSPORT=broker（opt-in・切戻し可）では MCP サーバー名がorg-brokerになり、ツールの 完全修飾名がmcp__renga-peers__*→mcp__org-broker__*に機械置換される（引数形・セマンティクスは同一なので手順の論理は変わらない）。輸送依存で手順が変わる点だけ broker 併記する:
- 受信モデル（push 一次 =
claude/channel/ pull フォールバック）: renga は dispatcher / worker のメッセージが<channel source="renga-peers" …>として in-band で push される。broker は push 一次に再設計されている（runtime push-first 0.1.24+、transport-labdocs/design/broker-native-roles.md§9）: 各ペイン同居の channel sidecar（server:org-broker-channel）が broker キューを ~1 秒間隔で claim→push し、notifications/claude/channelで本文を idle セッションへ注入する（renga の in-band push と同じ「受けたら即応答」契機）。pull はフォールバック層: sidecar 不在 / unhealthy（heartbeat timeout でdelivery_mode=PULL）/ channel 非対応ペイン / claude.ai login 不在時は、各役割が自身の cadence で能動的にcheck_messages（broker ではmcp__org-broker__check_messages）する（§9.6 読み替え表の役割別 cadence。ナッジが出れば契機になりうるが idle を起こさないため能動 poll が受信の正路。既存の「ナッジを見たらcheck_messages」prose は撤回せずこの fallback cadence として読む。ツール名以外の手順は同型）。契約面は Surface 8 で push 一次が ratified 済み（2026-06-15、S3。broker pull-only を supersede し pull は fallback として retain・renga 不変）。- spawn 儀式（folder-trust 承認 + dev-channel sidecar 承認の再導入）: renga の
spawn_claude_paneは--dangerously-load-development-channels server:renga-peersを注入し「Load development channel?」を画面判定で承認する（Block D-1）。broker は--mcp-config <broker>を注入し承認プロンプトが Claude Code の folder-trust プロンプトに変わる（画面判定で機械承認）のに加えて、push 一次のため channel sidecar を--dangerously-load-development-channels server:org-broker-channelで load し dev-channel 承認プロンプト（spawn-flow 3-3b）を画面判定で 再導入機械承認する（ratified §5/§8.5 の folder-trust フローへの加算であり置換ではない。設計は broker-native-roles.md §9.5）。画面判定 =inspect_pane→claude-org-runtime dispatcher spawn-prompt-stepが返した 1 手だけをsend_keysする反復（runtime 0.1.43+）。盲目 Enter は禁止（folder-trust の初期カーソルは「No, exit」で、Enter 一発は起動したセッションを終了させる）。- エラー分岐（broker 追加コード）: renga コード（
[split_refused]/[pane_not_found]/[cwd_invalid]等）に加え broker は[token_invalid]/[session_invalid]/[tool_not_authorized]/[no_backend]（= adapter_unavailable）/[nudge_failed]/[peer_not_found]/[name_taken]を返しうる（未知コードは default-branch で escalate）。一覧は.claude/skills/org-delegate/references/renga-error-codes.mdの broker 節を参照。
new_tab/focus_paneは broker surface に無い（意図的除外。本フローは元々使わない）。契約面の正本はdocs/contracts/backend-interface-contract.mdSurface 8（broker auth & delivery、ratified 2026-06-14。push 一次への additive 改訂 S3 が ratified 済み（2026-06-15、「Ratified amendment」節）・既存 ratified 本文不変更）、設計 SoT は transport-labdocs/design/broker-native-roles.md§9（push 一次再設計）/docs/design/ja-migration-plan.md§5.2(ii)・§8。broker 実走（dogfood）は Epic #6 Issue G スコープで本スキルの既定経路ではない。（既定の二フレーム注記（Refs #604）: ここでの「既定
renga」は運用既定（broker 実走 dogfood が Epic #6 Issue G まで未活性）の意。別にコード既定としてtools/transport.py: DEFAULT_TRANSPORTが runtime 0.1.28 (Epic #586) でbrokerにフリップ済みで、ja 生成器・transport.resolve()はこのコードフレームで render するため生成面は「既定broker」と表示する — 両フレームは指す対象（運用経路 vs コード定数）が異なり矛盾しない。総説は rootCLAUDE.md「輸送層（transport）両系」節。）
ORG_TRANSPORT 環境変数を確認し、以降の手順で使う MCP サーバー名を確定する:
echo "${ORG_TRANSPORT:-renga}"
renga（無設定を含む既定）: 本スキル記載のとおり mcp__renga-peers__* をそのまま使うbroker: 以降の手順（Step 0 の残りサブステップ〜Block D・失敗モードを含むすべて）のツールを mcp__org-broker__* で呼ぶとここで決めてから MCP 呼び出しに入る（冒頭注記の機械置換）。broker 環境で判定せずに mcp__renga-peers__* を先に叩くと「RENGA_PANE_ID not set — Claude Code was not launched by renga」エラーで初めて気づく無駄な往復になるmcp__renga-peers__set_summary（broker では mcp__org-broker__set_summary）で自分のサマリーを設定する: 「Secretary: 窓口」
list_peers で窓口を発見するために必須mcp__renga-peers__list_panes（broker では
mcp__org-broker__list_panes）を呼び出す。
renga mcp install の実行を促す。詳細は README の「インストール」
セクション参照renga mcp install は renga 専用の復旧手順なので適用しない。
broker daemon の起動状態と --mcp-config に渡す broker 設定をユーザーに
確認してもらうfocused=true を「自分」と読まない）: list_panes の
focused は「そのタブで今フォーカスされているペイン」であって caller 自身ではない。人間が
フォーカスを移した瞬間 focused は別ペインを指すので、そこを起点にすると無関係のペインを
secretary に改名しうる。identity の検証も修復も、契約
docs/contracts/backend-interface-contract.md
T-§4.2 の caller pane id 取得規則に従って caller pane id 起点で行う:
RENGA_PANE_ID を caller pane id の起点にする（renga が起動したペイン内でのみ
継承される。冒頭「前提」で挙げた環境変数で、未設定は detached 相当）:
echo "${RENGA_PANE_ID:-unset}"
mcp__renga-peers__list_panes（broker では mcp__org-broker__list_panes）を列挙し、
同一 id のレコードが存在することを照合する（id recycle / 列挙不能の検出）。照合できた
そのレコードが caller 自身であり、以降の期待値判定と修復はこのレコードだけを対象にするname == "secretary" かつ role == "secretary"caller-id 未確定 の場合 — RENGA_PANE_ID が未設定 / list_panes に同一 id のレコードが
無い / broker 等そもそも同等の caller-id を入手できない transport: 自己修復（下の自動リカバリ）を
実行せず、identity 未確認のまま人間に報告して続行判断を仰ぐ（勝手に fatal にしない。相対セレクタは
hook が deny する）。broker の縮退の具体は下の broker 分岐を参照renga --layout ops 以外の経路で起動された / 旧ops.tomlで起動された既存セッションに attach 等:
mcp__renga-peers__set_pane_identity(target="<RENGA_PANE_ID の値>", name="secretary", role="secretary") を呼んで自動修復（照合済みの数値 pane id で撃つ）bash tools/journal_append.sh secretary_identity_restored note=auto_recovered）name_in_use（broker では name_taken）エラー: 既存の別ペインが secretary を占有している。ユーザーに状況を報告し、「現セッション継続なら全ワーカーに to_id="{numeric_pane_id}" で送信させる」「永続修復なら /org-suspend → 終了 → renga --layout ops で再起動」の選択肢を提示name_invalid / その他: ユーザーに原因を報告ORG_TRANSPORT=broker）の場合: broker には RENGA_PANE_ID に相当する caller pane id が無く、secretary 自身の pane record が存在しないこともある。したがって broker では上の caller pane id 取得規則が最初から caller-id 未確定 に落ち、set_pane_identity による自動修復は行わない（相対セレクタで撃てば [pane_not_found] no pane for target 'focused' になるが、そもそも撃たない）。上記の不一致リカバリは再試行せず、この分岐に進む。この結論は下の「broker 論理エントリ注記」にも等しく及ぶ — list_panes に数値 id のエントリが在って手元で掴めていても例外にならない。数値 id であることは契約 T-§4.2 Group B の MUST の片方（相対セレクタでないこと）しか満たさず、もう片方（自タブと確立済みの列挙から採った id であり、かつ対象が caller であること）を満たさないからである。 このとき mcp__org-broker__list_peers を identity 検証の充足根拠にはしない（下記のとおり、承認の有無によらずこの経路から得られるものは無い）。list_peers を引くのは messaging 経路が生きていることの確認までで、broker の send_message ルーティングは peer 登録で成立し secretary の pane record を要求しないので、その確認自体には意味がある — ただしそれは identity の検証ではない（契約が MUST で禁じる「messaging 到達性から pane 制御到達性を推論する」に踏み込まないため、両者を明確に分ける）。この list_peers の直前にも .claude/skills/org-delegate/references/capability-first-drive-operational-gate.md を Read し、monitoring-read-only の分岐を適用する（同 reference §6 の表 #2b）。capability 形かつ未承認なら列挙を identity 検証の充足根拠にせず破棄し、name="secretary" の一致で満たされたとみなさない（予約名 secretary は別 org の並走タブに同名で実在しうる。共有 reference §3-B-1）。その場合は identity 未確認のまま人間に報告して続行判断を仰ぐ（勝手に fatal にしない）。承認済み（同 reference §2 の first_drive が recorded）のときも同じ結論になる: §1-2-d のとおり list_peers は caller を除外するので、name="secretary" に一致したレコードは同タブに 1 件だけ在っても自分ではありえず、自 identity の検証根拠にできない（承認の有無によらず、この経路が列挙から得られるものは無い）。なお現行 org-broker は本 amendment の capability を 1 つも広告しないので、この段落で言及した monitoring-read-only の縮退（capability 形かつ未承認のときの列挙破棄）は broker 面では発火しない。caller-id 未確定 の方は別物で、broker では常に発火する — capability の広告有無は first-drive gate を制御するだけで、欠けている out-of-band な caller pane id を供給しないからである。したがって broker 面でも上記の「自己修復せず人間へ報告して続行判断を仰ぐ」は必ず通る
broker 論理エントリ注記: broker の
list_panesに geometry が全て 0（w=0 h=0）でkindが null のエントリが現れることがある。これは残骸とは限らず、**adapter 実体を持たない論理エントリ（human-driven logical pane）**でありうる。典型は root secretary（窓口）自身の bookkeeping entry。扱いは次のとおり:
inspect_paneは adapter 不在のため失敗する（socket close を観測する）。調査目的で叩かないclose_paneは[logical_pane] cannot close a human-driven logical paneで拒否される。残骸と決めつけて close を試みない- このエントリの
name/roleが期待値（secretary/secretary）とずれたまま残っている場合（手動テストの名残等）でも、set_pane_identityによる改名修復はしない。上の broker 分岐と同じ結論に落とし、ずれを人間に報告して続行判断を仰ぐ。理由は、そのエントリが caller である証明が形状からは立たないためである — geometry 全 0 /kindが null / root secretary の bookkeeping entry という形が示すのは「adapter 実体を持たない論理エントリである」ことだけで、「それが自分である」ことではない。数値 id で撃てば相対セレクタは避けられるが、それは MUST の片方にすぎず、caller である裏付けを欠いたまま撃てば無関係のペインをsecretaryに改名しうる
registry/projects.md は operator-local な生成ファイル（.gitignore 済み）で、
コミットされているのはテンプレート registry/projects.example.md の方である。
fresh clone 直後は実体が無いので、ここで生成する:
python3 tools/ensure_projects_registry.py # Mac/Linux
py -3 tools/ensure_projects_registry.py # Windows native
created: なら新規生成、ok: なら既存のままheader drift: の場合、テンプレートに増えた列が手元ファイルに無い。
警告であり org-start は止めない（exit 0）。表示された列名をユーザーに伝え、
手元の registry/projects.md の表ヘッダー行とセパレーター行へ追記するよう案内する
（既存データ行は編集不要。空セルは従来動作を保つ）error: で exit 1 の場合はテンプレート自体が壊れている。ユーザーに報告して続行する
（後続の Block B / D はレジストリを読まないので org-start 自体は継続できるが、
ワーカー派遣前に解消が必要）docs/operations/registry-projects-migration.md を参照registry/org-config.md の workers_dir を読み、ワーカーディレクトリの存在を確認する。
存在するディレクトリがあれば一覧をユーザーに報告する。過去の作業成果や再利用可能なプロジェクトを含むため削除はせず、org-delegate のディレクトリ保持ポリシーに従う。起動順: Step 0 (transport 判定 / set_summary / MCP 疎通 / identity 検証 / projects レジストリ配置 / workers_dir 確認の 6 サブステップすべて) が完了した後に dispatcher の
spawn_claude_paneを発火し、Claude 起動待ち (〜30〜60s) と並列に Block B (前回状態の DB 読み込み) / Block C (ダッシュボード server 起動) を進める（短縮効果は.claude/skills/org-start/references/rationale.md）。実行モデル: Secretary が以下の 3 ブロック (A/B/C) を発火し、最後に block D で合流する。block A は I/O bound（renga MCP の応答は数百 ms、その後は別プロセスである Claude の boot を待つだけ）なので B/C と wall-clock を完全に overlap できる。
ペイン配置は org-delegate/references/pane-layout.md に従う (renga 版)。curator はここでは spawn しない（オンデマンド化、本ファイル冒頭注記）。
spawn_claude_pane:
mcp__renga-peers__spawn_claude_pane(
target="focused",
direction="horizontal",
role="dispatcher",
name="dispatcher",
cwd=".dispatcher",
permission_mode="bypassPermissions",
model="sonnet"
)
"Spawned pane id=N." から dispatcher の pane_id を控える。引数の意味と落とし穴は .claude/skills/org-start/references/rationale.md「spawn_claude_pane 引数の詳細」を参照。[<code>] <msg> で失敗していた場合は本ファイル末尾「### 失敗モード」へ。spawn が成功（pane_id 取得）なら、Block B / C と並列に進む。read 経路は DB only（例外は手順 3 の pending-decisions register だけ）。Block A の spawn 発火と並列で実行する（Block A は MCP 経由でペイン作成を依頼するだけで Claude の boot は別プロセスのため、ここで CPU / I/O を競合しない）。
.state/state.db が存在するか確認し、存在すれば中身にテーブルがあるかも確かめる（Issue #1154: ファイルはあるがテーブルが 1 つも無い空の DB がありうる）:
# Windows native は python3 を py -3 に読み替える
python3 -c "import sqlite3,sys; t={r[0] for r in sqlite3.connect('.state/state.db').execute(\"SELECT name FROM sqlite_master WHERE type='table'\")}; sys.exit(0 if {'runs','events'}<=t else 3 if not t else 4)"
sqlite3.connect が空ファイルを作ってしまう）。終了コードで分岐する:
0（テーブルあり）→ DB をクエリ:
# Mac/Linux
python3 -c "from tools.state_db import connect; from tools.state_db.queries import get_org_state_summary; import json; \
conn = connect('.state/state.db'); \
print(json.dumps(get_org_state_summary(conn), ensure_ascii=False, indent=2, default=str))"
# Windows native（Git Bash。PowerShell では行末の `\` を `` ` `` に替える）
py -3 -c "from tools.state_db import connect; from tools.state_db.queries import get_org_state_summary; import json; \
conn = connect('.state/state.db'); \
print(json.dumps(get_org_state_summary(conn), ensure_ascii=False, indent=2, default=str))"
active_runs / recent_events / run_status_counts / session.status / session.objective で前回状態を把握する3（テーブルが 1 つも無い空の DB）→ 初回起動と判断する。Secretary に importer 実行を促す:
python3 -m tools.state_db.importer --db .state/state.db --root . --rebuild --no-strict4（テーブルはあるが runs / events が欠けている）やそれ以外の失敗（壊れたファイル等）→ importer を回さない（--rebuild は全テーブルを消すので、残っている記録を失う）。エラー内容を添えて「state.db が不完全で前回状態を読めない」と人間に報告し、扱いを確認するSUSPENDED なら /org-resume の Phase 1〜3（ブリーフィング・照合・再開計画）を実行する。
Block A の spawn は既に発火済みなのでブリーフィング中に裏で Claude が boot している。
ブリーフィング完了後、Block D の合流で dispatcher が ready になるのを待ち、org-resume の Phase 4（ワーカー再派遣）を人間の承認に基づいて実行するACTIVE なら、前回のセッションが突然終了した可能性がある。
各ワーカーディレクトリの git 状態を確認し、現状を報告する.state/pending_decisions.json）を読み取り専用で読む:
python3 tools/pending_decisions.py stale --min-age-min 60 # Mac/Linux
py -3 tools/pending_decisions.py stale --min-age-min 60 # Windows native
received_at）から 60 分以上経ち、まだ resolved になっていない項目（pending / escalated）が 1 行 1 件で出る。出たらブリーフィングに「要確認の判断仰ぎ」として task_id・状態・受信日時・要約を並べる{"status": "unreadable", ...}（exit 2）のときは「該当なし」と書かず「判断仰ぎ register を確認できない」とエラー内容つきで報告し、起動は続ける.dispatcher/references/worker-monitoring.md Step 5.1）が受け持つ。起動後に生じた滞留をこの一覧が何分以内に見つけるかは保証しない（次回起動まで見つからないこともある）Block A の spawn 発火と並列。ダッシュボード server は別プロセス（Python HTTP server）で Claude pane と独立。
サーバーは 8099 → 8100 → 8101 のうち空いているポートを使う（同じホストの別の組織が 8099 を使っていることがある）。案内する URL は必ず --status の出力から取り、8099 を決め打ちしない。
python3 を py -3 に読み替える。以下同じ）:
python3 dashboard/server.py --status
--status は bind 後にサーバーが書く .state/dashboard.json（実際のポートと pid）を読み、そのポートで応答しているのがこの clone のサーバーかを HTTP で確かめる。終了コード 0 なら標準出力が URL なので手順 3 へ。1（停止中）なら手順 2 へ。3（ポート記録を持たない旧版サーバーがこの組織で稼働中）なら Mac/Linux は python3 tools/stop_dashboard.py、Windows native は .claude/skills/org-down/SKILL.md Step 2 の PowerShell 手順（Get-CimInstance で CommandLine を照合してから Stop-Process）で止めてから手順 2 へ。Windows native では py -3 tools/stop_dashboard.py を使わない（内部の os.kill(pid, 0) が Windows ではプロセスを終了させるため、照合前に無関係なプロセスを止めうる）。止められなければ「ダッシュボードの再起動が必要」と報告して本 Block を終える。2（記録が壊れている / 記録のポートで別のプロセスが応答している）なら標準エラーの理由を添えて報告し、URL は案内しない。python3 dashboard/server.py &
python3 dashboard/server.py --status --wait 15
0 以外なら「ダッシュボードを起動できませんでした（<標準エラーの理由>）」と報告し、URL は案内しない（候補ポートが全部使用中、ポート記録が書けない等）。<url> は --status の標準出力）:
「ダッシュボードを起動しました → <url>」sandbox 注記（false negative 回避）: Claude Code の Bash sandbox はネットワーク / プロセス namespace が隔離されているため、本 Block の常駐起動・疎通確認を sandbox 内で行うと誤判定する。ホスト側で server が正常に listen していても、sandbox 内では
curlが000を返し、ssに port が見えず、pgrep/kill -0はホストのプロセスを観測できない（「起動失敗」と誤判定して再起動ループに陥る）。また sandbox 内のnohup ... &で起動したプロセスはコマンド終了時に残らず常駐しない。server の起動（手順 2）と疎通確認（手順 1・2 の--status、tools/stop_dashboard.pyやcurl/ss/pgrep/kill -0等）は sandbox 外で実行する（Claude Code の Bash tool ならdangerouslyDisableSandbox: trueを付ける、またはrun_in_backgroundによるホスト実行を使う）。
Block A の spawn 発火と並列。claude-org-runtime の installed バージョンと PyPI の latest を比較し、drift があれば Step 4 の起動完了報告に 1 行 warning を添える。auto-upgrade は行わず通知のみ。バージョン番号は本ファイルにも script にも hard-code せず、すべて importlib.metadata と PyPI JSON API の動的取得値のみを使う（runtime のリリースごとに記述が陳腐化することを避けるため）。
sandbox 内では PyPI に届かない → ホスト実行する: sandbox 内でしか回せない場合は exit 2 =「PyPI 未確認」となり、ネットワーク到達可能なホストで再実行するまで drift 未検証と扱う（経緯と設計メモは
.claude/skills/org-start/references/rationale.md）。
dangerouslyDisableSandbox: true を付ける）:
py -3 tools/check_runtime_version.py # Windows
python3 tools/check_runtime_version.py # Mac/Linux
[runtime drift] ... 1 行を そのまま Step 4 起動完了報告の末尾に warning として転記する。あわせて stderr の 測定 interpreter: 行が示す Python パスを転記行に添える（下記「interpreter の併記」を参照）。packaging 欠如、または installed が local install（file:// パス / VCS / editable。PEP 610 direct_url.json で判定）で PyPI 照合不能 の場合。stderr に理由診断が出る。drift は未検証なので Step 4 報告に「runtime drift: PyPI 未確認（要ホスト再実行）」を明示する（silent にしない）。local install 起因の場合はホスト再実行では解消しない（installed の実体がリリース版と限らないため）ので、stderr の診断が local install -- PyPI 照合不能 を示すときは「runtime: local install のため PyPI 照合不能（要 PyPI 由来インストールで再確認）」と読み替えて報告する。それ以外（オフライン / sandbox 内）は dangerouslyDisableSandbox: true で再実行する。interpreter の併記（バージョン報告は測った Python に相対）: 本 Block が報告する installed は「このコマンドを実行した Python が解決したバージョン」であって、ホストの状態ではない。ホストには runtime が複数入りうる（プロジェクトの
.venvとシステムpython3が別バージョンで同居し、CLI shimclaude-org-runtimeの shebang はそのどちらか片方に束ねられる）。そのため drift 行を interpreter 抜きで転記すると「更新が遅れている」と読めてしまうが、実際には「もう片方を測った」だけということが起こる。script は 毎回・全 outcome で stderr の 1 行目に[runtime drift-check] 測定 interpreter: <sys.executable> (installed=<version>)を出すので、Step 4 報告で installed / 未インストールに言及するときは必ずこの Python パスを併記する（例:「system python3 で測って installed=X」）。上の実行例がpython3/py -3である以上、測っているのは既定でシステム側であって ja の.venvではない点に注意する。
ORG_TRANSPORT=broker のときのみ実行する。renga では起動しない（broker の queue.jsonl が存在しないため。Step 0 の transport 判定が renga なら本 Block はまるごと skip する）。
broker transport では過去に「secretary 宛メッセージが claimed/delivered 記録付きで silent 消失する」障害があった（channel sidecar の二重走行レースが根因。runtime 側の observer lease で修正済み）。その再発・類似滞留に対する運用ガードとして、broker セッションでは org-start 直後に queue.jsonl の滞留 watcher を常駐させる。
run_in_background=true を付けて 1 回呼ぶだけ:
python3 tools/secretary_queue_watcher.py # Mac/Linux
py -3 tools/secretary_queue_watcher.py # Windows
$ORG_BROKER_STATE_DIR/queue.jsonl 末尾を起点に live-tail し、それ以降の secretary 宛 message_enqueued が delivered されないまま閾値（default 120 秒）を超えたら、滞留件数と経過秒を 1 行 print して exit する。background Bash の終了イベントで窓口が再起床するので、その出力を見たら使用中 transport の check_messages（broker では mcp__org-broker__check_messages）で drain する。過去ログの通算 gap は数えない（既知の過去消失分が混入して誤検知になるため、本セッション中の新規レコードのみを対象にする）。.state/secretary_queue_watcher.json（pid / cwd / cmdline / broker_state_dir を記録した sidecar）を書き、/org-suspend（Phase 3.6）/ /org-down がこれを identity 照合して停止する（pid recycle / 別 broker 誤停止を避けるため pid 単独では kill しない）。滞留検知で自 exit した場合や SIGTERM で停止した場合は watcher 自身が sidecar を掃除する。sandbox 注記: 常駐プロセスなので Block C と同様 sandbox 内起動は不可、
run_in_backgroundによるホスト実行を使う。
スクリプト本体:
tools/secretary_queue_watcher.py（--owner/--stale-sec/--poll-secで調整可。ORG_BROKER_STATE_DIR未設定なら exit 1 で即終了する broker 専用ツール）
Sidebar: attention watcher の起動案内（optional, 明示起動推奨）
承認待ち / 判断待ち / CI 失敗 / silent stop / PR merged 等を OS notification + 音 + terminal bell で能動的に通知する watcher を別途常駐させられる。
/org-startからの自動起動はしない（OS 通知 backend は環境依存が強く、勝手に音が鳴ると不快になりやすいため。設計docs/design/attention-notification.md§11 Q1）。有効化したいユーザーには Step 4 の起動完了報告と合わせて
/org-attention-startの実行を案内する。skill が以下を一括で行う:
.state/attention.json未配置時はtools/templates/attention.example.jsonから自動コピー- dispatcher ペインの右側を vertical split し
claude-org-runtime attention watch ...を常駐起動- pane_id を
.state/attention_pane.jsonsidecar に記録（停止は/org-attention-stopで参照）1 回限りの動作確認は
claude-org-runtime attention scan --state-dir .state --config .state/attention.json --dry-run --json（--configを外すと runtime 中立の英語 default が出るので、ja テンプレートの導通確認には必ず付ける）。OS 別 backend 挙動・トラブルシューティング・別ターミナルからの素 CLI 起動手順はdocs/operations/attention-watch.mdを参照。
Block A の spawn 発火と並列。各ロールの settings.local.json を schema に対して検証し、drift があれば Step 4 の起動完了報告に 1 行 warning を添える。自動修復は行わず通知のみ（修復は /org-setup）。Block C2 と同列の 非 fatal な warning ブロックであり、drift を検出しても org-start は止めない。CI は --include-local を付けず gitignored の settings.local.json を検証しないので、起動時のこの検証が唯一の定期的な契機になる（理由と drift の種類は .claude/skills/org-start/references/rationale.md）。
py -3 tools/check_role_configs.py --include-local # Windows
python3 tools/check_role_configs.py --include-local # Mac/Linux
[role config drift] ... 1 行を そのまま Step 4 起動完了報告の末尾に warning として転記する。個別の [ERROR] <path> :: <role> :: <理由> 行は同じ stdout の上部に出ているので、ユーザーが詳細を求めたらそこから提示する（起動報告に全件は貼らない。実測で数十行になりうる）。core_harness 解決失敗等）。stderr に traceback と role_configs: 検証不能 -- ... 診断が出る。silent にせず「role config: 検証不能（guard 未検証・要確認）」の 1 行を報告に添える。drift の有無は 未測定であって clean ではない、という区別が本 exit code の存在意義である。読み取りが sandbox の deny に掛かって exit 2 に落ちた場合は、dangerouslyDisableSandbox: true でホスト再実行する。必ず窓口の cwd（ja live repo root）で実行する:
--rootの既定はスクリプト位置から導出される repo root なので、worktree 内から叩くとその worktree の.claude/settings.local.json（= ワーカー用の設定）を secretary の schema で検証してしまい、数十件の false positive になる。ロール別に個別検証したい場合は当該 worktree で--role workerを付ける（--roleは--include-localの意味を含む）。
Block A の spawn 成功後、dispatcher ペインで Claude が boot している。
spawn-prompt-step に任せ、窓口は返された手だけを打つ:
date +%s%3N）。previous = nullmcp__renga-peers__inspect_pane(target="dispatcher", format="grid") を呼ぶ（lines は付けない。背の高いペインでは下端 N 行の外にダイアログが残る）{"screen": <2 の結果>, "previous_screen": <前回の inspect 結果か null>, "elapsed_ms": <開始からの経過 ms の整数>} を 1 つ渡す（画面テキストはシェルの引用へ直に埋め込まず、JSON 文字列としてエンコードしてファイル経由で渡す）:
claude-org-runtime dispatcher spawn-prompt-step --deadline-ms 120000 < "$TMPDIR/spawn-prompt-step.json"
# PATH に無ければ: python3 -m claude_org_runtime.dispatcher.runner spawn-prompt-step --deadline-ms 120000
# （Windows native は py -3 -m claude_org_runtime.dispatcher.runner spawn-prompt-step --deadline-ms 120000）
action: "send_keys": 返された send_keys オブジェクトをそのまま mcp__renga-peers__send_keys(target="dispatcher", ...) に渡す（enter を自分で足さない）。previous = null にして 1 秒待ち 2 へaction: "wait": previous = 今回の inspect 結果にして 1 秒待ち 2 へaction: "done": 承認完了。手順 2（list_peers poll）へ[key_unsupported] 等）: Enter を送らずに中止し、ペインの状態をユーザーに報告して判断を仰ぐ（下記「失敗モード」の起動失敗として扱う）server:renga-peers チャネルが有効化されず、send_message の channel push が届かない。未表示段階では判定が wait を返すので、done まで反復すればよい（Enter を「念のため再送」しない）ORG_TRANSPORT=broker）の場合 — 承認は 2 段（folder-trust + dev-channel sidecar の再導入）: spawn_claude_pane は --mcp-config <broker>（daemon）を注入し、初回に Claude Code の folder-trust プロンプトが出る。加えて push 一次のため channel sidecar を --dangerously-load-development-channels server:org-broker-channel で load するため「Load development channel?」プロンプトが再出現する（--mcp-config-only 設計で一旦消えた 3-3b 承認の再導入）。手順は上と同じループを mcp__org-broker__inspect_pane / mcp__org-broker__send_keys で回す（判定が 2 つのダイアログを順に扱う。順序は boot タイミング依存）。WezTerm adapter は Up / Down を送れず [key_unsupported] になるので、そのときも Enter に倒さず中止して報告する。承認しないと broker token のバインド／channel sidecar の登録が完了せず、次の list_peers 待ちが同様にタイムアウトする（ratified §5/§8.5 の folder-trust フローへの加算であり置換ではない。設計 broker-native-roles.md §9.5）list_peers の直前に .claude/skills/org-delegate/references/capability-first-drive-operational-gate.md を Read し、monitoring-read-only の分岐を適用する（同 reference §6 の表 #2）。
mcp__renga-peers__list_peers
# 結果に name="dispatcher" が現れるまで poll
done なら承認は済んでいるので poll を続ける）、(b) [pane_not_found] 等 fatal なら「失敗モード」セクションへname="dispatcher" の一致だけで登録ゲートを開けない — 予約名は別 org の並走タブに同名で実在しうるので、name 一致は「まだ登録していない自分の子」のゲートを他 org のピアで開けてしまう（契約 T-§2.2「MUST NOT key a lookup … on name alone」／共有 reference §3-B-1）
list_panes の生存と inspect_pane のプロンプト表示は Claude が起動したことしか示さず、MCP の peer 登録が済んだことを示さない。プロンプトが見えた時点で boot 完了とみなすと、手順 3 の一度きりの挨拶が [pane_not_found] で消える。したがって: (a) list_panes でペイン生存だけ確認し、(b) 手順 3 の send_message を送り、(c) [pane_not_found]（broker では [peer_not_found]）で失敗したら 2 秒間隔・最大 30 秒で再送する（その間も Enter は再送せず、承認が未完了なら Block D-1 の画面判定ループを done まで回す）、(d) 送達成功をもって「起動・登録・挨拶送信」が同時に確定するfirst_drive が recorded）のとき: 登録受理の判定を同 reference §1-2 の三値判定に委ね、name="dispatcher" が**「在」（同タブ・一意）のときだけ受理する。poll の継続・再送予算・受理後の挨拶送信・予算切れの失敗処理は §1-2-c のとおりこの経路の従来手順のまま**で、ここに重ねて書かない
unknown が残っていた場合は fatal に落とさない（close_pane + StateWriter.CLEAR へ進まない）。タブ数 / ピア総数 / 他タブ判定数 / unknown 件数を添えて人間に報告し判断を仰ぐ（共有 reference §1-2-b: unknown を「peer 未登録」に潰さない）。「不在」「他タブのみ」で予算切れになったときは従来どおり「失敗モード」の分岐に落とす.state/state.db 不在 → importer --rebuild が走った場合、schema 構築完了までは StateWriter.update_session() が失敗するので、Block D-5 の DB write 前に Block B が完了している必要がある。Block B が SUSPENDED ブリーフィング待ちで未完了なら、ブリーフィング完了 → DB schema 健全性確認 → ここに進むStateWriter.transaction() 経由、markdown 直接編集禁止。post-commit hook が .state/org-state.md を再生成)。dispatcher の identity を write し、curator の identity は常に StateWriter.CLEAR で明示クリアする（オンデマンド化により常駐 curator は存在しない。旧仕様の SUSPENDED 状態から繰り越した stale な curator_pane_id / curator_peer_id が残ると、ダッシュボードと balanced split target 選出が生きた curator がいる前提で誤判断する。StateWriter.update_session() は None 渡しを「未指定 = 保持」と解釈する契約なので、明示クリアが必須）:
# 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_session(
dispatcher_pane_id='<d_pane>', dispatcher_peer_id='<d_peer>',
curator_pane_id=StateWriter.CLEAR, curator_peer_id=StateWriter.CLEAR,
)
"
# 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_session(
dispatcher_pane_id='<d_pane>', dispatcher_peer_id='<d_peer>',
curator_pane_id=StateWriter.CLEAR, curator_peer_id=StateWriter.CLEAR,
)
"
dispatcher_peer_id に StateWriter.CLEAR を渡す。縮退中は <d_peer> を観測できていないので、推測値や他タブ由来の id を書くと以後の routing が壊れた宛先を掴む。ここで「未指定 = 保持」に倒してはならない: /org-start は dispatcher ペインを新規 spawn するので、DB に残っている値は前セッションの死んだペインのものであり、保持は stale の温存になる（生きたペインを引き継ぐ .claude/skills/dispatcher-resume/SKILL.md Step 0 とはここが逆になる。あちらは同じペインが生きているので保持が正しい）。dispatcher_pane_id は list_panes から確定できるので通常どおり書く。peer_id が null の間、dispatcher への送信は安定名 to_id="dispatcher" で行う（root CLAUDE.md の既定の宛先指定と同じ）。この状態はユーザー報告に含める。python3 dashboard/org_state_converter.py # Mac/Linux
py -3 dashboard/org_state_converter.py # Windows native
Block D の合流が終わった後に 1 回実行する（Block D-1 の画面判定の最中に走らせない）。ディスパッチャーの文脈が閾値を超え、ターンの区切りで静かなときに、/dispatcher-handover auto op=<OP> → /clear → /dispatcher-resume auto op=<OP> を外から打つ決定的プロセス（LLM を含まない）をペインなしの常駐プロセスとして起動する。設計は docs/design/context-auto-handover.md、本体は tools/context_handover_watch.py。測る材料はディスパッチャーの settings に置いた記録フック（context-record.sh、.claude/skills/org-setup/references/permissions.md のディスパッチャー節）が書く .state/context/dispatcher.json で、これが無い間 watcher は何もしない。
<env 前置>python3 tools/context_handover_watch.py --daemon
<env 前置> は .claude/skills/pr-watch-pane/SKILL.md Step 3-1 の env 前置注入と同じ規則で作る（窓口ペインの ORG_TRANSPORT / ORG_BROKER_STATE_DIR / PATH の実値を export ...; で並べ、空の変数は export 文ごと省く）。watcher は transport を解決して打鍵先（renga CLI か tmux）を選び、失敗の通知を tools/peer_notify.py で送るので、窓口と同じ値が要る--daemon は watcher を窓口のシェルから切り離して起こし、.state/context_handover_watch.json に pid が載るのを見届けてから戻る。ログは .state/context_handover_watch.log に追記される（稼働中は状態が変わった行だけ）DAEMON: started pid=... log=...（exit 0）→ 稼働中、報告不要 / 自動引き継ぎ無効: ...（exit 3）→ broker の terminal adapter が tmux でない、または Windows native（--daemon は POSIX のみ。停止経路が無いため）。起動完了報告に「文脈の自動引き継ぎ: 無効（<理由>）」と 1 行書く / already running ...（exit 3）→ 既に動いている（/org-resume での再実行など）。何もしない / DAEMON: exited at start または did not register（exit 1）→ ログを読み、起動完了報告に「文脈の自動引き継ぎ: watcher を起動できず（<理由>）」と 1 行書く。別の方法で代わりに回さない。自動引き継ぎが無いだけで、手動の DISPATCHER_HANDOVER 経路は使えるpython3 tools/context_handover_watch.py --status。pid ファイルの pid と生きているプロセスの cmdline・cwd を照合し、STATUS: running pid=...（exit 0）か STATUS: not running（exit 1。残骸の pid ファイルがあれば stale sidecar と付く）を返す.state/context_handover_watch.json（pid / cwd / cmdline）を書き、/org-suspend Phase 3.65 / /org-down が python3 tools/context_handover_watch.py --stop で照合して止める。ペインが無いので teardown では閉じず、この --stop が唯一の停止経路になるauto_handover_failed を events に書き、窓口へ DISPATCHER_AUTO_HANDOVER_FAILED: op=... stage=... reason=... を送り、30 分は試さない。受けた窓口は人に伝える（/clear 済みの段で止まったときは、ディスパッチャーペインに /dispatcher-resume を打てば戻れる）。切り替えの前後で稼働中ワーカーや判断仰ぎが消えていれば DISPATCHER_AUTO_HANDOVER_LOSS_SUSPECTED: ... が届くので、これも人に伝える。ディスパッチャーからの DISPATCHER_AUTO_HANDOVER: 自動引き継ぎ中 ... は知らせだけで、窓口は打鍵しない。sandbox 注記:
--daemonは窓口が sandbox の外で実行する（renga CLI / tmux のソケットに届き、常駐プロセスを残せるのは外だけ）。起こされた watcher は窓口のシェルから切り離されているので、窓口を/clearしても止まらない。
Block A の spawn 段階で分類する:
[split_refused] / [cwd_invalid] / その他 [<code>]) — 失敗をユーザーに報告し、原因解消後 /org-start を再実行するStateWriter.CLEAR で消した上でユーザー報告し /org-start 再実行を促す
docs/contracts/backend-interface-contract.md T-§4.2「Fail-safe consequence for Group B」）。spawn 戻り値で pane_id が手元にあることは免除にならない — 未確立の列挙では、下の identity 照合の結果そのものを信用できないため:
org-broker。同契約 §8.1 / §8.10）/ (ii) caller_scope を確立できている（同 T-§cap）のいずれか 1 つが成立すること。どちらも不成立なら close_pane を撃たない — その場合はペインを残したまま StateWriter.CLEAR とユーザー報告だけを行い、「dispatcher ペイン (id={N}) が残っているので手動で閉じてほしい」を報告に含める（相対セレクタへはフォールバックしない）mcp__renga-peers__list_panes で spawn 戻り値の pane_id が name == "dispatcher" かつ role == "dispatcher" をなお指しているか確認する。別ペインへ再割当て済み / 列挙に現れない場合は close せず、同じく StateWriter.CLEAR と報告に倒す（pane_id recycle 対策）mcp__renga-peers__close_pane(target=<照合済みの数値 pane_id>) で破棄するlist_peers に居ない = peer 未登録」という判定が成立せず（共有 reference §1-1 / §3-B-1）、それを根拠に close_pane + StateWriter.CLEAR を撃つと健全な dispatcher ペインと 2 つの identity を破棄する。代わりに Block D-2 の縮退手順で使う「挨拶 send_message の再送」が 30 秒の予算を使い切って一度も送達しなかったことを fatal の根拠にする（プロンプトが見えていても、送達できない dispatcher は org-delegate / SECRETARY_RELAY を担えないので起動失敗である）。その場合は従来どおり両 identity の StateWriter.CLEAR + ユーザー報告を行い、ペインの破棄は上の 3 段（自タブ確立 → identity 照合 → 数値 close）を踏んでから撃つ（踏めなければ close せず、ペインが残る旨を報告に含める）。「ペインが boot していれば fatal にしない」ではない — 到達不能な dispatcher を抱えたまま /org-start を成功として報告してはならないdone を返す前に先へ進まない（プロンプト未表示の間は wait が返る）。判定が escalate（exit 10）/ 入力不正（exit 2）/ ツールエラーで止まったら Enter に倒さず、ペインの状態を添えてユーザーに報告する（folder-trust で Enter を打つと「No, exit」が選ばれて dispatcher が終了する）。Block D-2 の peer 登録 poll が登録の ground truthcurator の spawn / boot 失敗モードは org-start には存在しない（spawn しないため）。オンデマンド起動時の失敗ハンドリングは .dispatcher/references/pane-close.md Step 5-3 / 5-4 を参照。
dispatcher は初回 DELEGATE 完了報告で「/loop 3m で監視します」と宣言したまま実 invoke せず idle に落ちることがある（宣言はターン終了と同時に失効し、次の契機がなければ実行されない）。窓口は初回 DELEGATE 完了報告や監視宣言を信用せず、使用中 transport の inspect_pane(target="dispatcher") で /loop の実行痕跡（loop 予約 / 監視サイクル出力）を確認し、無ければ send_keys で /loop 3m <監視ディレクティブ> を user turn として打鍵し再点火する。打鍵は text と Enter を別呼び出しに分ける 2 段（send_keys(target="dispatcher", text="/loop 3m ...") → inspect_pane で入力欄に乗ったことを確認 → send_keys(target="dispatcher", enter=true)。text+enter 同時送は draft 残りで未武装が再発しやすい。.dispatcher/references/spawn-flow.md 3-5a と同じ手順）で行う（いずれも Step 0 で判定した transport の完全修飾名で呼ぶ。監視ディレクティブは placeholder のまま打鍵せず、.claude/skills/dispatcher-resume/SKILL.md Step 5 のコードブロック正文をそのまま使う。手順詳細は .dispatcher/references/worker-monitoring.md）。send_message / check_messages 経由の指示では武装しない — 打鍵による user turn 注入が確実な武装手段である（ultracode 武装と同型の構造）。
人間に簡潔に報告する。起動するのはディスパッチャーのみ（キュレーターはオンデマンド）。
Block C2 / C4 の warning 行の置き方: 各 Block の exit code の項で決まった行（drift 行・「PyPI 未確認」・「検証不能」等）を、下記いずれのテンプレートでも 末尾に空行を 1 つ挟んだ上でそのまま転記する。両方出る場合は 1 行ずつ並べる。exit 0 は何も付けない。
Sidebar: dispatcher の自己修復ビュー起動案内（broker フレーム時のみ、optional）
broker(tmux) backend では dispatcher ペインは detached tmux session として独立して存在する。窓口の隣のターミナルでこれを 1 回起動しておくと control plane を常に視界に保てる（restart / auto-compact fork でセッション名が変わっても自己修復で再 attach し直す）:
tools/org-dispatcher-view.sh # read-only attach（既定・安全） tools/org-dispatcher-view.sh --rw # 読み書き attach（誤入力で dispatcher に直接打鍵されるので注意）read-only で十分だが、attach 中に
Ctrl-b sで同 socket 上の他のセッション（= worker / curator のペイン）に切り替えて覗ける。終了はCtrl-b dで detach してからプロンプトでCtrl-C。renga フレームでは tmux session モデルが写像しないので案内しない（renga なら画面そのものを見ればよい）。詳細はtools/org-dispatcher-view.shの--help。打鍵の読み替え: 上記
Ctrl-bは tmux prefix の既定値なので、prefix を変更している場合は設定した prefix に読み替える。さらに、この broker フレームのビューアを renga の画面の中で起動する場合はこの打鍵が届かない — renga の org サイドバーは既定で有効なあいだCtrl+B（tmux prefixCtrl-bと同じ物理入力）を消費して PTY へ渡さないため、Ctrl-b sでの切替もCtrl-b dでの detach もできなくなる（抜けられなくなるので起動前に対処する）。回避策（renga 設定[ui] org_sidebar = "off"、または内側 tmux prefix の変更）はdocs/operations/dispatcher-view.md「外側フレームが renga の場合」を参照。
前回の状態がある場合:
組織を起動しました。
前回の状態: {サマリー}
ディスパッチャーを起動しました（キュレーターは知見が溜まったときに自動で一時起動されます）。
何をしますか？
初回起動の場合:
組織を起動しました。
ディスパッチャーを起動しました（キュレーターは知見が溜まったときに自動で一時起動されます）。
プロジェクトはまだ登録されていません。何をしましょうか？
drift 検出時の warning 添付例 (上記テンプレートの末尾に転記。{installed} / {latest_in_window} / {pin} は実行時にスクリプトが PyPI と pyproject.toml から動的に決定するもので、本ファイルには hard-code しない):
...
何をしますか？
[runtime drift] claude-org-runtime: installed={installed} latest={latest_in_window} -- `python3 -m pip install --upgrade 'claude-org-runtime{pin}'`（Windows は `py -3 -m pip ...`）で更新できます
role config drift 検出時の warning 添付例 (Block C4 exit 1。{errors} / {findings} は実行時にスクリプトが決定するもので、本ファイルには hard-code しない。Block C2 の行と両方出るときは 1 行ずつ並べる):
...
何をしますか？
[role config drift] {errors} error(s) / {findings} finding(s) -- see the [ERROR] lines above
ユーザーが再実行コマンドを求めたら、上の手順 1 のコマンド（py -3 / python3 のプラットフォーム別）をそのまま案内する。スクリプトは再実行コマンドを出力しない: 貼って動く形は読み手のシェル（cmd.exe / PowerShell / Git Bash）ごとに quoting が非互換で、プロセス側からはどれで読まれるか知りようがないため、誤った形を出すより窓口が固定文で案内する方が確実。
Block A / org-delegate Step 3 で使う spawn_claude_pane の役割別パラメータ。
renga 0.18.0+ では mcp__renga-peers__spawn_claude_pane が役割別の構造化フィールド（cwd / permission_mode / model / args[]）を受け取り、--dangerously-load-development-channels server:renga-peers を自動付与する。旧方式の cd X && claude ... を spawn_pane に流し込むパターンは 禁止（renga の bare-claude auto-upgrade が発動せず channel push が届かなくなる落とし穴を再導入するため）。
共通引数:
permission_mode: auto リテラル直書き（ディスパッチャー除く）。CLAUDE.md には変数展開機構がないため registry/org-config.md の値を実行時に代入することはできない。値を変更する場合は registry/org-config.md 冒頭の同期注意セクションを参照cwd: 各ロール専用ディレクトリへの相対パス（caller pane の cwd 基準で解決される）注: Secretary は
renga --layout opsで起動され、--permission-mode未指定のまま動作する（人間判断窓口のため）。registry/org-config.mdの「Role別の適用範囲」節を参照。
cwd=".dispatcher"permission_mode="bypassPermissions"（固定。default_permission_mode の影響を受けない）model="sonnet"理由: ディスパッチャーはワーカー起動時に mcp__renga-peers__spawn_claude_pane を発行する。auto モードの安全分類器はこの「子エージェント起動」を "Create Unsafe Agents" と判定してブロックするため、auto ではワーカー派遣が成立しない。
ディスパッチャーが worker クローズ時の閾値超過で spawn する（.dispatcher/references/pane-close.md Step 5-3）:
cwd="../.curator"（caller は dispatcher、cwd=.dispatcher/ 基準の相対解決）permission_mode=automodel="sonnet"理由: auto モードの safety classifier はセッションモデルと独立した専用モデルで動作し、承認判定はセッションモデルに依存しない（公式: https://www.anthropic.com/engineering/claude-code-auto-mode）。キュレーターの知見整理ワークロードは軽量・機械的側に分類できるため Sonnet で十分（ワーカーのモデル方針とは独立の判断）。
既定は model="sonnet"。窓口が DELEGATE 本文に モデル: opus 行を載せたときだけ model="opus"。
Opus にするかを決めるのは窓口で、条件は次のいずれか:
CODEX_ROUND_DENIED）の後に、窓口が Opus へ上げると決めたとき(c)(d) は派遣時に モデル: opus 行で伝え、(a)(b) は spawn 後に窓口が同じペインで昇格させる（手順は .claude/skills/org-delegate/SKILL.md のモデル選定節）。ディスパッチャーは モデル: opus 行が無ければ sonnet で spawn し、inbox task JSON の "model" を必ず明示する（runtime helper は欠落時に opus を既定にするため。.dispatcher/references/spawn-flow.md 3-2）。
モデル選択は承認フローの安全性とは独立である。auto モードの分類器はワーカーのセッションモデルとは別の専用モデルで動作し、承認判定はワーカーが opus か sonnet かに依存しない（公式: https://www.anthropic.com/engineering/claude-code-auto-mode）。ディスパッチャーだけは bypassPermissions 固定なので分類器を経由せず、コスト最適化として sonnet 運用（この判断はワーカーには自動適用しない）。
通常:
cwd="{workers_dir}/{task_id}"（絶対パス推奨）permission_mode=automodel="sonnet"（既定。DELEGATE 本文に モデル: opus 行があるときだけ "opus"）还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
ディスパッチャーのコンテキストを圧迫したまま session を続けるのを避けるため、 monitoring 状態（active workers / 直近 polling cursor / pending escalations）を handover ファイルに書き出し、secretary の指示で /clear → /dispatcher-resume の 流れで新しいディスパッチャー session を開始する準備をする。 Secretary から DISPATCHER_HANDOVER peer message を受領したとき、または ディスパッチャー自身が context が長くなったと判断したときに使う。 context-handover watcher が `/dispatcher-handover auto op=<OP>` を打鍵したときも使う。
中文简介正在准备中。当前显示原文说明。
/dispatcher-handover で書き出した handover ファイルを読み込み、 ディスパッチャーを新しい session で復帰させる。/clear 直後の最初のターンで使う。 state.db の dispatcher_pane_id / dispatcher_peer_id を atomic に更新し、 worker monitoring の /loop 3m を再開する。 secretary が /clear の後にディスパッチャーペインへ /dispatcher-resume を打鍵したときに使う。 context-handover watcher が `/dispatcher-resume auto op=<OP>` を打鍵したときも使う。 /org-start ではない（ワーカー・窓口は生きている前提。キュレーターは常駐しない）。
中文简介正在准备中。当前显示原文说明。
プロジェクトのゴール台帳（registry/goals/<owner>/<repo>.md）を人間と対話して新規作成・改訂する。 README と open Issue からゴール候補を推定して提示し、「何を目指すか」「何が起きていたら未達か」を 短く質問して条項を固め、書式検証（tools/work_discovery_goals.py validate）を通してから保存する。 「ゴール台帳を書きたい」「ゴールを設定して」「ゴール未設定と出た」「台帳エラーを直して」 「このプロジェクトの目標を決めたい」等や、/work-discovery の「ゴール未設定」「ゴール台帳エラー」案内を 受けて窓口が起動する。候補の提示そのものは /work-discovery の役目で本スキルではない。
中文简介正在准备中。当前显示原文说明。
組織の生きているペイン（secretary / dispatcher / worker）へ tmux で**直接入る** ための **コマンドを出力するだけ** の read-only スキル。`mcp__org-broker__list_panes`（論理ペイン） と `/usr/bin/tmux -L claude-org-broker list-panes -a`（pane_id ↔ session マッピング）を pane_id（%N）で突き合わせ、各ペインに role + name(task_id) ラベル付きの attach コマンドを 生成する（既定は読取書込 = `-r` 無し / 読取専用 `-r` はオプション / デタッチは `Ctrl-b d`）。 外側が tmux のときに今の tmux を分割してワーカー（と dispatcher）を並べる `split-window` コマンドも出す。 特定のペインの画面を直接見たい・入りたい・並べて見たい、attach コマンドを知りたいという依頼で発動。 自分で attach / split はせず・ペインも一切変更しない（コマンド文字列とペイン一覧表を表示するのみ）。 作業委譲（org-delegate）・ダッシュボードで状況一覧（org-dashboard）・watcher 停止（org-attention-stop） には発動しない。
中文简介正在准备中。当前显示原文说明。
attention notification watcher（承認待ち / 判断待ち / CI 失敗等を OS 通知 + 音で能動通知）を dispatcher ペインの右側に split で常駐起動する。`.state/attention.json` が未配置なら ja 既定テンプレートを `tools/templates/attention.example.json` から自動コピーする。 起動後のペイン id は `.state/attention_pane.json` に記録し、`/org-attention-stop` から参照する。 「attention 起動」「通知監視を始めて」「watcher を立てて」等で発動。 `/org-start` からの auto-start はしない（明示起動推奨ポリシー）。
中文简介正在准备中。当前显示原文说明。
`/org-attention-start` で起動した attention watcher ペインを停止する。 `.state/attention_pane.json` に記録された pane_id を `list_panes` の name/role で identity 確認し、いまも attention watcher を指している場合だけ `close_pane`（pane 破棄）で 破棄する（pane_id が別ペインへ再割当て済みなら close せず stale sidecar として削除）。 「attention 止めて」「通知監視を停止」「watcher 落として」等で発動。
中文简介正在准备中。当前显示原文说明。