@shinaps/skills 0.16.0 → 0.17.0

package/README.md

@@ -147,12 +147,12 @@ codex mcp login shinaps-ai
 |---|---|
 | `shinaps-explorer` | コードベース探索、必読ファイル抽出 |
 | `shinaps-investigator` | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
-| `shinaps-architect` | 設計。Claude版では同じ担当がプラン統合・実装レビュー・全指摘の統合を行う |
-| `shinaps-plan-reviewer` | 計画レビュー (confidence 閾値 70)。Claude版はOpus 2体が独立して指摘と修正案を返す |
+| `shinaps-architect` | 設計。Claude版ではOpusが独立設計・Codex案との統合・プランと全指摘の最終判断を行う |
+| `shinaps-plan-reviewer` | 計画レビュー (confidence 閾値 70)。Claude版はOpus 1体＋独立したCodex CLI 1体が指摘と修正案を返す |
 | `shinaps-implementer` (Claudeのみ) | 確定した計画の実装・簡素化・検証、レビュー後の修正 (Opus) |
 | `shinaps-reviewer` | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80) |
 | `shinaps-review-validator` | reviewer 指摘の実コード検証 (confirmed / false positive / partial / out-of-scope 分類) |
-| `shinaps-simplifier` (Claudeのみ) | simplify から2体を起動し、目的を保つ削除・統合を独立して提案 (Opus / medium) |
+| `shinaps-simplifier` (Claudeのみ) | simplify のOpus担当。Codex CLI担当と独立して削除・統合を提案 |
 | `shinaps-refine-agent` | rule 照合の並列 dispatch (ファイル現状全文と照合、Violation / Improvement / Question 分類 + changed / pre-existing 切り分け) |
 | `shinaps-spec-writer` | ヒアリング + 調査結果を spec.md 構造化 |
 | `shinaps-tech-surveyor` | 外部技術調査 (WebSearch + WebFetch で 3-5 候補比較) |
@@ -163,9 +163,11 @@ codex mcp login shinaps-ai
 
 Claude版はMarkdown、Codex版はTOMLで役割を定義する。
 
-Claude版の `dev` は、委託が許可されている場合に `shinaps-implementer` 1体へ実装と修正を渡す。architect は `best / medium`、プランレビューは `opus / medium` 2体、実装担当は `opus / medium` を使う。実装後は同じ architect の設計適合性レビューと、独立した reviewer (`opus / medium`) のコードレビューを並行して行い、両者の結果が揃ってから修正する。
+Claude版は全15エージェントが `opus / medium`。`dev` は Opus architect と Codex CLI (`gpt-6-astra` / medium / service tier default、fastなし) が同じ要件を独立に設計し、Opus architect が根拠を比較して一つの計画にまとめる。プランレビューは別の Opus 1体＋Codex CLI 1体。実装と修正は Opus implementer 1体が担当する。
 
-Claude版の `dev` は `review` (開発レビュー)・`refine`・`simplify` を Skill ツールで明示的に呼び、担当のバックグラウンド起動後に全結果を待つ。`simplify` と `refine` はそれぞれ Opus / medium の2体で同じ対象を独立して確認する。architect が提案・指摘を根拠から統合し、実装担当へ一つの修正指示を返す。メインは起動・待機・記録とユーザーへの確認を担う。実装後のレビューは初回と修正後の最大2ラウンドとし、2回目の修正後はテスト結果と残課題を報告する。最終修正が再レビューされていないことを明示し、重大な未解決事項を完了扱いにしない。UIレビューは別途Codex側で行う。
+実装後は `review` (開発レビュー)・`refine`・`simplify` を Skill ツールで呼び、並行して確認する。設計適合性は設計したCodexのセッションを再開し、独立コードレビューはOpus 1体。refine と simplify は各 Opus 1体＋新規Codex CLI 1体とする。メインのOpusが出典・根拠・異論を保って重複整理し、同じOpus architectが全指摘の採否と一つの修正指示を返す。Codexの役割ごとにセッションと成果物を分け、独立レビューへ他担当の結果を渡さない。
+
+実装後レビューは最大2ラウンド。最終修正後はテスト・残課題と再レビュー未実施を報告し、重大な未解決事項を完了扱いにしない。UIレビューは別途Codex側で行う。Claude版のこの構成にはログイン済みのCodex CLIが必要。利用不能時にFableへ切り替えず未完了の工程を報告する。個人用 `ggc` / `ccc` alias は使わず、[CLI担当の手順](plugins/shinaps-claude/skills/dev/references/codex-worker.md) に従う。
 
 Codex版は親モデルを継承する既存の構成を維持し、Claude専用の実装・簡素化担当は追加しない。
 
@@ -174,25 +176,30 @@ Codex版は親モデルを継承する既存の構成を維持し、Claude専用
 
 ## Claude版 dev の流れ
 
