@shinaps/skills 0.48.0 → 0.50.0

package/dist/lib/transaction.js

@@ -1,10 +1,7 @@
 import { mkdir, rm, rename, cp } from 'node:fs/promises';
-import { createHash } from 'node:crypto';
 import { join } from 'node:path';
 import { managedAgent, marketplaceName, payloadDir, pluginId, statePath } from "./layout.js";
-import { errorCode, errorMessage, readJsonIfExists, readTextIfExists, writeFileAtomic, } from "./fs.js";
-/** エージェント内容の sha256。state.json と journal の `nextHashes` はこの形式で記録する。 */
-export const digest = (text) => createHash('sha256').update(text).digest('hex');
+import { errorCode, errorMessage, readJsonIfExists, readTextIfExists, writeFileAtomic, sha256, } from "./fs.js";
 /** 配布物を Codex に登録する。install と restore で同じ手順を使う。 */
 export async function registerPlugin(command, payload) {
     await command(['plugin', 'marketplace', 'add', payload]);
@@ -83,7 +80,7 @@ export async function restore(target) {
         const current = await readTextIfExists(join(agentsDir, name));
         if (current === null)
             continue;
-        if (current !== priorContent && digest(current) !== journal.nextHashes[name]) {
+        if (current !== priorContent && sha256(current) !== journal.nextHashes[name]) {
             throw new Error(`Modified agent preserved during recovery: ${join(agentsDir, name)}. Move the edited file elsewhere, then run "shinaps-skills recover codex".`);
         }
     }

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

@@ -7,15 +7,17 @@
 - Claude 版: `plugins/shinaps-claude/`、marketplace は `.claude-plugin/marketplace.json`
 - Codex 版: `plugins/shinaps-codex/`、marketplace は `.agents/plugins/marketplace.json`。サブエージェントは `plugins/shinaps-codex/agents/`
 - Claude Managed Agents 版: 両 plugin の `managed-agents/`。plugin と一緒に配布され、npm パッケージの `plugins/` にも含まれる
+- 規約の受け渡し: plugin の hook が `search_rules` の応答を保存し、配布 CLI の `rule-snapshot`・`rule-coverage` が担当と機械検査の読むファイルと報告の区分を作る（手順は `references/rules.md`）。
 - 配布 CLI: ソースは `bin/skills.ts` と `lib/*.ts`。規約の機械検査（`lint`）は ESLint の Node API を使い、仕組みと同梱ルールの追加手順は [規約の機械検査](lint.md) にある。TypeScript は typescript-eslint が対応する 6 系を実行時の依存に持ち、開発用の `tsc` も同じ版を使う（typescript-eslint が 7 に対応したら上げる）。`npm run build`（`tsc`）で `dist/` に JS を出力し、npm にはそれを配布する。Node.js は `node_modules` 配下の `.ts` に型除去を適用しないため、ソースのままは配布できない。checkout では型除去で直接実行するので、`enum` など型除去で消せない構文は使わない（`tsconfig.json` の `erasableSyntaxOnly`）
 
 品質基準とプロジェクト設定の方針は両版で揃え、クライアント固有の実行手順とエージェントの形式は別々に管理する。スキルを追加・変更したら各版への適用可否を判断する。
 
 - `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 プラグインを使う。
+- 役割の定義は Claude 版が Markdown、Codex 版が TOML、Managed 版が `ant apply` 用の frontmatter を付けた Markdown。サブエージェント内では shinaps MCP を直接呼ばず、rule の全文はスキル側から渡すか、スキル側が機械保存した snapshot のファイルを読ませる（MCP の利用量が重複せず、全文をモデルに書き写させないため）。この原則を全ての役割定義に書く。
+- `autonomous-commit-review` の役割は `commit` に統合した。旧 `linear` の入口は廃止し、`linear-plan`・`linear-execute` に分けた。規約照合と簡素化の独立した入口は `review` に統合し、規約の一括抽出の入口は廃止した（規約の登録は利用者がその場で依頼する）。個人用の別 AI 呼び出し・ブラウザ管理・ゴール管理・動画制作はこの plugin に含めない。Bridge 本体は同梱せず、導入済みの MCP と WebStorm プラグインを使う。
 
 ## ローカル開発
 
@@ -40,6 +42,7 @@ npm run verify:package
 
 `.github/workflows/publish.yml` は main への push・PR・手動実行でテストと配布内容を検証する。通常の GitHub Release を公開すると、検証の成功後に同じ tag のパッケージを npm へ公開する。prerelease と手動実行では公開しない。
 
+- plugin の hook（`hooks/`）は両版で本文を揃える。Codex は plugin の更新のたびに hook の信頼が外れるので、リリースの案内に `/hooks` での再信頼を書く。Shinaps AI の MCP の応答の形を変える版は、API の配備を先に行う。
 - リリース時は `package.json` と両 plugin の manifest のバージョンを揃えてコミットし、`v<version>` の tag で GitHub Release を公開する。tag とバージョンが一致しなければ止まる。既存の npm の版は再公開できないため、次の変更には新しいバージョンを使う。`docs/install.md` の配布 CLI の導入コマンドと、`references/linear/configuration.md`（両版）の CLI の版も新しい版に揃える。設定例の `$schema` と同梱 schema の `$id`（Linear・Managed、両版）は、schema の契約を変えた版でだけ上げる。公開前に npm スコープ `@shinaps` の権限と tarball の内容を確認する。
 - npm の `@shinaps/skills` には GitHub Actions の Trusted Publisher（owner `sh1n4ps`、repository `shinaps-skills`、workflow `publish.yml`、direct publish を許可）を登録している。publish job だけに `id-token: write` を付け、`NPM_TOKEN` secret は使わない。CI は GitHub-hosted の Ubuntu と Node.js 24 を使う。初回の信頼設定には本人認証が必要だが、その後の公開に毎回のセキュリティキー操作は不要。
 - npm の provenance は公開リポジトリからの Trusted Publishing で生成される。

package/docs/install.md

@@ -23,13 +23,24 @@ npx @shinaps/skills@latest recover codex
 
 ## 配布 CLI
 
-設定の検証（`validate-linear-config`・`validate-managed-config`）、Managed Agents の操作（`managed`）、規約の機械検査（`lint`、[規約の機械検査](lint.md)）には、配布 CLI `shinaps-skills` を使います。CLI は plugin に含まれないため、利用中のスキルと同じ版を導入します。
+設定の検証（`validate-linear-config`・`validate-managed-config`）、Managed Agents の操作（`managed`）、規約の機械検査と受け渡し（`lint`・`rule-snapshot`・`rule-coverage`、[規約の機械検査](lint.md)）には、配布 CLI `shinaps-skills` を使います。CLI は plugin に含まれないため、利用中のスキルと同じ版を導入します。
 
 ```sh
-npm install -g @shinaps/skills@0.48.0
+npm install -g @shinaps/skills@0.50.0
 shinaps-skills --version
 ```
 
+## 規約の hook
+
+規約の照合では、plugin の hook が Shinaps AI の `search_rules` の応答をプロジェクトの `.shinaps/work/rule-captures/` へ保存します。送信はしません。保存先の `.gitignore` で Git の対象外にし、24 時間より古いものは `rule-snapshot` の実行時に消します。
+
+- **Codex**: hook は信頼するまで動きません。plugin の導入と**更新のたびに**、CLI の `/hooks`（または起動時の確認）で内容を確かめて信頼してください。未信頼でも `codex exec` は何も表示せず、`rule-snapshot` が「捕捉が無い」で失敗し、規約照合は未完了になります。
+- **Claude Code**: plugin を有効にすると動きます。`disableAllHooks` や `allowManagedHooksOnly` の環境では動かず、同じく未完了になります。
+
+## 規約の適用結果の記録
+
+dev と `review` は、確定した適用結果（規約の id、作業の key、違反・改善・誤検知・許容の別）を既定で Shinaps AI の本人の集計へ記録します。コード・差分・会話・ファイル名・repository は送りません。集計は `get_rule` で本人の分だけを見られ、他の利用者には返りません。直近 90 日で削除されます。作業ごとに「規約の適用結果を記録しない」と依頼すれば送りません。送信に失敗しても作業の結果は変わらず、未記録として報告します。Codex の読取り専用の sandbox で承認が得られないときも未記録になります。
+
 ## Claude Code の更新
 
 Claude Code は標準の marketplace の自動更新を使います。`/plugin` の Marketplaces から対象 marketplace の auto-update を有効にします。GitHub から自動で取得するには、GitHub のリポジトリを marketplace として登録します（[README のインストール](../README.md#インストール)）。

package/docs/lint.md

@@ -35,6 +35,8 @@ shinaps-skills lint --checks <checks.json> --root <project> --out <result.json>
 }
 ```
 
+結果には他に `checksSha256`（`--checks` のファイルの sha256）と `files`（相対パス → 内容の sha256）が付きます。`rule-coverage` が、別の検査や変更前の内容から作られた結果を拒否するために使います。
+
 | state | 意味 | 照合 |
 | --- | --- | --- |
 | `covered` | `full` の検査が実行され、違反が無い | 外す |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.48.0",
+  "version": "0.50.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.50.0",
   "author": {
     "name": "shinaps"
   },

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

@@ -1,24 +1,24 @@
 ---
 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 の指摘を返してください。
 
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された取得済みの規約全文 (差分カテゴリに対応した userRules + officialRules)**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文、または読むよう指定された規約のファイル (差分カテゴリに対応した userRules + officialRules)**
 
 ## レビューの種類
 
-呼び出し元が「独立コードレビュー」「可読性・慣習レビュー」「規約照合」「実装の簡素化」のうち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/hooks/capture-rule-response.mjs

@@ -0,0 +1,27 @@
+// PostToolUse hook: search_rules (fields=full) の標準入力の全体を、モデルを通さずローカルへ保存する。
+// 形式の正本は lib/rule-snapshot.ts のコメント。失敗しても作業は止めず、rule-snapshot が欠けた捕捉として検出する。
+import { existsSync, mkdirSync, readFileSync, renameSync, writeFileSync } from 'node:fs';
+import { dirname, join } from 'node:path';
+
+// plugin の hook は配布 CLI の lib を読めないので、同じ処理をここにも持つ。
+function projectRoot(cwd) {
+  for (let directory = cwd; ; directory = dirname(directory)) {
+    if (existsSync(join(directory, '.git'))) return directory;
+    if (dirname(directory) === directory) return cwd;
+  }
+}
+
+const safeName = (value) => String(value).replace(/[^\w-]/g, '_');
+
+const raw = readFileSync(0);
+const event = JSON.parse(raw);
+if (event.tool_input?.fields === 'full') {
+  const captures = join(projectRoot(event.cwd), '.shinaps', 'work', 'rule-captures');
+  const directory = join(captures, safeName(event.session_id));
+  mkdirSync(directory, { recursive: true });
+  // 捕捉には個人規約の本文が入る。プロジェクトの ignore の内容によらず Git の対象外にする。
+  writeFileSync(join(captures, '.gitignore'), '*\n');
+  const file = join(directory, `${Date.now()}-${safeName(event.tool_use_id)}.json`);
+  writeFileSync(`${file}.tmp`, raw);
+  renameSync(`${file}.tmp`, file);
+}

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

@@ -0,0 +1,15 @@
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "mcp__.*shinaps[-_]ai.*__search_rules",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node \"${CLAUDE_PLUGIN_ROOT}/hooks/capture-rule-response.mjs\""
+          }
+        ]
+      }
+    ]
+  }
+}

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,19 +14,19 @@ tools:
         enabled: false
 ---
 
-あなたは dev の入口の実装後レビュー（独立コードレビュー・「可読性・慣習レビュー」・規約照合・実装の簡素化）、および `/shinaps:review` の一次レビューで起動されるレビュー担当エージェントです。
+あなたは dev の入口の実装後レビューと `/shinaps:review` で起動されるレビュー担当エージェントです（独立コードレビュー・「可読性・慣習レビュー」・規約照合・実装の簡素化・指摘の検証）。
 呼び出し元が指定した「レビューの種類」に従ってレビューし、Critical / Warning / Info の指摘を返してください。
 
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された取得済みの規約全文 (差分カテゴリに対応した userRules + officialRules)**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文、または読むよう指定された規約のファイル (差分カテゴリに対応した userRules + officialRules)**
 
 ## レビューの種類
 
-呼び出し元が「独立コードレビュー」「可読性・慣習レビュー」「規約照合」「実装の簡素化」のうち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 と対応づけて保持する。