@shinaps/skills 0.29.0 → 0.30.0

package/plugins/shinaps-codex/references/human-review.md

@@ -0,0 +1,24 @@
+# 人レビューの差分提示
+
+人のコードレビューが必要な場合、またはコミット単位の承認を求める場合に使う。人レビューの要否・操作許可・コミットモードは、プロジェクト設定と今回の依頼に従う。この手順はそれらを変更しない。
+
+## 対象の準備
+
+レビュー対象のcheckoutの絶対パス、ブランチ、比較元のcommit、対象ファイルと完全な差分、検証結果を確定する。未追跡ファイルも対象に含める。stageは許可された範囲だけで行い、無関係な差分や既存のステージ境界を変更しない。対象差分と比較元は作業記録へ残し、後で承認対象と照合できるようにする。
+
+## CodexではPlasmaで開く
+
+人への窓口がCodexの場合は、実装担当がCodexかClaudeかによらず、レビューを依頼する会話でPlasmaを開く。人への窓口がClaudeの場合は既存の差分提示方法を使い、Plasmaのためだけに別のCodexタスクを作らない。
+
+1. 利用可能なPlasmaの`open_workbench`ツールと現在の入力仕様を確認する。ファイルを開く`route`が使える場合は、対象checkoutの絶対パスとレビュー対象のファイルを指定する。現在の形式は`/open?project=ABSOLUTE_PATH&file=RELATIVE_PATH&line=START&endLine=END`で、各値をURLエンコードする。存在するファイルを使い、適切なファイルがない場合はプロジェクト選択画面から対象checkoutを選ぶ。
+2. ファイルを開くことと差分を表示することを区別する。ファイル用routeに差分モードの未定義パラメーターを足さない。利用可能なUI操作ツールでPlasmaのGit画面を確認し、レビュー対象に合う比較を選ぶ。UI操作が使えない場合は、対象プロジェクト・比較方法・ファイル一覧を示して利用者に選択を依頼する。
+3. 表示中のcheckout・比較元・対象範囲をGitで確定した差分と照合する。ステージ済みの単位なら`git diff --cached`を基準にする。作業ツリー全体や別ブランチの差分を、その単位の差分として提示しない。対象全体を表示できない場合は、未表示の範囲を明示し、完全な差分を確認できる方法を利用者と決める。
+4. 会話に変更の目的、確認してほしい点、検証結果、対象単位を示し、修正指示またはレビュー完了を依頼する。Linear進行ではIssueも示す。Plasma内の注釈は指摘として扱い、画面を開いたことや操作の終了を承認とみなさない。
+
+Plasmaが未導入・起動失敗の場合は、その状態を伝え、Codexの差分表示など利用者が選んだ方法で同じ対象を提示する。無断でインストールや設定変更を行わず、表示できていないレビューを完了扱いにしない。
+
+## 承認後の照合
+
+利用者の明示的なレビュー完了を、対象単位と対応付けて記録する。修正した場合は必要な検証を行い、更新した差分を再提示して再確認を受ける。待機中に対象が変わった場合も、古い承認をそのまま適用しない。
+
+コミット直前に実際のコミット対象と承認対象の完全な差分を照合する。不一致ならコミットせず、変更後の対象を提示する。Plasmaを開くことはstage・commit・pushの許可を追加しない。具体的なコミット操作は`commit`に従う。

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

@@ -1,21 +1,21 @@
 # Codexの実装タスク
 
-`implementation_skill` が `dev-codex` または `dev-codex-ultra` の場合に使う。会話側のCodexがゴール・Linear・人への窓口・Agent QA・公開の進行を所有し、Issueごとの別のCodexタスクに実装を任せる。実装タスクは指定されたdevの入口でサブエージェントを使う。別タスクとdev内部のサブエージェントは別の役割である。
+`implementation_skill` が `dev-codex` の場合に使う。会話側のCodexがゴール・Linear・人への窓口・Agent QA・公開の進行を所有し、Issueごとの別のCodexタスクに実装を任せる。実装タスクは指定されたdevの入口でサブエージェントを使う。別タスクとdev内部のサブエージェントは別の役割である。
 
 ## 作成と再利用
 
 - 利用者の明示的な依頼または合意済みの `permissions: [codex_task, ...]` の範囲を確認する。ツールが利用者からの明示依頼を要求する場合はその条件も満たす必要があり、設定だけで迂回しない。必要な許可やツールがなければ開始前に止め、会話側での実装やCLIへの置き換えをしない。
 - 既存の同じIssueの実装タスクがあれば状態を読み直して再利用する。なければ `list_projects` で所属先を確認し、`create_thread` で新しいローカルCodexタスクを一つ作る。所属プロジェクトと実際の作業ディレクトリは一致を必須にしない。作業先が登録一覧にない場合も、利用者が指定した所属先を使い、対象checkoutの絶対パスを依頼に明記できる。実装担当は変更前に、指定先のGitルート・ブランチ・差分と適用される規約を確認し、以後の操作をその作業先で行う。指定先にアクセスできない場合は、別checkoutで代用せず必要な準備を報告する。会話全体をforkせず、実装に必要な情報だけを渡す。新しいworktreeは作らず、明示的に別途許可された場合だけ使う。
 - 返された確定済みthreadId・hostIdとIssue・checkout・branchをローカルの作業記録で対応づける。準備中のclientThreadIdを送信先にしない。作成結果が不明なときは一覧と状態を確認してから再試行する。
-- 同じIssueの質問回答・修正・許可されたコミット依頼は `send_message_to_thread` で同じタスクへ送る。モデルを利用者の指定なしに変更しない。dev内のモデル・役割構成は指定した入口に従う。
+- 同じIssueの質問回答・修正・許可されたコミット依頼は `send_message_to_thread` で同じタスクへ送る。モデルを利用者の指定なしに変更しない。dev内のモデルは起動手順に従い、役割構成は初期体制と途中の判断に従う。
 
 ## 実装依頼に渡すもの
 
-Issueリンク・範囲・受入条件・仕様や調査成果物、指定devスキル、Gitの絶対作業ディレクトリ・ブランチ・現在の差分、設定の保存方式・正本と必要な補足の所在、合意済みの操作許可とユーザーの委託許可、必要な検証、会話側のタスクIDを渡す。秘密値をプロンプトへ転記しない。
+Issueリンク・範囲・受入条件・仕様や調査成果物、指定devスキル、初期体制（役割別人数・根拠・専任なしの責任者・必須検証）、Gitの絶対作業ディレクトリ・ブランチ・現在の差分、設定の保存方式・正本と必要な補足の所在、合意済みの操作許可とユーザーの委託許可、必要な検証、会話側のタスクIDを渡す。秘密値をプロンプトへ転記しない。
 
 実装担当には次を明記する。
 
