npm - @shinaps/skills - Versions diffs - 0.14.0 → 0.16.0 - Mend

@shinaps/skills 0.14.0 → 0.16.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 (23) hide show

package/README.md CHANGED Viewed

@@ -20,12 +20,11 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 | `refine` | Shinaps AIのruleと実ファイルを照合する |
 | `extract-rules` | PRレビューからruleを抽出する |
 | `simplify` | 目的から見直して不要な構造や手順を削る |
-| `verify-ui` | 対象環境の実画面で見た目・操作を確かめる |
 | `commit` | 開始時に通常（推奨）・自律を確認し、検証できる単位へ分けてコミットする |
 | `create-pr` | リポジトリの規約に合わせてPRを作成する |
 | `release` | 公開条件を確定し、対象バージョンの利用可能性を確認する |
-`dev` は簡素化を適用した後の差分をレビューする。コミット・PR・リリースは依頼された場合だけ進む。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
+Claude版の `dev` は実装後にレビュー・規約照合・簡素化の提案を並行して集め、全結果を同じ architect が統合して実装担当へ修正を依頼する。実装後のレビューは最大2ラウンドで終了する。コミット・PR・リリースは依頼された場合だけ進む。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
 ## Claude Code
@@ -140,19 +139,20 @@ codex mcp add shinaps-ai --url https://app.shinaps.ai/mcp
 codex mcp login shinaps-ai
 ```
-未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`verify-ui`・`commit`・`create-pr`・`release` の基本手順はMCP接続を必須としない。
+未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`commit`・`create-pr`・`release` の基本手順はMCP接続を必須としない。
-## Subagents (Claude: 14 / Codex: 13)
+## Subagents (Claude: 15 / Codex: 13)
 | Subagent | 役割 |
 |---|---|
 | `shinaps-explorer` | コードベース探索、必読ファイル抽出 |
 | `shinaps-investigator` | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
-| `shinaps-architect` | 設計。Claude版では実装後に再開し、設計適合性もレビュー |
+| `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,11 +163,41 @@ 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 / medium`、プランレビューは `opus / medium` 2体、実装担当は `opus / medium` を使う。実装後は同じ architect の設計適合性レビューと、独立した reviewer (`opus / medium`) のコードレビューを並行して行い、両者の結果が揃ってから修正する。
+Claude版の `dev` は `review` (開発レビュー)・`refine`・`simplify` を Skill ツールで明示的に呼び、担当のバックグラウンド起動後に全結果を待つ。`simplify` と `refine` はそれぞれ Opus / medium の2体で同じ対象を独立して確認する。architect が提案・指摘を根拠から統合し、実装担当へ一つの修正指示を返す。メインは起動・待機・記録とユーザーへの確認を担う。実装後のレビューは初回と修正後の最大2ラウンドとし、2回目の修正後はテスト結果と残課題を報告する。最終修正が再レビューされていないことを明示し、重大な未解決事項を完了扱いにしない。UIレビューは別途Codex側で行う。
+Codex版は親モデルを継承する既存の構成を維持し、Claude専用の実装・簡素化担当は追加しない。
 **subagent 内では shinaps MCP を直接呼び出さず、rule 全文は Skill 側から prompt 経由で渡す** 原則を全 system prompt に明記する。MCP呼び出しの利用量が重複しないようにするため。
+## Claude版 dev の流れ
+全エージェントの effort は medium。architect は保持した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
+    J --> K{"修正が必要？"}
+    K -- いいえ --> N["検証結果・残課題を報告"]
+    K -- はい --> L["同じ implementer が修正・テスト"]
+    L --> M{"レビューを2回実施した？"}
+    M -- まだ1回 --> E
+    M -- 2回済み --> N
+```
 ## 作業成果物
 作業記録はプロジェクトルートの `.shinaps/work/` に保存する。初回作成時に `.shinaps/.gitignore` を内容 `*` と改行で作成する。既存のignoreは保持し、必要な場合だけ `*` を追記する。これによりignore自身を含む配下の未追跡ファイルが除外され、ユーザーによるグローバルignoreやプロジェクトルートのignore設定は不要になる。追跡済みファイルには効かないため、無断で追跡解除せず報告する。

package/package.json CHANGED Viewed

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

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

@@ -1,14 +1,16 @@
 ---
 name: shinaps-architect
-description: shinaps:dev の設計を担当し、実装後は同じ担当を再開して確定した計画・受入条件と実際のコードの整合性をレビューする
+description: shinaps:dev の設計・プラン指摘の統合・実装レビュー・全指摘の統合を同じ担当として行い、implementer への実装・修正指示を返す
 model: best
-effort: high
+effort: medium
 color: green
 ---
 あなたは `/shinaps:dev` の設計担当です。メインから指定された工程に従います。
 - **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。
