@shinaps/skills 0.33.2 → 0.34.1

package/plugins/shinaps-claude/references/linear/workflow.md

@@ -5,8 +5,8 @@
 | 担当 | 責務 |
 | --- | --- |
 | Codex（進行役） | Issueの作成・整理、仕様相談、Ready判定、依存・Cycle管理、進行判断、作業先設定からの経路と許可の確定、体制判断の材料（受入条件・関連範囲・既存検証・リスク）の提示、Claudeへの依頼（auto: CLI、manual: Bridge）、Local・Staging・ProductionのAgent QA、単位・全体の照合、許可されたpush・PR・merge・配備・公開、Issueへの記録、人への依頼 |
-| Claude（実装担当・Claude Code） | 初期体制の決定と途中の増員、`shinaps:dev-claude` による技術調査・計画・実装・検証・独立レビュー、QA指摘の修正、`shinaps:commit`（auto: 独立レビュー後にcommit、manual: 提示・相談・人の単位承認後にcommit）、結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
-| 人 | 未合意の仕様・権限の判断、manualの単位レビュー・修正相談・承認、本人の操作が必要な認証等、必要なHuman QA |
+| Claude（実装担当・Claude Code） | 初期体制の決定と途中の増員、`shinaps:dev-claude` による技術調査・計画・実装・検証・独立レビュー、QA指摘の修正、`shinaps:commit`（auto: 独立レビュー後にcommit、manual: 人の開始依頼で分割案、人が依頼した単位ごとにcommit）、結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
+| 人 | 未合意の仕様・権限の判断、manualのWebStormでの差分レビュー・修正相談・コミットの開始と単位ごとの依頼、本人の操作が必要な認証等、必要なHuman QA |
 
 経路は着手時に通常設定の `review_flow.mode` で決まる（[経路](configuration.md#経路)）。autoはCodexが[ローカルClaude CLI](claude-cli.md)の同じsessionをresumeし、manualはWebStorm内の対話Claude Codeセッションへ[Bridge](bridge.md)で依頼する。どちらでもClaudeはdev内レビューと検証を終えて結果を返し、CodexがLocal Agent QAを行う。Claudeの報告をQA合格の根拠にせず、この引き渡しを進行全体の終了と扱わない。
 
@@ -23,8 +23,8 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 | 工程 | 状態キー | 内容と次へ進む条件 |
 | --- | --- | --- |
 | 着手 | `ready` | Readyと依存を確認し、作業先設定を読み、通常設定の `review_flow` から経路と必要な許可（auto: `claude_cli`、manual: `bridge_request`）を確定する。checkout・branch・HEAD・既存差分を固定し、体制判断の材料を添えてClaudeへ依頼する。通常設定がautoでmanualのパス別ルールがあれば、起こり得る停止（[経路](configuration.md#経路)）を依頼に書く |
-| 実装 | `coding`, `local_agent_qa` | Claudeのメインが初期体制を決めて報告し、`shinaps:dev-claude` で実装・検証・独立レビューを行い、未コミット差分・単位案・予定差分・判定記録を返す。CodexがLocal Agent QA（判定記録と経路の整合を含む）を行い、不合格なら同じsessionへ戻す |
-| 差分確定 | `code_review` | QA合格後、Codexが実効flow・判定記録・QA結果を同じsessionへ渡し、Claudeが `shinaps:commit` を行う。autoは単位ごとに独立レビュー後にcommitする。manualは退避・stage・提示、相談・修正、人の明示承認の後にcommitする。Codexは各コミットの単位照合と全体照合を行う。差分確定中の修正は単位の目的・範囲内に限り、超えるものは実装へ戻す。差分確定で差分が変わったIssueは、確定後にCodexのAgent QAを必須にする（公開確認のpush前の最終Agent QAで兼ねてよい） |
+| 実装 | `coding`, `local_agent_qa` | Claudeのメインが初期体制を決めて報告し、`shinaps:dev-claude` で実装・検証・独立レビューを行い、未コミット差分・単位案・予定差分・判定記録を返す。manualでは人へユーザーのレビュー待ちと明示する。CodexがLocal Agent QA（判定記録と経路の整合を含む）を行い、不合格なら同じsessionへ戻す |
+| 差分確定 | `code_review` | QA合格後、Codexが実効flow・判定記録・QA結果を同じsessionへ渡し、Claudeが `shinaps:commit` を行う。autoは単位ごとに独立レビュー後にcommitする。manualではCodexはcommitを依頼せず、渡した後は報告を待つ。人のコミット開始依頼でClaudeが分割案を示し、人が単位ごとに依頼したcommitを行う。Codexは各コミットの単位照合と全体照合を行う。差分確定中の修正は単位の目的・範囲内に限り、超えるものは実装へ戻す。差分確定で差分が変わったIssueは、確定後にCodexのAgent QAを必須にする（公開確認のpush前の最終Agent QAで兼ねてよい） |
 | 公開確認 | `post_commit`, `staging_agent_qa`, `staging_human_qa`, `release`, `production_agent_qa`, `production_human_qa` | 受入条件と許可に応じて必要なものだけ行う: push前の最終Agent QA、push・PR作成、環境配備とStaging/ProductionのAgent QA、必要なHuman QA、merge・配備・公開。適用しない項目は理由を記録する |
 | 結果報告 | （状態キーなし） | 結果・証拠・省略した工程と理由・残項目をIssueへ記録し、終了地点に到達する。必須受入条件をすべて満たしたIssueは `done` にする |
 
@@ -60,7 +60,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 | Codexから許可範囲と受入条件を伴う実装・修正の依頼を受けた | Claudeは人へ着手を再確認せず、指定されたスキルで実行する |
 | devの入口の中で計画上の判断が必要になった | autoはClaudeがresultでCodexへ相談し、Codexは既存の合意で判断できれば回答する。manualはClaudeが人へ直接確認し、決定を報告する |
 | QAで受入条件の範囲内の不具合が見つかった | Codexが同じClaude sessionへ修正を依頼し、Claudeは人の着手許可を改めて取らずに修正する。Codexが再検証する |
-| ClaudeがCLIのresultでcommitの完了を、またはBridgeで人の承認とcommitの完了を報告した | Codexは人に同じ事実を聞き直さず、報告の対象とGitの状態を照合して次の工程へ進む |
+| ClaudeがCLIのresultでcommitの完了を、またはBridgeで人の依頼によるcommitの完了を報告した | Codexは人に同じ事実を聞き直さず、報告の対象とGitの状態を照合して次の工程へ進む |
 | 次の操作の継続的な許可があり、必要な工程の結果が揃った | Codexは「進めてもよいか」を再質問せずに実行する |
 | Cycle全体を任され、対象Issueが設定された終了地点に達した | Codexは開始時に確定した対象と順序を照合し、その範囲の次のIssueへ進む |
 
@@ -72,9 +72,9 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 1. Claudeは成果引き渡しに、モードによらず自然な責務で決めたコミット単位案と予定差分を含める。CodexはLocal Agent QAで対象を検証し、単位案が依頼全体を漏れなく覆い対象外変更を含まないことと、各単位の[判定記録](configuration.md#判定記録と変更時の扱い)を確認する。依頼の比較元と全体差分も最終照合用に記録する。判定記録に経路と異なるmanual単位があれば、差分確定の依頼前に[経路](configuration.md#経路)に従って人へ確認する。
 2. QA合格後、Codexは実効flow・単位の判定記録・QA結果を同じClaude sessionへ渡す。Claudeは設定・予定差分・合意根拠を照合する。
-3. Claudeは `commit` に従う。autoでは独立レビュー後にClaudeがstage・commitする。manualでは単位外を安全に退避して単位をstage・提示し、人と修正を相談し、人がその単位を承認した後にClaudeがcommitする。各コミット直前・作成後の実差分と確定した予定単位を照合し、予定単位・SHA・検証・レビュー・承認記録・復元結果をCodexへ返す。
+3. Claudeは `commit` に従う。autoでは独立レビュー後にClaudeがstage・commitする。manualでは人のコミット開始依頼で分割案を示し、人がその単位のコミットを依頼したら単位外を安全に退避して単位をstage・検証し、Claudeがcommitする。各コミット直前・作成後の実差分と確定した予定単位を照合し、予定単位・SHA・検証・レビュー・依頼記録・復元結果をCodexへ返す。
 4. 全単位完了後、Codexは各コミットの単位照合結果を実差分で独立確認したうえで、依頼の比較元からの全体差分が、`commit` の手順で正当な人の修正を反映した確定済みの全体期待差分と一致し、対象の未コミット変更が残っていないことを照合する。最終差分だけでは途中で混入し後で相殺された対象外変更を検出できないため、単位照合を省かない。人レビューを省略した単位は、上の省略記録を完成させる。
-5. 単位の組み替え・内容・設定の変更は[変更時の扱い](configuration.md#判定記録と変更時の扱い)に従って再判定し、必要なレビュー・許可確認・検証へ戻す。承認後のcommit（または人自身のcommit）の後は、`commit` に従って正当な修正と元の予定差分の対応を記録し、確定単位に更新する。確定単位と実コミットに不一致があれば次工程を止め、SHA・予定差分・実差分の違いを記録して人に確認する。履歴を無断で書き換えない。
+5. 単位の組み替え・内容・設定の変更は[変更時の扱い](configuration.md#判定記録と変更時の扱い)に従って再判定し、必要なレビュー・許可確認・検証へ戻す。人の依頼によるcommit（または人自身のcommit）の後は、`commit` に従って正当な修正と元の予定差分の対応を記録し、確定単位に更新する。確定単位と実コミットに不一致があれば次工程を止め、SHA・予定差分・実差分の違いを記録して人に確認する。履歴を無断で書き換えない。
 
 ## 待ち状態
 
@@ -90,13 +90,13 @@ manual経路の依頼・報告と、別会話との任意の進行の引き渡
 
 ## 人への依頼
 
-manualの単位の提示・相談・承認は、WebStorm内の対話Claude Codeセッションで[manualの差分提示と単位承認](../human-review.md)に従って行う。
+manualの差分レビュー・相談・コミットの依頼は、WebStormの差分表示と対話Claude Codeセッションで[manualのレビュー待ちと単位ごとのコミット](../human-review.md)に従って行う。
 
 会話でIssueリンクと必要な作業を明示し、ステータスの変更だけで依頼を済ませない。
 
 | 依頼 | 文例 |
 | --- | --- |
-| manualの単位レビュー | できるようになったことと重点確認点を添えて「[Issueリンク]の単位レビュー・承認を、WebStormのClaude Codeセッションでお願いします。」 |
+| manualのレビュー | できるようになったことと重点確認点を添えて「[Issueリンク]の差分をWebStormでレビューし、コミットはWebStormのClaude Codeセッションで依頼してください。」 |
 | Human QA | 「[Issueリンク]のHuman QAをお願いします。」 |
 | 外部対応 | 「[Issueリンク]の〇〇をお願いします。」 |
 

package/plugins/shinaps-claude/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-claude/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-claude/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-claude/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-claude/skills/commit/SKILL.md

@@ -22,11 +22,11 @@ description: 許可された差分を依存順のローカルコミットにし
 
 ## 範囲と進め方
 
-コミットは利用者の明示依頼、または[Linear共通設定](../../references/linear/configuration.md)の合意済みの許可に従う。Linear進行では[担当と工程](../../references/linear/workflow.md)の差分確定に従い、Local Agent QA後に進行役から対象を指定した依頼を受けて行う。単独の依頼にはLinear進行や新しいゴールを必須にしない。
+コミットは利用者の明示依頼、または[Linear共通設定](../../references/linear/configuration.md)の合意済みの許可に従う。Linear進行では[担当と工程](../../references/linear/workflow.md)の差分確定に従い、Local Agent QA後に進行役から対象を指定した依頼を受けて行う。manualでは進行役はcommitを依頼せず、QA結果と判定記録の引き渡しの後に人の依頼で行う。単独の依頼にはLinear進行や新しいゴールを必須にしない。
 
 どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。
 
-Git準備・修正・commitはAIが現在のセッションで行い、manualのレビュー・承認は人が行う。autoは独立レビューを必須とする。必要な担当・許可が利用できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
+Git準備・修正・commitはAIが現在のセッションで行い、manualのレビューとコミットの依頼は人が行う。autoは独立レビューを必須とする。必要な担当・許可が利用できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
 
 ## 回復できる状態を作る
 
@@ -43,23 +43,23 @@ Git準備・修正・commitはAIが現在のセッションで行い、manualの
 
 予定単位ごとに、[パス別の方針](../../references/linear/configuration.md#パス別の方針)でそのコミットの全変更を判定し、同資料の判定記録を残す。Linear進行から記録を受け取った場合は、設定とその単位の予定差分（内容・mode等を含む）の一致を確認して引き継ぐ。単独の依頼でも同じ判定を使い、Linear専用の工程は追加しない。設定が真にない単独依頼では、今回の明示許可とプロジェクト規約を通常方針とし、パス例外は適用しない。
 
-合意済みの実効 `review_flow` と今回の明示指示から進め方を確定する。両方とも対象のstageとAIのcommitを許可し、`auto` では独立レビュー後、`manual` では人の単位承認後にAIがcommitする。設定の存在だけを合意と扱わない。旧キー・不備・競合は共通設定に従って止める。
+合意済みの実効 `review_flow` と今回の明示指示から進め方を確定する。両方とも対象のstageとAIのcommitを許可し、`auto` では独立レビュー後、`manual` では人がその単位のコミットを依頼した後にAIがcommitする。設定の存在だけを合意と扱わない。旧キー・不備・競合は共通設定に従って止める。
 
-設定がない単独依頼でも「各単位をAIがレビューして自動コミット」「単位ごとに見せて承認後にコミット」など明確な意図を引き継ぐ。「コミットして」「進めて」だけからautoを推測しない。flowが未解決のときだけ対象を示し「auto（AIがレビュー・コミット）とmanual（人がレビュー・承認し、AIが修正・コミット）のどちらで進めますか？」と一問聞き、回答まで依存操作を待つ。未回答を承認と扱わない。同じ依頼内でもパス例外により異なるflowの単位があってよい。
+設定がない単独依頼でも「各単位をAIがレビューして自動コミット」「人がレビューしてから単位ごとにコミット」など明確な意図を引き継ぐ。「コミットして」「進めて」だけからautoを推測しない。flowが未解決のときだけ対象を示し「auto（AIがレビュー・コミット）とmanual（人がレビューして単位ごとにコミットを依頼し、AIが修正・コミット）のどちらで進めますか？」と一問聞き、回答まで依存操作を待つ。未回答を承認と扱わない。同じ依頼内でもパス例外により異なるflowの単位があってよい。
 
 モード決定後にレビュー可能性や依存関係のため単位を分割・統合する場合は、[変更時の扱い](../../references/linear/configuration.md#判定記録と変更時の扱い)に従って変更した単位を再判定し、必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。「autoだからまとめる」「manualだから分ける」を先に適用して単位決定と判定を循環させない。
 
 ## 単位ごとの検証・レビュー・コミット
 
-manualでは[manualの差分提示と単位承認](../../references/human-review.md)に従い、人と対話できるセッションで提示・相談・承認を受ける。ローカルClaude CLIの非対話実行でmanualの単位を検出した場合は、手順を進めず、判定を記録してresultへ返す（[経路](../../references/linear/configuration.md#経路)）。
+manualでは[manualのレビュー待ちと単位ごとのコミット](../../references/human-review.md)に従い、人と対話できるセッションで人の依頼を受ける。手順1は人のコミット開始依頼の後に、手順2以降は人がその単位のコミットを依頼した後に行う。ローカルClaude CLIの非対話実行でmanualの単位を検出した場合は、手順を進めず、判定を記録してresultへ返す（[経路](../../references/linear/configuration.md#経路)）。
 
 以下を、その単位のモードで行う。
 
 1. 単位案を短く示す。manualで複数の単位に分ける場合、許可された独立レビュアーがいれば、各単位の差分だけで人が妥当性を判断できるかを差分自体から確認させ、結論はメインが実際の差分で検証する。autoでは単位案の独立レビューを求めない（プロジェクトの必須条件にある場合は従う）。
 2. コミットと検証の内容が単位だけで決まるようにする。manualでは、単位以外の未コミット変更（対象外、後続の単位、untracked）を一意な名前のstashへ退避し、作業ツリーとindexに単位の変更だけを残す。autoでは、対象外の変更を作業ツリーとindexに残してよく、検証結果が残る変更に依存しないことを根拠（例: 残る変更が検証の入力に含まれない）とともに判断する。依存する、または判断できない場合は、許可された範囲で単位をまとめ直すか、manualと同じ方法で退避する。退避が他の進行中の作業（他のセッションや人がステージ・編集中の変更）を妨げる場合は退避せず、所有者と調整できるまで止める。manualは別の隔離方法へ置き換えない。退避するときは、stashのindexにコミット対象のステージ済み変更を入れない。`git stash push` はパスを指定してもindex全体を保存し、対象のステージ済み変更が入ると後の `git stash apply --index` が失敗するため。対象のステージ済み差分のパッチを保存し、対象のステージを外してから退避し、退避後にそのパッチで対象のステージを戻す。作成前後のstash一覧を比べて今回作成されたものだけのSHAを記録し、既存stashの先頭を自分のものと決めつけない。共有ファイルのhunk分割は控えから行い、対象のhunkだけのステージを外せない場合や、対象外のステージ済みの変更が変わる場合は止める。
 3. コミットする内容に必要な検証を行う。後続や対象外の未コミット変更に依存した成功を、その単位の検証としない。範囲を限った検証はプロジェクトが認める場合だけ使い、必須検証を省かない。後続や対象外への依存で失敗するなら、手順2に戻って単位か隔離を見直す。
-4. 対象だけをステージし、実際にコミットされる差分の全体（indexのままコミットする場合は完全なcached diff）と影響するファイルをレビューする。indexに対象外の変更を残す場合は、それを含めずに対象だけをコミットする方法を使い、対象を限定できなければ止める。manualで提示する差分は、コミットされる差分と同じものにする。指摘は実物で確認し、依頼範囲の修正後は再ステージ・再検証する。外部仕様の調査は変更がそこに依存するときに行う。
-5. 必須検証と独立レビュー（auto必須）が通り、阻害指摘がないことを確認する。autoでは直前の全差分が予定単位と一致してからAIが `git commit` を単独実行する（`git add` と連結しない）。manualでは単位の差分・理由・検証結果・推奨メッセージを提示し、提示時の `git write-tree` を記録する。人との相談で修正したら再stage・再検証・再提示する。人がその単位を明示的に承認したら、直前のindexのtreeが承認したtreeと一致することを確認してAIが `git commit` を単独実行し、作成したコミットのtreeも照合する。承認後に単位のパスで作業ツリーまたはindexが変わったら承認は失効し、再提示・再承認する。承認はその単位にだけ及ぶ。commit後に（人自身のcommitを含む）、比較元からの実コミット一覧と各SHA・全差分を調べ、相談で行った修正が許可された目的・範囲を満たすことを確認する。実差分で実効flowを再判定し、影響する挙動を再検証する。正当な人の修正は確定単位と全体の期待差分へ反映し、元の予定差分・承認記録・変更理由・実コミットとの対応を残す。意図や範囲が不明、対象外の混入、flowの適用が未解決なら人へ確認して止める。Gitにcommitがあるだけで人レビュー完了としない。各コミットを確定単位と照合してSHA・結果を記録し、不一致なら次工程を止める。履歴を無断で書き換えない。
+4. 対象だけをステージし、実際にコミットされる差分の全体（indexのままコミットする場合は完全なcached diff）と影響するファイルをレビューする。indexに対象外の変更を残す場合は、それを含めずに対象だけをコミットする方法を使い、対象を限定できなければ止める。manualで人がWebStormで確認できるstaged差分は、コミットされる差分と同じものにする。指摘は実物で確認し、依頼範囲の修正後は再ステージ・再検証する。外部仕様の調査は変更がそこに依存するときに行う。
+5. 必須検証と独立レビュー（auto必須）が通り、阻害指摘がないことを確認する。autoでは直前の全差分が予定単位と一致してからAIが `git commit` を単独実行する（`git add` と連結しない）。manualではstage時の `git write-tree` を記録し、単位名・目的・検証結果・推奨メッセージを短く示す（差分本文は貼らない）。記録時の差分が分割案の予定単位と違えばcommitせず報告して依頼を取り直す。直前のindexのtreeが記録したtreeと一致することを確認してAIが `git commit` を単独実行し、作成したコミットのtreeも照合する。treeの記録後に単位のパスで作業ツリーまたはindexが変わったら（人との相談による修正を含む）依頼は失効し、再stage・再検証・再提示して改めて人の依頼を受ける。依頼はその単位にだけ及ぶ。commit後に（人自身のcommitを含む）、比較元からの実コミット一覧と各SHA・全差分を調べ、相談で行った修正が許可された目的・範囲を満たすことを確認する。実差分で実効flowを再判定し、影響する挙動を再検証する。正当な人の修正は確定単位と全体の期待差分へ反映し、元の予定差分・依頼記録・変更理由・実コミットとの対応を残す。意図や範囲が不明、対象外の混入、flowの適用が未解決なら人へ確認して止める。Gitにcommitがあるだけで人レビュー完了としない。各コミットを確定単位と照合してSHA・結果を記録し、不一致なら次工程を止める。履歴を無断で書き換えない。
 6. 退避した場合は、コミット後または中断時に、indexにコミット対象のステージ済み変更がない状態で、記録したSHAのstashを `git stash apply --index` で戻す。中断時は対象のステージを外し、stashの復元を妨げる対象の未コミット変更（共有ファイルの対象のhunkなど）もパッチに保存して作業ツリーから一時的に外してから戻す。その後、外した対象の変更を戻し、対象のステージ済み差分のパッチで対象のステージを戻す。復元前に人が修正した最新のHEAD・作業ツリー・indexを記録して保全する。控えで扱った対象外変更だけを復元し、古い対象パッチで人の修正を上書きしたり、コミット済みの変更を再び加えたりしない。退避の有無によらず、コミットしていない変更（ステージ済み・未ステージ・untracked）と既存stashが、操作前の記録と確定済みの人の修正からコミットした内容を除いたものと一致することを確認する。一致しない、曖昧な競合がある、ステージ境界を戻せない場合は推測で消さず、一致しないパスと、退避した場合は回復資料を示して止める。一致を確認してから今回作成したstashだけをdropし、HEADを確認して次へ進む。
 
 全単位の完了後、各単位の照合結果に加え、元の比較元からの全体差分が、人の正当な修正を反映した確定済みの全体期待差分と一致し、対象の未コミット変更が残っていないことを確認する。最終差分だけで途中コミットの照合を代用しない。予定どおりのコミットによる残差分の減少は不一致と扱わない。

package/plugins/shinaps-claude/skills/linear-execute/SKILL.md

@@ -12,7 +12,7 @@ Claudeは実装担当で、Codexが進行・Agent QA・Issueの記録・人へ
 経路は着手時に通常設定の `review_flow.mode` で決まり、Issueの途中で切り替えない（[経路](../../references/linear/configuration.md#経路)）。
 
 - auto: Codexが起動する[ローカルClaude CLI](../../references/linear/claude-cli.md)で依頼を受け、質問・障害・完了はresultへ返す。回答・修正・コミットの依頼は同じsessionのresumeで受ける。
-- manual: WebStorm内の対話Claude Codeセッションで[Bridge](../../references/linear/bridge.md)の依頼を受ける。人と直接作業し、計画上の判断・仕様の不明点は人へ `AskUserQuestion` で一問ずつ確認する。完了・障害・人の承認とcommitの完了は、Bridgeで依頼元のCodexへ報告する。
+- manual: WebStorm内の対話Claude Codeセッションで[Bridge](../../references/linear/bridge.md)の依頼を受ける。人と直接作業し、計画上の判断・仕様の不明点は人へ `AskUserQuestion` で一問ずつ確認する。作業の完了時は人へユーザーのレビュー待ちと明示する（[manualの手順](../../references/human-review.md)）。完了・障害・人の依頼によるcommitの完了は、Bridgeで依頼元のCodexへ報告する。
 
 ## 読む資料
 
@@ -29,12 +29,12 @@ Claudeは実装担当で、Codexが進行・Agent QA・Issueの記録・人へ
 - devの入口の委託（サブエージェント）は、依頼の許可範囲に `dev_delegation` が書かれている場合だけ使う。worktreeの作成は含まない。
 - QAで見つかった不具合の修正依頼も同じ扱いにし、人の着手許可を改めて取らない。
 - 同じ作業ツリーをCodexや人と同時に編集しない。人や他のAIの変更を保持する。
-- コミットの許可は[共通設定](../../references/linear/configuration.md)、担当とQA後の条件は[担当と工程](../../references/linear/workflow.md)の差分確定に従う。実装完了の直後に先行してコミットせず、Codexへ結果を返す。差分確定の依頼を受けたら `shinaps:commit` を使い、許可済みの操作を再確認しない。
+- コミットの許可は[共通設定](../../references/linear/configuration.md)、担当とQA後の条件は[担当と工程](../../references/linear/workflow.md)の差分確定に従う。実装完了の直後に先行してコミットせず、Codexへ結果を返す。autoはCodexから差分確定の依頼を受けたら、manualは人がコミットの開始を依頼したら `shinaps:commit` を使い（単位の退避・stage・commitはQA結果の引き渡し後）、許可済みの操作を再確認しない。
 
 ## 結果と人の対応を報告する
 
-- 完了の報告と、人の承認・commit完了の報告に含める項目は、経路の資料に従う。
-- 人がClaudeへ直接伝えた指示・決定・承認は保持し、Codexへ報告する。Gitにコミットがあるだけで、人の承認済みと報告しない。設定で人のレビューを省略した単位は、省略と報告する。
+- 完了の報告と、人の依頼とcommitの報告に含める項目は、経路の資料に従う。
+- 人がClaudeへ直接伝えた指示・決定・コミットの依頼は保持し、Codexへ報告する。Gitにコミットがあるだけで、人の依頼によるcommitと報告しない。設定で人のレビューを省略した単位は、省略と報告する。
 
 ## Codexの依頼なしで起動された場合
 

package/plugins/shinaps-claude/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-claude/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 から許可・予算を推定しない。秘密値を表示・記録しない。

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

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