@shinaps/skills 0.37.0 → 0.38.0

package/plugins/shinaps-codex/references/managed/execute.md

@@ -1,118 +1,82 @@
 # Managed Agents への依頼と観測
 
-作業先の設定を読み、Claude Managed Agents の lead `shinaps-dev-managed-cc` へ dev を依頼し、進み具合の観測・質問の取り次ぎ・成果物と draft PR の確認を行う手順。体制は合意する入力として渡す。計画・実装・レビューの工程と追加の担当は lead が [skill `dev-managed-cc`](../../managed-agents/skills/dev-managed-cc/SKILL.md) に従って決めるので、ここでは指示しない。
+Claude Managed Agents の lead `shinaps-dev-managed-cc` へ dev を依頼し、進み具合の観測・質問の取り次ぎ・出力の回収と draft PR の確認を行う手順。体制は合意する入力として渡す。計画・実装・レビューの工程と追加の担当は lead が [skill `dev-managed-cc`](../../managed-agents/skills/dev-managed-cc/SKILL.md) に従って決めるので、ここでは指示しない。アカウント・キー・状態の置き場所は[設定とアカウント](configuration.md)に従う。
 
 ## 呼び出し時に合意する入力
 
-設定からは読まず、依頼のたびに利用者と合意する。
+設定・記録・過去の作業からは推定せず、依頼のたびに利用者と合意して引数で明示する。
 
-- 必須: base ブランチとその SHA、head ブランチ、範囲と受入条件、体制（LITE・BASIC・ULTRA。[体制の選択](../dev/staffing.md)に従い推奨を添えて確認する）、許可（commit・head への push・draft PR の作成のうち明示されたもの）、予算（USD のセント単位）
-- 任意: 必須検証のコマンド、コミットの author、利用者 CLAUDE.md の添付
+- 必須: アカウント、base ブランチとその SHA、head ブランチ、範囲と受入条件（ファイル）、体制（LITE・BASIC・ULTRA。[体制の選択](../dev/staffing.md)に従い推奨を添えて確認する）、許可（`none`、または `commit`・`push`・`draft_pr` のうち明示されたもの）、予算（USD のセント単位）
+- 任意: 必須検証のコマンド、コミットの author、セッションの題名、利用者 CLAUDE.md の添付
 
-設定から読むのは `definitions`（lock の場所）・`repository`・`vault_id` だけで、lead と環境の ID は lock から読む（[設定](configuration.md)）。許可と予算は合意した内容だけで、会話の途中で増やさない。
+設定（`.shinaps/managed.json`）から読むのは `repository` とそのアカウントの `vault_id` だけで、lead と環境の ID はアカウントの lock から読む。許可と予算は合意した内容だけで、会話の途中で増やさない。
 
-## 1. 前提を確かめる
+## 1. 設定を用意する
 