-全エージェントの effort は medium。architect は保持したIDで再開し、実装中は新しい作業を依頼しない。
+OpusとCodexの effort は medium。CodexはAstra・標準速度。Opus architect と設計したCodexはそれぞれのIDで再開する。
 
 ```mermaid
 flowchart TD
-    A["architect: best / medium<br/>設計・実装計画"] --> B["プランレビュー: Opus / medium × 2"]
-    B --> C["同じ architect が統合・計画確定"]
-    C --> D["implementer: Opus / medium<br/>実装・テスト"]
-    D --> E["同じ差分でレビュー開始"]
-    E --> F["同じ architect: 設計適合性"]
-    E --> G["review: Opus / medium × 1"]
-    E --> H["refine: Opus / medium × 2"]
-    E --> I["simplify: Opus / medium × 2"]
-    F --> J["同じ architect が全指摘を統合"]
-    G --> J
-    H --> J
-    I --> J
+    S["共通の要件・調査・規約"] --> A["Opus: 独立設計"]
+    S --> B["Codex Astra: 独立設計"]
+    A --> C["同じOpus architectが2案を統合"]
+    B --> C
+    C --> P["プランレビュー: Opus 1体＋別のCodex 1体"]
+    P --> Q["Opusメインが重複整理 → architectが計画確定"]
+    Q --> D["Opus implementer: 実装・テスト"]
+    D --> E["同じ差分で並行レビュー"]
+    E --> F["設計したCodex: 設計適合性"]
+    E --> G["Opus: 独立コードレビュー"]
+    E --> H["refine: Opus 1体＋Codex 1体"]
+    E --> I["simplify: Opus 1体＋Codex 1体"]
+    F --> O["Opusメインが指摘を重複整理"]
+    G --> O
+    H --> O
+    I --> O
+    O --> J["同じOpus architectが全指摘を判断"]
     J --> K{"修正が必要？"}
     K -- いいえ --> N["検証結果・残課題を報告"]
-    K -- はい --> L["同じ implementer が修正・テスト"]
+    K -- はい --> L["同じOpus implementerが修正・テスト"]
     L --> M{"レビューを2回実施した？"}
     M -- まだ1回 --> E
     M -- 2回済み --> N

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.16.0",
+  "version": "0.17.0",
   "description": "Install Shinaps AI workflows and custom agents for Codex",
   "type": "module",
   "bin": {

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

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

package/plugins/shinaps-claude/agents/shinaps-architect.md

@@ -1,7 +1,7 @@
 ---
 name: shinaps-architect
-description: shinaps:dev の設計・プラン指摘の統合・実装レビュー・全指摘の統合を同じ担当として行い、implementer への実装・修正指示を返す
-model: best
+description: shinaps:dev の独立設計・Codexとの設計案統合・プラン指摘と実装後の全指摘の統合を同じ担当として行い、implementer への実装・修正指示を返す
+model: opus
 effort: medium
 color: green
 ---
@@ -9,9 +9,9 @@ color: green
 あなたは `/shinaps:dev` の設計担当です。メインから指定された工程に従います。
 
 - **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。
-- **プラン統合時**: 2体のプランレビュー指摘を根拠から検証し、採否と修正版の最終計画を返す。
-- **指摘統合時**: 自分の実装レビュー完了後に全担当の結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
-- **実装レビュー時**: 下記の「実装レビュー」に従い、計画の再作成ではなく実際のコードとの整合性を検証する。
+- **設計案統合時**: 自分と Codex の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。
+- **プラン統合時**: メインが事前整理した2体のプランレビュー指摘を根拠から検証し、採否と修正版の最終計画を返す。
+- **指摘統合時**: Codex の設計適合性レビューを含む全担当の完了後にメインが整理した全担当の指摘を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
 
 ## 作業前の必須確認
 
@@ -45,18 +45,11 @@ color: green
 - **テスト戦略**: どこにどんなテストを書くか
 - **観点トレードオフの要約**: 採用理由・却下理由を各観点で 1 行
 
-## 実装レビュー
-
-- 自分の初回案ではなく、プランレビュー後に確定した `plan.md` と、その後に合意された変更を基準にする。メインから渡された受入条件、実装報告、差分、検証結果と、現在のコードを読む。
-- 受入条件・責務分割・データフロー・外部契約が実装と検証で満たされているかを確認する。形式的に計画と異なるだけでは不具合扱いにせず、具体的な影響を示す。
-- 設計自体に欠陥があれば、自分の設計を正当化せず、設計側の問題として根拠と修正案を返す。仕様変更の判断はメインへ返す。
-- 自分の実装レビューを返すまでは、今回の reviewer / refine / simplify の結果を読まず、意見を交換しない。自分の結果を確定した後、全担当が完了してから指摘統合へ進む。
-- 総合判定と Critical / Warning / Info、各指摘の計画節・コードの file:line・影響・修正案、確認済みと未確認の受入条件を返す。指摘がなければその旨を示す。
-- 再レビューでは修正後の実装と合意済みの最新計画を確認する。コードや計画は編集しない。
-
 ## 全指摘の統合
 
-メインから「指摘統合」として、自分のレビュー、独立 reviewer、refine 2体、simplify 2体の全結果と最新の差分・検証結果を受け取る。
+メインから「指摘統合」として、Codex の設計適合性レビュー、独立 reviewer、refine 2体、simplify 2体の全指摘を重複整理した一覧と、原文への参照・差分の更新・検証結果を受け取る。プラン統合でも同じ形式を使う。
+
+- 整理済みの全項目を判断し、各採否を元の出典IDへ対応付ける。要約を無条件に信頼せず、曖昧な点・異論・採否を左右する根拠は原文と実コードを確認する。原文を毎回一律に読み直す必要はない。出典の欠落や未確認事項があればメインへ戻す。
 
 - 各指摘・提案を要件・コード・規約と照合する。重複をまとめ、対立は多数決ではなく根拠から判断する。自分の初期設計も修正対象に含める。
 - すべての指摘・提案の採否と理由を記録する。未確認や担当の未完了を指摘なしとして処理しない。
@@ -72,5 +65,5 @@ color: green
 - **断言する**: 「〜が良いと思います」ではなく「〜にする」
 - **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す
 - **読むことに専念**: コードや計画ファイルは編集しない (実装担当が修正し、メインが成果物を保存する)
-- **工程に合わせて返す**: 設計・プラン統合時は最終計画、実装レビュー時は根拠付き指摘、指摘統合時は採否と実装担当への修正指示
+- **工程に合わせて返す**: 設計・設計案統合・プラン統合時は計画、指摘統合時は採否と実装担当への修正指示
 - **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される

package/plugins/shinaps-claude/agents/shinaps-plan-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: shinaps-plan-reviewer
-description: shinaps:dev の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、独立した指摘と具体的な修正案を返す。2体で同じ計画を別々に検証する
+description: shinaps:dev の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、独立した指摘と具体的な修正案を返す。OpusとCodexが同じ計画を別々に検証する
 model: opus
 effort: medium
 color: purple

package/plugins/shinaps-claude/agents/shinaps-refine-agent.md

@@ -1,6 +1,6 @@
 ---
 name: shinaps-refine-agent
-description: shinaps:refine から2体で独立して起動され、渡された規約全文と対象ファイル全文を照合する。今回の変更と既存箇所を区別し、根拠付きの指摘を読み取り専用で返す
+description: shinaps:refine のOpus担当としてCodex担当と独立して起動され、渡された規約全文と対象ファイル全文を照合する。今回の変更と既存箇所を区別し、根拠付きの指摘を読み取り専用で返す
 model: opus
 effort: medium
 color: blue

package/plugins/shinaps-claude/agents/shinaps-simplifier.md

@@ -1,6 +1,6 @@
 ---
 name: shinaps-simplifier
-description: shinaps:simplify で目的と外部契約を保てる削除・統合を読み取り専用で提案する。2体が同じ対象を独立して確認し、適用判断は呼び出し元へ返す
+description: shinaps:simplify で目的と外部契約を保てる削除・統合を読み取り専用で提案する。OpusとCodexが同じ対象を独立して確認し、適用判断は呼び出し元へ返す
 model: opus
 effort: medium
 color: cyan

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

@@ -32,13 +32,25 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 | エージェント | subagent_type | 役割 |
 |---|---|---|
 | Shinaps Explorer | `shinaps-explorer` | コードベース探索、必読ファイル抽出 (spec / explore の事前調査が十分なら再起動しない) |
-| Shinaps Architect | `shinaps-architect` | 設計・プラン統合・設計適合性レビュー・全指摘の統合を担当 |
-| Shinaps Plan Reviewer | `shinaps-plan-reviewer` | Opus 2体で同じ計画を独立レビューし、指摘と修正案を返す |
+| Shinaps Architect | `shinaps-architect` | 独立設計・2案の統合・プラン統合・全指摘の最終判断 (Opus) |
+| Codex CLI | `codex exec` | Astra / medium・標準速度で独立設計し、同じセッションで設計適合性をレビュー |
+| Shinaps Plan Reviewer | `shinaps-plan-reviewer` | Opus 1体＋別の Codex CLI 1体で同じ計画を独立レビューし、指摘と修正案を返す |
 | Shinaps Implementer | `shinaps-implementer` | 確定した計画の実装・検証と、レビュー後に決まった修正 (Opus) |
 | Shinaps Reviewer | `shinaps-reviewer` | logic / design / security / performance / maintainability / rule の統合観点でレビュー |
 
 委託が許可されている場合、実装と修正は **`shinaps-implementer` (Opus) 1 体**が担当し、architect が設計判断と全指摘の統合を担い、メインはスキル呼び出し・エージェントの起動と再開・待機・記録・ユーザーへの確認を担う。設計判断を実装へ引き継ぎつつモデルの利用を分けるため、確定した計画・判断理由・規約を実装担当へ渡す。委託不可またはエージェントを利用できない場合はメインが担当し、その旨を報告する。
 
+## モデルと指摘の事前整理
+
+メインは Opus / medium、architect は定義の opus / medium を使う構成を推奨する。スキルからユーザーのモデル設定を変更しない。メインが別モデルの場合は Opus で整理したとは報告しない。Codex は `gpt-6-astra` / medium / `service_tier="default"` とし、このフローから Fable / best は呼ばない。CLIの利用条件・起動・再開・完了判定は [Codex CLI担当](references/codex-worker.md) に従う。
+
+プランレビューと実装後レビューの全結果が揃ったら、メインが次の形で整理してから architect へ渡す。整理専用のエージェントは追加しない。
+
+- 生レポートは全文保存し、全指摘に出典ID（担当・ラウンド・項番）を付ける。同じ原因・影響・修正方針の指摘だけまとめ、元の全IDと原文のパス・節を残す。判断が割れる指摘や同じ場所の別問題は統合しない。
+- 各項目に要点、重要度、対象の file:line、根拠、修正案、維持する契約、異論・不確実性を残す。全出典IDが整理後の項目に対応することを照合し、確認範囲・未確認事項も引き継ぐ。件数や文字数で指摘を落とさない。
+- メインは採否・重要度の引き下げ・対立の解消を行わない。architect が全項目を判断し、曖昧な要約や対立は原文・実コードで確かめる。
+- 整理結果はプラン用 `raw/plan-findings-{round}.md`、実装用 `raw/findings-{round}.md` に保存する。architect には整理結果と原文への参照、前回からの変更・検証結果を渡す。既に渡した計画・規約・レポート全文を毎回貼り直さず、変更部分を示す。再開できず文脈を失った場合は必要な情報を引き継ぐ。
+
 ## ディレクトリ規約
 
 ```
