@shinaps/skills 0.37.0 → 0.39.0

package/plugins/shinaps-codex/references/linear/claude-cli.md

@@ -1,17 +1,17 @@
 # ローカルClaude CLIによる実装
 
-通常設定が `review_flow.mode: auto` のIssueと、`ask` で着手時にautoを選んだIssue（[経路](configuration.md#経路)）で、Codexが作業先でローカル `claude -p` を起動する。初回実装前に、正確なcheckout・branch・HEAD・既存差分、`claude_cli` の許可（または今回の明示依頼）、必須検証とそのツールチェーンの状態、依頼で使うコマンドの許可を確定する。必須検証は対象リポジトリの規約・CI・スクリプトから読み、ツールチェーンは実際のコマンド（例: `node --version`、依存の導入状態の確認）の結果で確かめる。確かめるのは依頼で実際に使うコマンドに限る。
+通常設定が `review_flow.mode: auto` のIssueと、`ask` で着手時にautoを選んだIssue（[経路](configuration.md#経路)）で、Codexが作業先でローカル `claude -p` を起動する。初回実装前に、正確なcheckout・branch・HEAD・既存差分、`claude_cli` と `claude_cli_bypass_permissions` の許可（または今回の明示依頼）、必須検証とそのツールチェーンの状態、依頼で許可・禁止する操作を確定する。必須検証は対象リポジトリの規約・CI・スクリプトから読み、ツールチェーンは実際のコマンド（例: `node --version`、依存の導入状態の確認）の結果で確かめる。確かめるのは依頼で実際に使うコマンドに限る。
 
 パス例外はコミット単位のreview_flowを全体置換し、実装sessionを途中で切り替えない。manual単位が生じた場合は[経路](configuration.md#経路)に従う。
 
 ## 起動と観測
 
-通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。メインのモデルは[経路](configuration.md#経路)のとおり、起動とすべてのresumeで `--model opus` を指定する。resumeで省くと既定のモデルで再開され得るため、毎回指定する。effort・plugin構成は指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作の権限が許可されることは別である。
+通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。メインのモデルは[経路](configuration.md#経路)のとおり、起動とすべてのresumeで `--model opus` を指定する。resumeで省くと既定のモデルで再開され得るため、毎回指定する。権限モードも同じ理由で、起動とすべてのresumeで `--permission-mode bypassPermissions` を指定する（下の「操作権限」）。effort・plugin構成は指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作の権限が許可されることは別である。
 
-依頼本文を作業記録のpromptファイルへ保存し、stdinで渡す。本文をshellへ展開しない。以下は絶対パスを今回の記録先に置き換え、コマンドのcwdを確定済みcheckoutへ指定して実行する例。毎回異なる出力名を使い、既存記録を上書きしない。必要なSkill/Agent・Read/Edit・検証コマンド等の `--allowedTools` は依頼の許可と範囲から個別に追加する。たとえばcommit段階の `Bash(git add <対象パス>)` と `Bash(git commit -m <確定メッセージ>)` は実際の引数に限定し、初回実装にはcommit権限を渡さない。広範な既存allow設定がある場合も対象外操作の許可とは扱わない。
+依頼本文を作業記録のpromptファイルへ保存し、stdinで渡す。本文をshellへ展開しない。以下は絶対パスを今回の記録先に置き換え、コマンドのcwdを確定済みcheckoutへ指定して実行する例。毎回異なる出力名を使い、既存記録を上書きしない。
 
 ```sh
-claude -p --model opus --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
+claude -p --model opus --output-format json --permission-mode bypassPermissions --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
 ```
 
 途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue、出力パスを記録する。実行中は、実行ツールがprocessの終了を通知する場合はその通知を待つ。通知を受け取れるかは、利用時の実行ツールが実際に提供する機能で判断する。通知を受け取れない場合だけ、起動または前回の確認から5分おきに同じprocessの終了だけを確認する。この5分は確認の間隔で、進行役の1回の待機の長さ（[実行](execution.md) の「待機の手順（進行役）」）とは別に扱い、短い待機から戻るたびには確認しない。終了を待つ間は、stream-json・stderr・出力ファイルなどのログや途中成果を読まない。異常の根拠がある場合と利用者に依頼された場合だけ、必要な範囲で調べる。新しいCLIを並行起動せず、終了したら終了コードを取得して結果を会話へ返す。
@@ -20,18 +20,24 @@ jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、
 
 ## 依頼・質問・修正・コミット
 
-promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、体制と体制判断の材料、exact cwd・branch・HEAD・既存差分、必須検証コマンドと確かめたツールチェーンの状態、許可・禁止操作と起動時に渡す `--allowedTools` の個別エントリ、規約と参照先、返却条件を含める。通常設定が `ask` なら、解決したmodeと回答の記録も含め、Claudeが再質問しないようにする。依頼の体制で進め、BASIC・ULTRAでは追加の担当をClaudeのメインが材料と現物から決め、体制と理由をresultに含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。[途中確認](qa.md#qaの時点対象最終qa)の依頼は、実行中の担当が無い時点でresultに返す。この依頼は完了報告ではなく、CodexはLocal Agent QAへ進めない。CLIからBridge送信や人の対話入力を待たせない。
+promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、体制と体制判断の材料、exact cwd・branch・HEAD・既存差分、必須検証コマンドと確かめたツールチェーンの状態、許可・禁止操作、規約と参照先、返却条件を含める。通常設定が `ask` なら、解決したmodeと回答の記録も含め、Claudeが再質問しないようにする。依頼の体制で進め、BASIC・ULTRAでは追加の担当をClaudeのメインが材料と現物から決め、体制と理由をresultに含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。[途中確認](qa.md#qaの時点対象最終qa)の依頼は、実行中の担当が無い時点でresultに返す。この依頼は完了報告ではなく、CodexはLocal Agent QAへ進めない。CLIからBridge送信や人の対話入力を待たせない。
 
 回答・QA修正・QA後のautoコミット依頼は、元のprocess終了後、記録済みの正確なIDで同じセッションをresumeする。`--continue` で別セッションを推測しない。
 
 ```sh
-claude -p --resume '<recorded-session-id>' --model opus --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/follow-up.txt > /absolute/work/follow-up-result.json 2> /absolute/work/follow-up-stderr.log
+claude -p --resume '<recorded-session-id>' --model opus --output-format json --permission-mode bypassPermissions --permission-prompts none < /absolute/work/follow-up.txt > /absolute/work/follow-up-result.json 2> /absolute/work/follow-up-stderr.log
 ```
 
 resumeにも同じcwdと許可境界を指定し、外部で変化したHEAD・差分を渡す。commit依頼にはLocal Agent QA結果、独立レビュー、単位案と全差分、実効review_flowと合意根拠（askでは解決したmodeと回答の記録）を含める。完了報告は体制（必須担当の完了・未完了と合意による未実施を含む）と途中の増員、変更範囲、検証、未解決事項、単位案と予定差分、Local Agent QAの後に修正があった場合は変更記録（[qa.md](qa.md#qaの時点対象最終qa)）、commitした場合はSHA・単位照合・残差分・stash復元結果・修正サイクルで確定した変更を含める。復帰不能時は理由を報告し、黙って別sessionに作り直さない。
 
 ## 操作権限
 
-`review_flow.mode: auto` はClaudeの `--permission-mode auto` を意味しない。非対話起動では `--permission-mode dontAsk` を明示し、既存設定がbypassでも継承しない。effort・pluginsは保持し、操作許可は既存の個別allow設定と今回の範囲に限定する。`--permission-prompts none` は対話できないpromptを拒否として返すためであり、許可を付与しない。permission_denialsがあれば操作と必要な権限を報告し、既存の明示許可が対象を満たすか確認する。満たす場合だけ必要なSkill/Agentや対象を限定した `--allowedTools` を明示し、同じsessionへ明示的に再依頼する。新しい権限が必要ならCodexが人へ確認する。`--allowedTools` を使う場合も対象・操作に限定し、無条件の `Bash(*)`、bypassPermissions、dangerously-skip-permissionsを使わない。拒否を隠すsilent retryをしない。会話上の許可はCLIの権限チェックを消さない。
+`review_flow.mode: auto` はClaudeの `--permission-mode auto` を意味しない。非対話起動と同じsessionのresumeでは `--permission-mode bypassPermissions` を明示する。依頼で必要になる操作を個別のallowで事前に列挙しきれず、非対話では足りない許可を求められないまま作業が止まるためである。`--allowedTools` で個別の許可を足したり、dontAskなど別のモードで起動したりしない。`--permission-prompts none` は、bypassでも残る確認を入力待ちにせず拒否としてresultへ返すために付け、許可を付与しない。
 
-CLI仕様の参照: [headless](https://code.claude.com/docs/en/headless)、[CLI reference](https://code.claude.com/docs/en/cli-reference)。利用版で必要なflagが非対応なら状態を報告して停止し、権限回避へ切り替えない。
+bypassでの起動には、`claude_cli` に加えて利用者が明示的に同意した `claude_cli_bypass_permissions`（または今回の明示依頼）が必要で、`claude_cli` だけをbypassへの同意とみなさない。同意が無ければCodexは起動前に人へ一問で確認し、回答まで起動しない。回答は同じIssueの起動とすべてのresumeに引き継ぐ。同意が得られなければauto経路では起動せず、許可不足のブロッカー（[実行](execution.md)）として報告する。manual経路で進めるかは利用者が決め、その場合は[経路](configuration.md#経路)のとおり設定（通常設定がaskなら同じIssueの選択）を見直してから着手する。
+
+bypassはCLIの権限チェックを省くだけで、操作の許可ではない。Claudeが行う操作は依頼の範囲と、[共通設定](configuration.md)の `permissions`・合意済みの `review_flow` に限る。stage・commitは、QA後の差分確定の依頼を受けたときだけ `shinaps:commit` に従って行う。push・公開・外部への送信・破壊的操作は、それぞれの許可と工程に従う。CLIで実行できることや会話上の許可を、依頼の範囲外の操作の許可とは扱わない。
+
+permission_denialsがあれば操作と理由を報告し、拒否を隠すsilent retryをしない。bypassでも残る拒否（deny設定・保護されたパス・組織の設定など）は、同じ指定で再依頼しても解消しない。依頼の範囲内で別の手段を指示できる場合だけ同じsessionへ再依頼し、それ以外や新しい許可が必要な場合はCodexが人へ確認する。
+
+CLI仕様の参照: [headless](https://code.claude.com/docs/en/headless)、[CLI reference](https://code.claude.com/docs/en/cli-reference)。利用版で必要なflagが非対応、またはbypassPermissionsが組織の設定などで無効なら、状態を報告して停止し、別の権限モードへ切り替えて進めない。

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

@@ -4,10 +4,12 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.37.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.37.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.39.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.39.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
 
 0.35.0から通常設定の `review_flow.mode` に `ask` を受理する。`config_version` は2のままで、既存のauto・manualの設定は変更不要。0.33.0〜0.34.xのCLIと `$schema` のURLは `ask` を拒否するため、`ask` を使う設定では `$schema` も0.35.0以降のURLにする。
 
+0.39.0から許可 `claude_cli_bypass_permissions` を受理する。`config_version` は2のままで、0.33.0〜0.38.xのCLIと `$schema` のURLはこの許可を拒否するため、使う設定では `$schema` も0.39.0以降のURLにする。
+
 ```sh
 shinaps-skills --version
 shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
@@ -75,7 +77,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 | `team_settings` | `existing_only`（既存の定義に合わせ、変更しない）または `manage_on_setup`（初期設定・設定変更のときだけ変更案を示し、合意後に整備できる） |
 | `statuses` | 状態キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる |
 | `stop_after` | 終了地点（下の「終了地点」） |
-| `permissions` | 継続的に許可した操作の一覧（下の「許可」）。経路の許可（auto: `claude_cli`、manual: `bridge_request`）も含む。許可なしは `[]` |
+| `permissions` | 継続的に許可した操作の一覧（下の「許可」）。経路の許可（auto: `claude_cli` と `claude_cli_bypass_permissions`、manual: `bridge_request`）も含む。許可なしは `[]` |
 | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
 | `cycle_report` | Cycle報告の設定（下の「Cycle報告」）。報告を使わない場合は `null` |
 | `review_flow` | `{ "mode": "auto" }`（AIが自然な単位を決め、独立レビュー・QA後にstage・commit）または `{ "mode": "manual" }`（AIがレビュー待ちを明示し、人がWebStormで差分を確認する。人のコミット開始依頼でAIが分割案を示し、人が単位ごとに依頼したらAIがstage・commit）、または `{ "mode": "ask" }`（着手時に進行役が人へautoかmanualかを一問で確認し、回答を同じIssueの通常flowとして使う）。開始時の値（askでは回答）で経路も決まる（下の「経路」） |
@@ -92,7 +94,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 | 通常設定 | 経路 | 必要な許可 | メインのモデル |
 | --- | --- | --- | --- |
-| `auto` | Codexが起動するローカルClaude CLIの同じsession（[Claude CLI](claude-cli.md)） | `claude_cli` | Opus。起動とすべてのresumeで `--model opus` を指定する |
+| `auto` | Codexが起動するローカルClaude CLIの同じsession（[Claude CLI](claude-cli.md)） | `claude_cli`・`claude_cli_bypass_permissions` | Opus。起動とすべてのresumeで `--model opus` を指定する |
 | `manual` | WebStorm内の対話Claude CodeセッションへBridgeで依頼する（[Bridge](bridge.md)） | `bridge_request` | Opusを基本とし、Issueの着手時にFableかOpusかを確認する。同じIssueの一括修正・継続・再開では選択を引き継ぐ |
 | `ask` | 着手時に人へ一問で確認した回答（auto・manual）の経路 | 回答した経路の許可 | 回答した経路のモデル |
 
@@ -152,7 +154,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 1. 現在の設定・許可・補足・進行中Issueを確認する。
 2. `config_version: 2` にし、`implementation_skill`、`review_flow.tool`、`path_policy_overrides[].review_flow.tool` を削除する。
-3. `permissions` から `codex_task`・`managed_session:*` を削除する。経路の許可（通常設定がautoなら `claude_cli`、manualなら `bridge_request`）は、そのリポジトリの利用者と合意して明示的に追加する。既存の `bridge_request` は、任意の引き渡しに加えてmanual経路の依頼も表すようになるため、残すかを確認する。他の許可は増やさない。
+3. `permissions` から `codex_task`・`managed_session:*` を削除する。経路の許可（通常設定がautoなら `claude_cli` と `claude_cli_bypass_permissions`、manualなら `bridge_request`）は、そのリポジトリの利用者と合意して明示的に追加する。既存の `bridge_request` は、任意の引き渡しに加えてmanual経路の依頼も表すようになるため、残すかを確認する。他の許可は増やさない。
 4. `statuses` は変更しない。補足からCodex実装タスク・Managed・tool・人がコミットする条件の記述とそれらの資料へのリンクを除き、合意日付を残す。
 5. `$schema` を利用中の公開版のURLへ更新し、CLIで検証して読み戻す。
 
@@ -177,7 +179,8 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 | --- | --- |
 | `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
 | `development_operations` | 任された対象の開発に必要な、既存アカウントへの通常のログイン、ローカル環境準備、プロジェクトの依存導入、開発サーバー・Simulatorの起動停止、ビルド・テスト・QA操作を継続的に許可する。下の範囲に従う |
-| `claude_cli` | auto経路で、Codexが行うClaudeのローカルCLI起動、同じsessionの状態・結果取得、質問への回答・修正・許可済みコミットのresume。メインのモデル（[経路](#経路)）の指定のほかは既存CLI設定を保持し、個別の操作権限を維持する（[手順](claude-cli.md)） |
+| `claude_cli` | auto経路で、Codexが行うClaudeのローカルCLI起動、同じsessionの状態・結果取得、質問への回答・修正・許可済みコミットのresume。メインのモデル（[経路](#経路)）と権限モードの指定のほかは既存CLI設定を保持する（[手順](claude-cli.md)）。bypassPermissionsでの起動への同意は含まない |
+| `claude_cli_bypass_permissions` | auto経路のClaudeのローカルCLIを、起動と同じsessionのすべてのresumeで `--permission-mode bypassPermissions` にすることへの、利用者の継続的な同意。CLIの権限チェックを省くだけで、操作の許可を追加しない。Claudeの操作は依頼の範囲と他の許可・合意済みの `review_flow` に限る（[手順](claude-cli.md#操作権限)） |
 | `bridge_request` | manual経路で、CodexがBridgeで対話Claude Codeセッションへ行う依頼と報告の受け取り、および別会話との任意の進行の引き渡し。報告は照合材料であり、操作許可を変更しない（[手順](bridge.md)） |
 | `push` | 対象Issueの作業ブランチの通常のpush |
 | `pr_create` | 対象IssueのPRの作成と更新 |
@@ -187,7 +190,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 | `dev_delegation` | `shinaps:dev-claude` の中で、サブエージェントへ委託する。許可がない場合、入口のメインは担当の作業を代わりに行わず、必要な許可を求める。worktreeの作成は含まない |
 | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
 
-- 開発進行には `issue_update` と、[経路](#経路)の許可が必要（auto: `claude_cli` とローカルClaude CLI、manual: `bridge_request` と、Bridge MCP・WebStorm内の対話Claude Codeセッション。ask: 着手時に選んだ経路の許可）。今回の明示依頼による同じ経路の許可も引き継ぐ。初期設定は `issue_update`・経路の許可（askでは選択肢にする両経路の許可）・`dev_delegation` と `review_flow` を具体的に提案し、合意を得る。設定の存在だけでは許可を得ない。
+- 開発進行には `issue_update` と、[経路](#経路)の許可が必要（auto: `claude_cli`・`claude_cli_bypass_permissions` とローカルClaude CLI、manual: `bridge_request` と、Bridge MCP・WebStorm内の対話Claude Codeセッション。ask: 着手時に選んだ経路の許可）。今回の明示依頼による同じ経路の許可も引き継ぐ。初期設定は `issue_update`・経路の許可（askでは選択肢にする両経路の許可）・`dev_delegation` と `review_flow` を具体的に提案し、合意を得る。設定の存在だけでは許可を得ない。
 - `development_operations` は、既存の認証手段と利用者が許可した既存アカウントを使い、対象の開発・検証環境と専用の検証データで行う操作に限る。本人の二要素認証・セキュリティキー・CAPTCHA等が必要なら具体的に依頼し、回避しない。ログイン成功を新しい権限への同意と扱わず、新規アカウント・OAuth権限の拡大・課金・新規クラウド資源・共有環境への破壊的変更・実利用者データの操作は含めない。秘密値をIssueや証拠へ記載しない。
 - この包括許可は `stage`・`commit`・`push`・`pr_create`・`merge`・`deploy:*`・`publish:*`・外部への送信・履歴やデータの破壊的操作を含まない。テストや環境準備がこれらを伴うときも、stage・commitは合意済みflow、その他はそれぞれの許可が必要。人レビュー・Human QA・ツール側の承認条件を省略しない。`permissions` に明示された場合だけ適用し、既存設定に自動で追加しない。
 - 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする（マージで本番へ自動配備される場合は `merge` と `deploy:production`）。
@@ -214,7 +217,7 @@ manualの設定例。同じprojectを複数のリポジトリがそれぞれの
 
 ```json
 {
-  "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.35.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
+  "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.39.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
   "config_version": 2,
   "config_storage": "shared",
   "target": {

package/plugins/shinaps-codex/references/linear/configuration.schema.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.35.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
+  "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.39.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
   "title": "Shinaps Linear configuration v2",
   "type": "object",
   "properties": {
@@ -142,6 +142,7 @@
               "issue_update",
               "development_operations",
               "claude_cli",
+              "claude_cli_bypass_permissions",
               "bridge_request",
               "dev_delegation",
               "push",

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

@@ -23,7 +23,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 | 工程 | 状態キー | 内容と次へ進む条件 |
 | --- | --- | --- |
-| 着手 | `ready` | Readyと依存を確認し、作業先設定を読み、通常設定の `review_flow` から経路と必要な許可（auto: `claude_cli`、manual: `bridge_request`）を確定する。通常設定がaskなら、Claudeへの依頼前に作業内容と推奨理由を添えてautoかmanualかを人へ一問で確認し、回答まで着手しない。回答と根拠を作業記録に残し、同じIssueでは再質問しない。依頼の前に `dev_delegation`（または今回の明示依頼）があるかを確かめ、無ければ人へ一問で確認する。経路・メインのモデル（manualのみ。[経路](configuration.md#経路)）・体制（[体制の選択](../dev/staffing.md)）は別の項目とし、指定されていないものだけを推奨とともに一問ずつ確認して記録する。体制は依頼にも書く。checkout・branch・HEAD・既存差分を固定し、体制判断の材料を添えてClaudeへ依頼する。経路がautoでmanualのパス別ルールがあれば、起こり得る停止（[経路](configuration.md#経路)）を依頼に書く |
+| 着手 | `ready` | Readyと依存を確認し、作業先設定を読み、通常設定の `review_flow` から経路と必要な許可（auto: `claude_cli` と `claude_cli_bypass_permissions`、manual: `bridge_request`）を確定する。通常設定がaskなら、Claudeへの依頼前に作業内容と推奨理由を添えてautoかmanualかを人へ一問で確認し、回答まで着手しない。回答と根拠を作業記録に残し、同じIssueでは再質問しない。依頼の前に `dev_delegation`（または今回の明示依頼）があるかを確かめ、無ければ人へ一問で確認する。経路・メインのモデル（manualのみ。[経路](configuration.md#経路)）・体制（[体制の選択](../dev/staffing.md)）は別の項目とし、指定されていないものだけを推奨とともに一問ずつ確認して記録する。体制は依頼にも書く。checkout・branch・HEAD・既存差分を固定し、体制判断の材料を添えてClaudeへ依頼する。経路がautoでmanualのパス別ルールがあれば、起こり得る停止（[経路](configuration.md#経路)）を依頼に書く |
 | 実装 | `coding`, `local_agent_qa` | Claudeのメインが依頼の体制の担当（BASIC・ULTRAでは追加の担当を含む）を決めて報告し、`shinaps:dev-claude` で実装・検証・独立レビューを行い、未コミット差分・単位案・予定差分・判定記録を返す。manualでは人へユーザーのレビュー待ちと明示する。CodexがLocal Agent QA（判定記録と経路の整合、必須担当の照合を含む）を行う。依頼に書いた体制の必須担当（[実装体制の判断](../dev/staffing.md)）は、完了または合意の記録付きの未実施を合格とする。不合格（必須担当のそれ以外の未完了や代替を含む）なら同じsessionへ戻し、再QAは[初回QAの一部](qa.md#qaの時点対象最終qa)として合格まで続ける |
 | 差分確定 | `code_review` | QA合格後、Codexが実効flow・判定記録・QA結果を同じsessionへ渡し、Claudeが `shinaps:commit` を行う。autoは単位ごとに独立レビュー後にcommitする。manualではCodexはcommitを依頼せず、渡した後は報告を待つ。人のコミット開始依頼でClaudeが分割案を示し、人が単位ごとに依頼したcommitを行う。Codexは各コミットの単位照合と全体照合を行う。差分確定中の実装の修正は、devの修正サイクル（[工程](../dev/workflow.md)の「役割と継続」）で行い、ステータスは `code_review` のままにする。修正やコミットのたびにCodexのQAへ戻さない（[最終QA](qa.md#qaの時点対象最終qa)） |
 | 公開確認 | `post_commit`, `staging_agent_qa`, `staging_human_qa`, `release`, `production_agent_qa`, `production_human_qa` | 受入条件と許可に応じて必要なものだけ行う: push前の最終Agent QAとpushするHEADの照合（[最終QA](qa.md#qaの時点対象最終qa)）、push・PR作成、環境配備とStaging/ProductionのAgent QA、必要なHuman QA、merge・配備・公開。適用しない項目は理由を記録する |

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

@@ -1,59 +1,84 @@
-# Claude Managed Agents の設定
+# Claude Managed Agents の設定とアカウント
 
-作業先リポジトリの `.shinaps/managed.json` に置く。`config_version: 1` のJSONで、[JSON Schema](configuration.schema.json)を契約の正本とする。
+Managed Agents は配布CLI `shinaps-skills managed` で導入・依頼・観測・回収する（[導入](setup.md)・[依頼と観測](execute.md)）。CLI は利用中の skill と同じ版の `@shinaps/skills` を使う。クラウドの操作は公式の `ant` CLI（2.4.0 以上）へ委ね、CLI は PATH 上の `ant` を呼ぶ。CLI が使うコマンド・フラグ・stdin の本文・出力の形は、ant 2.4.0 の公式ソースで照合した（実行は未確認。[未検証の境界](execute.md#未検証の境界)）。
 
-設定が持つのは、共通定義のコピーの置き場所・対象リポジトリ・GitHub MCP の資格情報を登録した vault だけである。許可・予算・Issueの範囲・base と head・終了条件は呼び出しのたびに利用者と合意して決め、設定には書かない。lead・役割・環境のリソース ID は lock から読み、設定には書かない。vault は lock に記録されないため、`vault_id` だけを設定に持つ。秘密値は書かない。schema は未知のキーを拒否するので、許可や予算などのキーを書いた設定は検証で失敗し、許可や予算として扱われることはない。
+## アカウント
 
-認証は `ant` の既存のログイン（利用者本人が `ant auth login` を行う）と環境変数、GitHub MCP は vault の資格情報を使う。
+アカウントは、APIキー1つが属する組織・workspace に利用者が付ける名前で、英小文字・数字と単独のハイフン（`^[a-z0-9]+(-[a-z0-9]+)*$`）にする。同じマシンでは、同じ名前は常に同じ組織・workspace を表すようにする。lock がアカウント名で引かれるので、別の組織に同じ名前を使うと別の組織の lock で適用しようとする（`ant apply` は lock と違う組織・workspace の資格情報を拒否して止まる）。
 
-## 配置
+### APIキー
+
+コマンドごとに、各アカウントのキーを次のどちらかで渡す。
+
+- 環境変数 `SHINAPS_MANAGED_API_KEY_<NAME>`（`<NAME>` はアカウント名の英大文字で、`-` は `_`。例 `work-us` → `SHINAPS_MANAGED_API_KEY_WORK_US`）。推奨。
+- 引数 `--api-key <name>=<key>`（環境変数より優先）。引数は同じマシンの他のプロセスやシェルの履歴から見えるので、共有のマシンでは使わない。
+
+CLI はキーを保存せず、出力とエラー文では伏字にする。`ant` へは子プロセスの環境変数 `ANTHROPIC_API_KEY` だけで渡し、親の `ANTHROPIC_*`（別のキー・`ant auth login` のプロファイル・workspace の指定）と他アカウントのキーは子へ渡さない。workspace をまたげる資格情報（`--workspace-id` が必要なもの）は扱わないので、workspace に属するキーを使う。
+
+### アカウントの状態
+
+各アカウントの状態は、マシン単位の管理ディレクトリ `~/.local/share/shinaps-ai/skills/managed/<account>/` に置く。lock は組織・workspace に属し、リポジトリには属さないため。複数のリポジトリから同じアカウントを使っても lock は1つになり、clone のやり直し・worktree・`git clean` で失われない。
 
 | パス | 内容 |
 | --- | --- |
-| `.shinaps/managed.json` | この設定 |
-| `<definitions>/agents/`・`environments/`・`skills/` | plugin の `managed-agents/` からコピーした共通定義。テンプレートの所有で、更新時は丸ごと置き換える |
-| `<definitions>/claude-lock.json` | `ant apply` が記録するクラウド上のリソースの ID と版 |
+| `definitions/agents/`・`environments/`・`skills/` | 同梱の共通定義の写し。setup が同梱の定義に揃える |
+| `definitions/claude-lock.json` | `ant apply` が記録するクラウド上の lead・役割・skill・環境の ID と版。setup は読むだけで書き換えない。手で編集しない |
+| `definitions.json` | setup が最後に書いた共通定義の各ファイルのハッシュ。利用者の変更の検出に使う |
+| `sessions/<request_id>.json` | このアカウントで作ったセッションの記録（入力と session ID。秘密値は含まない） |
+| `sessions/<session_id>/outputs/` | 回収した出力ファイル |
+| `update.lock` | 同じアカウントの setup・run を同時に1つにする排他（`ant apply` は lock を排他しないため） |
+
+`definitions/` には同梱の共通定義と lock だけを置き、共通定義を手で編集しない。適用はディレクトリ内の定義をすべて送るため。利用者が加えた定義の変更は導入に取り込まない（クラウドへ持ち越さない）。setup は、自分が最後に書いた内容か今回書く内容と一致するファイルだけを書き換え・削除する。利用者の編集・追加、記録の無い既存のファイル（旧版の定義ごと複写した場合など）、通常のファイル・ディレクトリ以外のもの、ほかの項目が一つでもあれば、何も変えずにそのアカウントを失敗にし、該当するパスを示す。それらを `definitions/` の外へ退避してから（lock は残す）再実行すると、同梱の定義を書き直して進む。消えた共通定義のファイルは書き直す。
+
+## lock の扱い
 
-いずれも Git 対象外にする。`.shinaps/.gitignore` が `*` で始まる場合は追加の設定なしで除外される。書き込む前に `git check-ignore --no-index -v <パス>` で除外を確認する。除外されていなければ、[導入の手順](setup.md#1-設定を読む)に従って既存の規則と共有例外を保ったまま `.shinaps/.gitignore` に必要な行だけを加えてから書き込む（新規作成の内容は[作業記録の共通手順](../work-records.md)と同じ）。`<definitions>` をリポジトリの外に置く場合は Git の対象にならないので、この確認は `.shinaps/managed.json` だけに行う。
+- `definitions/claude-lock.json` がクラウド上の ID の正本である。lead の ID は `./agents/shinaps-dev-managed-cc.md`、環境の ID は `./environments/shinaps-dev.yaml` の `id` にある。
+- lock のキーは lock のあるディレクトリからの相対パスである。共通定義を同じ構造で `definitions/` 直下に置き、そこで適用するので、既存のリソースに対応づく。
+- lock が無いと適用は既存のリソースと対応づかず、同じ名前のリソースを重複して作る。lock の `hash` は既存のリソースから作り直せないので、setup は lock が無いアカウントに同名の未アーカイブの lead・役割・環境があれば止まる。バックアップや以前の置き場所から lock を戻して再実行する。見つからなければ適用せず、利用者に相談する。
+- 別のマシンでは lock が無い。同じ組織を別のマシンから導入するときは、元のマシンの lock を同じ名前のアカウントへ複写する。
 
-## 項目
+## 作業先の設定（`.shinaps/managed.json`）
 
-全項目が必須で、`$schema` だけは省略できる。
+`managed run` だけが読む作業先の設定。`config_version: 2` のJSONで、[JSON Schema](configuration.schema.json)を契約の正本とする。持つのは、セッションにマウントするリポジトリと、アカウントごとの GitHub MCP の vault だけである。許可・予算・base と head・範囲・体制は依頼のたびに引数で明示し、設定には書かない。schema は未知のキーを拒否するので、許可や予算のキーを書いた設定は検証で失敗する。lead と環境の ID はアカウントの lock から読む。秘密値は書かない。
 
 | キー | 内容 |
 | --- | --- |
 | `$schema` | 任意のエディタ補助。CLI はこの URL を取得しない |
-| `config_version` | `1` |
-| `definitions` | 共通定義のコピーと lock を置くディレクトリ。リポジトリのルートからの相対パス、または絶対パス。clone のやり直し・worktree・`git clean` の影響を避けたい場合は、リポジトリの外の絶対パスにする。同じマシンの同じ組織で複数のリポジトリから使う場合は、全リポジトリの `definitions` に同じ絶対パスを指定し、lock を 1 つにする。別のマシンでは[lock の扱い](#lock-の扱い)に従う |
+| `config_version` | `2` |
 | `repository.url` | セッションにマウントする GitHub リポジトリの URL |
 | `repository.mount_path` | セッション内のマウント先（例 `/workspace/widgets`） |
-| `vault_id` | GitHub MCP の資格情報を登録した vault の ID。未登録なら `null` |
+| `accounts.<name>.vault_id` | そのアカウントで GitHub MCP の資格情報を登録した vault の ID（vault は組織ごと）。未登録なら `null`。依頼に使うアカウントを全て書く |
 
-## 検証
+設定は Git 対象外にする（`.shinaps/.gitignore` が `*` で始まる場合は追加の設定なしで除外される）。書き込む前に `git check-ignore --no-index -v .shinaps/managed.json` で除外を確認し、除外されていなければ既存の規則と共有例外を保ったまま `.shinaps/.gitignore` の末尾に `/managed.json` を加える（新規作成の内容は[作業記録の共通手順](../work-records.md)と同じ）。
 
-利用中の 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 を更新する。
+`shinaps-skills validate-managed-config <明示ファイル>` で検証する。ローカル開発では `node bin/skills.ts validate-managed-config <file>` を使える。CLI は指定された一つのJSONを同梱 schema で検証し、ネットワーク取得・設定の探索・Git 操作・入力の変更はしない。成功は構造が正しいことだけを表し、vault やアカウントの lock がクラウドに存在することは保証しない。
 
-## 設定例
+`config_version` が欠落または旧版なら作り直し、未来版なら skill と CLI を更新する。
+
+### version 1 からの移行
+
+version 1 は lock を作業先の `definitions`（既定 `.shinaps/managed/`）に置いていた。
+
+1. 使っていた組織・workspace にアカウント名を決める。
+2. `<definitions>/claude-lock.json` だけを `~/.local/share/shinaps-ai/skills/managed/<account>/definitions/claude-lock.json` へ移す（複数のリポジトリで同じ `definitions` を共有していた場合も1回でよい）。旧版の `agents/` などは移さない。移すと記録の無いファイルとして setup が止まる。
+3. 設定を version 2 で作り直す。`definitions` を除き、`vault_id` を `accounts.<account>.vault_id` へ移す。
+4. `managed setup --account <account>` で計画を確かめる（[導入](setup.md)）。lock を移し忘れると同名のリソースで止まる。旧版の定義を手で編集していた場合、その変更は持ち越されない。計画に、クラウド上の定義を同梱の定義へ戻す update が含まれることを確かめてから適用する。
+
+### 設定例
 
 ```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",
+  "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.38.0/plugins/shinaps-claude/references/managed/configuration.schema.json",
+  "config_version": 2,
   "repository": {
     "url": "https://github.com/acme/widgets",
     "mount_path": "/workspace/widgets"
   },
-  "vault_id": null
+  "accounts": {
+    "personal": { "vault_id": null },
+    "work": { "vault_id": "vlt_011CZkZDLs7fYzm1hXNPeRjv" }
+  }
 }
 ```
-
-## 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

@@ -1,7 +1,7 @@
 {
   "$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",
+  "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.38.0/plugins/shinaps-claude/references/managed/configuration.schema.json",
+  "title": "Shinaps Managed Agents configuration v2",
   "type": "object",
   "properties": {
     "$schema": {
@@ -9,11 +9,7 @@
     },
     "config_version": {
       "type": "integer",
-      "const": 1
-    },
-    "definitions": {
-      "type": "string",
-      "minLength": 1
+      "const": 2
     },
     "repository": {
       "type": "object",
@@ -30,18 +26,32 @@
       "required": ["url", "mount_path"],
       "additionalProperties": false
     },
-    "vault_id": {
-      "anyOf": [
-        {
-          "type": "string",
-          "minLength": 1
+    "accounts": {
+      "type": "object",
+      "minProperties": 1,
+      "propertyNames": {
+        "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$"
+      },
+      "additionalProperties": {
+        "type": "object",
+        "properties": {
+          "vault_id": {
+            "anyOf": [
+              {
+                "type": "string",
+                "minLength": 1
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
         },
-        {
-          "type": "null"
-        }
-      ]
+        "required": ["vault_id"],
+        "additionalProperties": false
+      }
     }
   },
-  "required": ["config_version", "definitions", "repository", "vault_id"],
+  "required": ["config_version", "repository", "accounts"],
   "additionalProperties": false
 }

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

@@ -1,118 +1,82 @@
 # 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) に従って決めるので、ここでは指示しない。
+Claude Managed Agents の lead `shinaps-dev-managed-cc` へ dev を依頼し、進み具合の観測・質問の取り次ぎ・出力の回収と draft PR の確認を行う手順。体制は合意する入力として渡す。計画・実装・レビューの工程と追加の担当は lead が [skill `dev-managed-cc`](../../managed-agents/skills/dev-managed-cc/SKILL.md) に従って決めるので、ここでは指示しない。アカウント・キー・状態の置き場所は[設定とアカウント](configuration.md)に従う。
 
 ## 呼び出し時に合意する入力
 
-設定からは読まず、依頼のたびに利用者と合意する。
+設定・記録・過去の作業からは推定せず、依頼のたびに利用者と合意して引数で明示する。
 
-- 必須: base ブランチとその SHA、head ブランチ、範囲と受入条件、体制（LITE・BASIC・ULTRA。[体制の選択](../dev/staffing.md)に従い推奨を添えて確認する）、許可（commit・head への push・draft PR の作成のうち明示されたもの）、予算（USD のセント単位）
-- 任意: 必須検証のコマンド、コミットの author、利用者 CLAUDE.md の添付
+- 必須: アカウント、base ブランチとその SHA、head ブランチ、範囲と受入条件（ファイル）、体制（LITE・BASIC・ULTRA。[体制の選択](../dev/staffing.md)に従い推奨を添えて確認する）、許可（`none`、または `commit`・`push`・`draft_pr` のうち明示されたもの）、予算（USD のセント単位）
+- 任意: 必須検証のコマンド、コミットの author、セッションの題名、利用者 CLAUDE.md の添付
 
-設定から読むのは `definitions`（lock の場所）・`repository`・`vault_id` だけで、lead と環境の ID は lock から読む（[設定](configuration.md)）。許可と予算は合意した内容だけで、会話の途中で増やさない。
+設定（`.shinaps/managed.json`）から読むのは `repository` とそのアカウントの `vault_id` だけで、lead と環境の ID はアカウントの lock から読む。許可と予算は合意した内容だけで、会話の途中で増やさない。
 
-## 1. 前提を確かめる
+## 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 の作成を含まない依頼だけは続けられる。
+`.shinaps/managed.json` が無い、または version 1 なら、`repository`（URL とマウント先）と、使うアカウントの `vault_id` を利用者に一問ずつ確認して version 2 で作る（[作業先の設定](configuration.md#作業先の設定shinapsmanagedjson)。version 1 は[移行](configuration.md#version-1-からの移行)のとおり lock も移す）。書き込む前に Git 対象外であることを確かめる。作った設定は `shinaps-skills validate-managed-config` で検証する。
 
-## 2. セッションを作る
+## 2. 依頼する
 
 合意済みの依頼があるときだけ作る。この手順を読んだことを理由に作らない。
 
-GitHub の token は対象リポジトリだけに限った fine-grained token にし、Contents と Pull requests の write だけを許可する。merge できるかは GitHub のブランチ保護で決まるので、base を保護しておく。token は `read -rs` で画面に出さずに受け取り、サンドボックス・作業記録・チャットに書かない。
-
-次はひな形で、`<...>` を設定と合意した入力で埋める。`vault_id` が `null` なら `--vault-id` の行を除く。
+GitHub の token は対象リポジトリだけに限った fine-grained token にし、Contents と Pull requests の write だけを許可する。merge できるかは GitHub のブランチ保護で決まるので、base を保護しておく。token は利用者が環境変数 `SHINAPS_MANAGED_GITHUB_TOKEN` に設定する（例 `read -rs SHINAPS_MANAGED_GITHUB_TOKEN && export SHINAPS_MANAGED_GITHUB_TOKEN`）。CLI はリクエスト本文（stdin）にだけ入れ、保存・表示しない。
 
 ```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: <ブランチ名>
-          範囲と受入条件: <内容>
-          体制: <LITE|BASIC|ULTRA>
-          許可: <commit・headへのpush・draft PRの作成のうち許可するもの>
-          予算: <金額>
-          必須検証（任意）: <コマンド。省略時はリポジトリの規約に従う>
-          author（任意）: <name> <email>
-YAML
-unset GITHUB_TOKEN
+shinaps-skills managed run .shinaps/managed.json --account <name> \
+  --base <branch> --base-sha <SHA> --head <branch> \
+  --staffing <LITE|BASIC|ULTRA> --allow <none|commit,push,draft_pr> \
+  --budget-cents <セント。4000 は 40 USD> --task-file <範囲と受入条件のファイル> \
+  [--verify "<コマンド>"] [--author "<name> <email>"] [--title "<作業名>"] [--claude-md <パス>]
 ```
 
-- `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` に置かれる）。
+- 設定と引数を検証し、セッションを作る前に次で止まる: `draft_pr` を許可したのにそのアカウントの `vault_id` が `null`、`push` か `draft_pr` を許可したのに token が無い。どちらもセッションを作ってから lead が気づくと予算を消費した後になるため。
+- セッションは lock の lead と環境、そのアカウントの vault、`max_list_cost` の予算、base の SHA をチェックアウトしたリポジトリで作る。head ブランチが無ければ lead が base から作る。初回メッセージにはリポジトリ・base と SHA・head・範囲と受入条件・体制・許可・予算・任意の入力を全て書く。
+- `--claude-md` は `ant beta:files upload` で上げ、`/mnt/session/uploads/CLAUDE.md` に置く。
+- 同じ入力（設定のリポジトリと vault、引数、範囲と CLAUDE.md の本文）の再実行は新しいセッションを作らず、記録したセッションの ID を返す。完了後に同じ範囲で新しく依頼するときは、題名など入力を変える。作成の途中で止まった記録が残っていれば作らずに止まる。表示された metadata `shinaps_request` のセッションがコンソールに無いことを確かめてから、表示された記録を消して再実行する。
 
 ## 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行目が `状態: 完了`・`状態: 質問`・`状態: 未完了` のどれかを読む。
+```sh
+shinaps-skills managed status --account <name> --session <ID>
+```
+
+セッションの `status`・`usage`（`list_cost` を含む）・`budget` と、lead の最後の `agent.message` の本文と1行目の状態（`完了`・`質問`・`未完了`）を JSON で表示する。扱うのは、そのアカウントで `managed run` が作った記録のあるセッションだけである。
 
 ## 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) の本文と同じ構造）。
+- 状態が `質問` なら、質問を一問ずつ利用者へ伝える。
+- 回答はファイルに書き、`user.message` として送る。
 
   ```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
+  shinaps-skills managed reply --account <name> --session <ID> --message-file <回答のファイル>
   ```
 
-  同じ内容は `--event.type user.message --event.content '<content の JSON 配列>'` のフラグでも渡せる。回答の送信は、依頼が進行中のセッションに対してだけ行う。
-- 回答で新しい許可・予算を加えない。必要なら新しい依頼として合意し直す。
-- `user.tool_confirmation` は利用者の明示の指示なしに送らない。
+- 回答の送信は、依頼が進行中のセッションに対してだけ行う。回答で新しい許可・予算を加えない。必要なら新しい依頼として合意し直す。
+- `user.tool_confirmation` は送らない。
 
-## 5. 成果物を確かめる
+## 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 に対して適用して、範囲と受入条件に対する差分を確かめる。
+```sh
+shinaps-skills managed collect --account <name> --session <ID>
+```
+
+- セッションに紐づく Files（`changes.patch` と作業記録の tar）を、そのアカウントの `sessions/<ID>/outputs/` へ保存し、保存したパスを表示する。同じ名前のファイルは最新のものだけを保存する（lead は毎ターン `changes.patch` を比較元からの全体の差分で置き換える）。名前がファイル名だけでないものは保存せずに止まる。保存したサイズは一覧の値と比べる。
+- CLI は差分を適用しない。`changes.patch` は合意した base の SHA のチェックアウトで `git apply --check` してから、範囲と受入条件に対する差分を確かめる。適用するかは利用者と決める。
 - `コミット:` と 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 は呼び出し元が別に行う。完了後に修正する場合は、新しい依頼として、体制を含めて合意し直す。
+状態行、回収した出力ファイル、コミット、push 先、PR の URL、未検証の事項を報告する。merge・deploy・release・Issue の更新・セッションのアーカイブは行わない。QA は呼び出し元が別に行う。完了後に修正する場合は、新しい依頼として、体制を含めて合意し直す。
 
 ## 未検証の境界
 
+- `managed setup`・`run`・`status`・`reply`・`collect` のコマンド・フラグ・stdin の本文・出力の形は ant 2.4.0 の公式ソースで照合し、偽の `ant` を使うテストで確かめた。実際の `ant` とクラウドではまだ実行していない。
+- API の側で決まり、ant のソースでは確かめられないこと: 予算 `max_list_cost.amount` がセント単位か、`mount_path: /CLAUDE.md` が `/mnt/session/uploads/CLAUDE.md` に置かれるか、Files の upload・一覧・取得に `files-api-2025-04-14` と `managed-agents-2026-04-01` の両方の beta を付ければよいか（ant の `--beta` は既定の beta を置き換えるので、全ての呼び出しで明示している）、Files の応答の `filename`・`size_bytes`・`created_at`、events の一覧に役割のスレッドの `agent.message` が混ざるか。lock が無い状態での skill の重複は、同じ setup で作る lead の同名確認で止まる。
 - マウントしたリポジトリの 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 仕様で確かめただけで、実際のセッションではまだ送っていない。出力ファイルの一覧と取得は既存のセッションで確かめた。
 - 完了したスレッドが同時実行の枠（25本）を空けるか。ULTRAでは、ラウンドごとに新しく起動する担当を含めて、同時に保つスレッドが多い。