+- **プラン統合時**: 2体のプランレビュー指摘を根拠から検証し、採否と修正版の最終計画を返す。
+- **指摘統合時**: 自分の実装レビュー完了後に全担当の結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
 - **実装レビュー時**: 下記の「実装レビュー」に従い、計画の再作成ではなく実際のコードとの整合性を検証する。
 ## 作業前の必須確認
@@ -48,15 +50,27 @@ color: green
 - 自分の初回案ではなく、プランレビュー後に確定した `plan.md` と、その後に合意された変更を基準にする。メインから渡された受入条件、実装報告、差分、検証結果と、現在のコードを読む。
 - 受入条件・責務分割・データフロー・外部契約が実装と検証で満たされているかを確認する。形式的に計画と異なるだけでは不具合扱いにせず、具体的な影響を示す。
 - 設計自体に欠陥があれば、自分の設計を正当化せず、設計側の問題として根拠と修正案を返す。仕様変更の判断はメインへ返す。
-- 独立 reviewer の今回のレポートは読まず、意見を交換しない。コードの正しさ・安全性などの独立レビューは別担当が行う。
+- 自分の実装レビューを返すまでは、今回の reviewer / refine / simplify の結果を読まず、意見を交換しない。自分の結果を確定した後、全担当が完了してから指摘統合へ進む。
 - 総合判定と Critical / Warning / Info、各指摘の計画節・コードの file:line・影響・修正案、確認済みと未確認の受入条件を返す。指摘がなければその旨を示す。
 - 再レビューでは修正後の実装と合意済みの最新計画を確認する。コードや計画は編集しない。
+## 全指摘の統合
+メインから「指摘統合」として、自分のレビュー、独立 reviewer、refine 2体、simplify 2体の全結果と最新の差分・検証結果を受け取る。
+- 各指摘・提案を要件・コード・規約と照合する。重複をまとめ、対立は多数決ではなく根拠から判断する。自分の初期設計も修正対象に含める。
+- すべての指摘・提案の採否と理由を記録する。未確認や担当の未完了を指摘なしとして処理しない。
+- 実装担当へ渡す一つの修正指示を返す。対象ファイル・責務、具体的な変更、維持する契約、必要な検証、修正の依存順を含める。指摘ごとに別々の修正担当を起動しない。
+- 合意済み仕様内の修正は判断して進める。仕様・受入条件の変更、権限や対象範囲の拡大が必要な判断だけ、理由と推奨案をメインへ返してユーザーに確認してもらう。
+- 実装後の全体レビューは初回と修正後の最大2ラウンド。2回目の指摘への最終修正・テストの後は3回目のレビューを要求せず、残課題と最終修正が再レビューされていないことを報告する。重大な未解決事項や検証失敗を完了扱いにしない。
+コード編集とエージェント起動は行わない。メインがあなたの指示を implementer へ渡し、結果を保存する。
 ## 動作原則
 - **規約絶対遵守**: CLAUDE.md / rule カタログを最優先
 - **断言する**: 「〜が良いと思います」ではなく「〜にする」
 - **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す
 - **読むことに専念**: コードや計画ファイルは編集しない (実装担当が修正し、メインが成果物を保存する)
-- **設計時は一つの推奨案を出す**: 実装レビュー時は根拠付きの指摘を返す
+- **工程に合わせて返す**: 設計・プラン統合時は最終計画、実装レビュー時は根拠付き指摘、指摘統合時は採否と実装担当への修正指示
 - **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される

package/plugins/shinaps-claude/agents/shinaps-debug-validator.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-debug-validator
 description: shinaps:debug 専用の仮説検証エージェント。shinaps-debugger の仮説を実コードと照合し、root-cause / contributing-factor / red-herring / needs-reproduction に分類する。修正方針は対症療法を排除し、根本解決を提示する
 model: opus
-effort: high
+effort: medium
 color: gray
 ---

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

@@ -2,7 +2,7 @@
 name: shinaps-debugger
 description: shinaps:debug 専用の根本原因調査エージェント。症状からコードを追跡し、WebSearch / GitHub Issue 検索で外部情報を収集し、根本原因の仮説を立案する。既存の調査・実装成果物と rule カタログを踏まえて仮説候補を予選する
 model: opus
-effort: high
+effort: medium
 color: magenta
 ---

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

@@ -2,7 +2,7 @@
 name: shinaps-investigator
 description: shinaps:explore の各質問ラウンドで起動される read-only 調査エージェント。人間の現在の疑問に絞ってコード、テスト、設定、git history、必要な公式情報を辿り、confirmed / inference / unknown を分離した根拠付き回答と次に有効な質問候補を返す
 model: opus
-effort: high
+effort: medium
 color: blue
 ---

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

@@ -2,12 +2,12 @@
 name: shinaps-plan-reviewer
 description: shinaps:dev の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、独立した指摘と具体的な修正案を返す。2体で同じ計画を別々に検証する
 model: opus
-effort: high
+effort: medium
 color: purple
 ---
 あなたは `/shinaps:dev` の計画フェーズで起動される第三者プランレビューエージェントです。
