組織の全ロール（窓口・ディスパッチャー・キュレーター・ワーカー）に必要な Claude Code の許可設定・環境変数を一括で配置・更新するスキル。「設定して」「許可設定を更新して」「セットアップして」 「permissions設定」「org-setup」等で発動する。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
組織の各ロールが必要とする permissions allow と環境変数を、 正しいスコープの settings ファイルに配置する。
輸送層 両系（
ORG_TRANSPORT: 既定renga/ opt-inbroker）: 本スキルが配る messaging MCP の allow は 既定renga（ORG_TRANSPORT無設定）でmcp__renga-peers__*tier。references/permissions.mdは renga アンカー（byte 比較対象）として不変であり、broker への置換は prose ではなく生成/検証ツール側で行う:tools/org_setup_prune.py（per-role allow /--user-common-allowlist）とtools/check_role_configs.pyがORG_TRANSPORT=brokerのときmcp__renga-peers__*ブロックを broker messaging tier（mcp__org-broker__*）に射影する（runtime のtransport_allowlistdescriptor 駆動、Epic #6 E）。既定 renga は恒等（生成物 byte 等価・file no-op）なので本スキルの手順・報告文はそのまま使えばよい。設計 SoT は transport-labdocs/design/ja-migration-plan.md§5.3、契約面はdocs/contracts/backend-interface-contract.mdSurface 8（ratified 2026-06-14）。
Claude Code は起動ディレクトリの .claude/ 配下から設定を読み込む。
サブディレクトリで起動した場合、親ディレクトリの設定は読み込まれない。
そのため、ロールごとに独立した設定ファイルが必要になる。
| スコープ | ファイルパス | 対象 |
|---|---|---|
| ユーザー共通 | ~/.claude/settings.json | 全プロジェクト・全ロール |
| 窓口 | <repo>/.claude/settings.local.json | リポジトリルートで起動した窓口 |
| ディスパッチャー | <repo>/.dispatcher/.claude/settings.local.json | .dispatcher/ で起動したディスパッチャー |
| キュレーター | <repo>/.curator/.claude/settings.local.json | .curator/ で起動したキュレーター |
| ワーカー | ワーカーディレクトリの .claude/settings.local.json | org-delegate が動的に作成 |
references/permissions.md に全ロールのJSON定義がある。以下の手順でこれを参照する。
以下の4ファイルを読み取る（存在しない場合は空オブジェクト扱い）:
~/.claude/settings.json<repo>/.claude/settings.local.json<repo>/.dispatcher/.claude/settings.local.json<repo>/.curator/.claude/settings.local.json各ファイルについて、上記「各ロールの必要設定」と比較し、不足しているエントリを特定する。
不足分を追加する。既存の設定は絶対に削除しない。
permissions.allow は配列なので、既存エントリを保持しつつ新規エントリを追加する。
env はオブジェクトなので、既存キーを保持しつつ新規キーを追加する。
sandbox.network.allowedDomains（窓口・ディスパッチャー。/work-discovery 判定段の api.anthropic.com）も配列として既存を保持して追加する。sandbox の他のキー（enabled / filesystem）はテンプレートに無いので足さない（理由は .claude/skills/org-setup/references/permissions.md 窓口節の sandbox.network.allowedDomains の注記）。
許可設定と同じく、fresh clone 直後に無い operator-local ファイルをここで揃える。 いずれも既存があれば上書きしない（operator の実データが入っているため）。
registry/projects.md（プロジェクトレジストリ、Issue #811）— コミットされているのは
テンプレート registry/projects.example.md の方で、実体は git 管理外:
python3 tools/ensure_projects_registry.py # Mac/Linux
py -3 tools/ensure_projects_registry.py # Windows native
created: なら新規生成、ok: なら既存のままheader drift: はテンプレートに増えた列が手元ファイルに無い warning（exit 0、非 fatal）。
表示された列名をユーザーに伝え、手元ファイルの表ヘッダーへの追記を案内する/org-start の Step 0 でも同じコマンドが走るので、
どちらを先に実行しても実体は揃う。既存 checkout の移行手順は
docs/operations/registry-projects-migration.md変更があった場合:
設定を更新しました:
- ~/.claude/settings.json: renga, renga-peers の許可を追加
- .dispatcher/.claude/settings.local.json: claude 起動コマンドの許可を追加
- (変更なし: .curator/.claude/settings.local.json)
変更がなかった場合:
全ての設定は最新です。変更はありません。
--prune モード）通常の Step 1〜3 は additive-only（不足分を追加するだけで既存は削除しない）。
過去に蓄積した広すぎる allow や旧エントリは残り続けるため、
permissions.md を SOT として settings.local.json を完全に書き換える prune モードを用意している。
実行は tools/org_setup_prune.py を使う:
# 差分プレビュー（書き換え無し）
python tools/org_setup_prune.py --role secretary --dry-run
python tools/org_setup_prune.py --all --dry-run
# 実行（タイムスタンプ付き .bak を自動生成 → 書き換え）
python tools/org_setup_prune.py --role secretary
python tools/org_setup_prune.py --all
対象ロール: secretary / dispatcher / curator。
（user_common は ~/.claude/settings.json で他プラグインと同居するため対象外。
ワーカーは org-delegate が動的生成するため対象外。）
settings.local.override.jsonprune は permissions.md の role テンプレートで丸ごと書き換えるため、
個人で追加した allow / env / hook をそのままにすると消えてしまう。
これを避けるため、各 settings ファイルと同じディレクトリに
settings.local.override.json を置くと、prune 時に deep-merge される。
例: 窓口で Bash(my-private-tool:*) を恒久的に許可したい場合は
.claude/settings.local.override.json に以下を書く（このファイルは
prune ツールが読むだけで、書き換えはしない）:
{
"permissions": {
"allow": ["Bash(my-private-tool:*)"]
}
}
マージ規則:
permissions.allow / permissions.deny: base 順を保ったまま和集合env: キー単位 merge（override 側が勝つ）hooks.PreToolUse[] 等: 等値判定で重複排除した上で append.gitignore 対象（個人設定のため。.gitignore:23-25 で .claude/settings.local.override.json と
.claude/settings.local.json.bak.* を ignore 済み。.curator/.claude/ と .dispatcher/.claude/
配下はディレクトリごと ignore のため自動的に対象）。チームで共有したい設定は
permissions.md 側に追加し、schema (tools/org_extension_schema.json) も同時に更新する。
tools/check_role_configs.py は同じ override ファイルを読み、その allow を
closed-world 検証から除外する（_load_override_allow）。よって override に追加した
個人 allow は CI / --include-local で unknown allow entry にならない。
ただし forbidden_allow_exact（Bash(git *) 等の wide allow）と
disallow_allow_regex（旧 mcp__claude-peers__*、現 renga-peers 等）は override 側にあっても
従来通り ERROR となる。安全契約は override で迂回できない。
{claude_org_path} の解決（窓口 / dispatcher / worker）窓口・dispatcher・worker のテンプレートには {claude_org_path} プレースホルダがある
（hook command を絶対パスで固定するため。相対パスだと cwd が org ルート以外のロールで
hook が解決されず、ガードが無言で無効化する）。prune ツールは以下の優先順で解決する:
--claude-org-path <abs> 引数settings.local.json の env.CLAUDE_ORG_PATHbash "<abs>/.hooks/..." の <abs>--root、既定はリポジトリルート）。<root>/.hooks/ に schema の
required_hook_scripts が全て実在する場合のみ採用する窓口テンプレートには env.CLAUDE_ORG_PATH が無いため、初回実行では 2 も 3 も取れず 4 で解決される。
4 の条件を満たさない（org checkout ではない）場合は unresolved placeholders で中断するので、
誤った --root の内容が黙って書き込まれることはない。.hooks/ ディレクトリの実在だけを条件に
すると、たまたま同名ディレクトリを持つ無関係なプロジェクトを org root として受理し、
存在しないスクリプトを指す hook（＝生成時点で死んでいるガード）を書いてしまうため。
いずれも取れない場合（fresh install など）は --claude-org-path を明示する:
python tools/org_setup_prune.py --role dispatcher --claude-org-path "C:/Users/me/work/claude-org"
書き換え前に settings.local.json.bak.YYYYMMDD-HHMMSS を同ディレクトリに作成する。
失敗時はこの .bak を mv で戻せば原状復帰できる。
不要であれば --no-backup で抑止できる。
--user-common-sandbox、Issue #429 Task B / C）⚠️ main pull 後の 1 回必須: 本リポジトリを clone / pull した後に
python tools/org_setup_prune.py --user-common-sandboxを 1 回実行する。Issue #429 Task C で共有.claude/settings.jsonから個人 path（~/.config/gh/hosts.ymlおよびRead(~/.ssh/*)/Read(~/.aws/*)）を除去したため、未実行だと 個人環境の sandbox denyRead 補強が一時的に弱くなる。
--user-common-sandbox は ~/.claude/settings.json の sandbox.filesystem.denyRead に対してのみ idempotent な union-merge を行う専用モード（他キーは無触）:
# diff プレビュー
python tools/org_setup_prune.py --user-common-sandbox --dry-run
# 実行（既存があれば .bak 自動生成、上書き候補がない場合は no-op）
python tools/org_setup_prune.py --user-common-sandbox
対象ディレクトリ（~/.ssh / ~/.aws / ~/.config/gh / ~/.kube / ~/.gnupg / ~/.docker / ~/.config/aws-vault）のうち、実在し、かつ realpath が HOME を escape しない symlink でない ものだけが追加される。WSL2 + DriveFS の ~/.aws → /mnt/c/... のようなケースは自動 skip（bwrap bootstrap 失敗の予防）。
仕様詳細は .claude/skills/org-setup/references/permissions.md の「ユーザー共通の sandbox denyRead 補強」節を参照。
settings.local.json は .gitignore に入っている前提（個人設定のため）~/.claude/settings.json は既存の設定（plugins 等）を壊さないよう注意するtools/org_setup_prune.py の docstring と tools/test_org_setup_prune.py のテストが正典まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
ディスパッチャーのコンテキストを圧迫したまま session を続けるのを避けるため、 monitoring 状態（active workers / 直近 polling cursor / pending escalations）を handover ファイルに書き出し、secretary の指示で /clear → /dispatcher-resume の 流れで新しいディスパッチャー session を開始する準備をする。 Secretary から DISPATCHER_HANDOVER peer message を受領したとき、または ディスパッチャー自身が context が長くなったと判断したときに使う。
/dispatcher-handover で書き出した handover ファイルを読み込み、 ディスパッチャーを新しい session で復帰させる。/clear 直後の最初のターンで使う。 state.db の dispatcher_pane_id / dispatcher_peer_id を atomic に更新し、 worker monitoring の /loop 3m を再開する。 「ディスパッチャー復帰」「resume」「引き継ぎから再開」と secretary から指示された ときに使う。/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`）。 「ワーカーのペインを見たい」「ワーカーのペインに入りたい」「dispatcher の様子を直接見たい」 「ペインに入りたい」「あのペインを直接覗きたい」「attach コマンド教えて」 「tmux でつなぎたい」「worker の画面に入る」等で発動。 自分で attach はせず・ペインも一切変更しない（コマンド文字列とペイン一覧表を表示するのみ）。 作業委譲（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 落として」等で発動。