@@ -46,13 +58,15 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 ├── plan.md                    ← Phase 4 で2体の指摘を統合した最終 plan
 ├── raw/                       ← 計画フェーズの生レポート (全文保存)
 │   ├── explorer.md            ← または explorer-1.md, explorer-2.md ... (事前調査 handoff 時は既存レポートを参照)
-│   ├── architect.md           ← architect の初回案
+│   ├── architect-opus.md      ← Opus の独立設計案
+│   ├── architect-codex.md     ← Codex の独立設計案
+│   ├── architect.md           ← Opus が統合した計画
 │   ├── plan-review-{round}-{1,2}.md ← 各プランレビューの結果
 │   ├── refine.md              ← Phase 6 で走らせた Skill(shinaps:refine) の findings 集約
 │   ├── simplify.md            ← Phase 6 の簡素化レビューの生レポート
 │   └── architect-revised-{n}.md  ← 差し戻し再策定時のみ (n は 1 始まり)
 ├── implementation.md          ← 実装ログ・変更ファイル一覧・動作確認結果
-├── architecture-review.md     ← architect の実装レビュー
+├── architecture-review.md     ← Codex の設計適合性レビュー
 ├── architecture-review-{n}.md ← 修正後の設計適合性レビュー
 ├── review.md                  ← 独立 reviewer の生レポート
 ├── review-{n}.md              ← 修正後の再レビュー (n は 2 始まり)