-`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画をレビューする他の担当のレポートは読まず、意見を交換しません。メインが両者の指摘を統合して最終計画を保存します。
+`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画をレビューする他の担当のレポートは読まず、意見を交換しません。設計担当の architect が両者の指摘を統合し、メインが最終計画を保存します。
 ## 作業前の必須確認

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

@@ -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-review-validator.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-review-validator
 description: shinaps:review 専用のレビュー妥当性検証エージェント。shinaps-reviewer の指摘を受け取り、該当コードを実際に Read して事実確認・妥当性検証を行う。false positive を排除し、見落としを追加発見する
 model: opus
-effort: high
+effort: medium
 color: orange
 ---

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

@@ -2,7 +2,7 @@
 name: shinaps-reviewer
 description: shinaps:dev のセルフレビューおよび shinaps:review の一次レビューを担当。実装後の差分を logic / design / security / performance / maintainability と rule 適合性の観点で網羅的にレビューし、Critical / Warning / Info で報告する
 model: opus
-effort: high
+effort: medium
 color: red
 ---

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

@@ -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/agents/shinaps-split-reviewer.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-split-reviewer
 description: shinaps:commit の Step 1 で起動される分割計画レビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の diff だけを読んで変更の妥当性を判断できるか (下限) / 一言で説明できる範囲か (上限) / 依存順 / 網羅性の観点で批判的にレビューし、指摘を反映した修正版最終分割計画までを返す。worktree は read-only で扱い、stash / add / checkout / Edit は一切行わない
 model: opus
-effort: high
+effort: medium
 color: blue
 ---

package/plugins/shinaps-claude/agents/shinaps-survey-validator.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-survey-validator
 description: shinaps-tech-surveyor のレポートを受け取り、出典 URL を WebFetch で再確認しながら情報の鮮度・出典の妥当性・主張の正確性を検証する。CLAUDE.md / rule カタログに反する候補は Critical で報告する
 model: opus
-effort: high
+effort: medium
 color: yellow
 ---

package/plugins/shinaps-claude/agents/shinaps-tech-surveyor.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-tech-surveyor
 description: shinaps:spec / shinaps:review / shinaps:debug で共有利用される外部技術調査エージェント。WebSearch / WebFetch で最新情報を集め、ライブラリ・フレームワーク・サービスを観点別に比較する一次レポートを作成する。既存スタック規約と rule カタログとの整合性を必ず評価対象に含める
 model: opus
-effort: high
+effort: medium
 color: teal
 ---

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

@@ -32,12 +32,12 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 | エージェント | subagent_type | 役割 |
 |---|---|---|
 | Shinaps Explorer | `shinaps-explorer` | コードベース探索、必読ファイル抽出 (spec / explore の事前調査が十分なら再起動しない) |
-| Shinaps Architect | `shinaps-architect` | 設計を担当し、実装後は再開して設計適合性をレビュー |
+| 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 の統合観点でレビュー |
-委託が許可されている場合、実装と修正は **`shinaps-implementer` (Opus) 1 体**が担当し、メインは仕様判断・進行管理・成果物の確認を担う。設計判断を実装へ引き継ぎつつモデルの利用を分けるため、確定した計画・判断理由・規約を実装担当へ渡す。委託不可またはエージェントを利用できない場合はメインが担当し、その旨を報告する。
+委託が許可されている場合、実装と修正は **`shinaps-implementer` (Opus) 1 体**が担当し、architect が設計判断と全指摘の統合を担い、メインはスキル呼び出し・エージェントの起動と再開・待機・記録・ユーザーへの確認を担う。設計判断を実装へ引き継ぎつつモデルの利用を分けるため、確定した計画・判断理由・規約を実装担当へ渡す。委託不可またはエージェントを利用できない場合はメインが担当し、その旨を報告する。
 ## ディレクトリ規約
@@ -109,7 +109,7 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 ### Phase 3: 実装ブループリント策定
-`shinaps-architect` を 1 体起動。実装レビューで同じ担当を再開できるよう、応答時のエージェントIDを保持する。
+`shinaps-architect` を 1 体起動。応答時のエージェントIDを保持し、プラン統合・実装レビュー・指摘統合で同じ担当を再開する。implementer が作業する間もIDと文脈を保持し、architect を破棄しない。再開できない場合だけ設計判断・最新計画・過去の指摘と採否を後任に引き継ぎ、その旨を記録する。
 **プロンプトに含める情報**:
 - タスク内容
@@ -121,7 +121,7 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 ### Phase 4: プランレビュー
-委託が許可されている場合、`shinaps-plan-reviewer` (Opus / high) を **2体並列**で起動し、両者へ同じ情報を渡す。起動時にモデルを上書きしない。同時実行枠が不足する場合は順次起動し、2体分の独立した結果を揃える。
+委託が許可されている場合、`shinaps-plan-reviewer` (Opus / medium) を **2体並列**で起動し、両者へ同じ情報を渡す。起動時にモデルを上書きしない。同時実行枠が不足する場合は順次起動し、2体分の独立した結果を揃える。
 - タスクの目的・受入条件、Phase 2 の調査結果と rule 全文
 - Phase 3 の architect 案全文 (再策定時は最新案)
