@shinaps/skills 0.33.2 → 0.34.1

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

@@ -12,7 +12,7 @@ Issueの責務・受入条件・ステータスを、実際の成果と一致さ
 着手時に作業先設定の通常の `review_flow.mode` で経路を決め、Issueの途中で切り替えない（[経路](../../references/linear/configuration.md#経路)）。
 
 - auto: [ローカルClaude CLI](../../references/linear/claude-cli.md)を起動し、質問への回答・修正・差分確定を同じsessionのresumeで依頼する。許可は `claude_cli`。
-- manual: WebStorm内の対話Claude Codeセッションへ[Bridge](../../references/linear/bridge.md)で依頼する。人とClaudeの作業中は同じIssueへ指示を送らず、報告を待つ。許可は `bridge_request`。
+- manual: WebStorm内の対話Claude Codeセッションへ[Bridge](../../references/linear/bridge.md)で依頼する。人とClaudeの作業中は同じIssueへ指示を送らず、報告を待つ。QA合格後もcommitを依頼せず、QA結果と判定記録を渡して人の依頼によるcommitの報告を待つ。許可は `bridge_request`。
 
 体制判断の材料（受入条件・関連範囲・既存検証・リスク）を依頼に添える。初期体制はClaudeのメインが決めて報告する。
 
@@ -22,7 +22,7 @@ Issueの責務・受入条件・ステータスを、実際の成果と一致さ
 
 開発進行には作業先の明示された設定と `issue_update`、経路の許可が必要（[configuration.md](../../references/linear/configuration.md) の「許可」）。設定の許可・`stop_after` を超えない。Issue未作成の明示的な実装依頼は共通の紐づけ手順でIssueを作って続けられるが、仕様が未決なら `shinaps:linear-plan` へ整理を戻す。
 
-実行には対象と終了条件を持つゴールの設定成功が必須。環境が明示許可を要求する場合は、既存の依頼で満たされるか確認し、なければ開始前に一度確認する。ゴール未設定のまま実装へ進まない。Claudeの作業・manualの単位承認・Human QA待ちは予定された工程として待機する。スキルの実行だけで予約実行・定期監視は開始しない。人への確認は会話で一問ずつ行う。
+実行には対象と終了条件を持つゴールの設定成功が必須。環境が明示許可を要求する場合は、既存の依頼で満たされるか確認し、なければ開始前に一度確認する。ゴール未設定のまま実装へ進まない。Claudeの作業・manualの人のレビュー・コミットの依頼・Human QA待ちは予定された工程として待機する。スキルの実行だけで予約実行・定期監視は開始しない。人への確認は会話で一問ずつ行う。
 
 ## 設定と補足を読む
 
@@ -42,4 +42,4 @@ Issueの責務・受入条件・ステータスを、実際の成果と一致さ
 | QAの実施・記録・素材 | [references/qa.md](../../references/linear/qa.md) |
 | Cycle完了QA・報告 | [references/cycle-report.md](../../references/linear/cycle-report.md) |
 
-コミットはClaudeへ差分確定を依頼して `shinaps:commit` で行い、Codexは各コミットの単位照合と全体照合を行う。pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで継続する。
+コミットはClaudeへ差分確定を依頼して `shinaps:commit` で行い（manualは上の経路の項に従う）、Codexは各コミットの単位照合と全体照合を行う。pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで継続する。

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