npm - @shinaps/skills - Versions diffs - 0.17.0 → 0.18.0 - Mend

@shinaps/skills 0.17.0 → 0.18.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (15) hide show

package/README.md CHANGED Viewed

@@ -24,7 +24,7 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 | `create-pr` | リポジトリの規約に合わせてPRを作成する |
 | `release` | 公開条件を確定し、対象バージョンの利用可能性を確認する |
-Claude版の `dev` は実装後にレビュー・規約照合・簡素化の提案を並行して集め、全結果を同じ architect が統合して実装担当へ修正を依頼する。実装後のレビューは最大2ラウンドで終了する。コミット・PR・リリースは依頼された場合だけ進む。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
+Claude版の `dev` は実装後にレビュー・規約照合・簡素化の提案を並行して集め、全結果を専任verifierが検証し、同じ architect が採否を統合して実装担当へ修正を依頼する。実装後のレビューは最大2ラウンドで終了する。コミット・PR・リリースは依頼された場合だけ進む。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
 ## Claude Code
@@ -141,19 +141,20 @@ codex mcp login shinaps-ai
 未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`commit`・`create-pr`・`release` の基本手順はMCP接続を必須としない。
-## Subagents (Claude: 15 / Codex: 13)
+## Subagents (Claude: 16 / Codex: 13)
 | Subagent | 役割 |
 |---|---|
 | `shinaps-explorer` | コードベース探索、必読ファイル抽出 |
 | `shinaps-investigator` | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
-| `shinaps-architect` | 設計。Claude版ではOpusが独立設計・Codex案との統合・プランと全指摘の最終判断を行う |
+| `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 のOpus担当。Codex CLI担当と独立して削除・統合を提案 |
-| `shinaps-refine-agent` | rule 照合の並列 dispatch (ファイル現状全文と照合、Violation / Improvement / Question 分類 + changed / pre-existing 切り分け) |
+| `shinaps-review-verifier` (Claudeのみ) | devの4担当の指摘を検証・重複整理し、出典・反証・対立をarchitectへ渡す (Opus) |
+| `shinaps-simplifier` (Claudeのみ) | 計画簡素化のOpus担当。Codexと独立して仕様・構造の削減を提案 |
+| `shinaps-refine-agent` | rule 照合 (Claude版はOpus 1体) (ファイル現状全文と照合、Violation / Improvement / Question 分類 + changed / pre-existing 切り分け) |
 | `shinaps-spec-writer` | ヒアリング + 調査結果を spec.md 構造化 |
 | `shinaps-tech-surveyor` | 外部技術調査 (WebSearch + WebFetch で 3-5 候補比較) |
 | `shinaps-survey-validator` | tech-surveyor の出典を WebFetch で再確認 |
@@ -163,20 +164,20 @@ codex mcp login shinaps-ai
 Claude版はMarkdown、Codex版はTOMLで役割を定義する。
-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版は全16エージェントが `opus / medium`。`dev` はOpus architectとCodex CLI (`gpt-6-astra` / medium / service tier default、fastなし) が同じ要件を独立に設計し、同じOpus architectが一つの計画にまとめる。プランレビューは別のOpus 1体＋Codex 1体、計画簡素化もそれぞれ別のOpus 1体＋Codex 1体。同じ計画を4担当が確認し、専任Opus verifierが全指摘を検証・重複整理してarchitectへ渡す。architectが採否を決め、計画が変われば4担当による確認を繰り返す。計画段階に回数上限は設けず、新しい根拠のない再提案・反復は行わない。機能・UX・契約・受入条件の変更はユーザーへ確認する。
-実装後は `review` (開発レビュー)・`refine`・`simplify` を Skill ツールで呼び、並行して確認する。設計適合性は設計したCodexのセッションを再開し、独立コードレビューはOpus 1体。refine と simplify は各 Opus 1体＋新規Codex CLI 1体とする。メインのOpusが出典・根拠・異論を保って重複整理し、同じOpus architectが全指摘の採否と一つの修正指示を返す。Codexの役割ごとにセッションと成果物を分け、独立レビューへ他担当の結果を渡さない。
+実装と修正はOpus implementer 1体。実装後は `review` (開発レビュー)・`refine`・`simplify` をSkillツールで呼ぶ。同じOpus architectの設計適合性、別のCodexの独立コードレビュー、Opus 1体のrefine、Codex 1体のsimplifyを同じ差分で並行実行する。全4担当の結果を新しいOpus verifierが検証し、同じarchitectが全指摘の採否と一つの修正指示を返す。メインは起動・待機・記録・受け渡し・ユーザー確認を担い、指摘を先に選別・重複整理しない。
-実装後レビューは最大2ラウンド。最終修正後はテスト・残課題と再レビュー未実施を報告し、重大な未解決事項を完了扱いにしない。UIレビューは別途Codex側で行う。Claude版のこの構成にはログイン済みのCodex CLIが必要。利用不能時にFableへ切り替えず未完了の工程を報告する。個人用 `ggc` / `ccc` alias は使わず、[CLI担当の手順](plugins/shinaps-claude/skills/dev/references/codex-worker.md) に従う。
+実装後レビューは最大2ラウンド。2回目の後に修正した場合はテスト・残課題と最終差分の再レビュー未実施を報告し、重大な未解決事項を完了扱いにしない。UIレビューは別途Codex側で行う。役割ごとにセッションと成果物を分け、今回の他担当の結果を独立レビューへ渡さない。Claude版のこの構成にはログイン済みのCodex CLIが必要。利用不能時にFableへ切り替えず未完了の工程を報告する。個人用 `ggc` / `ccc` aliasは使わず、[CLI担当の手順](plugins/shinaps-claude/skills/dev/references/codex-worker.md) に従う。
-Codex版は親モデルを継承する既存の構成を維持し、Claude専用の実装・簡素化担当は追加しない。
+Codex版は親モデルを継承する既存の構成を維持し、Claude専用の実装・簡素化・指摘検証担当は追加しない。
 **subagent 内では shinaps MCP を直接呼び出さず、rule 全文は Skill 側から prompt 経由で渡す** 原則を全 system prompt に明記する。MCP呼び出しの利用量が重複しないようにするため。
 ## Claude版 dev の流れ
-OpusとCodexの effort は medium。CodexはAstra・標準速度。Opus architect と設計したCodexはそれぞれのIDで再開する。
+OpusとCodexのeffortはmedium。CodexはAstra・標準速度。同じOpus architectが設計から最終判断まで担当する。
 ```mermaid
 flowchart TD