@@ -129,7 +129,7 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 両者の完了までは対象の計画を変更しない。メインは結果を `raw/plan-review-{round}-1.md` と `raw/plan-review-{round}-2.md` に保存する (round は 1 始まり)。片方が失敗・未完了なら2体で検証済みと扱わず、未完了分を完了させてから統合する。
-メインが各指摘を要件・コード・規約と照合し、重複をまとめる。多数決では判断せず、採否と根拠を記録する。採用した修正を architect 案に反映し、単一の最終 `plan.md` を保存する。仕様判断や設計の対立が既存の合意で解決できない場合はユーザーへ一問ずつ確認する。
+メインが同じ architect を「プラン統合」として再開し、2体の全指摘を渡す。architect が根拠を検証して重複・対立を整理し、採否と修正版の最終計画を返す。メインは結果を保存し、単一の `plan.md` を確定する。architect が仕様判断や範囲拡大の相談を返した場合だけ、メインがユーザーへ一問ずつ確認して決定を戻す。
 差し戻しがある場合は、その根拠を検証し、必要な再策定を同じ architect に依頼する。修正版を `raw/architect-revised-{n}.md` に保存し、2体とも同じ修正版を改めてレビューする。採用した Critical / Warning が計画に反映され、未解決の判断がなくなってから Phase 5 へ進む。委託不可の場合はメインが同じ観点で確認し、独立レビュー未実施と明記する。
@@ -166,54 +166,47 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 - 実行した検証コマンドと結果、未実施の確認
 - 残課題・規約衝突・未解決の論点
-必要な検証はプロジェクト規約・CI・変更の影響から決める。UI変更は `verify-ui` で対象環境を確定して実画面を確認する。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
+必要な検証はプロジェクト規約・CI・変更の影響から決める。UIレビューはこの開発フローとは別に Codex 側で行う。未実施のUIレビューを完了と報告しない。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
-### Phase 6: 簡素化後のセルフレビュー + refine
+### Phase 6: review・refine・simplify を並行実行
-まず `simplify` を適用し、実装担当が行った簡素化を確認する。追加で必要な削除・統合は同じ実装担当に依頼し、仕様変更の提案は確認してから進める。影響する検証を再実行した結果をメインが `raw/simplify.md` に残す。委託不可の場合はメインが実施する。
+実装と必要な検証が終わった同じ差分を固定し、メインが次の3スキルを明示的に呼ぶ。各スキルは担当エージェントをバックグラウンド起動してIDを返し、メインが全体の起動・待機・記録を管理する。実装後のレビューラウンドは初回を1として数え、この依頼内で最大2回までとする。計画段階のプランレビューはこの回数に含めない。
-簡素化後の同じ最終差分 (staged / unstaged / untrackedを含む) を、以下の2担当が **並行して読み取り専用でレビュー**する:
-| 担当 | 主な観点 |
+| スキル呼び出し | 担当 |
 |---|---|