-- `.shinaps/managed.json` を CLI で検証する。
-- `<definitions>/claude-lock.json` が無ければ止める。setup へ自動で進まない。
-- `ant auth status` を確かめ、lock の `origin.workspace_id` と一致することを確かめる。複数のワークスペースで使える資格情報では各コマンドに `--workspace-id` を付ける。
-- `vault_id` が `null` で、許可に draft PR の作成が含まれる場合は、セッションを作る前に止めて利用者に確認する。draft PR の作成を含まない依頼だけは続けられる。
+`.shinaps/managed.json` が無い、または version 1 なら、`repository`（URL とマウント先）と、使うアカウントの `vault_id` を利用者に一問ずつ確認して version 2 で作る（[作業先の設定](configuration.md#作業先の設定shinapsmanagedjson)。version 1 は[移行](configuration.md#version-1-からの移行)のとおり lock も移す）。書き込む前に Git 対象外であることを確かめる。作った設定は `shinaps-skills validate-managed-config` で検証する。
 
-## 2. セッションを作る
+## 2. 依頼する
 
 合意済みの依頼があるときだけ作る。この手順を読んだことを理由に作らない。
 
-GitHub の token は対象リポジトリだけに限った fine-grained token にし、Contents と Pull requests の write だけを許可する。merge できるかは GitHub のブランチ保護で決まるので、base を保護しておく。token は `read -rs` で画面に出さずに受け取り、サンドボックス・作業記録・チャットに書かない。
-
-次はひな形で、`<...>` を設定と合意した入力で埋める。`vault_id` が `null` なら `--vault-id` の行を除く。
+GitHub の token は対象リポジトリだけに限った fine-grained token にし、Contents と Pull requests の write だけを許可する。merge できるかは GitHub のブランチ保護で決まるので、base を保護しておく。token は利用者が環境変数 `SHINAPS_MANAGED_GITHUB_TOKEN` に設定する（例 `read -rs SHINAPS_MANAGED_GITHUB_TOKEN && export SHINAPS_MANAGED_GITHUB_TOKEN`）。CLI はリクエスト本文（stdin）にだけ入れ、保存・表示しない。
 
 ```sh
-LOCK=<definitions>/claude-lock.json
-LEAD_ID=$(jq -r '.resources["./agents/shinaps-dev-managed-cc.md"].id' "$LOCK")
-ENV_ID=$(jq -r '.resources["./environments/shinaps-dev.yaml"].id' "$LOCK")
-read -rs GITHUB_TOKEN   # 画面に表示せずに入力する
-ant beta:sessions create --beta managed-agents-2026-04-01 \
-  --agent "$LEAD_ID" \
-  --environment-id "$ENV_ID" \
-  --vault-id <vault_id> \
-  --title "<作業名>" <<YAML
-budget: {type: limit, max_list_cost: {amount: "<セント単位の金額。4000 は 40 USD>", currency: USD}}
-resources:
-  - type: github_repository
-    url: <repository.url>
-    mount_path: <repository.mount_path>
-    authorization_token: "$GITHUB_TOKEN"
-    checkout: {type: commit, sha: <base の SHA>}
-initial_events:
-  - type: user.message
-    content:
-      - type: text
-        text: |
-          リポジトリ: <repository.url>（マウント先 <repository.mount_path>）
-          base: <ブランチ> @ <SHA>
-          head: <ブランチ名>
-          範囲と受入条件: <内容>
-          体制: <LITE|BASIC|ULTRA>
-          許可: <commit・headへのpush・draft PRの作成のうち許可するもの>
-          予算: <金額>
-          必須検証（任意）: <コマンド。省略時はリポジトリの規約に従う>
-          author（任意）: <name> <email>
-YAML
-unset GITHUB_TOKEN
+shinaps-skills managed run .shinaps/managed.json --account <name> \
+  --base <branch> --base-sha <SHA> --head <branch> \
+  --staffing <LITE|BASIC|ULTRA> --allow <none|commit,push,draft_pr> \
+  --budget-cents <セント。4000 は 40 USD> --task-file <範囲と受入条件のファイル> \
+  [--verify "<コマンド>"] [--author "<name> <email>"] [--title "<作業名>"] [--claude-md <パス>]
 ```
 
-- `checkout` は base の SHA にする。比較元が必ずチェックアウトされ、head ブランチが無ければ lead がそこから作る。
-- 利用者 CLAUDE.md を渡す場合は `ant files upload --file <パス>` で上げ、`resources` に `{type: file, file_id: <ID>, mount_path: /CLAUDE.md}` を加える（`/mnt/session/uploads/CLAUDE.md` に置かれる）。
+- 設定と引数を検証し、セッションを作る前に次で止まる: `draft_pr` を許可したのにそのアカウントの `vault_id` が `null`、`push` か `draft_pr` を許可したのに token が無い。どちらもセッションを作ってから lead が気づくと予算を消費した後になるため。
+- セッションは lock の lead と環境、そのアカウントの vault、`max_list_cost` の予算、base の SHA をチェックアウトしたリポジトリで作る。head ブランチが無ければ lead が base から作る。初回メッセージにはリポジトリ・base と SHA・head・範囲と受入条件・体制・許可・予算・任意の入力を全て書く。
+- `--claude-md` は `ant beta:files upload` で上げ、`/mnt/session/uploads/CLAUDE.md` に置く。
+- 同じ入力（設定のリポジトリと vault、引数、範囲と CLAUDE.md の本文）の再実行は新しいセッションを作らず、記録したセッションの ID を返す。完了後に同じ範囲で新しく依頼するときは、題名など入力を変える。作成の途中で止まった記録が残っていれば作らずに止まる。表示された metadata `shinaps_request` のセッションがコンソールに無いことを確かめてから、表示された記録を消して再実行する。
 
 ## 3. 観測する
 
-- `ant beta:sessions:events stream --session-id <ID> --beta managed-agents-2026-04-01` で進行を追う。途中から見る場合は `ant beta:sessions:events list --session-id <ID> --beta managed-agents-2026-04-01` を使う。
-- セッションの状態は `ant beta:sessions retrieve --session-id <ID> --beta managed-agents-2026-04-01` で確かめる。
-- lead のターンの最後の `agent.message` の1行目が `状態: 完了`・`状態: 質問`・`状態: 未完了` のどれかを読む。
+```sh
+shinaps-skills managed status --account <name> --session <ID>
+```
+
+セッションの `status`・`usage`（`list_cost` を含む）・`budget` と、lead の最後の `agent.message` の本文と1行目の状態（`完了`・`質問`・`未完了`）を JSON で表示する。扱うのは、そのアカウントで `managed run` が作った記録のあるセッションだけである。
 
 ## 4. 質問を取り次ぐ
 
-- `状態: 質問` なら、質問を一問ずつ利用者へ伝える。
-- 回答は `ant beta:sessions:events send` に、API の本文と同じ形の JSON を標準入力で渡して返す。`events` 配列に `user.message` を1件入れ、本文は `text` ブロックにする（[Send Events](https://platform.claude.com/docs/en/api/beta/sessions/events/send) の本文と同じ構造）。
+- 状態が `質問` なら、質問を一問ずつ利用者へ伝える。
+- 回答はファイルに書き、`user.message` として送る。
 
   ```sh
-  ant beta:sessions:events send --session-id <ID> --beta managed-agents-2026-04-01 <<'JSON'
-  {
-    "events": [
-      {
-        "type": "user.message",
-        "content": [
-          { "type": "text", "text": "<質問への回答>" }
-        ]
-      }
-    ]
-  }
-  JSON
+  shinaps-skills managed reply --account <name> --session <ID> --message-file <回答のファイル>
   ```
 
-  同じ内容は `--event.type user.message --event.content '<content の JSON 配列>'` のフラグでも渡せる。回答の送信は、依頼が進行中のセッションに対してだけ行う。
-- 回答で新しい許可・予算を加えない。必要なら新しい依頼として合意し直す。
-- `user.tool_confirmation` は利用者の明示の指示なしに送らない。
+- 回答の送信は、依頼が進行中のセッションに対してだけ行う。回答で新しい許可・予算を加えない。必要なら新しい依頼として合意し直す。
+- `user.tool_confirmation` は送らない。
 
-## 5. 成果物を確かめる
+## 5. 出力を回収して確かめる
 
 確かめる対象は、lead の最終報告の `出力:`・`コミット:`・`PR:` の行にある成果物だけにする。許可に push や draft PR の作成を含めない依頼では、remote の head ブランチや PR は存在しないので、出力ファイルだけを確かめる。
 
-- 出力ファイル（`changes.patch` と作業記録の tar）は、セッションに紐づく Files から取得する。`ant beta:files list --scope-id <セッションの ID> --beta managed-agents-2026-04-01` で一覧を取り、`ant beta:files download --file-id <ID> --beta managed-agents-2026-04-01 --output <保存先>` で保存する。保存したサイズを一覧の metadata と比べる。複数のワークスペースで使える資格情報では `--workspace-id` を付ける。
-- `changes.patch` は作業先で `git apply --check` するか、合意した base の SHA に対して適用して、範囲と受入条件に対する差分を確かめる。
+```sh
+shinaps-skills managed collect --account <name> --session <ID>
+```
+
+- セッションに紐づく Files（`changes.patch` と作業記録の tar）を、そのアカウントの `sessions/<ID>/outputs/` へ保存し、保存したパスを表示する。同じ名前のファイルは最新のものだけを保存する（lead は毎ターン `changes.patch` を比較元からの全体の差分で置き換える）。名前がファイル名だけでないものは保存せずに止まる。保存したサイズは一覧の値と比べる。
+- CLI は差分を適用しない。`changes.patch` は合意した base の SHA のチェックアウトで `git apply --check` してから、範囲と受入条件に対する差分を確かめる。適用するかは利用者と決める。
 - `コミット:` と push 先がある場合は `git fetch origin <head>` で head ブランチを取得し、base の SHA からのコミットと差分を確かめる。
 - `PR:` がある場合は `gh pr view <PR の URL> --json isDraft,baseRefName,headRefName` または GitHub MCP の読み取りで、draft であること・base と head が合意どおりであることを確かめる。
-- `ant beta:sessions connect <セッションの ID> --web --no-browser` でも内容を閲覧できるが、この画面からはメッセージ送信やツールの承認もできるので、観測目的では操作しない。
 
 ## 6. 終了する
 
-状態行、取得した出力ファイル、コミット、push 先、PR の URL、未検証の事項を報告する。merge・deploy・release・Issue の更新・セッションのアーカイブは行わない。QA は呼び出し元が別に行う。完了後に修正する場合は、新しい依頼として、体制を含めて合意し直す。
+状態行、回収した出力ファイル、コミット、push 先、PR の URL、未検証の事項を報告する。merge・deploy・release・Issue の更新・セッションのアーカイブは行わない。QA は呼び出し元が別に行う。完了後に修正する場合は、新しい依頼として、体制を含めて合意し直す。
 
 ## 未検証の境界
 
+- `managed setup`・`run`・`status`・`reply`・`collect` のコマンド・フラグ・stdin の本文・出力の形は ant 2.4.0 の公式ソースで照合し、偽の `ant` を使うテストで確かめた。実際の `ant` とクラウドではまだ実行していない。
+- API の側で決まり、ant のソースでは確かめられないこと: 予算 `max_list_cost.amount` がセント単位か、`mount_path: /CLAUDE.md` が `/mnt/session/uploads/CLAUDE.md` に置かれるか、Files の upload・一覧・取得に `files-api-2025-04-14` と `managed-agents-2026-04-01` の両方の beta を付ければよいか（ant の `--beta` は既定の beta を置き換えるので、全ての呼び出しで明示している）、Files の応答の `filename`・`size_bytes`・`created_at`、events の一覧に役割のスレッドの `agent.message` が混ざるか。lock が無い状態での skill の重複は、同じ setup で作る lead の同名確認で止まる。
 - マウントしたリポジトリの remote へ `git push` できるか（`authorization_token` が push に使われるか）。最初のセッションで最優先に確かめ、できなければ GitHub MCP の push 用ツール（`create_branch`・`push_files`）を有効にするかを利用者と相談する。
 - commit をチェックアウトしてマウントした作業先から、origin の head ブランチを取得できるか（clone の深さと fetch の資格情報）。
 - GitHub MCP で draft PR を作れるか。`draft: true` は lead への指示でしか担保されない。
 - vault に資格情報を登録できたことは、上の3点の確認にならない。
-- `events send` による回答の送信は、本文の構造を API 仕様で確かめただけで、実際のセッションではまだ送っていない。出力ファイルの一覧と取得は既存のセッションで確かめた。
 - 完了したスレッドが同時実行の枠（25本）を空けるか。ULTRAでは、ラウンドごとに新しく起動する担当を含めて、同時に保つスレッドが多い。

package/plugins/shinaps-codex/references/managed/setup.md

@@ -1,74 +1,62 @@
 # Managed 構成の導入と更新
 
-共通の dev 構成（lead `shinaps-dev-managed-cc`、dev の3役割、skill `dev-managed-cc`、環境 `shinaps-dev`）を利用者の組織へ導入・更新する手順。既存の lock を使い、同じリソースを重複して作らない。セッションの作成・予定実行は行わない。dev の工程は [skill `dev-managed-cc`](../../managed-agents/skills/dev-managed-cc/SKILL.md) が持つので、ここでは扱わない。
+共通の dev 構成（lead `shinaps-dev-managed-cc`、dev の3役割、skill `dev-managed-cc`、環境 `shinaps-dev`）を、利用者の1つ以上のアカウントへ一コマンドで導入・更新する手順。既存の lock を使い、同じリソースを重複して作らない。セッションの作成・予定実行は行わない。dev の工程は [skill `dev-managed-cc`](../../managed-agents/skills/dev-managed-cc/SKILL.md) が持つので、ここでは扱わない。アカウント・キー・状態の置き場所は[設定とアカウント](configuration.md)に従う。
 
 ## 前提
 
-- `ant` 1.30 以上（`ant --version` で確認する。確認済みの版は 1.42.0）
-- 利用者本人が `ant auth login` を済ませている。ログインは代行しない。`ant auth status` で組織とワークスペースを確認する。複数のワークスペースで使える資格情報では各コマンドに `--workspace-id` が必要になる。lock があれば `origin.workspace_id` と一致することを確かめる
-- 作業先の `.shinaps/managed.json`（[設定](configuration.md)）
+- PATH 上の `ant` 2.4.0 以上（`ant --version`）と、利用中の skill と同じ版の `shinaps-skills`
+- 導入する各アカウントの APIキー（[APIキー](configuration.md#apiキー)）。利用者が環境変数に設定する。キーをチャット・作業記録に貼らない
 
-## 1. 設定を読む
-
-`.shinaps/managed.json` を読み、CLI で検証する。無ければ、決まっていない項目を利用者に一問ずつ確認して作る。書き込む前に Git 対象外であることを確かめる（[設定](configuration.md#配置)）。`.shinaps/.gitignore` が無ければ[作業記録の共通手順](../work-records.md)のとおり `*` だけの内容で作る。既存の ignore が設定や `<definitions>` を除外していない場合は、既存の規則と共有例外を保ったまま、末尾に `/managed.json` と `<definitions>` の相対パス（既定は `/managed/`）の2行だけを加える。この追記は導入の依頼に含まれる操作として行い、別の承認を求めない。
-
-## 2. 共通定義を配置する
-
-このスキルを含む plugin の `managed-agents/`（SKILL.md から `../../managed-agents/`）にある `agents/`・`environments/`・`skills/` で、`<definitions>` の同名の3ディレクトリを丸ごと置き換える。この3ディレクトリはテンプレートの所有で、手で編集した内容は上書きされる。`<definitions>` には `claude-lock.json` 以外のファイルを置かない。適用はディレクトリ内の定義をすべて送信するため。
-
-置き換える前に、既存の3ディレクトリとテンプレートを `diff -r` で比べる。テンプレートに無い変更（利用者が手で直した定義や追加したファイル）があれば、その一覧を示して残すか捨てるかを確かめてから置き換える。黙って失わせない。
-
-以前の置き場所に lock があれば、`<definitions>/claude-lock.json` へ移してから進む。lock の扱いは[設定](configuration.md#lock-の扱い)に従う。
-
-## 3. 安全上の注意を示す
+## 1. 安全上の注意を示す
 
 適用の合意を求める前に、次を利用者へ示す。
 
 - 環境のネットワークは制限しない（`unrestricted`）。bash と GitHub MCP の3ツール（`get_me`・`create_pull_request`・`pull_request_read`）は承認なし（`always_allow`）で動く。無人のセッションが承認待ちで止まらないようにするため。
 - サンドボックスのコードは外部へデータを送れる。取得した内容に書かれた指示に従ってしまう危険（プロンプトインジェクション）がある。
+- lead と3役割は Opus 5.5（`claude-opus-5-5` / medium / standard）で動く。費用はセッションごとに依頼時の予算で上限を付ける。
 
-## 4. 計画を確認する
+## 2. 計画を確認する
 
 ```sh
-(cd <definitions> && ant apply --dry-run .)
+shinaps-skills managed setup --account <name> [--account <name> ...]
 ```
 
-サブシェルで `<definitions>` に移動してから実行する。lock は実行した場所から上へ探され、キーは lock のディレクトリからの相対パスになるため。
+アカウントごとに順に、次を行う。どのアカウントのキーが欠けていても、何も変えずに止まる。
+
+1. アカウントの `definitions/` の3ディレクトリを同梱の共通定義に揃える。書き換え・削除するのは setup が最後に書いた内容か今回書く内容と一致するファイルだけで、利用者の編集・追加や記録の無いファイルがあれば何も変えずに止まる。消えたファイルは書き直す（[アカウントの状態](configuration.md#アカウントの状態)）。lock は書き換えない。
+2. lock が無ければ、`ant beta:agents list`・`ant beta:environments list` で同名の未アーカイブの lead・役割・環境を探し、あれば止める。以前の lock を戻してから再実行する（[lock の扱い](configuration.md#lock-の扱い)、[version 1 からの移行](configuration.md#version-1-からの移行)）。
+3. `definitions/` で `ant apply --dry-run --lock-file claude-lock.json .` を実行して計画を表示する。`ant` は `--lock-file` が無いと lock を上のディレクトリへ探すので、祖先の lock で対応づけないよう `definitions/` 直下の lock を常に指定する。`--prune`・`--force` は使わない。
+4. 計画に `This plan cannot be applied` があれば、そのアカウントを失敗にする（dry-run はこの場合も終了コード0で返る）。
+
+失敗したアカウントがあれば一覧を示して終了コード1で終わる。他のアカウントの処理は続ける。
 
-- 出力の `Preview` 行が `./claude-lock.json`（`<definitions>` 直下）であることを確かめる。違えば止める。別の場所の lock を `--lock-file` で指定しない。キーの基準がずれて重複作成につながる。
-- lock があれば、計画は定義を変えたリソースの update、テンプレートに新しく加わったリソースの create、それ以外の unchanged になる。lock にあってソースの無い項目は警告として残る。`--prune` は付けない。
-- 次の場合は適用せずに止めて報告する: `This plan cannot be applied` が出る、意図しない環境の更新がある。
-- create があれば、`ant beta:agents list --beta managed-agents-2026-04-01` と `ant beta:environments list --beta managed-agents-2026-04-01` で、アーカイブされていない同じ名前の lead・役割・環境が既にあるかを確かめる。あれば止める。アーカイブの状態を判定できなければ止める。
-  - lock がある場合は、lock を変えずに状況を報告して利用者と相談する。
-  - lock が無い場合は、lock を戻す方法を利用者と相談する。同じマシンで同じ組織に導入済みなら、その `<definitions>` を指すよう設定を直してやり直す。別のマシンでは[lock の扱い](configuration.md#lock-の扱い)に従い、バックアップや以前の置き場所から lock を戻し、無ければ相談する。
+計画は、lock があれば定義を変えたリソースの update、テンプレートに新しく加わったリソースの create、それ以外の unchanged になる。lock にあってソースの無い項目は警告として残る。意図しない環境の更新があれば適用しない。
 
-## 5. 適用する
+## 3. 適用する
 
-利用者が dry-run の計画に合意してから実行する。
+利用者が計画に合意してから、同じアカウントで `--apply` を付けて実行する。
 
 ```sh
-(cd <definitions> && ant apply .)
+shinaps-skills managed setup --account <name> [--account <name> ...] --apply
 ```
 
-`ant apply` は計画を表示して承認を求める。確認した計画と同じ内容の適用を利用者が明示的に許可している場合は `--yes` を付けて、同じ範囲の承認を繰り返さない。計画が変わっていれば `--yes` を付けずに止める。`--prune`・`--force` は使わない。リソースを削除しない。
+計画を作り直し、上の止める条件を同じように確かめてから、変更のあるアカウントだけ `ant apply --yes --lock-file claude-lock.json .` を実行する。適用後にもう一度 dry-run し、`Everything is up to date.` でなければ失敗にする。リソースは削除しない。`--apply` は作り直した計画をそのまま適用し、途中で確認を挟まない。計画を確かめてから適用するまでの間に、CLI の版・同梱の定義・lock を変えない。適用時に表示された計画が合意した計画と違えば、利用者へ報告する。
 
-## 6. 結果を確かめる
+## 4. 結果を確かめる
 
-- もう一度 dry-run を実行し、`Everything is up to date.` を確かめる。
-- lock を適用前の複製と比べ、更新したリソースの `version`・`hash`・`remote_hash` 以外が変わっていないことを確かめる。変わっていれば報告する。
-- 読み取りで確かめる場合は `ant beta:agents retrieve --agent-id <ID> --beta managed-agents-2026-04-01` と `ant beta:environments retrieve --environment-id <ID>` を使う。セッションは作らない。
+- 各アカウントの結果（`applied`・`up-to-date`・`planned`・`failed`）を確かめる。
+- 読み取りで確かめる場合は、そのアカウントのキーを `ANTHROPIC_API_KEY` に入れて `ant beta:agents retrieve --agent-id <ID>`・`ant beta:environments retrieve --environment-id <ID>` を使う。セッションは作らない。
 
 ## GitHub MCP の vault を準備する
 
-lead の GitHub MCP（`https://api.githubcopilot.com/mcp`）は、セッション作成時に渡す vault の資格情報で認証する。vault はセッション作成時にしか渡せない。
+lead の GitHub MCP（`https://api.githubcopilot.com/mcp`）は、セッション作成時に渡す vault の資格情報で認証する。vault は組織ごとで、セッション作成時にしか渡せない。
 
-1. Claude Console で vault を作る。
+1. そのアカウントの組織の Claude Console で vault を作る。
 2. vault に MCP OAuth の資格情報を追加し、GitHub を選んで利用者本人がブラウザで承認する。資格情報の MCP サーバーの URL は lead 定義の `mcp_servers[].url` と同じ `https://api.githubcopilot.com/mcp` にする。URL で照合されるため、末尾のスラッシュの有無も揃える。
-3. `ant beta:vaults list --beta managed-agents-2026-04-01` と `ant beta:vaults:credentials list --vault-id <vault の ID> --beta managed-agents-2026-04-01` で vault と資格情報を確かめる。
-4. vault の ID を `.shinaps/managed.json` の `vault_id` に書く。
+3. vault の ID を `.shinaps/managed.json` の `accounts.<name>.vault_id` に書く。
 
 token をチャット・設定・作業記録に貼らない。資格情報の登録ができたことと、セッションで push・draft PR の作成が動くことは別に報告する。後者は[依頼の手順](execute.md#未検証の境界)の未検証の境界にあたる。
 
 ## 報告
 
-作成・更新・変更なしのリソース、lock の差分、示した安全上の注意、確かめられなかった事項を報告する。作業記録は `.shinaps/work/` に置く。
+アカウントごとの結果と計画の要点、示した安全上の注意、確かめられなかった事項を報告する。作業記録は `.shinaps/work/` に置く。

package/plugins/shinaps-codex/skills/managed-execute/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: managed-execute
-description: 作業先の Managed 設定を読み、Claude Managed Agents の lead へ dev を依頼し、観測・質問の取り次ぎ・成果物と draft PR の確認を行う。dev の工程自体は lead に任せる。依頼があるときに使う。
+description: Claude Managed Agents の lead へ、アカウントを選んで dev を依頼し、観測・質問の取り次ぎ・出力のローカル回収と draft PR の確認を行う。dev の工程自体は lead に任せる。依頼があるときに使う。
 ---
 
 ## 作業記録の保存先
@@ -9,10 +9,10 @@ description: 作業先の Managed 設定を読み、Claude Managed Agents の le
 
 # Managed Agents へ依頼する
 
-[設定](../../references/managed/configuration.md)と[依頼と観測の手順](../../references/managed/execute.md)を読んで進める。
+[設定とアカウント](../../references/managed/configuration.md)と[依頼と観測の手順](../../references/managed/execute.md)を読んで進める。操作は配布CLIの `managed run`・`status`・`reply`・`collect` で行う。
 
-- 呼び出しのたびに base ブランチと SHA・head ブランチ・範囲と受入条件・体制（LITE・BASIC・ULTRA）・許可・予算を利用者と合意する。設定・lock・過去の作業から推定しない。
-- 設定から読むのは `definitions`（lock の場所）・`repository`・`vault_id` だけで、lead と環境の ID は lock から読む。lock が無ければ止め、導入は managed-setup で行う。
+- 呼び出しのたびにアカウント・base ブランチと SHA・head ブランチ・範囲と受入条件・体制（LITE・BASIC・ULTRA）・許可・予算を利用者と合意し、引数で明示する。設定・lock・過去の作業から推定しない。
+- 設定（`.shinaps/managed.json`）が無いか旧版なら、手順の「設定を用意する」に従って一問ずつ確認して作る。設定から読むのは `repository` とアカウントの `vault_id` だけで、lead と環境の ID はアカウントの lock から読む。lock が無ければ止め、導入は managed-setup で行う。
 - 計画・実装・レビューの工程と追加の担当は lead に任せ、ここでは指示しない。
-- Linear の進行とは独立した入口である。merge・deploy・release・Issue の更新・セッションのアーカイブは行わない。
-- 秘密値を表示・記録しない。
+- 回収した差分は適用しない。確認と適用の判断は利用者と行う。push・merge・deploy・release・Issue の更新・セッションのアーカイブは行わない。Linear の進行とは独立した入口である。
+- キーと token は利用者が環境変数に設定する。受け取らない・表示しない・記録しない。

package/plugins/shinaps-codex/skills/managed-setup/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: managed-setup
-description: Claude Managed Agents の共通 dev 構成（lead・役割・skill・環境）を自分の組織へ導入・更新する。既存の lock を使い、同じリソースを重複して作らない。導入・更新の依頼があるときに使う。
+description: Claude Managed Agents の共通 dev 構成（lead・役割・skill・環境）を、利用者の1つ以上のアカウントへ一コマンドで導入・更新する。アカウントごとの lock を使い、同じリソースを重複して作らない。導入・更新の依頼があるときに使う。
 ---
 
 ## 作業記録の保存先
@@ -9,11 +9,10 @@ description: Claude Managed Agents の共通 dev 構成（lead・役割・skill
 
 # Managed 構成を導入・更新する
 
-[設定](../../references/managed/configuration.md)と[導入・更新の手順](../../references/managed/setup.md)を読んで進める。共通定義はこのスキルを含む plugin の `managed-agents/` にある。
+[設定とアカウント](../../references/managed/configuration.md)と[導入・更新の手順](../../references/managed/setup.md)を読んで進める。操作は配布CLIの `managed setup` で行い、`ant apply` を手で実行しない。
 
-- 前提: `ant` CLI 1.30 以上、利用者本人による `ant auth login`、作業先の `.shinaps/managed.json`。設定が無ければ一問ずつ確認して作る。
-- 適用は dry-run の計画を利用者に示し、合意を得てから行う。同じ計画の適用を明示的に許可されていれば `--yes` で進め、同じ範囲の承認を繰り返さない。`--prune`・`--force` は使わない。
-- 既存の `<definitions>` を置き換える前にテンプレートとの差分を示し、利用者の変更を黙って失わせない。
-- lock が無い状態で既存のリソースへ適用しない。lock を失った場合は戻すまで止める。
+- 前提: `ant` CLI 2.4.0 以上と、利用中の skill と同じ版の配布CLI。導入するアカウントの名前と、各アカウントのキーを利用者が環境変数に設定していること。キーを受け取らない・表示しない・記録しない。
+- まず `--apply` 無しで計画を示し、利用者の合意を得てから同じアカウントで `--apply` を付けて適用する。`--apply` は計画を作り直してそのまま適用するので、その間に CLI の版・同梱の定義・lock を変えない。適用時の計画が合意と違えば報告する。
+- lock が無いアカウントに同名のリソースがあれば止まる。lock を戻すまで適用しない。
 - セッションの作成・予定実行は行わない。依頼と観測は managed-execute で扱う。
-- 設定と lock から許可・予算を推定しない。秘密値を表示・記録しない。
+- lock から許可・予算を推定しない。