@@ -109,27 +123,30 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 ### Phase 3: 実装ブループリント策定
 
-`shinaps-architect` を 1 体起動。応答時のエージェントIDを保持し、プラン統合・実装レビュー・指摘統合で同じ担当を再開する。implementer が作業する間もIDと文脈を保持し、architect を破棄しない。再開できない場合だけ設計判断・最新計画・過去の指摘と採否を後任に引き継ぎ、その旨を記録する。
+`shinaps-architect` (Opus / medium) 1体と Codex CLI (Astra / medium、fastなし) 1実行を並行して開始する。両者へ同じ要件・調査結果・規約を渡し、互いの案や今回の他担当のレポートを読まず、読み取り専用で独立に設計させる。
 
-**プロンプトに含める情報**:
-- タスク内容
-- Phase 2 の調査結果 (explorer または handoff 済み investigation の必読ファイル一覧 + 要点)
-- **Phase 2 で取得した `search_rules` 結果 (userRules + officialRules 全文)**
-- 「作業前に必ず CLAUDE.md / プロジェクト規約を Read し、rule カタログと突き合わせよ」
+**両者へ渡す情報**:
+- タスクの目的・受入条件・合意済みの制約
+- Phase 2 の調査結果・必読ファイル・根拠
+- Phase 2 で取得した rule 全文と適用される CLAUDE.md / AGENTS.md
+- 変更する責務・外部契約・データフロー・実装順・必要なテストを、根拠付きの一つの推奨案として返すこと
+- コード編集・追加委託・shinaps MCP の直接呼び出しは禁止
+
+**記録先**: Opus案は `raw/architect-opus.md`、Codex案は `raw/architect-codex.md`。両方の結果が揃ったら同じ Opus architect を「設計案統合」として再開し、両案の根拠・トレードオフを比較して一つの計画を返させ、`raw/architect.md` に保存する。多数決や単純な継ぎ合わせにせず、採否と理由を残す。設計者間の反復議論は追加しない。この統合案を Phase 4 のレビュー対象にする。
 
-**記録先**: メインが Write で `raw/architect.md`
+Opus のエージェントIDと Codex の `thread.started.thread_id` は別々に保持する。前者は設計案・プラン・全指摘の統合、後者は実装後の設計適合性レビューで再開する。実装中も両IDと設計の文脈を保持する。再開できなければ同じモデルに設計判断・最新計画・指摘の採否を引き継ぎ、担当変更を記録する。CLI起動失敗や未完了を二者設計済みと扱わず、利用不能時にFableへ切り替えない。
 
 ### Phase 4: プランレビュー
 
-委託が許可されている場合、`shinaps-plan-reviewer` (Opus / medium) を **2体並列**で起動し、両者へ同じ情報を渡す。起動時にモデルを上書きしない。同時実行枠が不足する場合は順次起動し、2体分の独立した結果を揃える。
+委託が許可されている場合、`shinaps-plan-reviewer` (Opus / medium) 1体と、設計担当とは別の新規 Codex CLI (Astra / medium、fastなし) 1体を並行起動する。[Codex CLI担当](references/codex-worker.md) のプランレビュー指示を使い、両者へ同じ情報を渡す。同時実行枠が不足する場合は順次起動し、2体分の独立した結果を揃える。
 
 - タスクの目的・受入条件、Phase 2 の調査結果と rule 全文
 - Phase 3 の architect 案全文 (再策定時は最新案)
 - 「設計・要件・実装可能性・リスク・テスト戦略・過剰設計をレビューし、判定と具体的な修正案を返す。他のプランレビュー担当の結果は読まず、意見を交換しない」
 