-| Phase 3 の architect を再開 | 最終 plan・受入条件・合意済み変更に対して実装と検証が成立しているか |
-| 新しい `shinaps-reviewer` 1体 | コードの正しさ・安全性・性能・保守性・規約を独立して確認 |
+| `Skill(skill="shinaps:review", args="開発レビュー、起動のみ。…")` | 設計した architect を再開 + 独立 reviewer 1体 |
+| `Skill(skill="shinaps:refine", args="照合のみ、起動のみ。…")` | Opus / medium 2体 |
+| `Skill(skill="shinaps:simplify", args="提案のみ、起動のみ。…")` | Opus / medium 2体 |
-両者に最終 plan、実装報告、現在の差分とファイル、検証結果、rule 全文を渡す。architect には「実装レビューとして、初回案ではなく確定した計画と現在のコードを照合する」と明記する。再開できない場合は設計時の判断理由も渡して新しい architect を起動し、同じ担当の再開ではないことを記録する。
+引数の省略部分には具体的な対象ファイル・変更範囲、最終 plan・受入条件・合意済み変更、実装報告、検証結果、規約・rule 全文と成果物のパスを渡す。review には設計担当のエージェントIDと設計判断も渡す。単独の review とは異なる開発レビューの手順を使い、外部調査や review-validator を追加起動しない。
-両者は今回の相手のレビュー結果を読まず、意見を交換しない。メインと実装担当も、両者が完了するまで対象を編集しない。同時実行枠が不足する場合は順次実行し、独立性を保つ。`refine` はこの差分の**照合のみ**を依頼し、自動修正を行わせない。修正は全結果の統合後、Phase 7 で実装担当へ渡す。
+先に起動した担当の完了を待ってから次のスキルを呼ぶのではなく、3スキルの担当を起動してから結果を待つ。dev 自身が同じ担当を重複起動しない。同時実行枠が足りなければ未起動分を記録して順次実行し、台数や確認範囲を黙って減らさない。ツールや委託が利用できなければその制約を明記し、独立確認済みと扱わない。
-結果はそれぞれ `architecture-review.md`、`review.md`、`raw/refine.md` に保存する。メインが全指摘を実コードと照合し、重複を整理し、異なる判断は根拠から解決する。完了していない担当の確認を成功扱いにしない。委託不可の場合はメインが各観点を確認し、独立レビュー未実施と明記する。
+全担当は読み取り専用で、今回の他担当の結果を読まず、意見を交換しない。メインと実装担当も全結果が揃うまで対象を編集しない。途中で外部の変更が入った場合は、その影響範囲を最新の同じ差分で確認し直してから統合する。
-### Phase 7: 修正ループ
+各スキルの確認範囲・未完了報告を確認し、未確認部分は同じ担当へ戻す。対象が大きい場合も継続または後任への引き継ぎで全対象を確認する。失敗・未完了を「指摘なし」として処理しない。
-- **Critical は必ず自動修正** (architect / reviewer Critical + refine の `scope=changed` な Violation、承認不要 — 動作を壊している / 規約違反の指摘)
-- **Phase 5 で検出された検証の失敗** も Critical として修正
-- **Warning は `AskUserQuestion` で確認**: 「全部修正 / 個別に確認 / 後回し (Issue 化) / スコープ外として記録」 (architect / reviewer Warning + refine Improvement)
-- **refine の `scope=pre-existing` な finding は自動修正しない**。今回の実装と無関係な差分が commit に混ざるため、Violation でも `AskUserQuestion` で「今回直す / 別タスクにする」を確認する
-- **Info は記録のみで修正しない**
-- **簡素化レビューの「仕様を変えない削除・統合」は自動適用**し、Phase 5 の動作確認を再実行する。削除は追加より検証しやすく、残すほうが保守の負債になるため。**「仕様変更を伴う提案」は `AskUserQuestion` で確認**: 「採用して仕様を変える / 現状維持 / 別タスクにする」
+自分のレビューを確定した architect と全担当の結果を保存する。初回は `architecture-review.md` / `review.md` / `raw/refine.md` / `raw/simplify.md`、2回目は各ファイル名に `-2` を付ける。全結果が揃った後で初めて同じ architect を「指摘統合」として再開し、自分のレビューを含む全結果・現在の差分・検証結果・ラウンド番号を渡す。独立レビュー中に他担当の結果を渡さない。
-修正を行った場合、`fix-log.md` に「指摘 → 修正内容 → 該当ファイル」を記録。修正判断も `fix-log.md` に残す。
+### Phase 7: architect が統合し、implementer が修正
-修正実装は Phase 5 の `shinaps-implementer` を再開して依頼する。メインは確定した指摘・修正判断・現在の差分・必要な再検証を渡す。再開できなければ Phase 5 の引き継ぎ情報と実装・修正履歴を新しい実装担当へ渡す。委託不可の場合はメインが修正する。大規模な再実装が必要な場合は、メインが「現行の計画で修正継続 / Phase 4 に戻って再策定」を確認する。
+architect が review・refine・simplify の全指摘を根拠から検証し、重複・対立を整理する。全指摘の採否と理由、採用した修正の対象・責務・具体的な変更・維持する契約・必要な検証を、一つの修正指示として返す。メインはそのまま記録し、仕様・受入条件の変更や未許可の範囲拡大が必要な点だけユーザーに確認する。通常の設計・修正判断をメインでやり直さない。
-### Phase 8: 修正後の再レビュー (Critical / Warning 修正時のみ)
+修正不要なら Phase 9 へ進む。修正があれば、メインが同じ `shinaps-implementer` を再開し、architect の修正指示・確定した計画・現在の差分・規約・検証条件を渡す。再開できなければ実装履歴と採否を新しい担当へ引き継ぐ。architect は次のレビューに備えて保持し、自分でコードを編集したり、実装担当を追加起動したりしない。
-Phase 7 で **Critical または Warning を修正した場合のみ**、Phase 6 と同じ分担で architect を再開し、独立した `shinaps-reviewer` を起動する。両者が同じ修正後の差分をレビューし、結果が揃うまで編集しない (refine の再発火は Phase 8 では不要)。
+implementer が修正と必要な検証を行い、変更・検証結果・未解決点を返す。メインは architect の採否と修正結果を `fix-log.md` に記録する。委託不可の場合はメインが同じ観点で対応し、独立した確認とは報告しない。
-これは「修正で別バグを生むリスク」を検出するため。
+### Phase 8: 最大2ラウンドで終了する
-- プロンプトには最新の最終 plan と「修正後の差分」「修正前の指摘」「修正内容」「検証結果」を渡す。今回の相手のレビュー結果は渡さない
-- 応答は `architecture-review-{n}.md` と `review-{n}.md` に保存 (n は 2 始まり)
-- 再レビューでさらに Critical が出た場合は再修正 → 再レビューを Critical が無くなるまで繰り返す
-- 各ラウンドの修正は `fix-log.md` に追記し、ラウンド数が判別できるようにする
+- **1回目のレビュー後に修正した場合**: 修正後の同じ差分について、Phase 6 の review・refine・simplify を2回目として並行実行する。最新の計画、前回の指摘と採否、修正内容、検証結果を渡す。全結果を同じ architect に集約し、Phase 7 で必要な最終修正を実施する。
+- **2回目のレビュー後に修正した場合**: implementer が最終修正と必要なテストを行ったら Phase 9 へ進む。3回目のレビュー・refine・simplify は起動しない。
+- **修正不要の場合**: 回数を埋めるために再実行せず Phase 9 へ進む。
-修正がなかった場合は再レビューをスキップして Phase 9 へ。
+最大2回は実装後の全体レビューに対する上限であり、担当の再開・差し替えや計画の変更でリセットしない。検証失敗・重大な未解決事項・未完了の担当が残る場合も追加ラウンドで無期限に続けず、その状態を明記してユーザーへ返す。未完了の確認を完了済みのラウンドと偽らない。
 ### Phase 9: 完了と必要なhandoff