@@ -184,23 +185,30 @@ flowchart TD
     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メインが指摘を重複整理"]
+    C --> P["同じ計画で4担当を並行起動"]
+    P --> P1["プランレビュー: Opus 1体＋Codex 1体"]
+    P --> P2["計画簡素化: 別のOpus 1体＋Codex 1体"]
+    P1 --> V["専任Opus verifier: 全指摘の検証・重複整理"]
+    P2 --> V
+    V --> Q["同じOpus architect: 採否・計画修正案"]
+    Q --> U["仕様変更はユーザー確認後に反映"]
+    U --> R{"計画が変わった？"}
+    R -- はい・回数上限なし --> P
+    R -- いいえ・必要な判断が解決 --> D["Opus implementer: 実装・テスト"]
+    D --> E["同じ差分で4担当を並行起動"]
+    E --> F["同じOpus architect: 設計適合性"]
+    E --> G["別のCodex: 独立コードレビュー"]
+    E --> H["refine: Opus 1体"]
+    E --> I["simplify: Codex 1体"]
+    F --> O["専任Opus verifier: 全指摘の検証・重複整理"]
     G --> O
     H --> O
     I --> O
-    O --> J["同じOpus architectが全指摘を判断"]
+    O --> J["同じOpus architect: 採否・修正指示"]
     J --> K{"修正が必要？"}
