@shinaps/skills 0.37.0 → 0.39.0

package/plugins/shinaps-claude/references/managed/configuration.md

@@ -1,59 +1,84 @@
-# Claude Managed Agents の設定
+# Claude Managed Agents の設定とアカウント
 
-作業先リポジトリの `.shinaps/managed.json` に置く。`config_version: 1` のJSONで、[JSON Schema](configuration.schema.json)を契約の正本とする。
+Managed Agents は配布CLI `shinaps-skills managed` で導入・依頼・観測・回収する（[導入](setup.md)・[依頼と観測](execute.md)）。CLI は利用中の skill と同じ版の `@shinaps/skills` を使う。クラウドの操作は公式の `ant` CLI（2.4.0 以上）へ委ね、CLI は PATH 上の `ant` を呼ぶ。CLI が使うコマンド・フラグ・stdin の本文・出力の形は、ant 2.4.0 の公式ソースで照合した（実行は未確認。[未検証の境界](execute.md#未検証の境界)）。
 
-設定が持つのは、共通定義のコピーの置き場所・対象リポジトリ・GitHub MCP の資格情報を登録した vault だけである。許可・予算・Issueの範囲・base と head・終了条件は呼び出しのたびに利用者と合意して決め、設定には書かない。lead・役割・環境のリソース ID は lock から読み、設定には書かない。vault は lock に記録されないため、`vault_id` だけを設定に持つ。秘密値は書かない。schema は未知のキーを拒否するので、許可や予算などのキーを書いた設定は検証で失敗し、許可や予算として扱われることはない。
+## アカウント
 
-認証は `ant` の既存のログイン（利用者本人が `ant auth login` を行う）と環境変数、GitHub MCP は vault の資格情報を使う。
+アカウントは、APIキー1つが属する組織・workspace に利用者が付ける名前で、英小文字・数字と単独のハイフン（`^[a-z0-9]+(-[a-z0-9]+)*$`）にする。同じマシンでは、同じ名前は常に同じ組織・workspace を表すようにする。lock がアカウント名で引かれるので、別の組織に同じ名前を使うと別の組織の lock で適用しようとする（`ant apply` は lock と違う組織・workspace の資格情報を拒否して止まる）。
 
-## 配置
+### APIキー
+
+コマンドごとに、各アカウントのキーを次のどちらかで渡す。
+
+- 環境変数 `SHINAPS_MANAGED_API_KEY_<NAME>`（`<NAME>` はアカウント名の英大文字で、`-` は `_`。例 `work-us` → `SHINAPS_MANAGED_API_KEY_WORK_US`）。推奨。
+- 引数 `--api-key <name>=<key>`（環境変数より優先）。引数は同じマシンの他のプロセスやシェルの履歴から見えるので、共有のマシンでは使わない。
+
+CLI はキーを保存せず、出力とエラー文では伏字にする。`ant` へは子プロセスの環境変数 `ANTHROPIC_API_KEY` だけで渡し、親の `ANTHROPIC_*`（別のキー・`ant auth login` のプロファイル・workspace の指定）と他アカウントのキーは子へ渡さない。workspace をまたげる資格情報（`--workspace-id` が必要なもの）は扱わないので、workspace に属するキーを使う。
+
+### アカウントの状態
+
+各アカウントの状態は、マシン単位の管理ディレクトリ `~/.local/share/shinaps-ai/skills/managed/<account>/` に置く。lock は組織・workspace に属し、リポジトリには属さないため。複数のリポジトリから同じアカウントを使っても lock は1つになり、clone のやり直し・worktree・`git clean` で失われない。
 
 | パス | 内容 |
 | --- | --- |
-| `.shinaps/managed.json` | この設定 |
-| `<definitions>/agents/`・`environments/`・`skills/` | plugin の `managed-agents/` からコピーした共通定義。テンプレートの所有で、更新時は丸ごと置き換える |
-| `<definitions>/claude-lock.json` | `ant apply` が記録するクラウド上のリソースの ID と版 |
+| `definitions/agents/`・`environments/`・`skills/` | 同梱の共通定義の写し。setup が同梱の定義に揃える |
+| `definitions/claude-lock.json` | `ant apply` が記録するクラウド上の lead・役割・skill・環境の ID と版。setup は読むだけで書き換えない。手で編集しない |
+| `definitions.json` | setup が最後に書いた共通定義の各ファイルのハッシュ。利用者の変更の検出に使う |
+| `sessions/<request_id>.json` | このアカウントで作ったセッションの記録（入力と session ID。秘密値は含まない） |
+| `sessions/<session_id>/outputs/` | 回収した出力ファイル |
+| `update.lock` | 同じアカウントの setup・run を同時に1つにする排他（`ant apply` は lock を排他しないため） |
+
+`definitions/` には同梱の共通定義と lock だけを置き、共通定義を手で編集しない。適用はディレクトリ内の定義をすべて送るため。利用者が加えた定義の変更は導入に取り込まない（クラウドへ持ち越さない）。setup は、自分が最後に書いた内容か今回書く内容と一致するファイルだけを書き換え・削除する。利用者の編集・追加、記録の無い既存のファイル（旧版の定義ごと複写した場合など）、通常のファイル・ディレクトリ以外のもの、ほかの項目が一つでもあれば、何も変えずにそのアカウントを失敗にし、該当するパスを示す。それらを `definitions/` の外へ退避してから（lock は残す）再実行すると、同梱の定義を書き直して進む。消えた共通定義のファイルは書き直す。
+
+## lock の扱い
 
-いずれも Git 対象外にする。`.shinaps/.gitignore` が `*` で始まる場合は追加の設定なしで除外される。書き込む前に `git check-ignore --no-index -v <パス>` で除外を確認する。除外されていなければ、[導入の手順](setup.md#1-設定を読む)に従って既存の規則と共有例外を保ったまま `.shinaps/.gitignore` に必要な行だけを加えてから書き込む（新規作成の内容は[作業記録の共通手順](../work-records.md)と同じ）。`<definitions>` をリポジトリの外に置く場合は Git の対象にならないので、この確認は `.shinaps/managed.json` だけに行う。
+- `definitions/claude-lock.json` がクラウド上の ID の正本である。lead の ID は `./agents/shinaps-dev-managed-cc.md`、環境の ID は `./environments/shinaps-dev.yaml` の `id` にある。
+- lock のキーは lock のあるディレクトリからの相対パスである。共通定義を同じ構造で `definitions/` 直下に置き、そこで適用するので、既存のリソースに対応づく。
+- lock が無いと適用は既存のリソースと対応づかず、同じ名前のリソースを重複して作る。lock の `hash` は既存のリソースから作り直せないので、setup は lock が無いアカウントに同名の未アーカイブの lead・役割・環境があれば止まる。バックアップや以前の置き場所から lock を戻して再実行する。見つからなければ適用せず、利用者に相談する。
+- 別のマシンでは lock が無い。同じ組織を別のマシンから導入するときは、元のマシンの lock を同じ名前のアカウントへ複写する。
 
-## 項目
+## 作業先の設定（`.shinaps/managed.json`）
 
-全項目が必須で、`$schema` だけは省略できる。
+`managed run` だけが読む作業先の設定。`config_version: 2` のJSONで、[JSON Schema](configuration.schema.json)を契約の正本とする。持つのは、セッションにマウントするリポジトリと、アカウントごとの GitHub MCP の vault だけである。許可・予算・base と head・範囲・体制は依頼のたびに引数で明示し、設定には書かない。schema は未知のキーを拒否するので、許可や予算のキーを書いた設定は検証で失敗する。lead と環境の ID はアカウントの lock から読む。秘密値は書かない。
 
 | キー | 内容 |
 | --- | --- |
 | `$schema` | 任意のエディタ補助。CLI はこの URL を取得しない |
-| `config_version` | `1` |
-| `definitions` | 共通定義のコピーと lock を置くディレクトリ。リポジトリのルートからの相対パス、または絶対パス。clone のやり直し・worktree・`git clean` の影響を避けたい場合は、リポジトリの外の絶対パスにする。同じマシンの同じ組織で複数のリポジトリから使う場合は、全リポジトリの `definitions` に同じ絶対パスを指定し、lock を 1 つにする。別のマシンでは[lock の扱い](#lock-の扱い)に従う |
+| `config_version` | `2` |
 | `repository.url` | セッションにマウントする GitHub リポジトリの URL |
 | `repository.mount_path` | セッション内のマウント先（例 `/workspace/widgets`） |
-| `vault_id` | GitHub MCP の資格情報を登録した vault の ID。未登録なら `null` |
+| `accounts.<name>.vault_id` | そのアカウントで GitHub MCP の資格情報を登録した vault の ID（vault は組織ごと）。未登録なら `null`。依頼に使うアカウントを全て書く |
 
-## 検証
+設定は Git 対象外にする（`.shinaps/.gitignore` が `*` で始まる場合は追加の設定なしで除外される）。書き込む前に `git check-ignore --no-index -v .shinaps/managed.json` で除外を確認し、除外されていなければ既存の規則と共有例外を保ったまま `.shinaps/.gitignore` の末尾に `/managed.json` を加える（新規作成の内容は[作業記録の共通手順](../work-records.md)と同じ）。
 
-利用中の skill と同じ版の `@shinaps/skills` を導入し、`shinaps-skills validate-managed-config <明示ファイル>` で検証する。ローカル開発では `node bin/skills.ts validate-managed-config <file>` を使える。CLI は指定された一つのJSONを同梱 schema で検証し、ネットワーク取得・設定の探索・Git 操作・入力の変更はしない。成功は構造が正しいことだけを表し、lock や vault がクラウドに存在することは保証しない。
+### 検証
 
-`config_version` が欠落または旧版なら setup で作り直し、未来版なら skill と CLI を更新する。
+`shinaps-skills validate-managed-config <明示ファイル>` で検証する。ローカル開発では `node bin/skills.ts validate-managed-config <file>` を使える。CLI は指定された一つのJSONを同梱 schema で検証し、ネットワーク取得・設定の探索・Git 操作・入力の変更はしない。成功は構造が正しいことだけを表し、vault やアカウントの lock がクラウドに存在することは保証しない。
 
-## 設定例
+`config_version` が欠落または旧版なら作り直し、未来版なら skill と CLI を更新する。
+
+### version 1 からの移行
+
+version 1 は lock を作業先の `definitions`（既定 `.shinaps/managed/`）に置いていた。
+
+1. 使っていた組織・workspace にアカウント名を決める。
+2. `<definitions>/claude-lock.json` だけを `~/.local/share/shinaps-ai/skills/managed/<account>/definitions/claude-lock.json` へ移す（複数のリポジトリで同じ `definitions` を共有していた場合も1回でよい）。旧版の `agents/` などは移さない。移すと記録の無いファイルとして setup が止まる。
+3. 設定を version 2 で作り直す。`definitions` を除き、`vault_id` を `accounts.<account>.vault_id` へ移す。
+4. `managed setup --account <account>` で計画を確かめる（[導入](setup.md)）。lock を移し忘れると同名のリソースで止まる。旧版の定義を手で編集していた場合、その変更は持ち越されない。計画に、クラウド上の定義を同梱の定義へ戻す update が含まれることを確かめてから適用する。
+
+### 設定例
 
 ```json
 {
-  "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.34.0/plugins/shinaps-claude/references/managed/configuration.schema.json",
-  "config_version": 1,
-  "definitions": ".shinaps/managed",
+  "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.38.0/plugins/shinaps-claude/references/managed/configuration.schema.json",
+  "config_version": 2,
   "repository": {
     "url": "https://github.com/acme/widgets",
     "mount_path": "/workspace/widgets"
   },
-  "vault_id": null
+  "accounts": {
+    "personal": { "vault_id": null },
+    "work": { "vault_id": "vlt_011CZkZDLs7fYzm1hXNPeRjv" }
+  }
 }
 ```
-
-## lock の扱い
-
-- `<definitions>/claude-lock.json` がクラウド上の lead・役割・skill・環境の ID の正本である。`ant apply` が作成・更新するので手で編集しない。
-- lock のキーは lock のあるディレクトリからの相対パス（例 `./agents/shinaps-dev-managed-cc.md`）である。共通定義を同じ構造で `<definitions>` 直下に置くので、そこで適用すると既存のリソースに対応づく。
-- lead の ID は `./agents/shinaps-dev-managed-cc.md`、環境の ID は `./environments/shinaps-dev.yaml` の `id` から読む。
-- lock が無いと適用は既存のリソースと対応づかず、同じ名前のリソースを重複して作る。lock の `hash` は既存のリソースから作り直せないため、バックアップや以前の置き場所から戻す。見つからなければ適用せず、利用者に相談する。
-- 適用の前後に lock を作業記録（`.shinaps/work/`）へ複製し、適用後の差分を比べる。

package/plugins/shinaps-claude/references/managed/configuration.schema.json

@@ -1,7 +1,7 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.34.0/plugins/shinaps-claude/references/managed/configuration.schema.json",
-  "title": "Shinaps Managed Agents configuration v1",
+  "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.38.0/plugins/shinaps-claude/references/managed/configuration.schema.json",
+  "title": "Shinaps Managed Agents configuration v2",
   "type": "object",
   "properties": {
     "$schema": {
@@ -9,11 +9,7 @@
     },
     "config_version": {
       "type": "integer",
-      "const": 1
-    },
-    "definitions": {
-      "type": "string",
-      "minLength": 1
+      "const": 2
     },
     "repository": {
       "type": "object",
@@ -30,18 +26,32 @@
       "required": ["url", "mount_path"],
       "additionalProperties": false
     },
-    "vault_id": {
-      "anyOf": [
-        {
-          "type": "string",
-          "minLength": 1
+    "accounts": {
+      "type": "object",
+      "minProperties": 1,
+      "propertyNames": {
+        "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$"
+      },
+      "additionalProperties": {
+        "type": "object",
+        "properties": {
+          "vault_id": {
+            "anyOf": [
+              {
+                "type": "string",
+                "minLength": 1
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
         },
-        {
-          "type": "null"
-        }
-      ]
+        "required": ["vault_id"],
+        "additionalProperties": false
+      }
     }
   },
-  "required": ["config_version", "definitions", "repository", "vault_id"],
+  "required": ["config_version", "repository", "accounts"],
   "additionalProperties": false
 }

package/plugins/shinaps-claude/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-claude/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-claude/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-claude/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 から許可・予算を推定しない。

package/plugins/shinaps-codex/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "shinaps",
-  "version": "0.37.0",
+  "version": "0.39.0",
   "description": "Shinaps AIのCodex向け開発ワークフロー",
   "skills": "./skills/"
 }

package/plugins/shinaps-codex/managed-agents/agents/shinaps-dev-managed-cc.md

@@ -2,7 +2,7 @@
 name: shinaps-dev-managed-cc
 description: shinaps の dev 工程を Claude Managed Agents で進める lead。メインとして調査・設計・実装・指摘の採否を行い、選んだ体制の独立した担当に別案と独立レビューを委任し（BASIC・ULTRAでは追加の担当を判断する）、draft PR まで進める。
 model:
-  id: claude-fable-5-1
+  id: claude-opus-5-5
   effort: medium
   speed: standard
 mcp_servers: