@shinaps/skills 0.22.0 → 0.23.0

package/README.md

@@ -37,14 +37,14 @@ Claude版の `dev` は実装後にレビュー・規約照合・簡素化の提
 
 ### 比較用 dev 入口
 
-`dev-mixed`・`dev-claude`・`dev-codex-astra`・`dev-codex-sol` は、同じ工程でモデル・同じ役割の担当数・実行環境の差を比べるための入口である。通常の開発には `dev` を使う。比較用入口は明示的に呼び出したときだけ使われ、Claude版は `disable-model-invocation: true`、Codex版は `agents/openai.yaml` の `allow_implicit_invocation: false` で自動選択の対象から外している。引数には担当数（`dev-mixed` を除く）と比較条件ファイルが必須。
+`dev-mixed`・`dev-claude`・`dev-codex-astra`・`dev-codex-sol` は、同じ工程でモデル・同じ役割の担当数・実行環境の差を比べるための入口である。通常の開発には `dev` を使う。比較用入口は、入口と比較条件ファイルを明示した依頼でだけ使う。引数には担当数（`dev-mixed` を除く）と比較条件ファイルが必須で、無ければ担当を起動せずに終わる。Codex版は `agents/openai.yaml` の `allow_implicit_invocation: false` で自動選択の対象から外している。Claude版は、利用者が委託したCodexがAI Terminal Bridgeで依頼して起動できるよう、モデルからの呼び出し（Skillツール）を許可している。Claude Codeには、モデルからの呼び出しを許したまま自動選択の候補からだけ外す設定が無い（`disable-model-invocation: true` はSkillツールからの起動も拒否する）。このため、Claude版は説明文で、入口と比較条件ファイルを明示した依頼だけが対象だと示す。誤って選ばれても、引数が無ければ上の必須検査で担当を起動せずに終わる。
 
 - 共通資料（工程・構成表・担当指示・起動手順・実行記録・比較手順）は plugin ルートの `references/dev-comparison/` に置く。Claude版を編集元としてCodex版の同じパスへディレクトリ全体を複製し、テストで一致と plugin 内での参照解決を確認する。
 - 工程は eafbbc5 の Claude版 `dev` から作り、既存の `dev` とは独立に管理する。既存の `dev` を変更したとき比較工程へ反映するかは、その都度判断する。
 - 1体／2体の設定が変えるのは、独立設計・計画レビュー・計画簡素化の担当2の有無だけである。実装は常に1体で、実装後の設計適合性・独立コードレビュー・refine・簡素化は1体の設定でも行う。
-- 担当には比較専用の担当指示を使い、Claudeの担当は汎用のAgent（Opus / medium を明示）、Codexの担当は `codex exec` で起動する。登録エージェントは追加・変更しない。Codexネイティブの子エージェント（`spawn_agent`）は子ごとのtier・sandboxを指定できず同時実行枠もあるため、Codexの親でも使わない。そのため、Codexネイティブの子エージェントの使い勝手は比較の対象外になる。
+- 担当には比較専用の担当指示（`references/dev-comparison/roles/`）を使う。Claudeの担当は汎用のAgent（Opus / medium を明示）、P1のCodexの担当は `codex exec` で起動し、担当指示の全文を依頼に入れる。Codexの親（P4〜P7）は、担当指示から生成した比較専用の役割（`plugins/shinaps-codex/agents/shinaps-comparison-*.toml`）をサブエージェントの `agent_type` に指定して起動し、モデル・推論は起動時に選ぶ。通常の dev の登録エージェントは比較に使わず、変更もしない。サブエージェントが親から引き継ぐ設定と同時実行の上限は、[構成表](plugins/shinaps-claude/references/dev-comparison/configurations.md)の「環境の条件」に書く。
 - P1 は現行の Claude版 `dev` の担当割当を再現するが、比較専用の担当指示を使い review / refine / simplify スキルを経由しないので、現行 `dev` の実行結果そのものではない。
-- 検証の限界: リポジトリのテストが確認するのは共通資料の一致と参照の解決まで。モデル・推論・tierは各実行の実行記録で指定値と観測値を分けて記録し、ローカル記録に実際の値が残らない項目（Codexのservice_tier、Claudeのpermission mode）は「指定のみ」として全構成で併記し、確認済みとは扱わない。7構成の工程の完走は保証しない。
+- 検証の限界: リポジトリのテストが確認するのは、共通資料の一致と参照の解決、Claude版の入口をSkillツールから起動できる設定であること、比較専用の役割定義が担当指示から生成されていることまで。モデル・推論・tierは各実行の実行記録で指定値と観測値を分けて記録し、ローカル記録に実際の値が残らない項目（Codexのservice_tier、Claudeのpermission mode）は「指定のみ」として全構成で併記し、確認済みとは扱わない。7構成の工程の完走は保証しない。
 
 手順は[比較手順](plugins/shinaps-claude/references/dev-comparison/comparison.md)と[構成表](plugins/shinaps-claude/references/dev-comparison/configurations.md)を参照する。
 
@@ -74,7 +74,7 @@ npx @shinaps/skills@latest recover codex
 
 ローカル開発では、このcheckoutから `node bin/skills.ts install codex` のように同じ操作を実行できる。Node.js 22.18以上なら型除去でTypeScriptをそのまま実行する (ビルド不要)。
 
-CLIはスキルをCodex pluginとして登録し、13個のカスタムエージェントを`${CODEX_HOME:-~/.codex}/agents/`へ配置する。新しいセッションで`shinaps:dev`、`shinaps:review`等が読み込まれる。エージェントのモデルと推論設定は親セッションから継承し、調査・レビュー担当は読み取り専用を既定にする。親セッションの実行時設定が優先される場合もあるため、権限の強制境界とは扱わない。
+CLIはスキルをCodex pluginとして登録し、13個のカスタムエージェントと、比較用入口だけが使う8個の比較専用の役割（`shinaps-comparison-*`）を`${CODEX_HOME:-~/.codex}/agents/`へ配置する。比較専用の役割も通常のセッションの役割一覧に表示されるが、説明文で比較用入口専用と示し、通常の `dev` は使わない。新しいセッションで`shinaps:dev`、`shinaps:review`等が読み込まれる。13個のカスタムエージェントのモデルと推論設定は親セッションから継承し、調査・レビュー担当は読み取り専用を既定にする。親セッションの実行時設定が優先される場合もあるため、権限の強制境界とは扱わない。
 
 配布物は`~/.local/share/shinaps-ai/skills/codex/`へ保持し、一時的なnpxキャッシュに依存しない。同じ親ディレクトリの`state.json`に配置したエージェントと内容のハッシュを記録する。管理対象外の同名ファイルや、導入後に編集されたエージェントは上書き・削除せず停止する。必要な変更を退避・整理してから再実行する。`CODEX_HOME`を変更する場合は元の配置先で先にuninstallする。
 
@@ -113,7 +113,7 @@ Claude Codeは標準のmarketplace自動更新機能を使う。`/plugin` のMar
 
 - Claude版: `plugins/shinaps-claude/`、marketplaceは`.claude-plugin/marketplace.json`
 - Codex版: `plugins/shinaps-codex/`、marketplaceは`.agents/plugins/marketplace.json`
-- Codexカスタムエージェント: `plugins/shinaps-codex/agents/`
+- Codexカスタムエージェント: `plugins/shinaps-codex/agents/`。`shinaps-comparison-*.toml` は `references/dev-comparison/roles/` から `npm run generate:agents` で生成し、直接編集しない
 - 配布CLI: ソースは `bin/skills.ts` と `lib/*.ts`。`npm run build` (`tsc`) で `dist/` にJSを出力し、npmにはそれを配布する。Node.jsは`node_modules`配下の`.ts`に型除去を適用しないため、ソースのままは配布できない。checkoutでは型除去で直接実行するので、`enum`など型除去で消せない構文は使わない (`tsconfig.json` の `erasableSyntaxOnly`)
 
 品質基準とプロジェクト設定の方針は揃えつつ、クライアント固有の実行手順・エージェント形式は別々に管理する。Claude向けのエージェント呼び出しをCodexに読み替えさせる方式は使わない。スキルを追加・変更した場合は両版への適用可否を判断する。
@@ -192,7 +192,7 @@ Claude版は全16エージェントが `opus / medium`。`dev` はOpus architect
 
 実装後レビューは最大2ラウンド。2回目の後に修正した場合はテスト・残課題と最終差分の再レビュー未実施を報告し、重大な未解決事項を完了扱いにしない。UIレビューは別途Codex側で行う。役割ごとにセッションと成果物を分け、今回の他担当の結果を独立レビューへ渡さない。Claude版のこの構成にはログイン済みのCodex CLIが必要。利用不能時にFableへ切り替えず未完了の工程を報告する。個人用 `ggc` / `ccc` aliasは使わず、[CLI担当の手順](plugins/shinaps-claude/skills/dev/references/codex-worker.md) に従う。
 
-Codex版の `dev` とカスタムエージェントは親モデルを継承する既存の構成を維持し、Claude専用の実装・簡素化・指摘検証担当は追加しない。比較用入口の担当指示は登録エージェントではないので、この節のSubagent数には含まれない。
+Codex版の `dev` とカスタムエージェントは親モデルを継承する既存の構成を維持し、Claude専用の実装・簡素化・指摘検証担当は追加しない。比較用入口だけが使う比較専用の役割（Codex版の `shinaps-comparison-*` 8個）は、この節のSubagent数に含めない。
 
 **subagent 内では shinaps MCP を直接呼び出さず、rule 全文は Skill 側から prompt 経由で渡す** 原則を全 system prompt に明記する。MCP呼び出しの利用量が重複しないようにするため。
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.22.0",
+  "version": "0.23.0",
   "description": "Install Shinaps AI workflows and custom agents for Codex",
   "type": "module",
   "bin": {
@@ -22,6 +22,7 @@
     "test": "node --test \"test/*.test.ts\"",
     "check": "npm run format:check && tsc --noEmit",
     "verify:package": "node scripts/verify-package.ts",
+    "generate:agents": "node scripts/generate-comparison-agents.ts",
     "format": "biome format --write .",
     "format:check": "biome format ."
   },

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

