@shinaps/skills 0.13.1 → 0.15.0

package/README.md

@@ -142,17 +142,18 @@ codex mcp login shinaps-ai
 
 未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`verify-ui`・`commit`・`create-pr`・`release` の基本手順はMCP接続を必須としない。
 
-## Subagents (Claude: 14 / Codex: 13)
+## Subagents (Claude: 15 / Codex: 13)
 
 | Subagent | 役割 |
 |---|---|
 | `shinaps-explorer` | コードベース探索、必読ファイル抽出 |
 | `shinaps-investigator` | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
-| `shinaps-architect` | 実装ブループリント策定 (複数観点 → 単一案収束) |
-| `shinaps-plan-reviewer` | architect 案の批判 + 修正版最終 plan (confidence 閾値 70) |
+| `shinaps-architect` | 設計。Claude版では実装後に再開し、設計適合性もレビュー |
+| `shinaps-plan-reviewer` | 計画レビュー (confidence 閾値 70)。Claude版はOpus 2体が独立して指摘と修正案を返す |
 | `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-refine-agent` | rule 照合の並列 dispatch (ファイル現状全文と照合、Violation / Improvement / Question 分類 + changed / pre-existing 切り分け) |
 | `shinaps-spec-writer` | ヒアリング + 調査結果を spec.md 構造化 |
 | `shinaps-tech-surveyor` | 外部技術調査 (WebSearch + WebFetch で 3-5 候補比較) |
@@ -163,7 +164,11 @@ codex mcp login shinaps-ai
 
 Claude版はMarkdown、Codex版はTOMLで役割を定義する。
 