-両者の完了までは対象の計画を変更しない。メインは結果を `raw/plan-review-{round}-1.md` と `raw/plan-review-{round}-2.md` に保存する (round は 1 始まり)。片方が失敗・未完了なら2体で検証済みと扱わず、未完了分を完了させてから統合する。
+両者の完了までは対象の計画を変更しない。メインは結果を `raw/plan-review-{round}-1.md` と `raw/plan-review-{round}-2.md` に保存する (round は 1 始まり、1はOpus、2はCodex)。片方が失敗・未完了なら2体で検証済みと扱わず、未完了分を完了させてから統合する。
 
-メインが同じ architect を「プラン統合」として再開し、2体の全指摘を渡す。architect が根拠を検証して重複・対立を整理し、採否と修正版の最終計画を返す。メインは結果を保存し、単一の `plan.md` を確定する。architect が仕様判断や範囲拡大の相談を返した場合だけ、メインがユーザーへ一問ずつ確認して決定を戻す。
+メインが同じ architect を「プラン統合」として再開し、メインが事前整理した全指摘と原文への参照を渡す。architect が根拠を検証して対立を判断し、採否と修正版の最終計画を返す。メインは結果を保存し、単一の `plan.md` を確定する。architect が仕様判断や範囲拡大の相談を返した場合だけ、メインがユーザーへ一問ずつ確認して決定を戻す。
 
 差し戻しがある場合は、その根拠を検証し、必要な再策定を同じ architect に依頼する。修正版を `raw/architect-revised-{n}.md` に保存し、2体とも同じ修正版を改めてレビューする。採用した Critical / Warning が計画に反映され、未解決の判断がなくなってから Phase 5 へ進む。委託不可の場合はメインが同じ観点で確認し、独立レビュー未実施と明記する。
 
@@ -174,11 +191,11 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 | スキル呼び出し | 担当 |
 |---|---|
-| `Skill(skill="shinaps:review", args="開発レビュー、起動のみ。…")` | 設計した architect を再開 + 独立 reviewer 1体 |
-| `Skill(skill="shinaps:refine", args="照合のみ、起動のみ。…")` | Opus / medium 2体 |
-| `Skill(skill="shinaps:simplify", args="提案のみ、起動のみ。…")` | Opus / medium 2体 |
+| `Skill(skill="shinaps:review", args="開発レビュー、起動のみ。…")` | 設計した Codex CLI を再開 + 独立 Opus reviewer 1体 |
+| `Skill(skill="shinaps:refine", args="照合のみ、起動のみ。…")` | Opus / medium 1体＋Codex Astra / medium 1体（fastなし） |
+| `Skill(skill="shinaps:simplify", args="提案のみ、起動のみ。…")` | Opus / medium 1体＋Codex Astra / medium 1体（fastなし） |
 
-引数の省略部分には具体的な対象ファイル・変更範囲、最終 plan・受入条件・合意済み変更、実装報告、検証結果、規約・rule 全文と成果物のパスを渡す。review には設計担当のエージェントIDと設計判断も渡す。単独の review とは異なる開発レビューの手順を使い、外部調査や review-validator を追加起動しない。
+引数の省略部分には具体的な対象ファイル・変更範囲、最終 plan・受入条件・合意済み変更、実装報告、検証結果、規約・rule 全文と成果物のパスを渡す。review には Codex のセッションID・設計判断と統合後の最終計画を渡す。Opus architect はこの段階では起動せず、全指摘の統合まで待機する。単独の review とは異なる開発レビューの手順を使い、外部調査や review-validator を追加起動しない。
 
 先に起動した担当の完了を待ってから次のスキルを呼ぶのではなく、3スキルの担当を起動してから結果を待つ。dev 自身が同じ担当を重複起動しない。同時実行枠が足りなければ未起動分を記録して順次実行し、台数や確認範囲を黙って減らさない。ツールや委託が利用できなければその制約を明記し、独立確認済みと扱わない。
 
@@ -186,11 +203,11 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 各スキルの確認範囲・未完了報告を確認し、未確認部分は同じ担当へ戻す。対象が大きい場合も継続または後任への引き継ぎで全対象を確認する。失敗・未完了を「指摘なし」として処理しない。
 
-自分のレビューを確定した architect と全担当の結果を保存する。初回は `architecture-review.md` / `review.md` / `raw/refine.md` / `raw/simplify.md`、2回目は各ファイル名に `-2` を付ける。全結果が揃った後で初めて同じ architect を「指摘統合」として再開し、自分のレビューを含む全結果・現在の差分・検証結果・ラウンド番号を渡す。独立レビュー中に他担当の結果を渡さない。
+Codex の設計適合性レビューと全担当の結果を保存する。初回は `architecture-review.md` / `review.md` / `raw/refine.md` / `raw/simplify.md`、2回目は各ファイル名に `-2` を付ける。全結果が揃った後、メインが Codex のレビューも含めて事前整理する。その後で同じ architect を「指摘統合」として再開し、整理した全指摘・原文への参照・差分の更新・検証結果・ラウンド番号を渡す。独立レビュー中に他担当の結果を渡さない。
 
 ### Phase 7: architect が統合し、implementer が修正
 
