@shinaps/skills 0.29.1 → 0.30.0

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

@@ -61,7 +61,7 @@
 | `permissions` | 継続的に許可した操作の一覧（下の「許可」）。許可なしは `[]` |
 | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
 | `cycle_report` | Cycle報告の設定（下の「Cycle報告」）。報告を使わない場合は `null` |
-| `implementation_skill` | Issueの実装・修正に使うdevの入口。`dev-claude`・`dev-claude-ultra`（CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する）、または `dev-codex`・`dev-codex-ultra`（Issueごとの別Codexタスクがその入口を実行し、会話側は進行・Agent QAを担当する） |
+| `implementation_skill` | Issueの実装・修正に使うruntimeの入口。担当数は固定せずメインが作業ごとに決める。`dev-claude`（CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する）、`dev-codex`（Issueごとの別Codexタスクがその入口を実行し、会話側は進行・Agent QAを担当する）、または `dev-managed-cc`（linear-executeを実行する会話が進行役になり、IssueごとのClaude Managed Agentsセッションのleadがその入口で実装する） |
 | `commit_mode` | `shinaps:commit` でコミットするときの進め方。`normal`（単位ごとに承認を得る）または `autonomous`（個別の承認なしで単位ごとに検証してコミットする） |
 | `human_code_review` | 人のコードレビューの要否。`required`（人がレビューする）または `skip`（人のレビューを行わない） |
 | `path_policy_overrides` | パス別に人レビュー・AIコミット許可・コミットの進め方を上書きするルールの一覧。例外なしは `[]`。既存設定で欠落していれば例外なし（下の「パス別の方針」） |
@@ -100,7 +100,7 @@ path_policy_overrides:
 
 ### 判定記録と変更時の扱い
 
-各予定単位について、設定の正本と内容、適用した全ルール（または適用なしの理由）、単位の比較元と全差分、継承後の実効3項目、今回の明示指示、`stage` の許可、検証・レビューの結果を記録する。差分の同一性はパスだけでなく内容・mode等も含めて確認する。Linear進行での担当間の引き渡しは [workflow.md](workflow.md)、コミット前後の単位照合と完了時の全体照合は [commit](../../skills/commit/SKILL.md) に従う。
+各予定単位について、設定の正本と内容、適用した全ルール（または適用なしの理由）、単位の比較元と全差分、継承後の実効3項目、今回の明示指示、`stage` の許可、検証・レビューの結果を記録する。差分の同一性はパスだけでなく内容・mode等も含めて確認する。Linear進行での担当間の引き渡しは [workflow.md](workflow.md)、コミット前後の単位照合と完了時の全体照合は `commit` に従う。
 
 予定単位の内容・分割・統合を変更したら、変更した単位を再判定して必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。以前の判定や別単位の方針は流用しない。実コミットが予定と異なれば停止し、履歴を無断で書き換えない。
 