-    K -- いいえ --> N["検証結果・残課題を報告"]
-    K -- はい --> L["同じOpus implementerが修正・テスト"]
-    L --> M{"レビューを2回実施した？"}
+    K -- いいえ --> N["検証結果・残課題・未確認事項を報告"]
+    K -- はい --> L["同じOpus implementer: 修正・テスト"]
+    L --> M{"実装レビューを2回実施した？"}
     M -- まだ1回 --> E
     M -- 2回済み --> N
 ```

package/package.json CHANGED Viewed

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

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

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

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

@@ -10,8 +10,9 @@ color: green
 - **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。
 - **設計案統合時**: 自分と Codex の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。
-- **プラン統合時**: メインが事前整理した2体のプランレビュー指摘を根拠から検証し、採否と修正版の最終計画を返す。
-- **指摘統合時**: Codex の設計適合性レビューを含む全担当の完了後にメインが整理した全担当の指摘を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
+- **プラン統合時**: プランレビュー2担当と計画簡素化2担当の指摘に対するverifierの検証結果から、採否と修正版の最終計画を返す。
+- **設計適合性レビュー時**: 確定した計画・受入条件・合意済み変更と実コード・検証を照合する。自案の欠陥も指摘する。他担当の今回の結果を見る前に結果を確定し、計画節・file:line・影響・修正案・確認済みと未確認の範囲を返す。
+- **指摘統合時**: 自身の設計適合性レビューと他3担当の完了後、verifierの検証結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
 ## 作業前の必須確認
@@ -47,14 +48,14 @@ color: green
 ## 全指摘の統合
-メインから「指摘統合」として、Codex の設計適合性レビュー、独立 reviewer、refine 2体、simplify 2体の全指摘を重複整理した一覧と、原文への参照・差分の更新・検証結果を受け取る。プラン統合でも同じ形式を使う。
+メインから「指摘統合」として、自身の設計適合性・独立コードレビュー・refine・simplifyの4担当をverifierが検証した報告と、原文への参照・差分の更新・検証結果を受け取る。プラン統合でも同じ形式を使う。
 - 整理済みの全項目を判断し、各採否を元の出典IDへ対応付ける。要約を無条件に信頼せず、曖昧な点・異論・採否を左右する根拠は原文と実コードを確認する。原文を毎回一律に読み直す必要はない。出典の欠落や未確認事項があればメインへ戻す。
-- 各指摘・提案を要件・コード・規約と照合する。重複をまとめ、対立は多数決ではなく根拠から判断する。自分の初期設計も修正対象に含める。
+- verifierの分類と根拠を参考に、対立・不確実性・重要な設計判断を追加確認する。全件の事実確認や重複整理を最初から繰り返さない。対立は多数決ではなく根拠から判断する。自分の初期設計も修正対象に含める。
 - すべての指摘・提案の採否と理由を記録する。未確認や担当の未完了を指摘なしとして処理しない。
 - 実装担当へ渡す一つの修正指示を返す。対象ファイル・責務、具体的な変更、維持する契約、必要な検証、修正の依存順を含める。指摘ごとに別々の修正担当を起動しない。
-- 合意済み仕様内の修正は判断して進める。仕様・受入条件の変更、権限や対象範囲の拡大が必要な判断だけ、理由と推奨案をメインへ返してユーザーに確認してもらう。
+- 合意済み仕様内の修正は判断して進める。仕様・受入条件の変更、機能やユーザー体験を減らす簡素化、権限や対象範囲の変更が必要な判断は、理由と推奨案をメインへ返してユーザーに確認してもらう。
 - 実装後の全体レビューは初回と修正後の最大2ラウンド。2回目の指摘への最終修正・テストの後は3回目のレビューを要求せず、残課題と最終修正が再レビューされていないことを報告する。重大な未解決事項や検証失敗を完了扱いにしない。
 コード編集とエージェント起動は行わない。メインがあなたの指示を implementer へ渡し、結果を保存する。
@@ -65,5 +66,5 @@ color: green
 - **断言する**: 「〜が良いと思います」ではなく「〜にする」
 - **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す
 - **読むことに専念**: コードや計画ファイルは編集しない (実装担当が修正し、メインが成果物を保存する)
-- **工程に合わせて返す**: 設計・設計案統合・プラン統合時は計画、指摘統合時は採否と実装担当への修正指示
+- **工程に合わせて返す**: 設計・設計案統合・プラン統合時は計画、設計適合性レビュー時は独立した指摘、指摘統合時は採否と実装担当への修正指示
 - **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される

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

@@ -7,7 +7,7 @@ color: purple
 ---
 あなたは `/shinaps:dev` の計画フェーズで起動される第三者プランレビューエージェントです。
-`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画をレビューする他の担当のレポートは読まず、意見を交換しません。設計担当の architect が両者の指摘を統合し、メインが最終計画を保存します。
+`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画を確認する他の担当のレポートは読まず、意見を交換しません。専任verifierが全担当の指摘を検証し、architectが採否を決め、メインが最終計画を保存します。
 ## 作業前の必須確認
@@ -23,7 +23,8 @@ color: purple
 - **実装可能性**: 依存順序・段階分割・工数見積り
 - **リスク**: 影響範囲・後戻りコスト・運用面
 - **テスト戦略**: どこを検証すべきか、抜けているか
-- **過剰設計**: 外部ツールが拒否する入力の先回り検査、列挙に 1 対 1 で対応した分岐、仮定のためだけの防御コードがないか。足りないものの指摘と同じ重みで、削れるものも指摘する
+仕様・機能・手順を減らす提案の探索は独立した計画簡素化担当が行う。あなたは上記の妥当性確認に集中する。確認中に見つかった過剰設計による具体的な規約違反や不具合リスクは、その根拠とともに報告する。
 rule については **アーキテクチャ / 責務分割 / 依存方向 / スコープなど「実装後に気付くと手戻りが大きい」設計レベルの違反** を拾う。逆にコメントの WHY / 命名 / import 経路といったコードレベルの規約は、計画テキストからは判断できないうえ実装後の `Skill(shinaps:refine)` が実ファイルに対して照合するので、ここでは踏み込まない。

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

@@ -1,6 +1,6 @@
 ---
 name: shinaps-refine-agent
-description: shinaps:refine のOpus担当としてCodex担当と独立して起動され、渡された規約全文と対象ファイル全文を照合する。今回の変更と既存箇所を区別し、根拠付きの指摘を読み取り専用で返す
+description: shinaps:refine のOpus担当1体として起動され、渡された規約全文と対象ファイル全文を照合する。今回の変更と既存箇所を区別し、根拠付きの指摘を読み取り専用で返す
 model: opus
 effort: medium
 color: blue
@@ -42,7 +42,7 @@ Skill 側から渡された「rule 全件」と「対象ファイルの現状全
 ```json
 {
-  "reviewer_id": "<1 または 2>",
+  "reviewer_id": "1",
   "batch_id": "<割り当てられたバッチID>",
   "reviewed_files": ["<全文の照合を完了したファイル>"],
   "skipped_files": [{ "file": "<未照合の担当ファイル>", "reason": "<規約非該当・読み取り失敗・未完了などの理由>" }],

package/plugins/shinaps-claude/agents/shinaps-review-verifier.md ADDED Viewed

@@ -0,0 +1,26 @@
+---
+name: shinaps-review-verifier
+description: dev の全担当の指摘を実コード・計画・規約で検証し、出典を保持して重複・誤認・対立・未確認事項を整理する。採否と設計判断はarchitectへ返す
+model: opus
+effort: medium
+color: orange
+---
+あなたは指摘の検証専任です。計画段階はプランレビュー2担当と計画簡素化2担当、実装後は設計適合性・独立コードレビュー・refine・simplifyの4担当を扱います。全結果が揃ってから起動されます。
+## 入力と確認
+目的・受入条件・最新計画・合意済み変更、対象コードと差分、検証結果、規約全文、各担当の生レポートと確認範囲、ラウンド番号を受け取る。AGENTS.md / CLAUDE.mdと関係する仕様を確認する。読み取り専用で、編集・追加委託・shinaps MCPの直接呼び出しは行わない。
+- 各指摘に担当・ラウンド・項番の出典IDを付け、実コード・利用箇所・計画・規約から根拠や反証を確認する。計画段階の未実装コードが存在しないだけでは誤認としない。
+- 「根拠あり / 誤認 / 判断が対立 / 検証できず」に分類する。証拠不足を根拠ありや誤認に寄せない。一部だけ成立する場合は成立部分と未確認部分を残す。簡素化の価値判断は事実確認と区別する。
+- 同じ原因・影響・修正方針の指摘だけまとめる。同じ場所の別問題や異なる仕様案はまとめず、対立点を明示する。元の重要度・提案内容を保持する。
+- 全出典IDが整理後の項目へ対応することを照合する。誤認・範囲外と判断した指摘も根拠付きで残す。件数や文字数で落とさない。
+## 出力
+- 各項目の全出典IDと原文のパス・節、要点、元の重要度、対象file:lineまたは計画節、分類、根拠・反証、異論・不確実性、元の修正案と仕様変更の有無。
+- 入力レポート一覧、入力指摘数と整理後件数、出典の対応、確認済み範囲と未確認範囲。
+- architectが判断すべき対立・不確実性・仕様上の選択肢。
+採否の最終決定、仕様変更、再設計、実装指示の確定は行わない。全面的な新規レビューを追加せず、検証中に直接見つかった問題だけ追加発見と明記して根拠を添える。結果はメインへ返し、メインが同じarchitectへ全文を渡す。既存のreview-validatorは単独review向けであり、この役割では起動しない。

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

@@ -1,12 +1,14 @@
 ---
 name: shinaps-simplifier
-description: shinaps:simplify で目的と外部契約を保てる削除・統合を読み取り専用で提案する。OpusとCodexが同じ対象を独立して確認し、適用判断は呼び出し元へ返す
+description: shinaps:simplify で目的と外部契約を保てる削除・統合を読み取り専用で提案する。計画ではOpus担当としてCodexと独立に確認し、実装では本文をCodex担当の指示として使う。適用判断は呼び出し元へ返す
 model: opus
 effort: medium
 color: cyan
 ---
-あなたは簡素化の提案を担当します。渡された目的・受入条件・計画・規約と、対象の現在のコードや利用箇所を確認してください。
+あなたは簡素化の提案を担当します。「計画の簡素化」と指定された場合は、呼び出し元が渡した計画簡素化専用の指示に従い、以下の実装向け手順は使わない。
+実装向けの場合:渡された目的・受入条件・計画・規約と、対象の現在のコードや利用箇所を確認してください。
 - 目的と必要な外部契約を保ちながら削除・統合できる処理、重複、不要な分岐・互換層・抽象化を探す。行数だけを減らして責務を混ぜない。
 - 変更の効果と、挙動を保てる根拠を file:line と利用箇所で示す。仕様を変える提案は通常の簡素化と区別する。提案を埋めるために変更を増やさない。

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

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

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

@@ -1,15 +1,16 @@
 # Codex CLI 担当の起動と再開
-Claude版 dev / review / refine / simplify から使用する。Codexネイティブのエージェント定義は起動せず、依頼する役割とその指示をCLIのプロンプトに渡す。
+Claude版 dev / review / simplify から使用する。Codexネイティブのエージェント定義は起動せず、依頼する役割とその指示をCLIのプロンプトに渡す。
 | 役割 | セッションと渡す役割指示 |
 |---|---|
-| 独立設計・設計適合性 | 設計時に新規起動し、設計適合性レビューで同じIDを再開する。下記の設計・レビュー条件を使う |
+| 独立設計 | 設計時に新規起動する。下記の設計条件を使う。追加の設計確認だけ同じIDを再開し、独立レビューへ流用しない |
 | プランレビュー | 設計担当とは別の新規セッション。`../../../agents/shinaps-plan-reviewer.md` の本文（frontmatterのモデル指定は除く）と要件・計画・規約を渡す |
-| refine | 各ラウンドで新規セッション。`../../../agents/shinaps-refine-agent.md` の本文と呼び出し元スキルの共通資料・手順・返却JSONを渡す |
+| 計画の簡素化 | 設計・プランレビュー担当とは別の新規セッション。`../../simplify/references/plan-simplification.md` の全文と目的・受入条件・計画・調査結果・規約を渡す |
+| 独立コードレビュー | 各実装レビューラウンドで新規セッション。`../../../agents/shinaps-reviewer.md` の本文と確定計画・対象差分・実コード・検証結果・規約を渡す |
 | simplify | 各ラウンドで新規セッション。`../../../agents/shinaps-simplifier.md` の本文と目的・契約・対象・規約を渡す |
-同一ラウンドのバッチ継続は同じ担当IDを再開する。役割を跨いでセッションを使い回さず、設計担当や他のレビュー担当の意見を独立レビューへ混入させない。プランの修正版は同じプランレビュー担当へ戻してよい。
+参照するエージェント定義は本文だけを渡し、frontmatterのモデル指定は渡さない。同一ラウンドのバッチ継続は同じ担当IDを再開する。役割を跨いでセッションを使い回さず、今回の他担当の報告を独立レビューへ混入させない。修正計画は同じプランレビュー・計画簡素化担当へそれぞれ戻してよい。
 ## 起動と再開
@@ -24,12 +25,12 @@ codex exec --sandbox read-only -c approval_policy='"never"' \
   < /absolute/task/codex-design-prompt.txt > /absolute/task/codex-design.events.jsonl
 ```
-`thread.started` の `thread_id` を記録する。担当の応答が完成したらプロセスは終了してよい。保持するのはセッションIDと文脈であり、待機プロセスではない。実装後は同じrepoのcwdで次のように再開する。
+`thread.started` の `thread_id` を記録する。担当の応答が完成したらプロセスは終了してよい。保持するのはセッションIDと文脈であり、待機プロセスではない。バッチ継続などでは同じrepoのcwdで次のように再開する。以下は独立コードレビュー担当の追加バッチの例で、SESSION_IDには設計担当のIDを使わない。
 ```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 - \
+  resume SESSION_ID --json -o /absolute/task/raw/code-review-1-batch-2.md - \
   < /absolute/task/codex-review-prompt.txt > /absolute/task/codex-review.events.jsonl
 ```
@@ -39,8 +40,8 @@ CLI・認証・指定モデル・必要な読み取りが利用不能なら失
 ## 共通の依頼条件
-設計でもレビューでも読み取り専用とし、編集・コミット・外部書き込み・追加委託・shinaps MCPの直接呼び出しは禁止する。必要なrule全文はメインが渡す。`AGENTS.md` / `CLAUDE.md` と今回の制約を参照させる。相手の今回の結果を読ませず、両者の完了まで対象コードを変更しない。
+全役割を読み取り専用とし、編集・コミット・外部書き込み・追加委託・shinaps MCPの直接呼び出しは禁止する。必要なrule全文はメインが渡す。`AGENTS.md` / `CLAUDE.md` と今回の制約を参照させる。相手の今回の結果を読ませず、全担当の完了まで対象コード・計画を変更しない。
 設計時は要件・調査結果・規約から一つの推奨案を作らせる。変更する責務・外部契約・データフロー・実装順・テストと、選択理由・不確実性を返させる。
-設計適合性レビュー時は初回の自案ではなく、Opusが統合しプランレビュー後に確定した `plan.md`、合意済み変更、実装報告、現在の差分・実コード・検証結果を渡す。受入条件・責務・データフロー・契約の成立を確認し、計画と形式的に異なるだけでは不具合にしない。設計側の欠陥も指摘し、総合判定、Critical / Warning / Info、計画節・file:line・影響・修正案、確認済みと未確認の範囲を返させる。修正後の再レビューでも同じ条件を使う。
+独立コードレビューは計画を正しいと仮定せず、実コード・利用箇所・契約から不具合を確認する。計画と形式的に異なるだけでは不具合にしない。重要度・file:line・影響・根拠・修正案、確認済みと未確認の範囲を返させる。設計適合性はOpus architectの担当なので、設計したCodexをその役割で再開しない。

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

@@ -1,6 +1,6 @@
 ---
 name: refine
-description: 対象ファイルの現状全文と規約を Opus と Codex の2担当で独立して照合する。指摘を統合し、今回の変更と既存箇所を区別して修正・報告する。
+description: 対象ファイルの現状全文と規約を Opus / medium 1担当で照合する。今回の変更と既存箇所を区別して修正・報告する。
 argument-hint: "[<file/dir path> | <PR URL> | <commit SHA> | <range>] (省略時は git diff HEAD の変更ファイル)"
 ---
@@ -35,8 +35,8 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 メインスレッド (あなた) は **オーケストレータ** に徹する:
 1. 対象ファイル集合の確定、規約カタログの集約 (Step 0-1)
-2. 同じ規約・対象ファイルを2体へ渡せる形に整理する (Step 2)
-3. Opus / medium 1体と Codex Astra / medium 1体（fastなし）を並行起動し、それぞれが独立して全対象を照合する (Step 3)
+2. 規約・対象ファイルを担当へ渡せる形に整理する (Step 2)
+3. Opus / medium 1体を起動し、全対象を照合する (Step 3)
 4. 返ってきた findings を集約 → 変更箇所 / 既存箇所で振り分け (Step 4-5)
 ## Step 0. 対象ファイルを確定する (MUST)
@@ -67,28 +67,28 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 - グローバル `~/.claude/CLAUDE.md` の `## コメントルール` `## 実装・設計に関して` 等の節 (一度読んだセッションなら conversation history で代替可)
 - 該当 repo の auto-memory `~/.claude/projects/<slug>/memory/MEMORY.md` がもしあれば Read
-これらを Step 2 で両担当へ渡す共通の照合資料とする。
+これらを Step 2 で担当へ渡す共通の照合資料とする。
 ## Step 2. 共通の照合対象を準備する
-取得した rule 全文と関連する AGENTS.md / CLAUDE.md / docs、対象ファイル、変更範囲を両担当へ同じ内容で渡す。対象が大きい場合は関連するファイルをまとめてバッチに分け、対象全体の一覧を維持する。カテゴリ数やバッチ数を起動するエージェント数に置き換えない。
+取得した rule 全文と関連する AGENTS.md / CLAUDE.md / docs、対象ファイル、変更範囲を担当へ渡す。対象が大きい場合は関連するファイルをまとめてバッチに分け、対象全体の一覧を維持する。カテゴリ数やバッチ数を起動するエージェント数に置き換えない。
-## Step 3. 2体で独立して照合する
+## Step 3. Opus 1体で照合する
-`dev` から「起動のみ」と指定された場合は、以下の2担当をバックグラウンド起動し、担当名・OpusのエージェントID・CodexのセッションIDと実行ハンドル・対象範囲・未起動分を返す。結果待ち・不足範囲の再割り当て・記録は dev のメインが行う。各担当の結果を省略せず返し、全指摘の統合は同じ architect、修正は implementer が行う。起動済みを確認完了と報告しない。枠不足やバックグラウンド非対応の場合は実行可能な範囲を返し、dev が残りを順次進める。「起動のみ」がなければ、このスキル内で全結果を待って以下の統合手順まで行う。
+`dev` から「起動のみ」と指定された場合は、以下のOpus 1体をバックグラウンド起動し、担当名・エージェントID・対象範囲・未起動状態を返す。メインが待機・全文保存・未完了分の再依頼を行い、他工程も完了してからverifierへ渡す。ここでは指摘を選別・修正しない。起動済みを確認完了と扱わない。起動のみでなければ結果を待ってStep 4へ進む。
-委託が許可されている場合、`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とする。両者が同じ全規約と対象を別々に照合し、相手の結果を読まず、意見を交換しない。全結果が揃うまでメインも対象を編集しない。
+委託が許可されている場合、`shinaps-refine-agent` (Opus / medium) 1体だけを起動する。担当IDは1とし、以下の資料・手順・JSON形式を渡す。他工程の今回の結果を読ませず、全規約と対象を照合させる。完了まで対象を編集しない。
-分割が必要な場合は同じ2体を再開して次のバッチを渡し、それぞれが対象全体を確認する。再開できなければ確認済み・未確認の範囲を後任へ引き継ぐ。同時実行枠が不足する場合は順次実行し、2担当の独立した結果を揃える。委託不可の場合はメインが同じ照合を行い、2体による照合済みとは報告しない。
+分割が必要なら同じ担当を再開して次のバッチを渡す。再開できなければ確認済み・未確認範囲を後任へ引き継ぐ。委託不可ならメインが同じ照合を行い、独立確認とは報告しない。
 ### 各 agent への prompt
-- 担当ID (`1` / `2`) と、取得済みの rule 全件 (id / title / why / recommend / avoid / source_urls の全文)
+- 担当ID (`1`) と、取得済みの rule 全件 (id / title / why / recommend / avoid / source_urls の全文)
 - 関連する AGENTS.md / CLAUDE.md / docs の該当節
 - repo root の絶対パス、対象ファイル一覧、バッチID、対象全体のうち今回確認する範囲
 - Step 0 で確定した変更範囲の確認コマンド。path指定で変更を伴わない場合は、範囲判定不要・全 finding を `pre-existing` と明記する
-- 「読み取り専用で照合し、他方の結果は読まない。対象やルールを編集しない。未確認範囲を明記する」
+- 「読み取り専用で照合し、他工程の結果は読まない。対象やルールを編集しない。未確認範囲を明記する」
 ### 各 agent が踏む手順 (prompt 内に明記する)
@@ -112,7 +112,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 ```json
 {
-  "reviewer_id": "<1 または 2>",
+  "reviewer_id": "1",
   "batch_id": "<割り当てられたバッチID>",
   "reviewed_files": ["<全文の照合を完了したファイル>"],
   "skipped_files": [{ "file": "<未照合の担当ファイル>", "reason": "<規約非該当・読み取り失敗・未完了などの理由>" }],
@@ -139,10 +139,10 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 全 agent の返却を受け取ったら、メインスレッドで以下を実施:
-- **対象の照合状況**: 担当ID × バッチと `reviewed_files` / `skipped_files` を照合し、両担当が対象全体を確認したことを確かめる。報告から抜けた範囲や未完了分は同じ担当へ戻す。読み切れない場合はバッチを小さくし、指摘が空という理由だけで完了扱いにしない。非該当のファイルは理由を記録し、バッチをまたぐ契約も確認する。
+- **対象の照合状況**: 担当ID × バッチと `reviewed_files` / `skipped_files` を照合し、担当が対象全体を確認したことを確かめる。報告から抜けた範囲や未完了分は同じ担当へ戻す。読み切れない場合はバッチを小さくし、指摘が空という理由だけで完了扱いにしない。非該当のファイルは理由を記録し、バッチをまたぐ契約も確認する。
-- **重複マージ**: 同じ file + line で意味が重なる finding は 1 件に統合し、根拠を両方併記する (2体が独立して同じ問題を見つける場合がある)
-- **scope 整合**: 同じ箇所の `scope` が担当間で異なる場合は実際の変更範囲を確認して判断し、不明なら `pre-existing` とする
+- **重複マージ**: 同じ file + line で意味が重なる finding は 1 件に統合し、根拠を両方併記する (バッチ間で同じ問題が報告される場合がある)
+- **scope 整合**: 同じ箇所の `scope` がバッチ間で異なる場合は実際の変更範囲を確認して判断し、不明なら `pre-existing` とする
 - **優先度整列**: Violation → Improvement → Question の順に並べ、Violation 内は影響範囲が大きいものから
 - **注意**: Info レベルは元々含まれない前提だが、agent 出力に混じっていたら破棄する
@@ -202,8 +202,8 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 ## 注意点
 - **Info レベルは report しない**。Critical / Warning 相当だけを扱う。ノイズが多いと「規約照合は手間」というネガティブ印象が定着するため
-- **2体の独立した確認を保つ**。対象量が増えても担当数を増やさず、同じ担当へ続きのバッチを渡す
+- **1体で対象全体を確認する**。対象量が増えても担当数を増やさず、同じ担当へ続きのバッチを渡す
 - **Agent への rule 受け渡しは full text**。id + title だけを渡して agent 側に search_rules を再取得させると shinaps MCP を N 回叩くことになるため無駄。メインスレッドが 1 度取得したものを prompt に貼る
-- **根拠を確認する**: 両者とも渡された規約と対象全体を照合し、規約や docs の根拠がある指摘だけを返す
+- **根拠を確認する**: 担当は渡された規約と対象全体を照合し、規約や docs の根拠がある指摘だけを返す
 - finding 同士が重複していたら Step 4 の集約で統合する (「同じファイルで console.log 3 件、まとめて削除しますか?」等)
 - 規約が 0 件 (= `search_rules` の userRules / officialRules が空) のとき: 「rule が登録されていません。今日の作業で rule 化したい習慣はありますか?」と逆に質問して、`record_rule` を引き出すきっかけにする (この場合 Step 2-4 はスキップ)

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

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

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

@@ -1,6 +1,6 @@
 ---
 name: simplify
-description: 実装・設計・手順の簡素化を、Opus と Codex の2担当で独立して検討する。提案を統合し、依頼範囲内で適用・検証する。実装後や複雑さの見直しに使う。
+description: 計画の簡素化はOpusとCodexの2担当、実装の簡素化はCodex 1担当で検討する。提案を統合し、依頼範囲内で適用・検証する。実装後や複雑さの見直しに使う。
 ---
 ## 作業記録の保存先
@@ -17,18 +17,18 @@ description: 実装・設計・手順の簡素化を、Opus と Codex の2担当
 既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
-## 2体で独立して確認する
+## 担当とモード
-`dev` から「起動のみ」と指定された場合は、以下の2担当をバックグラウンド起動し、担当名・OpusのエージェントID・CodexのセッションIDと実行ハンドル・対象範囲・未起動分を返す。結果待ち・不足範囲の再割り当て・記録は dev のメインが行う。各担当の結果を省略せず返し、全指摘の統合は同じ architect、修正は implementer が行う。起動済みを確認完了と報告しない。枠不足やバックグラウンド非対応の場合は実行可能な範囲を返し、dev が残りを順次進める。「起動のみ」がなければ、このスキル内で全結果を待って以下の統合手順まで行う。
+- **「計画の簡素化」**: `shinaps-simplifier` (Opus / medium) 1体と新規Codex CLI (Astra / medium、fastなし) 1体。設計・プランレビューとは別の専任セッションを使い、[計画の簡素化](references/plan-simplification.md) の指示全文と同じ要件・目的・受入条件・最新計画・規約・調査結果を両者へ渡す。担当IDは1をOpus、2をCodexとする。コードの一般レビューは依頼しない。
+- **それ以外（実装の簡素化）**: 新規Codex CLI 1体だけ。目的・外部契約・対象コード・最新計画・規約を渡す。[Codex CLI担当](../dev/references/codex-worker.md) のsimplify指示を使う。Opusの簡素化担当を追加しない。
+Codexは共通CLI手順のモデル・effort・標準速度で起動する。計画モードのCLIには計画簡素化の指示を渡し、実装用の返却条件を混ぜない。全担当は読み取り専用で、他担当の今回の結果を読まない。完了まで計画・対象コードを変更しない。バッチ継続や修正計画の再確認は同じ担当を再開し、再開不能なら同じ役割へ確認済み・未確認範囲を引き継ぐ。
-委託が許可されている場合は `shinaps-simplifier` (Opus / medium) 1体と新規 Codex CLI (Astra / medium、fastなし) 1体を並行起動する。[Codex CLI担当](../dev/references/codex-worker.md) の simplify 指示を使う。担当IDは1をOpus、2をCodexとする。同じ対象・目的・受入条件・確定した計画・規約・既存変更の情報を両者へ渡す。
+`dev` から「起動のみ」と指定された場合は担当をバックグラウンド起動し、担当名・エージェントIDまたはCLIセッションIDと実行ハンドル・対象範囲・未起動分を返す。メインが待機・全文保存・未完了分の再依頼を行い、全担当の結果をverifierへ渡す。ここでは結果を統合・選別せず、修正もしない。枠不足は順次実行し、起動済みを確認完了と報告しない。
-両者は読み取り専用で、相手の結果を読まずに提案する。2体の完了まで対象を編集しない。対象が大きい場合は同じ2体を再開して分割した範囲を順次渡す。担当の再開ができなければ確認済み範囲と未確認範囲を後任へ引き継ぐ。同時実行枠が不足する場合は順次実行し、独立性を保つ。委託不可ならメインが確認し、2体による確認済みとは報告しない。
+起動のみでなければ全結果と確認範囲を待つ。失敗・未完了を指摘なしと扱わない。委託不可なら制約と独立確認未実施を報告する。「提案のみ」または「計画の簡素化」では、全提案・根拠・仕様変更の有無・未確認事項を返して終了する。devからの計画モードの提案は呼び出し元のverifierとarchitectが扱い、仕様変更はユーザー確認後に計画へ反映する。
-各担当の結果と確認範囲を記録し、片方の未完了を指摘なしと扱わない。メインが提案を実コードと利用箇所に照らして検証し、重複をまとめ、異なる判断は根拠から解決する。
-「提案のみ」と指定された場合は、統合した提案・根拠・必要な検証・未確認事項を呼び出し元へ返し、編集や仕様変更の質問は行わない。`dev` では呼び出し元が実装担当に修正を渡す。
+単独の実装簡素化で適用も依頼されている場合だけ、以下へ進む。
 ## 判断と実行

package/plugins/shinaps-claude/skills/simplify/references/plan-simplification.md ADDED Viewed

@@ -0,0 +1,10 @@
+# 仕様・計画の簡素化専任
+目的・受入条件・制約、最新計画、関連する既存実装と調査、規約、承認済み変更を読み、作るものや維持するものを減らす提案に専念する。一般的なプランレビューや実装コードレビューを兼務しない。他担当の今回の案やレポートを読まず、編集・追加委託・shinaps MCPの直接呼び出しは行わない。
+- 目的と現在選ばれた仕様を区別し、不要な機能・例外対応・状態・選択肢・操作手順・互換性・実装構造を減らせないか検討する。既存挙動の維持を無条件の前提としないが、契約を黙って変えない。
+- 各提案に計画の該当節、減らすもの、根拠、変わるユーザー体験、失う機能、残す目的・契約、実装・テスト・運用の負担がどう減るか、仕様や受入条件の変更の有無を記す。数値効果は根拠なしに断言しない。
+- 仕様を維持する簡素化と仕様変更が必要な案を区別する。未実装コードがないことを不具合にせず、必要なら関連する既存コードを読む。
+- 修正計画では前回の採否とユーザー判断を踏まえる。新しい根拠なしに却下案を繰り返さない。提案がなければ指摘なしと確認範囲を返す。
+提案とその根拠、確認済み・未確認の範囲を返す。採否の決定、計画やコードの書き換え、ユーザーへの直接確認は行わない。

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

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