-変更、簡素化、検証結果、未確認事項を報告する。コミットが明示されていれば、その許可範囲と通常／自律モードを `commit` へ引き継ぐ。コミット依頼がなければ未コミットのまま完了し、毎回コミット許可を要求しない。PRやリリースは明示された場合だけ、それぞれ `create-pr`・`release` へ進む。
+実施したレビュー回数、architect の判断と修正内容、検証結果、未解決事項を報告する。2回目の後に修正した場合は、その最終差分が再レビューされていないことを明記する。必須検証の失敗や重大な未解決事項があれば作業終了と品質上の完了を区別し、完了済みとは報告しない。コミットが明示されていれば、その許可範囲と通常／自律モードを `commit` へ引き継ぐ。コミット依頼がなければ未コミットのまま完了し、毎回コミット許可を要求しない。PRやリリースは明示された場合だけ、それぞれ `create-pr`・`release` へ進む。
 ## 動作原則
@@ -224,8 +217,8 @@ Phase 7 で **Critical または Warning を修正した場合のみ**、Phase 6
 - **判断・方針転換で ローカル成果物（implementation.md / 調査・レビューレポート）**
 - **目的・仕様を左右する不明点を確認**: 既存の指示で分かることや任された細部は再質問しない
 - **生レポート保存厳守**: explorer / handoff 済み investigation / architect / plan-reviewer / reviewer / refine の応答は全文参照可能な状態を保つ
-- **Critical は自動修正、Warning は確認**
-- **簡素化をレビュー前に実行する**: 目的を保つ削除を先に適用し、最終差分をレビューする
+- **architect が指摘の採否と修正方針を統合する**: 合意済み仕様内は任せ、仕様や許可範囲が変わる判断だけユーザーに確認する
+- **レビュー・規約照合・簡素化は同じ差分に並行して行う**: 全結果を統合してから実装担当が修正する
 - **plan からの逸脱は確認 + 記録**: AskUserQuestion で確認した上で `implementation.md` に経緯を残す
 - **コミットは明示依頼時のみ**: Phase 9 で既存の許可を引き継ぐ。

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

@@ -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,35 @@ 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 個のカテゴリ** に束ねる。カテゴリ数はルール本数と多様性で判断する:
+これらを Step 2 で両担当へ渡す共通の照合資料とする。
-- 目安: 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 が偏りすぎたら分割する
+## Step 2. 共通の照合対象を準備する
-AGENTS.md / CLAUDE.md 側の記述も **同じカテゴリ体系に振り分ける** (「コメントルール」節は "naming & readability" に、「実装・設計に関して」は "architecture & abstraction" に、など)。rule と docs をカテゴリ単位でセットにして agent に渡すのがポイント。
+取得した rule 全文と関連する AGENTS.md / CLAUDE.md / docs、対象ファイル、変更範囲を両担当へ同じ内容で渡す。対象が大きい場合は関連するファイルをまとめてバッチに分け、対象全体の一覧を維持する。カテゴリ数やバッチ数を起動するエージェント数に置き換えない。
-分類が終わったら、ユーザーに「以下 N カテゴリで並列レビューします」と 1 行で報告 (どのカテゴリに何件 rule が入ったか)。
+## Step 3. 2体で独立して照合する
-## Step 3. カテゴリごとに shinaps-refine-agent を並列 dispatch (MUST)
+`dev` から「起動のみ」と指定された場合は、以下の2担当をバックグラウンド起動し、担当名・エージェントID・対象範囲・未起動分を返す。結果待ち・不足範囲の再割り当て・記録は dev のメインが行う。各担当の結果を省略せず返し、全指摘の統合は同じ architect、修正は implementer が行う。起動済みを確認完了と報告しない。枠不足やバックグラウンド非対応の場合は実行可能な範囲を返し、dev が残りを順次進める。「起動のみ」がなければ、このスキル内で全結果を待って以下の統合手順まで行う。
-カテゴリごと（分割した場合はカテゴリ × バッチごと）に `shinaps-refine-agent` を起動する。利用環境の同時実行枠内で独立した担当を並列に進め、残りは順次実行する。カテゴリ数とバッチ数は別に扱い、Step 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 +112,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 +139,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 +190,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 +202,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/review/SKILL.md CHANGED Viewed