-> あなたはこのIssueの実装担当。指定されたdevスキルで実装・検証し、結果をこのタスクの最終回答へ返す。linear-executeを再起動せず、別の実装タスクや開発ゴールを作らない。dev内部のサブエージェントはdev_delegationの許可範囲で使う。仕様・権限の未決事項は質問として返し、人へ直接着手確認をしない。実装完了だけでコミット・push・公開・IssueのDone更新をしない。コミットは会話側からQA結果を伴う依頼を受け、必要な許可を確認して行う。単位案・判定・依頼・照合・報告は [共通手順](workflow.md#単位案からコミット完了まで)に従う。他の人・AIの差分を戻さない。
+> あなたはこのIssueの実装担当。指定されたdevスキルで実装・検証し、結果をこのタスクの最終回答へ返す。linear-executeを再起動せず、別の実装タスクや開発ゴールを作らない。dev内部のサブエージェントはdev_delegationの許可範囲で使う。初期体制を現物と照合し、途中の新しい根拠で必要な担当を追加して進行役へ報告する。仕様・権限の未決事項は質問として返し、人へ直接着手確認をしない。実装完了だけでコミット・push・公開・IssueのDone更新をしない。コミットは会話側からQA結果を伴う依頼を受け、必要な許可を確認して行う。単位案・判定・依頼・照合・報告は [共通手順](workflow.md#単位案からコミット完了まで)に従う。他の人・AIの差分を戻さない。
 
 ## 待機・QA・修正
 
@@ -24,3 +24,15 @@ Issueリンク・範囲・受入条件・仕様や調査成果物、指定devス
 実装中は会話側で同じファイルを編集しない。Agent QAの開始前に実装タスクの編集が止まったことを確認し、差分と対象版を固定してQAする。不具合は再現手順・期待と実際・証拠とともに同じタスクへ返し、修正終了後に再検証する。実装担当が返したテスト結果を独立したAgent QAの代わりにしない。
 
 質問は会話側が既存の合意で答え、仕様・権限を変える判断だけ人へ確認する。実装タスクの失敗・利用不能時は未完了として報告し、独断で別タスクを重ねない。利用者の停止・範囲変更は実装タスクにも伝え、停止を確認する。次のIssueへは今回の実行範囲と終了条件に従って進む。
+
+## 完了後の整理
+
+会話側のCodexが、合意した終了条件への到達、成果・検証結果・未実施事項の記録、その実装タスクで続ける作業がないことを確認してから、専用の実装タスクだけをアーカイブする。実装担当の完了報告や、IssueのDone・ゴールの完了だけでは、この確認の代わりにならない。修正・QA・コミットなどの続きがあるタスク、停止中・ブロッカー待ちのタスク、人との窓口や他の作業と共有しているタスクは保持する。
+
+アーカイブには、整理まで含む今回の利用者の明示合意、または対象・条件を確認できる記録済みの継続合意が必要。`codex_task` の許可だけからは推測せず、ツール固有の明示依頼条件も満たす。合意がない場合はタスクを保持し、整理が未実施であることを報告する。
+
+1. ローカル作業記録の確定済み `threadId`・`hostId` とIssue・checkout・branchの対応を確認する。対象を確定できなければ操作しない。
+2. `set_thread_archived` に、その `threadId`・`hostId` と `archived: true` を明示して実行する。IDを省略して呼出元を対象にしない。
+3. 結果を確認し、対象と成否を作業記録に残す。結果が不明なら `list_threads`・`list_archived_threads`・`read_thread` など利用可能な読取手段で同じ対象の状態を確認する。一覧に見当たらないだけで成功と扱わず、状態を確定できない場合は重複操作せず未整理として報告する。ツールが利用不能・失敗の場合も、未整理の対象と理由を報告する。
+
+この整理はブランチやworktreeの削除を含まない。タスク整理の成否は、終了地点への到達・IssueのDone・ゴールの状態と分けて記録する。

package/plugins/shinaps-codex/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` に従う。
 
 予定単位の内容・分割・統合を変更したら、変更した単位を再判定して必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。以前の判定や別単位の方針は流用しない。実コミットが予定と異なれば停止し、履歴を無断で書き換えない。
 
@@ -127,8 +127,9 @@ path_policy_overrides:
 | --- | --- |
 | `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
 | `development_operations` | 任された対象の開発に必要な、既存アカウントへの通常のログイン、ローカル環境準備、プロジェクトの依存導入、開発サーバー・Simulatorの起動停止、ビルド・テスト・QA操作を継続的に許可する。下の範囲に従う |
-| `codex_task` | 対象IssueごとのCodex実装タスクの新規作成・状態確認・実装や修正や許可済みコミットの依頼。worktree作成、操作許可の追加、タスク側でのゴールや実装タスクの再作成は含めない。ツールの明示依頼要件も満たす（[codex-task.md](codex-task.md)） |
+| `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-codex/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・必要な人の対応・コミットを残して次へ切り替えない。
@@ -29,9 +35,11 @@
 - バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
 - Issue単体・Cycle全体では、ブロッカー報告だけで完了にしない。必要な判断や準備を求め、再開条件を記録する。
 
+合意した終了地点に達して成果を記録した後、Codexの専用実装タスクは [完了後の整理](codex-task.md#完了後の整理) の条件に従って会話側が整理する。終了地点への到達・IssueのDone・ゴールの完了と、タスク整理の成否は分けて扱う。
+
 ## ゴール機能
 
-実行開始の必須条件として、上の対象と終了条件を持つゴールが設定済みであることを確認する。ゴールの作成成功、または同じ対象の既存ゴールの状態をツールで確認してから実装・QA・公開の進行を始める。文章で目標を書くだけでは設定済みとしない。ツールが利用者の明示依頼を要求する場合、スキルの選択だけで迂回せず、既存の明示依頼を使い、なければ開始時に一度確認し、回答と設定成功を待つ。同じ対象のゴールは再利用し、別の未完了ゴールを上書きしない。予算は明示された場合だけ設定する。
+実行開始の必須条件として、上の対象と終了条件を持つゴールが設定済みであることを確認する。ゴールの作成成功、または同じ対象の既存ゴールの状態をツールで確認してから実装・QA・公開の進行を始める。文章で目標を書くだけでは設定済みとしない。ツールが利用者の明示依頼を要求する場合、スキルの選択だけで迂回せず、既存の明示依頼を使い、なければ開始時に一度確認し、回答と設定成功を待つ。同じ対象のゴールは再利用し、別の未完了ゴールを上書きしない。予算は明示された場合だけ設定する。モデルのツールでゴールの設定を確認できないruntimeでは、そのruntimeのlinear-executeの手順が定める確認手段で確認する。確認できなければ下の段落に従って開始前で止まる。
 
 ゴール機能が利用できない、作成に失敗した、または別の未完了ゴールと競合する場合は、理由と必要な準備を報告して実行開始前で止まる。ゴールなしで代替実行しない。
 

package/plugins/shinaps-codex/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-codex/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へ報告する。
 
@@ -53,6 +55,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 - 工程名を使うことは、チーム設定を変更する許可ではない。専用のステータスがないQA工程は進行中の状態に対応づけ、工程・待ち理由・再開条件をコメントへ記録する。`done` と途中の工程を同じ完了状態に対応づけない。
 - QAステータスへの移動とQAの合格を区別する。終了地点への到達とIssueのDoneを区別する。
+- Codexの専用実装タスクの整理は、終了条件への到達と成果記録を確認した後、会話側が [完了後の整理](codex-task.md#完了後の整理) に従って行う。タスクのアーカイブを工程・Issue・ゴールの完了確認の代わりにしない。
 - 工程を行うかどうかは、Issueの受入条件と終了地点で決める。Issueに適用されない工程は通らない（配備しない変更の環境配備・環境QA、Git変更がない作業のレビュー・コミット・PRなど）。省略した工程は理由を記録する。工程の省略を理由に、必要なQAや未達の受入条件を省かない。
 - 終了地点の工程がそのIssueにない場合は、適用される最後の必要工程まで進めて止まる。そのとき必須受入条件をすべて満たしていればDoneにする。満たしていなければ、残る条件を記録してDoneにしない（push前QAで止める運用で、本番公開の受入条件が残るIssueなど）。
 - 人がレビュー中に修正した場合は `code_review` を続ける。AIへ追加実装を依頼する場合は、範囲と受入条件をIssueで更新してから `coding` へ戻す。
@@ -68,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・予定差分・実差分の違いを記録して人に確認する。履歴を無断で書き換えない。
 
@@ -92,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から利用者へ確認する |
 
@@ -104,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の有無を含む>
 ```
 
@@ -126,6 +130,8 @@ Bridgeの報告は、新しい公開や破壊的な操作の許可を作らな
 
 Code Reviewを依頼する前に対象差分を確認する。`stage` の許可がある場合だけ、対象だけをステージする。`git diff --cached` と `git status --short` で、新規ファイルの漏れと無関係な差分の混入を確認する。ステージにコミットは含めない。許可がなければ、ステージを人への依頼に含める。
 
+人レビューの差分提示は[共通手順](../human-review.md)に従う。
+
 会話でIssueリンクと必要な作業を明示し、ステータスの変更だけで依頼を済ませない。
 
 | 依頼 | 文例 |

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

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

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

@@ -11,6 +11,6 @@ description: 再現手順、コード、ログと必要な外部情報から不
 
 委託が許可され登録されている場合はshinaps-debuggerで仮説を立て、shinaps-debug-validatorで実コードを検証する。外部調査にはshinaps-tech-surveyorとshinaps-survey-validatorを必要に応じて使う。取得済みのShinapsルールは親が担当へ渡す。MCP不可ならルール照合未確認とする。
 
-結論、証拠、再現状況、最小の修正方針と未確認を報告する。修正まで依頼されている場合は$shinaps:dev-codex-ultraへ引き継ぐ。1体での実行を指定された場合は$shinaps:dev-codexを使う。調査だけなら変更しない。
+結論、証拠、再現状況、最小の修正方針と未確認を報告する。修正まで依頼されている場合は$shinaps:dev-codexへ引き継ぐ。担当と人数はdevのメインが作業に応じて判断する。調査だけなら変更しない。
 
 必要な記録は.shinaps/work/debug/へ保存し、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。秘密情報・既存記録の削除・外部投稿は含めない。

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

@@ -1,9 +1,10 @@
 ---
 name: dev-codex
-description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化をそれぞれ1体で確認する。実装依頼で1体での実行を指定されたときに使う。コミットは許可と工程の条件に従い、Linear進行ではQAへ結果を返す。
+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-codex/skills/explore/SKILL.md

@@ -9,6 +9,6 @@ description: 既存挙動の理由、実装方針、変更の影響を対話し
 
 委託を許可されている場合は登録済みのshinaps-investigatorに現在の質問と対象範囲を渡せる。許可がなければ現在のセッションで調べる。調査依頼を実装・設定変更・外部投稿の許可として扱わない。
 
-質問が曖昧なら結果を左右する点だけ一問確認する。回答後に新たな質問が来たら続け、仕様策定や修正へ自動で進まない。理解が揃い実装を依頼されたら、目的・合意事項・未確認事項・関連ファイルを引き継ぎ、$shinaps:dev-codex-ultraを読む。1体での実行を指定された場合は$shinaps:dev-codexを使う。
+質問が曖昧なら結果を左右する点だけ一問確認する。回答後に新たな質問が来たら続け、仕様策定や修正へ自動で進まない。理解が揃い実装を依頼されたら、目的・合意事項・未確認事項・関連ファイルを引き継ぎ、$shinaps:dev-codexを読む。担当と人数はdevのメインが作業に応じて判断する。
 
 継続用の記録が必要なら.shinaps/work/explorations/へ保存する。[作業記録の共通手順](../../references/work-records.md)に従い、秘密情報や無関係な記録を持ち込まない。MCPが使えないときはルール照合未確認と明記する。

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

@@ -5,7 +5,7 @@ description: 指定したIssue・Cycle・バックログの実装からQA・許
 
 # Linearを起点に開発を進める
 
-Issueの責務・受入条件・ステータスを、実際の成果と一致させる。初版は利用者本人の環境向けで、Codexが進行・Agent QA・人への窓口を担当する。実装担当は作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口ではClaudeがAI Terminal Bridge（以下Bridge）経由の依頼で実装し、Codexの入口（`dev-codex`・`dev-codex-ultra`）ではIssueごとの別Codexタスクが `$shinaps:<入口>` で実装・QA指摘の修正を行う（[references/workflow.md](../../references/linear/workflow.md) の「担当と窓口」）。設定と異なる担当への入れ替えは扱わない。
+Issueの責務・受入条件・ステータスを、実際の成果と一致させる。初版は利用者本人の環境向けで、Codexが進行・Agent QA・人への窓口を担当する。実装担当は作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口ではClaudeがAI Terminal Bridge（以下Bridge）経由の依頼で実装し、Codexの入口（`dev-codex`）ではIssueごとの別Codexタスクが `$shinaps:<入口>` で実装・QA指摘の修正を行う。Managedの入口（`dev-managed-cc`）では、会話側のCodexが進行役のまま、IssueごとのClaude Managed Agentsセッションが実装する（[managed-session.md](../../references/linear/managed-session.md)）。担当の対応は[references/workflow.md](../../references/linear/workflow.md) の「担当と窓口」にある。設定と異なる担当への入れ替えは扱わない。
 
 ## 再確認せず進める条件
 
@@ -19,15 +19,14 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 
 [実行範囲とゴール](../../references/linear/execution.md)を読み、Issue単体・Cycle全体・バックログ消化から依頼に合う範囲を確定する。依頼が明確なら聞き直さず、不明な場合だけ一問確認する。対象ID・順序・終了条件を記録してから実装を始める。
 
-開発進行には作業先の明示された設定と `issue_update` が必要。Claudeの入口では `bridge_request` とBridge、Codexの入口では `codex_task` と別タスクの作成・連絡手段も必要。設定の許可・`stop_after` を超えない。Issue未作成の明示的な実装依頼は共通の紐づけ手順でIssueを作って続けられるが、仕様が未決なら `shinaps:linear-plan` へ整理を戻す。
+開発進行には作業先の明示された設定と `issue_update` が必要。入口ごとに必要な許可とツールは [configuration.md](../../references/linear/configuration.md) の「許可」に従う。設定の許可・`stop_after` を超えない。Issue未作成の明示的な実装依頼は共通の紐づけ手順でIssueを作って続けられるが、仕様が未決なら `shinaps:linear-plan` へ整理を戻す。
 
-実行には対象と終了条件を持つゴールの設定成功が必須。環境が明示許可を要求する場合は、既存の依頼で満たされるか確認し、なければ開始前に一度確認する。ゴール未設定のまま実装へ進まない。人レビュー・Human QA待ちは予定された工程として待機する。スキルの実行だけで予約実行・定期監視は開始しない。
+実行には対象と終了条件を持つゴールの設定成功が必須。環境が明示許可を要求する場合は、既存の依頼で満たされるか確認し、なければ開始前に一度確認する。ゴール未設定のまま実装へ進まない。人レビュー・Human QA待ちは予定された工程として待機する。スキルの実行だけで予約実行・定期監視は開始しない。Managedの入口では、セッションの完了を、シェルで[managed-session.md](../../references/linear/managed-session.md)の「観測と判定」の確認を60秒ごとに繰り返して待つ。これは進行中のIssueの観測であり、予約実行・定期監視には当たらない。人への確認は会話で一問ずつ行う。
 
 ## 設定と補足を読む
 
 - 設定の所在・読み方・補足との関係・不足時の止め方は、[references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従う。
-- 作業先リポジトリは、Issue本文の「対象・範囲外」で特定する。Issueがまだない作業では、依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、`list_sessions` の `project_path`、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。
-- 操作の許可は作業先リポジトリの設定で決める。同じLinear projectに属するだけでは、別のリポジトリの作業を現在の設定に含めない。作業先を特定できないIssueや、作業先に設定がないIssueでは、開発進行を始めない。
+- 作業先の特定と作業先の設定による許可は、[execution.md](../../references/linear/execution.md) の「開始時に固定するもの」に従う。
 - 依頼の実行に設定が必要で、[設定の読み方](../../references/linear/configuration.md#設定の読み方)で真に未設定と確認した場合だけ、同じセッションで `shinaps:linear-plan` の初期設定ヒアリングに進む。保存・確認後に元の依頼へ戻り、設定と既存の許可の範囲で再開する。設定不要のIssueの読み取り、整理案、明示依頼された更新はそのまま行う。
 
 ## 作業ごとに読む資料
@@ -38,7 +37,12 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 | 着手前の紐づけ、Issueの作成・整理・本文の更新 | [references/issue.md](../../references/linear/issue.md) |
 | 担当、工程、待ち状態、Bridge、人への依頼、継続の範囲 | [references/workflow.md](../../references/linear/workflow.md) |
 | Codex実装タスクの作成・再利用・依頼とQAへの受け渡し | [codex-task.md](../../references/linear/codex-task.md) |
+| Managedセッションの作成・観測・取り出し・適用とQAへの受け渡し | [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`（Claudeの入口ではClaudeへ依頼し、Codexの入口では会話側がQA後に実装タスクへ依頼する）、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで継続する。
+コミットは `shinaps:commit`（Claudeの入口ではClaudeへ依頼し、Codexの入口では会話側がQA後に実装タスクへ依頼し、Managedの入口では会話側がQA後に自分で行う）、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで継続する。
+
+## 初期体制と途中の増員
+
+[Issue開始時の実装体制](../../references/linear/execution.md#issue開始時の実装体制)と[体制の判断](../../references/dev/staffing.md)に従う。進行役は各Issueの初期体制を設計前に決めて渡し、実装側のメインは現物と照合して必要な担当を追加できる。Claudeが実装の受け手の場合も同じ基準を使い、変更理由と体制を進行役へ返す。Managedの進行役も初期体制をleadへ渡す。人数の固定された入口へ戻さず、必須検証と独立性を保つ。

package/plugins/shinaps-codex/skills/spec/SKILL.md

@@ -13,4 +13,4 @@ description: 曖昧な要望を対話と既存実装・実現可能性の調査
 
 利用可能なShinapsルールを制約の根拠に含める。利用できないときはルール照合を未確認とし、実現可能性や仕様確定に残る影響を明記する。
 
-合意した仕様を.shinaps/work/specs/のspec.mdへ保存する。[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。仕様には目的・範囲・挙動・受入条件・設計判断・根拠・未決事項を含める。実装依頼があれば$shinaps:dev-codex-ultraへこの記録を渡す。1体での実行を指定された場合は$shinaps:dev-codexを使う。仕様作成だけの依頼で自動実装しない。
+合意した仕様を.shinaps/work/specs/のspec.mdへ保存する。[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。仕様には目的・範囲・挙動・受入条件・設計判断・根拠・未決事項を含める。実装依頼があれば$shinaps:dev-codexへこの記録を渡す。担当と人数はdevのメインが作業に応じて判断する。仕様作成だけの依頼で自動実装しない。

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

@@ -1,10 +0,0 @@
----
-name: dev-claude-ultra
-description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化を同じ役割の2体で独立に確認する。機能追加や修正の実装依頼の既定。コミットは許可と工程の条件に従い、Linear進行ではQAへ結果を返す。
-argument-hint: <実装したい機能・解決したい課題>
----
-
-# 開発（同じ役割 2 体）
-
-同じ役割の担当数は 2 体。[工程](../../references/dev/workflow.md)と[起動手順](../../references/dev/launch.md)を読み、この担当数で進める。
-タスクの確定は[工程](../../references/dev/workflow.md)の Phase 1 に従う（引数が無いだけでは終了しない）。

package/plugins/shinaps-codex/skills/dev-codex-ultra/SKILL.md

@@ -1,9 +0,0 @@
----
-name: dev-codex-ultra
-description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化を同じ役割の2体で独立に確認する。機能追加や修正の実装依頼の既定。コミットは許可と工程の条件に従い、Linear進行ではQAへ結果を返す。
----
-
-# 開発（同じ役割 2 体）
-
-同じ役割の担当数は 2 体。[工程](../../references/dev/workflow.md)と[起動手順](../../references/dev/launch.md)を読み、この担当数で進める。
-タスクの確定は[工程](../../references/dev/workflow.md)の Phase 1 に従う（引数が無いだけでは終了しない）。