@shinaps/skills 0.36.1 → 0.38.0

package/README.md

@@ -18,10 +18,10 @@ sharedで採用する `instructions.md` は共有JSONの `references.specificati
 
 0.35.0から通常設定の `review_flow.mode` に `ask` を追加しました（パス別ルールは `auto`・`manual` だけ）。既存の設定は変更不要です。
 
-CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.36.1` を導入し、`shinaps-skills --version` で確認します。`shinaps-skills validate-linear-config <明示ファイル>` は同梱schemaだけで検証し、ネットワーク取得・正本探索・Git操作・入力変更は行いません。`$schema` は固定URLによるエディタ補助で、契約の正本は[同梱schema](plugins/shinaps-claude/references/linear/configuration.schema.json)です。0.34.0から、Managed Agentsの `.shinaps/managed.json`（`config_version: 1`）も `shinaps-skills validate-managed-config <明示ファイル>` で同じ方式で検証します（[Managedの設定](plugins/shinaps-claude/references/managed/configuration.md)）。
+CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.38.0` を導入し、`shinaps-skills --version` で確認します。`shinaps-skills validate-linear-config <明示ファイル>` は同梱schemaだけで検証し、ネットワーク取得・正本探索・Git操作・入力変更は行いません。`$schema` は固定URLによるエディタ補助で、契約の正本は[同梱schema](plugins/shinaps-claude/references/linear/configuration.schema.json)です。Managed Agentsの `.shinaps/managed.json` も `shinaps-skills validate-managed-config <明示ファイル>` で同じ方式で検証します。0.38.0から `config_version: 2`（リポジトリとアカウント別のvault）になり、lockはアカウントごとの管理ディレクトリへ移ります（[Managedの設定と移行](plugins/shinaps-claude/references/managed/configuration.md)）。
 
 ```sh
-npm install -g @shinaps/skills@0.36.1
+npm install -g @shinaps/skills@0.38.0
 shinaps-skills --version
 shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.json
@@ -33,7 +33,7 @@ shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.jso
 |---|---|
 | `explore` | 対話しながら既存挙動と変更影響を調べる |
 | `spec` | 目的・仕様・実現方法を詰める |
-| `dev-claude` (Claudeのみ) | メインが選んだ体制（LITE・BASIC・ULTRA）で進行と取りまとめを行い（LITEは実装担当と独立レビュー担当の2名だけで進め、BASIC・ULTRAは必須担当を下限に追加できる）、担当が計画・実装・検証・独立レビューを行う |
+| `dev-claude` (Claudeのみ) | メインが計画・実装・検証・採否を行い、選んだ体制（LITE・BASIC・ULTRA）の担当が独立した別案と独立レビューを行う |
 | `debug` | 不具合の原因を検証する |
 | `review` | 差分や既存コードをレビューする |
 | `refine` | Shinaps AIのruleと実ファイルを照合する |
@@ -44,8 +44,8 @@ shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.jso
 | `release` | 公開条件を確定し、対象バージョンの利用可能性を確認する |
 | `linear-plan` | 相談・必要なspec/explore・Issue作成と整理・プロジェクト設定を行い、実装前で止める |
 | `linear-execute` | Issue単体・Cycle全体・バックログ消化を選び、設定に従って実装・QA・許可された公開を進める |
-| `managed-setup` | Claude Managed Agentsの共通dev構成を自分の組織へ導入・更新する。既存のlockを使い、重複して作らない |
-| `managed-execute` | Managed Agentsのleadへdevを依頼し、観測・質問の取り次ぎ・成果物とdraft PRの確認を行う |
+| `managed-setup` | Claude Managed Agentsの共通dev構成を1つ以上のアカウントへ一コマンドで導入・更新する。アカウントごとのlockを使い、重複して作らない |
+| `managed-execute` | Managed Agentsのleadへdevを依頼し、観測・質問の取り次ぎ・出力のローカル回収とdraft PRの確認を行う |
 
 コミット・PR・リリースは、利用者の依頼またはLinear進行で合意済みの継続許可に従う。[共通設定](plugins/shinaps-claude/references/linear/configuration.md)・[担当と工程](plugins/shinaps-claude/references/linear/workflow.md)・[終了と待機](plugins/shinaps-claude/references/linear/execution.md)を参照し、必要な前工程が揃えば再確認せずに進む。単独スキル利用にはLinear進行や新しいゴールを必須にしない。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
 
@@ -61,15 +61,15 @@ shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.jso
 
 ### dev の入口と体制
 