@@ -129,6 +129,7 @@ path_policy_overrides:
 | `development_operations` | 任された対象の開発に必要な、既存アカウントへの通常のログイン、ローカル環境準備、プロジェクトの依存導入、開発サーバー・Simulatorの起動停止、ビルド・テスト・QA操作を継続的に許可する。下の範囲に従う |
 | `codex_task` | 対象IssueごとのCodex実装タスクの新規作成・状態確認・実装や修正や許可済みコミットの依頼。アーカイブ、worktree作成、操作許可の追加、タスク側でのゴールや実装タスクの再作成は含めない。ツールの明示依頼要件も満たす。アーカイブの合意と手順は [完了後の整理](codex-task.md#完了後の整理) に従う |
 | `bridge_request` | BridgeによるCodexからClaudeへの実装・修正の依頼と、ClaudeからCodexへの開発進行の引き渡し |
+| `managed_session:<USD>` | 対象IssueごとにClaude Managed Agentsのセッションを作り、同じIssueのコミット前のQA修正には続けて使う（コミット後の修正は新しいセッションで行う。扱いは[Managedセッション](managed-session.md)の「QAと修正」に従う）。`<USD>` は1セッションの予算の上限で、正の整数のUSD（作成時にセントへ換算する）。値がない、または正の整数でない場合は設定不備として止める。含める操作: 作業先のコミット済みの内容（git bundle）と、あれば `~/.claude/CLAUDE.md` のFiles APIへのアップロード、上限内での予算の設定、一覧から名前で一件に特定したvaultの受け渡し、状態・イベント・出力の取得、回答と修正依頼の送信、取得した差分の作業先への適用と作業記録の展開。含めない操作: 上限を超える予算の引き上げ（その場で確認する）、セッションとファイルのアーカイブ・削除、定義のapply、vaultの作成・変更 |
 | `stage` | レビュー・コミットの対象差分だけをステージする |
 | `commit` | 対象Issueの差分を、Local Agent QAの合格と `human_code_review` に従った工程の後に、`shinaps:commit` でローカルにコミットする。AIのコミットには `stage` の許可も併せて必要。push・PR・履歴の書き換え、人のレビューの省略を含めない。パス別の `ai_commit` を含む実効方針に従う（上の「パス別の方針」） |
 | `push` | 対象Issueの作業ブランチの通常のpush |
@@ -139,7 +140,7 @@ path_policy_overrides:
 | `dev_delegation` | `implementation_skill` で選んだdevの入口の中で、サブエージェントへ委託する。許可がない場合は、入口のメインが同じ観点を自分で確認し、独立確認とは報告しない。worktreeの作成は含まない |
 | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
 
-- 開発進行には `issue_update` が必要である。`implementation_skill` がClaudeの入口のときは `bridge_request` も必要で、Codexの入口のときは代わりに `codex_task` とCodexタスクの作成・読み取り・送信のツールが必要である。初期設定では、`issue_update`・`bridge_request`・`stage`・`dev_delegation` を開発進行の標準の組として提案する（Codexの入口を選ぶ場合は `bridge_request` を `codex_task` に置き換える）。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
+- 開発進行には `issue_update` が必要である。`implementation_skill` がClaudeの入口のときは `bridge_request` も必要で、Codexの入口のときは代わりに `codex_task` とCodexタスクの作成・読み取り・送信のツールが必要である。Managedの入口のときは、代わりに `managed_session:<USD>` と `dev_delegation`、および会話側で認証済みの `ant` CLIが必要である（leadは担当を必ずサブエージェントへ委任するため、`dev_delegation` がなければ開始しない）。初期設定では、`issue_update`・`bridge_request`・`stage`・`dev_delegation` を開発進行の標準の組として提案する（Codexの入口を選ぶ場合は `bridge_request` を `codex_task` に、Managedの入口を選ぶ場合は `bridge_request` を `managed_session:<USD>` に置き換える）。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
 - `development_operations` は、既存の認証手段と利用者が許可した既存アカウントを使い、対象の開発・検証環境と専用の検証データで行う操作に限る。本人の二要素認証・セキュリティキー・CAPTCHA等が必要なら具体的に依頼し、回避しない。ログイン成功を新しい権限への同意と扱わず、新規アカウント・OAuth権限の拡大・課金・新規クラウド資源・共有環境への破壊的変更・実利用者データの操作は含めない。秘密値をIssueや証拠へ記載しない。
 - この包括許可は `stage`・`commit`・`push`・`pr_create`・`merge`・`deploy:*`・`publish:*`・外部への送信・履歴やデータの破壊的操作を含まない。テストや環境準備がこれらを伴うときも、それぞれの許可が必要。人レビュー・Human QA・ツール側の承認条件を省略しない。`permissions` に明示された場合だけ適用し、既存設定に自動で追加しない。
 - 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする（マージで本番へ自動配備される場合は `merge` と `deploy:production`）。
@@ -184,7 +185,7 @@ statuses:
   human_input: In Progress
   done: Done
 stop_after: pre_push_qa
-implementation_skill: dev-claude-ultra # CodexがBridgeでClaudeへ依頼する。Codexが実装する場合は dev-codex-ultra など
+implementation_skill: dev-claude # CodexがBridgeでClaudeへ依頼する。Codexが実装する場合は dev-codex など
 human_code_review: required
 commit_mode: autonomous
 path_policy_overrides: []
@@ -266,4 +267,8 @@ sharedでは `.shinaps/.gitignore` 自身、`linear.yaml`、採用した補足
 
 `instructions.md` には、QA固有の注意（端末・ブラウザ・テストアカウントの取得方法への参照）、版の照合に使うコマンド、報告の文体・見せ方、関係者への依頼方法など、プロジェクト共通の条件・手順・相対パス・URLを書く。共通の手順は複製しない。端末固有の絶対パス、session/thread ID、一時的なログイン状態、進捗、QA結果は現在の `.shinaps/work/` へ記録する。秘密値はshared・localのどちらにも保存しない。
 
-委託時は保存方式、正本の所在、必要な補足・参照資料、合意済みの操作許可を渡す。CodexからClaudeへの依頼にも同じ情報を添える。
+委託時は保存方式、正本の所在、必要な補足・参照資料、合意済みの操作許可を渡す。CodexからClaudeへの依頼にも同じ情報を添える。Managedのセッションには[初回メッセージ](managed-session.md#初回メッセージと修正依頼)で渡す。
+
+## 旧dev入口からの移行
+
+通常／ultraの人数指定は廃止した。旧 `dev-claude-ultra`・`dev-codex-ultra`・`dev-managed-cc-ultra` は、それぞれ `dev-claude`・`dev-codex`・`dev-managed-cc` へ設定と呼び出しを移行する。旧名を受け付ける別名は残さない。移行が依頼・許可されている場合はruntime・操作許可・QA・終了地点を保って該当名だけを更新する。未許可の設定変更は依存する実行前に確認する。人数は恒久設定へ保存せず、各作業の体制記録に残す。

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

@@ -14,10 +14,16 @@
 
 対象一覧は最後のページまで読み、作業先・依存・状態・優先順位を確認する。対象IDの一覧、依存順の実行順、開始時点、終了条件を既存の親Issue・依頼元Issueのコメントまたはローカル作業記録へ残す。記録のためだけに親Issueを新設しない。後から追加されたIssue、別Cycle、対象外の依存Issueを自動で取り込まない。順序を変える必要がある場合は理由を記録し、範囲の変更は利用者と合意する。
 
-各Issueの作業先の設定・補足を読み、担当と許可を引き継ぐ。設定がない・不足する対象を他のリポジトリの設定で実行しない。バックログで開始時から進められない場合も、その理由を報告し、独断で対象を除外して消化済みにしない。
+作業先リポジトリは、Issue本文の「対象・範囲外」で特定する。Issueがまだない作業では依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、利用できるセッションの一覧、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。各Issueの作業先の設定・補足を読み、担当と許可を引き継ぐ。操作の許可は作業先リポジトリの設定で決め、同じLinear projectに属するだけでは別のリポジトリの作業を含めない。設定がない・不足する対象は、他のリポジトリの設定で実行せず、開発進行を始めない。バックログで開始時から進められない場合も、その理由を報告し、独断で対象を除外して消化済みにしない。
 
 「このIssueを進めて」などの一般的な進行依頼では、設定の `stop_after` を到達点として記録する。Doneより手前という理由だけで再確認しない。具体的に指定された到達点と設定が矛盾する場合だけ、開始前に相違を解消する。途中の終了地点への到達を、Issue全体の完了とは報告しない。Cycle完了報告を含む依頼で `cycle_report: null` の場合も、設定変更か報告なしの範囲を利用者と合意してから進む。操作許可を暗黙に増やさない。
 
+## Issue開始時の実装体制
+
+進行役のメインは各Issueの設定・受入条件・関連コード・既存検証を短く確認し、[実装体制の判断](../dev/staffing.md)に従って設計担当の起動前に役割・人数・専任なしの責任者・理由を決める。`implementation_skill` は実行環境の選択であり、担当数を固定しない。Issueごとに判断し、Cycleや前のIssueの体制を無条件に流用しない。
+
+初期体制を人へ短く示し、根拠・必須検証・許可範囲とともに実装担当へ渡す。実装側のメインは初期確認と照合し、途中の新しい根拠で必要な担当を増やして進行役へ報告できる。追加担当の確認が必要な工程は結果が揃うまで完了にしない。通常の体制決定・増員は人の承認待ちにせず、仕様・範囲・許可・予算の変更だけ確認する。
+
 ## 継続と待機
 
 原則、確定した順序で一つずつ実行する。Issue単体の依頼では完了後に別Issueへ進まない。複数対象では、現在のIssueのQA・必要な人の対応・コミットを残して次へ切り替えない。
@@ -33,7 +39,7 @@
 
 ## ゴール機能
 
-実行開始の必須条件として、上の対象と終了条件を持つゴールが設定済みであることを確認する。ゴールの作成成功、または同じ対象の既存ゴールの状態をツールで確認してから実装・QA・公開の進行を始める。文章で目標を書くだけでは設定済みとしない。ツールが利用者の明示依頼を要求する場合、スキルの選択だけで迂回せず、既存の明示依頼を使い、なければ開始時に一度確認し、回答と設定成功を待つ。同じ対象のゴールは再利用し、別の未完了ゴールを上書きしない。予算は明示された場合だけ設定する。
+実行開始の必須条件として、上の対象と終了条件を持つゴールが設定済みであることを確認する。ゴールの作成成功、または同じ対象の既存ゴールの状態をツールで確認してから実装・QA・公開の進行を始める。文章で目標を書くだけでは設定済みとしない。ツールが利用者の明示依頼を要求する場合、スキルの選択だけで迂回せず、既存の明示依頼を使い、なければ開始時に一度確認し、回答と設定成功を待つ。同じ対象のゴールは再利用し、別の未完了ゴールを上書きしない。予算は明示された場合だけ設定する。モデルのツールでゴールの設定を確認できないruntimeでは、そのruntimeのlinear-executeの手順が定める確認手段で確認する。確認できなければ下の段落に従って開始前で止まる。
 
 ゴール機能が利用できない、作成に失敗した、または別の未完了ゴールと競合する場合は、理由と必要な準備を報告して実行開始前で止まる。ゴールなしで代替実行しない。
 

package/plugins/shinaps-claude/references/linear/managed-session.md

@@ -0,0 +1,144 @@
+# Managedセッション
+
+作業先の設定の `implementation_skill` が `dev-managed-cc` のときに、IssueごとのClaude Managed Agentsセッションへ実装・修正を依頼し、結果を受け取る手順。進行役は、linear-executeを実行している会話（ClaudeまたはCodex）である（[担当と工程](workflow.md)の「担当と窓口」）。
+
+## 適用と前提
+
+- 必要な許可は [configuration.md](configuration.md) の「許可」に従う。
+- `ant auth login` とvaultの登録は人が行う。AIは認証情報の値を扱わない。
+- 人への確認と待ち方は、runtimeごとのlinear-executeの手順に従う。
+- `beta:` で始まる `ant` のコマンドには `--beta managed-agents-2026-04-01` を付ける（以下の例では省く）。
+
+## 未完了の扱い
+
+IDの取得から適用・展開までのどこかで、完了の条件（最後のメッセージが `状態: 完了`、`出力:` のファイルが揃い、patchとtarが「確認・適用・展開」の確認を通って適用できる）を満たさなかった場合は、すべて同じ扱いにする（例: IDの取得・アップロード・作成・予算の引き上げなど `ant` の失敗、`budget_reached` などでの停止やセッションの終了、状態行がない・`状態: 未完了`、ファイルが揃わない、範囲外の変更、確認や適用の失敗）。`状態: 質問` は「質問への応答」で扱う。
+
+原因、`stop_reason`（あれば）、累計の費用（セッションがあれば、最新の `session.usage` のlist_cost）、leadの報告（あれば）を作業記録に残す。そのうえで、状況に合う選択肢を示して次の対応を一問だけ利用者に確認する（例: 予算の引き上げ額を示して再開、修正依頼、準備を整えて再開、新しいセッションで再開、中止）。
+
+予算の引き上げに合意を得たら、`ant beta:sessions update --session-id <session> --budget '{type: limit, max_list_cost: {amount: "<セント>", currency: USD}}'` を実行し、user.messageで再開を伝える。ブロッカーを報告しただけでは完了にしない（[execution.md](execution.md) の「継続と待機」）。
+
+## 作業ブランチと持ち込み
+
+1. 進行役が、作業先の規約に従った名前で、合意した土台からブランチを切る。
+2. 作業ツリーにHEADとの差（ignoreされていない未追跡ファイルを含む）があれば開始せず、利用者に一問で確認する。
+3. `git bundle create <記録先>/<repo>.bundle <branch>` を作る。この時点の `git rev-parse HEAD` が比較元になる。記録先は進行役の作業記録のディレクトリとする。
+4. 同じセッションを続けて使う間は、進行役による適用と展開を除き、ローカルのHEADと作業ツリーを変えない。変わった後の扱いは「QAと修正」に従う。
+
+## IDの取得、アップロードと作成
+
+一覧は `--max-items -1 --format jsonl` で全件を取り、jqで名前を照合する。
+
+- lead: `ant beta:agents list` の `name` が `shinaps-<入口名>`（例 `shinaps-dev-managed-cc`）
+- environment: `ant beta:environments list` の `name` が `shinaps-dev`
+- vault: `ant beta:vaults list` の `display_name` が `shinaps-ai`
+
+leadとenvironmentが一件に定まらなければ「未完了の扱い」に従う。vaultは一件に定まる場合だけ `--vault-id` で渡し、定まらなければ渡さずに「規約照合は未確認」と記録して進める。vaultはセッションの作成時にしか渡せない。
+
+bundleと、`~/.claude/CLAUDE.md` があればそれも、`ant files upload --file <パス> --expires-in-seconds 604800 --transform id --raw-output` でアップロードし、返されたfile_idを記録する。
+
+セッションは次のように作る。予算は許可の値（USD）の100倍を、セント単位の文字列で書く。CLAUDE.mdがなければ、resourcesはbundleの1つだけにする。
+
+```sh
+ant beta:sessions create --agent <lead> --environment-id <environment> [--vault-id <vault>] \
+  --title "<IssueのID> <題名>" --transform id --raw-output <<'YAML'
+budget: {type: limit, max_list_cost: {amount: "<セント>", currency: USD}}
+resources:
+  - {type: file, file_id: <bundleのfile_id>, mount_path: /<repo>.bundle}
+  - {type: file, file_id: <CLAUDE.mdのfile_id>, mount_path: /CLAUDE.md}
+initial_events:
+  - type: user.message
+    content:
+      - type: text
+        text: |
+          <初回メッセージ>
+YAML
+```
+
+作業記録には、Issue、session_id、入口、ブランチ、比較元、file_id、vaultの有無、予算を残す。
+
+## 観測と判定
+
+判定の境界の時刻tは、最後に送ったuser.messageの `processed_at` とする。
+
+- 送信の結果に送ったeventのIDがあれば、`ant beta:sessions:events list --session-id <session> --type user.message --max-items -1 --format jsonl` からそのIDのeventを探し、`processed_at` が入った時点の値をtとする。
+- IDがない場合（作成時を含む）は、送る前に `processed_at` の入ったuser.messageの件数Nを数えておき、送った後に `processed_at` の入ったuser.messageがN+1件になるまで待つ。そのうえで、それらの最新の `processed_at` をtとする（作成時はN=0）。
+
+idle、`agent.message`、出力ファイルは、すべてtより後のものだけで判定する。
+
+- 待ちを終える条件は、tより後の `session.status_idle` または `session.status_terminated` が現れること。`--type session.status_idle --type session.status_terminated --created-at-gt <t> --max-items 1` で取り、なければ待ち続ける。待つ時間の上限は設けない（費用の上限は予算が担う）。`session.status_terminated` なら「未完了の扱い」に従う。
+- スレッド単位の `session.thread_status_idle` と、再試行中の `session.error` は判定に使わない。担当のスレッドはleadの作業中にも個別にidleになり、再試行中のerrorの後もセッションは続くため。
+
+idleの `stop_reason.type` が `end_turn` なら、tより後の最新の `agent.message` の1行目で分ける。`end_turn` 以外なら「未完了の扱い」に従う。
+
+- `状態: 完了` なら「取り出し」へ進む。
+- `状態: 質問` なら「質問への応答」へ進む。
+- それ以外は「未完了の扱い」に従う。
+
+## 質問への応答
+
+既存の合意で答えられる質問には、一問ずつ答えて「観測と判定」に戻る。仕様・権限を変える判断は人に確認してから答える。
+
+```sh
+ant beta:sessions:events send --session-id <session> --format json <<'YAML'
+events:
+  - type: user.message
+    content:
+      - type: text
+        text: |
+          <回答>
+YAML
+```
+
+## 取り出し
+
+1. `ant beta:files list --scope-id <session> --beta managed-agents-2026-04-01 --max-items -1 --format jsonl` から、`出力:` 行の各名前について、tより後に作られた最新の1件を選ぶ。`--beta` がないと `scope_id: unknown field` で拒否される。
+2. 進行役の作業記録の、ラウンドごとのディレクトリへ `ant files download --file-id <file_id> -o <保存先>` で保存する。
+
+一覧への表示が数秒遅れることがあるので、名前が揃わなければ最大30秒待って1回だけ読み直す。それでも揃わなければ「未完了の扱い」に従う。
+
+## 確認・適用・展開
+
+作業先のルートで、次の順に行う。
+
+1. `tar -tvzf <作業記録のtar.gz>` の一覧で、全項目が作業記録の名前の形（`{YYYYMMDD-HHMMSS}-{slug}`）の一つのディレクトリの下にある普通のファイルかディレクトリで、`..` と絶対パスを含まないことを確かめる。そのディレクトリが `.shinaps/work/` に既にある場合は、同じセッションで前回展開したleadの記録のときだけ可とする。セッションから取得したtarを展開して、進行役や他の作業記録を上書きしないため。
+2. `git apply --numstat <patch>` と `git apply --summary <patch>` で、変更されるパスとmodeをIssueの範囲と照合する。範囲の外があれば「未完了の扱い」に従う。
+3. 今回のpatchが比較元に適用できることを、作業ツリーを変えずに確かめてから適用する。前回のpatchを外した後に今回が適用できないと、作業ツリーがどちらの状態でもなくなるため。
+   - 確認: `idx=$(mktemp)` を実行し、`GIT_INDEX_FILE="$idx" git read-tree <比較元> && GIT_INDEX_FILE="$idx" git apply --cached --check <今回のpatch>` で確かめ、終わったら `rm -f "$idx"` を実行する。
+   - 確認が通ったら、このセッションで前回適用したpatchがあれば `git apply -R <前回のpatch>` を実行し、続けて `git apply <今回のpatch>` を実行する。
+   - 確認や適用が失敗したら、作業先をそのままにして「未完了の扱い」に従う。
+4. `tar -xzf <作業記録のtar.gz> -C .shinaps/work` で展開し、leadの記録のディレクトリ名を作業記録に残す。
+5. 検証コマンドは、この後に実行する。
+
+## QAと修正
+
+適用した時点を「差分と対象版の固定」とし、[codex-task.md](codex-task.md) の「待機・QA・修正」と同じように扱う。不合格なら修正を依頼する。
+
+- 前回の適用の後に、進行役による適用と展開のほかに作業ツリーが変わっておらず、比較元の後にコミットもしていない場合は、下の修正依頼を同じセッションへ送り、「観測と判定」に戻る。
+- コミットの後で、作業ツリーにHEADとの差（進行役が展開した作業記録を除く）がない場合は、同じセッションへ送らない。leadの差分と今の作業ツリーが合わなくなるため。「作業ブランチと持ち込み」の手順2から（ブランチはそのまま使う）、現在のHEADでbundleと比較元を作り直し、新しいセッションを作る。予算は許可の上限まで改めて設定する。初回メッセージの「タスク」には、不具合と前回までの経緯を書く（前回のleadの作業記録はbundleに含まれない）。
+- それ以外（コミットされていない人の修正がある）は、新しいセッションを作らず「未完了の扱い」に従う（選択肢の例: 人がコミットしてから新しいセッションで再開、中止）。
+
+## Managed固有の読み替えと記録
+
+- [単位案からコミット完了まで](workflow.md#単位案からコミット完了まで)の手順2は、依頼を送らず、進行役が許可と記録の一致を確かめる手順として読む。手順3は、進行役が `commit` に従って行う。
+- 各idleでの累計の費用と最終の費用を、作業記録とIssueの記録に残す。
+
+## 初回メッセージと修正依頼
+
+初回メッセージ:
+
+```text
+初期体制: <役割別人数・根拠・専任なしの責任者・必須検証。leadは現物と照合し、必要な増員を予算と許可内で行い報告する>
+Linear進行の実装依頼として、skill dev-managed-cc の工程と起動手順に従ってください。
+作業先: /mnt/session/uploads/<repo>.bundle をブランチ <branch> で /workspace/<repo> に用意する。比較元 <SHA>。
+タスク: <Issueの識別子とリンク>。<範囲・受入条件・範囲外・仕様や調査成果物の本文。leadはLinearを読めない>。必要な検証: <references.validation に従うコマンド>。
+設定: 保存方式 <shared|local>。正本 <作業先の .shinaps/linear.yaml。bundleに含まれるか>。読む補足 <references のうち工程に必要なもの>。正本や補足がbundleに含まれない場合（`local` など）は、その本文をこの欄に写す。
+前提: <CLAUDE.mdを添付した場合だけ: 利用者共通方針は /mnt/session/uploads/CLAUDE.md>。規約照合: <vaultあり | vaultなし。取得できなければ未確認として進める>。許可範囲: devの入口の中の委託（dev_delegation）。コミット・push・PR作成・Issueの更新・ant apply はしない。仕様・権限の不明点は一問ずつ質問してターンを終える。通常の実装判断は任せる。
+報告: 最終報告に、変更範囲、検証結果、dev内レビューの結果と未解決の指摘、起動方法、未解決事項、コミット単位案と単位ごとの予定差分（references/linear/workflow.md「単位案からコミット完了まで」の1）を含める。
+```
+
+修正依頼（同じセッションへのuser.message）:
+
+```text
+Local Agent QAで不合格。skill <入口> の工程で、修正依頼として Phase 1 から進める。前回の作業記録 .shinaps/work/<dir>/ を引き継ぎ資料とする。比較元 <SHA>。
+不具合: <再現手順・期待と実際・対象差分・証拠>
+```

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

@@ -8,7 +8,9 @@
 | 実装担当 | 技術調査、`implementation_skill` で選んだdevの入口による実装・自動テスト・簡素化・セルフレビュー、QA指摘の修正、成果と人の対応結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
 | 人 | 未合意の仕様・権限の判断、設定で必要なコードレビュー・必要な修正、AIに許可していないコミット、本人の操作が必要な認証等、必要なHuman QA |
 
-実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口（`dev-claude`・`dev-claude-ultra`）では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口（`dev-codex`・`dev-codex-ultra`）では、この文書でClaudeが行うとした実装・修正・コミット・完了報告を会話側とは別のCodex実装タスクが行い、[Codex実装タスク](codex-task.md)の手順で依頼・結果を扱う。Bridgeは使わない。どちらでも実装担当はdev内レビューと検証を終えて進行役へ結果を返し、進行役がLocal Agent QAを行う。実装担当の報告をQA合格の根拠にせず、この引き渡しを進行全体の終了と扱わない。
+実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口（`dev-claude`）では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口（`dev-codex`）では、この文書でClaudeが行うとした実装・修正・コミット・完了報告を会話側とは別のCodex実装タスクが行い、[Codex実装タスク](codex-task.md)の手順で依頼・結果を扱う。Bridgeは使わない。どちらでも実装担当はdev内レビューと検証を終えて進行役へ結果を返し、進行役がLocal Agent QAを行う。実装担当の報告をQA合格の根拠にせず、この引き渡しを進行全体の終了と扱わない。
+
+Managedの入口（`dev-managed-cc`）では、linear-executeを実行している会話（ClaudeまたはCodex）が進行役になり、`linear/` の各文書でCodexが行うとした進行・Agent QA・記録・人への窓口を行う。実装・修正はIssueごとのClaude Managed Agentsセッションのleadがその入口のskillで行い、[Managedセッション](managed-session.md)の手順で依頼・結果を扱う。この文書でClaudeまたは実装担当が行うとした実装・修正・完了報告はleadが行う。leadはローカルの作業先へ書けないため、差分の適用・コミットと、人の対応結果の受け取りは進行役が行う。BridgeとCodex実装タスクは使わない。
 
 人への質問と依頼は会話側のCodexが窓口になる。実装担当は人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
 
@@ -69,11 +71,11 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 ### 単位案からコミット完了まで
 
-以下はClaude・Codexの両実装方式に共通する。単位計画の作成・確認にはコミット許可を要求しない。
+以下はすべての実装方式に共通する（Managedの入口での手順2・3の読み方は、[Managedセッション](managed-session.md)の「Managed固有の読み替えと記録」にある）。単位計画の作成・確認にはコミット許可を要求しない。
 
 1. 実装担当は成果引き渡しに、モードによらず自然な責務で決めたコミット単位案と予定差分を含める。進行役のCodexはLocal Agent QAで対象を検証し、単位案が依頼全体を漏れなく覆い対象外変更を含まないことと、各単位の[判定記録](configuration.md#判定記録と変更時の扱い)を確認する。依頼の比較元と全体差分も最終照合用に記録する。
 2. 人レビューを待つかAIコミットを依頼するかは、各単位の実効方針で決める。QA合格とその単位に必要な人レビュー・AIコミット・stageの許可が揃ったら、CodexはQA結果、単位の判定記録、人レビュー完了の証拠または省略根拠を添えて実装担当へ依頼する。担当は設定・予定差分と記録の一致、許可を確認し、不一致なら実行せず進行役へ返す。
-3. 実装担当は [commit](../../skills/commit/SKILL.md) に従い、各単位のモードに応じた承認・隔離・検証・レビューを行う。同じ依頼内に通常・自律の単位が混在してよい。各コミット直前・作成後の実差分をその単位の予定差分と照合し、予定単位・SHA・照合結果・検証とレビュー結果を進行役へ返す。
+3. 実装担当は `commit` に従い、各単位のモードに応じた承認・隔離・検証・レビューを行う。同じ依頼内に通常・自律の単位が混在してよい。各コミット直前・作成後の実差分をその単位の予定差分と照合し、予定単位・SHA・照合結果・検証とレビュー結果を進行役へ返す。
 4. 全単位完了後、Codexは各コミットの単位照合結果を実差分で独立確認したうえで、依頼の比較元からの全体差分が対象と一致し、対象の未コミット変更が残っていないことを照合する。最終差分だけでは途中で混入し後で相殺された対象外変更を検出できないため、単位照合を省かない。人レビューを省略した単位は、上の省略記録を完成させる。
 5. 単位の組み替え・内容・設定の変更は[変更時の扱い](configuration.md#判定記録と変更時の扱い)に従って再判定し、必要なレビュー・許可確認・検証へ戻す。実コミットに不一致があれば次工程を止め、SHA・予定差分・実差分の違いを記録して人に確認する。履歴を無断で書き換えない。
 
@@ -93,9 +95,9 @@ AI Terminal Bridge（以下Bridge）の本体は同梱しない。導入済み
 
 | 依頼・報告 | 含めるもの |
 | --- | --- |
-| 実装・修正の依頼（CodexからClaude） | Issueリンク、使う入口（`implementation_skill` の値、またはその場の明示的な指定）、範囲・受入条件、Gitの作業ディレクトリ・ブランチ・既存差分、許可範囲（`dev_delegation` の有無を含む）、返信先のCodexの `session_id`、関係する補足と参照先、下の定型文。修正依頼では、再現手順・期待と実際・対象差分・証拠の場所を加える |
+| 実装・修正の依頼（CodexからClaude） | Issueリンク、使う入口（`implementation_skill` の値、またはその場の明示的な指定）、範囲・受入条件、初期体制（役割別人数・根拠・専任なしの責任者・必須検証）、Gitの作業ディレクトリ・ブランチ・既存差分、許可範囲（`dev_delegation` の有無を含む）、返信先のCodexの `session_id`、関係する補足と参照先、下の定型文。修正依頼では、再現手順・期待と実際・対象差分・証拠の場所を加える |
 | コミットの依頼（CodexからClaude） | Issueリンク、Gitの作業ディレクトリ・ブランチ、返信先のCodexの `session_id` と、上の「単位案からコミット完了まで」で定める依頼情報 |
-| 完了の報告（ClaudeからCodex） | 対象差分、自動検証の結果、起動方法、確認観点、既知の制限、未解決の事項、devの入口内のレビュー結果の要約と未解決の指摘。コミットした場合の返却情報は上の「単位案からコミット完了まで」に従う |
+| 完了の報告（ClaudeからCodex） | 対象差分、自動検証の結果、起動方法、確認観点、既知の制限、未解決の事項、初期体制からの変更と理由、実際の担当と確認範囲、devの入口内のレビュー結果の要約と未解決の指摘。コミットした場合の返却情報は上の「単位案からコミット完了まで」に従う |
 | 人のレビュー・コミット完了の報告（ClaudeからCodex） | 下の「人のレビュー・コミット完了の報告」の項目 |
 | 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle・バックログの範囲と順序、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先リポジトリの設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
 
@@ -105,7 +107,8 @@ AI Terminal Bridge（以下Bridge）の本体は同梱しない。導入済み
 
 ```text
 ユーザー承認済みの範囲でCodexが進行する。shinaps:linear-executeを読み込み、この依頼の範囲と受入条件の中では人へ着手を再確認せず、指定した入口で実行する。計画の相談・質問・障害・完了はBridgeで依頼元のCodexへ返す。人のレビュー・コミット完了を受けた場合も同じ返信先へ報告する。
-入口: shinaps:<dev-claude または dev-claude-ultra>
+入口: shinaps:dev-claude
+初期体制: <役割別人数・根拠・専任なしの責任者・必須検証。途中の増員はdevのメインが判断して進行役へ報告する>
 許可範囲: <設定と会話で許可された操作。dev_delegationの有無を含む>
 ```
 
@@ -127,6 +130,8 @@ Bridgeの報告は、新しい公開や破壊的な操作の許可を作らな
 
 Code Reviewを依頼する前に対象差分を確認する。`stage` の許可がある場合だけ、対象だけをステージする。`git diff --cached` と `git status --short` で、新規ファイルの漏れと無関係な差分の混入を確認する。ステージにコミットは含めない。許可がなければ、ステージを人への依頼に含める。
 
+人レビューの差分提示は[共通手順](../human-review.md)に従う。
+
 会話でIssueリンクと必要な作業を明示し、ステータスの変更だけで依頼を済ませない。
 
 | 依頼 | 文例 |

package/plugins/shinaps-claude/skills/commit/SKILL.md

@@ -53,6 +53,8 @@ Git操作と修正は現在のセッションが行う。独立レビューは
 
 ## 単位ごとの検証・レビュー・コミット
 
+人レビューまたは通常モードの単位承認を依頼するときは、[人レビューの差分提示](../../references/human-review.md)に従う。CodexではPlasmaを開いてコミット対象と表示差分を照合する。Linear進行で同じ差分の人レビューが完了済みなら、その証拠を引き継ぎ、同じレビューを重ねて依頼しない。通常モードの単位承認は別の条件として扱う。
+
 以下を、その単位のモードで行う。
 
 1. 単位案を短く示す。通常モードで複数の単位に分ける場合、許可された独立レビュアーがいれば、各単位の差分だけで人が妥当性を判断できるかを差分自体から確認させ、結論はメインが実際の差分で検証する。自律モードでは単位案の独立レビューを求めない（プロジェクトの必須条件にある場合は従う）。

package/plugins/shinaps-claude/skills/debug/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: debug
-description: バグ報告・不具合の根本原因を多角的に調査し、対症療法ではなく根本解決を導くスキル。コードトレース + WebSearch + GitHub Issue 検索で仮説を立て、実コード検証で確定させ、必要に応じて shinaps-tech-surveyor + shinaps-survey-validator で外部情報を深掘りし、/shinaps:dev-claude-ultra に橋渡しする。既存の調査・実装成果物と rule カタログを仮説候補の予選材料に使う
+description: バグ報告・不具合の根本原因を多角的に調査し、対症療法ではなく根本解決を導くスキル。コードトレース + WebSearch + GitHub Issue 検索で仮説を立て、実コード検証で確定させ、必要に応じて shinaps-tech-surveyor + shinaps-survey-validator で外部情報を深掘りし、/shinaps:dev-claude に引き継ぐ。既存の調査・実装成果物と rule カタログを仮説候補の優先順位付けに使う
 argument-hint: <なし | エラーメッセージ / 症状の説明 | ファイルパス>
 ---
 
@@ -80,7 +80,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 - プロジェクト `CLAUDE.md` 全文
 - **Phase 1 で作成した既存成果物の要約**
 - **前準備の `search_rules` 結果 (userRules + officialRules 全文)**
-- 「対症療法ではなく根本原因を特定せよ。既存成果物 と rule カタログを仮説予選材料に使う」
+- 「対症療法ではなく根本原因を特定せよ。既存成果物 と rule カタログを仮説の優先順位付けに使う」
 - trace モードの場合: 起点ファイル指定
 
 **記録先**: メインが Write で `debug-report.md`
@@ -103,10 +103,10 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 - 症状が特定 library / framework 依存
 - 環境依存 (OS / runtime version) の疑い
 
-実施する場合、`shinaps-tech-surveyor` → `shinaps-survey-validator` の 2 段パイプ。
+実施する場合、`shinaps-tech-surveyor` → `shinaps-survey-validator` の順に 2 段階で実行する。
 
 - **shinaps-tech-surveyor プロンプト**: `input.md` + `debug-validated.md` + `search_rules` 結果 + 「関連 library / API の既知バグ / breaking change / 挙動仕様を WebSearch + GitHub Issue で調査」
-- **shinaps-survey-validator プロンプト**: `raw/survey.md` 全文 + `search_rules` 結果 + 「出典 URL を再確認、CLAUDE.md / rule 逆行する候補は Critical」
+- **shinaps-survey-validator プロンプト**: `raw/survey.md` 全文 + `search_rules` 結果 + 「出典 URL を再確認、CLAUDE.md / rule に反する候補は Critical」
 
 **記録先**: メインが Write で `raw/survey.md` / `raw/survey-validated.md`
 
@@ -115,18 +115,18 @@ Phase 4.5 実施後、`debug-validated.md` を更新して「## 関連する外
 ### Phase 5: 次アクション選択
 
 root-cause または contributing-factor が 1 件以上あれば `AskUserQuestion` で:
-- **修正実装に進む** (`/shinaps:dev-claude-ultra` へ橋渡し) (推奨)
+- **修正実装に進む** (`/shinaps:dev-claude` へ引き継ぐ) (推奨)
 - **追加調査を依頼する** (Phase 7 へ)
 - **保存のみで終了**
 
 **根本原因確定時に ローカル成果物（implementation.md / 調査・レビューレポート）** で「症状 → 根本原因 → 修正方針」を記録。
 
-### Phase 6: /shinaps:dev-claude-ultra への橋渡し (修正実装選択時)
+### Phase 6: /shinaps:dev-claude への引き継ぎ (修正実装選択時)
 
-`debug-validated.md` のパスを渡す。dev の入口は Phase 1 でこのファイルを読み、root-cause / contributing-factor を修正タスクとして扱う。利用者が1体での実行を指定した場合は `shinaps:dev-claude` を使う。
+`debug-validated.md` のパスを渡す。dev の入口は Phase 1 でこのファイルを読み、root-cause / contributing-factor を修正タスクとして扱う。担当と人数はdevのメインが作業に応じて判断する。
 
 ```
-Skill(skill="shinaps:dev-claude-ultra", args="以下のデバッグ結果に基づき根本原因を修正する。詳細は .shinaps/work/debug/{ts}-{slug}/debug-validated.md を参照: {根本原因の 1 行サマリ}")
+Skill(skill="shinaps:dev-claude", args="以下のデバッグ結果に基づき根本原因を修正する。詳細は .shinaps/work/debug/{ts}-{slug}/debug-validated.md を参照: {根本原因の 1 行サマリ}")
 ```
 
 ### Phase 7: 追加調査 (選択時)
@@ -138,7 +138,7 @@ Skill(skill="shinaps:dev-claude-ultra", args="以下のデバッグ結果に基
 - **根本原因志向**: 対症療法を推奨しない、根本解決を導く
 - **多角的調査**: コード + docs + WebSearch + GitHub Issue を組み合わせる
 - **二段検証**: debugger の仮説を debug-validator が必ず実コードで検証
-- **rule と既存成果物を仮説予選に活用**: `search_rules` の結果と、今回の依頼に関連する Git・spec・raw report の根拠を debugger prompt に埋め込む
+- **rule と既存成果物を仮説の優先順位付けに活用**: `search_rules` の結果と、今回の依頼に関連する Git・spec・raw report の根拠を debugger prompt に埋め込む
 - **subagent は文字列応答のみ**: ファイル書き込みは必ずメインが担当
 - **生レポート保存厳守**: すべての subagent 応答を全文保存
-- **根本原因確定時に ローカル成果物（implementation.md / 調査・レビューレポート）**: 未来の自分と別 AI agent が辿れるように
+- **根本原因確定時に ローカル成果物（implementation.md / 調査・レビューレポート）**: 後の作業者と別 AI agent が辿れるように

package/plugins/shinaps-claude/skills/dev-claude/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: dev-claude
-description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化をそれぞれ1体で確認する。実装依頼で1体での実行を指定されたときに使う。コミットは許可と工程の条件に従い、Linear進行ではQAへ結果を返す。
-argument-hint: <実装したい機能・解決したい課題>
+description: 実装の不確実性・影響範囲・失敗時の影響から必要な担当と人数を決め、計画・実装・検証・独立レビューを進める。途中の新しい根拠で体制を追加する。コミットは許可に従い、Linear進行ではQAへ結果を返す。
 ---
 
-# 開発（同じ役割 1 体）
+# 作業に応じた体制で開発する
 
-同じ役割の担当数は 1 体。[工程](../../references/dev/workflow.md)と[起動手順](../../references/dev/launch.md)を読み、この担当数で進める。
-タスクの確定は[工程](../../references/dev/workflow.md)の Phase 1 に従う（引数が無いだけでは終了しない）。
+[体制の判断](../../references/dev/staffing.md)・[工程](../../references/dev/workflow.md)・[起動手順](../../references/dev/launch.md)を読む。人数を入口名で固定しない。linear-executeから渡された初期体制を引き継ぎ、なければメインが関連コードを確認して設計前に決める。途中でも必要な役割・人数を追加する。
+
+依頼や成果物からタスクが確定していれば、形式的な引数の再入力を求めずPhase 1から進める。

package/plugins/shinaps-claude/skills/explore/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: explore
-description: バグか確定していない違和感、既存挙動の「なぜ」、実装方針や変更影響について、人間が理解・納得できるまで質問を重ねる対話型 read-only 調査スキル。質問ごとにコード、テスト、設定、git history、必要な公式情報を調べ、confirmed / inference / unknown を分けて根拠付きで回答する。debug のように根本原因確定を急がず、spec のように仕様策定を目的にせず、実装は行わない。理解が揃い実装内容に合意したら exploration.md を /shinaps:dev-claude-ultra に直接橋渡しする。「今の実装はどうなっている？」「なぜこうなる？」「この変更はどこに効く？」「実装前に一緒に調べたい」「質問しながら理解したい」で使う
+description: バグか確定していない違和感、既存挙動の「なぜ」、実装方針や変更影響について、人間が理解・納得できるまで質問を重ねる対話型 read-only 調査スキル。質問ごとにコード、テスト、設定、git history、必要な公式情報を調べ、confirmed / inference / unknown を分けて根拠付きで回答する。debug のように根本原因確定を急がず、spec のように仕様策定を目的にせず、実装は行わない。理解が揃い実装内容に合意したら exploration.md を /shinaps:dev-claude に直接渡す。「今の実装はどうなっている？」「なぜこうなる？」「この変更はどこに効く？」「実装前に一緒に調べたい」「質問しながら理解したい」で使う
 argument-hint: <調べたいバグ・挙動・実装上の疑問（省略可）>
 ---
 
@@ -25,7 +25,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 | `shinaps:explore` | 現状・因果・選択肢を対話で理解する | `exploration.md` |
 | `shinaps:debug` | 具体的な不具合の根本原因を仮説検証で確定する | `debug-validated.md` |
 | `shinaps:spec` | 要望と受け入れ条件を確定する | `spec.md` |
-| `shinaps:dev-claude-ultra`（1体は `shinaps:dev-claude`） | 計画し、実装・検証・セルフレビューする | コード + `implementation.md` |
+| `shinaps:dev-claude` | 計画し、実装・検証・セルフレビューする | コード + `implementation.md` |
 
 `explore` では最初から「バグ」「採用案」「修正対象」を決めつけない。調査中に不具合らしさが高まっても、自動で `debug` や dev の入口へ移らず、人間の質問に答え続ける。
 
@@ -55,7 +55,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 ```
 .shinaps/work/explorations/{YYYYMMDD-HHMMSS}-{slug}/
-├── exploration.md                 ← 現在の理解と dev handoff 契約を保つ living document
+├── exploration.md                 ← 現在の理解と dev handoff 契約を保つ、随時更新する文書
 ├── question-log.md                ← 質問と回答の要約。会話の逐語録にはしない
 └── raw/
     ├── investigation-001.md       ← 各ラウンドの investigator 生レポート
@@ -115,7 +115,7 @@ investigator の回答をそのまま転送しない。結論を支える主要
 - production deploy、外部データ変更、依存追加など調査を越える操作は行わない
 - 確認できない主張は `inference` または `unknown` に下げ、解消に必要な証拠を示す
 
-### Phase 4: 回答と living document 更新
+### Phase 4: 回答と exploration.md 更新
 
 各ラウンドの回答は次の順で短く提示する。
 
@@ -123,7 +123,7 @@ investigator の回答をそのまま転送しない。結論を支える主要
 2. **確認できたこと (`confirmed`)** — file:line / test / docs URL を添える
 3. **推測 (`inference`)** — 推測である理由と確信度を添える
 4. **まだ分からないこと (`unknown`)** — 何を見れば確定できるかを添える
-5. **次に掘る価値が高い論点** — 最大 3 件
+5. **次に調べる価値が高い論点** — 最大 3 件
 
 回答後、`question-log.md` には質問と回答の要約だけを追記し、`exploration.md` を現在の理解へ更新する。confirmed finding を支えるローカルファイルは、現在内容の hash (`git hash-object` など、object を書き込まない read-only 計算) を関連リソースへ記録する。過去の誤った仮説を残す必要がある場合は「却下済み」と明記し、現在の結論と混ぜない。
 
@@ -180,7 +180,7 @@ investigator の回答をそのまま転送しない。結論を支える主要
 
 実装内容がまだ曖昧な状態で「実装へ進む」が選ばれたら、望む変更を 1 問ずつ確認する。未解決点が残る場合は、残したまま実装するか調査を続けるかを選んでもらう。
 
-### Phase 6: `/shinaps:dev-claude-ultra` への橋渡し
+### Phase 6: `/shinaps:dev-claude` への引き継ぎ
 
 実装へ進む前に `exploration.md` の「実装 handoff」セクションを確定する。
 
@@ -195,10 +195,10 @@ handoff 直前に confirmed 根拠の content hash を再計算し、`evidenceSn
 
 安定した設計判断や再利用価値のある発見だけをローカル成果物（implementation.md / 調査・レビューレポート）へ短く記録する。質問ログや長いコード引用は記録しない。
 
-中間 handoff ファイルは作らず、`exploration.md` のパスを直接渡す。利用者が1体での実行を指定した場合は `shinaps:dev-claude` を使う。
+中間 handoff ファイルは作らず、`exploration.md` のパスを直接渡す。担当と人数はdevのメインが作業に応じて判断する。
 
 ```
-Skill(skill="shinaps:dev-claude-ultra", args="以下の対話調査で合意した変更を実装する。詳細は .shinaps/work/explorations/{ts}-{slug}/exploration.md を参照: {実装目的の 1 行サマリ}")
+Skill(skill="shinaps:dev-claude", args="以下の対話調査で合意した変更を実装する。詳細は .shinaps/work/explorations/{ts}-{slug}/exploration.md を参照: {実装目的の 1 行サマリ}")
 ```
 
 dev の入口は「実装 handoff」の `status: ready` と `evidenceSnapshot` の内容ハッシュを確認してから合意済み変更・confirmed findings・未解決点を取り込む。`exploration.md` と同ディレクトリの `raw/investigation-*.md` を既存実装調査として再利用し、情報が不足・陳腐化している場合だけ `shinaps-explorer` で補完する。

package/plugins/shinaps-claude/skills/extract-rules/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: extract-rules
-description: 過去 PR のレビューコメントから shinaps-ai の rules を bulk 生成する skill。新規リポジトリ着手時、または search_rules の userRules が空 / 少ない (5 件未満) ときに提案・起動。owner / repo / since を確認し、bot 除外 + gh api pulls で 100 PR ブロック単位に fetch → LLM で規約抽出 → record_rules で投入 → 続行確認 → 完了 report まで完走。shinaps-ai server 未登録時は search_rules 呼び出しが自動で失敗して abort する。
+description: 過去 PR のレビューコメントから shinaps-ai の rules を bulk 生成する skill。新規リポジトリ着手時、または search_rules の userRules が空 / 少ない (5 件未満) ときに提案・起動。owner / repo / since を確認し、bot 除外 + gh api pulls で 100 PR ブロック単位に fetch → LLM で規約抽出 → record_rules で投入 → 続行確認 → 完了 report まで実行する。shinaps-ai server 未登録時は search_rules 呼び出しが自動で失敗して abort する。
 argument-hint: (引数なし、対話で owner-repo / since を確認)
 ---
 
@@ -18,7 +18,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 # shinaps:extract-rules — 過去 PR review から rules を bulk 生成
 
-新規リポジトリ着手時、または既存 userRules が薄いときに、過去 PR のレビューコメントから規約を bulk import する skill。shinaps-ai サーバは GitHub API も LLM も呼ばず、すべて Claude Code 側のあなた (= AI) が `gh` / 既存 MCP tools 経由で実行する (token / repo 内容をサーバ境界に置かない)。
+新規リポジトリ着手時、または既存 userRules が少ないときに、過去 PR のレビューコメントから規約を bulk import する skill。shinaps-ai サーバは GitHub API も LLM も呼ばず、すべて Claude Code 側のあなた (= AI) が `gh` / 既存 MCP tools 経由で実行する (token / repo 内容をサーバ境界に置かない)。
 
 ## Step 0. 対象 repo を環境から決定する (MUST)
 
@@ -63,7 +63,7 @@ PR description (本文) は対象外。あくまで「レビュー観点」を
 
 ## Step 6. 既存 rules 把握
 
-100 PR を 1 ブロックとして処理する。ブロックの開始時に必ず shinaps-ai MCP server の `search_rules({ repoOwner, repoName })` を呼んで、既存 userRules を取得する (facet を渡さないので officialRules は空、userRules は継承マージで scope=user / repo_owner / repo の全件、最大 200)。これを「新規 (= `record_rules` の投入対象に含める) か、既存に被せる `update_rule` か」を判断する material にする。
+100 PR を 1 ブロックとして処理する。ブロックの開始時に必ず shinaps-ai MCP server の `search_rules({ repoOwner, repoName })` を呼んで、既存 userRules を取得する (facet を渡さないので officialRules は空、userRules は継承マージで scope=user / repo_owner / repo の全件、最大 200)。これを「新規 (= `record_rules` の投入対象に含める) か、既存 rule を更新する `update_rule` か」を判断する材料にする。
 
 ## Step 7. rules 生成と投入
 
@@ -86,7 +86,7 @@ Good/Bad サンプルコード (examples) の付け方:
 
 投入手順:
 
-- 候補を既存 rules と照合し、**新規** (該当 rule 不在) だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, rules: [{ title, why, recommend?, avoid?, kind?, labels?, examples?, sourceUrls? }, ...] })` で **1 call bulk 投入** する。`labels` は language / platform / framework / topic の slug 配列 (`list_search_facets` の master 登録済みのみ、language/platform/framework は 1 rule に各 1 つまで) (1 call 最大 100 件、超えたら分割。同一 title の重複は入力段階で INPUT_INVALID)。extract-rules は対象 repo の PR レビューから抽出する性質上 scope=repo (当該 repo 限定) がデフォルト。横断ルールとして残したい場合だけユーザー判断で `scope: 'user'` に格上げ。**格上げするときは why / recommend / avoid / examples を当該 repo の固有文脈 (内部 API 名・モジュール構成・ドメイン固有の識別子) から切り離し、他プロジェクトでも適用イメージが湧く汎用的な表現・汎用サンプルに解釈し直してから登録する** (scope=repo のままなら repo 固有の具体的な記述・コード片で良い)。title は 200 字以内、規約本文は why (必須、なぜこの規約か、2000 字以内) / recommend (推奨行動、任意、1000 字以内) / avoid (避けるべきこと、任意、1000 字以内) の 3 フィールドに構造化する
+- 候補を既存 rules と照合し、**新規** (該当 rule 不在) だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, rules: [{ title, why, recommend?, avoid?, kind?, labels?, examples?, sourceUrls? }, ...] })` で **1 call bulk 投入** する。`labels` は language / platform / framework / topic の slug 配列 (`list_search_facets` の master 登録済みのみ、language/platform/framework は 1 rule に各 1 つまで) (1 call 最大 100 件、超えたら分割。同一 title の重複は入力段階で INPUT_INVALID)。extract-rules は対象 repo の PR レビューから抽出する性質上 scope=repo (当該 repo 限定) がデフォルト。横断ルールとして残したい場合だけユーザー判断で `scope: 'user'` に格上げ。**格上げするときは why / recommend / avoid / examples を当該 repo の固有文脈 (内部 API 名・モジュール構成・ドメイン固有の識別子) から切り離し、他プロジェクトでも適用場面を想定できる汎用的な表現・汎用サンプルに解釈し直してから登録する** (scope=repo のままなら repo 固有の具体的な記述・コード片で良い)。title は 200 字以内、規約本文は why (必須、なぜこの規約か、2000 字以内) / recommend (推奨行動、任意、1000 字以内) / avoid (避けるべきこと、任意、1000 字以内) の 3 フィールドに構造化する
 - 戻り値の `skipped: { title, existingRuleId, existingWhy, existingRecommend, existingAvoid, existingLabels, existingExamples, existingSourceUrls }[]` は「既存と title 重複して投入されなかった候補」。新しい why/recommend/avoid と existing* が異なるなら **ユーザーに diff を提示して同意を取る** (examples / sourceUrls の差分も同様):
 
 > 既存 rule "no-unused-vars" が見つかりました。why/recommend/avoid の差分:

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

@@ -1,11 +1,15 @@
 ---
 name: linear-execute
-description: Linearの実行でCodexから受けた実装・修正・コミット依頼を実行し結果を報告する。直接の開発進行依頼は設定と許可を確認してCodexへ引き渡す。相談・Issue整理はlinear-planを使う。
+description: Linearの開発で、Codexから受けた実装・修正・コミット依頼を実行する。作業先の設定の実装担当がManagedの入口なら、Claudeが進行役として実装からQA・許可された公開まで進める。それ以外の開発進行依頼はCodexへ引き渡す。相談・Issue整理はlinear-planを使う。
 ---
 
 # Linearの開発でClaudeが行うこと
 
-初版では、Codexが進行・Agent QA・人への窓口を担当する。作業先リポジトリの設定の `implementation_skill` がClaudeの入口のとき、ClaudeはAI Terminal Bridge（以下Bridge）経由の依頼で、技術調査と実装・修正を担当する。担当を入れ替えない。
+開発進行を依頼されたら、まず[設定の読み方](../../references/linear/configuration.md#設定の読み方)で作業先の設定を読み、`implementation_skill` で役割を決める。設定が真に未設定なら、下の「Codexの依頼なしで起動された場合」の初期設定へ進む。
+
+- Claudeの入口（`dev-claude`）では、Codexが進行・Agent QA・人への窓口を担当する。ClaudeはAI Terminal Bridge（以下Bridge）の受け手として、技術調査と実装・修正を担当し、「読む資料」「依頼を受けて実行する」「結果と人の対応を報告する」に従う。担当を入れ替えない。
+- Managedの入口（`dev-managed-cc`）の開発進行では、Claudeが進行役になり、「Managedの入口で進行する」にだけ従う。
+- Codexの入口（`dev-codex`）では、開発進行をCodexへ引き渡す。
 
 ## 再確認せず進める条件
 
@@ -25,7 +29,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 
 - 依頼の範囲・受入条件・Gitの作業ディレクトリ・ブランチ・既存差分・許可範囲を確認する。
 - Codexから依頼された実装・修正は、依頼の対象Issueに紐づく。Claudeは別のIssueを作らない。
-- 実装・修正には、依頼で指定された入口（`shinaps:dev-claude` または `shinaps:dev-claude-ultra`）を使う。指定と設定を照合し、欠落・不一致ならCodexへ確認してから進め、受信側で入口を変えない。devの入口は内部で簡素化・規約照合・レビューを行うので、これらを別に起動しない。入口を使えない場合は、独自の手順で代わりに実装せずCodexへ報告する。
+- 実装・修正には、依頼で指定された入口（`shinaps:dev-claude`）を使う。指定と設定を照合し、欠落・不一致ならCodexへ確認してから進め、受信側で入口を変えない。devの入口は内部で簡素化・規約照合・レビューを行うので、これらを別に起動しない。入口を使えない場合は、独自の手順で代わりに実装せずCodexへ報告する。
 - devの入口の委託（サブエージェント）は、依頼の許可範囲に `dev_delegation` が書かれている場合だけ使う。許可範囲に `dev_delegation` がない依頼では委託しない。worktreeの作成は含まない。
 - devの入口が利用者に確認する場面（計画の判断、不明点、承認）では、人ではなくCodexへ相談する。Codexが既存の合意で答えた内容を人へ再確認しない。仕様・受入条件・許可範囲の変更が必要な場合は、Codexが人に確認する。
 - QAで見つかった不具合の修正依頼も同じ扱いにし、人の着手許可を改めて取らない。
@@ -37,10 +41,33 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 - 完了の報告と、人のレビュー・コミット完了の報告に含める項目は、[references/workflow.md](../../references/linear/workflow.md) の「Bridgeでの依頼と報告」に従う。
 - 人へ着手の確認やコミットの依頼をしない。人がClaudeへ直接伝えた指示や結果は保持し、Codexへ報告する。Gitにコミットがあるだけで、人のレビュー済みと報告しない。設定で人のレビューを省略した場合は、省略と報告する。
 
+## Managedの入口で進行する
+
+実行範囲、開始時に固定するもの、継続とゴールは [execution.md](../../references/linear/execution.md) に従う。必要な許可は [configuration.md](../../references/linear/configuration.md) の「許可」に従う。実装・修正は [managed-session.md](../../references/linear/managed-session.md) の手順でセッションへ依頼し、結果を受け取る。
+
+- ゴール: 対象と終了条件を、会話から到達を確かめられる `/goal` の文で示す（例「SHINAPS-xxx が終了地点 <到達点> に達し、PRのURLとIssueとの相互リンクを報告した」）。ProposeGoalツールが使えればそれで提案し、その結果を確認とする。使えなければ `AskUserQuestion` で `/goal` の設定を依頼し、設定済みという回答を受けてから始める。Claude Codeではモデルからゴールの状態を読めないため、この回答を確認とする。設定されなければ、execution.mdの「ゴール機能」に従って開始前で止まる。
+- 人への確認（人の判断が要る質問への回答、未完了の扱い、作業ツリーに差がある場合など）は、すべて `AskUserQuestion` でターンの中で受ける。確認のためにターンを終えて待たない。Claude Code では /goal が有効な間、ターンを終えると Stop hook がゴール未達と判定して作業が続き、利用者の回答を待てないため。
+- セッションの完了待ち: backgroundのBashで、managed-session.mdの「観測と判定」の待ちを終える条件が現れるまで60秒ごとに確かめるuntilループを回し、終了の通知で再開する。`/goal` によって作業が続いても、動いているループがあれば二重に起動しない。
+
+| 作業 | 読む資料 |
+| --- | --- |
+| 設定の確認 | [references/configuration.md](../../references/linear/configuration.md) |
+| 着手前の紐づけ、Issueの作成・整理・本文の更新 | [references/issue.md](../../references/linear/issue.md) |
+| 担当、工程、待ち状態、人への依頼、継続の範囲 | [references/workflow.md](../../references/linear/workflow.md) |
+| Managedセッションの作成・観測・取り出し・適用とQAへの受け渡し | [references/managed-session.md](../../references/linear/managed-session.md) |
+| QAの実施・記録・素材 | [references/qa.md](../../references/linear/qa.md) |
+| Cycle完了QA・報告 | [references/cycle-report.md](../../references/linear/cycle-report.md) |
+
+コミットは `shinaps:commit`、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、Claudeが自分で行う。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで続ける。
+
 ## Codexの依頼なしで起動された場合
 
 相談・Issue整理・設定変更は `shinaps:linear-plan` を使う。実行範囲は [execution.md](../../references/linear/execution.md) に従って引き渡す。
 
 - 利用者から直接依頼された実作業（開発進行の依頼を除く）は、着手前に [references/issue.md](../../references/linear/issue.md) の「着手前に作業をIssueへ紐づける」に従う。Issueの作成は利用者がその場で依頼した場合だけ行い、設定の `issue_update` を根拠にしない。
 - 利用者から明示的にIssueの整理を依頼された場合は、[references/issue.md](../../references/linear/issue.md) に従って整理する。Issueの更新は、依頼で指定された範囲だけにする（設定の有無にかかわらない）。
-- 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、Claudeは進行役を兼ねない。[設定の読み方](../../references/linear/configuration.md#設定の読み方)で真に未設定と確認した場合だけ、同じセッションで `shinaps:linear-plan` の初期設定ヒアリングに進み、保存・確認後に元の依頼の引き渡しへ戻る。作業先リポジトリの設定で `bridge_request` が許可され、BridgeでCodexのセッションを特定できる場合は、[references/workflow.md](../../references/linear/workflow.md) の「開発進行の引き渡し」の項目を添えてCodexへ引き渡す。設定は [references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従って読む。許可や相手のセッションがない場合は、必要な準備（設定、Codexセッションの起動、Bridgeの導入）を利用者へ案内する。
+- 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、設定の `implementation_skill` がManagedの入口なら「Managedの入口で進行する」に従う。それ以外の入口ではClaudeは進行役を兼ねない。[設定の読み方](../../references/linear/configuration.md#設定の読み方)で真に未設定と確認した場合だけ、同じセッションで `shinaps:linear-plan` の初期設定ヒアリングに進み、保存・確認後に元の依頼の引き渡しへ戻る。作業先リポジトリの設定で `bridge_request` が許可され、BridgeでCodexのセッションを特定できる場合は、[references/workflow.md](../../references/linear/workflow.md) の「開発進行の引き渡し」の項目を添えてCodexへ引き渡す。設定は [references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従って読む。許可や相手のセッションがない場合は、必要な準備（設定、Codexセッションの起動、Bridgeの導入）を利用者へ案内する。
+
+## 初期体制と途中の増員
+
+[Issue開始時の実装体制](../../references/linear/execution.md#issue開始時の実装体制)と[体制の判断](../../references/dev/staffing.md)に従う。進行役は各Issueの初期体制を設計前に決めて渡し、実装側のメインは現物と照合して必要な担当を追加できる。Claudeが実装の受け手の場合も同じ基準を使い、変更理由と体制を進行役へ返す。Managedの進行役も初期体制をleadへ渡す。人数の固定された入口へ戻さず、必須検証と独立性を保つ。