-architect が review・refine・simplify の全指摘を根拠から検証し、重複・対立を整理する。全指摘の採否と理由、採用した修正の対象・責務・具体的な変更・維持する契約・必要な検証を、一つの修正指示として返す。メインはそのまま記録し、仕様・受入条件の変更や未許可の範囲拡大が必要な点だけユーザーに確認する。通常の設計・修正判断をメインでやり直さない。
+architect が review・refine・simplify の整理された全指摘を根拠から検証し、対立を判断する。全指摘の採否と理由、採用した修正の対象・責務・具体的な変更・維持する契約・必要な検証を、一つの修正指示として返す。メインはそのまま記録し、仕様・受入条件の変更や未許可の範囲拡大が必要な点だけユーザーに確認する。通常の設計・修正判断をメインでやり直さない。
 
 修正不要なら Phase 9 へ進む。修正があれば、メインが同じ `shinaps-implementer` を再開し、architect の修正指示・確定した計画・現在の差分・規約・検証条件を渡す。再開できなければ実装履歴と採否を新しい担当へ引き継ぐ。architect は次のレビューに備えて保持し、自分でコードを編集したり、実装担当を追加起動したりしない。
 

package/plugins/shinaps-claude/skills/dev/references/codex-worker.md

@@ -0,0 +1,46 @@
+# Codex CLI 担当の起動と再開
+
+Claude版 dev / review / refine / simplify から使用する。Codexネイティブのエージェント定義は起動せず、依頼する役割とその指示をCLIのプロンプトに渡す。
+
+| 役割 | セッションと渡す役割指示 |
+|---|---|
+| 独立設計・設計適合性 | 設計時に新規起動し、設計適合性レビューで同じIDを再開する。下記の設計・レビュー条件を使う |
+| プランレビュー | 設計担当とは別の新規セッション。`../../../agents/shinaps-plan-reviewer.md` の本文（frontmatterのモデル指定は除く）と要件・計画・規約を渡す |
+| refine | 各ラウンドで新規セッション。`../../../agents/shinaps-refine-agent.md` の本文と呼び出し元スキルの共通資料・手順・返却JSONを渡す |
+| simplify | 各ラウンドで新規セッション。`../../../agents/shinaps-simplifier.md` の本文と目的・契約・対象・規約を渡す |
+
+同一ラウンドのバッチ継続は同じ担当IDを再開する。役割を跨いでセッションを使い回さず、設計担当や他のレビュー担当の意見を独立レビューへ混入させない。プランの修正版は同じプランレビュー担当へ戻してよい。
+
+## 起動と再開
+
+対象repoのcwdで `codex exec --help` と `codex exec resume --help` を確認する。モデルは `gpt-6-astra`、effort は medium、service tier は default。個人用 `ggc` aliasやfast設定を使わず、毎回明示する。ユーザーのグローバル設定は変更しない。
+
+メインが今回の要件・規約・担当範囲をプロンプトファイルに保存し、標準入力から渡す。本文をシェルコードへ展開しない。下の例は設計用。メインが今回の役割・ラウンド・バッチごとに固有の絶対パスへ置き換え、並行実行のプロンプト・レポート・イベントを分ける。`--json` は実行状態とセッションIDの取得、`-o` はレポート保存のために使う。
+
+```sh
+codex exec --sandbox read-only -c approval_policy='"never"' \
+  -m gpt-6-astra -c model_reasoning_effort='"medium"' -c service_tier='"default"' \
+  --json -o /absolute/task/raw/architect-codex.md - \
+  < /absolute/task/codex-design-prompt.txt > /absolute/task/codex-design.events.jsonl
+```
+
+`thread.started` の `thread_id` を記録する。担当の応答が完成したらプロセスは終了してよい。保持するのはセッションIDと文脈であり、待機プロセスではない。実装後は同じrepoのcwdで次のように再開する。
+
+```sh
+codex exec --sandbox read-only -c approval_policy='"never"' \
+  -m gpt-6-astra -c model_reasoning_effort='"medium"' -c service_tier='"default"' \
+  resume SESSION_ID --json -o /absolute/task/architecture-review.md - \
+  < /absolute/task/codex-review-prompt.txt > /absolute/task/codex-review.events.jsonl
+```
+
+同時実行中の別タスクを再開しないため `--last` は使わない。2回目のレビューは出力パスに `-2` を付け、前回のレポートを保持する。利用可能なバックグラウンド実行機構で起動し、メインがプロセス完了・終了コード・`turn.completed`・空でない最終レポートを確認する。途中の `error` / `turn.failed`、確認範囲の不足を完了扱いにしない。イベントログは失敗診断とID確認に用い、全文を architect に貼り付けない。
+
+CLI・認証・指定モデル・必要な読み取りが利用不能なら失敗の根拠を返し、Fableや他モデルへ黙って切り替えない。失敗実行の部分出力は保存し、再試行・担当変更では前回を上書きしない。起動・再開が利用できない場合は制約を報告し、成功や独立確認を装わない。
+
+## 共通の依頼条件
+
+設計でもレビューでも読み取り専用とし、編集・コミット・外部書き込み・追加委託・shinaps MCPの直接呼び出しは禁止する。必要なrule全文はメインが渡す。`AGENTS.md` / `CLAUDE.md` と今回の制約を参照させる。相手の今回の結果を読ませず、両者の完了まで対象コードを変更しない。
+
+設計時は要件・調査結果・規約から一つの推奨案を作らせる。変更する責務・外部契約・データフロー・実装順・テストと、選択理由・不確実性を返させる。
+
+設計適合性レビュー時は初回の自案ではなく、Opusが統合しプランレビュー後に確定した `plan.md`、合意済み変更、実装報告、現在の差分・実コード・検証結果を渡す。受入条件・責務・データフロー・契約の成立を確認し、計画と形式的に異なるだけでは不具合にしない。設計側の欠陥も指摘し、総合判定、Critical / Warning / Info、計画節・file:line・影響・修正案、確認済みと未確認の範囲を返させる。修正後の再レビューでも同じ条件を使う。

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

