@shinaps/skills 0.33.2 → 0.34.0

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

@@ -0,0 +1,42 @@
+# 実装体制の判断
+
+人数を入口名や変更行数で固定しない。lead が設計担当の起動前に初期体制を決める。初回メッセージに初期体制があれば引き継ぐ。
+
+## 判断すること
+
+- **不確実性**: 要件と既存の解法が明確か。責務・依存方向・設計案の比較に独立した検討が必要か。
+- **影響範囲**: 局所的で利用側を追えるか。複数機能・共通基盤・実行環境をまたぐか。
+- **失敗時の影響と検証可能性**: 容易に戻せて既存テストで確認できるか。認証・課金・データ保全などの重要な契約や、再現・検証が難しい挙動に関わるか。
+
+点数・行数・一律の大小ラベルで人数を自動決定せず、未解決の問いと必要な独立確認に担当を対応させる。初期確認だけで分からなければ、まず探索の範囲を決め、その結果で設計前に体制を更新する。担当を起動するためだけの調査や計画書は増やさない。
+
+| 役割 | 専任を置く判断と人数 | 専任を置かない場合 |
+| --- | --- | --- |
+| 設計 | 責務・依存・方式の判断が必要なら配置。競合する案や重大な見落としを独立に比較する必要があれば複数 | lead が短い計画と検証方針を確定 |
+| 計画レビュー | 実装前に検証すべき設計リスクがあれば配置。異なる観点の独立確認が必要なら複数 | lead が要件・実装可能性・検証方針を確認 |
+| 計画／実装の簡素化 | 状態・抽象化・変更範囲の複雑さに専門の検討が必要なら配置。計画と実装で別々に判断 | 計画は設計責任者、実装は実装担当とコードレビュー担当が確認 |
+| 実装 | 1体。修正も同じ担当に戻す | 委任できない場合だけ、許可と規約に従って lead が実装 |
+| 独立コードレビュー | 最低1体。重要な契約や複数領域の見落としを独立に確認する必要があれば追加 | 起動不能なら独立レビュー未完了。自己レビューで代替完了にしない |
+
+探索・指摘検証・規約照合の専任は置けない。
+
+- 探索は lead と設計担当が関連ファイルと既存調査を確認し、実装担当は実装の詳細を調べる。
+- 指摘検証は設計責任者（設計担当1、専任なしなら lead）が全指摘の根拠・出典・重複・対立・未確認を整理して採否を決め、再現や検証が必要なら実装担当へ依頼する。対立・不確実な指摘を黙って消さない。
+- 規約照合はコードレビュー担当に規約全文と照合責務を渡す。
+
+明確で局所的な変更なら、lead が計画し、実装1体・独立コードレビュー1体で進められる。設計が難しければ設計担当や計画レビューを追加し、設計案の独立比較が必要なら設計担当を複数にする。コードのリスクが高い場合はコードレビューを増やす。どれか一つを増やすために全役割を複数にしない。
+
+起動前に、判断の根拠、工程ごとの役割・人数・確認範囲、専任なしの責任者、必須検証、設計と指摘の統合責任者を作業記録へ短く残す。設計担当がいれば担当1が設計・統合を継続し、いなければ lead が責任を持つ。
+
+## 途中の増員
+
+初期体制は上限ではない。設計上の新しい不確実性、影響領域の追加、重要な契約への影響、検証失敗、指摘の対立が判明した時点で lead が必要な役割・人数・確認範囲を増やし、理由と体制の変更を記録する。担当からの提案は lead が判断する。追加担当の確認が必要な工程は結果が揃うまで完了にしない。
+
+- 新しい担当には現在の要件・同じ版の対象・規約・確定済み判断を渡す。独立確認を求める場合、他担当の今回の未確定結果は渡さない。
+- 設計担当を途中で置く場合は担当1を統合責任者として引き継ぎ、lead の旧計画も検討対象にする。既存担当の仕事を理由なく最初から繰り返さない。
+- 増員で既存の未完了・不利な指摘を消さない。同じ対象への増員・交代でレビューラウンドの上限をリセットしない。枠不足は順番に起動し、人数を黙って減らさない。
+- 体制判断は操作・予算の許可を作らない。仕様・範囲・明示された人数制限・許可・予算を変える必要がある場合だけ、`状態: 質問` で利用者に一問で確認する。
+
+## 人数によらず維持する条件
+
+要件と影響範囲の確認、必要なテストとプロジェクトの必須検証、実装者と独立したコードレビュー、適用規約の照合、全指摘の採否と根拠の記録を維持する。専任なしは責務の省略ではない。自己レビューや設計責任者の検証は、実装者と独立したコードレビュー（最低1体）の代わりにならない。担当が未完了、必須検証が失敗した場合はその状態を報告し、確認済みと偽らない。重大な未解決事項を完了にしない。

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

