@shinaps/skills 0.14.0 → 0.15.0

package/README.md

@@ -142,7 +142,7 @@ 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 | 役割 |
 |---|---|
@@ -153,6 +153,7 @@ codex mcp login shinaps-ai
 | `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 は `best / high`、プランレビューは `opus / high` 2体、実装担当は `opus / medium` を使う。実装後は同じ architect の設計適合性レビューと、独立した reviewer (`opus / high`) のコードレビューを並行して行い、両者の結果が揃ってから修正する。メインは仕様判断・進行管理と実際の差分・検証結果の確認を担う。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.14.0",
+  "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.14.0",
+  "version": "0.15.0",
   "author": {
     "name": "shinaps",
     "email": "ryuta@shinaps.jp"

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

@@ -166,11 +166,15 @@ 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担当が **並行して読み取り専用でレビュー**する:
 
@@ -181,7 +185,7 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 両者に最終 plan、実装報告、現在の差分とファイル、検証結果、rule 全文を渡す。architect には「実装レビューとして、初回案ではなく確定した計画と現在のコードを照合する」と明記する。再開できない場合は設計時の判断理由も渡して新しい architect を起動し、同じ担当の再開ではないことを記録する。
 
-両者は今回の相手のレビュー結果を読まず、意見を交換しない。メインと実装担当も、両者が完了するまで対象を編集しない。同時実行枠が不足する場合は順次実行し、独立性を保つ。`refine` はこの差分の**照合のみ**を依頼し、自動修正を行わせない。修正は全結果の統合後、Phase 7 で実装担当へ渡す。
+両者は今回の相手のレビュー結果を読まず、意見を交換しない。メインと実装担当も、両者が完了するまで対象を編集しない。同時実行枠が不足する場合は順次実行し、独立性を保つ。先に実行した `refine` の照合結果も統合し、修正は全結果が揃ってから Phase 7 で実装担当へ渡す。
 
 結果はそれぞれ `architecture-review.md`、`review.md`、`raw/refine.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 の変更ファイル)"
 ---
 
@@ -35,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)
 
 以下の優先順位で **対象ファイル集合** を決める:
@@ -55,7 +53,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 
 対象が決まったらユーザーに「以下 N ファイルの現状を refine します」と 1 行で宣言してから先に進む。**Step 3 で各 agent に渡すファイル一覧と「変更範囲の確認コマンド」も、ここで決めた集合に必ず合わせること** (agent が独立に `git diff HEAD` を叩いて対象を取り違えないよう prompt に具体コマンドを埋め込む)。
 
-**ファイル数による一律の上限は設けない**。確定した対象集合を維持し、件数の多さだけを理由に対象の縮小やユーザーへの分割確認を求めない。各カテゴリの担当量が大きい場合は、ファイルの行数・内容量と関連性（ディレクトリ、機能、依存関係）を見て自動的にバッチへ分ける。小規模なら分割は不要。関連ファイルはできるだけ同じバッチにまとめ、バッチをまたぐ契約は集約時に照合する。
+**ファイル数による一律の上限は設けない**。確定した対象集合を維持し、件数の多さだけを理由に対象の縮小やユーザーへの分割確認を求めない。対象の内容量が大きい場合は、ファイルの行数・内容量と関連性（ディレクトリ、機能、依存関係）を見て自動的にバッチへ分ける。小規模なら分割は不要。関連ファイルはできるだけ同じバッチにまとめ、バッチをまたぐ契約は集約時に照合する。
 
 ## Step 1. 規約と context を集約する (並列取得)
 
@@ -69,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 でも解釈済み):
@@ -127,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",
@@ -154,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 出力に混じっていたら破棄する
 
@@ -205,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 行の何をどう直したか。ユーザーが事後確認する唯一の接点なので省略しない)
@@ -217,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.14.0",
+  "version": "0.15.0",
   "description": "Shinaps AIのCodex向け開発ワークフロー",
   "skills": "./skills/"
 }