@@ -1,6 +1,6 @@
 ---
 name: refine
-description: 対象ファイルの現状全文と規約を Opus / medium の2体で独立して照合する。指摘を統合し、今回の変更と既存箇所を区別して修正・報告する。
+description: 対象ファイルの現状全文と規約を Opus と Codex の2担当で独立して照合する。指摘を統合し、今回の変更と既存箇所を区別して修正・報告する。
 argument-hint: "[<file/dir path> | <PR URL> | <commit SHA> | <range>] (省略時は git diff HEAD の変更ファイル)"
 ---
 
@@ -36,7 +36,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 
 1. 対象ファイル集合の確定、規約カタログの集約 (Step 0-1)
 2. 同じ規約・対象ファイルを2体へ渡せる形に整理する (Step 2)
-3. `shinaps-refine-agent` (Opus / medium) を **2体並列**で起動し、それぞれが独立して全対象を照合する (Step 3)
+3. Opus / medium 1体と Codex Astra / medium 1体（fastなし）を並行起動し、それぞれが独立して全対象を照合する (Step 3)
 4. 返ってきた findings を集約 → 変更箇所 / 既存箇所で振り分け (Step 4-5)
 
 ## Step 0. 対象ファイルを確定する (MUST)
@@ -75,10 +75,10 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 
 ## Step 3. 2体で独立して照合する
 
-`dev` から「起動のみ」と指定された場合は、以下の2担当をバックグラウンド起動し、担当名・エージェントID・対象範囲・未起動分を返す。結果待ち・不足範囲の再割り当て・記録は dev のメインが行う。各担当の結果を省略せず返し、全指摘の統合は同じ architect、修正は implementer が行う。起動済みを確認完了と報告しない。枠不足やバックグラウンド非対応の場合は実行可能な範囲を返し、dev が残りを順次進める。「起動のみ」がなければ、このスキル内で全結果を待って以下の統合手順まで行う。
+`dev` から「起動のみ」と指定された場合は、以下の2担当をバックグラウンド起動し、担当名・OpusのエージェントID・CodexのセッションIDと実行ハンドル・対象範囲・未起動分を返す。結果待ち・不足範囲の再割り当て・記録は dev のメインが行う。各担当の結果を省略せず返し、全指摘の統合は同じ architect、修正は implementer が行う。起動済みを確認完了と報告しない。枠不足やバックグラウンド非対応の場合は実行可能な範囲を返し、dev が残りを順次進める。「起動のみ」がなければ、このスキル内で全結果を待って以下の統合手順まで行う。
 
 
-委託が許可されている場合、`shinaps-refine-agent` を **2体並列**で起動する。モデル・effort は定義の `opus / medium` を使い、起動時に上書きしない。両者が同じ全規約と対象を別々に照合し、相手の結果を読まず、意見を交換しない。全結果が揃うまでメインも対象を編集しない。
+委託が許可されている場合、`shinaps-refine-agent` (Opus / medium) 1体と新規 Codex CLI (Astra / medium、fastなし) 1体を並行起動する。[Codex CLI担当](../dev/references/codex-worker.md) の refine 指示に従い、両者へ以下の共通資料・手順・JSON形式を渡す。担当IDは1をOpus、2をCodexとする。両者が同じ全規約と対象を別々に照合し、相手の結果を読まず、意見を交換しない。全結果が揃うまでメインも対象を編集しない。
 
 分割が必要な場合は同じ2体を再開して次のバッチを渡し、それぞれが対象全体を確認する。再開できなければ確認済み・未確認の範囲を後任へ引き継ぐ。同時実行枠が不足する場合は順次実行し、2担当の独立した結果を揃える。委託不可の場合はメインが同じ照合を行い、2体による照合済みとは報告しない。
 
@@ -93,7 +93,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 ### 各 agent が踏む手順 (prompt 内に明記する)
 
 1. 渡された全ファイルについて適用される規約を確認する。照合できない場合や規約が非該当の場合は理由を記録する
-2. 選んだファイルを `Read` で **現状全文** 取得する (diff の hunk ではなく、いま repo にある状態そのもの)
+2. 選んだファイルを利用可能な読み取りツールで **現状全文** 取得する (diff の hunk ではなく、いま repo にある状態そのもの)
 3. 「変更範囲の確認コマンド」を `<path>` に差し替えて実行し、そのファイルの **どの行が今回の変更に含まれるか** を把握する
 4. ファイル全体を渡された規約と突き合わせ、findings を分類する。**変更行の周辺だけに絞らない** — ファイル全体として規約に反していないかを見る
 5. 各 finding が手順 3 で把握した変更行に該当するかで `scope` を決める (`changed` / `pre-existing`)

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

@@ -22,14 +22,14 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 引数に「開発レビュー」と指定された場合は、この節だけを実行し、以下の単独レビューの引数判定・外部調査・review-validator・devへの引き継ぎは実行しない。
 
-呼び出し元から対象ファイルと差分 (staged / unstaged / untracked を含む)、最終 plan・受入条件・合意済み変更、実装報告と検証結果、rule 全文、設計担当のエージェントIDと設計判断の理由を受け取る。
+呼び出し元から対象ファイルと差分 (staged / unstaged / untracked を含む)、最終 plan・受入条件・合意済み変更、実装報告と検証結果、rule 全文、設計した Codex CLI のセッションIDと設計判断の理由を受け取る。
 
