@shinaps/skills 0.37.0 → 0.39.0

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/linear-execute/SKILL.md

@@ -11,7 +11,7 @@ Issueの責務・受入条件・ステータスを、実際の成果と一致さ
 
 着手時に作業先設定の通常の `review_flow.mode` で経路を決め、Issueの途中で切り替えない（[経路](../../references/linear/configuration.md#経路)）。
 
-- auto: [ローカルClaude CLI](../../references/linear/claude-cli.md)を起動し、質問への回答・修正・差分確定を同じsessionのresumeで依頼する。許可は `claude_cli`。
+- auto: [ローカルClaude CLI](../../references/linear/claude-cli.md)を起動し、質問への回答・修正・差分確定を同じsessionのresumeで依頼する。許可は `claude_cli` と、起動・resumeを `--permission-mode bypassPermissions` にする同意の `claude_cli_bypass_permissions`。
 - manual: WebStorm内の対話Claude Codeセッションへ[Bridge](../../references/linear/bridge.md)で依頼する。人とClaudeの作業中は同じIssueへ指示を送らず（Claudeが依頼した途中確認への応答と、[UIの微調整](../../references/linear/workflow.md#codexによるuiの微調整)の人と調整したうえでの一時停止の依頼・返却を除く）、報告を待つ。QA合格後もcommitを依頼せず、QA結果と判定記録を渡して人の依頼によるcommitの報告を待つ。許可は `bridge_request`。
 - ask: Claudeへ依頼する前に、Issueの作業内容と推奨する経路の理由を添えてautoかmanualかを人へ一問で確認し、回答まで着手しない。記録・再質問しない条件・許可は[経路](../../references/linear/configuration.md#経路)に従う。Claudeへの依頼には解決したmodeと回答の記録を添える。
 

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