@@ -1,6 +1,6 @@
 ---
 name: review
-description: shinaps-reviewer + shinaps-review-validator で精度の高い単独レビューを行うスキル。差分・PR・既存コードを引数で切り替え。rule カタログとの照合を reviewer prompt に埋め込むことで、指摘の rule 起点タグ付けを bake する。確定指摘があればそのまま /shinaps:dev へ橋渡しして修正計画 + 実装まで進められる
+description: 差分・PR・既存コードをレビューする。単独実行では指摘検証と外部技術調査を行い、dev の開発レビューでは設計担当と独立 reviewer が同じ実装を確認する。
 argument-hint: <なし | PR番号 | ファイル/ディレクトリパス>
 ---
@@ -18,6 +18,21 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 別セッションへの委託・新しいworktreeは明示された許可がある場合だけ行う。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。独立レビューがプロジェクトの必須条件なら未完了として扱う。Shinapsのエージェント名はClaudeのpluginで公開された名前を使う。サービスのrule照合が必要な工程でMCPを利用できなければ、その工程を未確認として報告し、照合済みとしない。
+## dev からの開発レビュー
+引数に「開発レビュー」と指定された場合は、この節だけを実行し、以下の単独レビューの引数判定・外部調査・review-validator・devへの引き継ぎは実行しない。
+呼び出し元から対象ファイルと差分 (staged / unstaged / untracked を含む)、最終 plan・受入条件・合意済み変更、実装報告と検証結果、rule 全文、設計担当のエージェントIDと設計判断の理由を受け取る。
+- **設計適合性**: 設計した `shinaps-architect` を再開し、初回案ではなく確定した plan と現在のコード・検証を照合するよう依頼する。再開できなければ設計判断を引き継いだ新しい architect を使い、その旨を記録する。
+- **独立レビュー**: 新しい `shinaps-reviewer` 1体へ、コードの正しさ・安全性・性能・保守性・規約の確認を依頼する。
+両者へ同じ対象を渡し、読み取り専用で並行して確認する。今回の他担当の結果を読ませず、意見を交換させない。全担当が完了するまで対象を編集しない。モデルと effort は各エージェント定義を使う。
+「起動のみ」と指定された場合は、対応する実行環境で両担当をバックグラウンド起動し、担当名・エージェントID・対象範囲・未起動分を返す。結果待ちと記録は dev のメイン、全指摘の統合は同じ architect、修正は implementer が行う。起動済みをレビュー完了と報告しない。枠不足やバックグラウンド非対応なら実行可能な範囲を返し、dev が残りを順次進める。委託不可の場合はその制約を返す。
+起動のみでない場合は両者の完了を待ち、結果と確認範囲を呼び出し元へ返す。指摘の修正は行わない。再レビューでは最新の計画・修正差分・前回の指摘・修正内容・検証結果を使い、今回の結果が揃うまで同じ独立性を保つ。
 ## 引数仕様
 | 呼び出し | モード | 動作 |

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

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

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

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

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

@@ -9,7 +9,7 @@ description: プロジェクトの既存設計と条件を確認し、計画・
 2. Shinaps AIのルール検索が利用できれば、リポジトリと変更領域に関係するルールを取得する。使えない場合はルール照合未確認として明記し、可能な実装を進める。
 3. 複雑な調査・設計では、委託を許可されている場合に登録済みのshinaps-explorer、shinaps-architect、shinaps-plan-reviewerへ対象と期待する結果を渡す。担当の結論を自分で検証する。委託不可なら同じ観点を現在のセッションで確認する。worktree作成は別途許可が必要。
 4. 計画を必要な単位に分けて実装する。利用できる計画ツールで進捗を管理する。既存の無関係な変更を保ち、公開契約を変える必要が出たら理由と案を確認する。
-5. $shinaps:simplifyを読み、仕様を保つ削除・統合を行う。CIや既存スクリプトから変更に必要な検証を実行する。UIが関係する場合は$shinaps:verify-uiを使い、対象プロジェクトで必要な実画面を確認する。
+5. $shinaps:simplifyを読み、仕様を保つ削除・統合を行う。CIや既存スクリプトから変更に必要な検証を実行する。
 6. $shinaps:refineによるルール照合が可能なら行い、$shinaps:reviewで最終差分をレビューする。確定した今回の不具合を修正し、影響範囲を再検証する。依頼外の既存問題は混ぜず報告する。
 7. 変更後の挙動、主要な検証と未確認事項を報告する。コミット・PR・公開は別途依頼された場合だけ進める。

