@shinaps/skills 0.48.0 → 0.49.0

package/README.md

@@ -3,7 +3,7 @@
 Claude Code と Codex で使う、開発ワークフローのスキル集です。調査・仕様の整理・実装・レビュー・コミット・PR・リリースの手順を、それぞれのクライアント向けの plugin として配布します。
 
 - 実装は Claude Code が行います。Codex は調査・レビュー・Linear での進行管理と QA を担当します。
-- 導入に Shinaps AI のアカウントは不要です。コーディング規約（rule）の照合・抽出を使うときだけ、[Shinaps AI](https://app.shinaps.ai) でアカウントを作成して MCP を接続します。
+- 導入に Shinaps AI のアカウントは不要です。コーディング規約（rule）の照合・登録を使うときだけ、[Shinaps AI](https://app.shinaps.ai) でアカウントを作成して MCP を接続します。
 
 ## 必要なもの
 
@@ -36,7 +36,7 @@ Claude Code では `/shinaps:<スキル名>`（例 `/shinaps:review`）で呼び
 
 1. `explore` で今の挙動と変更の影響を調べる。要件が曖昧なら `spec` で仕様を詰める。
 2. Claude Code の `dev-claude` で実装する。体制（LITE・BASIC・ULTRA）を選ぶと、実装とは別の担当が計画や実装をレビューします。
-3. `simplify` で不要な構造を削り、`review` で差分を確かめる。
+3. `review` で差分を確かめる。体制（LITE・BASIC・ULTRA）を選べ、規約照合や簡素化だけの依頼もできます。追加修正の後や、実装時と違う体制で確かめたいときにも単独で使えます。指摘の検証と報告までを行い、修正は依頼されたときだけ開発の担当へ引き継ぎます。
 4. `commit`・`create-pr`・`release` で、コミット・PR・公開を行う。これらは依頼されたとき、または Linear で合意した終了地点までの進行を依頼されたときに実行します。操作ごとの許可の一覧は持たず、依頼の範囲とプロジェクトの制約で判断します（[依頼範囲と操作](plugins/shinaps-claude/references/request-scope.md)）。
 
 スキルは、対象プロジェクトの `AGENTS.md`・`CLAUDE.md`・README・CI・既存のスクリプトから、対象の環境・必要な検証・公開の条件を読み取ります。書かれていない条件は、結果を左右するものだけを確認します。Linear と Claude Managed Agents 以外のスキルは、専用の設定ファイル無しで使えます。`linear-execute` での開発の進行には `.shinaps/linear.json`、Managed Agents への依頼には `.shinaps/managed.json` が必要です（下の「機能別の資料」）。
@@ -49,10 +49,7 @@ Claude Code では `/shinaps:<スキル名>`（例 `/shinaps:review`）で呼び
 | `spec` | 目的・仕様・実現方法を詰める |
 | `dev-claude`（Claude のみ） | 選んだ体制で実装し、別の担当が独立にレビューする |
 | `debug` | 不具合の原因を調べて確かめる |
-| `review` | 差分や既存のコードをレビューする |
-| `refine` | Shinaps AI の rule と実際のファイルを照合する |
-| `extract-rules` | PR のレビューから rule を抽出する |
-| `simplify` | 目的から見直して、不要な構造や手順を削る |
+| `review` | 差分や既存のコードを、選んだ体制でレビューする（規約照合・可読性・慣習・簡素化を含む） |
 | `commit` | 変更を単位に分けてコミットする |
 | `create-pr` | リポジトリの規約に合わせて PR を作る |
 | `release` | 公開条件を確かめて公開し、対象の版を使えることを確かめる |
@@ -67,6 +64,7 @@ Claude Code では `/shinaps:<スキル名>`（例 `/shinaps:review`）で呼び
 |---|---|
 | 更新・削除・macOS での Codex の自動更新 | [導入と更新](docs/install.md) |
 | `dev-claude` の体制と工程 | [実装体制の判断](plugins/shinaps-claude/references/dev/staffing.md)・[dev の工程](plugins/shinaps-claude/references/dev/workflow.md) |
+| レビューの担当の構成と指摘の採否・単独起動の手順 | [レビューの共通契約](plugins/shinaps-claude/references/review.md)・[単独レビューの手順](plugins/shinaps-claude/references/review-standalone.md) |
 | Linear での開発進行（`.shinaps/linear.json` の書き方・終了地点と制約・auto と manual） | [プロジェクト設定](plugins/shinaps-claude/references/linear/configuration.md)・[担当と工程](plugins/shinaps-claude/references/linear/workflow.md) |
 | Claude Managed Agents（必要なもの・導入・依頼） | [設定とアカウント](plugins/shinaps-claude/references/managed/configuration.md)・[導入と更新](plugins/shinaps-claude/references/managed/setup.md)・[依頼と観測](plugins/shinaps-claude/references/managed/execute.md) |
 | スキルが使う担当（サブエージェント）の一覧 | [サブエージェント](docs/agents.md) |
@@ -75,9 +73,22 @@ Claude Code では `/shinaps:<スキル名>`（例 `/shinaps:review`）で呼び
 
 旧版の設定は自動では変換しません。Linear は [旧設定の移行](plugins/shinaps-claude/references/linear/configuration.md#旧設定の移行)（0.48.0 から `config_version: 3`。操作ごとの許可の一覧を廃止し `constraints` に置き換え）、Managed Agents は [version 1 からの移行](plugins/shinaps-claude/references/managed/configuration.md#version-1-からの移行)に従ってください。
 
+### 0.49.0 の変更
+
+`refine`・`simplify`・`extract-rules` のスキルを廃止しました。規約照合と簡素化は `review` に依頼します（「規約照合だけ」「簡素化だけ」と限定できます）。規約の登録はその場で AI に依頼します。PR からの一括抽出の代わりになるスキルはありません。計画の簡素化だけを単独で起動する手段も無くなり、dev の計画レビューに含まれます。
+
+`review` の名前は同じですが、次の動作が変わります。
+
+- 既定では指摘の検証と報告で終わり、修正や次の操作の質問をしません。修正まで依頼すると、開発の担当が修正と再レビューを行い、未コミットの差分を返します。Codex の `review` は Linear 進行でなくてもローカルの Claude CLI を権限確認を省くモード（`bypassPermissions`）で起動して修正を渡します。操作は依頼の範囲に限り、CLI が無いときは止まります。
+- 指摘の独立検証と外部調査は、毎回ではなく、依頼されたときや判断を左右するときに行います。
+- 変更を対象にしたレビューでは、変更と無関係な既存箇所の規約違反を Critical にせず、別の一覧で報告します。ファイル・ディレクトリを指定した場合は、指定した全体を対象に重要度を下げません。
+- 引数なしの対象は、ベースブランチからのコミット済みの差分と作業ツリーの変更です。
+
+dev の実装後レビューでは、規約に機械検査があるときに配布 CLI の `lint` を使います（使えないときは AI が照合します）。
+
 ## Shinaps AI との接続
 
-`refine`・`extract-rules` など rule を使う工程に必要です。導入とは別に設定し、既存の登録があれば再利用します。同じサーバーを plugin とグローバル設定の両方に登録しないでください。認証情報は各クライアントの認証で管理し、このリポジトリの CLI では扱いません。
+`review` や `dev-claude` の規約照合など rule を使う工程に必要です。規約の登録・更新はその場で AI に依頼します（[規約の書き方](plugins/shinaps-claude/references/rule-writing.md)）。導入とは別に設定し、既存の登録があれば再利用します。同じサーバーを plugin とグローバル設定の両方に登録しないでください。認証情報は各クライアントの認証で管理し、このリポジトリの CLI では扱いません。
 
 ```sh
 # Claude Code（登録後、Claude Code 内の /mcp から認証）

package/docs/agents.md

@@ -2,7 +2,7 @@
 
 スキルが内部で起動する担当（サブエージェント）の一覧です。概要は [README](../README.md) を参照してください。
 
-Claude 版は 14、Codex 版は 10 の担当を配布します。
+Claude 版は 11、Codex 版は 8 の担当を配布します。
 
 | 担当 | 配布 | 役割 |
 |---|---|---|
@@ -10,10 +10,7 @@ Claude 版は 14、Codex 版は 10 の担当を配布します。
 | `shinaps-investigator` | 両方 | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
 | `shinaps-architect` | Claudeのみ | dev で独立設計担当を置く場合（ULTRA、または追加した BASIC）の独立設計。メインの案を見ずに、要件・制約・規約・引き継いだ成果物から別案を返す |
 | `shinaps-plan-reviewer` | Claudeのみ | 計画レビュー (confidence 閾値 70) と計画の簡素化。体制に応じて1〜2名で独立に指摘・修正案・削減の提案を返す |
-| `shinaps-reviewer` | 両方 | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80)。Claude の dev では、「可読性・慣習レビュー」「規約照合」「実装の簡素化」も同じ役割の種類として担う |
-| `shinaps-review-validator` | 両方 | reviewer 指摘の実コード検証 (confirmed / false positive / partial / out-of-scope 分類) |
-| `shinaps-simplifier` | Claudeのみ | `shinaps:simplify` の計画・実装の簡素化の提案。仕様・構造・処理の削減を読み取り専用で提案 |
-| `shinaps-refine-agent` | 両方 | rule 照合 (ファイル現状全文と照合、Violation / Improvement / Question 分類 + changed / pre-existing 切り分け) |
+| `shinaps-reviewer` | 両方 | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80)。dev と `review` では、「可読性・慣習レビュー」「規約照合」「実装の簡素化」「指摘の検証」も同じ役割の種類として担う |
 | `shinaps-spec-writer` | 両方 | ヒアリング + 調査結果を spec.md 構造化 |
 | `shinaps-tech-surveyor` | 両方 | 外部技術調査 (WebSearch + WebFetch で 3-5 候補比較) |
 | `shinaps-survey-validator` | 両方 | tech-surveyor の出典を WebFetch で再確認 |

package/docs/development.md

@@ -12,10 +12,11 @@
 品質基準とプロジェクト設定の方針は両版で揃え、クライアント固有の実行手順とエージェントの形式は別々に管理する。スキルを追加・変更したら各版への適用可否を判断する。
 
 - `references/`（`dev/launch.md` を除く）は Claude 版を編集元として Codex 版へ同じ内容を複製し、テストで一致を確認する。`SKILL.md` と役割の本文は版ごとに書き分け、Claude 向けの呼び出しを Codex に読み替えさせる方式は使わない。
-- Managed の共通定義は `plugins/shinaps-claude/managed-agents/` を編集元として Codex 版へ複製し、テストで一致を確認する。Managed の skill の `staffing.md`・`workflow.md`・`launch.md` は Claude 版を写した適応版で一致はテストしないため、Claude 版の工程・体制の基準を変えたら Managed への適用可否を判断する。
+- Managed の共通定義は `plugins/shinaps-claude/managed-agents/` を編集元として Codex 版へ複製し、テストで一致を確認する。Managed の skill の `staffing.md`・`workflow.md`・`launch.md` は Claude 版を写した適応版で一致はテストしないため（`review.md`・`design.md` は下の正本の複製でテストする）、Claude 版の工程・体制の基準を変えたら Managed への適用可否を判断する。
+- レビューの共通契約は `references/review.md` を正本とし、本文を Managed の skill の `references/review.md` に複製してテストで一致を確認する。Codex の `shinaps-reviewer` は、Claude 版の「レビューの種類」以降の本文を同じ文で持ち、テストで一致を確認する。担当の構成・対象の固定・完了の判定・採否は契約に、種類ごとの作業手順は役割の定義に、単独起動の対象・体制・到達点は `references/review-standalone.md` に、担当の起動と修正の引き継ぎ先だけを両版の `review` の `SKILL.md` に書く。
 - テスト方針は各版の `references/testing.md` を正本とし、その段落を役割定義と Managed の lead の定義に複製する。設計の観点は `references/dev/design.md` を正本とし、本文を独立設計担当（`shinaps-architect`）の定義と Managed の skill の `references/design.md` に複製する。どちらもテストで一致を確認する。
 - 役割の定義は Claude 版が Markdown、Codex 版が TOML、Managed 版が `ant apply` 用の frontmatter を付けた Markdown。サブエージェント内では shinaps MCP を直接呼ばず、rule の全文はスキル側から渡す（MCP の利用量が重複しないようにするため）。この原則を全ての役割定義に書く。
-- `autonomous-commit-review` の役割は `commit` に統合した。旧 `linear` の入口は廃止し、`linear-plan`・`linear-execute` に分けた。個人用の別 AI 呼び出し・ブラウザ管理・ゴール管理・動画制作はこの plugin に含めない。Bridge 本体は同梱せず、導入済みの MCP と WebStorm プラグインを使う。
+- `autonomous-commit-review` の役割は `commit` に統合した。旧 `linear` の入口は廃止し、`linear-plan`・`linear-execute` に分けた。規約照合と簡素化の独立した入口は `review` に統合し、規約の一括抽出の入口は廃止した（規約の登録は利用者がその場で依頼する）。個人用の別 AI 呼び出し・ブラウザ管理・ゴール管理・動画制作はこの plugin に含めない。Bridge 本体は同梱せず、導入済みの MCP と WebStorm プラグインを使う。
 
 ## ローカル開発
 

package/docs/install.md

@@ -26,7 +26,7 @@ npx @shinaps/skills@latest recover codex
 設定の検証（`validate-linear-config`・`validate-managed-config`）、Managed Agents の操作（`managed`）、規約の機械検査（`lint`、[規約の機械検査](lint.md)）には、配布 CLI `shinaps-skills` を使います。CLI は plugin に含まれないため、利用中のスキルと同じ版を導入します。
 
 ```sh
-npm install -g @shinaps/skills@0.48.0
+npm install -g @shinaps/skills@0.49.0
 shinaps-skills --version
 ```
 

package/package.json

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

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

@@ -1,7 +1,7 @@
 {
   "name": "shinaps",
   "description": "Shinaps AIの開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・レビュー・コミット・PR・リリースとLinearでの開発進行を支援する。",
-  "version": "0.48.0",
+  "version": "0.49.0",
   "author": {
     "name": "shinaps"
   },

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

@@ -1,12 +1,12 @@
 ---
 name: shinaps-reviewer
-description: dev の入口の実装後レビュー（独立コードレビュー・「可読性・慣習レビュー」・規約照合・実装の簡素化のうち指定された種類）および shinaps:review の一次レビューを担当。独立コードレビューは実装後の差分を logic / design / security / performance / maintainability と rule 適合性の観点で網羅的に、可読性・慣習レビューは指定された範囲を規約と先例に照らし、規約照合は対象ファイル全文を規約と1件ずつ照らし、実装の簡素化は削除・統合できる処理を探して、Critical / Warning / Info で報告する
+description: dev の入口の実装後レビューと shinaps:review で、独立コードレビュー・「可読性・慣習レビュー」・規約照合・実装の簡素化・指摘の検証のうち指定された種類を担当。独立コードレビューは実装後の差分を logic / design / security / performance / maintainability と rule 適合性の観点で網羅的に、可読性・慣習レビューは指定された範囲を規約と先例に照らし、規約照合は対象ファイル全文を規約と1件ずつ照らし、実装の簡素化は削除・統合できる処理を探し、指摘の検証は渡された指摘を実コードで確かめて、Critical / Warning / Info で報告する
 model: opus
 effort: medium
 color: red
 ---
 
-あなたは dev の入口の実装後レビュー（独立コードレビュー・「可読性・慣習レビュー」・規約照合・実装の簡素化）、および `/shinaps:review` の一次レビューで起動されるレビュー担当エージェントです。
+あなたは dev の入口の実装後レビューと `/shinaps:review` で起動されるレビュー担当エージェントです（独立コードレビュー・「可読性・慣習レビュー」・規約照合・実装の簡素化・指摘の検証）。
 呼び出し元が指定した「レビューの種類」に従ってレビューし、Critical / Warning / Info の指摘を返してください。
 
 ## 作業前の必須確認
@@ -16,9 +16,9 @@ color: red
 
 ## レビューの種類
 
-呼び出し元が「独立コードレビュー」「可読性・慣習レビュー」「規約照合」「実装の簡素化」のうち1つ以上を指定する。指定が無ければ独立コードレビューとして動く。複数を指定されたら、各節の観点を1名で見て、一つのレポートで返す。指定された種類の節に従い、下の「可読性のレビュー」・Confidence 閾値・出力形式・動作原則はどの種類でも共通に使う。規約を根拠にする指摘（rule 観点・可読性・慣習・規約照合）は、今回の変更か既存箇所かを区別する。dev で呼び出された場合は、そのうち今回の変更と無関係な既存箇所のものを、どの種類でも「既存箇所の指摘」に分け、Critical にせず、完了を止める指摘にしない。この扱いは、下の重要度と「必ず Critical」の文より優先する。
+呼び出し元が「独立コードレビュー」「可読性・慣習レビュー」「規約照合」「実装の簡素化」「指摘の検証」のうち1つ以上を指定する。指定が無ければ独立コードレビューとして動く。複数を指定されたら、各節の観点を1名で見て、一つのレポートで返す。指定された種類の節に従い、下の「可読性のレビュー」・Confidence 閾値・出力形式・動作原則はどの種類でも共通に使う。規約を根拠にする指摘（rule 観点・可読性・慣習・規約照合）は、今回の変更か既存箇所かを区別する。変更を対象にしたレビューでは、そのうち今回の変更と無関係な既存箇所のものを、どの種類でも「既存箇所の指摘」に分け、Critical にせず、完了を止める指摘にしない。この扱いは、下の重要度と「必ず Critical」の文より優先する。呼び出し元が「範囲判定なし」と指定した場合は、指定された対象全体を今回の対象とし、変更か既存かを区別せず、重要度も下げない。
 
-devで呼び出し元が設計適合性も依頼した場合は、design 観点で計画・受入条件・責務・依存方向と実コードを照合する。規約照合の種類が指定されなければ、規約は独立コードレビューの rule 観点で、渡された規約全文に照らす。
+呼び出し元が設計適合性も依頼した場合は、design 観点で計画・受入条件・責務・依存方向と実コードを照合する。規約照合の種類が指定されなければ、規約は独立コードレビューの rule 観点で、渡された規約全文に照らす。呼び出し元が機械検査で照合から外すと伝えた組（規約×ファイル）は、rule 観点でも規約照合でも照らさない。
 
 ### 独立コードレビュー
 
@@ -47,7 +47,7 @@ devで呼び出し元が設計適合性も依頼した場合は、design 観点
 
 1. 渡された全ファイルについて、適用される規約を確認する。非該当・読み取り失敗・未完了は理由を明記する。
 2. 対象のファイルを現状全文で読む。
-3. 依頼に書かれた変更範囲の確認コマンド（`git diff HEAD -- <path>` など）を実行し、そのファイルのどの行が今回の変更かを把握する。未追跡のファイルは全行を今回の変更とする。
+3. 依頼に書かれた変更範囲の確認コマンド（`git diff HEAD -- <path>` など）を実行し、そのファイルのどの行が今回の変更かを把握する。未追跡のファイルは全行を今回の変更とする。「範囲判定なし」と指定された場合は、この手順と手順5を省き、範囲を分類しない。
 4. ファイル全体を、渡された規約と1件ずつ照らして指摘を分類する（変更行の周辺だけに絞らない）。
 5. 各指摘の範囲を決める。
 
@@ -69,6 +69,16 @@ devで呼び出し元が設計適合性も依頼した場合は、design 観点
 - 各提案について対象、削除・統合の内容、理由、維持する契約、必要な検証、仕様判断の要否を返す。
 - 簡素化の提案は下の Confidence 閾値の対象外とする。提案がなければ「なし」と確認範囲を書き、この節を必ず出力する。
 
+### 指摘の検証
+
+渡された指摘を、該当するファイルと行、周辺の関数・呼び出し元・型定義を読んで確かめる。推測で判定しない。
+
+- **分類**: confirmed（指摘のとおり修正が必要）、false positive（実際は問題ない）、partial（一部は妥当だが範囲や表現の修正が必要）、out-of-scope（妥当だが今回の対象の外）。
+- 反証を示せない指摘を false positive にしない。規約を根拠にする指摘は、規約から明確に外れない証拠が無い限り confirmed 側で判定する。
+- false positive には実コードでの反証を、out-of-scope には対象の外と判断した理由を付ける。
+- 確認中に見つけた、元の指摘に無い問題は追加の指摘として報告する。
+- 検証の分類は下の Confidence 閾値の対象外とし、渡された指摘すべてを分類する。
+
 ## 可読性のレビュー（どの種類にも共通）
 
 対象言語の基礎を知るジュニアが初めて読んでも、処理の目的・流れ・判断理由を追えるかを基準にする。レビュアー自身が解読できることを、読みやすさの根拠にしない。
@@ -89,28 +99,30 @@ devで呼び出し元が設計適合性も依頼した場合は、design 観点
 - **Critical**: 動作を壊す / セキュリティ問題 / 規約 (rule 含む) 違反
 - **Warning**: 修正すべきだが動作は壊さない
 - **Info**: 参考情報 / 好み
-- **既存箇所の指摘**: dev で、規約を根拠にする指摘のうち既存箇所のもの（「レビューの種類」の規則のとおり Critical にしない）
+- **既存箇所の指摘**: 変更を対象にしたレビューで、規約を根拠にする指摘のうち既存箇所のもの（「レビューの種類」の規則のとおり Critical にしない）
 - **規約照合の範囲**: 規約照合を指定された場合、照合を終えたファイルと、未照合のファイル（理由付き）
 - **実装の簡素化**: 実装の簡素化を指定された場合、その節の提案（無ければ「なし」と確認範囲）
+- **指摘の検証**: 指摘の検証を指定された場合、指摘ごとの分類と根拠、追加の指摘
 
 各指摘は以下を含む:
 
 - `file:line` (絶対 or repo 相対)
 - **観点タグ**: `[logic]` / `[design]` / `[security]` / `[performance]` / `[maintainability]` / `[rule]`（可読性・慣習レビューは `[readability]` も使う）
-- **問題説明**: 何が問題か
+- **問題説明**: 何が問題か（発生条件と具体的な影響を含む）
 - **修正方針**: どう直すべきか (具体的に)
 - **根拠**: rule 引用 or docs 引用 or file:line 引用（規約照合では、「規約照合」の節の根拠）
 - 規約照合の指摘は、種類（Violation・Improvement・Question）と範囲（changed・pre-existing）も含む
 
 ## 動作原則
 
-- **confidence ≥ 80 のみ報告**（規約照合と簡素化の提案は除く）
+- **confidence ≥ 80 のみ報告**（規約照合・簡素化の提案・指摘の検証は除く）
 - **前回の採否（人が決めた判断を除く）を、指摘の可否の根拠にしない**: 経緯として読むだけにする
 - **確認中に見つけた現在のコードの欠陥は指摘として返す**: 簡素化の提案の効果に含めるだけにせず、影響に応じた重要度の指摘として報告する
 - **規約違反 (rule 違反含む) は必ず Critical**
+- **不確実な仮説と確認済みの問題を分ける**: 検証していない動作を確認済みとしない
 - **観点を分けて報告しない**: 1 つの指摘に複数観点タグが付いても良い
 - **修正は提案のみ**: コード・設定・ルール・進行管理ファイルは編集せず、指摘を呼び出し元へ返す。追加の委託・worktree の作成・コミット・公開はしない
-- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される。渡されていない、または読み終えていない規約と照合済みとは報告せず、読んだ範囲と未読の規約（id・topic など特定できる単位）を返す
+- **shinaps MCP を直接呼ばない**: rule 全文は呼び出し元から渡される。渡されていない、または読み終えていない規約と照合済みとは報告せず、読んだ範囲と未読の規約（id・topic など特定できる単位）を返す
 
 ## テスト方針
 

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

@@ -6,7 +6,7 @@ effort: medium
 color: yellow
 ---
 
-あなたは `/shinaps:spec` の Phase 4-A / `/shinaps:review` の Phase 3.5 / `/shinaps:debug` の Phase 4.5 で起動される調査妥当性検証エージェントです。
+あなたは `/shinaps:spec` の Phase 4-A / `/shinaps:review` / `/shinaps:debug` の Phase 4.5 で起動される調査妥当性検証エージェントです。
 `shinaps-tech-surveyor` の一次レポートを受け取り、**出典を WebFetch で再確認** して主張の正確性を検証してください。
 
 ## 作業前に必ず読むもの

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

@@ -6,7 +6,7 @@ effort: medium
 color: teal
 ---
 
-あなたは `/shinaps:spec` の Phase 4-A / `/shinaps:review` の Phase 3 / `/shinaps:debug` の Phase 4.5 で共有利用される外部技術調査エージェントです。
+あなたは `/shinaps:spec` の Phase 4-A / `/shinaps:review` / `/shinaps:debug` の Phase 4.5 で共有利用される外部技術調査エージェントです。
 WebSearch / WebFetch で **一次情報** を集め、3-5 候補の比較レポートを作成してください。
 
 ## 作業前に必ず読むもの

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

@@ -1,6 +1,6 @@
 ---
 name: shinaps-reviewer
-description: dev の入口の実装後レビュー（独立コードレビュー・「可読性・慣習レビュー」・規約照合・実装の簡素化のうち指定された種類）および shinaps:review の一次レビューを担当。独立コードレビューは実装後の差分を logic / design / security / performance / maintainability と rule 適合性の観点で網羅的に、可読性・慣習レビューは指定された範囲を規約と先例に照らし、規約照合は対象ファイル全文を規約と1件ずつ照らし、実装の簡素化は削除・統合できる処理を探して、Critical / Warning / Info で報告する
+description: dev の入口の実装後レビューと shinaps:review で、独立コードレビュー・「可読性・慣習レビュー」・規約照合・実装の簡素化・指摘の検証のうち指定された種類を担当。独立コードレビューは実装後の差分を logic / design / security / performance / maintainability と rule 適合性の観点で網羅的に、可読性・慣習レビューは指定された範囲を規約と先例に照らし、規約照合は対象ファイル全文を規約と1件ずつ照らし、実装の簡素化は削除・統合できる処理を探し、指摘の検証は渡された指摘を実コードで確かめて、Critical / Warning / Info で報告する
 model:
   id: claude-opus-5-5
   effort: medium
@@ -14,7 +14,7 @@ tools:
         enabled: false
 ---
 
-あなたは dev の入口の実装後レビュー（独立コードレビュー・「可読性・慣習レビュー」・規約照合・実装の簡素化）、および `/shinaps:review` の一次レビューで起動されるレビュー担当エージェントです。
+あなたは dev の入口の実装後レビューと `/shinaps:review` で起動されるレビュー担当エージェントです（独立コードレビュー・「可読性・慣習レビュー」・規約照合・実装の簡素化・指摘の検証）。
 呼び出し元が指定した「レビューの種類」に従ってレビューし、Critical / Warning / Info の指摘を返してください。
 
 ## 作業前の必須確認
@@ -24,9 +24,9 @@ tools:
 
 ## レビューの種類
 
-呼び出し元が「独立コードレビュー」「可読性・慣習レビュー」「規約照合」「実装の簡素化」のうち1つ以上を指定する。指定が無ければ独立コードレビューとして動く。複数を指定されたら、各節の観点を1名で見て、一つのレポートで返す。指定された種類の節に従い、下の「可読性のレビュー」・Confidence 閾値・出力形式・動作原則はどの種類でも共通に使う。規約を根拠にする指摘（rule 観点・可読性・慣習・規約照合）は、今回の変更か既存箇所かを区別する。dev で呼び出された場合は、そのうち今回の変更と無関係な既存箇所のものを、どの種類でも「既存箇所の指摘」に分け、Critical にせず、完了を止める指摘にしない。この扱いは、下の重要度と「必ず Critical」の文より優先する。
+呼び出し元が「独立コードレビュー」「可読性・慣習レビュー」「規約照合」「実装の簡素化」「指摘の検証」のうち1つ以上を指定する。指定が無ければ独立コードレビューとして動く。複数を指定されたら、各節の観点を1名で見て、一つのレポートで返す。指定された種類の節に従い、下の「可読性のレビュー」・Confidence 閾値・出力形式・動作原則はどの種類でも共通に使う。規約を根拠にする指摘（rule 観点・可読性・慣習・規約照合）は、今回の変更か既存箇所かを区別する。変更を対象にしたレビューでは、そのうち今回の変更と無関係な既存箇所のものを、どの種類でも「既存箇所の指摘」に分け、Critical にせず、完了を止める指摘にしない。この扱いは、下の重要度と「必ず Critical」の文より優先する。呼び出し元が「範囲判定なし」と指定した場合は、指定された対象全体を今回の対象とし、変更か既存かを区別せず、重要度も下げない。
 
-devで呼び出し元が設計適合性も依頼した場合は、design 観点で計画・受入条件・責務・依存方向と実コードを照合する。規約照合の種類が指定されなければ、規約は独立コードレビューの rule 観点で、渡された規約全文に照らす。
+呼び出し元が設計適合性も依頼した場合は、design 観点で計画・受入条件・責務・依存方向と実コードを照合する。規約照合の種類が指定されなければ、規約は独立コードレビューの rule 観点で、渡された規約全文に照らす。呼び出し元が機械検査で照合から外すと伝えた組（規約×ファイル）は、rule 観点でも規約照合でも照らさない。
 
 ### 独立コードレビュー
 
@@ -55,7 +55,7 @@ devで呼び出し元が設計適合性も依頼した場合は、design 観点
 
 1. 渡された全ファイルについて、適用される規約を確認する。非該当・読み取り失敗・未完了は理由を明記する。
 2. 対象のファイルを現状全文で読む。
-3. 依頼に書かれた変更範囲の確認コマンド（`git diff HEAD -- <path>` など）を実行し、そのファイルのどの行が今回の変更かを把握する。未追跡のファイルは全行を今回の変更とする。
+3. 依頼に書かれた変更範囲の確認コマンド（`git diff HEAD -- <path>` など）を実行し、そのファイルのどの行が今回の変更かを把握する。未追跡のファイルは全行を今回の変更とする。「範囲判定なし」と指定された場合は、この手順と手順5を省き、範囲を分類しない。
 4. ファイル全体を、渡された規約と1件ずつ照らして指摘を分類する（変更行の周辺だけに絞らない）。
 5. 各指摘の範囲を決める。
 
@@ -77,6 +77,16 @@ devで呼び出し元が設計適合性も依頼した場合は、design 観点
 - 各提案について対象、削除・統合の内容、理由、維持する契約、必要な検証、仕様判断の要否を返す。
 - 簡素化の提案は下の Confidence 閾値の対象外とする。提案がなければ「なし」と確認範囲を書き、この節を必ず出力する。
 
+### 指摘の検証
+
+渡された指摘を、該当するファイルと行、周辺の関数・呼び出し元・型定義を読んで確かめる。推測で判定しない。
+
+- **分類**: confirmed（指摘のとおり修正が必要）、false positive（実際は問題ない）、partial（一部は妥当だが範囲や表現の修正が必要）、out-of-scope（妥当だが今回の対象の外）。
+- 反証を示せない指摘を false positive にしない。規約を根拠にする指摘は、規約から明確に外れない証拠が無い限り confirmed 側で判定する。
+- false positive には実コードでの反証を、out-of-scope には対象の外と判断した理由を付ける。
+- 確認中に見つけた、元の指摘に無い問題は追加の指摘として報告する。
+- 検証の分類は下の Confidence 閾値の対象外とし、渡された指摘すべてを分類する。
+
 ## 可読性のレビュー（どの種類にも共通）
 
 対象言語の基礎を知るジュニアが初めて読んでも、処理の目的・流れ・判断理由を追えるかを基準にする。レビュアー自身が解読できることを、読みやすさの根拠にしない。
@@ -97,28 +107,30 @@ devで呼び出し元が設計適合性も依頼した場合は、design 観点
 - **Critical**: 動作を壊す / セキュリティ問題 / 規約 (rule 含む) 違反
 - **Warning**: 修正すべきだが動作は壊さない
 - **Info**: 参考情報 / 好み
-- **既存箇所の指摘**: dev で、規約を根拠にする指摘のうち既存箇所のもの（「レビューの種類」の規則のとおり Critical にしない）
+- **既存箇所の指摘**: 変更を対象にしたレビューで、規約を根拠にする指摘のうち既存箇所のもの（「レビューの種類」の規則のとおり Critical にしない）
 - **規約照合の範囲**: 規約照合を指定された場合、照合を終えたファイルと、未照合のファイル（理由付き）
 - **実装の簡素化**: 実装の簡素化を指定された場合、その節の提案（無ければ「なし」と確認範囲）
+- **指摘の検証**: 指摘の検証を指定された場合、指摘ごとの分類と根拠、追加の指摘
 
 各指摘は以下を含む:
 
 - `file:line` (絶対 or repo 相対)
 - **観点タグ**: `[logic]` / `[design]` / `[security]` / `[performance]` / `[maintainability]` / `[rule]`（可読性・慣習レビューは `[readability]` も使う）
-- **問題説明**: 何が問題か
+- **問題説明**: 何が問題か（発生条件と具体的な影響を含む）
 - **修正方針**: どう直すべきか (具体的に)
 - **根拠**: rule 引用 or docs 引用 or file:line 引用（規約照合では、「規約照合」の節の根拠）
 - 規約照合の指摘は、種類（Violation・Improvement・Question）と範囲（changed・pre-existing）も含む
 
 ## 動作原則
 
-- **confidence ≥ 80 のみ報告**（規約照合と簡素化の提案は除く）
+- **confidence ≥ 80 のみ報告**（規約照合・簡素化の提案・指摘の検証は除く）
 - **前回の採否（人が決めた判断を除く）を、指摘の可否の根拠にしない**: 経緯として読むだけにする
 - **確認中に見つけた現在のコードの欠陥は指摘として返す**: 簡素化の提案の効果に含めるだけにせず、影響に応じた重要度の指摘として報告する
 - **規約違反 (rule 違反含む) は必ず Critical**
+- **不確実な仮説と確認済みの問題を分ける**: 検証していない動作を確認済みとしない
 - **観点を分けて報告しない**: 1 つの指摘に複数観点タグが付いても良い
 - **修正は提案のみ**: コード・設定・ルール・進行管理ファイルは編集せず、指摘を呼び出し元へ返す。追加の委託・worktree の作成・コミット・公開はしない
-- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される。渡されていない、または読み終えていない規約と照合済みとは報告せず、読んだ範囲と未読の規約（id・topic など特定できる単位）を返す
+- **shinaps MCP を直接呼ばない**: rule 全文は呼び出し元から渡される。渡されていない、または読み終えていない規約と照合済みとは報告せず、読んだ範囲と未読の規約（id・topic など特定できる単位）を返す
 
 ## テスト方針
 

package/plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/review.md

@@ -0,0 +1,70 @@
+# レビューの共通契約
+
+実装後の差分や既存のコードを独立してレビューするときの、担当の構成・対象の固定・完了の判定・指摘の採否を定める。devの実装後レビューと単独の `review` が同じ契約を使う。種類ごとの作業手順は `shinaps-reviewer` の定義にある。規約の取得、質問の経路、担当の起動方法、作業記録の場所、修正の進め方は呼び出す入口の手順に従う。「メイン」はレビューの結果を統合するセッション（Managed では lead）を指す。
+
+## 担当の構成
+
+担当はすべて `shinaps-reviewer` で起動し、次の種類を依頼する。
+
+| 体制 | 担当と依頼するレビューの種類 |
+| --- | --- |
+| LITE | 新規の1名に、独立コードレビュー（設計適合性を含む）・可読性・慣習レビュー・実装の簡素化を依頼する。規約は独立コードレビューの rule 観点で照らし、規約照合の種類は依頼しない。担当は追加しない |
+| BASIC | LITE と同じ1名を下限に、不確実性・影響範囲・失敗時の影響から担当を追加できる |
+| ULTRA | A: 新規の1名に、対象全体の独立コードレビュー（設計適合性を含む）・実装の簡素化を依頼する。B: 技術領域ごとの1名に、規約照合・可読性・慣習レビューを依頼する。必要な担当を追加できる |
+
+依頼が種類を限定している場合（規約照合だけ、簡素化だけなど）は、限定された種類だけを依頼する。担当は1名とする。ただし ULTRA を同時に指定され、限定された種類に規約照合または可読性・慣習レビューが含まれるときは、その種類を技術領域ごとに1名へ依頼する。
+
+技術領域は、Web・API・iOSのように技術や実装慣習が違う領域とする。配布先・写し・文書の分類は、別の技術領域に数えない。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属するようにし、足りない技術領域があれば担当を足す。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
+
+## 対象の固定
+
+- レビューの前に対象の版を固定して記録する。コミットはSHAで、未コミットの変更はHEADのSHAと追跡・未追跡ファイルの内容のハッシュで識別する。全文・差分・機械検査は同じ固定版を読む。作業ツリーが固定版でない場合（別のブランチのPRなど）は、担当と機械検査がその版の一時worktreeを読む。
+- 全結果が揃うまで対象を変えない。外部の変更が入ったら、影響範囲を同じ最新の版で確認し直す。
+- 変更を対象にするときは、staged・unstaged・untrackedのうち対象に含まれるものを特定する。未追跡のファイルは全行を今回の変更とし、削除されたファイルは全文の照合と機械検査から外す。
+- 変更範囲の確認コマンドは、入口が対象に合わせて決めて担当へ渡す。既存のコードを変更と関係なく対象にするときは「範囲判定なし」と渡す。
+
+## 担当へ渡すもの
+
+- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、規約全文、合意済み仕様。入手できなかったもの（計画・受入条件など）はそのことを伝える。
+- 独立コードレビュー: 対象コード、全差分、利用側、計画、検証結果。計画自体も誤りうるものとして確かめさせる。設計適合性は、計画・受入条件・責務・依存方向と実コードを照合させる。
+- 規約照合: 対象ファイルの一覧と、変更範囲の確認コマンド。担当は対象ファイルの現状全文を読む。
+- 可読性・慣習レビュー: 担当する範囲の差分と対象ファイルの現状全文、先例。
+- 実装の簡素化: 目的、維持する外部契約、対象コード、計画。
+- 指摘の検証: 元の対象、検証する指摘の全文、確認範囲、外部調査があればその結果。
+
+## 独立性
+
+独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませず、意見を交換させない（指摘の検証の担当は、検証する指摘だけを読む）。担当は読み取り専用で、修正・追加の委託・コミット・公開をしない。担当を起動できない場合は、その担当を未完了とし、メインの確認を独立レビューとは報告しない。
+
+## 機械検査
+
+規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら変わったファイルで実行し直し、前回の結果を引き継がない。
+
+- 全体を検査して違反が無いと確かめた組（規約×ファイル）と、違反を確かめた組は、そのファイルの rule 観点・規約照合から外す。外した規約の id をファイルごとに担当へ伝える。
+- 一部だけを検査した組は担当の照合に残し、機械検査の指摘を添える。
+- 機械検査の指摘は、メインが該当位置を読んで確かめてから、他の指摘と同じ基準で扱う。
+- 実行できない場合は全ての規約をAIの照合に回し、理由を報告する。
+
+## 完了の判定
+
+未確認の部分があれば同じ担当へ戻し、全結果が揃ってから検証・統合する。起動失敗・空回答・未確認範囲を「指摘なし」にしない。指摘なしの担当は、完了と確認範囲を確かめる。
+
+担当が規約を読み終えられなかった場合は、未読の規約を読める単位に分けて同じ担当へ渡す。それでも読めない規約はメインが未照合と確定し、その規約を担当へ伝え、それを除いた範囲で完了を判定する。未照合の規約は、特定できる単位（例: id・topic）で報告する。対象が大きい場合は、件数を理由に対象を減らさず、関連するファイルをまとめて同じ担当へ分けて渡し、分けた範囲をまたぐ契約は統合のときに確かめる。担当を再開できない場合は、確認済みと未確認の範囲を後任へ引き継いで交代を記録する。
+
+## 指摘の検証と統合
+
+メインが全レポート全文・出典・確認範囲・要件・対象の版・規約・検証結果を使い、全指摘を整理する。各指摘に担当・ラウンド・項番の出典IDを付け、実コード・利用箇所・計画・規約から根拠や反証を確かめ、根拠・誤認・重複・対立・未確認を区別する。同じ原因・影響・修正方針の指摘だけまとめ、元の項目と重要度を消さない。外部の仕様が判断を左右する指摘は、公式情報で確かめる。
+
+全項目の採否と理由、必要な修正と検証を一つにまとめる。統合は多数決ではなく根拠で行う。メイン自身の確認を独立検証とは報告しない。
+
+- 今回の対象（変更を対象にしたときは今回の変更とその影響範囲。範囲判定なしのときは指定された対象全体）にある次の指摘は、修正で解消するか事実（file:line・コマンドの結果）で反証するまで、退けたり消したりしない。
+  - (1) Critical・Warning の指摘（例: 今回の変更の規約違反、正しさ・契約・設計適合性の欠陥）。
+  - (2) 重要度・種類（Info・簡素化の提案）によらず、確認対象（計画またはコード）の正しさ・契約・設計上の欠陥を示す指摘。
+  - (1)・(2) のどちらも、修正案だけを退ける場合は、その欠陥をどう解消するか、またはその欠陥が成り立たない根拠を書く。前回の採否（人が決めた判断を除く）は退ける理由にならない。仕様を変えなければ解消できない欠陥は、入口の経路で利用者に確認し、利用者の判断を記録した時点で解決とする。
+- 事実で決まらない対立と、根拠不足で判断できない指摘は、同じ担当の継続で指摘元に確認する（レビューのラウンドに数えない）。解消しなければ未解決とし、品質上の完了にしない。
+- 変更を対象にしたときの既存箇所（今回の変更と無関係な箇所）の規約違反と欠陥は、「既存箇所の指摘」として別の一覧で報告し、完了を止めない。
+- 欠陥を示さず、好み・任意の改善に留まる Info と提案は、採らない理由を記録するだけで同意を求めない。仕様・受入条件・ユーザー体験の変更や、依頼範囲・許可の拡大は、利用者の合意前に採用しない。
+
+## 報告
+
+固定した版、体制と担当、確認範囲と完了状態、全指摘の対象箇所・発生条件・影響・修正案と採否・根拠、既存箇所の指摘、機械検査の組の状態ごとの数と実行できなかった理由、未照合の規約、未確認の範囲、未解決の事項を報告する。推測と確認済みの事実、実施した検証と未実施を区別する。独立コードレビューを依頼し規約照合の種類を依頼しなかった場合は、規約を独立コードレビューの中で照らし、ファイルごとの完了一覧が無いことを書く。どちらも依頼しなかった場合は、規約を照合していないと書く。

package/plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/staffing.md

@@ -13,10 +13,10 @@ lead はメインとして、同じ文脈を必要とする作業（調査・設
 | 調査・設計・計画 | lead（短い計画と検証方針） | lead | lead が自案を保存した後、独立設計担当1名が別案を作り、lead が比較して統合する |
 | 計画の独立確認 | 置かない（実装後の独立レビューが計画も確かめる） | 計画レビュー担当1名（計画レビュー・計画の簡素化。各1） | 計画レビュー担当2名（計画レビュー・計画の簡素化・独立案の論点を根拠なく退けていないか。各2） |
 | 実装・検証・自己簡素化・修正 | lead | lead | lead |
-| 実装後の独立レビュー | 独立コードレビューの担当1名（独立コードレビューの全観点（rule 観点を含む）・設計適合性・可読性・慣習・実装の簡素化。各1） | LITEと同じ | A: 独立コードレビューの担当1名（独立コードレビューの全観点（rule 観点を含む）・設計適合性・実装の簡素化）。B: 技術領域ごとに1名（規約照合（全手順）・可読性・慣習）。各1（A も rule 観点で規約に照らす） |
+| 実装後の独立レビュー | [レビューの共通契約](review.md)の LITE（1名） | 同じ契約の BASIC（1名） | 同じ契約の ULTRA（全体1名・技術領域ごとに1名） |
 | 指摘の検証・採否・修正計画 | lead | lead | lead |
 
-各役割の定義・継続・新規にする単位と、体制ごとに依頼するレビューの種類は[工程](workflow.md)の「役割と継続」とPhase 6に従う。探索の担当は置けないので、lead と独立設計担当がそれぞれ必要な範囲を調べる。
+各役割の定義・継続・新規にする単位は[工程](workflow.md)の「役割と継続」に、体制ごとに依頼するレビューの種類と技術領域の定義は[レビューの共通契約](review.md)に従う。探索の担当は置けないので、lead と独立設計担当がそれぞれ必要な範囲を調べる。
 
 ## lead の裁量
 
@@ -30,10 +30,6 @@ lead は受け取った体制の必須担当に加えて、役割の追加、技
 
 LITEでは、探索を含む担当を追加しない。独立コードレビューの担当1名で足りないと分かったら、理由を添えて `状態: 質問` でBASIC・ULTRAへの変更を利用者に相談する。
 
-## 技術領域
-
-技術領域は、Web・API・iOSのように技術や実装慣習が違う領域とする。配布先・写し・文書の分類は、別の技術領域に数えない。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属するようにする。
-
 ## 記録
 
 計画の前に、受け取った体制、追加した担当とその根拠、工程ごとの役割・人数・確認範囲、技術領域ごとに担当を置く場合はその割り当て、必須検証を作業記録へ短く残す。

package/plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/workflow.md

@@ -13,7 +13,7 @@ Claude Code の dev の工程を、Managed Agents のセッション向けに絞
 | Phase 6 | `shinaps-reviewer` | 独立コードレビューを含む担当はレビューラウンドごとに新規。規約照合と可読性・慣習レビューを技術領域ごとに置く担当は、ラウンドと修正サイクルをまたいで継続し、技術領域が増えたら追加 |
 
 - 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・依頼するレビューの種類を依頼に渡す（独立設計担当への依頼はPhase 3に従う）。
-- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませない。対象を編集中にレビューせず、全結果が揃うまで lead は対象を変えない。
+- 計画の確認と実装後の確認に、[レビューの共通契約](review.md)の「対象の固定」「独立性」「完了の判定」を適用する。計画の確認では対象の版を計画の内容のハッシュとし、差分・機械検査・変更範囲の文は適用しない。Phase 4 の入力として定めた両案は他担当の結果に当たらない。独立案（Phase 3）はPhase 3の節に従う。
 - 各担当の報告は全文を作業記録の `raw/` に保存し、対象版・役割・担当番号・確認範囲・完了状態を対応づける。Phase 4 の採否は `plan.md`、Phase 6 の採否は `fix-log.md` の「指摘の採否」の節に書く。
 - lead は、体制と工程の調整、調査・設計・計画の統合・実装・検証・修正、指摘の検証と採否、修正計画、担当の委任・待機、結果と未解決事項の取りまとめ、利用者判断の取り次ぎ、作業先・書き込み制限の比較・git・draft PR を行う。体制が求める独立確認を lead の自己確認で代えない。継続のターンで来る質問・修正も同じように扱う。
 - **修正サイクル**: 継続のターンで実装の修正が必要になったら、契機によらず、未対応の指摘の集合を一つの入力にして次の順に進める。
@@ -22,7 +22,6 @@ Claude Code の dev の工程を、Managed Agents のセッション向けに絞
   3. lead が修正する（Phase 5）。
   4. Phase 6 の担当（受け取った体制のとおり）が確認する。範囲は修正とその影響範囲とし、確定できなければ広げる。
   5. Phase 7 で統合・修正する。
-- 起動失敗・空回答・未確認範囲を「指摘なし」にしない。
 
 ## Phase 1: タスクと体制
 
@@ -58,24 +57,11 @@ lead が確定計画を実装する。
 
 ## Phase 6: 実装後の確認
 
-同じ差分を固定し、受け取った体制の担当と追加した担当を `shinaps-reviewer` へ並行して委任する。依頼するレビューの種類は体制ごとに次のとおり。設計適合性（計画・受入条件・責務・依存方向と実コードの照合）は、独立コードレビューの種類の中で毎回依頼する。staged・unstaged・untracked を含めて対象を特定する。
-
-- LITE・BASIC: 新規の1名に、独立コードレビュー（設計適合性を含む）・可読性・慣習レビュー・実装の簡素化を依頼する。規約は独立コードレビューの rule 観点で照らし、規約照合の種類は依頼しない。
-- ULTRA: A として新規の1名に、独立コードレビュー（設計適合性を含む）・実装の簡素化を依頼する。B として技術領域ごとの1名に、規約照合・可読性・慣習レビューを依頼する。
-- 規約照合には、規約（`AGENTS.md`・`CLAUDE.md` とその参照先）の全文と、比較元からの差分コマンド（`git diff <比較元> -- <path>`）を変更範囲の確認コマンドとして渡す。未追跡の新規ファイルは全行を今回の変更として扱う。
-- 可読性・慣習レビューには、担当する範囲の差分と対象ファイルの現状全文、規約、計画に記した先例、合意済み仕様を渡す。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属することを確かめ、足りない技術領域があれば担当を足す。
+[レビューの共通契約](review.md)に従い、同じ差分を固定して、受け取った体制の担当と追加した担当を並行して委任する。設計適合性は、独立コードレビューの種類の中で毎回依頼する。変更範囲の確認コマンドは比較元からの差分（`git diff <比較元> -- <path>`）を渡す。規約は [SKILL.md の規約](../SKILL.md#規約) の範囲で、機械検査は実行しない。
 
 ## 指摘の検証と統合（Phase 4・6）
 
-lead が全レポートを使って全指摘の根拠・誤認・重複・対立・未確認を区別し、出典IDを保持して全項目の採否と理由、必要な修正と検証をまとめる。統合は多数決ではなく根拠で行い、自分の成果物への指摘の確認を独立検証とは報告しない。
-
-- 今回の変更とその影響範囲にある次の指摘は、修正で解消するか事実（file:line・コマンドの結果）で反証するまで、退けたり消したりしない。
-  - (1) Critical・Warning の指摘（例: 今回の変更の規約違反、正しさ・契約・設計適合性の欠陥）。
-  - (2) 重要度・種類（Info・簡素化の提案）によらず、確認対象（計画またはコード）の正しさ・契約・設計上の欠陥を示す指摘。
-  - (1)・(2) のどちらも、修正案だけを退ける場合は、その欠陥をどう解消するか、またはその欠陥が成り立たない根拠を書く。前回の採否（人が決めた判断を除く）は退ける理由にならない。仕様を変えなければ解消できない欠陥は、`状態: 質問` で利用者に確認し、利用者の判断を記録した時点で解決とする。
-- 事実で決まらない対立と、根拠不足で判断できない指摘は、同じ担当の継続で指摘元に確認する（レビューのラウンドに数えない）。解消しなければ未解決とし、品質上の完了にしない。
-- 既存箇所（今回の変更と無関係な箇所）の規約違反と欠陥は、「既存箇所の指摘」として別の一覧で報告し、完了を止めない。
-- 欠陥を示さず、好み・任意の改善に留まる Info と提案は、採らない理由を記録するだけで同意を求めない。仕様・受入条件の変更や許可範囲の拡大は、利用者の合意前に採用しない。
+[レビューの共通契約](review.md)の「指摘の検証と統合」に従う。利用者への確認は `状態: 質問` で行う。
 
 ## Phase 7〜8: 修正と終了判定
 

package/plugins/shinaps-claude/references/dev/launch.md

@@ -1,6 +1,6 @@
 # 担当の起動（Claude Code）
 
-[工程](workflow.md)の体制で選んだ担当を Claude Code で起動・継続する手順。
+devの[工程](workflow.md)の体制で選んだ担当と、単独の `review` の担当を Claude Code で起動・継続する手順。
 
 - 担当は Agent ツールで登録エージェントを起動する。`subagent_type` は `shinaps:` に役割定義名を付けたもの（例 `shinaps:shinaps-architect`）にする。model・effort は定義（Opus / medium）のまま使い、起動時に上書きしない。
 - 同じ役割の複数担当 は、同じ登録エージェントを別々に起動する。呼び出しごとに別のコンテキストになるので、互いの結果は共有されない。担当番号は起動前に固定し、返された ID と対応づけて保持する。

package/plugins/shinaps-claude/references/dev/staffing.md

@@ -13,10 +13,10 @@ devの体制はLITE・BASIC・ULTRAの3段階で、作業ごとに人が選ぶ
 | 調査・設計・計画 | メイン（短い計画と検証方針） | メイン | メインが自案を保存した後、独立設計担当1名が別案を作り、メインが比較して統合する |
 | 計画の独立確認 | 置かない（実装後の独立レビューが計画も確かめる） | 計画レビュー担当1名（計画レビュー・計画の簡素化。各1） | 計画レビュー担当2名（計画レビュー・計画の簡素化・独立案の論点を根拠なく退けていないか。各2） |
 | 実装・検証・自己簡素化・修正 | メイン | メイン | メイン |
-| 実装後の独立レビュー | 独立コードレビューの担当1名（独立コードレビューの全観点（rule 観点を含む）・設計適合性・可読性・慣習・実装の簡素化。各1） | LITEと同じ | A: 独立コードレビューの担当1名（独立コードレビューの全観点（rule 観点を含む）・設計適合性・実装の簡素化）。B: 技術領域ごとに1名（規約照合（全手順）・可読性・慣習）。各1（A も rule 観点で規約に照らす） |
+| 実装後の独立レビュー | [レビューの共通契約](../review.md)の LITE（1名） | 同じ契約の BASIC（1名） | 同じ契約の ULTRA（全体1名・技術領域ごとに1名） |
 | 指摘の検証・採否・修正計画・人の指摘の調査 | メイン | メイン | メイン |
 
-各役割の定義・継続・新規にする単位と、体制ごとに依頼するレビューの種類は[工程](workflow.md)の「役割と継続」とPhase 6に従う。探索は必須にしない。体制・経路（auto・manual）・メインのモデルは別の項目で、互いに影響しない。
+各役割の定義・継続・新規にする単位は[工程](workflow.md)の「役割と継続」に、体制ごとに依頼するレビューの種類と技術領域の定義は[レビューの共通契約](../review.md)に従う。探索は必須にしない。体制・経路（auto・manual）・メインのモデルは別の項目で、互いに影響しない。
 
 ## 体制の選択
 
@@ -29,7 +29,7 @@ devの体制はLITE・BASIC・ULTRAの3段階で、作業ごとに人が選ぶ
 確認の規則は次のとおり。
 
 - 確認するのは人への確認の窓口とする。Linear進行では[停止と人への確認](../linear/workflow.md)の経路の規則に従い、単独のdevではメインが行う。
-- 各Issueの着手時と、人の指摘の一括修正を始めるたびに確認する。次の場合は聞き直さない: 依頼に体制が書かれている、利用者が範囲全体に体制を指定している、同じ修正単位を再開する、QAの差し戻しやコミット中の指摘で修正する、個々の指摘。
+- 各Issueの着手時と、人の指摘の一括修正を始めるたびに確認する。単独の `review` の体制はこの確認とは別に、その入口で選ぶ。次の場合は聞き直さない: 依頼に体制が書かれている、`review` で選んだ体制を修正へ引き継ぐ、利用者が範囲全体に体制を指定している、同じ修正単位を再開する、QAの差し戻しやコミット中の指摘で修正する、個々の指摘。
 - 人の修正開始以外で始まる修正サイクルは、その作業で直近に選んだ体制を使う。
 - 体制を変えたときは、新しく必要になった担当を新規に起動し、既存の成果と確定済みの判断・採否を引き継ぐ。レビューの回数はリセットしない。
 
@@ -45,10 +45,6 @@ BASIC・ULTRAでは、メインは選んだ体制の必須担当に加えて、
 
 LITEでは、探索を含む担当を追加しない。独立コードレビューの担当1名で足りないと分かったら、理由を添えて、人への確認の窓口からBASIC・ULTRAへの変更を相談する（変更の扱いは「体制の選択」のとおり）。
 
-## 技術領域
-
-技術領域は、Web・API・iOSのように技術や実装慣習が違う領域とする。配布先・写し・文書の分類は、別の技術領域に数えない。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属するようにする。
-
 ## 記録と引き渡し
 
 設計を始める前に、選んだ体制、追加した担当とその根拠、工程ごとの役割・人数・確認範囲、技術領域ごとに担当を置く場合はその割り当て、必須検証を短く記録する。独立した担当は、実装したメインとは別のコンテキストにする。