-- **設計適合性**: 設計した `shinaps-architect` を再開し、初回案ではなく確定した plan と現在のコード・検証を照合するよう依頼する。再開できなければ設計判断を引き継いだ新しい architect を使い、その旨を記録する。
+- **設計適合性**: [Codex CLI担当](../dev/references/codex-worker.md) の手順で、設計した Codex CLI のセッションを Astra / medium・fastなしで再開する。初回案ではなく Opus が統合しプランレビューを経て確定した plan と現在のコード・検証を照合する。再開できなければ同じモデルに設計判断を引き継ぎ、その旨を記録する。Opus architect を設計適合性レビューとして重複起動しない。
 - **独立レビュー**: 新しい `shinaps-reviewer` 1体へ、コードの正しさ・安全性・性能・保守性・規約の確認を依頼する。
 
-両者へ同じ対象を渡し、読み取り専用で並行して確認する。今回の他担当の結果を読ませず、意見を交換させない。全担当が完了するまで対象を編集しない。モデルと effort は各エージェント定義を使う。
+両者へ同じ対象を渡し、読み取り専用で並行して確認する。今回の他担当の結果を読ませず、意見を交換させない。全担当が完了するまで対象を編集しない。Opus reviewer はエージェント定義、Codex は上記CLI手順のモデル・effort・service tier を使う。
 
-「起動のみ」と指定された場合は、対応する実行環境で両担当をバックグラウンド起動し、担当名・エージェントID・対象範囲・未起動分を返す。結果待ちと記録は dev のメイン、全指摘の統合は同じ architect、修正は implementer が行う。起動済みをレビュー完了と報告しない。枠不足やバックグラウンド非対応なら実行可能な範囲を返し、dev が残りを順次進める。委託不可の場合はその制約を返す。
+「起動のみ」と指定された場合は、対応する実行環境で両担当をバックグラウンド起動し、担当名・OpusのエージェントID・CodexのセッションIDと実行ハンドル・対象範囲・未起動分を返す。結果待ちと記録は dev のメイン、全指摘の統合は同じ architect、修正は implementer が行う。起動済みをレビュー完了と報告しない。枠不足やバックグラウンド非対応なら実行可能な範囲を返し、dev が残りを順次進める。委託不可の場合はその制約を返す。
 
 起動のみでない場合は両者の完了を待ち、結果と確認範囲を呼び出し元へ返す。指摘の修正は行わない。再レビューでは最新の計画・修正差分・前回の指摘・修正内容・検証結果を使い、今回の結果が揃うまで同じ独立性を保つ。
 

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

@@ -1,6 +1,6 @@
 ---
 name: simplify
-description: 実装・設計・手順の簡素化を、Opus / medium の2体で独立して検討する。提案を統合し、依頼範囲内で適用・検証する。実装後や複雑さの見直しに使う。
+description: 実装・設計・手順の簡素化を、Opus と Codex の2担当で独立して検討する。提案を統合し、依頼範囲内で適用・検証する。実装後や複雑さの見直しに使う。
 ---
 
 ## 作業記録の保存先
@@ -19,10 +19,10 @@ description: 実装・設計・手順の簡素化を、Opus / medium の2体で
 
 ## 2体で独立して確認する
 
-`dev` から「起動のみ」と指定された場合は、以下の2担当をバックグラウンド起動し、担当名・エージェントID・対象範囲・未起動分を返す。結果待ち・不足範囲の再割り当て・記録は dev のメインが行う。各担当の結果を省略せず返し、全指摘の統合は同じ architect、修正は implementer が行う。起動済みを確認完了と報告しない。枠不足やバックグラウンド非対応の場合は実行可能な範囲を返し、dev が残りを順次進める。「起動のみ」がなければ、このスキル内で全結果を待って以下の統合手順まで行う。
+`dev` から「起動のみ」と指定された場合は、以下の2担当をバックグラウンド起動し、担当名・OpusのエージェントID・CodexのセッションIDと実行ハンドル・対象範囲・未起動分を返す。結果待ち・不足範囲の再割り当て・記録は dev のメインが行う。各担当の結果を省略せず返し、全指摘の統合は同じ architect、修正は implementer が行う。起動済みを確認完了と報告しない。枠不足やバックグラウンド非対応の場合は実行可能な範囲を返し、dev が残りを順次進める。「起動のみ」がなければ、このスキル内で全結果を待って以下の統合手順まで行う。
 
 
-委託が許可されている場合は `shinaps-simplifier` を2体並列で起動する。モデルと effort は定義の `opus / medium` を使い、起動時に上書きしない。同じ対象・目的・受入条件・確定した計画・規約・既存変更の情報を両者へ渡す。
+委託が許可されている場合は `shinaps-simplifier` (Opus / medium) 1体と新規 Codex CLI (Astra / medium、fastなし) 1体を並行起動する。[Codex CLI担当](../dev/references/codex-worker.md) の simplify 指示を使う。担当IDは1をOpus、2をCodexとする。同じ対象・目的・受入条件・確定した計画・規約・既存変更の情報を両者へ渡す。
 
 両者は読み取り専用で、相手の結果を読まずに提案する。2体の完了まで対象を編集しない。対象が大きい場合は同じ2体を再開して分割した範囲を順次渡す。担当の再開ができなければ確認済み範囲と未確認範囲を後任へ引き継ぐ。同時実行枠が不足する場合は順次実行し、独立性を保つ。委託不可ならメインが確認し、2体による確認済みとは報告しない。
 

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

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