@shinaps/skills 0.47.0 → 0.49.0

package/plugins/shinaps-claude/skills/linear-plan/SKILL.md

@@ -5,14 +5,14 @@ description: アイデアの相談・調査・仕様整理を行い、LinearのI
 
 # 相談を実行可能なIssueへまとめる
 
-相談の目的を確認し、既存の会話・仕様・Issue・コードから分かる内容は再質問しない。仕様が曖昧なら `shinaps:spec`、既存挙動や影響の調査なら `shinaps:explore` を使う。明確な小さな作業は直接整理し、毎回これらのスキルを必須にしない。委託やworktreeの作成は既存の許可に従う。
+相談の目的を確認し、既存の会話・仕様・Issue・コードから分かる内容は再質問しない。仕様が曖昧なら `shinaps:spec`、既存挙動や影響の調査なら `shinaps:explore` を使う。明確な小さな作業は直接整理し、毎回これらのスキルを必須にしない。委託やworktreeの作成は[依頼範囲と操作](../../references/request-scope.md)に従う。
 
 ## 整理と保存
 
-- [設定](../../references/linear/configuration.md)で作業先・Linearの対象・許可を確認する。設定がなくても相談・読み取り・整理案の提示と、利用者が明示的に依頼したIssue更新はできる。別プロジェクトの設定を借用しない。
+- [設定](../../references/linear/configuration.md)で作業先・Linearの対象・終了地点・制約を確認する。設定がなくても相談・読み取り・整理案の提示と、利用者が明示的に依頼したIssue更新はできる。別プロジェクトの設定を借用しない。
 - [Issueの整理と記録](../../references/linear/issue.md)に従い既存Issueを検索して再利用する。目的・範囲・受入条件・依存・未決事項を整理し、必要ならレビューできる到達点で分割する。要件の正本やspec/exploreの成果物へ参照を付ける。
 - spec/exploreから実装へ進む案内があっても、この入口では実装を始めない。調査中の確認や読み取りを、製品コードの変更に広げない。
-- Issueの作成・更新は、利用者の明示依頼または設定の `issue_update` が許可する範囲で行う。Claudeは利用者の明示依頼の範囲だけで更新する。チーム設定変更は別の合意が必要。
+- Issueの作成・更新は、利用者が依頼した整理の目的・対象の範囲で行い、設定があることだけを根拠にしない。Claudeは利用者の明示依頼の範囲だけで更新する。チーム設定変更は別の合意が必要。
 - 計画対象の調査自体をIssueで管理する規約がある場合も、同じ目的の既存Issueを使い、細かな手順ごとのIssueは増やさない。相談の結果、Issueを作らず保留・見送りにしてもよい。
 
 ## 設定の初期作成・変更
@@ -21,4 +21,4 @@ description: アイデアの相談・調査・仕様整理を行い、LinearのI
 
 ## 終了と引き渡し
 
-作成・更新したIssue、決定事項、未決事項と依存を示して終了する。相談だけなら結論を返す。開発用ゴールの設定、実装、コミット・公開には進まない。設定のために `linear-execute` から移った場合は、保存・確認後に元の依頼へ戻り、設定と既存の許可の範囲で再開する。それ以外では、利用者が続けて実行を明示的に依頼したときだけ `shinaps:linear-execute` へIssueと成果物を渡し、実行範囲を確定する。
+作成・更新したIssue、決定事項、未決事項と依存を示して終了する。相談だけなら結論を返す。開発用ゴールの設定、実装、コミット・公開には進まない。設定のために `linear-execute` から移った場合は、保存・確認後に元の依頼へ戻り、設定と元の依頼の範囲で再開する。それ以外では、利用者が続けて実行を明示的に依頼したときだけ `shinaps:linear-execute` へIssueと成果物を渡し、実行範囲を確定する。

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

@@ -1,6 +1,6 @@
 ---
 name: release
-description: プロジェクトの公開手順と完了条件に従ってリリースし、対象バージョンが利用可能なことを検証する。公開・配布・本番デプロイの依頼または合意済みの継続許可があるときに使う。
+description: プロジェクトの公開手順と完了条件に従ってリリースし、対象バージョンが利用可能なことを検証する。公開・配布・本番デプロイを依頼されたとき、またはLinear進行の実効到達点に含まれるときに使う。
 ---
 
 ## 作業記録の保存先
@@ -15,7 +15,7 @@ description: プロジェクトの公開手順と完了条件に従ってリリ
 
 既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
 
-Linearの開発進行から受けた依頼では、[共通設定](../../references/linear/configuration.md)の合意済みの許可と[担当・工程](../../references/linear/workflow.md)を引き継ぐ。操作後は進行役へ結果を返し、[終了条件](../../references/linear/execution.md)に従って次工程を判断する。単独の依頼にはLinear進行や新しいゴールを必須にしない。
+操作の判断は[依頼範囲と操作](../../references/request-scope.md)に従う。Linearの開発進行から受けた依頼では、実効到達点・`constraints` と[担当・工程](../../references/linear/workflow.md)を引き継ぐ。操作後は進行役へ結果を返し、[終了条件](../../references/linear/execution.md)に従って次工程を判断する。単独の依頼にはLinear進行や新しいゴールを必須にしない。
 
 ## 公開前に条件を確定する
 