-ローカルの実装の入口は Claude Code の `dev-claude` だけで、Codexに実装の入口はない。Claude Managed Agentsは別runtimeで、`managed-setup`・`managed-execute` から使う。「[Claude Managed Agents](#claude-managed-agents)」節で扱う。メインのモデルは[経路](plugins/shinaps-claude/references/linear/configuration.md#経路)で決まる（単独devは利用者のセッション設定のまま）。担当は登録エージェントの定義（Opus / medium）で動く。
+ローカルの実装の入口は Claude Code の `dev-claude` だけで、Codexに実装の入口はない。Claude Managed Agentsは別runtimeで、`managed-setup`・`managed-execute` から使う。「[Claude Managed Agents](#claude-managed-agents)」節で扱う。メインのモデルは[経路](plugins/shinaps-claude/references/linear/configuration.md#経路)で決まる（単独devは利用者のセッション設定のまま）。メインは調査・設計・実装・指摘の採否を自分で行うので、メインのモデルと effort がそのまま設計・実装のモデルになる。担当は登録エージェントの定義（Opus / medium）で動く。
 
-devの体制は、実装担当と独立レビュー担当だけのLITE、担当を少なくして進めるBASIC、独立した確認を厚くするULTRAの3段階で、LITEは実装担当と独立レビュー担当の2名だけで進め、BASIC・ULTRAは必須担当を下限にメインが追加できる（[実装体制の判断](plugins/shinaps-claude/references/dev/staffing.md)）。体制・経路（auto・manual）・メインのモデルは別の軸である。体制は各Issueの着手時と人の指摘の一括修正の開始時に、推奨を添えて人に確認する。人数を増やすだけで許可・予算・品質条件は変えない。
+devの体制は、実装後の独立コードレビューの担当1名だけのLITE、計画レビュー担当1名と独立コードレビューの担当1名を置くBASIC、メインの案を見ない独立設計担当1名・計画レビュー担当2名・実装後の独立レビュー（A: 独立コードレビューの担当1名、B: 技術領域ごとの規約照合・可読性・慣習の担当1名）を置くULTRAの3段階で、BASIC・ULTRAは必須担当を下限にメインが追加できる（[実装体制の判断](plugins/shinaps-claude/references/dev/staffing.md)）。3体制の違いは独立確認の対象・人数・深さだけで、共有する文脈が必要な作業はどの体制でもメインが行う。同じ対象を読む確認の観点（計画の簡素化、規約照合、実装の簡素化など）は少数の担当にまとめて依頼する。体制・経路（auto・manual）・メインのモデルは別の軸である。体制は各Issueの着手時と人の指摘の一括修正の開始時に、推奨を添えて人に確認する。人数を増やすだけで許可・予算・品質条件は変えない。
 
 - 工程と体制基準はClaude版を編集元としてCodexへ複製する。起動手順だけはruntimeごとに異なる。
 - Managedの `staffing.md`・`workflow.md`・`launch.md` はClaude版を編集元に写した適応版で、一致はテストしない。Claude版の工程・体制基準を変えたらManagedへの適用可否を判断する。
 - Claudeは登録エージェント、Codexは名前付きサブエージェントを使う。担当のモデル・推論の設定は人数判断で変更しない。
 - Claudeのexplore・spec・review・debugからは `dev-claude` へ引き継ぐ。ClaudeのdevはSkillツールからの起動も許可する。Codexのスキルは実装へ引き継がず、Linear進行では `linear-execute` でClaudeへ依頼する。
-- テスト方針は各版の `references/testing.md` を正本とし、役割定義に同じ段落を複製して検証する。
+- テスト方針は各版の `references/testing.md` を正本とし、役割定義に同じ段落を複製して検証する。設計の観点は `references/dev/design.md` を正本とし、独立設計担当（`shinaps-architect`）の定義とManagedのskillの `references/design.md` に本文を複製して検証する。
 
 ## Claude Code
 
@@ -134,38 +134,50 @@ Claude Codeは標準のmarketplace自動更新機能を使う。`/plugin` のMar
 
 ## Claude Managed Agents
 
-両pluginの `managed-agents/` は、Claude Managed Agentsでdev工程を進めるための共通定義である。lead `shinaps-dev-managed-cc`、devの7役割、skill `dev-managed-cc`、環境 `shinaps-dev` を置く。クラウドのIDを記録する `claude-lock.json` と実設定は利用者ごとのものなので、作業先の `.shinaps/` に置き、公開する定義には含めない。予定実行はこの構成に含めない。
+両pluginの `managed-agents/` は、Claude Managed Agentsでdev工程を進めるための共通定義である。lead `shinaps-dev-managed-cc`、devの3役割、skill `dev-managed-cc`、環境 `shinaps-dev` を置く。クラウドのIDを記録する `claude-lock.json` は利用者のアカウント（APIキーの組織・workspace）ごとのものなので、マシン単位の管理ディレクトリに置き、公開する定義には含めない。予定実行はこの構成に含めない。
 
-- leadはFable 5.1（`claude-fable-5-1` / medium）、役割はOpus 5.5（`claude-opus-5-5` / medium）で動く。全agent定義に `speed: standard` を明示する（既存リソースに残るfastを戻すため）。leadのモデルは定義で決まり、Linear進行の経路ごとのメインのモデルとは別に扱う。
-- 体制はLITE・BASIC・ULTRAを初回メッセージで受け、`dev-claude` と同じ体制の表に従い、BASIC・ULTRAではleadが追加の担当を決める。ULTRAのため指摘検証（review-verifier）と規約照合（refine）の役割も登録する。廃止したdev-ultraなどの入口とexplorerは置かず、探索は設計担当が行う。
+- leadと3役割はOpus 5.5（`claude-opus-5-5` / medium）で動く。全agent定義に `speed: standard` を明示する（既存リソースに残るfastを戻すため）。leadのモデルは定義で決まり、Linear進行の経路ごとのメインのモデルとは別に扱う。
+- 体制はLITE・BASIC・ULTRAを初回メッセージで受け、`dev-claude` と同じ体制の表に従い、BASIC・ULTRAではleadが追加の担当を決める。leadがメインとして調査・設計・実装・採否を行い、独立設計（ULTRAでは必須）・計画レビュー・実装後の独立レビューだけを登録した3役割（architect・plan-reviewer・reviewer）へ委任する。Managedで設計・実装を行うモデルはleadのOpusになる。廃止したdev-ultraなどの入口・explorer・refine専用の役割は置かず、探索はleadと独立設計担当が行う。
 - Shinaps AIのMCPとruleを使わない。規約はマウントしたリポジトリの `AGENTS.md`・`CLAUDE.md` と参照先、添付された利用者CLAUDE.mdだけで、最終報告ではShinaps AI ruleを未照合とする。
-- 初回メッセージにリポジトリ・base・head・範囲と受入条件・許可・予算が揃わなければ、leadは作業を始めず欠落を質問する。許可はそのメッセージで明示された操作だけで、構成の導入からは生じない。
+- 初回メッセージにリポジトリ・base・head・範囲と受入条件・体制・許可・予算が揃わなければ、leadは作業を始めず欠落を質問する。許可はそのメッセージで明示された操作だけで、構成の導入からは生じない。
 - 終了地点は範囲を限ったコミット・headブランチへのpush・draft PR。merge・deploy・release・Issueの更新はしない。CodexのQAはセッションの外で、PRの後に行う。push前に最終QAを行うLinear進行とは順序が違う。
 
-### 定義の更新と適用
+### CLI
 
-1. 共通定義は `plugins/shinaps-claude/managed-agents/` を編集元とし、`plugins/shinaps-codex/managed-agents/` へ同じ内容を複製する。一致はテストで確認する。
-2. 作業先では `managed-setup` が、`.shinaps/managed.json`（[設定](plugins/shinaps-claude/references/managed/configuration.md)）の `definitions` が指すディレクトリ（既定は `.shinaps/managed/`、Git対象外）へ共通定義をコピーする。
-3. そのディレクトリで `ant apply --dry-run .` を実行し、計画を確認する。
-4. 利用者の合意後に `ant apply .` で適用する。`--prune`・`--force` は使わず、リソースを削除しない。
-5. 適用前に複製したlock（`.shinaps/work/` に置く）と比べ、更新したリソースの `version`・`hash`・`remote_hash` 以外が変わっていないことを確かめる。
+導入・依頼・観測・回収は配布CLIの `shinaps-skills managed` で行い、クラウドの操作は公式の `ant` CLI（2.4.0以上。コマンド・フラグ・stdin・出力はこの版のソースで照合した）へ委ねる。各アカウントのAPIキーは環境変数 `SHINAPS_MANAGED_API_KEY_<NAME>` か引数 `--api-key <name>=<key>` で渡し、CLIは保存・表示しない。lock・セッション記録・回収した出力は `~/.local/share/shinaps-ai/skills/managed/<account>/` にアカウントごとに分かれる。
 
-手順・安全上の注意・止める条件は[導入と更新の手順](plugins/shinaps-claude/references/managed/setup.md)にある。セッションの依頼・観測・未検証の境界は[依頼と観測の手順](plugins/shinaps-claude/references/managed/execute.md)にある。これらはpluginに含まれ、どちらのruntimeからも読める。
+```sh
+shinaps-skills managed setup --account personal --account work          # 計画の表示だけ
+shinaps-skills managed setup --account personal --account work --apply  # 合意後に適用
+shinaps-skills managed run .shinaps/managed.json --account work --base main --base-sha <SHA> --head feat/x \
+  --staffing BASIC --allow commit,push,draft_pr --budget-cents 4000 --task-file task.md
+shinaps-skills managed status --account work --session <ID>
+shinaps-skills managed reply --account work --session <ID> --message-file answer.md
+shinaps-skills managed collect --account work --session <ID>
+```
 
-### このリポジトリのlock
+- setupはアカウントごとのlockで既存のリソースを更新し、lockが無いのに同名のリソースがあれば作らずに止まる。`--apply` を付けない限りクラウドを変更しない。
+- runはリポジトリ・base・head・範囲・体制・許可・予算を毎回明示し、同じ入力の再実行では新しいセッションを作らない。
+- collectはセッションの出力を保存するだけで、差分を適用しない。CLIはgitを呼ばず、pushしない。
+
+手順・安全上の注意・止める条件は[設定とアカウント](plugins/shinaps-claude/references/managed/configuration.md)・[導入と更新の手順](plugins/shinaps-claude/references/managed/setup.md)・[依頼と観測の手順](plugins/shinaps-claude/references/managed/execute.md)にある。これらはpluginに含まれ、どちらのruntimeからも読める。
 
-shinaps-skills自身のlockは0.34.0で `.shinaps/managed/claude-lock.json`（Git対象外）へ移した。以前の内容は `git show 8679d8f:managed-agents/claude-lock.json` で取り出せる。
+### 定義の更新と適用
+
+共通定義は `plugins/shinaps-claude/managed-agents/` を編集元とし、`plugins/shinaps-codex/managed-agents/` へ同じ内容を複製する。一致はテストで確認する。定義を変えたら `managed setup` で計画を確かめてから `--apply` で適用する。`--prune`・`--force` は使わず、リソースを削除しない。
 
-定義を変えたら、`managed-setup` の手順（[導入と更新の手順](plugins/shinaps-claude/references/managed/setup.md)）でdry-runの計画を確かめてから適用する。`--prune` は付けない。旧CC Ultraのleadと専用skill、旧explorerと旧review-verifierはクラウドでアーカイブ済みで、lockでも追跡しない。
+### このリポジトリのlock
 
-GitHub MCP（`https://api.githubcopilot.com/mcp`）の資格情報はvaultに登録し、セッション作成時に渡す。vaultの資格情報はMCPサーバーのURLで照合されるので、lead定義のURLと末尾のスラッシュまで揃える。leadは最後のメッセージの1行目に `状態: 完了`・`状態: 質問`・`状態: 未完了` を書き、`changes.patch` と作業記録のtarを `/mnt/session/outputs/` に置く（[起動手順](plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/launch.md)）。マウントしたリポジトリへのpushとdraft PRの作成は、実際のセッションで確かめるまで未検証である。
+shinaps-skills自身のlockは0.34.0から0.37.0まで `.shinaps/managed/claude-lock.json`（Git対象外）に置いていた。0.38.0では[version 1 からの移行](plugins/shinaps-claude/references/managed/configuration.md#version-1-からの移行)に従い、アカウントの `definitions/claude-lock.json` へ移してから適用する。それ以前の内容は `git show 8679d8f:managed-agents/claude-lock.json` で取り出せる。旧CC Ultraのleadと専用skill、旧explorerと旧review-verifierはクラウドでアーカイブ済みで、lockでも追跡しない。
+
+GitHub MCP（`https://api.githubcopilot.com/mcp`）の資格情報はアカウントの組織のvaultに登録し、セッション作成時に渡す。vaultの資格情報はMCPサーバーのURLで照合されるので、lead定義のURLと末尾のスラッシュまで揃える。leadは最後のメッセージの1行目に `状態: 完了`・`状態: 質問`・`状態: 未完了` を書き、`changes.patch` と作業記録のtarを `/mnt/session/outputs/` に置く（[起動手順](plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/launch.md)）。CLIの実クラウドでの実行、マウントしたリポジトリへのpushとdraft PRの作成は、実際のセッションで確かめるまで未検証である。
 
 ## 開発と配布
 
 - Claude版: `plugins/shinaps-claude/`、marketplaceは`.claude-plugin/marketplace.json`
 - Codex版: `plugins/shinaps-codex/`、marketplaceは`.agents/plugins/marketplace.json`
 - Codexカスタムエージェント: `plugins/shinaps-codex/agents/`
-- Claude Managed Agents版: 両pluginの `managed-agents/`（Claude版が編集元）。pluginと一緒に配布され、npmパッケージの `plugins/` にも含まれる。適用は作業先の `.shinaps/managed/` へコピーしてから「Claude Managed Agents」節の手順で行い、`--prune`・`--force` を使わない
+- Claude Managed Agents版: 両pluginの `managed-agents/`（Claude版が編集元）。pluginと一緒に配布され、npmパッケージの `plugins/` にも含まれる。適用は `shinaps-skills managed setup` がアカウントごとの管理ディレクトリへコピーしてから行い、`--prune`・`--force` を使わない
 - 配布CLI: ソースは `bin/skills.ts` と `lib/*.ts`。`npm run build` (`tsc`) で `dist/` にJSを出力し、npmにはそれを配布する。Node.jsは`node_modules`配下の`.ts`に型除去を適用しないため、ソースのままは配布できない。checkoutでは型除去で直接実行するので、`enum`など型除去で消せない構文は使わない (`tsconfig.json` の `erasableSyntaxOnly`)
 
 品質基準とプロジェクト設定の方針は揃えつつ、クライアント固有の実行手順・エージェント形式は別々に管理する。Codex版の工程の資料（`references/` の、`dev/launch.md` を除くもの）はClaude版と一致させ、テストで確認する。Codex版は役割の本文とスキルを書き分け、Claude向けのエージェント呼び出しをCodexに読み替えさせる方式は使わない。スキルを追加・変更した場合は各版への適用可否を判断する。
@@ -219,19 +231,17 @@ codex mcp login shinaps-ai
 
 未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`commit`・`create-pr`・`release`・`linear-plan`・`linear-execute` の基本手順はMCP接続を必須としない。
 
-## Subagents (Claude: 16 / Codex: 10)
+## Subagents (Claude: 14 / Codex: 10)
 
 | Subagent | 配布 | 役割 |
 |---|---|---|
 | `shinaps-explorer` | 両方 | コードベース探索、必読ファイル抽出 |
 | `shinaps-investigator` | 両方 | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
-| `shinaps-architect` | Claudeのみ | 設計。dev では設計担当1 が設計・設計案統合・設計適合性・プランと全指摘の最終判断・修正サイクルの修正計画・人の指摘の調査を行い、設計担当2以降が独立設計を行う |
-| `shinaps-plan-reviewer` | Claudeのみ | 計画レビュー (confidence 閾値 70)。2名以上で独立に指摘と修正案を返す |
-| `shinaps-implementer` | Claudeのみ | 確定した計画の実装・簡素化・検証、レビュー後の修正 |
-| `shinaps-reviewer` | 両方 | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80)。Claude の dev では、「可読性・慣習レビュー」も同じ役割の種類として担う |
+| `shinaps-architect` | Claudeのみ | dev で独立設計担当を置く場合（ULTRA、または追加した BASIC）の独立設計。メインの案を見ずに、要件・制約・規約・引き継いだ成果物から別案を返す |
+| `shinaps-plan-reviewer` | Claudeのみ | 計画レビュー (confidence 閾値 70) と計画の簡素化。体制に応じて1〜2名で独立に指摘・修正案・削減の提案を返す |
+| `shinaps-reviewer` | 両方 | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80)。Claude の dev では、「可読性・慣習レビュー」「規約照合」「実装の簡素化」も同じ役割の種類として担う |
 | `shinaps-review-validator` | 両方 | reviewer 指摘の実コード検証 (confirmed / false positive / partial / out-of-scope 分類) |
-| `shinaps-review-verifier` | Claudeのみ | dev の計画段階と実装後の各検証ラウンドで新しく起動され、全担当の指摘を検証・重複整理し、出典・反証・対立をarchitectへ渡す |
-| `shinaps-simplifier` | Claudeのみ | 計画・実装の簡素化の提案。仕様・構造・処理の削減を読み取り専用で提案 |
+| `shinaps-simplifier` | Claudeのみ | `shinaps:simplify` の計画・実装の簡素化の提案。仕様・構造・処理の削減を読み取り専用で提案 |
 | `shinaps-refine-agent` | 両方 | rule 照合 (ファイル現状全文と照合、Violation / Improvement / Question 分類 + changed / pre-existing 切り分け) |
 | `shinaps-spec-writer` | 両方 | ヒアリング + 調査結果を spec.md 構造化 |
 | `shinaps-tech-surveyor` | 両方 | 外部技術調査 (WebSearch + WebFetch で 3-5 候補比較) |
@@ -240,9 +250,9 @@ codex mcp login shinaps-ai
 | `shinaps-debug-validator` | 両方 | 仮説の実コード検証 (root-cause / contributing-factor / red-herring / needs-reproduction 分類) |
 | `shinaps-split-reviewer` | Claudeのみ | `shinaps:commit` のmanualの分割案を「単位の diff だけで妥当性を判断できるか」で批判 + 修正版最終分割計画 (worktree は read-only) |
 
-Claude版はMarkdown、Codex版はTOMLで役割を定義する。Managed Agents版（両pluginの `managed-agents/agents/`）はdevの7役割だけを、Claude版の `name`・`description`・本文に `ant apply` 用の frontmatter を付けたMarkdownで定義する。
+Claude版はMarkdown、Codex版はTOMLで役割を定義する。Managed Agents版（両pluginの `managed-agents/agents/`）はdevの3役割だけを、Claude版の `name`・`description`・本文に `ant apply` 用の frontmatter を付けたMarkdownで定義する。
 
-Claude版は全16エージェントが `opus / medium`。Codex版の役割定義はモデルを書かず、モデルと推論は親セッションから継承する。dev での担当の割り当ては[dev の工程](plugins/shinaps-claude/references/dev/workflow.md)にある。
+Claude版は全14エージェントが `opus / medium`。Codex版の役割定義はモデルを書かず、モデルと推論は親セッションから継承する。dev での担当の割り当ては[dev の工程](plugins/shinaps-claude/references/dev/workflow.md)にある。
 
 **subagent 内では shinaps MCP を直接呼び出さず、rule 全文は Skill 側から prompt 経由で渡す** 原則を全 system prompt に明記する。MCP呼び出しの利用量が重複しないようにするため。
 
@@ -256,8 +266,7 @@ Claude版は全16エージェントが `opus / medium`。Codex版の役割定義
 ├── .gitignore             # 保存方式に応じた除外・共有対象の例外
 ├── linear.json            # linear のプロジェクト設定（任意）
 ├── linear/                # linear の補足（任意）
-├── managed.json           # Managed Agents のローカル設定（任意・Git対象外）
-├── managed/               # Managed の共通定義のコピーと claude-lock.json（任意・Git対象外）
+├── managed.json           # Managed Agents の依頼先リポジトリとアカウント別のvault（任意・Git対象外）
 └── work/
     ├── {日時}-{作業名}/
     ├── explorations/
@@ -266,6 +275,8 @@ Claude版は全16エージェントが `opus / medium`。Codex版の役割定義
     └── debug/
 ```
 
+Managed Agentsのアカウントごとのlock・セッション記録・回収した出力は、リポジトリではなく `~/.local/share/shinaps-ai/skills/managed/<account>/` に置く（[設定とアカウント](plugins/shinaps-claude/references/managed/configuration.md)）。
+
 旧 `.claude/shinaps/` の成果物はパスを指定して引き継げる。既存記録を自動移動・削除しない。共有する仕様書などの明示された納品先は尊重し、作業記録に秘密情報を含めない。
 
 ## 対応範囲

package/dist/bin/skills.js

@@ -4,6 +4,7 @@ import { join } from 'node:path';
 import { packageRoot } from '../lib/layout.js';
 import { validateLinearConfig } from '../lib/linear-config.js';
 import { validateManagedConfig } from '../lib/managed-config.js';
+import { managed } from '../lib/managed.js';
 import { run } from '../lib/install.js';
 import { autoUpdate } from '../lib/auto-update.js';
 import { errorMessage } from '../lib/fs.js';
@@ -22,8 +23,10 @@ try {
         if (rest.length !== 1)
             throw new Error('Usage: shinaps-skills validate-managed-config <file>');
         await validateManagedConfig(rest[0]);
-        console.log('Managed configuration is valid (config_version: 1).');
+        console.log('Managed configuration is valid (config_version: 2).');
     }
+    else if (command === 'managed')
+        await managed(rest);
     else if (command === 'auto-update')
         await autoUpdate(rest);
     else

package/dist/lib/config-validation.js

@@ -2,7 +2,7 @@ import { readFile } from 'node:fs/promises';
 import { join } from 'node:path';
 import { Ajv } from 'ajv';
 import { packageRoot } from './layout.js';
-/** 明示されたファイルを同梱の契約で検証する。設定の探索・変更や外部取得は行わない。 */
+/** 明示されたファイルを同梱の契約で検証し、検証した内容を返す。設定の探索・変更や外部取得は行わない。 */
 export async function validateConfig(path, contract) {
     const input = JSON.parse(await readFile(path, 'utf8'));
     // 版の不一致は設定修正とskill更新で対処が異なるため、schema検証より先に案内する。
@@ -30,4 +30,5 @@ export async function validateConfig(path, contract) {
             .join('\n');
         throw new Error(`Invalid ${contract.name} configuration. Correct the JSON to match configuration.schema.json:\n${errors}`);
     }
+    return input;
 }

package/dist/lib/install.js

@@ -12,6 +12,7 @@ const usage = [
     'Usage: shinaps-skills <install|update|uninstall|recover> codex',
     '       shinaps-skills validate-linear-config <file>',
     '       shinaps-skills validate-managed-config <file>',
+    '       shinaps-skills managed <setup|run|status|reply|collect> (see managed --help)',
     '       shinaps-skills auto-update <enable|disable|status|check> codex',
     'Claude Code: /plugin marketplace add sh1n4ps/shinaps-skills',
     '             /plugin install shinaps@shinaps-skills',

package/dist/lib/layout.js

@@ -5,6 +5,8 @@ import { fileURLToPath } from 'node:url';
 // launchd ジョブは enable した版の CLI ではなく、実行のたびに npm から取得した最新版の CLI を起動する。
 // そのためここに定義した場所と形式 (auto-update.json、state.json、transaction/journal.json) は
 // どの版でも読めるように保ち、変える場合は旧形式も読めるようにする。
+// Managed Agents のアカウントごとの配置 (managed/<account>/ の lock とセッション記録) も同じ約束で、
+// 版を変えても既存の lock を見失わないようにする。lock を見失うと、次の適用が同じリソースを重複して作る。
 /**
  * このパッケージのルートディレクトリ。リポジトリの checkout、または npm が展開したディレクトリ。
  * このファイルは checkout では `lib/`、配布物では `dist/lib/` にあり深さが違うので、package.json が
@@ -39,6 +41,16 @@ export const managedRoot = (home) => join(home, '.local', 'share', 'shinaps-ai',
 /** 配置済みの配布物。Codex の marketplace はここを指す。 */
 export const payloadDir = (root) => join(root, 'codex');
 export const statePath = (root) => join(root, 'state.json');
+/**
+ * Managed Agents のアカウントのディレクトリ。lock は組織・workspace (APIキー) に属し、リポジトリには
+ * 属さないので、リポジトリではなくマシン単位の管理ディレクトリに置く。
+ * - `definitions/`: `ant apply` の cwd。同梱の共通定義の写しと `claude-lock.json` だけを置く。
+ * - `sessions/<request_id>.json`: このアカウントで作成したセッションの記録。
+ * - `sessions/<session_id>/outputs/`: 回収したファイル。
+ */
+export const managedAccountDir = (root, account) => join(root, 'managed', account);
+/** 同梱の Managed 共通定義。両 plugin の内容は同一 (テストで確認) なので Claude 版を使う。 */
+export const managedTemplatePath = 'plugins/shinaps-claude/managed-agents';
 /** CODEX_HOME の解決値。オプション (`auto-update check` が渡す) → 環境変数 → Codex の既定の順。 */
 export const codexHomeOf = (options, home) => resolve(options.codexHome ?? process.env.CODEX_HOME ?? join(home, '.codex'));
 /**

package/dist/lib/linear-config.js

@@ -1,7 +1,7 @@
 import { validateConfig } from './config-validation.js';
 /** `.shinaps/linear.json` を同梱の契約で検証する。 */
-export function validateLinearConfig(path) {
-    return validateConfig(path, {
+export async function validateLinearConfig(path) {
+    await validateConfig(path, {
         name: 'Linear',
         schema: 'plugins/shinaps-claude/references/linear/configuration.schema.json',
         version: 2,

package/dist/lib/managed-ant.js

@@ -0,0 +1,70 @@
+import { spawn } from 'node:child_process';
+/**
+ * Managed Agents の beta ヘッダ。ant の `--beta` は既定の beta ヘッダを置き換えるので、既定に頼らず
+ * 毎回明示する (agents・environments・sessions の既定と同じ値)。Files は `filesBeta` を使う。
+ */
+export const managedBeta = ['--beta', 'managed-agents-2026-04-01'];
+/** セッションの Files には Files API と Managed Agents の両方の beta が要る。 */
+export const filesBeta = ['--beta', 'files-api-2025-04-14', ...managedBeta];
+/**
+ * 子プロセスの環境。親の `ANTHROPIC_*` (別のキー・ログインのプロファイル・workspace・federation) と
+ * 他アカウントのキー (`SHINAPS_MANAGED_*`) を渡さず、そのアカウントのキーだけを資格情報にする。
+ * ant は環境変数をログインより優先するが、複数の資格情報が残ると、どれが使われるかが ant の優先順位に
+ * 依存し、別アカウントのリソースを操作しかねないため。
+ */
+export function antEnvironment(env, apiKey) {
+    const result = {};
+    for (const [name, value] of Object.entries(env)) {
+        if (!name.startsWith('ANTHROPIC_') && !name.startsWith('SHINAPS_MANAGED_')) {
+            result[name] = value;
+        }
+    }
+    result.ANTHROPIC_API_KEY = apiKey;
+    // ant は FORCE_COLOR=1 で非端末にも色を付ける。計画の文言や jsonl の解析が ANSI で壊れないよう止める。
+    result.FORCE_COLOR = '0';
+    return result;
+}
+/**
+ * stdin に渡すリクエスト本文。ant は本文の文字列値のうち `@` で始まるものをファイル参照として展開し
+ * (`@notes.md` ならそのファイルの内容を送り、無ければ失敗する)、`\@` で始まるものだけを `@` の文字列に
+ * 戻す。題名や回答の本文を書かれたとおりに送るため、`@` で始まる文字列を全て `\@` に置き換える。
+ * `\@` で始まる文字列は ant が必ず `@` に変えるので、そのままは送れない (ant の制約)。
+ */
+export function antRequestBody(value) {
+    return JSON.stringify(value, (_key, item) => typeof item === 'string' && item.startsWith('@') ? `\\${item}` : item);
+}
+/**
+ * PATH 上の `ant` を実行する。本文が無ければ stdin を /dev/null にする。ant は stdin がパイプなら
+ * 本文の有無を 10 ms 待って確かめるので、本文の無い呼び出しにパイプを渡さない。本文は起動と同時に
+ * パイプへ書き込むので、ant が確かめる時点では既に読める。
+ */
+export const antCommand = (env) => ({ argv, apiKey, cwd, body }) => new Promise((resolve, reject) => {
+    const child = spawn('ant', argv, {
+        cwd,
+        env: antEnvironment(env, apiKey),
+        stdio: [body === undefined ? 'ignore' : 'pipe', 'pipe', 'pipe'],
+    });
+    const stdout = [];
+    const stderr = [];
+    child.stdout?.on('data', (chunk) => stdout.push(chunk));
+    child.stderr?.on('data', (chunk) => stderr.push(chunk));
+    child.on('error', reject);
+    child.on('close', (status, signal) => {
+        if (status === 0) {
+            resolve(Buffer.concat(stdout).toString('utf8'));
+            return;
+        }
+        // ant は API エラーの本文と、途中で失敗した apply の結果を stdout に出すので、両方を残す。
+        // 呼び出し側が秘密値を伏字にしてから表示する。
+        const output = [Buffer.concat(stdout), Buffer.concat(stderr)]
+            .map((chunk) => chunk.toString('utf8').trim())
+            .filter(Boolean)
+            .join('\n');
+        reject(new Error(`ant ${argv.slice(0, 2).join(' ')} exited with ${status ?? signal}:\n${output}`));
+    });
+    // ant が本文を読む前に終わる (引数の誤りなど) と書き込みは EPIPE で失敗する。その成否は
+    // 終了コードとエラー出力で報告するので、書き込みのエラーでプロセスを落とさない。
+    child.stdin?.on('error', () => { });
+    if (body !== undefined)
+        child.stdin?.end(antRequestBody(body));
+});

package/dist/lib/managed-config.js

@@ -1,10 +1,10 @@
 import { validateConfig } from './config-validation.js';
-/** `.shinaps/managed.json` を同梱の契約で検証する。 */
-export function validateManagedConfig(path) {
-    return validateConfig(path, {
+/** `.shinaps/managed.json` を同梱の契約で検証し、内容を返す。 */
+export async function validateManagedConfig(path) {
+    return (await validateConfig(path, {
         name: 'Managed',
         schema: 'plugins/shinaps-claude/references/managed/configuration.schema.json',
-        version: 1,
-        migration: 'Create it with managed-setup (config_version: 1).',
-    });
+        version: 2,
+        migration: 'Recreate it as config_version: 2 with managed-execute and move each existing claude-lock.json to its account directory (references/managed/configuration.md, migration from version 1).',
+    }));
 }