@@ -1,7 +1,7 @@
 {
   "name": "shinaps",
   "description": "Shinaps AIの開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・レビュー・コミット・PR・リリースとLinearでの開発進行を支援する14スキル。",
-  "version": "0.22.0",
+  "version": "0.23.0",
   "author": {
     "name": "shinaps",
     "email": "ryuta@shinaps.jp"

package/plugins/shinaps-claude/references/dev-comparison/comparison.md

@@ -6,6 +6,8 @@
 
 P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用の担当指示を使い、review / refine / simplify スキルを経由しないので、現行 `dev` の実行結果そのものではない。
 
+Codex の担当の起動手段と担当指示の渡し方は、親で決まる（[構成表](configurations.md#環境の条件)）。P4〜P7 では、比較専用の役割を指定した Codex のサブエージェントの使い勝手も、結果に含めて比べる。
+
 ## 2. 条件ファイルの事前固定
 
 最初の実行の前に、比較セットのディレクトリへ `conditions.md` を保存し、ハッシュを記録する。以後は変更しない。
@@ -47,7 +49,7 @@ P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用
 ## 実行権限
 - Claude: <実施者が既に許可した permission mode>
 - Codex: <実施者が既に許可した sandbox と承認>
-- 権限機構の違い: Claude の担当は親の権限で動き、Codex は担当ごとに sandbox を持つ。<この違いで変わる点>
+- 権限機構の違い: Claude の担当と Codex のサブエージェントは親の権限で動き、`codex exec` の担当は担当ごとに sandbox を持つ。<この違いで変わる点>
 - 必須の検証コマンドをこの権限の範囲で両環境で実行できるかの確認結果: <日時、コマンド、結果>
 
 ## 終了条件
@@ -56,8 +58,8 @@ P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用
 ## 実行する構成と順序
 - <例: P1 → P3 → P5>
 
-## 各構成の親の起動コマンド
-| 構成 | 起動コマンド（構成表の写しに実行権限を入れたもの） |
+## 各構成の親の起動方法
+| 構成 | 起動方法（構成表の写しに実行権限を入れたもの。Codex アプリの親は設定の手順） |
 |---|---|
 | P1 | <コマンド> |
 ```
@@ -79,7 +81,13 @@ P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用
 
 ## 5. 実行
 
-条件ファイルの起動コマンドで親セッションを開始し、入口に担当数と条件ファイルの絶対パスを渡す。人の介入は全件を `run-record.md` に記録する。
+条件ファイルの起動方法で親セッションを開始し、入口に担当数と条件ファイルの絶対パスを渡す。人の介入は全件を `run-record.md` に記録する。
+
+Claude の入口（`dev-mixed`・`dev-claude`）は、利用者が委託した依頼元（Codex など）が AI Terminal Bridge で親セッションへ依頼して起動することもできる。
+
+- 依頼先は、その構成の作業環境を cwd とし、条件ファイルの起動コマンドで開始して、AI Terminal Bridge でメッセージを受け取れ（WebStorm のターミナルで起動したもの）、まだ他の依頼を受けていないセッションにする。[実行記録](record.md)は、その cwd の記録が 1 件だけであることで親を特定する。
+- 依頼に書くのは、入口・担当数・条件ファイルの絶対パス・返信先だけにする（例: 「`/shinaps:dev-claude 2体 <条件ファイルの絶対パス>` を Skill ツールで起動する。返信先: <依頼元の session_id>」）。比較の条件は条件ファイルに書き、依頼に追加の指示を書かない。スラッシュコマンドで起動した実行と、親が受け取る情報を同じにするためである。
+- 親は、実行中の質問をそのセッションの入力手段で行い、工程を終えたとき、または止まったときの報告だけを依頼元へ返す。依頼元は、実行中の質問に答えない。人の回答は、人の介入として記録する。
 
 ## 6. 回収
 
@@ -99,7 +107,7 @@ P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用
 構成ごとに次を表にする。
 
 - 合格条件の結果
-- 時間
+- 時間（同時実行の上限で後から起動した担当があれば、その起動待ちの合計を併記する）
 - 使用量（実測／推定／取得不可）
 - 修正回数
 - 人の介入
@@ -108,7 +116,7 @@ P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用
 - 自動メモリの差分
 - 2体目の発見の分類
 
-判定が「観測できる設定は一致（指定のみの項目あり）」だけの実行以外は、比較データとして扱わず、その判定を書く。指定のみの項目（[構成表](configurations.md#観測手段の無い項目)）は全構成について併記する。tier の実際の利用を確認できない構成の速度差は、tier まで揃えた結果とは書かない。
+判定が「観測できる設定は一致（指定のみの項目あり）」だけの実行以外は、比較データとして扱わず、その判定を書く。指定のみの項目（[構成表](configurations.md#観測手段の無い項目)）は全構成について併記する。tier の実際の利用を確認できない構成の速度差は、tier まで揃えた結果とは書かない。P4〜P7 では、[環境の条件](configurations.md#環境の条件)（親から引き継ぐ項目、同時実行の枠の数）も併記する。
 
 ## 9. SHINAPS-98 の初回
 

package/plugins/shinaps-claude/references/dev-comparison/configurations.md

@@ -1,15 +1,15 @@
 # 構成表と担当割当
 
-比較の構成（P1〜P7）ごとに、親の起動コマンド、各担当のモデルと起動手段を決める。工程・役割・担当指示・成果物・終了条件は全構成で同じで、[工程](workflow.md)に従う。担当の起動方法は[起動手順](launch.md)に従う。
+比較の構成（P1〜P7）ごとに、親の起動方法、各担当のモデルと起動手段を決める。工程・役割・担当指示・成果物・終了条件は全構成で同じで、[工程](workflow.md)に従う。担当の起動方法は[起動手順](launch.md)に従う。
 
-この表が指定値の正本である。比較条件ファイルには、比較セットで使う構成の行をこの表の写しとして書き、実行権限を加える。
+この表が既定の指定値である。比較条件ファイルには、比較セットで使う構成の行をこの表の写しとして書き、実行権限を加える。比較の目的で値（親のモデルなど）を変える場合は、変えた項目と理由を条件ファイルに書く。照合と記録は、条件ファイルの値で行う。
 
 ## 全構成で共通の指定
 
 - 推論は medium。
 - Fast なし。Claude は standard（Fast を有効にしない）、Codex は `service_tier="default"` を指定する。Fast の有無はモデルと別の比較条件で、P1〜P7 はすべて Fast なしに固定する。
-- `gpt-6.1-sol` の既定の推論は low で、利用者のグローバル設定の service_tier が priority の場合があるため、親・子とも推論と tier を起動のたびに明示する。
-- 実行権限はこの表で固定しない。比較条件ファイルに記録した「実施者が既に許可した実行権限」（例: Claude の `--permission-mode <mode>`、Codex の `--sandbox <mode> --ask-for-approval <policy>`）を親の起動コマンドに明示する。
+- `gpt-6.1-sol` の既定の推論は low で、利用者のグローバル設定の service_tier が priority の場合がある。このため、推論は親・子とも起動のたびに明示し、tier は指定できる手段（Claude の親の起動コマンド、Codex アプリの親の設定、`codex exec`）で毎回明示する。
+- 実行権限はこの表で固定しない。比較条件ファイルに記録した「実施者が既に許可した実行権限」（例: Claude の `--permission-mode <mode>`、Codex の `--sandbox <mode> --ask-for-approval <policy>`）を親の起動方法（Claude の親は起動コマンド、Codex アプリの親は設定）に明示する。
 
 ## 観測手段の無い項目
 
@@ -20,42 +20,52 @@
 
 これ以外の指定（モデル・推論、Claude の service_tier、Codex の sandbox・承認）は観測値と照合する。
 
+## 環境の条件
+
+Codex の親（P4〜P7）のサブエージェントは、次の条件で動く。ほかの構成とは揃えられないので、実行記録と比較記録に書き、確認できなかった値を確認済みとしない。
+
+- 子ごとに sandbox・承認を指定できず、親の値を引き継ぐ（役割定義にも書けない）。子の観測値（rollout の `turn_context`）は、親の指定値と照合する。
+- 親を含む同時実行の上限がある。実行記録には、Phase 1 で読んだ枠の数と、上限のために後から起動した担当の起動待ちの時間を書く。
+- tier は担当ごとには指定できず、親の設定を引き継ぐ（公式資料の記述）。記録に残らないので、上の「観測手段の無い項目」の Codex の service_tier として、親の指定値を「指定のみ」で書く。
+- 担当指示は、比較専用の役割定義（`shinaps-comparison-<役割>`。`roles/*.md` から生成した developer の指示）で渡す。P1〜P3 は、同じ担当指示を依頼の本文で渡す。渡し方の違いは構成差として比較記録に書く。
+
 ## 構成
 
-| 構成 | 入口・担当数 | 親（新しいセッションの起動コマンド） | 子の基本モデル | 担当2 |
+| 構成 | 入口・担当数 | 親（新しいセッションの起動方法） | 子の基本モデル | 担当2 |
 |---|---|---|---|---|
 | P1 混成 | `dev-mixed`（2体固定） | `claude --model opus --effort medium <条件ファイルの Claude 実行権限>` | Opus | Codex `gpt-6-astra` |
 | P2 | `dev-claude 1体` | 同上 | Opus | なし |
 | P3 | `dev-claude 2体` | 同上 | Opus | Opus（別コンテキスト） |
-| P4 | `dev-codex-astra 1体` | `codex -m gpt-6-astra -c model_reasoning_effort='"medium"' -c service_tier='"default"' <条件ファイルの Codex 実行権限>` | `gpt-6-astra` | なし |
+| P4 | `dev-codex-astra 1体` | Codex アプリの新しいチャット（モデル `gpt-6-astra`、推論 medium、Fast なし、<条件ファイルの Codex 実行権限> をアプリの設定で指定し、設定の手順を条件ファイルに書く） | `gpt-6-astra` | なし |
 | P5 | `dev-codex-astra 2体` | 同上 | `gpt-6-astra` | `gpt-6-astra`（別スレッド） |
-| P6 | `dev-codex-sol 1体` | `codex -m gpt-6.1-sol -c model_reasoning_effort='"medium"' -c service_tier='"default"' <条件ファイルの Codex 実行権限>` | `gpt-6.1-sol` | なし |
+| P6 | `dev-codex-sol 1体` | Codex アプリの新しいチャット（モデル `gpt-6.1-sol`、推論 medium、Fast なし、<条件ファイルの Codex 実行権限> をアプリの設定で指定し、設定の手順を条件ファイルに書く） | `gpt-6.1-sol` | なし |
 | P7 | `dev-codex-sol 2体` | 同上 | `gpt-6.1-sol` | `gpt-6.1-sol`（別スレッド） |
 
 ## 担当割当
 
-O = Opus（Claude Agent）、A = `gpt-6-astra`（codex exec）、S = `gpt-6.1-sol`（codex exec）。担当数と継続／新規の規則は[工程](workflow.md#2-役割と継続の規則)の役割表に従う。「—/O」は 1体の設定ではなし、2体の設定では O を表す。
-
-| Phase | 役割 | P1 | P2/P3 | P4/P5 | P6/P7 | Codex の sandbox |
-|---|---|---|---|---|---|---|
-| 2 | 探索 | O | O | A | S | read-only |
-| 3 | 設計担当1（設計統合・プラン統合・設計適合性・指摘統合） | O | O | A | S | read-only |
-| 3 | 設計担当2 | A | —/O | —/A | —/S | read-only |
-| 4 | 計画レビュー担当1 | O | O | A | S | read-only |
-| 4 | 計画レビュー担当2 | A | —/O | —/A | —/S | read-only |
-| 4 | 計画簡素化担当1 | O | O | A | S | read-only |
-| 4 | 計画簡素化担当2 | A | —/O | —/A | —/S | read-only |
-| 4, 6 | 指摘検証（verifier） | O | O | A | S | read-only |
-| 5, 7 | 実装 | O | O | A | S | 親に許可された sandbox（条件ファイル） |
-| 6 | 設計適合性 | O | O | A | S | read-only |
-| 6 | 独立コードレビュー | A | O | A | S | read-only |
-| 6 | refine | O | O | A | S | read-only |
-| 6 | 実装の簡素化 | A | O | A | S | read-only |
+O = Opus、A = `gpt-6-astra`、S = `gpt-6.1-sol`。起動手段は親で決まる。Claude の親（P1〜P3）の O は Claude Agent、A は `codex exec`。Codex の親（P4〜P7）の A・S は、比較専用の役割を指定した Codex のサブエージェント。担当数と継続／新規の規則は[工程](workflow.md#2-役割と継続の規則)の役割表に従う。「—/O」は 1体の設定ではなし、2体の設定では O を表す。
+
+| Phase | 役割 | P1 | P2/P3 | P4/P5 | P6/P7 |
+|---|---|---|---|---|---|
+| 2 | 探索 | O | O | A | S |
+| 3 | 設計担当1（設計統合・プラン統合・設計適合性・指摘統合） | O | O | A | S |
+| 3 | 設計担当2 | A | —/O | —/A | —/S |
+| 4 | 計画レビュー担当1 | O | O | A | S |
+| 4 | 計画レビュー担当2 | A | —/O | —/A | —/S |
+| 4 | 計画簡素化担当1 | O | O | A | S |
+| 4 | 計画簡素化担当2 | A | —/O | —/A | —/S |
+| 4, 6 | 指摘検証（verifier） | O | O | A | S |
+| 5, 7 | 実装 | O | O | A | S |
+| 6 | 設計適合性 | O | O | A | S |
+| 6 | 独立コードレビュー | A | O | A | S |
+| 6 | refine | O | O | A | S |
+| 6 | 実装の簡素化 | A | O | A | S |
 
 - P1 は eafbbc5 の Claude 版 `dev` の割当を再現し、担当1 を Opus、担当2 を Codex とする。ただし比較専用の担当指示を使い、review / refine / simplify スキルを経由しないので、現行 `dev` の実行結果そのものではない。
 - 担当番号は起動前に固定する。
-- Claude の担当は sandbox を個別に持たず親の権限で動き、Codex の担当は担当ごとに sandbox を持つ。この権限機構の差は同一とみなさず、条件ファイルと比較記録に書く。
-- P4〜P7 の親は Codex だが、子はすべて `codex exec` で起動する。Codex の親で使わない手段は[起動手順](launch.md#codex-の親で使わない手段)に書く。
+- P1 の A（`codex exec`）の sandbox は `read-only` にする。P4〜P7 の担当は、親の sandbox を引き継ぐ（上の「環境の条件」）。実装担当が使えるのは、条件ファイルに書いた親の権限の範囲である。
+- Claude の担当と Codex のサブエージェントは、親の権限で動く。`codex exec` の担当は、担当ごとに sandbox を持つ。この権限機構の差は同一とみなさず、条件ファイルと比較記録に書く。
+- P4〜P7 の担当は、すべて Codex のサブエージェントで起動する。P1 の Codex の担当（`codex exec`）とは、起動手段が違う。
 
 ## 比較の組み合わせ
 

package/plugins/shinaps-claude/references/dev-comparison/launch.md

@@ -1,6 +1,8 @@
 # 担当の起動手順
 
-[構成表](configurations.md)の担当割当で、O の担当は Claude Agent、A・S の担当は `codex exec` で起動する。どの起動手段でも、該当する担当指示（`roles/<役割>.md`）の全文と今回の入力（役割名・担当番号・ラウンド・今回の割当と担当数、工程が定める渡す情報）を渡す。起動・再開・交代の履歴、ID、指定値、開始・終了時刻は[実行記録](record.md)の担当表へ書く。
+[構成表](configurations.md)の担当割当と起動手段に従う。Claude の親（P1〜P3）は、O の担当を Claude Agent で、A の担当を `codex exec` で起動する。Codex の親（P4〜P7）は、A・S の担当を、比較専用の役割を指定した Codex のサブエージェントで起動する。
+
+担当指示（`roles/<役割>.md`）は、Claude Agent と `codex exec` では依頼の本文に全文を入れて渡す。Codex のサブエージェントでは、担当指示から生成した比較専用の役割定義（`shinaps-comparison-<役割>`）で渡すので、依頼の本文には入れない。どの起動手段でも、今回の入力を依頼の本文で渡す。今回の入力は、役割名・担当番号・ラウンド・今回の割当と担当数、工程が定める渡す情報である。読む資料はパスで指定し、作業記録にある他の担当の成果物は、工程が渡すと定めたもの以外を読ませない。担当には、他のエージェントを起動しないこと、実装担当以外はファイルを変更しないことを伝える。起動・再開・交代の履歴、ID、指定値、開始・終了時刻は、[実行記録](record.md)の担当表へ書く。
 
 ## Claude Agent
 
@@ -13,6 +15,8 @@
 
 ## codex exec
 
+Claude の親（P1）が Codex の担当を起動するときに使う。
+
 ```sh
 codex exec --sandbox <構成表の sandbox> -c approval_policy='"never"' \
   -m <model> -c model_reasoning_effort='"medium"' -c service_tier='"default"' \
@@ -20,19 +24,24 @@ codex exec --sandbox <構成表の sandbox> -c approval_policy='"never"' \
 ```
 
 - cwd は実行の作業環境（worktree またはクローン）のルートにする。
-- sandbox は構成表に従う。実装担当は条件ファイルに記録した、親に許可された sandbox の範囲で起動し、他の担当は `read-only` で起動する。許可の範囲を超える sandbox を指定しない。
+- sandbox は構成表に従う。許可の範囲を超える sandbox を指定しない。
 - 再開は `codex exec <同じフラグ> resume <thread_id> --json -o <report> - < <prompt> > <events>` で行う。起動時と同じモデル・推論・tier・sandbox を毎回明示する。同時に動いている別の担当を再開しないよう、`--last` は使わない。
 - プロンプトは `raw/cli/` にファイルとして保存して標準入力で渡し、担当指示の全文と今回の入力を含める。本文をシェルのコマンド文字列へ展開しない。プロンプト・レポート・イベントログのパスは役割・担当番号・ラウンド・バッチごとに分ける。
 - `thread.started` の `thread_id` を担当表に記録する。完了はプロセスの終了コード、`turn.completed`、空でない最終レポートの 3 つで判定し、`error` / `turn.failed` は未完了とする。担当の応答が完成したらプロセスは終了してよい。継続に使うのは thread_id と文脈である。
 - 失敗時は他のモデル・Fable・個人用 alias へ切り替えない。部分出力を保存し、再試行は別のファイル名で行って前回を残す。ユーザーのグローバル設定を変更しない。起動の失敗を理由に権限を広げない。許可された権限で `codex exec` を実行できない場合は、担当を親自身で代行せず、制約を報告して止まる。
 
-## Codex の親で使わない手段
-
-登録済みのカスタムエージェント（`$CODEX_HOME/agents/shinaps-*.toml`）と `spawn_agent` は、制作工程の担当に使わない。`spawn_agent` でも `fork_turns:"none"` でモデル・推論は明示できるが、次の 4 点で構成間の条件を揃えられないためである。
-
-- 子ごとに tier を指定できない（`spawn_agent` に tier の引数が無い）。
-- 担当ごとに sandbox を指定できず、子は親の sandbox を引き継ぐ。独立担当を `read-only` で起動できない。
-- 子の同時実行枠（親を含めて 4）があり、2体の設定の Phase 4 が順次になって、起動手段の制約で時間の比較が変わる。
-- P1 の Codex 担当（Claude の親から `codex exec` で起動）と起動手段が揃わない。
-
-このため、Codex ネイティブの子エージェントの使い勝手は比較の対象外である。
+## Codex のサブエージェント
+
+Codex の親（P4〜P7）が使う。`codex exec` は使わない。
+
+- 起動は `spawn_agent` で行い、毎回 `agent_type: "shinaps-comparison-<役割>"`、`fork_turns: "none"`、`model: <構成表のモデル>`、`reasoning_effort: "medium"` を明示する。役割は `roles/` のファイル名（`architect`、`explorer`、`implementer`、`plan-reviewer`、`refine-agent`、`review-verifier`、`reviewer`、`simplifier`）である。設計担当1・2 は `architect`、計画・実装の簡素化は `simplifier` を使う。
+- 比較専用の役割定義には model・推論を書かない。モデルと推論は、この指定で構成ごとに選ぶ。`fork_turns` を省略すると、親の履歴・モデル・推論を引き継いで上書きできず、独立した担当にもならない。
+- 比較専用の役割以外の `agent_type`（通常の dev の `shinaps-architect` などを含む）は使わない。
+- 実行で最初に起動した担当の完了後に、その子の rollout の `turn_context` のモデル・推論を指定と照合する。違えば不一致として記録し、報告して実行を止める（以後の担当も同じ仕組みで起動するので、照合は最初の 1 体で足りる。その実行は比較データにならないため、続けない。全担当の照合は Phase 9 の[実行記録](record.md)の手順で行う）。
+- `task_name` は、実行の中で重複しない名前にする。起動時に一度だけ決め、継続（`followup_task`）では変えない。一意にするため、`p<起動した Phase>_<役割>_<担当番号>_r<ラウンド>` の形で作る。役割の `-` は `_` に置き換え、使う文字は英小文字・数字・`_` だけにする（例: `p4_plan_reviewer_2_r1`、`p6_review_verifier_1_r2`）。交代した担当は、末尾に `_s<交代の回数>` を付ける。担当表には、`agent_type`・`task_name`・返された ID を記録する。
+- 渡した `message` の全文を `raw/agents/<task_name>-<n>.md`（n は、その担当への依頼の通し番号。起動が 1、継続ごとに 1 増える）に保存する。rollout には、`message` が暗号化されて残るためである。
+- サブエージェントは、親と同じ作業ディレクトリで動き、sandbox・承認・tier を親から引き継ぐ（[構成表](configurations.md#環境の条件)）。読み取り専用の役割は、担当への指示で変更を禁止する。変更が無いことは、[工程](workflow.md)の作業ツリーの確認で確かめる。
+- 同じ役割の継続には、同じ ID へ `followup_task` で依頼する。`send_message` は担当のターンを開始しないので、継続には使わない。工程に、実行中の担当へ補足を送る場面は無い。
+- 完了は `wait_agent` で待つ。待つ時間は分単位にし、短い間隔で繰り返さない。完了は、担当の完了通知と、空でない最終回答で判定する。`wait_agent` の時間切れや、`followup_task` の受領だけでは完了としない。
+- 同時実行の上限: Phase 1 で、親のセッションの開発者メッセージが示す枠の数（親を含む）を実行記録に書く。同時に実行中にする担当は、枠から 1 を引いた数までにする。工程が並行起動を求める担当がそれを超えるときは、役割表の順に枠の分だけ起動し、残りは実行中の担当が完了してから起動する（渡す情報と独立性は[工程](workflow.md)の規則のまま）。起動を待った担当は、待ち始めと起動の時刻を担当表に書く。
+- 起動できない（実行中の担当が無いのに枠の不足で失敗する場合を含む）、または完了しない担当は、[工程](workflow.md)の「実行の制約」のとおり、その担当を未完了として記録し、工程の終了条件に従う。`codex exec`・ほかのモデル・モデルごとの役割定義へ切り替えず、親が代わりに作業せず、ユーザーのグローバル設定（同時実行の上限を含む）を変更しない。

package/plugins/shinaps-claude/references/dev-comparison/record.md

@@ -12,7 +12,7 @@
 
 ## 開始前の照合
 
-Phase 1 で親の観測値（Claude: 自セッションの transcript、Codex: 自スレッドの rollout の `turn_context`）が読めれば、指定値と照合する。照合する項目は、Claude はモデル・推論・service_tier、Codex はモデル・推論・sandbox・承認である。不一致なら開始せず、構成表の起動コマンドで新しいセッションを開始し直すよう報告する。読めなければその項目を未検証として進める。観測手段の無い項目は照合せず、指定値を記録する。
+Phase 1 で親の観測値（Claude: 自セッションの transcript、Codex: 自スレッドの rollout の `turn_context`）が読めれば、指定値と照合する。照合する項目は、Claude はモデル・推論・service_tier、Codex はモデル・推論・sandbox・承認である。不一致なら開始せず、構成表の起動方法で新しいセッションを開始し直すよう報告する。読めなければその項目を未検証として進める。観測手段の無い項目は照合せず、指定値を記録する。
 
 ## 親の特定
 
@@ -25,8 +25,8 @@ Phase 1 で親の観測値（Claude: 自セッションの transcript、Codex:
 
 ## run-record.md の様式
 
-- **実行の識別**: 構成、入口、担当数、比較セット ID、条件ファイルのハッシュ（条件ファイルが課題ファイル・規約スナップショットのハッシュを列挙する）、比較スキルの plugin version と `references/dev-comparison/` のツリーハッシュ（使った plugin の `references/dev-comparison` を cwd にして `find . -type f | LC_ALL=C sort | xargs shasum -a 256 | shasum -a 256` の出力）、課題側の開始コミット、開始・終了時刻。
-- **担当表**（1 担当 1 行）: 役割、担当番号、ラウンド、実行手段、ID（親セッション ID / Claude agent ID / Codex thread_id）、起動・再開・交代の履歴、指定（モデル・推論・tier・Fast・sandbox）、観測（同じ項目、根拠ファイルと時点）、判定（一致／不一致／未検証／指定のみ）、開始・終了時刻、終了状態、使用量（実測／推定／取得不可と出典）。
+- **実行の識別**: 構成、入口、担当数、比較セット ID、条件ファイルのハッシュ（条件ファイルが課題ファイル・規約スナップショットのハッシュを列挙する）、比較スキルの plugin version と `references/dev-comparison/` のツリーハッシュ（使った plugin の `references/dev-comparison` を cwd にして `find . -type f | LC_ALL=C sort | xargs shasum -a 256 | shasum -a 256` の出力）、課題側の開始コミット、開始・終了時刻。Codex の親では、Phase 1 で読んだ同時実行の枠の数と、配置済みの比較専用の役割定義のハッシュ（`$CODEX_HOME/agents` を cwd にした `ls shinaps-comparison-*.toml | LC_ALL=C sort | xargs shasum -a 256 | shasum -a 256` の出力）。
+- **担当表**（1 担当 1 行）: 役割、担当番号、ラウンド、実行手段、ID（親セッション ID / Claude agent ID / Codex thread_id / サブエージェントの task_name・返された ID と、rollout の thread_id）、起動・再開・交代の履歴、指定（モデル・推論・tier・Fast・sandbox）、観測（同じ項目、根拠ファイルと時点）、判定（一致／不一致／未検証／指定のみ）、開始・終了時刻、終了状態、起動待ち（同時実行の上限で後から起動した担当の、待ち始めと起動の時刻）、使用量（実測／推定／取得不可と出典）。
 - **時間**: 総経過時間と Phase ごとの開始・終了。時刻はメインが `date -u +%FT%TZ` で記録する。並行か順次かは担当表の時刻から導く。
 - **修正**: Phase 7 の修正回数、実装後レビューのラウンド数、計画の修正版数。検証の回数は担当表の verifier の行から数える。
 - **人の介入・中断**: 時刻、内容（質問・回答・承認・手作業・環境の復旧）、理由、所要時間。全件を記録する。
@@ -39,19 +39,24 @@ Phase 1 で親の観測値（Claude: 自セッションの transcript、Codex:
   - 不一致: 観測値が指定値と違う項目がある。
   - 割当外の依頼あり: 担当表に無い AI への依頼がある（下記「割当外の依頼の確認」）。
   - 未完了: 未完了の担当がある。
+  - 制約違反あり: 実装担当の実行区間の外で、作業ツリー（未追跡ファイルを含む）が変わった（[工程](workflow.md)の作業ツリーの確認）。変化したパスを併記する。
 
 ## 観測値の読み方
 
 Phase 9、または読める時点で行う。抽出結果は `raw/settings/` に保存する。
 
 - **Claude（親・子）**: `$CLAUDE_CONFIG_DIR`（未指定なら `~/.claude`）の `projects/` 配下にある親の transcript と `<session-id>/subagents/agent-<id>.jsonl`・`.meta.json` の全 assistant メッセージから、`message.model`・各行の `effort`・`message.usage.service_tier` の組の一覧を抽出し、全期間で変化がないことを確認する。子は Agent が返した ID と対応付ける。
-- **Codex（親・子）**: rollout の全ターンの `turn_context`（`model`・`effort`・`sandbox_policy`・`approval_policy`）を読む。親の rollout は「親の特定」で決めたもの、codex exec の担当の rollout は `$CODEX_HOME/sessions/` 配下でファイル名に担当表の thread_id を含むもの。rollout が無ければ未検証とする。service_tier は指定のみ。
+- **Codex（親・子）**: rollout の全ターンの `turn_context`（`model`・`effort`・`sandbox_policy`・`approval_policy`）を読む。
+  - 親の rollout は、「親の特定」で決めたもの。
+  - `codex exec` の担当の rollout は、`$CODEX_HOME/sessions/` 配下で、ファイル名に担当表の thread_id を含むもの。
+  - サブエージェントの rollout は、最初の行の `session_meta.source.subagent.thread_spawn` で、`parent_thread_id` が親の ID、`agent_path` が担当表の `task_name` に対応し、`agent_role` が担当表の `agent_type` と一致するもの。この rollout の ID を担当表の thread_id に書く。1 件に決まらなければ未検証とする。サブエージェントの sandbox・承認の指定値は、親の値とする。
+  - rollout が無ければ未検証とする。service_tier は指定のみとする。サブエージェントの service_tier の指定値は、親の指定値とする（モデル・推論の指定値は、起動時に指定した値である）。
 - rollout は後で削除されることがあるので、各担当の完了後に読む。
 
 ## 使用量
 
 - **Claude**: 同じ `message.id` の行は一度だけ数える（同じ応答が transcript に複数行で記録されるため）。担当ごとの合計と総計で重ねて数えない。
-- **Codex（親・子）**: スレッドの rollout の最後の `token_count` の `info.total_token_usage`（スレッドの累計値。cached・reasoning の内訳を含む）をスレッドごとに一度だけ使い、スレッド間で合計する。resume の `turn.completed.usage` も累計値なので、イベントログの値を合計しない。イベントログは完了判定と thread_id の取得に使う。
+- **Codex（親・子）**: スレッドの rollout の最後の `token_count` の `info.total_token_usage`（スレッドの累計値。cached・reasoning の内訳を含む）をスレッドごとに一度だけ使い、スレッド間で合計する。resume の `turn.completed.usage` も累計値なので、イベントログの値を合計しない。イベントログは完了判定と thread_id の取得に使う。サブエージェントは、スレッドごとの値を書く。親の累計に子の使用量が含まれないことを確かめた場合だけ、確かめた方法と根拠を併記して合計を書く。確かめられなければ、総計は未確定とする。
 - 金額は取得できないので「取得不可」と書く。料金表からの換算は推定欄に根拠付きで書き、実測と合計しない。
 
 ## 割当外の依頼の確認
@@ -59,8 +64,8 @@ Phase 9、または読める時点で行う。抽出結果は `raw/settings/`
 構成表に無い AI への依頼が無いことを、次の一つの手順で確認する。
 
 1. その実行の cwd の記録をすべて列挙する（Claude の project ディレクトリの transcript、`$CODEX_HOME/sessions/` 配下で `session_meta` の `cwd` が一致する rollout）。
-2. 親・子の記録から、AI への依頼に当たる呼び出しを列挙する（Claude: Agent・Skill・MCP の tool_use と Bash コマンド、Codex: rollout の function call・`spawn_agent`・シェルコマンド）。呼び出しの単位（tool_use 1 件、function call 1 件）で、その呼び出しが AI を起動したかを判定する。コマンドやプロンプトの本文に文字列が含まれるだけのものは数えない。
-3. 1 と 2 を担当表と突き合わせる。担当表に無い依頼があれば記録し、判定に「割当外の依頼あり」を書く。
+2. 親・子の記録から、AI への依頼に当たる呼び出しを列挙する（Claude: Agent・Skill・MCP の tool_use と Bash コマンド、Codex: rollout の function call（`spawn_agent`・`followup_task` を含む）・シェルコマンド）。呼び出しの単位（tool_use 1 件、function call 1 件）で、その呼び出しが AI を起動したかを判定する。コマンドやプロンプトの本文に文字列が含まれるだけのものは数えない。子の記録にある `spawn_agent`、`thread_spawn.depth` が 2 以上の rollout、Codex の親による `codex exec` の実行は、担当表に無い依頼として数える。
+3. 1 と 2 を担当表と突き合わせる。担当表に無い依頼があれば記録し、判定に「割当外の依頼あり」を書く。AI Terminal Bridge で起動を依頼された実行の、依頼の受信（`read_messages`・`ack_messages`）と依頼元への終了・停止の報告（`send_message`）は、割当外の依頼に数えない。
 
 ## 2体目の発見の分類
 

package/plugins/shinaps-claude/references/dev-comparison/workflow.md

@@ -19,8 +19,8 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 ### 実行の制約
 
 - 構成表の担当の起動は、比較用入口の実行に含まれる許可として行う。新しい作業環境（worktree・クローン）は作らない。作業環境は実施者が事前に用意する。
-- 指定したモデル・推論・tier・実行権限で担当を起動できなければ、他のモデル・設定・起動手段へ切り替えず、メインが代行もせず、その担当を未完了として記録する。
-- 構成表に無い AI への依頼手段（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）を使わない。
+- 構成表と[起動手順](launch.md)がその起動手段で指定する値（モデル・推論。起動手段が指定できる場合は tier・実行権限も）で担当を起動できなければ、他のモデル・設定・起動手段へ切り替えず、メインが代行もせず、その担当を未完了として記録する。
+- 構成表に無い AI への依頼手段（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）を使わない。AI Terminal Bridge で起動を依頼された場合の、依頼の受信と、依頼元への終了・停止の報告は、これに当たらない。実行中の質問は上の入力手段で行う。
 - 比較実行中は自動メモリへ書き込まない。
 - 規約は比較条件ファイルの規約スナップショットだけを使い、`search_rules` などの shinaps MCP を呼ばない。
 
@@ -42,11 +42,13 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 | 6 | refine | 1 | 同一ラウンドのバッチは継続 | [refine-agent](roles/refine-agent.md) |
 | 6 | 実装の簡素化 | 1 | ラウンドごとに新規 | [simplifier](roles/simplifier.md)（実装の簡素化） |
 
-- 担当を起動するときは[起動手順](launch.md)に従い、担当指示の全文と今回の入力（役割名・担当番号・ラウンド・今回の割当と担当数）を渡す。担当番号は起動前に固定する。
+- 担当を起動するときは[起動手順](launch.md)に従い、担当指示と今回の入力（役割名・担当番号・ラウンド・今回の割当と担当数）を渡す。担当番号は起動前に固定する。
 - 異なる役割は、同じモデルでも別のコンテキストで起動する。同じ役割の継続は同じ ID を再開する。再開できなければ同じ割当（モデル・推論・tier・起動手段）の新しい担当へ確認済み・未確認の範囲と最新の文脈を引き継ぎ、交代を実行記録に書く。
 - 設計担当2 を他の役割へ流用しない。設計担当1 は設計から指摘統合まで同じ ID で続ける。
 - 独立に確認する担当（設計担当、計画レビュー担当、計画簡素化担当、実装後の4役割）は、今回の他担当の結果を受け取らず、意見を交換しない。全担当の完了まで計画・対象コードを変更しない。
-- メインは担当の起動・待機・全文保存・受け渡し・ユーザーへの確認・実行記録だけを行う。指摘を先に選別・要約・重複整理せず、検証をやり直さない。verifier と設計担当も自分で他の担当を起動しない。
+- メインは担当の起動・待機・全文保存・受け渡し・ユーザーへの確認・実行記録だけを行う。指摘を先に選別・要約・重複整理せず、検証をやり直さない。担当は自分で他の担当やエージェントを起動しない。
+- 「並行して起動する」担当の数が、起動手段の同時実行の上限を超える場合は、[起動手順](launch.md)のとおり分けて起動する。分けても、担当の数・独立性・渡す情報は変えない。
+- 作業ツリー（未追跡ファイルを含む）は、実装担当の実行区間の外では変わらない。メインは、Phase 1 の開始時、実装担当の各依頼の前と完了後、Phase 9 の開始時に、作業ツリーの値（`git diff HEAD` の出力と、`git ls-files --others --exclude-standard -z | xargs -0 shasum -a 256` の出力を合わせた sha256。`.shinaps/` は除外されている）を記録する。実装担当の完了後から次の依頼の前まで（Phase 1〜実装前、実装後〜Phase 9 を含む）で値が変わっていれば、[実行記録](record.md)の判定に「制約違反あり」と、変化したパスを書く。前後の値の比較なので、区間の途中で変えて元に戻した場合は検出できない。
 
 ## 3. 担当数の設定
 
@@ -56,7 +58,7 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 
 ### Phase 1: 条件の受け取りと開始前の照合
 
-1. 比較条件ファイル（必須）を読み、課題・開始コミット・規約スナップショット・探索条件・合格条件・許可範囲・実行権限・この構成の親の起動コマンドを確定する。条件ファイルにこの構成が無ければ開始しない。
+1. 比較条件ファイル（必須）を読み、課題・開始コミット・規約スナップショット・探索条件・合格条件・許可範囲・実行権限・この構成の親の起動方法を確定する。条件ファイルにこの構成が無ければ開始しない。
 2. 作業環境が開始状態であることを確認する。`HEAD` が開始コミットと一致し、`git status --porcelain` が空であること（`.shinaps/` は `.shinaps/.gitignore` で除外される）。満たさなければ開始しない。
 3. 課題から英語 slug（kebab-case、30 文字以内）を作り、作業ディレクトリ `.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/` と `raw/` を作る。
 4. `run-record.md` を作り、親の ID と指定値を記録し、[開始前の照合](record.md#開始前の照合)を行う。観測値が読めて指定値と一致しなければ開始しない。
@@ -216,7 +218,8 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 │   ├── simplify.md            ← Phase 6 の実装の簡素化の生レポート（2 回目は simplify-2.md）
 │   ├── architect-revised-{n}.md  ← 計画の修正版（n は 1 始まり）
 │   ├── settings/              ← 観測値の抜粋
-│   └── cli/                   ← codex exec のプロンプト・イベントログ
+│   ├── cli/                   ← codex exec のプロンプト・イベントログ（P1）
+│   └── agents/                ← サブエージェントへ渡した依頼の全文（P4〜P7）
 ├── implementation.md          ← 実装ログ・変更ファイル一覧・動作確認結果
 ├── architecture-review.md     ← 設計担当1 の設計適合性レビュー
 ├── architecture-review-{n}.md ← 修正後の設計適合性レビュー

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

@@ -1,8 +1,7 @@
 ---
 name: dev-claude
-description: 比較実行用。shinaps:dev の工程を Claude（Opus / medium）の担当だけで実行する（P2: 同じ役割1体、P3: 2体）。通常の開発には shinaps:dev を使う。
+description: 比較実行用。shinaps:dev の工程を Claude（Opus / medium）の担当だけで実行する（P2: 同じ役割1体、P3: 2体）。この入口・担当数・比較条件ファイルを明示した依頼（利用者本人、または利用者が委託した依頼元からの AI Terminal Bridge の依頼）でだけ使う。通常の開発には shinaps:dev を使う。
 argument-hint: <1体|2体> <比較条件ファイル>
-disable-model-invocation: true
 ---
 
 # 比較用 dev（Claude のみ）
@@ -16,6 +15,8 @@ disable-model-invocation: true
 | `/shinaps:dev-claude 1体 <比較条件ファイルの絶対パス>` | P2 |
 | `/shinaps:dev-claude 2体 <比較条件ファイルの絶対パス>` | P3 |
 
+依頼に明示された引数だけを使い、条件ファイルを探したり推定したりしない。
+
 担当数（`1体` / `2体`）と比較条件ファイルはどちらも必須。どちらかが無い、または担当数が `1体` / `2体` 以外なら、「`/shinaps:dev-claude <1体|2体> <比較条件ファイル>` で指定してください」と返して終了する。
 
 ## 読む資料
@@ -31,7 +32,7 @@ disable-model-invocation: true
 
 ## 守ること
 
-- 構成表のこの構成の行にある担当だけを、構成表の起動手段で起動する。構成表に無い AI への依頼（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）をしない。
+- 構成表のこの構成の行にある担当だけを、構成表の起動手段で起動する。構成表に無い AI への依頼（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）をしない。AI Terminal Bridge で起動を依頼された場合の、依頼元への終了・停止の報告は、これに当たらない（[工程](../../references/dev-comparison/workflow.md)の「実行の制約」）。
 - 既存の `dev`・`review`・`refine`・`simplify` スキルと、登録済みの Shinaps エージェントを使わない。
 
 ## 完了報告

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

@@ -1,8 +1,7 @@
 ---
 name: dev-mixed
-description: 比較実行用。shinaps:dev の工程を Claude（Opus / medium）と Codex（gpt-6-astra / medium）の混成の担当で実行する（P1）。通常の開発には shinaps:dev を使う。
+description: 比較実行用。shinaps:dev の工程を Claude（Opus / medium）と Codex（gpt-6-astra / medium）の混成の担当で実行する（P1）。この入口と比較条件ファイルを明示した依頼（利用者本人、または利用者が委託した依頼元からの AI Terminal Bridge の依頼）でだけ使う。通常の開発には shinaps:dev を使う。
 argument-hint: <比較条件ファイル>
-disable-model-invocation: true
 ---
 
 # 比較用 dev（混成）
@@ -15,6 +14,8 @@ disable-model-invocation: true
 |---|---|
 | `/shinaps:dev-mixed <比較条件ファイルの絶対パス>` | P1（担当数は 2体で固定） |
 
+依頼に明示された引数だけを使い、条件ファイルを探したり推定したりしない。
+
 比較条件ファイルは必須。無ければ「`/shinaps:dev-mixed <比較条件ファイル>` で指定してください」と返して終了する。
 
 ## 読む資料
@@ -30,7 +31,7 @@ disable-model-invocation: true
 
 ## 守ること
 
-- 構成表の P1 の行にある担当だけを、構成表の起動手段で起動する。構成表に無い AI への依頼（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）をしない。
+- 構成表の P1 の行にある担当だけを、構成表の起動手段で起動する。構成表に無い AI への依頼（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）をしない。AI Terminal Bridge で起動を依頼された場合の、依頼元への終了・停止の報告は、これに当たらない（[工程](../../references/dev-comparison/workflow.md)の「実行の制約」）。
 - 既存の `dev`・`review`・`refine`・`simplify` スキルと、登録済みの Shinaps エージェントを使わない。
 
 ## 完了報告

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

@@ -25,6 +25,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 
 - 依頼の範囲・受入条件・Gitの作業ディレクトリ・ブランチ・既存差分・許可範囲を確認する。
 - Codexから依頼された実装・修正は、依頼の対象Issueに紐づく。Claudeは別のIssueを作らない。
+- 比較用入口（`dev-mixed`・`dev-claude`）と比較条件ファイルを指定した比較実行の依頼は、このスキルの対象外にする。指定された入口を起動し、実行中の扱いと報告は入口に従う（[references/workflow.md](references/workflow.md) の「Bridgeでの依頼と報告」）。
 - 実装・修正には `shinaps:dev` を使う。`shinaps:dev` は内部で簡素化・規約照合・レビューを行うので、これらを別に起動しない。`shinaps:dev` を使えない場合は、独自の手順で代わりに実装せずCodexへ報告する。
 - `shinaps:dev` の委託（サブエージェントや別のCLI）は、依頼の許可範囲に `dev_delegation` が書かれている場合だけ使う。許可範囲に `dev_delegation` がない依頼では委託しない。worktreeの作成は含まない。
 - `shinaps:dev` が利用者に確認する場面（計画の判断、不明点、承認）では、人ではなくCodexへ相談する。Codexが既存の合意で答えた内容を人へ再確認しない。仕様・受入条件・許可範囲の変更が必要な場合は、Codexが人に確認する。

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

@@ -94,6 +94,7 @@ AI Terminal Bridge（以下Bridge）の本体は同梱しない。導入済み
 | 完了の報告（ClaudeからCodex） | 対象差分、自動検証の結果、起動方法、確認観点、既知の制限、未解決の事項、`shinaps:dev` 内のレビュー結果の要約と未解決の指摘。コミットした場合は、コミットSHAと `shinaps:commit` の検証・レビューの結果 |
 | 人のレビュー・コミット完了の報告（ClaudeからCodex） | 下の「人のレビュー・コミット完了の報告」の項目 |
 | 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先リポジトリの設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
+| 比較実行の依頼（CodexからClaude） | [比較手順](../../../references/dev-comparison/comparison.md#5-実行)の項目だけ。下の定型文と許可範囲は含めない。Claudeは指定された比較用入口で実行し、このスキルの実装・修正の手順（`shinaps:dev`、Codexへの相談、コミット）を適用しない |
 
 コミットの依頼では、`commit_mode` がない場合の開始時の確認と、通常モードの単位ごとの承認を、Codexが人へ取り次ぐ。Codexは自分で選択・承認しない。
 

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

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

package/plugins/shinaps-codex/agents/shinaps-comparison-architect.toml

@@ -0,0 +1,3 @@
+name = "shinaps-comparison-architect"
+description = "比較用 dev 入口（dev-codex-astra・dev-codex-sol）専用の設計担当。通常の開発では使わない。"
+developer_instructions = "# 設計担当\n\neafbbc5 の Claude 版 agents の本文から作った比較用の担当指示。元のファイル: `plugins/shinaps-claude/agents/shinaps-architect.md`（設計時の条件は `plugins/shinaps-claude/skills/dev/references/codex-worker.md` の「共通の依頼条件」を含める）。\n\nあなたは比較用 dev の工程の設計担当です。メインから指定された工程・担当番号・今回の割当と担当数に従います。設計担当1 は設計から指摘統合まで同じ担当として続けます。設計担当2 は独立設計と、その設計上の追加確認だけを担当します。\n\n- **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。同じ要件を別の設計担当が独立に設計している場合も、その案や今回の他担当のレポートは読まない。\n- **設計案統合時**（設計担当1、2体の設定のみ）: 設計担当1 と設計担当2 の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。\n- **プラン統合時**（設計担当1）: 計画レビュー担当と計画簡素化担当の指摘に対する verifier の検証結果から、採否と修正版の最終計画を返す。\n- **設計適合性レビュー時**（設計担当1）: 確定した計画・受入条件・合意済み変更と実コード・検証を照合する。計画に記した責務の所有者・配置・依存方向が実コードと全利用側で成立するか確認し、自案の配置判断の欠陥も指摘する。他担当の今回の結果を見る前に結果を確定し、計画節・file:line・影響・修正案・確認済みと未確認の範囲を返す。\n- **指摘統合時**（設計担当1）: 自身の設計適合性レビューと他の実装後レビュー担当の完了後、verifier の検証結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。\n\n## 作業前の必須確認\n\n以下を **自分の設計判断より優先** して読み込む:\n\n- 作業環境のリポジトリ直下の `CLAUDE.md` / `AGENTS.md` / `.cursorrules` / `.github/copilot-instructions.md`\n- **メインから渡された規約スナップショット（rule 全文と、適用される AGENTS.md / CLAUDE.md）** — これは CLAUDE.md と同格の必ず従う規約として扱う\n\n規約と自分の設計案が衝突する場合、規約を優先する (規約側を「時代遅れ」と判断せず、まずは従う)。\n\n## 変更後の構造を先に決める\n\n既存の配置を正解と仮定せず、要件を満たした最終状態の責務・配置・依存方向を先に決める。その状態に必要な移動・分割・置き換えは変更量が大きくても計画する。最小化するのは到達に不要な変更であり、無関係な領域の整理や仮想的な将来への汎用化は含めない。\n\n利用範囲が広がる処理は、現在の所有featureと全利用箇所を調べる。別featureが無関係なfeature内部へ依存するなら、共通の責務だけを適切な層へ切り出し、固有の状態・振る舞いは各featureに残す。独立feature・共通UI・共通ロジックの選択はプロジェクトの規約と責務から決め、利用者が複数という理由だけで共通化しない。\n\n合意済みの機能・外部契約を保つ必要な構造変更は設計判断として行う。仕様変更・未許可の作業範囲への拡大・データ保全に関わる判断はメインへ返す。移動に伴う全利用箇所の更新と旧経路・重複の解消、既存利用側の回帰確認まで計画に含める。\n\n設計時は、配置を移動／維持する理由と、全利用側の更新・旧経路の解消・回帰検証を計画に残す。変更する責務・外部契約・データフロー・実装順・テストと、選択理由・不確実性を返す。\n\n## 検討観点 (内部で衝突させ、単一案に収束)\n\n以下の観点を内部で検討し、トレードオフを踏まえた **唯一の推奨案** を出す:\n\n- **必要な変更の範囲**: 最終状態に必要な構造変更を含め、その到達に不要な変更を除く\n- **clean-architecture**: 責務分割・境界を綺麗に保つ\n- **pragmatic-balance**: 現実的な工数対効果\n- **security**: 認証・認可・入力検証・秘密情報\n- **performance**: 計算量・DB round trip・キャッシュ\n- **testability**: テスト容易性・依存注入\n- **simplicity**: 外部ツール・API が自分で拒否する入力を先回りして検査しない（失敗経路は 1 つ、安全側に倒す）。要件やレビューの列挙に 1 対 1 で分岐を作らず、共通する性質で設計する。失敗の理由を区別するのは動作を変える要件がある場合だけ\n\n## 出力ガイダンス\n\n- **アーキテクチャ判断**: 採用アプローチと、なぜ他を却下したかの WHY\n- **責務と配置**: 変更後の所有者・配置先・利用側からの依存方向と根拠。利用範囲が変わる責務は、移動する／現状に残す理由を示す\n- **変更・移動・削除・新規ファイル一覧**: 絶対パス列挙、責務 1 行\n- **コンポーネント設計**: 主要クラス / 関数 / 型のシグネチャ\n- **データフロー**: 主要なリクエスト・イベントの流れ\n- **ビルド順序**: 依存関係を考慮した実装順\n- **検証方針**: 実行する既存検証と、必要な場合だけ追加・更新する回帰テスト・仕様テスト。その保証対象と既存テストでは不足する理由\n- **観点トレードオフの要約**: 採用理由・却下理由を各観点で 1 行\n\n## 全指摘の統合\n\nメインから「指摘統合」として、自身の設計適合性・独立コードレビュー・refine・実装の簡素化の各担当の指摘を verifier が検証した報告と、原文への参照・差分の更新・検証結果を受け取る。プラン統合でも同じ形式を使う。\n\n- 整理済みの全項目を判断し、各採否を元の出典IDへ対応付ける。要約を無条件に信頼せず、曖昧な点・異論・採否を左右する根拠は原文と実コードを確認する。原文を毎回一律に読み直す必要はない。出典の欠落や未確認事項があればメインへ戻す。\n\n- verifier の分類と根拠を参考に、対立・不確実性・重要な設計判断を追加確認する。全件の事実確認や重複整理を最初から繰り返さない。対立は多数決ではなく根拠から判断する。自分の初期設計も修正対象に含める。\n- すべての指摘・提案の採否と理由を記録する。未確認や担当の未完了を指摘なしとして処理しない。\n- 実装担当へ渡す一つの修正指示を返す。対象ファイル・責務、具体的な変更、維持する契約、必要な検証、修正の依存順を含める。指摘ごとに別々の修正担当を求めない。\n- 合意済み仕様内の修正は判断して進める。仕様・受入条件の変更、機能やユーザー体験を減らす簡素化、権限や対象範囲の変更が必要な判断は、理由と推奨案をメインへ返してユーザーに確認してもらう。\n- 実装後の全体レビューは初回と修正後の最大2ラウンド。2回目の指摘への最終修正・テストの後は3回目のレビューを要求せず、残課題と最終修正が再レビューされていないことを報告する。重大な未解決事項や検証失敗を完了扱いにしない。\n\nコード編集と担当の起動は行わない。メインがあなたの指示を実装担当へ渡し、結果を保存する。\n\n## 動作原則\n\n- **規約に必ず従う**: CLAUDE.md / AGENTS.md / 規約スナップショットを最優先\n- **断言する**: 「〜が良いと思います」ではなく「〜にする」\n- **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す\n- **読むことに専念**: コードや計画ファイルは編集しない (実装担当が修正し、メインが成果物を保存する)\n- **工程に合わせて返す**: 設計・設計案統合・プラン統合時は計画、設計適合性レビュー時は独立した指摘、指摘統合時は採否と実装担当への修正指示\n\n## テスト追加の判断\n\nテスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、不具合の再発防止、または合意された仕様・外部契約の明示と保証を目的にする。仕様を表す既存テストは、過去のバグに由来しなくても残す。追加・更新する場合は、防ぐ不具合または保証する仕様の根拠と期待挙動を示す。実装方法を変えても守るべき挙動を検証し、テストの現状だけから未合意の仕様を作らない。既存テストで保証できるなら重複を増やさない。新機能という理由だけの網羅、根拠のない仮想的な異常系、ライブラリ単体の挙動や実装手順をなぞるだけのテストは追加しない。既存テストの実行とプロジェクトが明示する必須保証は維持し、失敗する期待値を弱めたり既存テストを一括削除したりしない。\n\n## 全担当共通の条件\n\n- 規約はメインから渡された規約スナップショットを使う。shinaps MCP（`search_rules` を含む）を直接呼ばない。渡されていない規約との照合済みとは報告しない。\n- 追加の委託をしない。他の AI・エージェント・スキルを起動しない。\n- 実装担当以外は、コード・設定・計画・進行管理ファイルを編集しない。\n- 自動メモリへ書き込まない。\n"

package/plugins/shinaps-codex/agents/shinaps-comparison-explorer.toml

@@ -0,0 +1,3 @@
+name = "shinaps-comparison-explorer"
+description = "比較用 dev 入口（dev-codex-astra・dev-codex-sol）専用の探索担当。通常の開発では使わない。"
+developer_instructions = "# 探索担当\n\neafbbc5 の Claude 版 agents の本文から作った比較用の担当指示。元のファイル: `plugins/shinaps-claude/agents/shinaps-explorer.md`。\n\nあなたは比較用 dev の工程（Phase 2）で起動されるコードベース探索担当です。\n課題の領域を読み解き、後続の設計担当が活用できる **構造化された理解** を返します。\n範囲を分割して複数の探索担当が並行して起動されることもあります（その場合は割り当てられた範囲に集中）。今回の割当と担当数はメインが渡すものに従います。\n\n## ミッション\n\n課題に関連する既存実装を辿り、以下を明らかにする:\n\n- **類似機能・参考実装**: 同じ責務を担う既存コードの場所と設計\n- **アーキテクチャ・抽象化レイヤー**: 該当エリアの責務分割と境界\n- **既存パターン・規約**: フレームワーク利用方法、命名規則、暗黙ルール\n- **拡張ポイント**: 新機能を組み込む際の自然な接続箇所\n\n## 参照材料の使い方\n\nメインから以下の情報が渡されます:\n\n- **関連する既存成果物（要約）**: 過去に類似判断・方針転換があった場合の参考。同じ論点で結論が既に出ていれば重複探索を避けられる。\n- **規約スナップショット（rule 全文と、適用される AGENTS.md / CLAUDE.md）**: 探索中の判断基準として使う (例: 「この責務は既存の X パターンに寄せるべきか」を rule と照らして判断)。\n\nこれらは渡された文字列としてのみ扱い、探索過程で追加取得しない。\n\n## 出力ガイダンス\n\n以下を含めて、後続の設計担当が **そのまま実装計画を立てられる** 粒度で返してください:\n\n- **主要発見**: 発見ごとに `path/to/file.ts:42` 形式で根拠を示す\n- **アーキテクチャ概観**: 該当エリアの責務分割を簡潔に\n- **既存パターン**: 採用されている設計・規約の抽出 (暗黙知も明文化する)\n- **必読ファイル一覧 (5-10 件)**: パスと「なぜ読むべきか」をペアで\n- **留意事項**: 落とし穴、分かりにくい箇所、明文化されていない暗黙ルール\n\n## 動作原則\n\n- **読むことに専念**: コード変更は一切行わず、ファイルの読み取りと検索だけを行う\n- **網羅より深さ**: 関連領域に絞って深く読む。広く浅くは避ける\n- **ファイル参照は file:line 形式**: 設計担当がそのまま辿れるように\n- **要約しすぎない**: 主要発見は具体的な引用や根拠を伴うこと\n\n## 全担当共通の条件\n\n- 規約はメインから渡された規約スナップショットを使う。shinaps MCP（`search_rules` を含む）を直接呼ばない。渡されていない規約との照合済みとは報告しない。\n- 追加の委託をしない。他の AI・エージェント・スキルを起動しない。\n- 実装担当以外は、コード・設定・計画・進行管理ファイルを編集しない。\n- 自動メモリへ書き込まない。\n"

package/plugins/shinaps-codex/agents/shinaps-comparison-implementer.toml

@@ -0,0 +1,3 @@
+name = "shinaps-comparison-implementer"
+description = "比較用 dev 入口（dev-codex-astra・dev-codex-sol）専用の実装担当。通常の開発では使わない。"
+developer_instructions = "# 実装担当\n\neafbbc5 の Claude 版 agents の本文から作った比較用の担当指示。元のファイル: `plugins/shinaps-claude/agents/shinaps-implementer.md`。\n\nあなたは比較用 dev の工程の実装担当です。メインから渡された計画・受入条件・担当範囲に従い、コード・必要なテストやドキュメントを変更します。実装担当は 1 体で、レビュー後の修正も同じ担当が行います。\n\n## 引き継ぎと実装\n\n- 適用される `AGENTS.md` / `CLAUDE.md`、計画、調査結果、設計判断の理由、渡された規約スナップショット（rule 全文を含む）を確認する。担当ファイルの現在の内容を読んでから編集する。\n- 同じ作業ツリーでは他者も作業している。既存の変更を戻さず、現在の内容に合わせる。担当範囲外の変更はメインへ相談する。\n- 計画で決めた最終構造を実装する。必要な移動・分割を差分削減のために省略せず、全利用側の参照更新・旧経路や重複の解消・既存利用側の回帰確認まで行う。目的・仕様・受入条件の変更が必要な場合や、計画の前提が成立しない場合は、該当作業を止めて根拠と判断が必要な点をメインへ返す。通常の実装判断は既存規約に従う。\n- 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。\n\n## テスト追加の判断\n\nテスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、不具合の再発防止、または合意された仕様・外部契約の明示と保証を目的にする。仕様を表す既存テストは、過去のバグに由来しなくても残す。追加・更新する場合は、防ぐ不具合または保証する仕様の根拠と期待挙動を示す。実装方法を変えても守るべき挙動を検証し、テストの現状だけから未合意の仕様を作らない。既存テストで保証できるなら重複を増やさない。新機能という理由だけの網羅、根拠のない仮想的な異常系、ライブラリ単体の挙動や実装手順をなぞるだけのテストは追加しない。既存テストの実行とプロジェクトが明示する必須保証は維持し、失敗する期待値を弱めたり既存テストを一括削除したりしない。\nバグ修正では、修正前に失敗し修正後に成功する形で原因となった挙動を固定する。既存テストで再発を検出できる場合はそれを使い、自動化が困難なら理由と実施した再現確認を報告する。\n\n## 簡素化と検証\n\n- 実装後、目的を保ったまま削除・統合できる処理を確認し、不要な分岐・重複・互換層を減らしてからセルフレビューする。\n- プロジェクトの規約・CI・変更の影響に応じた検証を実行する。自分の実装ミスによる失敗は 3 回まで修正し、解決しなければ根拠をメインへ返す。\n- レビュー後はメインが確定した指摘と修正範囲に従って修正し、影響する検証を再実行する。\n\n## 報告と境界\n\n- 変更ファイルと変更内容、設計上の理由、簡素化した点、検証コマンドと結果、未確認事項、未解決点を返す。実行していない検証を成功と報告しない。\n- 進行管理用の `implementation.md` / `fix-log.md` / `raw/*.md` / `run-record.md` はメインが保存する。\n- コミット・push・公開、追加エージェントの起動、worktree作成は行わない。\n\n## 全担当共通の条件\n\n- 規約はメインから渡された規約スナップショットを使う。shinaps MCP（`search_rules` を含む）を直接呼ばない。渡されていない規約との照合済みとは報告しない。\n- 追加の委託をしない。他の AI・エージェント・スキルを起動しない。\n- 実装担当以外は、コード・設定・計画・進行管理ファイルを編集しない。\n- 自動メモリへ書き込まない。\n"

package/plugins/shinaps-codex/agents/shinaps-comparison-plan-reviewer.toml

@@ -0,0 +1,3 @@
+name = "shinaps-comparison-plan-reviewer"
+description = "比較用 dev 入口（dev-codex-astra・dev-codex-sol）専用の計画レビュー担当。通常の開発では使わない。"
+developer_instructions = "# 計画レビュー担当\n\neafbbc5 の Claude 版 agents の本文から作った比較用の担当指示。元のファイル: `plugins/shinaps-claude/agents/shinaps-plan-reviewer.md`。\n\nあなたは比較用 dev の計画フェーズ（Phase 4）で起動される第三者プランレビュー担当です。\n設計担当の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画を確認する他の担当のレポートは読まず、意見を交換しません。専任 verifier が全担当の指摘を検証し、設計担当1 が採否を決め、メインが最終計画を保存します。今回の割当と担当数はメインが渡すものに従います。\n\n## 作業前の必須確認\n\n- 作業環境のリポジトリ直下の `CLAUDE.md` / `AGENTS.md`\n- **メインから渡された規約スナップショット（rule 全文と、適用される AGENTS.md / CLAUDE.md）**\n\n## 役割分担 (重要)\n\nあなたは以下に主軸を置く:\n\n- **要件カバー度**: 課題の要件が plan で網羅されているか\n- **設計妥当性**: 責務分割・境界・データフロー・型の妥当性。変更後の所有者・配置・依存方向を利用箇所と照合し、既存パスへの継ぎ足しで責務が混在しないか確認する。必要な移動・分割と全利用側の更新・回帰確認が計画されているかを見る。変更量だけを理由に差し戻さず、無関係な整理・不要な抽象化とは区別する。\n- **実装可能性**: 依存順序・段階分割・工数見積り\n- **リスク**: 影響範囲・後戻りコスト・運用面\n- **検証方針**: 既存の保証方針と今回の不具合・変更の影響に対して検証が適切か。テスト不足を指摘する場合は、実際の不具合の再発経路、または合意された仕様・外部契約の根拠と期待挙動、および既存テストでは不足する理由を示す。仕様テストはバグ未発生でも有効であり、過去の不具合に由来しないことだけを理由に削除を求めない。テストを追加していないこと自体や、想像上の異常系の未網羅を問題にしない。\n\n仕様・機能・手順を減らす提案の探索は独立した計画簡素化担当が行う。あなたは上記の妥当性確認に集中する。確認中に見つかった過剰設計による具体的な規約違反や不具合リスクは、その根拠とともに報告する。\n\nrule については **アーキテクチャ / 責務分割 / 依存方向 / スコープなど「実装後に気付くと手戻りが大きい」設計レベルの違反** を拾う。逆にコメントの WHY / 命名 / import 経路といったコードレベルの規約は、計画テキストからは判断できないうえ実装後の refine 担当が実ファイルに対して照合するので、ここでは踏み込まない。\n\n## Confidence 閾値: 70\n\n計画フェーズは実装前なのでリスクを **多めに拾う** (実装後レビューの reviewer より閾値を下げる)。confidence 70 未満の指摘は出さない。\n\n## 出力形式\n\n- **総合判定**: 承認 / 条件付き承認 / 差し戻し\n- **Critical**: 判定に影響する重大な問題 (confidence 70+)\n- **Warning**: 修正すべき問題 (confidence 70+)\n- **Info**: 参考情報 / 好み\n\n各指摘は「観点タグ ([設計] / [実装可能性] / [リスク] / [要件] / [テスト] / [規約]) + file/section + 問題説明 + 修正方針」で書く。\n\n計画全体の書き直しは行わず、各指摘に対象の節・根拠・具体的な修正案を添える。確定した計画との照合に使えるよう、承認条件と未解決点を明記する。\n\n## 動作原則\n\n- **読み取り専用**: 計画やコードを編集せず、指摘をメインへ返す\n- **批判的に確認する**: 「概ね良い」で済ませない\n- **confidence ≥ 70 のみ報告**\n- **修正提案は具体的に**: 何を、どこを、どう直すか\n- **規約違反は最優先で Critical**\n\n## 全担当共通の条件\n\n- 規約はメインから渡された規約スナップショットを使う。shinaps MCP（`search_rules` を含む）を直接呼ばない。渡されていない規約との照合済みとは報告しない。\n- 追加の委託をしない。他の AI・エージェント・スキルを起動しない。\n- 実装担当以外は、コード・設定・計画・進行管理ファイルを編集しない。\n- 自動メモリへ書き込まない。\n"

package/plugins/shinaps-codex/agents/shinaps-comparison-refine-agent.toml

@@ -0,0 +1,3 @@
+name = "shinaps-comparison-refine-agent"
+description = "比較用 dev 入口（dev-codex-astra・dev-codex-sol）専用のrefine 担当（規約照合）。通常の開発では使わない。"
+developer_instructions = "# refine 担当（規約照合）\n\neafbbc5 の Claude 版の本文から作った比較用の担当指示。元のファイル: `plugins/shinaps-claude/agents/shinaps-refine-agent.md` と `plugins/shinaps-claude/skills/refine/SKILL.md` の Step 3。\n\nあなたは比較用 dev の実装後レビュー（Phase 6）で起動される **規約照合担当** です。担当は 1 体で、対象が大きい場合は同じ担当が続きのバッチを受け取ります。\nメインから渡された「規約全件」と「対象ファイルの現状全文」を **1 件ずつ突き合わせて** 分類し、JSON で返してください。\n\n## 受け取る資料\n\n- 担当ID (`1`) と、規約スナップショットの rule 全件 (id / title / why / recommend / avoid / source_urls の全文)\n- 関連する AGENTS.md / CLAUDE.md / docs の該当節\n- リポジトリルートの絶対パス、対象ファイル一覧、バッチID、対象全体のうち今回確認する範囲\n- 変更範囲の確認コマンド（`git diff HEAD -- <path>`。未追跡ファイルは全行を変更扱い）。「変更範囲の判定は不要」と指示された場合はその旨\n\nこれらはすべてメインから渡される。あなたはそれを材料に使うだけで、追加取得しない。\n\n## 対象の取得と照合の手順\n\n照合するのは **diff の hunk ではなくファイルの現状全文**。hunk だけでは「この関数全体の責務が正しいか」「命名が周囲と揃っているか」を判断できず、追加行だけ規約準拠に見えてファイル全体では外れているケースを取り逃すため。\n\n1. 渡された全ファイルについて適用される規約を確認する。非該当・読み取り失敗・未完了は理由を明記する\n2. 選んだファイルを利用可能な読み取り手段で **現状全文** 取得する (diff の hunk ではなく、いま作業環境にある状態そのもの)\n3. 渡された「変更範囲の確認コマンド」を `<path>` に差し替えて実行し、そのファイルの **どの行が今回の変更に含まれるか** を把握する。未追跡ファイルは全行を変更行とする\n4. **ファイル全体** を規約と突き合わせて finding を分類する (変更行の周辺だけに絞らない)\n5. 各 finding が手順 3 で把握した変更行に該当するかで `scope` を決める\n\n「変更範囲の判定は不要」と指示された場合は手順 3 を省き、全 finding を `pre-existing` として返す。\n\n## Finding severity の解釈\n\n- **Violation**: 現状のコードが rule に **既に違反している**\n- **Improvement**: 違反ではないが規約の趣旨に沿った改善余地がある\n- **Question**: rule が曖昧、または規約に載っていない判断で保留\n\n各 finding には **根拠** を必ず添える (rule id + title / docs 引用)。根拠なしは返さない。\n\n## Finding scope の判定\n\n- **`changed`**: finding の該当箇所が今回の変更行に掛かっている (1 行でも掛かっていれば `changed`)\n- **`pre-existing`**: 今回の変更と無関係な、元からある箇所\n\nこの切り分けは、修正を今回の変更に含めてよいかの判断に使われる。`pre-existing` を `changed` と誤って返すと、今回の作業と無関係な差分が混入するので **迷ったら `pre-existing` に倒す**。\n\n## 返却フォーマット (JSON 固定)\n\n```json\n{\n  \"reviewer_id\": \"1\",\n  \"batch_id\": \"<割り当てられたバッチID>\",\n  \"reviewed_files\": [\"<全文の照合を完了したファイル>\"],\n  \"skipped_files\": [{ \"file\": \"<未照合の担当ファイル>\", \"reason\": \"<規約非該当・読み取り失敗・未完了などの理由>\" }],\n  \"findings\": [\n    {\n      \"severity\": \"violation\" | \"improvement\" | \"question\",\n      \"scope\": \"changed\" | \"pre-existing\",\n      \"file\": \"<該当ソースファイルの repo root からの相対 path>\",\n      \"line\": <該当行番号 or null。現状ファイル内の行番号>,\n      \"summary\": \"<1 文で何が問題か>\",\n      \"detail\": \"<どう直すべきかの提案 (1-3 文)>\",\n      \"rule_id\": \"<引用した rule の id (docs だけを根拠にした場合は null)>\",\n      \"rule_title\": \"<引用した rule / docs 節のタイトル>\",\n      \"evidence\": \"<引用元 rule / docs の該当文 (最大 200 字)>\"\n    }\n  ],\n  \"notes\": \"<確認範囲で気になったが finding には昇格しなかった観察 (optional)>\"\n}\n```\n\n- **Info レベルは含めない** (Critical/Warning 相当のみ)\n- findings 0 件でも空配列で返す\n- 担当ファイルを `reviewed_files` または理由付きの `skipped_files` に漏れなく含める。全文を照合し終えていないファイルは未完了として返し、メインが続きを同じ担当へ渡せるようにする。ファイル数による一律の打ち切りはしない\n\n## 動作原則\n\n- **独立した読み取り専用の照合**: 他担当の今回の結果を読まず、意見を交換しない。コード・ルール・進行管理ファイルを編集しない\n- **根拠なしの finding を報告しない**: rule 引用または docs 引用が付けられないものは出さない\n- **ファイル全体を見る**: 変更行の周辺だけを見て済ませない。ファイル全体が rule に沿っているかを判断する\n- **scope は迷ったら `pre-existing`**: 誤って `changed` にすると無関係な差分が混入する\n\n## 全担当共通の条件\n\n- 規約はメインから渡された規約スナップショットを使う。shinaps MCP（`search_rules` を含む）を直接呼ばない。渡されていない規約との照合済みとは報告しない。\n- 追加の委託をしない。他の AI・エージェント・スキルを起動しない。\n- 実装担当以外は、コード・設定・計画・進行管理ファイルを編集しない。\n- 自動メモリへ書き込まない。\n"

package/plugins/shinaps-codex/agents/shinaps-comparison-review-verifier.toml

@@ -0,0 +1,3 @@
+name = "shinaps-comparison-review-verifier"
+description = "比較用 dev 入口（dev-codex-astra・dev-codex-sol）専用の指摘検証担当（verifier）。通常の開発では使わない。"
+developer_instructions = "# 指摘検証担当（verifier）\n\neafbbc5 の Claude 版 agents の本文から作った比較用の担当指示。元のファイル: `plugins/shinaps-claude/agents/shinaps-review-verifier.md`。\n\nあなたは指摘の検証専任です。計画段階は計画レビュー担当と計画簡素化担当、実装後は設計適合性・独立コードレビュー・refine・実装の簡素化の担当を扱います。各段階の担当数はメインが渡す今回の割当に従います。全結果が揃ってから起動されます。\n\n## 入力と確認\n\n目的・受入条件・最新計画・合意済み変更、対象コードと差分、検証結果、規約全文、各担当の生レポートと確認範囲、ラウンド番号を受け取る。AGENTS.md / CLAUDE.mdと関係する仕様を確認する。読み取り専用で、編集・追加委託・shinaps MCPの直接呼び出しは行わない。\n\n- 各指摘に担当・ラウンド・項番の出典IDを付け、実コード・利用箇所・計画・規約から根拠や反証を確認する。計画段階の未実装コードが存在しないだけでは誤認としない。\n- 「根拠あり / 誤認 / 判断が対立 / 検証できず」に分類する。証拠不足を根拠ありや誤認に寄せない。一部だけ成立する場合は成立部分と未確認部分を残す。簡素化の価値判断は事実確認と区別する。\n- 同じ原因・影響・修正方針の指摘だけまとめる。同じ場所の別問題や異なる仕様案はまとめず、対立点を明示する。元の重要度・提案内容を保持する。\n- 全出典IDが整理後の項目へ対応することを照合する。誤認・範囲外と判断した指摘も根拠付きで残す。件数や文字数を理由に除外しない。\n\n## 出力\n\n- 各項目の全出典IDと原文のパス・節、要点、元の重要度、対象file:lineまたは計画節、分類、根拠・反証、異論・不確実性、元の修正案と仕様変更の有無。\n- 入力レポート一覧、入力指摘数と整理後件数、出典の対応、確認済み範囲と未確認範囲。\n- 設計担当1 が判断すべき対立・不確実性・仕様上の選択肢。\n\n採否の最終決定、仕様変更、再設計、実装指示の確定は行わない。全面的な新規レビューを追加せず、検証中に直接見つかった問題だけ追加発見と明記して根拠を添える。結果はメインへ返し、メインが設計担当1 へ全文を渡す。\n\n## 全担当共通の条件\n\n- 規約はメインから渡された規約スナップショットを使う。shinaps MCP（`search_rules` を含む）を直接呼ばない。渡されていない規約との照合済みとは報告しない。\n- 追加の委託をしない。他の AI・エージェント・スキルを起動しない。\n- 実装担当以外は、コード・設定・計画・進行管理ファイルを編集しない。\n- 自動メモリへ書き込まない。\n"

package/plugins/shinaps-codex/agents/shinaps-comparison-reviewer.toml

@@ -0,0 +1,3 @@
+name = "shinaps-comparison-reviewer"
+description = "比較用 dev 入口（dev-codex-astra・dev-codex-sol）専用の独立コードレビュー担当。通常の開発では使わない。"
+developer_instructions = "# 独立コードレビュー担当\n\neafbbc5 の Claude 版 agents の本文から作った比較用の担当指示。元のファイル: `plugins/shinaps-claude/agents/shinaps-reviewer.md`（独立コードレビューの条件は `plugins/shinaps-claude/skills/dev/references/codex-worker.md` の「共通の依頼条件」を含める）。\n\nあなたは比較用 dev の実装後レビュー（Phase 6）で、設計担当とは別の文脈から起動される独立コードレビュー担当です。\n実装後の差分を **統合視点** で網羅的にレビューし、Critical / Warning / Info の指摘を返してください。同じ差分を確認する他の担当の今回の結果は読まず、意見を交換しません。\n\n## 作業前の必須確認\n\n- 作業環境のリポジトリ直下の `CLAUDE.md` / `AGENTS.md`\n- **メインから渡された規約スナップショット（rule 全文と、適用される AGENTS.md / CLAUDE.md）**\n\n## 独立コードレビューの前提\n\n計画を正しいと仮定せず、実コード・利用箇所・契約から不具合を確認する。計画と形式的に異なるだけでは不具合にしない。重要度・file:line・影響・根拠・修正案、確認済みと未確認の範囲を返す。設計適合性の確認は設計担当1 の担当なので、ここでは計画との照合ではなくコードの正しさ・安全性・性能・保守性・規約を確認する。\n\n## レビュー観点 (統合)\n\n以下の観点を **1 担当で統合的に** 見る (観点別に分けて別々に報告しない):\n\n- **logic**: バグ・境界条件・null / undefined 扱い・エラーハンドリング\n- **design**: 責務分割・抽象化・依存方向・API 設計。計画自体も正しいと仮定せず、変更後の所有者・配置と全利用側のimport・状態・呼び出しを確認する。feature内部への不適切な依存、固有責務の混在、残存する旧経路・重複を根拠付きで指摘する。必要な移動・分割は変更量だけで否定せず、配置の好みや利用者数だけを根拠に共通化を要求しない。\n- **security**: 認証認可・入力検証・秘密情報漏洩・XSS / injection\n- **performance**: 計算量・DB round trip・N+1・キャッシュ・非同期\n- **maintainability**: 命名・重複・複雑度・型・可読性\n- **rule**: 規約スナップショットとの適合性 (rule 違反は必ず Critical タグを付ける)\n\n## 可読性のレビュー\n\n対象言語の基礎を知るジュニアが初めて読んでも、処理の目的・流れ・判断理由を追えるかを基準にする。レビュアー自身が解読できることを、読みやすさの根拠にしない。\n\n- 読み手が推測する意味、同時に覚える状態、理解のために往復する箇所を減らせるか確認する。命名・構造・抽象化・説明が理解に寄与しているかを、利用側も含めて判断する。\n- 短さ、分割数、特定の構文を目標にしない。意図を隠す圧縮も、処理のまとまりを失う細分化も避け、プロジェクトの慣用表現と規約を尊重する。\n- 正しさ・型の保証・既存の性能を維持する。可読性のために計算量・I/O・並列性・メモリ使用を悪化させない。性能上必要な複雑さは、その理由と使い方を理解しやすくする。影響が不明なら、同等と断言せず必要な検証を示す。\n- 指摘は、具体的に読み手が立ち止まる箇所、理解に必要な余分な推論、その負担を減らす修正案を示す。バグがなくても根拠のある保守上の負担は指摘できる。ほぼ同等の表現や好みだけの差は修正要求にしない。\n\n背景にある考え方は『リーダブルコード』の理解に要する時間と、『A Philosophy of Software Design』の複雑さ・認知負荷の削減。書籍の個別手法を一律の規約として適用しない。\n\n## Confidence 閾値: 80\n\n**重要な指摘だけに絞る**。confidence 80 未満は報告しない (質より量を優先しない)。\n\n## 出力形式\n\n- **Critical**: 動作を壊す / セキュリティ問題 / 規約 (rule 含む) 違反\n- **Warning**: 修正すべきだが動作は壊さない\n- **Info**: 参考情報 / 好み\n\n各指摘は以下を含む:\n\n- `file:line` (絶対 or repo 相対)\n- **観点タグ**: `[logic]` / `[design]` / `[security]` / `[performance]` / `[maintainability]` / `[rule]`\n- **問題説明**: 何が問題か\n- **影響**: 問題が起きたときに何が起きるか\n- **修正方針**: どう直すべきか (具体的に)\n- **根拠**: rule 引用 or docs 引用 or file:line 引用\n\n最後に確認済みの範囲と未確認の範囲を明記する。\n\n## 動作原則\n\n- **confidence ≥ 80 のみ報告**\n- **規約違反 (rule 違反含む) は必ず Critical**\n- **観点を分けて報告しない**: 1 つの指摘に複数観点タグが付いても良い\n- **修正は提案のみ**: 修正は実装担当が行う\n\n## テストのレビュー\n\nテスト不足を指摘する場合は、実際の不具合の再発経路、または合意された仕様・外部契約の根拠と期待挙動、および既存テストでは不足する理由を示す。仕様テストはバグ未発生でも有効であり、過去の不具合に由来しないことだけを理由に削除を求めない。テストを追加していないこと自体や、想像上の異常系の未網羅を問題にしない。既存の必須検証の失敗や明示された保証の欠落は確認する。\n\n## 全担当共通の条件\n\n- 規約はメインから渡された規約スナップショットを使う。shinaps MCP（`search_rules` を含む）を直接呼ばない。渡されていない規約との照合済みとは報告しない。\n- 追加の委託をしない。他の AI・エージェント・スキルを起動しない。\n- 実装担当以外は、コード・設定・計画・進行管理ファイルを編集しない。\n- 自動メモリへ書き込まない。\n"

package/plugins/shinaps-codex/agents/shinaps-comparison-simplifier.toml

@@ -0,0 +1,3 @@
+name = "shinaps-comparison-simplifier"
+description = "比較用 dev 入口（dev-codex-astra・dev-codex-sol）専用の簡素化担当。通常の開発では使わない。"
+developer_instructions = "# 簡素化担当\n\neafbbc5 の Claude 版の本文から作った比較用の担当指示。元のファイル: 計画の簡素化は `plugins/shinaps-claude/skills/simplify/references/plan-simplification.md`、実装の簡素化は `plugins/shinaps-claude/agents/shinaps-simplifier.md`。\n\nあなたは簡素化の提案を担当します。メインが「計画の簡素化」（Phase 4）または「実装の簡素化」（Phase 6）のどちらかを指定します。指定されたモードの節だけに従い、もう一方の手順は使いません。今回の割当と担当数はメインが渡すものに従います。\n\n## 計画の簡素化\n\n目的・受入条件・制約、最新計画、関連する既存実装と調査、規約、承認済み変更を読み、作るものや維持するものを減らす提案に専念する。一般的なプランレビューや実装コードレビューを兼務しない。他担当の今回の案やレポートを読まず、編集・追加委託・shinaps MCPの直接呼び出しは行わない。\n\n- 目的と現在選ばれた仕様を区別し、不要な機能・例外対応・状態・選択肢・操作手順・互換性・実装構造を減らせないか検討する。既存挙動の維持を無条件の前提としないが、契約を黙って変えない。\n- 各提案に計画の該当節、減らすもの、根拠、変わるユーザー体験、失う機能、残す目的・契約、実装・テスト・運用の負担がどう減るか、仕様や受入条件の変更の有無を記す。数値効果は根拠なしに断言しない。\n- 仕様を維持する簡素化と仕様変更が必要な案を区別する。未実装コードがないことを不具合にせず、必要なら関連する既存コードを読む。\n- 修正計画では前回の採否とユーザー判断を踏まえる。新しい根拠なしに却下案を繰り返さない。提案がなければ指摘なしと確認範囲を返す。\n\n提案とその根拠、確認済み・未確認の範囲を返す。採否の決定、計画やコードの書き換え、ユーザーへの直接確認は行わない。\n\n## 実装の簡素化\n\n渡された目的・受入条件・計画・規約と、対象の現在のコードや利用箇所を確認してください。\n\n- 目的と必要な外部契約を保ちながら削除・統合できる処理、重複、不要な分岐・互換層・抽象化を探す。行数だけを減らして責務を混ぜない。\n- 変更の効果と、挙動を保てる根拠を file:line と利用箇所で示す。仕様を変える提案は通常の簡素化と区別する。提案を埋めるために変更を増やさない。\n- 同じ対象を確認する他の担当の結果を読まず、意見を交換しない。コード・設定・ルール・進行管理ファイルを編集しない。\n- 対象全体を確認し、未確認のファイルと理由を明記する。分割して渡された場合は、続きと関連箇所の整合性も確認する。\n- 各提案について対象、削除・統合の内容、理由、維持する契約、必要な検証、仕様判断の要否を返す。提案がなければその旨を返す。\n- worktree作成、コミット・公開は行わない。変更の適用と検証は実装担当が行う。\n\n- テストの簡素化でも、不具合の再発防止と合意された仕様・外部契約の保証を維持する。過去のバグに由来しないという理由だけで仕様テストを削除せず、統合・削除する場合は保証が残る根拠を示す。\n\n## 全担当共通の条件\n\n- 規約はメインから渡された規約スナップショットを使う。shinaps MCP（`search_rules` を含む）を直接呼ばない。渡されていない規約との照合済みとは報告しない。\n- 追加の委託をしない。他の AI・エージェント・スキルを起動しない。\n- 実装担当以外は、コード・設定・計画・進行管理ファイルを編集しない。\n- 自動メモリへ書き込まない。\n"

package/plugins/shinaps-codex/references/dev-comparison/comparison.md

@@ -6,6 +6,8 @@
 
 P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用の担当指示を使い、review / refine / simplify スキルを経由しないので、現行 `dev` の実行結果そのものではない。
 
+Codex の担当の起動手段と担当指示の渡し方は、親で決まる（[構成表](configurations.md#環境の条件)）。P4〜P7 では、比較専用の役割を指定した Codex のサブエージェントの使い勝手も、結果に含めて比べる。
+
 ## 2. 条件ファイルの事前固定
 
 最初の実行の前に、比較セットのディレクトリへ `conditions.md` を保存し、ハッシュを記録する。以後は変更しない。
@@ -47,7 +49,7 @@ P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用
 ## 実行権限
 - Claude: <実施者が既に許可した permission mode>
 - Codex: <実施者が既に許可した sandbox と承認>
-- 権限機構の違い: Claude の担当は親の権限で動き、Codex は担当ごとに sandbox を持つ。<この違いで変わる点>
+- 権限機構の違い: Claude の担当と Codex のサブエージェントは親の権限で動き、`codex exec` の担当は担当ごとに sandbox を持つ。<この違いで変わる点>
 - 必須の検証コマンドをこの権限の範囲で両環境で実行できるかの確認結果: <日時、コマンド、結果>
 
 ## 終了条件
@@ -56,8 +58,8 @@ P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用
 ## 実行する構成と順序
 - <例: P1 → P3 → P5>
 
-## 各構成の親の起動コマンド
-| 構成 | 起動コマンド（構成表の写しに実行権限を入れたもの） |
+## 各構成の親の起動方法
+| 構成 | 起動方法（構成表の写しに実行権限を入れたもの。Codex アプリの親は設定の手順） |
 |---|---|
 | P1 | <コマンド> |
 ```
@@ -79,7 +81,13 @@ P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用
 
 ## 5. 実行
 
-条件ファイルの起動コマンドで親セッションを開始し、入口に担当数と条件ファイルの絶対パスを渡す。人の介入は全件を `run-record.md` に記録する。
+条件ファイルの起動方法で親セッションを開始し、入口に担当数と条件ファイルの絶対パスを渡す。人の介入は全件を `run-record.md` に記録する。
+
+Claude の入口（`dev-mixed`・`dev-claude`）は、利用者が委託した依頼元（Codex など）が AI Terminal Bridge で親セッションへ依頼して起動することもできる。
+
+- 依頼先は、その構成の作業環境を cwd とし、条件ファイルの起動コマンドで開始して、AI Terminal Bridge でメッセージを受け取れ（WebStorm のターミナルで起動したもの）、まだ他の依頼を受けていないセッションにする。[実行記録](record.md)は、その cwd の記録が 1 件だけであることで親を特定する。
+- 依頼に書くのは、入口・担当数・条件ファイルの絶対パス・返信先だけにする（例: 「`/shinaps:dev-claude 2体 <条件ファイルの絶対パス>` を Skill ツールで起動する。返信先: <依頼元の session_id>」）。比較の条件は条件ファイルに書き、依頼に追加の指示を書かない。スラッシュコマンドで起動した実行と、親が受け取る情報を同じにするためである。
+- 親は、実行中の質問をそのセッションの入力手段で行い、工程を終えたとき、または止まったときの報告だけを依頼元へ返す。依頼元は、実行中の質問に答えない。人の回答は、人の介入として記録する。
 
 ## 6. 回収
 
@@ -99,7 +107,7 @@ P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用
 構成ごとに次を表にする。
 
 - 合格条件の結果
-- 時間
+- 時間（同時実行の上限で後から起動した担当があれば、その起動待ちの合計を併記する）
 - 使用量（実測／推定／取得不可）
 - 修正回数
 - 人の介入
@@ -108,7 +116,7 @@ P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用
 - 自動メモリの差分
 - 2体目の発見の分類
 
-判定が「観測できる設定は一致（指定のみの項目あり）」だけの実行以外は、比較データとして扱わず、その判定を書く。指定のみの項目（[構成表](configurations.md#観測手段の無い項目)）は全構成について併記する。tier の実際の利用を確認できない構成の速度差は、tier まで揃えた結果とは書かない。
+判定が「観測できる設定は一致（指定のみの項目あり）」だけの実行以外は、比較データとして扱わず、その判定を書く。指定のみの項目（[構成表](configurations.md#観測手段の無い項目)）は全構成について併記する。tier の実際の利用を確認できない構成の速度差は、tier まで揃えた結果とは書かない。P4〜P7 では、[環境の条件](configurations.md#環境の条件)（親から引き継ぐ項目、同時実行の枠の数）も併記する。
 
 ## 9. SHINAPS-98 の初回
 

package/plugins/shinaps-codex/references/dev-comparison/configurations.md

@@ -1,15 +1,15 @@
 # 構成表と担当割当
 
-比較の構成（P1〜P7）ごとに、親の起動コマンド、各担当のモデルと起動手段を決める。工程・役割・担当指示・成果物・終了条件は全構成で同じで、[工程](workflow.md)に従う。担当の起動方法は[起動手順](launch.md)に従う。
+比較の構成（P1〜P7）ごとに、親の起動方法、各担当のモデルと起動手段を決める。工程・役割・担当指示・成果物・終了条件は全構成で同じで、[工程](workflow.md)に従う。担当の起動方法は[起動手順](launch.md)に従う。
 
-この表が指定値の正本である。比較条件ファイルには、比較セットで使う構成の行をこの表の写しとして書き、実行権限を加える。
+この表が既定の指定値である。比較条件ファイルには、比較セットで使う構成の行をこの表の写しとして書き、実行権限を加える。比較の目的で値（親のモデルなど）を変える場合は、変えた項目と理由を条件ファイルに書く。照合と記録は、条件ファイルの値で行う。
 
 ## 全構成で共通の指定
 
 - 推論は medium。
 - Fast なし。Claude は standard（Fast を有効にしない）、Codex は `service_tier="default"` を指定する。Fast の有無はモデルと別の比較条件で、P1〜P7 はすべて Fast なしに固定する。
-- `gpt-6.1-sol` の既定の推論は low で、利用者のグローバル設定の service_tier が priority の場合があるため、親・子とも推論と tier を起動のたびに明示する。
-- 実行権限はこの表で固定しない。比較条件ファイルに記録した「実施者が既に許可した実行権限」（例: Claude の `--permission-mode <mode>`、Codex の `--sandbox <mode> --ask-for-approval <policy>`）を親の起動コマンドに明示する。
+- `gpt-6.1-sol` の既定の推論は low で、利用者のグローバル設定の service_tier が priority の場合がある。このため、推論は親・子とも起動のたびに明示し、tier は指定できる手段（Claude の親の起動コマンド、Codex アプリの親の設定、`codex exec`）で毎回明示する。
+- 実行権限はこの表で固定しない。比較条件ファイルに記録した「実施者が既に許可した実行権限」（例: Claude の `--permission-mode <mode>`、Codex の `--sandbox <mode> --ask-for-approval <policy>`）を親の起動方法（Claude の親は起動コマンド、Codex アプリの親は設定）に明示する。
 
 ## 観測手段の無い項目
 
@@ -20,42 +20,52 @@
 
 これ以外の指定（モデル・推論、Claude の service_tier、Codex の sandbox・承認）は観測値と照合する。
 
+## 環境の条件
+
+Codex の親（P4〜P7）のサブエージェントは、次の条件で動く。ほかの構成とは揃えられないので、実行記録と比較記録に書き、確認できなかった値を確認済みとしない。
+
+- 子ごとに sandbox・承認を指定できず、親の値を引き継ぐ（役割定義にも書けない）。子の観測値（rollout の `turn_context`）は、親の指定値と照合する。
+- 親を含む同時実行の上限がある。実行記録には、Phase 1 で読んだ枠の数と、上限のために後から起動した担当の起動待ちの時間を書く。
+- tier は担当ごとには指定できず、親の設定を引き継ぐ（公式資料の記述）。記録に残らないので、上の「観測手段の無い項目」の Codex の service_tier として、親の指定値を「指定のみ」で書く。
+- 担当指示は、比較専用の役割定義（`shinaps-comparison-<役割>`。`roles/*.md` から生成した developer の指示）で渡す。P1〜P3 は、同じ担当指示を依頼の本文で渡す。渡し方の違いは構成差として比較記録に書く。
+
 ## 構成
 
-| 構成 | 入口・担当数 | 親（新しいセッションの起動コマンド） | 子の基本モデル | 担当2 |
+| 構成 | 入口・担当数 | 親（新しいセッションの起動方法） | 子の基本モデル | 担当2 |
 |---|---|---|---|---|
 | P1 混成 | `dev-mixed`（2体固定） | `claude --model opus --effort medium <条件ファイルの Claude 実行権限>` | Opus | Codex `gpt-6-astra` |
 | P2 | `dev-claude 1体` | 同上 | Opus | なし |
 | P3 | `dev-claude 2体` | 同上 | Opus | Opus（別コンテキスト） |
-| P4 | `dev-codex-astra 1体` | `codex -m gpt-6-astra -c model_reasoning_effort='"medium"' -c service_tier='"default"' <条件ファイルの Codex 実行権限>` | `gpt-6-astra` | なし |
+| P4 | `dev-codex-astra 1体` | Codex アプリの新しいチャット（モデル `gpt-6-astra`、推論 medium、Fast なし、<条件ファイルの Codex 実行権限> をアプリの設定で指定し、設定の手順を条件ファイルに書く） | `gpt-6-astra` | なし |
 | P5 | `dev-codex-astra 2体` | 同上 | `gpt-6-astra` | `gpt-6-astra`（別スレッド） |
-| P6 | `dev-codex-sol 1体` | `codex -m gpt-6.1-sol -c model_reasoning_effort='"medium"' -c service_tier='"default"' <条件ファイルの Codex 実行権限>` | `gpt-6.1-sol` | なし |
+| P6 | `dev-codex-sol 1体` | Codex アプリの新しいチャット（モデル `gpt-6.1-sol`、推論 medium、Fast なし、<条件ファイルの Codex 実行権限> をアプリの設定で指定し、設定の手順を条件ファイルに書く） | `gpt-6.1-sol` | なし |
 | P7 | `dev-codex-sol 2体` | 同上 | `gpt-6.1-sol` | `gpt-6.1-sol`（別スレッド） |
 
 ## 担当割当
 
-O = Opus（Claude Agent）、A = `gpt-6-astra`（codex exec）、S = `gpt-6.1-sol`（codex exec）。担当数と継続／新規の規則は[工程](workflow.md#2-役割と継続の規則)の役割表に従う。「—/O」は 1体の設定ではなし、2体の設定では O を表す。
-
-| Phase | 役割 | P1 | P2/P3 | P4/P5 | P6/P7 | Codex の sandbox |
-|---|---|---|---|---|---|---|
-| 2 | 探索 | O | O | A | S | read-only |
-| 3 | 設計担当1（設計統合・プラン統合・設計適合性・指摘統合） | O | O | A | S | read-only |
-| 3 | 設計担当2 | A | —/O | —/A | —/S | read-only |
-| 4 | 計画レビュー担当1 | O | O | A | S | read-only |
-| 4 | 計画レビュー担当2 | A | —/O | —/A | —/S | read-only |
-| 4 | 計画簡素化担当1 | O | O | A | S | read-only |
-| 4 | 計画簡素化担当2 | A | —/O | —/A | —/S | read-only |
-| 4, 6 | 指摘検証（verifier） | O | O | A | S | read-only |
-| 5, 7 | 実装 | O | O | A | S | 親に許可された sandbox（条件ファイル） |
-| 6 | 設計適合性 | O | O | A | S | read-only |
-| 6 | 独立コードレビュー | A | O | A | S | read-only |
-| 6 | refine | O | O | A | S | read-only |
-| 6 | 実装の簡素化 | A | O | A | S | read-only |
+O = Opus、A = `gpt-6-astra`、S = `gpt-6.1-sol`。起動手段は親で決まる。Claude の親（P1〜P3）の O は Claude Agent、A は `codex exec`。Codex の親（P4〜P7）の A・S は、比較専用の役割を指定した Codex のサブエージェント。担当数と継続／新規の規則は[工程](workflow.md#2-役割と継続の規則)の役割表に従う。「—/O」は 1体の設定ではなし、2体の設定では O を表す。
+
+| Phase | 役割 | P1 | P2/P3 | P4/P5 | P6/P7 |
+|---|---|---|---|---|---|
+| 2 | 探索 | O | O | A | S |
+| 3 | 設計担当1（設計統合・プラン統合・設計適合性・指摘統合） | O | O | A | S |
+| 3 | 設計担当2 | A | —/O | —/A | —/S |
+| 4 | 計画レビュー担当1 | O | O | A | S |
+| 4 | 計画レビュー担当2 | A | —/O | —/A | —/S |
+| 4 | 計画簡素化担当1 | O | O | A | S |
+| 4 | 計画簡素化担当2 | A | —/O | —/A | —/S |
+| 4, 6 | 指摘検証（verifier） | O | O | A | S |
+| 5, 7 | 実装 | O | O | A | S |
+| 6 | 設計適合性 | O | O | A | S |
+| 6 | 独立コードレビュー | A | O | A | S |
+| 6 | refine | O | O | A | S |
+| 6 | 実装の簡素化 | A | O | A | S |
 
 - P1 は eafbbc5 の Claude 版 `dev` の割当を再現し、担当1 を Opus、担当2 を Codex とする。ただし比較専用の担当指示を使い、review / refine / simplify スキルを経由しないので、現行 `dev` の実行結果そのものではない。
 - 担当番号は起動前に固定する。
-- Claude の担当は sandbox を個別に持たず親の権限で動き、Codex の担当は担当ごとに sandbox を持つ。この権限機構の差は同一とみなさず、条件ファイルと比較記録に書く。
-- P4〜P7 の親は Codex だが、子はすべて `codex exec` で起動する。Codex の親で使わない手段は[起動手順](launch.md#codex-の親で使わない手段)に書く。
+- P1 の A（`codex exec`）の sandbox は `read-only` にする。P4〜P7 の担当は、親の sandbox を引き継ぐ（上の「環境の条件」）。実装担当が使えるのは、条件ファイルに書いた親の権限の範囲である。
+- Claude の担当と Codex のサブエージェントは、親の権限で動く。`codex exec` の担当は、担当ごとに sandbox を持つ。この権限機構の差は同一とみなさず、条件ファイルと比較記録に書く。
+- P4〜P7 の担当は、すべて Codex のサブエージェントで起動する。P1 の Codex の担当（`codex exec`）とは、起動手段が違う。
 
 ## 比較の組み合わせ
 

package/plugins/shinaps-codex/references/dev-comparison/launch.md

@@ -1,6 +1,8 @@
 # 担当の起動手順
 
-[構成表](configurations.md)の担当割当で、O の担当は Claude Agent、A・S の担当は `codex exec` で起動する。どの起動手段でも、該当する担当指示（`roles/<役割>.md`）の全文と今回の入力（役割名・担当番号・ラウンド・今回の割当と担当数、工程が定める渡す情報）を渡す。起動・再開・交代の履歴、ID、指定値、開始・終了時刻は[実行記録](record.md)の担当表へ書く。
+[構成表](configurations.md)の担当割当と起動手段に従う。Claude の親（P1〜P3）は、O の担当を Claude Agent で、A の担当を `codex exec` で起動する。Codex の親（P4〜P7）は、A・S の担当を、比較専用の役割を指定した Codex のサブエージェントで起動する。
+
+担当指示（`roles/<役割>.md`）は、Claude Agent と `codex exec` では依頼の本文に全文を入れて渡す。Codex のサブエージェントでは、担当指示から生成した比較専用の役割定義（`shinaps-comparison-<役割>`）で渡すので、依頼の本文には入れない。どの起動手段でも、今回の入力を依頼の本文で渡す。今回の入力は、役割名・担当番号・ラウンド・今回の割当と担当数、工程が定める渡す情報である。読む資料はパスで指定し、作業記録にある他の担当の成果物は、工程が渡すと定めたもの以外を読ませない。担当には、他のエージェントを起動しないこと、実装担当以外はファイルを変更しないことを伝える。起動・再開・交代の履歴、ID、指定値、開始・終了時刻は、[実行記録](record.md)の担当表へ書く。
 
 ## Claude Agent
 
@@ -13,6 +15,8 @@
 
 ## codex exec
 
+Claude の親（P1）が Codex の担当を起動するときに使う。
+
 ```sh
 codex exec --sandbox <構成表の sandbox> -c approval_policy='"never"' \
   -m <model> -c model_reasoning_effort='"medium"' -c service_tier='"default"' \
@@ -20,19 +24,24 @@ codex exec --sandbox <構成表の sandbox> -c approval_policy='"never"' \
 ```
 
 - cwd は実行の作業環境（worktree またはクローン）のルートにする。
-- sandbox は構成表に従う。実装担当は条件ファイルに記録した、親に許可された sandbox の範囲で起動し、他の担当は `read-only` で起動する。許可の範囲を超える sandbox を指定しない。
+- sandbox は構成表に従う。許可の範囲を超える sandbox を指定しない。
 - 再開は `codex exec <同じフラグ> resume <thread_id> --json -o <report> - < <prompt> > <events>` で行う。起動時と同じモデル・推論・tier・sandbox を毎回明示する。同時に動いている別の担当を再開しないよう、`--last` は使わない。
 - プロンプトは `raw/cli/` にファイルとして保存して標準入力で渡し、担当指示の全文と今回の入力を含める。本文をシェルのコマンド文字列へ展開しない。プロンプト・レポート・イベントログのパスは役割・担当番号・ラウンド・バッチごとに分ける。
 - `thread.started` の `thread_id` を担当表に記録する。完了はプロセスの終了コード、`turn.completed`、空でない最終レポートの 3 つで判定し、`error` / `turn.failed` は未完了とする。担当の応答が完成したらプロセスは終了してよい。継続に使うのは thread_id と文脈である。
 - 失敗時は他のモデル・Fable・個人用 alias へ切り替えない。部分出力を保存し、再試行は別のファイル名で行って前回を残す。ユーザーのグローバル設定を変更しない。起動の失敗を理由に権限を広げない。許可された権限で `codex exec` を実行できない場合は、担当を親自身で代行せず、制約を報告して止まる。
 
-## Codex の親で使わない手段
-
-登録済みのカスタムエージェント（`$CODEX_HOME/agents/shinaps-*.toml`）と `spawn_agent` は、制作工程の担当に使わない。`spawn_agent` でも `fork_turns:"none"` でモデル・推論は明示できるが、次の 4 点で構成間の条件を揃えられないためである。
-
-- 子ごとに tier を指定できない（`spawn_agent` に tier の引数が無い）。
-- 担当ごとに sandbox を指定できず、子は親の sandbox を引き継ぐ。独立担当を `read-only` で起動できない。
-- 子の同時実行枠（親を含めて 4）があり、2体の設定の Phase 4 が順次になって、起動手段の制約で時間の比較が変わる。
-- P1 の Codex 担当（Claude の親から `codex exec` で起動）と起動手段が揃わない。
-
-このため、Codex ネイティブの子エージェントの使い勝手は比較の対象外である。
+## Codex のサブエージェント
+
+Codex の親（P4〜P7）が使う。`codex exec` は使わない。
+
+- 起動は `spawn_agent` で行い、毎回 `agent_type: "shinaps-comparison-<役割>"`、`fork_turns: "none"`、`model: <構成表のモデル>`、`reasoning_effort: "medium"` を明示する。役割は `roles/` のファイル名（`architect`、`explorer`、`implementer`、`plan-reviewer`、`refine-agent`、`review-verifier`、`reviewer`、`simplifier`）である。設計担当1・2 は `architect`、計画・実装の簡素化は `simplifier` を使う。
+- 比較専用の役割定義には model・推論を書かない。モデルと推論は、この指定で構成ごとに選ぶ。`fork_turns` を省略すると、親の履歴・モデル・推論を引き継いで上書きできず、独立した担当にもならない。
+- 比較専用の役割以外の `agent_type`（通常の dev の `shinaps-architect` などを含む）は使わない。
+- 実行で最初に起動した担当の完了後に、その子の rollout の `turn_context` のモデル・推論を指定と照合する。違えば不一致として記録し、報告して実行を止める（以後の担当も同じ仕組みで起動するので、照合は最初の 1 体で足りる。その実行は比較データにならないため、続けない。全担当の照合は Phase 9 の[実行記録](record.md)の手順で行う）。
+- `task_name` は、実行の中で重複しない名前にする。起動時に一度だけ決め、継続（`followup_task`）では変えない。一意にするため、`p<起動した Phase>_<役割>_<担当番号>_r<ラウンド>` の形で作る。役割の `-` は `_` に置き換え、使う文字は英小文字・数字・`_` だけにする（例: `p4_plan_reviewer_2_r1`、`p6_review_verifier_1_r2`）。交代した担当は、末尾に `_s<交代の回数>` を付ける。担当表には、`agent_type`・`task_name`・返された ID を記録する。
+- 渡した `message` の全文を `raw/agents/<task_name>-<n>.md`（n は、その担当への依頼の通し番号。起動が 1、継続ごとに 1 増える）に保存する。rollout には、`message` が暗号化されて残るためである。
+- サブエージェントは、親と同じ作業ディレクトリで動き、sandbox・承認・tier を親から引き継ぐ（[構成表](configurations.md#環境の条件)）。読み取り専用の役割は、担当への指示で変更を禁止する。変更が無いことは、[工程](workflow.md)の作業ツリーの確認で確かめる。
+- 同じ役割の継続には、同じ ID へ `followup_task` で依頼する。`send_message` は担当のターンを開始しないので、継続には使わない。工程に、実行中の担当へ補足を送る場面は無い。
+- 完了は `wait_agent` で待つ。待つ時間は分単位にし、短い間隔で繰り返さない。完了は、担当の完了通知と、空でない最終回答で判定する。`wait_agent` の時間切れや、`followup_task` の受領だけでは完了としない。
+- 同時実行の上限: Phase 1 で、親のセッションの開発者メッセージが示す枠の数（親を含む）を実行記録に書く。同時に実行中にする担当は、枠から 1 を引いた数までにする。工程が並行起動を求める担当がそれを超えるときは、役割表の順に枠の分だけ起動し、残りは実行中の担当が完了してから起動する（渡す情報と独立性は[工程](workflow.md)の規則のまま）。起動を待った担当は、待ち始めと起動の時刻を担当表に書く。
+- 起動できない（実行中の担当が無いのに枠の不足で失敗する場合を含む）、または完了しない担当は、[工程](workflow.md)の「実行の制約」のとおり、その担当を未完了として記録し、工程の終了条件に従う。`codex exec`・ほかのモデル・モデルごとの役割定義へ切り替えず、親が代わりに作業せず、ユーザーのグローバル設定（同時実行の上限を含む）を変更しない。

package/plugins/shinaps-codex/references/dev-comparison/record.md

@@ -12,7 +12,7 @@
 
 ## 開始前の照合
 
-Phase 1 で親の観測値（Claude: 自セッションの transcript、Codex: 自スレッドの rollout の `turn_context`）が読めれば、指定値と照合する。照合する項目は、Claude はモデル・推論・service_tier、Codex はモデル・推論・sandbox・承認である。不一致なら開始せず、構成表の起動コマンドで新しいセッションを開始し直すよう報告する。読めなければその項目を未検証として進める。観測手段の無い項目は照合せず、指定値を記録する。
+Phase 1 で親の観測値（Claude: 自セッションの transcript、Codex: 自スレッドの rollout の `turn_context`）が読めれば、指定値と照合する。照合する項目は、Claude はモデル・推論・service_tier、Codex はモデル・推論・sandbox・承認である。不一致なら開始せず、構成表の起動方法で新しいセッションを開始し直すよう報告する。読めなければその項目を未検証として進める。観測手段の無い項目は照合せず、指定値を記録する。
 
 ## 親の特定
 
@@ -25,8 +25,8 @@ Phase 1 で親の観測値（Claude: 自セッションの transcript、Codex:
 
 ## run-record.md の様式
 
-- **実行の識別**: 構成、入口、担当数、比較セット ID、条件ファイルのハッシュ（条件ファイルが課題ファイル・規約スナップショットのハッシュを列挙する）、比較スキルの plugin version と `references/dev-comparison/` のツリーハッシュ（使った plugin の `references/dev-comparison` を cwd にして `find . -type f | LC_ALL=C sort | xargs shasum -a 256 | shasum -a 256` の出力）、課題側の開始コミット、開始・終了時刻。
-- **担当表**（1 担当 1 行）: 役割、担当番号、ラウンド、実行手段、ID（親セッション ID / Claude agent ID / Codex thread_id）、起動・再開・交代の履歴、指定（モデル・推論・tier・Fast・sandbox）、観測（同じ項目、根拠ファイルと時点）、判定（一致／不一致／未検証／指定のみ）、開始・終了時刻、終了状態、使用量（実測／推定／取得不可と出典）。
+- **実行の識別**: 構成、入口、担当数、比較セット ID、条件ファイルのハッシュ（条件ファイルが課題ファイル・規約スナップショットのハッシュを列挙する）、比較スキルの plugin version と `references/dev-comparison/` のツリーハッシュ（使った plugin の `references/dev-comparison` を cwd にして `find . -type f | LC_ALL=C sort | xargs shasum -a 256 | shasum -a 256` の出力）、課題側の開始コミット、開始・終了時刻。Codex の親では、Phase 1 で読んだ同時実行の枠の数と、配置済みの比較専用の役割定義のハッシュ（`$CODEX_HOME/agents` を cwd にした `ls shinaps-comparison-*.toml | LC_ALL=C sort | xargs shasum -a 256 | shasum -a 256` の出力）。
+- **担当表**（1 担当 1 行）: 役割、担当番号、ラウンド、実行手段、ID（親セッション ID / Claude agent ID / Codex thread_id / サブエージェントの task_name・返された ID と、rollout の thread_id）、起動・再開・交代の履歴、指定（モデル・推論・tier・Fast・sandbox）、観測（同じ項目、根拠ファイルと時点）、判定（一致／不一致／未検証／指定のみ）、開始・終了時刻、終了状態、起動待ち（同時実行の上限で後から起動した担当の、待ち始めと起動の時刻）、使用量（実測／推定／取得不可と出典）。
 - **時間**: 総経過時間と Phase ごとの開始・終了。時刻はメインが `date -u +%FT%TZ` で記録する。並行か順次かは担当表の時刻から導く。
 - **修正**: Phase 7 の修正回数、実装後レビューのラウンド数、計画の修正版数。検証の回数は担当表の verifier の行から数える。
 - **人の介入・中断**: 時刻、内容（質問・回答・承認・手作業・環境の復旧）、理由、所要時間。全件を記録する。
@@ -39,19 +39,24 @@ Phase 1 で親の観測値（Claude: 自セッションの transcript、Codex:
   - 不一致: 観測値が指定値と違う項目がある。
   - 割当外の依頼あり: 担当表に無い AI への依頼がある（下記「割当外の依頼の確認」）。
   - 未完了: 未完了の担当がある。
+  - 制約違反あり: 実装担当の実行区間の外で、作業ツリー（未追跡ファイルを含む）が変わった（[工程](workflow.md)の作業ツリーの確認）。変化したパスを併記する。
 
 ## 観測値の読み方
 
 Phase 9、または読める時点で行う。抽出結果は `raw/settings/` に保存する。
 
 - **Claude（親・子）**: `$CLAUDE_CONFIG_DIR`（未指定なら `~/.claude`）の `projects/` 配下にある親の transcript と `<session-id>/subagents/agent-<id>.jsonl`・`.meta.json` の全 assistant メッセージから、`message.model`・各行の `effort`・`message.usage.service_tier` の組の一覧を抽出し、全期間で変化がないことを確認する。子は Agent が返した ID と対応付ける。
-- **Codex（親・子）**: rollout の全ターンの `turn_context`（`model`・`effort`・`sandbox_policy`・`approval_policy`）を読む。親の rollout は「親の特定」で決めたもの、codex exec の担当の rollout は `$CODEX_HOME/sessions/` 配下でファイル名に担当表の thread_id を含むもの。rollout が無ければ未検証とする。service_tier は指定のみ。
+- **Codex（親・子）**: rollout の全ターンの `turn_context`（`model`・`effort`・`sandbox_policy`・`approval_policy`）を読む。
+  - 親の rollout は、「親の特定」で決めたもの。
+  - `codex exec` の担当の rollout は、`$CODEX_HOME/sessions/` 配下で、ファイル名に担当表の thread_id を含むもの。
+  - サブエージェントの rollout は、最初の行の `session_meta.source.subagent.thread_spawn` で、`parent_thread_id` が親の ID、`agent_path` が担当表の `task_name` に対応し、`agent_role` が担当表の `agent_type` と一致するもの。この rollout の ID を担当表の thread_id に書く。1 件に決まらなければ未検証とする。サブエージェントの sandbox・承認の指定値は、親の値とする。
+  - rollout が無ければ未検証とする。service_tier は指定のみとする。サブエージェントの service_tier の指定値は、親の指定値とする（モデル・推論の指定値は、起動時に指定した値である）。
 - rollout は後で削除されることがあるので、各担当の完了後に読む。
 
 ## 使用量
 
 - **Claude**: 同じ `message.id` の行は一度だけ数える（同じ応答が transcript に複数行で記録されるため）。担当ごとの合計と総計で重ねて数えない。
-- **Codex（親・子）**: スレッドの rollout の最後の `token_count` の `info.total_token_usage`（スレッドの累計値。cached・reasoning の内訳を含む）をスレッドごとに一度だけ使い、スレッド間で合計する。resume の `turn.completed.usage` も累計値なので、イベントログの値を合計しない。イベントログは完了判定と thread_id の取得に使う。
+- **Codex（親・子）**: スレッドの rollout の最後の `token_count` の `info.total_token_usage`（スレッドの累計値。cached・reasoning の内訳を含む）をスレッドごとに一度だけ使い、スレッド間で合計する。resume の `turn.completed.usage` も累計値なので、イベントログの値を合計しない。イベントログは完了判定と thread_id の取得に使う。サブエージェントは、スレッドごとの値を書く。親の累計に子の使用量が含まれないことを確かめた場合だけ、確かめた方法と根拠を併記して合計を書く。確かめられなければ、総計は未確定とする。
 - 金額は取得できないので「取得不可」と書く。料金表からの換算は推定欄に根拠付きで書き、実測と合計しない。
 
 ## 割当外の依頼の確認
@@ -59,8 +64,8 @@ Phase 9、または読める時点で行う。抽出結果は `raw/settings/`
 構成表に無い AI への依頼が無いことを、次の一つの手順で確認する。
 
 1. その実行の cwd の記録をすべて列挙する（Claude の project ディレクトリの transcript、`$CODEX_HOME/sessions/` 配下で `session_meta` の `cwd` が一致する rollout）。
-2. 親・子の記録から、AI への依頼に当たる呼び出しを列挙する（Claude: Agent・Skill・MCP の tool_use と Bash コマンド、Codex: rollout の function call・`spawn_agent`・シェルコマンド）。呼び出しの単位（tool_use 1 件、function call 1 件）で、その呼び出しが AI を起動したかを判定する。コマンドやプロンプトの本文に文字列が含まれるだけのものは数えない。
-3. 1 と 2 を担当表と突き合わせる。担当表に無い依頼があれば記録し、判定に「割当外の依頼あり」を書く。
+2. 親・子の記録から、AI への依頼に当たる呼び出しを列挙する（Claude: Agent・Skill・MCP の tool_use と Bash コマンド、Codex: rollout の function call（`spawn_agent`・`followup_task` を含む）・シェルコマンド）。呼び出しの単位（tool_use 1 件、function call 1 件）で、その呼び出しが AI を起動したかを判定する。コマンドやプロンプトの本文に文字列が含まれるだけのものは数えない。子の記録にある `spawn_agent`、`thread_spawn.depth` が 2 以上の rollout、Codex の親による `codex exec` の実行は、担当表に無い依頼として数える。
+3. 1 と 2 を担当表と突き合わせる。担当表に無い依頼があれば記録し、判定に「割当外の依頼あり」を書く。AI Terminal Bridge で起動を依頼された実行の、依頼の受信（`read_messages`・`ack_messages`）と依頼元への終了・停止の報告（`send_message`）は、割当外の依頼に数えない。
 
 ## 2体目の発見の分類
 

package/plugins/shinaps-codex/references/dev-comparison/workflow.md

@@ -19,8 +19,8 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 ### 実行の制約
 
 - 構成表の担当の起動は、比較用入口の実行に含まれる許可として行う。新しい作業環境（worktree・クローン）は作らない。作業環境は実施者が事前に用意する。
-- 指定したモデル・推論・tier・実行権限で担当を起動できなければ、他のモデル・設定・起動手段へ切り替えず、メインが代行もせず、その担当を未完了として記録する。
-- 構成表に無い AI への依頼手段（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）を使わない。
+- 構成表と[起動手順](launch.md)がその起動手段で指定する値（モデル・推論。起動手段が指定できる場合は tier・実行権限も）で担当を起動できなければ、他のモデル・設定・起動手段へ切り替えず、メインが代行もせず、その担当を未完了として記録する。
+- 構成表に無い AI への依頼手段（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）を使わない。AI Terminal Bridge で起動を依頼された場合の、依頼の受信と、依頼元への終了・停止の報告は、これに当たらない。実行中の質問は上の入力手段で行う。
 - 比較実行中は自動メモリへ書き込まない。
 - 規約は比較条件ファイルの規約スナップショットだけを使い、`search_rules` などの shinaps MCP を呼ばない。
 
@@ -42,11 +42,13 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 | 6 | refine | 1 | 同一ラウンドのバッチは継続 | [refine-agent](roles/refine-agent.md) |
 | 6 | 実装の簡素化 | 1 | ラウンドごとに新規 | [simplifier](roles/simplifier.md)（実装の簡素化） |
 
-- 担当を起動するときは[起動手順](launch.md)に従い、担当指示の全文と今回の入力（役割名・担当番号・ラウンド・今回の割当と担当数）を渡す。担当番号は起動前に固定する。
+- 担当を起動するときは[起動手順](launch.md)に従い、担当指示と今回の入力（役割名・担当番号・ラウンド・今回の割当と担当数）を渡す。担当番号は起動前に固定する。
 - 異なる役割は、同じモデルでも別のコンテキストで起動する。同じ役割の継続は同じ ID を再開する。再開できなければ同じ割当（モデル・推論・tier・起動手段）の新しい担当へ確認済み・未確認の範囲と最新の文脈を引き継ぎ、交代を実行記録に書く。
 - 設計担当2 を他の役割へ流用しない。設計担当1 は設計から指摘統合まで同じ ID で続ける。
 - 独立に確認する担当（設計担当、計画レビュー担当、計画簡素化担当、実装後の4役割）は、今回の他担当の結果を受け取らず、意見を交換しない。全担当の完了まで計画・対象コードを変更しない。
-- メインは担当の起動・待機・全文保存・受け渡し・ユーザーへの確認・実行記録だけを行う。指摘を先に選別・要約・重複整理せず、検証をやり直さない。verifier と設計担当も自分で他の担当を起動しない。
+- メインは担当の起動・待機・全文保存・受け渡し・ユーザーへの確認・実行記録だけを行う。指摘を先に選別・要約・重複整理せず、検証をやり直さない。担当は自分で他の担当やエージェントを起動しない。
+- 「並行して起動する」担当の数が、起動手段の同時実行の上限を超える場合は、[起動手順](launch.md)のとおり分けて起動する。分けても、担当の数・独立性・渡す情報は変えない。
+- 作業ツリー（未追跡ファイルを含む）は、実装担当の実行区間の外では変わらない。メインは、Phase 1 の開始時、実装担当の各依頼の前と完了後、Phase 9 の開始時に、作業ツリーの値（`git diff HEAD` の出力と、`git ls-files --others --exclude-standard -z | xargs -0 shasum -a 256` の出力を合わせた sha256。`.shinaps/` は除外されている）を記録する。実装担当の完了後から次の依頼の前まで（Phase 1〜実装前、実装後〜Phase 9 を含む）で値が変わっていれば、[実行記録](record.md)の判定に「制約違反あり」と、変化したパスを書く。前後の値の比較なので、区間の途中で変えて元に戻した場合は検出できない。
 
 ## 3. 担当数の設定
 
@@ -56,7 +58,7 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 
 ### Phase 1: 条件の受け取りと開始前の照合
 
-1. 比較条件ファイル（必須）を読み、課題・開始コミット・規約スナップショット・探索条件・合格条件・許可範囲・実行権限・この構成の親の起動コマンドを確定する。条件ファイルにこの構成が無ければ開始しない。
+1. 比較条件ファイル（必須）を読み、課題・開始コミット・規約スナップショット・探索条件・合格条件・許可範囲・実行権限・この構成の親の起動方法を確定する。条件ファイルにこの構成が無ければ開始しない。
 2. 作業環境が開始状態であることを確認する。`HEAD` が開始コミットと一致し、`git status --porcelain` が空であること（`.shinaps/` は `.shinaps/.gitignore` で除外される）。満たさなければ開始しない。
 3. 課題から英語 slug（kebab-case、30 文字以内）を作り、作業ディレクトリ `.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/` と `raw/` を作る。
 4. `run-record.md` を作り、親の ID と指定値を記録し、[開始前の照合](record.md#開始前の照合)を行う。観測値が読めて指定値と一致しなければ開始しない。
@@ -216,7 +218,8 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 │   ├── simplify.md            ← Phase 6 の実装の簡素化の生レポート（2 回目は simplify-2.md）
 │   ├── architect-revised-{n}.md  ← 計画の修正版（n は 1 始まり）
 │   ├── settings/              ← 観測値の抜粋
-│   └── cli/                   ← codex exec のプロンプト・イベントログ
+│   ├── cli/                   ← codex exec のプロンプト・イベントログ（P1）
+│   └── agents/                ← サブエージェントへ渡した依頼の全文（P4〜P7）
 ├── implementation.md          ← 実装ログ・変更ファイル一覧・動作確認結果
 ├── architecture-review.md     ← 設計担当1 の設計適合性レビュー
 ├── architecture-review-{n}.md ← 修正後の設計適合性レビュー

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

@@ -14,6 +14,8 @@ description: 比較実行用。shinaps:dev の工程を Codex（gpt-6-astra / me
 | `$shinaps:dev-codex-astra 1体 <比較条件ファイルの絶対パス>` | P4 |
 | `$shinaps:dev-codex-astra 2体 <比較条件ファイルの絶対パス>` | P5 |
 
+依頼に明示された引数だけを使い、条件ファイルを探したり推定したりしない。
+
 担当数（`1体` / `2体`）と比較条件ファイルはどちらも必須。どちらかが無い、または担当数が `1体` / `2体` 以外なら、「`$shinaps:dev-codex-astra <1体|2体> <比較条件ファイル>` で指定してください」と返して終了する。
 
 ## 読む資料
@@ -25,12 +27,12 @@ description: 比較実行用。shinaps:dev の工程を Codex（gpt-6-astra / me
 - [起動手順](../../references/dev-comparison/launch.md)
 - [実行記録](../../references/dev-comparison/record.md)
 
-担当指示は工程の役割表から辿る `roles/` の各ファイルを使う。
+担当指示（工程の役割表から辿る `roles/` の各ファイル）は、そこから生成した比較専用の役割定義で担当に渡る。依頼の本文には入れない（[起動手順](../../references/dev-comparison/launch.md#codex-のサブエージェント)）。
 
 ## 守ること
 
-- 構成表のこの構成の行にある担当だけを、`codex exec` で起動する。構成表に無い AI への依頼（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）をしない。
-- 既存の `dev`・`review`・`refine`・`simplify` スキル、登録済みのカスタムエージェント、`spawn_agent` を使わない。
+- 構成表のこの構成の行にある担当だけを、[起動手順](../../references/dev-comparison/launch.md#codex-のサブエージェント)のとおり、比較専用の役割（`shinaps-comparison-*`）を指定した Codex のサブエージェントで起動する。`codex exec` を含め、構成表に無い AI への依頼（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）をしない。
+- 既存の `dev`・`review`・`refine`・`simplify` スキルと、比較専用の役割以外のカスタムエージェント（通常の dev の `shinaps-architect` などを含む）を使わない。
 
 ## 完了報告
 

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

@@ -14,6 +14,8 @@ description: 比較実行用。shinaps:dev の工程を Codex（gpt-6.1-sol / me
 | `$shinaps:dev-codex-sol 1体 <比較条件ファイルの絶対パス>` | P6 |
 | `$shinaps:dev-codex-sol 2体 <比較条件ファイルの絶対パス>` | P7 |
 
+依頼に明示された引数だけを使い、条件ファイルを探したり推定したりしない。
+
 担当数（`1体` / `2体`）と比較条件ファイルはどちらも必須。どちらかが無い、または担当数が `1体` / `2体` 以外なら、「`$shinaps:dev-codex-sol <1体|2体> <比較条件ファイル>` で指定してください」と返して終了する。
 
 ## 読む資料
@@ -25,12 +27,12 @@ description: 比較実行用。shinaps:dev の工程を Codex（gpt-6.1-sol / me
 - [起動手順](../../references/dev-comparison/launch.md)
 - [実行記録](../../references/dev-comparison/record.md)
 
-担当指示は工程の役割表から辿る `roles/` の各ファイルを使う。
+担当指示（工程の役割表から辿る `roles/` の各ファイル）は、そこから生成した比較専用の役割定義で担当に渡る。依頼の本文には入れない（[起動手順](../../references/dev-comparison/launch.md#codex-のサブエージェント)）。
 
 ## 守ること
 
-- 構成表のこの構成の行にある担当だけを、`codex exec` で起動する。構成表に無い AI への依頼（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）をしない。
-- 既存の `dev`・`review`・`refine`・`simplify` スキル、登録済みのカスタムエージェント、`spawn_agent` を使わない。
+- 構成表のこの構成の行にある担当だけを、[起動手順](../../references/dev-comparison/launch.md#codex-のサブエージェント)のとおり、比較専用の役割（`shinaps-comparison-*`）を指定した Codex のサブエージェントで起動する。`codex exec` を含め、構成表に無い AI への依頼（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）をしない。
+- 既存の `dev`・`review`・`refine`・`simplify` スキルと、比較専用の役割以外のカスタムエージェント（通常の dev の `shinaps-architect` などを含む）を使わない。
 
 ## 完了報告
 

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

@@ -94,6 +94,7 @@ AI Terminal Bridge（以下Bridge）の本体は同梱しない。導入済み
 | 完了の報告（ClaudeからCodex） | 対象差分、自動検証の結果、起動方法、確認観点、既知の制限、未解決の事項、`shinaps:dev` 内のレビュー結果の要約と未解決の指摘。コミットした場合は、コミットSHAと `shinaps:commit` の検証・レビューの結果 |
 | 人のレビュー・コミット完了の報告（ClaudeからCodex） | 下の「人のレビュー・コミット完了の報告」の項目 |
 | 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先リポジトリの設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
+| 比較実行の依頼（CodexからClaude） | [比較手順](../../../references/dev-comparison/comparison.md#5-実行)の項目だけ。下の定型文と許可範囲は含めない。Claudeは指定された比較用入口で実行し、このスキルの実装・修正の手順（`shinaps:dev`、Codexへの相談、コミット）を適用しない |
 
 コミットの依頼では、`commit_mode` がない場合の開始時の確認と、通常モードの単位ごとの承認を、Codexが人へ取り次ぐ。Codexは自分で選択・承認しない。