@@ -0,0 +1,61 @@
+# dev の工程（Managed Agents）
+
+Claude Code の dev の工程を、Managed Agents のセッション向けに絞ったもの。役割・人数は[実装体制の判断](staffing.md)に従って作業ごとに決め、担当の委任・継続・作業先・出力は[起動手順](launch.md)に従う。
+
+## 役割と継続
+
+下の表は必須起動一覧ではない。
+
+| 工程 | 役割定義 | 継続と責任 |
+| --- | --- | --- |
+| Phase 3・4・6・7 | `shinaps-architect` | 担当1は設計・統合・設計適合性を継続。担当2以降は独立設計と追加確認のみ |
+| Phase 4 | `shinaps-plan-reviewer` | 修正版の再確認も同じ担当 |
+| Phase 4・6 | `shinaps-simplifier` | 計画の再確認は継続。実装の簡素化は別担当 |
+| Phase 5・7 | `shinaps-implementer` | 1体。同じ担当へ修正を返す |
+| Phase 6 | `shinaps-reviewer` | 実装担当とは別。レビューラウンドごとに新規。規約照合も担う |
+
+- 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版を依頼に渡す。実装担当にはファイルの所有範囲を明記する。
+- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませない。対象を編集中にレビューせず、全結果が揃うまで lead と実装担当も対象を変えない。
+- 起動失敗・空回答・未確認範囲を「指摘なし」にしない。
+
+## Phase 1: タスクと初期体制
+
+初回メッセージの必須入力が揃っていることを確かめ、目的・受入条件・範囲を確定する。作業先を[起動手順](launch.md)に従って用意し、関連コードと検証方法を必要な範囲だけ確認して初期体制を決め、作業記録に残す。
+
+## Phase 2: 規約と必要な探索
+
+規約の範囲は [SKILL.md の規約](../SKILL.md#規約)に従う。lead が読んで以降の担当へ全文を渡す。lead（設計担当がいれば設計担当も）が関連ファイルを確認し、実装担当は実装の詳細を調べる。探索の専任は委任しない。
+
+## Phase 3: 設計と計画
+
+設計責任者は設計担当1、専任なしなら lead とする。計画には目的・不変条件・変更範囲（対象ファイルと責務）・実装順・検証を書く。設計担当が複数なら同じ入力で独立に検討させ、担当1が根拠で一つの案へ統合する。
+
+## Phase 4: 計画の確認
+
+選んだ計画レビュー・計画簡素化の担当へ同じ計画を渡し、指摘を「指摘の検証と統合」に従って扱う。同じ対象について初回を1として最大2ラウンドとする。上限到達後に計画を修正した場合は、未再確認の変更と残課題を記録する。重大な設計リスク、仕様・許可の未決事項、必要な担当の未完了があれば Phase 5 へ進まず未完了で返す。
+
+## Phase 5: 実装と検証
+
+実装担当1体へ確定計画・必読ファイル・規約全文・所有ファイル・必要な検証を渡す。実装担当は計画を実装し、簡素化・セルフレビュー・必須検証を行う。実装ミスによる検証失敗の自己修正は3回まで。lead は報告だけで完了とせず、差分と検証の根拠を確認する。
+
+## Phase 6: 実装後の確認
+
+同じ差分を固定し、選んだ担当を並行して委任する。実装者と独立したコードレビューは最低1体。設計適合性は設計担当1（専任なしなら lead）、規約照合はコードレビュー担当、実装の簡素化は選んだ simplifier（専任なしなら実装担当とコードレビュー担当）が確認する。staged・unstaged・untracked を含めて対象を特定する。
+
+## 指摘の検証と統合（Phase 4・6）
+
+設計責任者（設計担当1、専任なしなら lead）が全指摘の根拠・誤認・重複・対立・未確認を区別し、全項目の採否と理由、必要な修正と検証をまとめる。再現・検証が必要なら実装担当へ依頼する。仕様・受入条件の変更や許可範囲の拡大は利用者の合意前に採用しない。
+
+## Phase 7〜8: 修正と終了判定
+
+修正指示を同じ実装担当へ返す。実装後の全体レビューは初回を1として最大2ラウンド。2回目の後に修正したら必要なテストを行い、最終差分が再レビューされていないことを報告する。重大な未解決事項、必須検証の失敗、必要な担当の未完了が残れば品質上の完了とは報告しない。
+
+## Phase 9: コミット・push・draft PR と報告
+
+1. コミット単位を依存順に確定する。stage は合意した範囲のパスだけにし、作業記録やその他のファイルを含めない。
+2. 許可された場合だけ commit する。
+3. 許可された場合だけ head ブランチへ push する。
+4. 許可された場合だけ draft PR を作る。
+5. [起動手順](launch.md)の出力を置き、状態行と SKILL.md の最終報告を書く。
+
+許可されていない操作はその手前で止め、行わなかった操作を最終報告に書く。

package/plugins/shinaps-codex/references/linear/configuration.md

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.33.2のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.33.2`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.34.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.34.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
 
 ```sh
 shinaps-skills --version

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

@@ -0,0 +1,59 @@
+# Claude Managed Agents の設定
+
+作業先リポジトリの `.shinaps/managed.json` に置く。`config_version: 1` のJSONで、[JSON Schema](configuration.schema.json)を契約の正本とする。
+
+設定が持つのは、共通定義のコピーの置き場所・対象リポジトリ・GitHub MCP の資格情報を登録した vault だけである。許可・予算・Issueの範囲・base と head・終了条件は呼び出しのたびに利用者と合意して決め、設定には書かない。lead・役割・環境のリソース ID は lock から読み、設定には書かない。vault は lock に記録されないため、`vault_id` だけを設定に持つ。秘密値は書かない。schema は未知のキーを拒否するので、許可や予算などのキーを書いた設定は検証で失敗し、許可や予算として扱われることはない。
+
+認証は `ant` の既存のログイン（利用者本人が `ant auth login` を行う）と環境変数、GitHub MCP は vault の資格情報を使う。
+
+## 配置
+
+| パス | 内容 |
+| --- | --- |
+| `.shinaps/managed.json` | この設定 |
+| `<definitions>/agents/`・`environments/`・`skills/` | plugin の `managed-agents/` からコピーした共通定義。テンプレートの所有で、更新時は丸ごと置き換える |
+| `<definitions>/claude-lock.json` | `ant apply` が記録するクラウド上のリソースの ID と版 |
+
+いずれも Git 対象外にする。`.shinaps/.gitignore` が `*` で始まる場合は追加の設定なしで除外される。書き込む前に `git check-ignore --no-index -v <パス>` で除外を確認する。除外されていなければ、[導入の手順](setup.md#1-設定を読む)に従って既存の規則と共有例外を保ったまま `.shinaps/.gitignore` に必要な行だけを加えてから書き込む（新規作成の内容は[作業記録の共通手順](../work-records.md)と同じ）。`<definitions>` をリポジトリの外に置く場合は Git の対象にならないので、この確認は `.shinaps/managed.json` だけに行う。
+
+## 項目
+
+全項目が必須で、`$schema` だけは省略できる。
+
+| キー | 内容 |
+| --- | --- |
+| `$schema` | 任意のエディタ補助。CLI はこの URL を取得しない |
+| `config_version` | `1` |
+| `definitions` | 共通定義のコピーと lock を置くディレクトリ。リポジトリのルートからの相対パス、または絶対パス。clone のやり直し・worktree・`git clean` の影響を避けたい場合は、リポジトリの外の絶対パスにする。同じマシンの同じ組織で複数のリポジトリから使う場合は、全リポジトリの `definitions` に同じ絶対パスを指定し、lock を 1 つにする。別のマシンでは[lock の扱い](#lock-の扱い)に従う |
+| `repository.url` | セッションにマウントする GitHub リポジトリの URL |
+| `repository.mount_path` | セッション内のマウント先（例 `/workspace/widgets`） |
+| `vault_id` | GitHub MCP の資格情報を登録した vault の ID。未登録なら `null` |
+
+## 検証
+
+利用中の 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 を更新する。
+
+## 設定例
+
+```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",
+  "repository": {
+    "url": "https://github.com/acme/widgets",
+    "mount_path": "/workspace/widgets"
+  },
+  "vault_id": null
+}
+```
+
+## 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-codex/references/managed/configuration.schema.json

@@ -0,0 +1,47 @@
+{
+  "$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",
+  "type": "object",
+  "properties": {
+    "$schema": {
+      "type": "string"
+    },
+    "config_version": {
+      "type": "integer",
+      "const": 1
+    },
+    "definitions": {
+      "type": "string",
+      "minLength": 1
+    },
+    "repository": {
+      "type": "object",
+      "properties": {
+        "url": {
+          "type": "string",
+          "minLength": 1
+        },
+        "mount_path": {
+          "type": "string",
+          "minLength": 1
+        }
+      },
+      "required": ["url", "mount_path"],
+      "additionalProperties": false
+    },
+    "vault_id": {
+      "anyOf": [
+        {
+          "type": "string",
+          "minLength": 1
+        },
+        {
+          "type": "null"
+        }
+      ]
+    }
+  },
+  "required": ["config_version", "definitions", "repository", "vault_id"],
+  "additionalProperties": false
+}

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

@@ -0,0 +1,116 @@
+# 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) に従って決めるので、ここでは指示しない。
+
+## 呼び出し時に合意する入力
+
+設定からは読まず、依頼のたびに利用者と合意する。
+
+- 必須: base ブランチとその SHA、head ブランチ、範囲と受入条件、許可（commit・head への push・draft PR の作成のうち明示されたもの）、予算（USD のセント単位）
+- 任意: 必須検証のコマンド、コミットの author、利用者 CLAUDE.md の添付
+
+設定から読むのは `definitions`（lock の場所）・`repository`・`vault_id` だけで、lead と環境の ID は lock から読む（[設定](configuration.md)）。許可と予算は合意した内容だけで、会話の途中で増やさない。
+
+## 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 の作成を含まない依頼だけは続けられる。
+
+## 2. セッションを作る
+
+合意済みの依頼があるときだけ作る。この手順を読んだことを理由に作らない。
+
+GitHub の token は対象リポジトリだけに限った fine-grained token にし、Contents と Pull requests の write だけを許可する。merge できるかは GitHub のブランチ保護で決まるので、base を保護しておく。token は `read -rs` で画面に出さずに受け取り、サンドボックス・作業記録・チャットに書かない。
+
+次はひな形で、`<...>` を設定と合意した入力で埋める。`vault_id` が `null` なら `--vault-id` の行を除く。
+
+```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: <ブランチ名>
+          範囲と受入条件: <内容>
+          許可: <commit・headへのpush・draft PRの作成のうち許可するもの>
+          予算: <金額>
+          必須検証（任意）: <コマンド。省略時はリポジトリの規約に従う>
+          author（任意）: <name> <email>
+YAML
+unset GITHUB_TOKEN
+```
+
+- `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` に置かれる）。
+
+## 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行目が `状態: 完了`・`状態: 質問`・`状態: 未完了` のどれかを読む。
+
+## 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) の本文と同じ構造）。
+
+  ```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
+  ```
+
+  同じ内容は `--event.type user.message --event.content '<content の JSON 配列>'` のフラグでも渡せる。回答の送信は、依頼が進行中のセッションに対してだけ行う。
+- 回答で新しい許可・予算を加えない。必要なら新しい依頼として合意し直す。
+- `user.tool_confirmation` は利用者の明示の指示なしに送らない。
+
+## 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 に対して適用して、範囲と受入条件に対する差分を確かめる。
+- `コミット:` と 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 は呼び出し元が別に行う。
+
+## 未検証の境界
+
+- マウントしたリポジトリの 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 仕様で確かめただけで、実際のセッションではまだ送っていない。出力ファイルの一覧と取得は既存のセッションで確かめた。

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

@@ -0,0 +1,72 @@
+# Managed 構成の導入と更新
+
+共通の dev 構成（lead `shinaps-dev-managed-cc`、dev の5役割、skill `dev-managed-cc`、環境 `shinaps-dev`）を利用者の組織へ導入・更新する手順。既存の lock を使い、同じリソースを重複して作らない。セッションの作成・予定実行は行わない。dev の工程は [skill `dev-managed-cc`](../../managed-agents/skills/dev-managed-cc/SKILL.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)）
+
+## 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. 安全上の注意を示す
+
+適用の合意を求める前に、次を利用者へ示す。
+
+- 環境のネットワークは制限しない（`unrestricted`）。bash と GitHub MCP の3ツール（`get_me`・`create_pull_request`・`pull_request_read`）は承認なし（`always_allow`）で動く。無人のセッションが承認待ちで止まらないようにするため。
+- サンドボックスのコードは外部へデータを送れる。取得した内容に書かれた指示に従ってしまう危険（プロンプトインジェクション）がある。
+
+## 4. 計画を確認する
+
+```sh
+(cd <definitions> && ant apply --dry-run .)
+```
+
+サブシェルで `<definitions>` に移動してから実行する。lock は実行した場所から上へ探され、キーは lock のディレクトリからの相対パスになるため。
+
+- 出力の `Preview` 行が `./claude-lock.json`（`<definitions>` 直下）であることを確かめる。違えば止める。別の場所の lock を `--lock-file` で指定しない。キーの基準がずれて重複作成につながる。
+- lock があれば、計画は定義を変えたリソースの update と、それ以外の unchanged になる。lock にあってソースの無い項目は警告として残る。`--prune` は付けない。
+- 次の場合は適用せずに止めて報告する: `This plan cannot be applied` が出る、lock があるのに create がある、意図しない環境の更新がある。
+- lock が無く create を含む場合は、`ant beta:agents list --beta managed-agents-2026-04-01` と `ant beta:environments list --beta managed-agents-2026-04-01` で同じ名前の lead・役割・環境が既にあるかを確かめる。あれば止めて、lock を戻す方法を利用者と相談する。同じマシンで同じ組織に導入済みなら、その `<definitions>` を指すよう設定を直してやり直す。別のマシンでは[lock の扱い](configuration.md#lock-の扱い)に従い、バックアップや以前の置き場所から lock を戻し、無ければ相談する。
+
+## 5. 適用する
+
+利用者が dry-run の計画に合意してから実行する。
+
+```sh
+(cd <definitions> && ant apply .)
+```
+
+`ant apply` は計画を表示して承認を求める。確認した計画と同じ内容の適用を利用者が明示的に許可している場合は `--yes` を付けて、同じ範囲の承認を繰り返さない。計画が変わっていれば `--yes` を付けずに止める。`--prune`・`--force` は使わない。リソースを削除しない。
+
+## 6. 結果を確かめる
+
+- もう一度 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>` を使う。セッションは作らない。
+
+## GitHub MCP の vault を準備する
+
+lead の GitHub MCP（`https://api.githubcopilot.com/mcp`）は、セッション作成時に渡す vault の資格情報で認証する。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` に書く。
+
+token をチャット・設定・作業記録に貼らない。資格情報の登録ができたことと、セッションで push・draft PR の作成が動くことは別に報告する。後者は[依頼の手順](execute.md#未検証の境界)の未検証の境界にあたる。
+
+## 報告
+
+作成・更新・変更なしのリソース、lock の差分、示した安全上の注意、確かめられなかった事項を報告する。作業記録は `.shinaps/work/` に置く。

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

@@ -0,0 +1,18 @@
+---
+name: managed-execute
+description: 作業先の Managed 設定を読み、Claude Managed Agents の lead へ dev を依頼し、観測・質問の取り次ぎ・成果物と draft PR の確認を行う。dev の工程自体は lead に任せる。依頼があるときに使う。
+---
+
+## 作業記録の保存先
+
+作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
+
+# Managed Agents へ依頼する
+
+[設定](../../references/managed/configuration.md)と[依頼と観測の手順](../../references/managed/execute.md)を読んで進める。
+
+- 呼び出しのたびに base ブランチと SHA・head ブランチ・範囲と受入条件・許可・予算を利用者と合意する。設定・lock・過去の作業から推定しない。
+- 設定から読むのは `definitions`（lock の場所）・`repository`・`vault_id` だけで、lead と環境の ID は lock から読む。lock が無ければ止め、導入は managed-setup で行う。
+- 計画・実装・レビューの工程と体制は lead に任せ、ここでは指示しない。
+- Linear の進行とは独立した入口である。merge・deploy・release・Issue の更新・セッションのアーカイブは行わない。
+- 秘密値を表示・記録しない。

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

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