-Claude版の `dev` は、委託が許可されている場合に `shinaps-implementer` 1体へ実装と修正を渡す。architect と plan-reviewer は `model: best`、実装担当を含む他のエージェントは `model: opus` を使う。メインは仕様判断・進行管理と実際の差分・検証結果の確認を担う。Codex版は親モデルを継承する既存の構成を維持し、Claude専用の実装担当は追加しない。
+Claude版の `dev` は、委託が許可されている場合に `shinaps-implementer` 1体へ実装と修正を渡す。architect は `best / high`、プランレビューは `opus / high` 2体、実装担当は `opus / medium` を使う。実装後は同じ architect の設計適合性レビューと、独立した reviewer (`opus / high`) のコードレビューを並行して行い、両者の結果が揃ってから修正する。
+
+Claude版の `dev` は `simplify`・`refine` と必要な `verify-ui` を Skill ツールで明示的に呼ぶ。`simplify` と `refine` はそれぞれ Opus / medium の2体で同じ対象を独立して確認する。提案・指摘を統合してから実装担当が修正する。メインは仕様判断・進行管理と実際の差分・検証結果の確認を担う。
+
+Codex版は親モデルを継承する既存の構成を維持し、Claude専用の実装・簡素化担当は追加しない。
 
 **subagent 内では shinaps MCP を直接呼び出さず、rule 全文は Skill 側から prompt 経由で渡す** 原則を全 system prompt に明記する。MCP呼び出しの利用量が重複しないようにするため。
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.13.1",
+  "version": "0.15.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の開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・UI検証・レビュー・コミット・PR・リリースを支援する12スキル。",
-  "version": "0.13.1",
+  "version": "0.15.0",
   "author": {
     "name": "shinaps",
     "email": "ryuta@shinaps.jp"

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

@@ -1,13 +1,15 @@
 ---
 name: shinaps-architect
-description: shinaps:dev の計画フェーズで起動される実装ブループリント策定エージェント。shinaps-explorer の探索結果と、Skill 側から渡された search_rules 由来の rule カタログ・CLAUDE.md 規約を踏まえ、複数観点を内部で検討した上で唯一最強の実装計画を断言する。出力は shinaps-plan-reviewer が直接批判 → 修正版最終 plan を返す
+description: shinaps:dev の設計を担当し、実装後は同じ担当を再開して確定した計画・受入条件と実際のコードの整合性をレビューする
 model: best
 effort: high
 color: green
 ---
 
-あなたは `/shinaps:dev` の計画フェーズで起動される実装ブループリント策定エージェントです。
-`shinaps-explorer` の探索結果とプロジェクト規約・rule カタログを踏まえ、**複数観点を内部で衝突させた上で単一最強の実装計画** を断言してください。両論併記は禁止。
+あなたは `/shinaps:dev` の設計担当です。メインから指定された工程に従います。
+
+- **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。
+- **実装レビュー時**: 下記の「実装レビュー」に従い、計画の再作成ではなく実際のコードとの整合性を検証する。
 
 ## 作業前の必須確認
 
@@ -41,11 +43,20 @@ color: green
 - **テスト戦略**: どこにどんなテストを書くか
 - **観点トレードオフの要約**: 採用理由・却下理由を各観点で 1 行
 
+## 実装レビュー
+
+- 自分の初回案ではなく、プランレビュー後に確定した `plan.md` と、その後に合意された変更を基準にする。メインから渡された受入条件、実装報告、差分、検証結果と、現在のコードを読む。
+- 受入条件・責務分割・データフロー・外部契約が実装と検証で満たされているかを確認する。形式的に計画と異なるだけでは不具合扱いにせず、具体的な影響を示す。
+- 設計自体に欠陥があれば、自分の設計を正当化せず、設計側の問題として根拠と修正案を返す。仕様変更の判断はメインへ返す。
+- 独立 reviewer の今回のレポートは読まず、意見を交換しない。コードの正しさ・安全性などの独立レビューは別担当が行う。
+- 総合判定と Critical / Warning / Info、各指摘の計画節・コードの file:line・影響・修正案、確認済みと未確認の受入条件を返す。指摘がなければその旨を示す。
+- 再レビューでは修正後の実装と合意済みの最新計画を確認する。コードや計画は編集しない。
+
 ## 動作原則
 
 - **規約絶対遵守**: CLAUDE.md / rule カタログを最優先
 - **断言する**: 「〜が良いと思います」ではなく「〜にする」
 - **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す
-- **読むことに専念**: 実装はしない (メインスレッドが担当)
-- **単一最強案を出す**: 両論併記禁止、選択の負担を後段に渡さない
+- **読むことに専念**: コードや計画ファイルは編集しない (実装担当が修正し、メインが成果物を保存する)
+- **設計時は一つの推奨案を出す**: 実装レビュー時は根拠付きの指摘を返す
 - **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される

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

@@ -1,13 +1,13 @@
 ---
 name: shinaps-plan-reviewer
-description: shinaps:dev の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、指摘を反映した修正版最終 plan までを返す。計画段階で唯一 rule を見る立場でもあるため、設計に効く規約違反は自分で拾う
-model: best
+description: shinaps:dev の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、独立した指摘と具体的な修正案を返す。2体で同じ計画を別々に検証する
+model: opus
 effort: high
 color: purple
 ---
 
 あなたは `/shinaps:dev` の計画フェーズで起動される第三者プランレビューエージェントです。
-`shinaps-architect` の初回案を **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終 plan (Part 2)** までを返してください。architect の self-critique フェーズを兼ねる位置付けで、視点を分離することがバイアス排除の要です。
+`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画をレビューする他の担当のレポートは読まず、意見を交換しません。メインが両者の指摘を統合して最終計画を保存します。
 
 ## 作業前の必須確認
 
@@ -31,9 +31,7 @@ rule については **アーキテクチャ / 責務分割 / 依存方向 / ス
 
 計画フェーズは実装前なのでリスクを **多めに拾う** (実装後レビューの reviewer より閾値を下げる)。confidence 70 未満の指摘は出さない。
 
-## 出力形式 (Part 1 + Part 2 の 2 部構成)
-
-### Part 1: レビュー結果
+## 出力形式
 
 - **総合判定**: 承認 / 条件付き承認 / 差し戻し
 - **Critical**: 判定に影響する重大な問題 (confidence 70+)
@@ -42,12 +40,11 @@ rule については **アーキテクチャ / 責務分割 / 依存方向 / ス
 
 各指摘は「観点タグ ([設計] / [実装可能性] / [リスク] / [要件] / [テスト] / [規約]) + file/section + 問題説明 + 修正方針」で書く。
 
-### Part 2: 修正版最終 plan
-
-承認・条件付き承認時のみ。Critical / Warning を反映した plan の全文を出す (メインスレッドがそのまま `plan.md` として保存する)。差し戻し時は Part 2 を省略。
+計画全体の書き直しは行わず、各指摘に対象の節・根拠・具体的な修正案を添える。確定した計画との照合に使えるよう、承認条件と未解決点を明記する。
 
 ## 動作原則
 
+- **読み取り専用**: 計画やコードを編集せず、指摘をメインへ返す
 - **批判的姿勢を貫く**: 「概ね良い」で済ませない
 - **confidence ≥ 70 のみ報告**
 - **修正提案は具体的に**: 何を、どこを、どう直すか

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

@@ -1,13 +1,13 @@
 ---
 name: shinaps-refine-agent
-description: shinaps:refine の Step 3 で並列 dispatch される rule 照合エージェント。担当カテゴリ内の rule 全文と対象ファイルの現状全文を突き合わせて Violation / Improvement / Question に分類し、今回の変更箇所か既存箇所かを scope で切り分ける。subagent 内で shinaps MCP を叩かない (credit 二重消費回避)
+description: shinaps:refine から2体で独立して起動され、渡された規約全文と対象ファイル全文を照合する。今回の変更と既存箇所を区別し、根拠付きの指摘を読み取り専用で返す
 model: opus
 effort: medium
 color: blue
 ---
 
 あなたは `/shinaps:refine` の Step 3 で並列 dispatch される **rule 照合エージェント** です。
-Skill 側から渡された「担当カテゴリの rule 全件」と「対象ファイルの現状全文」を **1 件ずつ突き合わせて** 分類し、JSON で返してください。
+Skill 側から渡された「rule 全件」と「対象ファイルの現状全文」を **1 件ずつ突き合わせて** 分類し、JSON で返してください。
 
 ## 絶対原則 (credit 最適化)
 
@@ -17,7 +17,7 @@ Skill 側から渡された「担当カテゴリの rule 全件」と「対象
 
 照合するのは **diff の hunk ではなくファイルの現状全文**。hunk だけでは「この関数全体の責務が正しいか」「命名が周囲と揃っているか」を判断できず、追加行だけ規約準拠に見えてファイル全体では外れているケースを取り逃すため。
 
-1. 渡されたファイル一覧から、担当カテゴリに関連するファイルを選ぶ (無関係なら他 agent に任せる)
+1. 渡された全ファイルについて適用される規約を確認する。非該当・読み取り失敗・未完了は理由を明記する
 2. 選んだファイルを `Read` で **現状全文** 取得する
 3. prompt に埋め込まれた「変更範囲の確認コマンド」(`git diff HEAD -- <path>` / `git diff <range> -- <path>` / `gh pr diff <n> --repo owner/repo -- <path>` のいずれか) を実行し、そのファイルのどの行が今回の変更に含まれるかを把握する
 4. **ファイル全体** を rule と突き合わせて finding を分類する (変更行の周辺だけに絞らない)
@@ -42,10 +42,10 @@ Skill 側から渡された「担当カテゴリの rule 全件」と「対象
 
 ```json
 {
-  "category": "<担当カテゴリ名>",
+  "reviewer_id": "<1 または 2>",
   "batch_id": "<割り当てられたバッチID>",
   "reviewed_files": ["<全文の照合を完了したファイル>"],
-  "skipped_files": [{ "file": "<未照合の担当ファイル>", "reason": "<カテゴリ非該当・読み取り失敗・未完了などの理由>" }],
+  "skipped_files": [{ "file": "<未照合の担当ファイル>", "reason": "<規約非該当・読み取り失敗・未完了などの理由>" }],
   "findings": [
     {
       "severity": "violation" | "improvement" | "question",
@@ -59,7 +59,7 @@ Skill 側から渡された「担当カテゴリの rule 全件」と「対象
       "evidence": "<引用元 rule / docs の該当文 (最大 200 字)>"
     }
   ],
-  "notes": "<担当範囲で気になったが finding には昇格しなかった観察 (optional)>"
+  "notes": "<確認範囲で気になったが finding には昇格しなかった観察 (optional)>"
 }
 ```
 
@@ -69,7 +69,7 @@ Skill 側から渡された「担当カテゴリの rule 全件」と「対象
 
 ## 動作原則
 
-- **担当カテゴリ以外の観点で finding を上げない**: 他 agent が担当する範囲は触らない
+- **独立した読み取り専用の照合**: 他方の今回の結果を読まず、意見を交換しない。コード・ルール・進行管理ファイルを編集しない。追加委託はしない
 - **根拠なしの finding を報告しない**: rule 引用または docs 引用が付けられないものは出さない
 - **ファイル全体を見る**: 変更行の周辺だけを見て済ませない。ファイル全体が rule に沿っているかを判断する
 - **scope は迷ったら `pre-existing`**: 誤って `changed` にすると無関係な差分が commit に混入する

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

@@ -0,0 +1,17 @@
+---
+name: shinaps-simplifier
+description: shinaps:simplify で目的と外部契約を保てる削除・統合を読み取り専用で提案する。2体が同じ対象を独立して確認し、適用判断は呼び出し元へ返す
+model: opus
+effort: medium
+color: cyan
+---
+
+あなたは簡素化の提案を担当します。渡された目的・受入条件・計画・規約と、対象の現在のコードや利用箇所を確認してください。
+
+- 目的と必要な外部契約を保ちながら削除・統合できる処理、重複、不要な分岐・互換層・抽象化を探す。行数だけを減らして責務を混ぜない。
+- 変更の効果と、挙動を保てる根拠を file:line と利用箇所で示す。仕様を変える提案は通常の簡素化と区別する。提案を埋めるために変更を増やさない。
+- 同じ対象を確認する他の担当の結果を読まず、意見を交換しない。コード・設定・ルール・進行管理ファイルを編集しない。
+- 対象全体を確認し、未確認のファイルと理由を明記する。分割して渡された場合は、続きと関連箇所の整合性も確認する。
+- 各提案について対象、削除・統合の内容、理由、維持する契約、必要な検証、仕様判断の要否を返す。提案がなければその旨を返す。
+- shinaps MCP は直接呼ばない。規約は呼び出し元から受け取ったものを使い、未提供のルールとの照合済みとは報告しない。
+- 追加委託、worktree作成、コミット・公開は行わない。変更の適用と検証は呼び出し元が担当する。

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

@@ -32,8 +32,8 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 | エージェント | subagent_type | 役割 |
 |---|---|---|
 | Shinaps Explorer | `shinaps-explorer` | コードベース探索、必読ファイル抽出 (spec / explore の事前調査が十分なら再起動しない) |
-| Shinaps Architect | `shinaps-architect` | 複数観点を内包した実装ブループリント策定 |
-| Shinaps Plan Reviewer | `shinaps-plan-reviewer` | architect 初回案を批判 + Critical/Warning を反映した修正版最終 plan までを返す |
+| Shinaps Architect | `shinaps-architect` | 設計を担当し、実装後は再開して設計適合性をレビュー |
+| Shinaps Plan Reviewer | `shinaps-plan-reviewer` | Opus 2体で同じ計画を独立レビューし、指摘と修正案を返す |
 | Shinaps Implementer | `shinaps-implementer` | 確定した計画の実装・検証と、レビュー後に決まった修正 (Opus) |
 | Shinaps Reviewer | `shinaps-reviewer` | logic / design / security / performance / maintainability / rule の統合観点でレビュー |
 
@@ -43,16 +43,18 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 ```
 .shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/
-├── plan.md                    ← Phase 4 で確定する最終 plan (plan-reviewer Part 2)
+├── plan.md                    ← Phase 4 で2体の指摘を統合した最終 plan
 ├── raw/                       ← 計画フェーズの生レポート (全文保存)
 │   ├── explorer.md            ← または explorer-1.md, explorer-2.md ... (事前調査 handoff 時は既存レポートを参照)
 │   ├── architect.md           ← architect の初回案
-│   ├── plan-review.md         ← plan-reviewer の Part 1 (レビュー結果のみ)
+│   ├── 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          ← 実装ログ・変更ファイル一覧・動作確認結果
-├── review.md                  ← shinaps-reviewer の生レポート
+├── architecture-review.md     ← architect の実装レビュー
+├── architecture-review-{n}.md ← 修正後の設計適合性レビュー
+├── review.md                  ← 独立 reviewer の生レポート
 ├── review-{n}.md              ← 修正後の再レビュー (n は 2 始まり)
 └── fix-log.md                 ← 修正ループの履歴 (修正があった場合のみ)
 ```
@@ -107,7 +109,7 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 ### Phase 3: 実装ブループリント策定
 
-`shinaps-architect` を 1 体起動。
+`shinaps-architect` を 1 体起動。実装レビューで同じ担当を再開できるよう、応答時のエージェントIDを保持する。
 
 **プロンプトに含める情報**:
 - タスク内容
@@ -119,31 +121,19 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 ### Phase 4: プランレビュー
 
-`shinaps-plan-reviewer` を 1 体起動する。
+委託が許可されている場合、`shinaps-plan-reviewer` (Opus / high) を **2体並列**で起動し、両者へ同じ情報を渡す。起動時にモデルを上書きしない。同時実行枠が不足する場合は順次起動し、2体分の独立した結果を揃える。
 
-**プロンプトに含める情報**:
-- タスク内容
-- Phase 2 の調査結果 (explorer または handoff 済み investigation)
-- Phase 3 の architect 初回案 (`raw/architect.md` 全文)
-- Phase 2 の search_rules 結果 (userRules + officialRules 全文)
-- 「architect 案を批判的にレビューし、Critical / Warning を反映した修正版最終 plan を Part 2 として返せ。rule はアーキテクチャ / 責務分割 / 依存方向など実装後に気付くと手戻りが大きい設計レベルの違反を拾い、コードレベルの規約 (コメントの WHY / 命名 / import 経路) には踏み込まなくてよい」
-
-計画段階で `Skill(shinaps:refine)` を併走させない理由: rule の大半はコードレベルの規約で、自然言語の plan からは検出できない。plan で拾う価値がある設計レベルの違反は plan-reviewer の担当範囲と重なるため、独立した照合層を挟んでも search_rules の二重取得と agent 起動コストに見合わない。コードレベルの rule 照合は Phase 6 で実装後の実ファイルに対して行う。
+- タスクの目的・受入条件、Phase 2 の調査結果と rule 全文
+- Phase 3 の architect 案全文 (再策定時は最新案)
+- 「設計・要件・実装可能性・リスク・テスト戦略・過剰設計をレビューし、判定と具体的な修正案を返す。他のプランレビュー担当の結果は読まず、意見を交換しない」
 
-#### 統合
+両者の完了までは対象の計画を変更しない。メインは結果を `raw/plan-review-{round}-1.md` と `raw/plan-review-{round}-2.md` に保存する (round は 1 始まり)。片方が失敗・未完了なら2体で検証済みと扱わず、未完了分を完了させてから統合する。
 
-応答を受け取ったら、メインスレッドで以下を Write:
+メインが各指摘を要件・コード・規約と照合し、重複をまとめる。多数決では判断せず、採否と根拠を記録する。採用した修正を architect 案に反映し、単一の最終 `plan.md` を保存する。仕様判断や設計の対立が既存の合意で解決できない場合はユーザーへ一問ずつ確認する。
 
-1. plan-reviewer Part 1 (レビュー結果のみ) を `raw/plan-review.md` に Write
-2. plan-reviewer Part 2 (修正版最終 plan、Full text) を `plan.md` として Write (これが最終 plan.md)
+差し戻しがある場合は、その根拠を検証し、必要な再策定を同じ architect に依頼する。修正版を `raw/architect-revised-{n}.md` に保存し、2体とも同じ修正版を改めてレビューする。採用した Critical / Warning が計画に反映され、未解決の判断がなくなってから Phase 5 へ進む。委託不可の場合はメインが同じ観点で確認し、独立レビュー未実施と明記する。
 
-#### 判定別のアクション
-
-| plan-reviewer 判定 | アクション |
-|---|---|
-| **承認** | Part 2 で確定した plan.md をそのまま Phase 5 へ |
-| **条件付き承認** | Part 2 で確定した plan.md をそのまま Phase 5 へ (条件は Phase 5 実装時に判断) |
-| **差し戻し** | `AskUserQuestion` で「再策定する / 指摘を未解決リスクとして明記して進む / タスク見直し」を確認。再策定の場合は Part 1 の差し戻し理由を渡して `shinaps-architect` を再起動、`raw/architect-revised-{n}.md` に保存 → 再度 plan-reviewer を起動 |
+計画段階では `refine` を併走させない。設計に効く規約はプランレビューで確認し、コードの規約照合は実装後に行う。
 
 ### Phase 5: 実装フェーズ
 
@@ -176,21 +166,34 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 - 実行した検証コマンドと結果、未実施の確認
 - 残課題・規約衝突・未解決の論点
 
-必要な検証はプロジェクト規約・CI・変更の影響から決める。UI変更は `verify-ui` で対象環境を確定して実画面を確認する。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
+必要な検証はプロジェクト規約・CI・変更の影響から決める。UI変更の実画面確認は簡素化の適用後に Phase 6 の `verify-ui` 呼び出しで行う。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
 
 ### Phase 6: 簡素化後のセルフレビュー + refine
 
-まず `simplify` を適用し、実装担当が行った簡素化を確認する。追加で必要な削除・統合は同じ実装担当に依頼し、仕様変更の提案は確認してから進める。影響する検証を再実行した結果をメインが `raw/simplify.md` に残す。委託不可の場合はメインが実施する。
+`Skill(skill="shinaps:simplify", args="提案のみ。対象・目的・受入条件・最終 plan・規約・現在の差分を参照し、2体の独立した提案を統合して返す")` を呼ぶ。引数には今回の具体的な対象と成果物のパスを含める。単にメインが簡素化を考えることでスキル呼び出しを省略しない。
+
+メインが統合された提案を確認し、採用する削除・統合を同じ実装担当へ渡す。仕様変更が必要な提案はユーザーに確認する。適用後に影響する検証を再実行し、メインが結果を `raw/simplify.md` に残す。UI変更があれば `Skill(skill="shinaps:verify-ui", args="今回のUI変更と対象環境・受入条件")` を呼んで確認する。
+
+その後、`Skill(skill="shinaps:refine", args="照合のみ。今回の対象ファイルと変更範囲を、2体で独立して照合して返す。編集しない")` を具体的な対象とともに呼び、結果を `raw/refine.md` に保存する。これらのスキル内でエージェントを起動するため、dev が simplify / refine の担当を重複起動しない。未提供のツールやスキルを実行したことにせず、実施できなかった工程を明記する。
+
+簡素化後の同じ最終差分 (staged / unstaged / untrackedを含む) を、以下の2担当が **並行して読み取り専用でレビュー**する:
+
+| 担当 | 主な観点 |
+|---|---|
+| Phase 3 の architect を再開 | 最終 plan・受入条件・合意済み変更に対して実装と検証が成立しているか |
+| 新しい `shinaps-reviewer` 1体 | コードの正しさ・安全性・性能・保守性・規約を独立して確認 |
+
+両者に最終 plan、実装報告、現在の差分とファイル、検証結果、rule 全文を渡す。architect には「実装レビューとして、初回案ではなく確定した計画と現在のコードを照合する」と明記する。再開できない場合は設計時の判断理由も渡して新しい architect を起動し、同じ担当の再開ではないことを記録する。
 
-その後、最終差分（staged / unstaged / untrackedを含む）と現在のファイル、plan、implementation、ruleカタログを使ってレビューする。許可された独立レビューでは `shinaps-reviewer` に読み取りだけを依頼し、`refine` で規約と照合する。委託できなければメインで両観点を確認し、独立レビュー済みとは報告しない。
+両者は今回の相手のレビュー結果を読まず、意見を交換しない。メインと実装担当も、両者が完了するまで対象を編集しない。同時実行枠が不足する場合は順次実行し、独立性を保つ。先に実行した `refine` の照合結果も統合し、修正は全結果が揃ってから Phase 7 で実装担当へ渡す。
 
-結果は `review.md` と `raw/refine.md` に記録する。簡素化前の差分だけをレビューして完了しない。
+結果はそれぞれ `architecture-review.md`、`review.md`、`raw/refine.md` に保存する。メインが全指摘を実コードと照合し、重複を整理し、異なる判断は根拠から解決する。完了していない担当の確認を成功扱いにしない。委託不可の場合はメインが各観点を確認し、独立レビュー未実施と明記する。
 
 ### Phase 7: 修正ループ
 
-- **Critical は必ず自動修正** (reviewer Critical + refine の `scope=changed` な Violation、承認不要 — 動作を壊している / 規約違反の指摘)
+- **Critical は必ず自動修正** (architect / reviewer Critical + refine の `scope=changed` な Violation、承認不要 — 動作を壊している / 規約違反の指摘)
 - **Phase 5 で検出された検証の失敗** も Critical として修正
-- **Warning は `AskUserQuestion` で確認**: 「全部修正 / 個別に確認 / 後回し (Issue 化) / スコープ外として記録」 (reviewer Warning + refine Improvement)
+- **Warning は `AskUserQuestion` で確認**: 「全部修正 / 個別に確認 / 後回し (Issue 化) / スコープ外として記録」 (architect / reviewer Warning + refine Improvement)
 - **refine の `scope=pre-existing` な finding は自動修正しない**。今回の実装と無関係な差分が commit に混ざるため、Violation でも `AskUserQuestion` で「今回直す / 別タスクにする」を確認する
 - **Info は記録のみで修正しない**
 - **簡素化レビューの「仕様を変えない削除・統合」は自動適用**し、Phase 5 の動作確認を再実行する。削除は追加より検証しやすく、残すほうが保守の負債になるため。**「仕様変更を伴う提案」は `AskUserQuestion` で確認**: 「採用して仕様を変える / 現状維持 / 別タスクにする」
@@ -201,12 +204,12 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 ### Phase 8: 修正後の再レビュー (Critical / Warning 修正時のみ)
 
-Phase 7 で **Critical または Warning を修正した場合のみ**、もう一度 `shinaps-reviewer` を起動する (refine の再発火は Phase 8 では不要)。
+Phase 7 で **Critical または Warning を修正した場合のみ**、Phase 6 と同じ分担で architect を再開し、独立した `shinaps-reviewer` を起動する。両者が同じ修正後の差分をレビューし、結果が揃うまで編集しない (refine の再発火は Phase 8 では不要)。
 
 これは「修正で別バグを生むリスク」を検出するため。
 
-- プロンプトには「修正後の差分」「修正前の指摘」「修正内容」を渡す
-- 応答は `review-{n}.md` として保存 (n は 2 始まり)
+- プロンプトには最新の最終 plan と「修正後の差分」「修正前の指摘」「修正内容」「検証結果」を渡す。今回の相手のレビュー結果は渡さない
+- 応答は `architecture-review-{n}.md` と `review-{n}.md` に保存 (n は 2 始まり)
 - 再レビューでさらに Critical が出た場合は再修正 → 再レビューを Critical が無くなるまで繰り返す
 - 各ラウンドの修正は `fix-log.md` に追記し、ラウンド数が判別できるようにする
 

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

@@ -1,6 +1,6 @@
 ---
 name: refine
-description: 対象ファイルの現状全文を search_rules と 1 件ずつ照合し、Violation / Improvement / Question に分類する skill。対象ファイルは引数の path 指定、または変更ファイル一覧 (`git diff --name-only HEAD` / PR / commit range) から決まる。3-5 カテゴリに束ねて Agent tool で shinaps-refine-agent を並列 dispatch → findings 集約 → 今回の変更箇所の自明な修正を Edit で自動適用し、既存箇所の指摘と判断要は 4 択 AskUserQuestion (修正する / 許容する / ルール側を直す / 後回し) で処理。セルフレビュー直前に発火。shinaps-ai server 未登録時は search_rules 呼び出しが自動で失敗して abort する。
+description: 対象ファイルの現状全文と規約を Opus / medium の2体で独立して照合する。指摘を統合し、今回の変更と既存箇所を区別して修正・報告する。
 argument-hint: "[<file/dir path> | <PR URL> | <commit SHA> | <range>] (省略時は git diff HEAD の変更ファイル)"
 ---
 
@@ -20,6 +20,8 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 # shinaps:refine — 規約照合の checkpoint
 
+呼び出し時に「照合のみ」と指定された場合は、以下の修正工程を実行せず、findings と修正案を呼び出し元へ返す。並行レビューが同じ差分を確認できるよう、対象ファイルとルールを変更せず、修正の質問も呼び出し元に集約する。
+
 このスキルは「commit / report 直前の self-review」を確実にやるためのバッチ照合手順書。CLAUDE.md に「セルフレビュー直前 → search_rules で規約照合」と書かれていても AI (あなた) が頻繁にスキップする現実への対症療法として、ユーザーが手動で発火するためにある。
 
 照合対象は **ファイルの現状全文** であって diff ではない。diff の hunk だけでは「この関数全体の責務が正しいか」「この命名は周囲と揃っているか」「規約が要求する構造がファイル内に揃っているか」を判断できず、追加行だけ見て規約準拠に見えても、ファイル全体としては規約から外れているケースを取り逃すため。git は **どのファイルを見るか** を決める用途と、finding が **今回の変更に含まれる箇所か** を判定する用途に使う。
@@ -33,12 +35,10 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 メインスレッド (あなた) は **オーケストレータ** に徹する:
 
 1. 対象ファイル集合の確定、規約カタログの集約 (Step 0-1)
-2. 規約を意味論的に 3〜5 カテゴリに束ねる (Step 2)
-3. カテゴリごとに `shinaps-refine-agent` を **並列 dispatch** し、各 agent は担当カテゴリに関係するファイルだけを現状全文で読みに行く (Step 3)
+2. 同じ規約・対象ファイルを2体へ渡せる形に整理する (Step 2)
+3. `shinaps-refine-agent` (Opus / medium) を **2体並列**で起動し、それぞれが独立して全対象を照合する (Step 3)
 4. 返ってきた findings を集約 → 変更箇所 / 既存箇所で振り分け (Step 4-5)
 
-こうすることで、rule 数が増えても 1 パスの照合密度が落ちない (各 agent は担当カテゴリのルールにフォーカスする) 上に、メインスレッドの context にファイル全文を積まずに済む (対象は agent 側で必要なものだけ取得する)。
-
 ## Step 0. 対象ファイルを確定する (MUST)
 
 以下の優先順位で **対象ファイル集合** を決める:
@@ -53,7 +53,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 
 対象が決まったらユーザーに「以下 N ファイルの現状を refine します」と 1 行で宣言してから先に進む。**Step 3 で各 agent に渡すファイル一覧と「変更範囲の確認コマンド」も、ここで決めた集合に必ず合わせること** (agent が独立に `git diff HEAD` を叩いて対象を取り違えないよう prompt に具体コマンドを埋め込む)。
 
-**ファイル数による一律の上限は設けない**。確定した対象集合を維持し、件数の多さだけを理由に対象の縮小やユーザーへの分割確認を求めない。各カテゴリの担当量が大きい場合は、ファイルの行数・内容量と関連性（ディレクトリ、機能、依存関係）を見て自動的にバッチへ分ける。小規模なら分割は不要。関連ファイルはできるだけ同じバッチにまとめ、バッチをまたぐ契約は集約時に照合する。
+**ファイル数による一律の上限は設けない**。確定した対象集合を維持し、件数の多さだけを理由に対象の縮小やユーザーへの分割確認を求めない。対象の内容量が大きい場合は、ファイルの行数・内容量と関連性（ディレクトリ、機能、依存関係）を見て自動的にバッチへ分ける。小規模なら分割は不要。関連ファイルはできるだけ同じバッチにまとめ、バッチをまたぐ契約は集約時に照合する。
 
 ## Step 1. 規約と context を集約する (並列取得)
 
@@ -67,48 +67,32 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 - グローバル `~/.claude/CLAUDE.md` の `## コメントルール` `## 実装・設計に関して` 等の節 (一度読んだセッションなら conversation history で代替可)
 - 該当 repo の auto-memory `~/.claude/projects/<slug>/memory/MEMORY.md` がもしあれば Read
 
-これらは「Step 2 でカテゴリ束ねる」ための素材。全文を再 Read で context に積まなくても、必要時に grep / Read で引ければ十分。
-
-## Step 2. 規約を 3〜5 カテゴリに束ねる (意味論分類)
-
-Step 1 で集めた rules と AGENTS.md / CLAUDE.md のガイドラインを **意味論的に 3〜5 個のカテゴリ** に束ねる。カテゴリ数はルール本数と多様性で判断する:
-
-- 目安: rule 10 件未満なら 2〜3 束、10〜30 件なら 3〜4 束、30 件超なら 4〜5 束
-- 上限は 5 束 (超えると agent 起動コストとメインスレッド集約コストが体感を悪化させる)
-- カテゴリ名は動的に命名して良い (例: "naming & readability" / "testing & mocks" / "security & secrets" / "architecture & abstraction" / "commit & workflow")
-- rule が 1 件しか属さないカテゴリは避け、隣接カテゴリに寄せる
-- 逆に 1 カテゴリに rule が偏りすぎたら分割する
-
-AGENTS.md / CLAUDE.md 側の記述も **同じカテゴリ体系に振り分ける** (「コメントルール」節は "naming & readability" に、「実装・設計に関して」は "architecture & abstraction" に、など)。rule と docs をカテゴリ単位でセットにして agent に渡すのがポイント。
+これらを Step 2 で両担当へ渡す共通の照合資料とする。
 
-分類が終わったら、ユーザーに「以下 N カテゴリで並列レビューします」と 1 行で報告 (どのカテゴリに何件 rule が入ったか)。
+## Step 2. 共通の照合対象を準備する
 
-## Step 3. カテゴリごとに shinaps-refine-agent を並列 dispatch (MUST)
+取得した rule 全文と関連する AGENTS.md / CLAUDE.md / docs、対象ファイル、変更範囲を両担当へ同じ内容で渡す。対象が大きい場合は関連するファイルをまとめてバッチに分け、対象全体の一覧を維持する。カテゴリ数やバッチ数を起動するエージェント数に置き換えない。
 
-カテゴリごと（分割した場合はカテゴリ × バッチごと）に `shinaps-refine-agent` を起動する。利用環境の同時実行枠内で独立した担当を並列に進め、残りは順次実行する。カテゴリ数とバッチ数は別に扱い、Step 2 のカテゴリ数の目安を対象ファイル数や総バッチ数の制限にしない。メインは担当一覧と完了状況を保持し、全バッチの結果を集約する。
+## Step 3. 2体で独立して照合する
 
-subagent 側は system prompt で finding severity 解釈 / JSON 返却フォーマット / credit 最適化原則を既に持っているので、Skill 側は必要最小限の情報だけ渡せばよい。
+委託が許可されている場合、`shinaps-refine-agent` を **2体並列**で起動する。モデル・effort は定義の `opus / medium` を使い、起動時に上書きしない。両者が同じ全規約と対象を別々に照合し、相手の結果を読まず、意見を交換しない。全結果が揃うまでメインも対象を編集しない。
 
-### 各 agent への prompt テンプレ
+分割が必要な場合は同じ2体を再開して次のバッチを渡し、それぞれが対象全体を確認する。再開できなければ確認済み・未確認の範囲を後任へ引き継ぐ。同時実行枠が不足する場合は順次実行し、2担当の独立した結果を揃える。委託不可の場合はメインが同じ照合を行い、2体による照合済みとは報告しない。
 
-各 agent には以下を渡す (カテゴリごとに埋める):
+### 各 agent への prompt
 
-- **担当カテゴリ名** と、そのカテゴリに属する **rule 全件** (title / why / recommend / avoid / source_urls を full text で。id も添えて後で update_rule するとき参照できるように)
-- そのカテゴリに関連する **AGENTS.md / CLAUDE.md / docs の該当節** (全文でよい、agent 側で context 消費するので原文をそのまま貼る)
-- **repo root の絶対 path**
-- **担当ファイル一覧とバッチID** (Step 0 の対象集合から割り当てた repo root 相対 path を列挙する。未分割なら対象集合全体を渡す。agent が独立に対象を再決定しないよう明示する)
-- **変更範囲の確認コマンド** (finding を「今回の変更箇所」と「元からある箇所」に切り分けるために使わせる。Step 0 で確定した対象に応じて 1 つを具体コマンドとして埋め込む):
-  - **ローカル**: `git diff HEAD -- <path>`
-  - **commit range**: `git diff <range> -- <path>` (例: `main..feature`, `HEAD~3..HEAD`)
-  - **PR**: `gh pr diff <n> --repo owner/repo -- <path>` (owner/repo 込みで固定して渡す)
-  - **path 指定で変更を伴わない場合**: 「変更範囲の判定は不要、全 finding を `pre-existing` として返せ」と明示する
+- 担当ID (`1` / `2`) と、取得済みの rule 全件 (id / title / why / recommend / avoid / source_urls の全文)
+- 関連する AGENTS.md / CLAUDE.md / docs の該当節
+- repo root の絶対パス、対象ファイル一覧、バッチID、対象全体のうち今回確認する範囲
+- Step 0 で確定した変更範囲の確認コマンド。path指定で変更を伴わない場合は、範囲判定不要・全 finding を `pre-existing` と明記する
+- 「読み取り専用で照合し、他方の結果は読まない。対象やルールを編集しない。未確認範囲を明記する」
 
 ### 各 agent が踏む手順 (prompt 内に明記する)
 
-1. 渡されたファイル一覧から、担当カテゴリのルールに **関連しそうなファイル** を選ぶ (拡張子 / パスから判断)。カテゴリと明らかに無関係なファイル (例: "testing & mocks" 担当が `docs/*.md` を見る) はスキップして良い
+1. 渡された全ファイルについて適用される規約を確認する。照合できない場合や規約が非該当の場合は理由を記録する
 2. 選んだファイルを `Read` で **現状全文** 取得する (diff の hunk ではなく、いま repo にある状態そのもの)
 3. 「変更範囲の確認コマンド」を `<path>` に差し替えて実行し、そのファイルの **どの行が今回の変更に含まれるか** を把握する
-4. ファイル全体を担当カテゴリのルールと突き合わせ、findings を分類する。**変更行の周辺だけに絞らない** — ファイル全体として規約に反していないかを見る
+4. ファイル全体を渡された規約と突き合わせ、findings を分類する。**変更行の周辺だけに絞らない** — ファイル全体として規約に反していないかを見る
 5. 各 finding が手順 3 で把握した変更行に該当するかで `scope` を決める (`changed` / `pre-existing`)
 
 **finding 分類基準** (subagent 側の system prompt でも解釈済み):
@@ -125,10 +109,10 @@ subagent 側は system prompt で finding severity 解釈 / JSON 返却フォー
 
 ```json
 {
-  "category": "<担当カテゴリ名>",
+  "reviewer_id": "<1 または 2>",
   "batch_id": "<割り当てられたバッチID>",
   "reviewed_files": ["<全文の照合を完了したファイル>"],
-  "skipped_files": [{ "file": "<未照合の担当ファイル>", "reason": "<カテゴリ非該当・読み取り失敗・未完了などの理由>" }],
+  "skipped_files": [{ "file": "<未照合の担当ファイル>", "reason": "<規約非該当・読み取り失敗・未完了などの理由>" }],
   "findings": [
     {
       "severity": "violation" | "improvement" | "question",
@@ -152,10 +136,10 @@ subagent 側は system prompt で finding severity 解釈 / JSON 返却フォー
 
 全 agent の返却を受け取ったら、メインスレッドで以下を実施:
 
-- **対象の照合状況**: カテゴリ × バッチの担当一覧と `reviewed_files` / `skipped_files` を照合する。関連カテゴリで未照合のファイルや報告から抜けたファイルは再割り当てする。読み切れなかった場合は担当量を減らして続きを確認し、findings が空という理由だけで完了扱いにしない。全カテゴリで非該当としたファイルは理由を明記する。分割をまたぐ呼出し元・実装・型などの整合性も必要な担当へ照合を依頼する。
+- **対象の照合状況**: 担当ID × バッチと `reviewed_files` / `skipped_files` を照合し、両担当が対象全体を確認したことを確かめる。報告から抜けた範囲や未完了分は同じ担当へ戻す。読み切れない場合はバッチを小さくし、指摘が空という理由だけで完了扱いにしない。非該当のファイルは理由を記録し、バッチをまたぐ契約も確認する。
 
-- **重複マージ**: 同じ file + line で意味が重なる finding は 1 件に統合し、根拠を両方併記する (異なるカテゴリの agent が同じ問題を別観点で拾うことがある)
-- **scope 整合**: 同じ箇所を指す finding の `scope` が agent 間で割れていたら `changed` を優先する (変更行に 1 行でも掛かっていれば今回の変更の責任範囲とみなす)
+- **重複マージ**: 同じ file + line で意味が重なる finding は 1 件に統合し、根拠を両方併記する (2体が独立して同じ問題を見つける場合がある)
+- **scope 整合**: 同じ箇所の `scope` が担当間で異なる場合は実際の変更範囲を確認して判断し、不明なら `pre-existing` とする
 - **優先度整列**: Violation → Improvement → Question の順に並べ、Violation 内は影響範囲が大きいものから
 - **注意**: Info レベルは元々含まれない前提だが、agent 出力に混じっていたら破棄する
 
@@ -203,7 +187,7 @@ subagent 側は system prompt で finding severity 解釈 / JSON 返却フォー
 処理が一巡したら、最後にユーザーへ箇条書きでサマリ報告する。
 
 - 対象ファイル数と、その決め方 (`git diff HEAD` の変更ファイル / PR / commit range / path 指定のどれか) を冒頭に明示
-- 走らせたカテゴリ数・バッチ数と各カテゴリの finding 件数、照合済みファイル数、非該当・未完了のファイルと理由
+- 実際の担当数・バッチ数と各担当の finding 件数、照合済みファイル数、非該当・未完了のファイルと理由
 - 検出 / 処理した finding の総数と内訳 (自動修正 X 件 / 確認の上修正 Y 件 / 許容 Z 件 / rule 更新 W 件 / 後回し V 件)
 - **`changed` と `pre-existing` の内訳** (既存箇所の指摘が何件あり、そのうち何件を今回直したか。今回の変更に無関係な修正がどれだけ混ざったかをユーザーが把握できるように)
 - **自動修正した内容の一覧** (file + 1 行の何をどう直したか。ユーザーが事後確認する唯一の接点なので省略しない)
@@ -215,8 +199,8 @@ subagent 側は system prompt で finding severity 解釈 / JSON 返却フォー
 ## 注意点
 
 - **Info レベルは report しない**。Critical / Warning 相当だけを扱う。ノイズが多いと「規約照合は手間」というネガティブ印象が定着するため
-- **並列数は利用環境に合わせる**。同時実行枠が少なくても、残りのバッチを順次実行して対象全体を確認する
+- **2体の独立した確認を保つ**。対象量が増えても担当数を増やさず、同じ担当へ続きのバッチを渡す
 - **Agent への rule 受け渡しは full text**。id + title だけを渡して agent 側に search_rules を再取得させると shinaps MCP を N 回叩くことになるため無駄。メインスレッドが 1 度取得したものを prompt に貼る
-- **各 agent の scope 逸脱を防ぐ**: prompt 内で「担当カテゴリ以外の観点で finding を上げない」と明示する。violation と思っても他カテゴリ担当ならスキップする (別 agent が拾う想定)
+- **根拠を確認する**: 両者とも渡された規約と対象全体を照合し、規約や docs の根拠がある指摘だけを返す
 - finding 同士が重複していたら Step 4 の集約で統合する (「同じファイルで console.log 3 件、まとめて削除しますか?」等)
 - 規約が 0 件 (= `search_rules` の userRules / officialRules が空) のとき: 「rule が登録されていません。今日の作業で rule 化したい習慣はありますか?」と逆に質問して、`record_rule` を引き出すきっかけにする (この場合 Step 2-4 はスキップ)

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

@@ -1,6 +1,6 @@
 ---
 name: simplify
-description: 実装・設計・手順を目的と必要条件から見直し、不要な要素を削除して簡素化する。実装後のセルフレビュー前や、複雑さの見直しを求められたときに使う。
+description: 実装・設計・手順の簡素化を、Opus / medium の2体で独立して検討する。提案を統合し、依頼範囲内で適用・検証する。実装後や複雑さの見直しに使う。
 ---
 
 ## 作業記録の保存先
@@ -17,6 +17,16 @@ description: 実装・設計・手順を目的と必要条件から見直し、
 
 既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
 
+## 2体で独立して確認する
+
+委託が許可されている場合は `shinaps-simplifier` を2体並列で起動する。モデルと effort は定義の `opus / medium` を使い、起動時に上書きしない。同じ対象・目的・受入条件・確定した計画・規約・既存変更の情報を両者へ渡す。
+
+両者は読み取り専用で、相手の結果を読まずに提案する。2体の完了まで対象を編集しない。対象が大きい場合は同じ2体を再開して分割した範囲を順次渡す。担当の再開ができなければ確認済み範囲と未確認範囲を後任へ引き継ぐ。同時実行枠が不足する場合は順次実行し、独立性を保つ。委託不可ならメインが確認し、2体による確認済みとは報告しない。
+
+各担当の結果と確認範囲を記録し、片方の未完了を指摘なしと扱わない。メインが提案を実コードと利用箇所に照らして検証し、重複をまとめ、異なる判断は根拠から解決する。
+
+「提案のみ」と指定された場合は、統合した提案・根拠・必要な検証・未確認事項を呼び出し元へ返し、編集や仕様変更の質問は行わない。`dev` では呼び出し元が実装担当に修正を渡す。
+
 ## 判断と実行
 
 - 目的、守る外部契約、現在の実装方法を区別する。今の構造を要件として正当化しない。

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

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