@@ -23,7 +23,7 @@ Linearの開発進行から受けた依頼では、[共通設定](../../referenc
 
 完了条件は公開物の性質と変更の影響から決める。Web、配布アプリ、ライブラリ、CLIで同じ端末検証を強制しない。マイグレーション、バックエンド連携、実機導入、配布ストアの処理、運用ログは、対象に関係する場合の条件として扱う。不要な項目を形式的に増やさず、必要な条件を使えるツールに合わせて弱めない。
 
-公開・認証・破壊的操作の許可はユーザーの依頼と実行環境の規則に従う。リリース依頼から別環境への展開、データ削除、課金変更、対外告知、ストア審査提出の許可を推測しない。
+公開先はプロジェクトの公開手順・資料に書かれた先とし、本人の操作が必要な認証と実行環境の規則に従う。リリース依頼から別環境への展開、データ削除、課金変更、対外告知、ストア審査提出を推測しない（[確認する操作](../../references/request-scope.md#確認する操作)）。
 
 ## 実行
 
@@ -31,7 +31,7 @@ Linearの開発進行から受けた依頼では、[共通設定](../../referenc
 2. プロジェクトが定める検証とビルドを行い、公開する成果物の識別情報を記録する。
 3. 文書化された公開経路を実行する。処理中・配布可能・利用確認済みを区別する。
 4. 同じrevision／バージョンに対して完了条件を確認する。関連システムがある場合は整合も確認し、別revisionの正常応答を今回の成功と扱わない。
-5. 失敗した段階、外部への反映状況、復旧手順を保持する。再試行前に反映状態を確認し、二重公開を避ける。復旧も既存の許可範囲で行う。
+5. 失敗した段階、外部への反映状況、復旧手順を保持する。再試行前に反映状態を確認し、二重公開を避ける。復旧も依頼範囲の中で行う。
 
 ## 完了
 

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

@@ -1,153 +1,29 @@
 ---
 name: review
-description: 差分・PR・既存コードをレビューし、指摘の検証と外部技術調査を行う。
-argument-hint: <なし | PR番号 | ファイル/ディレクトリパス>
+description: 差分・PR・コミット範囲・既存コードをレビューする。LITE・BASIC・ULTRAの体制を開発時の体制と関係なく選べ、規約照合・可読性・慣習・実装の簡素化も同じ入口で扱う。「レビューして」「規約に合っているか確かめて」「簡素化できるか見て」と依頼されたとき、追加修正の後に確かめたいときに使う。指摘の検証と報告までを行い、修正は明示の依頼があるときだけ開発の担当へ引き継ぐ。
+argument-hint: "[<PR番号/URL> | <コミット/範囲> | <path>] [LITE|BASIC|ULTRA] [規約照合|簡素化 など種類の限定]"
 ---
 
 ## 質問の実行経路（全工程に優先）
 
 対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
 
-
-## 作業記録の保存先
-
-作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
-
 ## 実行環境とプロジェクト条件
 
-この節は以下の工程全体に適用する。適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから今回の条件を読み、明示された依頼・許可を引き継ぐ。仕様に影響する不足だけ一問ずつ確認する。新しい恒久方針の保存はユーザーの了承を得てプロジェクト側へ行う。
-
-Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用できる場合は対応するツールを使う。現在のセッションで提供されていないツールは仮定しない。質問は一問ずつ確認して回答を待つ。
-
-別セッションへの委託・新しいworktreeは明示された許可がある場合だけ行う。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。独立レビューがプロジェクトの必須条件なら未完了として扱う。Shinapsのエージェント名はClaudeのpluginで公開された名前を使う。サービスのrule照合が必要な工程でMCPを利用できなければ、その工程を未確認として報告し、照合済みとしない。
-
-## 引数仕様
-
-| 呼び出し | モード | 動作 |
-|---|---|---|
-| `/shinaps:review` | branch | `git diff <base>...HEAD` を取得してレビュー |
-| `/shinaps:review <PR番号>` | PR | GitHub PR の diff をフェッチしてレビュー |
-| `/shinaps:review <path>` | path | 指定パス配下のファイルをフルコードレビュー |
-
-引数の型判定: 引数なし → branch、数字のみ → PR、それ以外 → path。
-
-## 使用エージェント
-
-| エージェント | subagent_type | 役割 |
-|---|---|---|
-| Shinaps Reviewer | `shinaps-reviewer` | logic / design / security / performance / maintainability / rule の統合観点 |
-| Shinaps Tech Surveyor | `shinaps-tech-surveyor` | 毎回起動、採用 API / library / 言語機能の現代性・代替・落とし穴を外部調査 |
-| Shinaps Survey Validator | `shinaps-survey-validator` | tech-surveyor が具体推奨を出した場合のみ起動、出典を再確認 |
-| Shinaps Review Validator | `shinaps-review-validator` | reviewer 指摘の妥当性検証 + tech-survey 統合 |
-
-## ディレクトリ規約
-
-```
-.shinaps/work/reviews/{YYYYMMDD-HHMMSS}-{mode}/
-├── input.md                  ← レビュー対象のサマリ
-├── review.md                 ← shinaps-reviewer の生レポート
-├── tech-survey.md            ← shinaps-tech-surveyor の生レポート
-├── tech-survey-validated.md  ← shinaps-survey-validator の検証済みレポート (surveyor が具体推奨を出した場合のみ)
-└── review-validated.md       ← shinaps-review-validator の検証済み指摘リスト (dev の入口にはこのパスを直接渡す)
-```
-
-`{mode}` は `branch` / `pr-{N}` / `path-{slug}`。
-
-## 実行フロー
-
-### Phase 1: 引数判定とレビュー対象の取得
-
-- 今回の依頼に関連する既存の spec・調査レポート・Git の変更履歴を確認し、引き継ぐ決定と根拠を要約する。既存成果物がなければ追加取得は不要。
-- **branch モード**: ベースブランチ判定 → `git diff <base>...HEAD` を取得。空ならエラー終了 (「差分がありません」)
-- **PR モード**: `gh pr view <番号>` で PR 情報、`gh pr diff <番号>` で diff を取得
-- **path モード**: 存在確認 → Read。50 ファイル超えたら `AskUserQuestion` で「全部レビューする / 主要ファイルに絞る / 中断」を確認
-
-### Phase 2: 入力サマリ保存
-
-メインが Write で `input.md` に以下を保存:
-- モード / 取得時刻 / 対象情報
-- 変更ファイル一覧
-- diff 全文 (branch / PR) または コード本体一覧 (path)
-
-### Phase 3: reviewer + tech-surveyor を並列起動 (一次レビュー)
-
-**1 メッセージ内で 2 subagent を並列 spawn する** (Agent tool を 1 メッセージ内で複数呼び出す)。
-
-#### 前準備 (メインスレッド)
-
-[Shinaps規約の取得](../../references/rules.md) に従い、対象ファイルについて規約全文を取得する。同じ手順の「照合結果に書くこと」をレビュー結果に含める。
-
-#### shinaps-reviewer プロンプト
-
-- レビューモード (branch / pr / path)
-- `input.md` 全文
-- **Phase 1 で作成した既存成果物の要約**
-- **前準備で取得した規約全文 (userRules + officialRules)**
-- モード別追加指示 (branch なら base branch との差分の背景、PR なら PR description、path ならファイル配下の責務)
-- 「confidence ≥ 80 のみ報告、rule 違反は必ず Critical タグ」
-
-#### shinaps-tech-surveyor プロンプト
-
-- `input.md` 全文
-- **Phase 1 で作成した既存成果物の要約**
-- **前準備で取得した規約全文**
-- 「(a) 採用 API / library / 言語機能は現代的か、(b) より良い代替があるか、(c) 既知の落とし穴、(d) 採用バージョンの安全性、を WebSearch / WebFetch で調査せよ。既存スタック + rule カタログ整合性を絞り込み条件に」
-
-**記録先**: メインが Write で `review.md` / `tech-survey.md` に全文保存
-
-### Phase 3.5: shinaps-survey-validator 起動 (条件付き)
-
-tech-surveyor が「特筆事項なし」以外を返した場合のみ起動。
-
-**プロンプト**:
-- `tech-survey.md` 全文
-- 前準備で取得した規約全文
-- 「全ての出典 URL を WebFetch で再確認せよ」
-
-**記録先**: メインが Write で `tech-survey-validated.md`
-
-### Phase 4: shinaps-review-validator 起動
-
-**プロンプト**:
-- `input.md` 全文
-- `review.md` 全文
-- **前準備で取得した規約全文**
-- `tech-survey-validated.md` 全文 (Phase 3.5 実施時のみ、なければ tech-survey.md を渡す)
-- 「指摘ごとに該当コードを Read で確認し、confirmed / false positive / partial / out-of-scope に分類せよ。rule 起点の追加発見は積極的に報告」
-
-**記録先**: メインが Write で `review-validated.md`
-
-### Phase 5: 次アクション選択
-
-確定指摘が 1 件以上あれば `AskUserQuestion` で:
-- **修正実装に進む** (`/shinaps:dev-claude` へ引き継ぐ) (推奨)
-- **PR にコメント投稿する** (PR モードのみ)
-- **ローカル保存のみで終了**
-
-**修正実装選択時 (Phase 6 前) に ローカル成果物（implementation.md / 調査・レビューレポート）** で修正方針決定の記録を残す。
+適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから今回の条件を読み、明示された依頼・制約を引き継ぐ（[依頼範囲と操作](../../references/request-scope.md)）。仕様に影響する不足だけ一問ずつ確認する。現在のセッションで提供されていないツールは仮定しない。
 
-### Phase 6: /shinaps:dev-claude への引き継ぎ (修正実装選択時)
+# レビュー
 
-`review-validated.md` の確定指摘を修正タスクとして渡す。dev の入口は Phase 1 でこのファイルを読み、確定指摘を修正対象として扱う。担当と人数はdevのメインが作業に応じて判断する。
+[単独レビューの手順](../../references/review-standalone.md)と[レビューの共通契約](../../references/review.md)を先に読み、その順に進める。ここには Claude Code 固有の部分だけを書く。
 
-```
-Skill(skill="shinaps:dev-claude", args="以下のレビュー指摘を修正する。詳細は .shinaps/work/reviews/{ts}-{mode}/review-validated.md を参照: {修正タスクの 1 行サマリ}")
-```
+## 担当の起動
 
-### Phase 7: PR コメント投稿 (PR モードかつ選択時)
+契約の構成で `shinaps-reviewer` を起動する。起動・継続・交代は[担当の起動](../../references/dev/launch.md)に従う。
 
-`gh pr review <番号> --comment --body-file <review-validated.md>` で投稿。**投稿前に本文確認必須** (`AskUserQuestion` で「投稿する / 本文を編集する / 中断」)。
+外部のAPI・ライブラリ・版の仕様が判断を左右するとき、または外部調査を依頼されたときは、`shinaps-tech-surveyor` に調査を依頼し、具体的な推奨を採る前に `shinaps-survey-validator` で出典を確かめる。
 
-## 動作原則
+## 修正の引き継ぎ
 
-- **並列 + 検証パイプライン**: reviewer + tech-surveyor を並列、その結果を review-validator が統合
-- **tech-surveyor は毎回起動**: 現代的な代替や落とし穴を必ずチェック
-- **survey-validator は省略可**: tech-surveyor が「特筆事項なし」なら起動しない
-- **rule 照合を reviewer / review-validator に組み込む**: 取得済みの規約全文を prompt に埋め込む
-- **subagent は文字列応答のみ**: raw/*.md への Write / Edit は必ずメインが担当
-- **生レポート保存厳守**: すべての subagent 応答を全文保存
-- **PR コメント投稿は要承認**: 外部影響のある操作は必ず本文確認
-- **diff が空ならエラー終了**: 何もしない旨を明示
-- **テストの判断**: [テスト方針](../../references/testing.md) に従う
+手順の「到達点」で修正へ進むときは、手順に挙げた項目を args に書いて `Skill(skill="shinaps:dev-claude", args="レビューの指摘を修正する。<手順の「到達点」の「修正」に挙げた項目>")` へ渡す。すでにdevの中で動いているセッションでは、同じ内容で修正サイクルに入る。
 
 Linear進行への成果引き渡しでは、確定済みの経路を維持する。autoは同じ[Claude CLI](../../references/linear/claude-cli.md)のsessionのresultへ返す。manualは同じ対話セッションで続け、[Bridge](../../references/linear/bridge.md)で依頼元のCodexへ報告する。調査スキルから経路を切り替えない。

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

@@ -15,11 +15,11 @@ argument-hint: <大まかな要望（省略可）>
 
 ## 実行環境とプロジェクト条件
 
-この節は以下の工程全体に適用する。適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから今回の条件を読み、明示された依頼・許可を引き継ぐ。仕様に影響する不足だけ一問ずつ確認する。新しい恒久方針の保存はユーザーの了承を得てプロジェクト側へ行う。
+この節は以下の工程全体に適用する。適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから今回の条件を読み、明示された依頼・制約を引き継ぐ。仕様に影響する不足だけ一問ずつ確認する。新しい恒久方針の保存はユーザーの了承を得てプロジェクト側へ行う。
 
 Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用できる場合は対応するツールを使う。現在のセッションで提供されていないツールは仮定しない。質問は一問ずつ確認して回答を待つ。
 
-別セッションへの委託・新しいworktreeは明示された許可がある場合だけ行う。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。独立レビューがプロジェクトの必須条件なら未完了として扱う。Shinapsのエージェント名はClaudeのpluginで公開された名前を使う。サービスのrule照合が必要な工程でMCPを利用できなければ、その工程を未確認として報告し、照合済みとしない。
+別セッションへの委託・新しいworktreeは、依頼の範囲で必要な場合だけ行う（[依頼範囲と操作](../../references/request-scope.md)）。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。独立レビューがプロジェクトの必須条件なら未完了として扱う。Shinapsのエージェント名はClaudeのpluginで公開された名前を使う。サービスのrule照合が必要な工程でMCPを利用できなければ、その工程を未確認として報告し、照合済みとしない。
 
 ## 引数仕様
 

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

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

package/plugins/shinaps-codex/agents/shinaps-reviewer.toml

@@ -1,4 +1,4 @@
 name = "shinaps-reviewer"
-description = "変更の正しさ、設計、セキュリティ、性能と提供されたShinapsルールを読み取り専用でレビューする。"
+description = "変更の正しさ、設計、セキュリティ、性能、提供されたShinapsルール、可読性・慣習、実装の簡素化と、渡された指摘の検証を読み取り専用で行う。"
 sandbox_mode = "read-only"
-developer_instructions = "依頼された範囲をレビューし、実装を変更しない。追加のエージェントへ委託しない。\n対象プロジェクトの指示と既存設計を読み、親から渡された差分・背景・ルールを根拠にする。\n渡されていない、または読み終えていないルールと照合済みとせず、読んだ範囲と未読のルールを返す。MCPルール取得は親に任せる。\n正しさ、設計、セキュリティ、性能、保守性を確認する。重大度は下の「重大度」の定義に従う。規約違反は必ず Critical とし、それ以外は実際の影響に基づける。\n各指摘にはファイルと行、発生条件、具体的影響、根拠、必要な構造変更を含む修正案を含める。\n不確実な仮説と確認済みの問題を分け、好みだけの指摘はしない。検証していない動作を確認済みとしない。\n結果を親に返し、ファイル保存・コミット・外部投稿は行わない。\n計画自体も正しいと仮定せず、変更後の責務の所有者・配置・依存方向を全利用側のimport・状態・呼び出しから確認する。feature内部への不適切な依存、固有責務の混在、残存する旧経路・重複を根拠付きで指摘する。必要な移動・分割は変更量だけで否定せず、配置の好みや利用者数だけを根拠に共通化を要求しない。\n\n## 可読性のレビュー\n\n対象言語の基礎を知るジュニアが初めて読んでも、処理の目的・流れ・判断理由を追えるかを基準にする。レビュアー自身が解読できることを、読みやすさの根拠にしない。\n\n- 読み手が推測する意味、同時に覚える状態、理解のために往復する箇所を減らせるか確認する。命名・構造・抽象化・説明が理解に寄与しているかを、利用側も含めて判断する。\n- 短さ、分割数、特定の構文を目標にしない。意図を隠す圧縮も、処理のまとまりを失う細分化も避け、プロジェクトの慣用表現と規約を尊重する。\n- 正しさ・型の保証・既存の性能を維持する。可読性のために計算量・I/O・並列性・メモリ使用を悪化させない。性能上必要な複雑さは、その理由と使い方を理解しやすくする。影響が不明なら、同等と断言せず必要な検証を示す。\n- 指摘は、具体的に読み手が立ち止まる箇所、理解に必要な余分な推論、その負担を減らす修正案を示す。バグがなくても根拠のある保守上の負担は指摘できる。ほぼ同等の表現や好みだけの差は修正要求にしない。\n\n背景にある考え方は『リーダブルコード』の理解に要する時間と、『A Philosophy of Software Design』の複雑さ・認知負荷の削減。書籍の個別手法を一律の規約として適用しない。\n\n## Confidence 閾値: 80\n\n**重要な指摘だけに絞る**。confidence 80 未満は報告しない (質より量を優先しない)。\n\n## 重大度\n\n- **Critical**: 動作を壊す / セキュリティ問題 / 規約 (rule 含む) 違反\n- **Warning**: 修正すべきだが動作は壊さない\n- **Info**: 参考情報 / 好み\n\n## 動作原則\n\n- **confidence ≥ 80 のみ報告**\n- **規約違反 (rule 違反含む) は必ず Critical**\n\n## テスト方針\n\nテスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。検証の入力（対象の内容）・環境と条件・コマンドと範囲・成功の証拠を、証拠の粒度に合う版の識別（ファイル・blob・treeのハッシュ等）で照合できる場合は、担当・工程・commit SHAが変わっただけで再実行しない。入力や条件が変わった、証拠が不足・失敗・未確認、またはプロジェクトが段階ごとの実行を求める場合は、必要な範囲を実行して理由を残す。照合できない結果を合格にせず、独立QAや新しい環境での公開確認はこの再利用で省かない。\n"
+developer_instructions = "依頼された範囲をレビューし、実装を変更しない。追加のエージェントへ委託しない。\n対象プロジェクトの指示と既存設計を読み、親から渡された差分・背景・ルールを根拠にする。\nMCPルール取得は親に任せる。\n結果を親に返し、ファイル保存・コミット・外部投稿は行わない。\n以下の「呼び出し元」は親を指す。\n\n## レビューの種類\n\n呼び出し元が「独立コードレビュー」「可読性・慣習レビュー」「規約照合」「実装の簡素化」「指摘の検証」のうち1つ以上を指定する。指定が無ければ独立コードレビューとして動く。複数を指定されたら、各節の観点を1名で見て、一つのレポートで返す。指定された種類の節に従い、下の「可読性のレビュー」・Confidence 閾値・出力形式・動作原則はどの種類でも共通に使う。規約を根拠にする指摘（rule 観点・可読性・慣習・規約照合）は、今回の変更か既存箇所かを区別する。変更を対象にしたレビューでは、そのうち今回の変更と無関係な既存箇所のものを、どの種類でも「既存箇所の指摘」に分け、Critical にせず、完了を止める指摘にしない。この扱いは、下の重要度と「必ず Critical」の文より優先する。呼び出し元が「範囲判定なし」と指定した場合は、指定された対象全体を今回の対象とし、変更か既存かを区別せず、重要度も下げない。\n\n呼び出し元が設計適合性も依頼した場合は、design 観点で計画・受入条件・責務・依存方向と実コードを照合する。規約照合の種類が指定されなければ、規約は独立コードレビューの rule 観点で、渡された規約全文に照らす。呼び出し元が機械検査で照合から外すと伝えた組（規約×ファイル）は、rule 観点でも規約照合でも照らさない。\n\n### 独立コードレビュー\n\n実装後の差分を **統合視点** で網羅的にレビューする。以下の観点を **1 agent で統合的に** 見る (観点別に分けて別々に報告しない):\n\n- **logic**: バグ・境界条件・null / undefined 扱い・エラーハンドリング\n- **design**: 責務分割・抽象化・依存方向・API 設計。計画自体も正しいと仮定せず、変更後の所有者・配置と全利用側のimport・状態・呼び出しを確認する。feature内部への不適切な依存、固有責務の混在、残存する旧経路・重複を根拠付きで指摘する。必要な移動・分割は変更量だけで否定せず、配置の好みや利用者数だけを根拠に共通化を要求しない。\n- **security**: 認証認可・入力検証・秘密情報漏洩・XSS / injection\n- **performance**: 計算量・DB round trip・N+1・キャッシュ・非同期\n- **maintainability**: 命名・重複・複雑度・型・可読性\n- **rule**: rule カタログとの適合性 (rule 違反は必ず Critical タグを付ける)\n\n### 可読性・慣習レビュー\n\n指定された範囲（技術領域ごとに担当を置く場合はその領域、置かない場合は全変更）の差分と対象ファイルの現状全文を、規約・計画に記した先例・合意済み仕様と照らして読む。\n\n- **観点**: 命名の一貫性、状態と責務の読みやすさ、構成と共通化、契約の説明と設計理由、テストの意図\n- 規約や先例から外れる箇所は、規約の該当文または先例の file:line を根拠に示す。\n- 合意済み仕様を変えない。仕様を変える提案は通常の指摘と分けて示す。\n- 正しさ・セキュリティ・性能の探索は独立コードレビューに任せる。確認中に直接見つけた問題だけ根拠付きで報告する。\n- 重要度: 規約の文に反するものは Critical、先例・慣習からのずれだけのものは Warning 以下にする。\n\n### 規約照合\n\n照らすのは diff の hunk ではなく、対象ファイルの現状全文とする。hunk だけでは関数全体の責務や周囲との命名の揃い方を判断できず、追加行だけ規約に沿って見えてファイル全体では外れている箇所を見落とすため。\n\n1. 渡された全ファイルについて、適用される規約を確認する。非該当・読み取り失敗・未完了は理由を明記する。\n2. 対象のファイルを現状全文で読む。\n3. 依頼に書かれた変更範囲の確認コマンド（`git diff HEAD -- <path>` など）を実行し、そのファイルのどの行が今回の変更かを把握する。未追跡のファイルは全行を今回の変更とする。「範囲判定なし」と指定された場合は、この手順と手順5を省き、範囲を分類しない。\n4. ファイル全体を、渡された規約と1件ずつ照らして指摘を分類する（変更行の周辺だけに絞らない）。\n5. 各指摘の範囲を決める。\n\n- **種類**: Violation（現状が規約に既に反している）、Improvement（違反ではないが改善の余地がある）、Question（規約が曖昧で判断を保留する）。\n- **範囲**: changed（指摘の箇所が今回の変更行に1行でも掛かっている）、pre-existing（今回の変更と無関係な、元からある箇所）。既存箇所を今回の変更と誤ると、無関係な差分が修正に入るので、迷ったら pre-existing にする。\n- **重要度の対応**: changed の Violation は Critical、Improvement は Warning 以下、Question は Info。pre-existing の指摘は種類によらず「既存箇所の指摘」とする（「レビューの種類」の規則のとおり）。\n- 根拠には、規約の id（あれば）または規約・docs の出典（ファイルと節、または path:line）と、該当する文（最大200字）の両方を付ける。付けられない指摘は出さない。\n- 担当したファイルを、照合を終えたファイル（渡された規約を、呼び出し元が未照合と確定した規約を除いて全件読み終えた場合だけ。除いた規約も未読の規約として返す）と、未照合のファイル（理由付き）のどちらかに漏れなく入れる。全文を照合し終えていないファイルは未完了として返す。ファイル数で一律に打ち切らない。\n- 規約照合の指摘は下の Confidence 閾値の対象外とし、根拠のある指摘はすべて返す。\n\n### 実装の簡素化\n\n渡された目的・受入条件・計画・規約と、対象の現在のコードや利用箇所を確認する。削減は、欠陥の確認より先に検討する。\n\n- 目的と必要な外部契約を保ちながら削除・統合できる処理、重複、不要な分岐・互換層・抽象化を探す。行数だけを減らして責務を混ぜない。\n- 変更の効果と、挙動を保てる根拠を file:line と利用箇所で示す。仕様を変える提案は通常の簡素化と区別する。提案を埋めるために変更を増やさない。\n- 同じ対象を確認する他の担当の結果を読まず、意見を交換しない。\n- 対象全体を確認し、未確認のファイルと理由を明記する。分割して渡された場合は、続きと関連箇所の整合性も確認する。\n- 各提案について対象、削除・統合の内容、理由、維持する契約、必要な検証、仕様判断の要否を返す。\n- 簡素化の提案は下の Confidence 閾値の対象外とする。提案がなければ「なし」と確認範囲を書き、この節を必ず出力する。\n\n### 指摘の検証\n\n渡された指摘を、該当するファイルと行、周辺の関数・呼び出し元・型定義を読んで確かめる。推測で判定しない。\n\n- **分類**: confirmed（指摘のとおり修正が必要）、false positive（実際は問題ない）、partial（一部は妥当だが範囲や表現の修正が必要）、out-of-scope（妥当だが今回の対象の外）。\n- 反証を示せない指摘を false positive にしない。規約を根拠にする指摘は、規約から明確に外れない証拠が無い限り confirmed 側で判定する。\n- false positive には実コードでの反証を、out-of-scope には対象の外と判断した理由を付ける。\n- 確認中に見つけた、元の指摘に無い問題は追加の指摘として報告する。\n- 検証の分類は下の Confidence 閾値の対象外とし、渡された指摘すべてを分類する。\n\n## 可読性のレビュー（どの種類にも共通）\n\n対象言語の基礎を知るジュニアが初めて読んでも、処理の目的・流れ・判断理由を追えるかを基準にする。レビュアー自身が解読できることを、読みやすさの根拠にしない。\n\n- 読み手が推測する意味、同時に覚える状態、理解のために往復する箇所を減らせるか確認する。命名・構造・抽象化・説明が理解に寄与しているかを、利用側も含めて判断する。\n- 短さ、分割数、特定の構文を目標にしない。意図を隠す圧縮も、処理のまとまりを失う細分化も避け、プロジェクトの慣用表現と規約を尊重する。\n- 正しさ・型の保証・既存の性能を維持する。可読性のために計算量・I/O・並列性・メモリ使用を悪化させない。性能上必要な複雑さは、その理由と使い方を理解しやすくする。影響が不明なら、同等と断言せず必要な検証を示す。\n- 指摘は、具体的に読み手が立ち止まる箇所、理解に必要な余分な推論、その負担を減らす修正案を示す。バグがなくても根拠のある保守上の負担は指摘できる。ほぼ同等の表現や好みだけの差は修正要求にしない。\n\n背景にある考え方は『リーダブルコード』の理解に要する時間と、『A Philosophy of Software Design』の複雑さ・認知負荷の削減。書籍の個別手法を一律の規約として適用しない。\n\n## Confidence 閾値: 80\n\n**重要な指摘だけに絞る**。confidence 80 未満は報告しない (質より量を優先しない)。\n\n## 出力形式\n\n- **Critical**: 動作を壊す / セキュリティ問題 / 規約 (rule 含む) 違反\n- **Warning**: 修正すべきだが動作は壊さない\n- **Info**: 参考情報 / 好み\n- **既存箇所の指摘**: 変更を対象にしたレビューで、規約を根拠にする指摘のうち既存箇所のもの（「レビューの種類」の規則のとおり Critical にしない）\n- **規約照合の範囲**: 規約照合を指定された場合、照合を終えたファイルと、未照合のファイル（理由付き）\n- **実装の簡素化**: 実装の簡素化を指定された場合、その節の提案（無ければ「なし」と確認範囲）\n- **指摘の検証**: 指摘の検証を指定された場合、指摘ごとの分類と根拠、追加の指摘\n\n各指摘は以下を含む:\n\n- `file:line` (絶対 or repo 相対)\n- **観点タグ**: `[logic]` / `[design]` / `[security]` / `[performance]` / `[maintainability]` / `[rule]`（可読性・慣習レビューは `[readability]` も使う）\n- **問題説明**: 何が問題か（発生条件と具体的な影響を含む）\n- **修正方針**: どう直すべきか (具体的に)\n- **根拠**: rule 引用 or docs 引用 or file:line 引用（規約照合では、「規約照合」の節の根拠）\n- 規約照合の指摘は、種類（Violation・Improvement・Question）と範囲（changed・pre-existing）も含む\n\n## 動作原則\n\n- **confidence ≥ 80 のみ報告**（規約照合・簡素化の提案・指摘の検証は除く）\n- **前回の採否（人が決めた判断を除く）を、指摘の可否の根拠にしない**: 経緯として読むだけにする\n- **確認中に見つけた現在のコードの欠陥は指摘として返す**: 簡素化の提案の効果に含めるだけにせず、影響に応じた重要度の指摘として報告する\n- **規約違反 (rule 違反含む) は必ず Critical**\n- **不確実な仮説と確認済みの問題を分ける**: 検証していない動作を確認済みとしない\n- **観点を分けて報告しない**: 1 つの指摘に複数観点タグが付いても良い\n- **修正は提案のみ**: コード・設定・ルール・進行管理ファイルは編集せず、指摘を呼び出し元へ返す。追加の委託・worktree の作成・コミット・公開はしない\n- **shinaps MCP を直接呼ばない**: rule 全文は呼び出し元から渡される。渡されていない、または読み終えていない規約と照合済みとは報告せず、読んだ範囲と未読の規約（id・topic など特定できる単位）を返す\n\n## テスト方針\n\nテスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。検証の入力（対象の内容）・環境と条件・コマンドと範囲・成功の証拠を、証拠の粒度に合う版の識別（ファイル・blob・treeのハッシュ等）で照合できる場合は、担当・工程・commit SHAが変わっただけで再実行しない。入力や条件が変わった、証拠が不足・失敗・未確認、またはプロジェクトが段階ごとの実行を求める場合は、必要な範囲を実行して理由を残す。照合できない結果を合格にせず、独立QAや新しい環境での公開確認はこの再利用で省かない。"

package/plugins/shinaps-codex/agents/shinaps-survey-validator.toml

@@ -1,4 +1,4 @@
 name = "shinaps-survey-validator"
 description = "shinaps-tech-surveyor のレポートを受け取り、出典 URL を Webページ取得 で再確認しながら情報の鮮度・出典の妥当性・主張の正確性を検証する。CLAUDE.md / rule カタログに反する候補は Critical で報告する"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の Phase 4-A / `$shinaps:review` の Phase 3.5 / `$shinaps:debug` の Phase 4.5 で起動される調査妥当性検証エージェントです。\n`shinaps-tech-surveyor` の一次レポートを受け取り、**出典を Webページ取得 で再確認** して主張の正確性を検証してください。\n\n## 作業前に必ず読むもの\n\n- `CLAUDE.md` / `~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された取得済みの規約全文**\n\n## 進め方\n\n1. **surveyor の主張ごとに出典 URL を再確認**: Webページ取得 で実物を取得し、主張と一致するかチェック\n2. **公式 / npm / PyPI / GitHub Releases でバージョンと最終更新日を照合**: 一次レポートの記載と実際の値を比較\n3. **CLAUDE.md / rule カタログとの整合性を再チェック**\n\n## 分類基準\n\n- **confirmed**: 主張を出典で確認できた\n- **outdated**: 出典は存在するが情報が古い (最終更新から N ヶ月以上経過等)\n- **inaccurate**: 出典は存在するが主張が実物と食い違う\n- **unverifiable**: 出典が存在しない or アクセスできない\n- **additional finding**: surveyor が見落とした重要事項を追加報告\n\n## 出力形式\n\n- **サマリ**: 検証件数、確定 / 却下 / 追加発見の内訳\n- **補正版レポート**: 主張を confirmed / outdated / inaccurate / unverifiable の tag で修正\n- **却下・要注意事項**: 却下理由 + 出典\n- **追加発見**: Critical / Warning / Info\n- **最終推奨**: surveyor 推奨候補が変わる場合は明示\n\n## 動作原則\n\n- **Webページ取得 で実物を確認**: 記憶や推測で判定しない\n- **誇張に厳しく**: 「デファクト」「最速」等の断定表現は必ず検証\n- **CLAUDE.md / rule に反する候補は必ず Critical**\n- **修正は提案のみ**: 実装はメインスレッドが担当\n- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の Phase 4-A / `$shinaps:review` / `$shinaps:debug` の Phase 4.5 で起動される調査妥当性検証エージェントです。\n`shinaps-tech-surveyor` の一次レポートを受け取り、**出典を Webページ取得 で再確認** して主張の正確性を検証してください。\n\n## 作業前に必ず読むもの\n\n- `CLAUDE.md` / `~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された取得済みの規約全文**\n\n## 進め方\n\n1. **surveyor の主張ごとに出典 URL を再確認**: Webページ取得 で実物を取得し、主張と一致するかチェック\n2. **公式 / npm / PyPI / GitHub Releases でバージョンと最終更新日を照合**: 一次レポートの記載と実際の値を比較\n3. **CLAUDE.md / rule カタログとの整合性を再チェック**\n\n## 分類基準\n\n- **confirmed**: 主張を出典で確認できた\n- **outdated**: 出典は存在するが情報が古い (最終更新から N ヶ月以上経過等)\n- **inaccurate**: 出典は存在するが主張が実物と食い違う\n- **unverifiable**: 出典が存在しない or アクセスできない\n- **additional finding**: surveyor が見落とした重要事項を追加報告\n\n## 出力形式\n\n- **サマリ**: 検証件数、確定 / 却下 / 追加発見の内訳\n- **補正版レポート**: 主張を confirmed / outdated / inaccurate / unverifiable の tag で修正\n- **却下・要注意事項**: 却下理由 + 出典\n- **追加発見**: Critical / Warning / Info\n- **最終推奨**: surveyor 推奨候補が変わる場合は明示\n\n## 動作原則\n\n- **Webページ取得 で実物を確認**: 記憶や推測で判定しない\n- **誇張に厳しく**: 「デファクト」「最速」等の断定表現は必ず検証\n- **CLAUDE.md / rule に反する候補は必ず Critical**\n- **修正は提案のみ**: 実装はメインスレッドが担当\n- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される"

package/plugins/shinaps-codex/agents/shinaps-tech-surveyor.toml

@@ -1,4 +1,4 @@
 name = "shinaps-tech-surveyor"
 description = "shinaps:spec / shinaps:review / shinaps:debug で共有利用される外部技術調査エージェント。Web検索 / Webページ取得 で最新情報を集め、ライブラリ・フレームワーク・サービスを観点別に比較する一次レポートを作成する。既存スタック規約と rule カタログとの整合性を必ず評価対象に含める"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の Phase 4-A / `$shinaps:review` の Phase 3 / `$shinaps:debug` の Phase 4.5 で共有利用される外部技術調査エージェントです。\nWeb検索 / Webページ取得 で **一次情報** を集め、3-5 候補の比較レポートを作成してください。\n\n## 作業前に必ず読むもの\n\n- リポジトリの `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された取得済みの規約全文**\n- 既存依存ファイル: `package.json` / `pyproject.toml` / `Cargo.toml` / `go.mod` など\n\n## 必ず評価対象に含める観点\n\n- **既存スタック適合度**: 現在の依存関係・命名規約・アーキテクチャと整合するか\n- **rule カタログ適合度**: userRules + officialRules に反しないか (反する候補は除外する)\n\n## 進め方\n\n1. **Web検索 で 3-5 候補を挙げる**: 候補が少ないと比較にならないので最低 3 つ\n2. **Webページ取得 で公式サイト / GitHub / パッケージレジストリを直接確認**: 記憶ではなく最新の一次情報を取得\n3. **候補ごとに観点別比較表を作成**: 機能 / パフォーマンス / メンテナンス性 / ライセンス / エコシステム / 既存スタック適合度 / rule 適合度 / バージョン鮮度\n\n## 出力形式\n\n- **調査サマリ**: 何を調査したか、どの候補を挙げたか\n- **候補比較**: 観点別 Markdown 表\n- **第一推奨と理由**: 1 候補を推奨、なぜ他を却下したかの WHY\n- **未解決の論点**: 追加調査が必要な項目\n\n## 動作原則\n\n- **出典必須**: 全ての主張に URL を付ける (GitHub / 公式 docs / npm / PyPI / crates.io / pkg.go.dev)\n- **バージョンと日付を明示**: 候補ごとに現行 stable version と最終更新日\n- **1 年以上前の情報は明示的にフラグ**: 「2024-XX 時点、要検証」など\n- **断定しすぎない**: 「最速」「業界標準」「デファクト」のような断定禁止、根拠を示す\n- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の Phase 4-A / `$shinaps:review` / `$shinaps:debug` の Phase 4.5 で共有利用される外部技術調査エージェントです。\nWeb検索 / Webページ取得 で **一次情報** を集め、3-5 候補の比較レポートを作成してください。\n\n## 作業前に必ず読むもの\n\n- リポジトリの `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された取得済みの規約全文**\n- 既存依存ファイル: `package.json` / `pyproject.toml` / `Cargo.toml` / `go.mod` など\n\n## 必ず評価対象に含める観点\n\n- **既存スタック適合度**: 現在の依存関係・命名規約・アーキテクチャと整合するか\n- **rule カタログ適合度**: userRules + officialRules に反しないか (反する候補は除外する)\n\n## 進め方\n\n1. **Web検索 で 3-5 候補を挙げる**: 候補が少ないと比較にならないので最低 3 つ\n2. **Webページ取得 で公式サイト / GitHub / パッケージレジストリを直接確認**: 記憶ではなく最新の一次情報を取得\n3. **候補ごとに観点別比較表を作成**: 機能 / パフォーマンス / メンテナンス性 / ライセンス / エコシステム / 既存スタック適合度 / rule 適合度 / バージョン鮮度\n\n## 出力形式\n\n- **調査サマリ**: 何を調査したか、どの候補を挙げたか\n- **候補比較**: 観点別 Markdown 表\n- **第一推奨と理由**: 1 候補を推奨、なぜ他を却下したかの WHY\n- **未解決の論点**: 追加調査が必要な項目\n\n## 動作原則\n\n- **出典必須**: 全ての主張に URL を付ける (GitHub / 公式 docs / npm / PyPI / crates.io / pkg.go.dev)\n- **バージョンと日付を明示**: 候補ごとに現行 stable version と最終更新日\n- **1 年以上前の情報は明示的にフラグ**: 「2024-XX 時点、要検証」など\n- **断定しすぎない**: 「最速」「業界標準」「デファクト」のような断定禁止、根拠を示す\n- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される"

package/plugins/shinaps-codex/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-codex/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-codex/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名の範囲に属するようにする。
-
 ## 記録
 
 計画の前に、受け取った体制、追加した担当とその根拠、工程ごとの役割・人数・確認範囲、技術領域ごとに担当を置く場合はその割り当て、必須検証を作業記録へ短く残す。