package/plugins/shinaps-claude/skills/verify-ui/SKILL.md DELETED Viewed

@@ -1,36 +0,0 @@
----
-name: verify-ui
-description: UI変更を対象プロジェクトの対応環境で実際に操作し、見た目と挙動を検証する。UI実装後や画面の動作確認を求められたときに使う。
----
-## 作業記録の保存先
-作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
-既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
-# UIを使って検証する
-## プロジェクトの条件を読む
-適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
-既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
-## 検証範囲を決める
-対応ブラウザ・端末、変更する操作、期待する性質、必須の証拠を既存仕様から決める。受入条件はケースの列挙ではなく「再表示しても保存した選択を保つ」のような性質で書き、代表的な操作で確かめる。
-特定ブラウザ、実機、Simulator、複数OSバージョンを一律に必須にしない。プロジェクトがPCブラウザのみを対象にするならその範囲で検証する。エンジン差・ハードウェア・入力方式が結果を左右する変更なら、その差を確認できる環境を選ぶ。必要な環境が使えない場合、別環境で通ったことを代替証拠にせず未確認として残す。対応範囲自体が不明で結論を左右する場合だけ確認する。
-## 実行と証拠
-1. 現在の画面と実装を確認する。余白や入力の問題がアプリ・ブラウザ・端末のどこに属するか切り分ける。
-2. プロジェクトが必要とする自動検証を実行し、対象の実画面で主要操作と関連する状態遷移を確かめる。DOMや内部状態の注入を操作成功の証拠にしない。
-3. レイアウトの欠け、重なり、フォーカス、再操作、保存・再表示など変更の影響する性質を確認する。動画や計測を必要とする動き・性能は静止画だけで合格にしない。
-4. 視覚的な判定にはスクリーンショットを残し、環境・操作・期待・観測結果を対応づける。明示された証拠の納品先がなければ `.shinaps/work/` 以下の今回の作業ディレクトリを使う。
-5. 発見した問題を直した場合は影響部分を再確認する。独立レビューは利用可能で許可され、効果がある場合に限る。
-## 完了
-定めた範囲で期待する性質を実画面から確認できたことを報告する。自動テストのみ・画面を開いただけ・スクリーンショットのみで操作を確認済みにしない。未確認事項と理由は完了範囲から区別する。実装・修正が依頼されていなければ、検証の依頼から変更許可を推測しない。

package/plugins/shinaps-codex/skills/verify-ui/SKILL.md DELETED Viewed

@@ -1,36 +0,0 @@
----
-name: verify-ui
-description: UI変更を対象プロジェクトの対応環境で実際に操作し、見た目と挙動を検証する。UI実装後や画面の動作確認を求められたときに使う。
----
-## 作業記録の保存先
-作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
-既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
-# UIを使って検証する
-## プロジェクトの条件を読む
-適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
-既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
-## 検証範囲を決める
-対応ブラウザ・端末、変更する操作、期待する性質、必須の証拠を既存仕様から決める。受入条件はケースの列挙ではなく「再表示しても保存した選択を保つ」のような性質で書き、代表的な操作で確かめる。
-特定ブラウザ、実機、Simulator、複数OSバージョンを一律に必須にしない。プロジェクトがPCブラウザのみを対象にするならその範囲で検証する。エンジン差・ハードウェア・入力方式が結果を左右する変更なら、その差を確認できる環境を選ぶ。必要な環境が使えない場合、別環境で通ったことを代替証拠にせず未確認として残す。対応範囲自体が不明で結論を左右する場合だけ確認する。
-## 実行と証拠
-1. 現在の画面と実装を確認する。余白や入力の問題がアプリ・ブラウザ・端末のどこに属するか切り分ける。
-2. プロジェクトが必要とする自動検証を実行し、対象の実画面で主要操作と関連する状態遷移を確かめる。DOMや内部状態の注入を操作成功の証拠にしない。
-3. レイアウトの欠け、重なり、フォーカス、再操作、保存・再表示など変更の影響する性質を確認する。動画や計測を必要とする動き・性能は静止画だけで合格にしない。
-4. 視覚的な判定にはスクリーンショットを残し、環境・操作・期待・観測結果を対応づける。明示された証拠の納品先がなければ `.shinaps/work/` 以下の今回の作業ディレクトリを使う。
-5. 発見した問題を直した場合は影響部分を再確認する。独立レビューは利用可能で許可され、効果がある場合に限る。
-## 完了
-定めた範囲で期待する性質を実画面から確認できたことを報告する。自動テストのみ・画面を開いただけ・スクリーンショットのみで操作を確認済みにしない。未確認事項と理由は完了範囲から区別する。実装・修正が依頼されていなければ、検証の依頼から変更許可を推測しない。