@shinaps/skills 0.48.0 → 0.49.0

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

package/plugins/shinaps-codex/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-codex/references/dev/launch.md

@@ -1,6 +1,6 @@
 # 担当の起動（Codex）
 
-review・debug・spec・refine・explore のCodexスキルが、名前を挙げる登録済みの担当を Codex のサブエージェントで起動・継続する手順。
+review・debug・spec・explore のCodexスキルが、名前を挙げる登録済みの担当を Codex のサブエージェントで起動・継続する手順。
 
 - 委託できるかは[依頼範囲と操作](../request-scope.md)で判断し、操作ごとの許可は求めない。利用者または作業先の制約が委託を禁止した場合と、Codexの実行環境がサブエージェントの起動に利用者の明示依頼を求めていてその依頼がない場合は委託しない（実行環境が強制する条件）。
 - 担当は `spawn_agent` で起動し、毎回 `agent_type`（役割定義名。例 `shinaps-reviewer`）と `fork_turns: "none"` を明示する。`fork_turns` を省略すると親の履歴を引き継ぎ、独立した担当にならない。役割定義には model を書かないので、`model`・`reasoning_effort` はスキルが指定する場合だけ明示し、指定がなければ親セッションから継承する。親セッションの設定は変更しない。

package/plugins/shinaps-codex/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名の範囲に属するようにする。
-
 ## 記録と引き渡し
 
 設計を始める前に、選んだ体制、追加した担当とその根拠、工程ごとの役割・人数・確認範囲、技術領域ごとに担当を置く場合はその割り当て、必須検証を短く記録する。独立した担当は、実装したメインとは別のコンテキストにする。

package/plugins/shinaps-codex/references/dev/workflow.md

@@ -23,9 +23,9 @@ devの依頼は登録済みのdev役割への委託（Agentでの起動）を含
 
 - 異なる役割と独立比較の担当は別コンテキストで起動する。担当番号を起動前に固定し、同じ役割の継続は同じIDを使う。再開できない場合（resumeをまたぐ場合を含む）は同じ役割へ既存の成果・最新の差分・未解決点を引き継いで交代を記録する。
 - 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・依頼するレビューの種類を依頼に渡す（独立設計担当への依頼はPhase 3に従う）。担当は読み取り専用で、自分でエージェントを起動しない。
-- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませず意見交換させない。継続担当には前回の確定済み指摘と採否を渡してよい。対象を編集中にレビューせず、全結果が揃うまでメインは対象を変えない。外部変更が入れば影響範囲を同じ最新の版で確認し直す。
-- メインは、依頼の確認、体制と工程の調整、調査・設計・計画の統合・実装・検証・修正、指摘の検証と採否、修正計画、担当の起動・待機・全文保存、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。体制が求める独立確認（独立案・計画の独立確認・実装後の独立レビュー）をメインの自己確認で代えない。起動失敗・空回答・未確認範囲を「指摘なし」にしない。
-- devの完了後に同じ会話・sessionで来る依頼（対話の次のターン、resume、Bridge、人の相談、QA差し戻し）も同じdevとして扱う。質問への回答と人の指摘の調査は、メインが読み取りだけで行い、編集は修正サイクルで行う。初回devの完了・短い追加依頼・通常の会話への復帰を例外にしない。Codexが[UIの微調整](../linear/workflow.md#codexによるuiの微調整)で返した差分は、メインが取り込み、現在の工程の差分として検証し、既存のレビューを続ける（回数はリセットしない）。
+- 計画の確認と実装後の確認に、[レビューの共通契約](../review.md)の「対象の固定」「独立性」「完了の判定」を適用する。計画の確認では対象の版を計画の内容のハッシュとし、差分・機械検査・変更範囲の文は適用しない。Phase 4 の入力として定めた両案は他担当の結果に当たらない。独立案（Phase 3）はPhase 3の節に従う。継続担当には前回の確定済み指摘と採否を渡してよい。
+- メインは、依頼の確認、体制と工程の調整、調査・設計・計画の統合・実装・検証・修正、指摘の検証と採否、修正計画、担当の起動・待機・全文保存、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。体制が求める独立確認（独立案・計画の独立確認・実装後の独立レビュー）をメインの自己確認で代えない。
+- devの完了後に同じ会話・sessionで来る依頼（対話の次のターン、resume、Bridge、人の相談、QA差し戻し）も同じdevとして扱う。ただし、利用者が `review` を明示して起動したレビューはdevの工程とは別の作業とし、devの体制とレビューの回数を引き継がない。その結果の修正を依頼された場合は人の修正開始として修正サイクルに入る。質問への回答と人の指摘の調査は、メインが読み取りだけで行い、編集は修正サイクルで行う。初回devの完了・短い追加依頼・通常の会話への復帰を例外にしない。Codexが[UIの微調整](../linear/workflow.md#codexによるuiの微調整)で返した差分は、メインが取り込み、現在の工程の差分として検証し、既存のレビューを続ける（回数はリセットしない）。
 - **修正サイクル**: devの完了後に実装の修正が必要になったら（人の修正開始（[人のレビュー](../human-review.md)）、Codex QAの差し戻し、コミット中の指摘など、契機によらず）、未対応の指摘の集合を一つの入力にして次の順に進める。人の修正開始では、体制を[体制の選択](staffing.md)に従って確認する。入力が一致する結果は[テスト方針](../testing.md)に従って引き継ぐ。一部をコミットした後の修正は `commit` の規定どおり後続単位にする。
   1. メインが修正計画と、影響を受ける工程を決める。
   2. 設計・契約・検証条件を変える場合だけ、Phase 4の扱いで再確認する。
@@ -84,35 +84,15 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 ## 8. Phase 6: 実装後の確認
 
-同じ差分を固定し、選んだ体制の担当と追加した担当を `shinaps-reviewer` で並行して起動する。依頼するレビューの種類は体制ごとに次のとおり。設計適合性（計画・受入条件・責務・依存方向と実コードの照合）は、独立コードレビューの種類の中で毎回依頼する。
+[レビューの共通契約](../review.md)に従い、同じ差分を固定して、選んだ体制の担当と追加した担当を並行して起動する。設計適合性は、独立コードレビューの種類の中で毎回依頼する。変更範囲の確認コマンドは `git diff HEAD -- <path>` を渡す。
 
-| 体制 | 担当と依頼するレビューの種類 |
-| --- | --- |
-| LITE・BASIC | 新規の1名に、独立コードレビュー（設計適合性を含む）・可読性・慣習レビュー・実装の簡素化を依頼する。規約は独立コードレビューの rule 観点で照らし、規約照合の種類は依頼しない |
-| ULTRA | A: 新規の1名に、独立コードレビュー（設計適合性を含む）・実装の簡素化を依頼する。B: 技術領域ごとの1名に、規約照合・可読性・慣習レビューを依頼する |
+変更言語・領域・バージョンがPhase 2の規約の範囲を超えた分だけ取得を補い、同じ全文を渡す。取得した規約に `checks` があれば、担当へ渡す前に[規約の機械検査](../lint.md)の「照合で使う」を行う。
 
-- 独立コードレビューには、対象コード・全差分・利用側・規約・計画・検証結果を渡し、計画自体も誤りうるものとして確かめさせる。
-- 規約照合には、規約全文・対象ファイル全文と、変更範囲の確認コマンド（`git diff HEAD -- <path>`。未追跡のファイルは全行を今回の変更とする）を渡す。
-- 可読性・慣習レビューには、担当する範囲の差分と対象ファイルの現状全文、規約、計画に記した先例、合意済み仕様を渡す。
-- 技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属することを確かめ、足りない技術領域があれば担当を足す。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
-
-変更言語・領域・バージョンがPhase 2の規約の範囲を超えた分だけ取得を補い、同じ全文を渡す。staged・unstaged・untrackedを含めて対象を特定し、新規ファイルも確認する。
-
-結果を `review-{round}-{n}.md` に保存する。未確認部分があれば同じ担当へ戻し、全結果が揃ってから検証・統合する。担当が規約を読み終えられなかった場合は、未読の規約を読める単位に分けて同じ担当へ渡す。それでも読めない規約はメインが未照合と確定し、その規約を担当へ伝え、それを除いた範囲で担当の完了を判定する。未照合の規約は、特定できる単位（例: id・topic）でPhase 9に報告する。
+結果を `review-{round}-{n}.md` に保存する。未照合の規約はPhase 9に報告する。
 
 ## 9. 指摘の検証と統合（Phase 4・6共通）
 
-メインが全レポート全文・出典・確認範囲・要件・対象版・規約・検証結果を使い、全指摘を整理する。各指摘に担当・ラウンド・項番の出典IDを付け、実コード・利用箇所・計画・規約から根拠や反証を確かめ、根拠・誤認・重複・対立・未確認を区別する。同じ原因・影響・修正方針の指摘だけまとめ、元の項目と重要度を消さない。指摘なしの担当は完了と確認範囲を確かめる。
-
-全項目の採否と理由、必要な計画修正・実装修正・検証を一つにまとめる。Phase 4は `plan.md`、Phase 6は `fix-log.md` の「指摘の採否」の節に書く（`fix-log.md` ではQAの変更記録と節を分ける）。統合は多数決ではなく根拠で行う。メイン自身の確認を独立検証とは報告しない。
-
-- 今回の変更とその影響範囲にある次の指摘は、修正で解消するか事実（file:line・コマンドの結果）で反証するまで、退けたり消したりしない。
-  - (1) Critical・Warning の指摘（例: 今回の変更の規約違反、正しさ・契約・設計適合性の欠陥）。
-  - (2) 重要度・種類（Info・簡素化の提案）によらず、確認対象（計画またはコード）の正しさ・契約・設計上の欠陥を示す指摘。
-  - (1)・(2) のどちらも、修正案だけを退ける場合は、その欠陥をどう解消するか、またはその欠陥が成り立たない根拠を書く。前回の採否（人が決めた判断を除く）は退ける理由にならない。仕様を変えなければ解消できない欠陥は、人への確認（Phase 5 の「該当作業を止めて人に確認する」）に回し、人の判断を記録した時点で解決とする。
-- 事実で決まらない対立と、根拠不足で判断できない指摘は、同じ担当の継続で指摘元に確認する（レビューのラウンドに数えない）。解消しなければ未解決とし、品質上の完了にしない。複雑な対立は[体制](staffing.md)の「途中の増員」で担当を追加できる（LITEでは体制の変更を相談する）。
-- 既存箇所（今回の変更と無関係な箇所）の規約違反と欠陥は、「既存箇所の指摘」として別の一覧で報告し、完了を止めない。
-- 欠陥を示さず、好み・任意の改善に留まる Info と提案は、採らない理由を記録するだけで同意を求めない。仕様・受入条件・ユーザー体験の変更や依頼範囲の拡大は、人の合意前に採用しない。
+[レビューの共通契約](../review.md)の「指摘の検証と統合」に従う。全項目の採否と理由、必要な計画修正・実装修正・検証は、Phase 4は `plan.md`、Phase 6は `fix-log.md` の「指摘の採否」の節に書く（`fix-log.md` ではQAの変更記録と節を分ける）。仕様を変えなければ解消できない欠陥は、Phase 5 の「該当作業を止めて人に確認する」に回す。複雑な対立は[体制](staffing.md)の「途中の増員」で担当を追加できる（LITEでは体制の変更を相談する）。
 
 ## 10. Phase 7〜8: 修正と終了判定
 
@@ -124,10 +104,10 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 ## 11. Phase 9: 完了と引き渡し
 
-選んだ体制・追加した担当と変更理由、実際の担当・確認範囲と必須担当の完了状況（合意による未実施を含む）、計画と実装後のレビュー回数、採否・修正（退けた Critical・Warning と、欠陥を示す Info・提案の件数と根拠の場所、人の判断で解決した件数と判断の記録の場所、既存箇所の指摘の件数を含む）、検証結果、未実施・未照合・未解決事項を報告する。規約照合の種類を依頼しない体制（BASIC・LITE）では、規約を独立コードレビューの中で照らし、ファイルごとの完了一覧が無いことを書く。修正サイクルの後は、初回の報告項目を最新にし、対応した指摘と採否・再実施した工程・[変更記録](../linear/qa.md#qaの時点対象最終qa)を加える。
+選んだ体制・追加した担当と変更理由、実際の担当・確認範囲と必須担当の完了状況（合意による未実施を含む）、計画と実装後のレビュー回数、採否・修正（退けた Critical・Warning と、欠陥を示す Info・提案の件数と根拠の場所、人の判断で解決した件数と判断の記録の場所、既存箇所の指摘の件数を含む）、検証結果、未実施・未照合・未解決事項を報告する。機械検査の組の状態ごとの数と実行できなかった理由、規約照合の種類を依頼しない体制（BASIC・LITE）では規約を独立コードレビューの中で照らしファイルごとの完了一覧が無いことも書く。修正サイクルの後は、初回の報告項目を最新にし、対応した指摘と採否・再実施した工程・[変更記録](../linear/qa.md#qaの時点対象最終qa)を加える。
 
 linear-executeから受けた作業は未コミットの差分と結果を進行役へ返す。devの完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)と[担当と工程](../linear/workflow.md)に従い、autoはQA後の差分確定の依頼を受けて、manualは人のコミット開始依頼で `commit` を始め、単位の退避・stage・commitはQA結果の引き渡し後に行う。auto経路は [Claude CLI](../linear/claude-cli.md) のresultへ報告し、同じsessionのresumeで質問・修正を受ける。manual経路は同じ対話セッションで人と作業し、[Bridge](../linear/bridge.md)で依頼元Codexへ報告する。manualの完了時は、修正サイクルの後も含めて、人へユーザーのレビュー待ちと明示する（[manualの手順](../human-review.md)）。
 
 単独のdevではコミットが依頼の到達点に含まれる場合だけ範囲とモードを `commit` へ渡す。含まれなければ未コミットで返し、形式的な確認を追加しない。PR・リリースも依頼の到達点に含まれる範囲で各スキルへ渡す。単独devにLinear進行・新しいゴールを必須にしない。
 
-explore・spec・review・debugからの成果物は入口の引数で直接渡す。専用の引き継ぎファイルは作らず、Phase 1・2で既存成果物を再利用する。
+explore・spec・review・debugからの成果物は入口の引数で直接渡す。reviewから渡された指摘は修正サイクルの入力とし、体制が渡された場合はその体制で進める。専用の引き継ぎファイルは作らず、Phase 1・2で既存成果物を再利用する。

package/plugins/shinaps-codex/references/linear/claude-cli.md

@@ -2,6 +2,8 @@
 
 通常設定が `review_flow.mode: auto` のIssueと、`ask` で着手時にautoを選んだIssue（[経路](configuration.md#経路)）で、Codexが作業先でローカル `claude -p` を起動する。初回実装前に、正確なcheckout・branch・HEAD・既存差分、必須検証とそのツールチェーンの状態、依頼範囲（目的・対象・実効到達点のうちClaudeが行う部分）と制約を確定する。auto経路の起動と同じsessionの再開は、依頼範囲の通常操作として行う（[依頼範囲と操作](../request-scope.md)）。必須検証は対象リポジトリの規約・CI・スクリプトから読み、ツールチェーンは実際のコマンド（例: `node --version`、依存の導入状態の確認）の結果で確かめる。確かめるのは依頼で実際に使うコマンドに限る。
 
+Linear進行ではない単独の `review` から修正まで依頼されたときも、Codexはこの文書の起動・resume・操作権限の手順でClaudeへ渡す（promptの内容と到達点は `review` のスキルに従う）。
+
 パス例外はコミット単位のreview_flowを全体置換し、実装sessionを途中で切り替えない。manual単位が生じた場合は[経路](configuration.md#経路)に従う。
 
 ## 起動と観測

package/plugins/shinaps-codex/references/linear/configuration.md

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.48.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.48.0`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.49.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.49.0`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
 
 0.48.0から `config_version: 3`（操作ごとの許可の一覧を廃止し `constraints` を必須にした契約）だけを受理する。0.47.x以前のCLIと `$schema` のURLはv3を拒否し、0.48.0以降はv2を拒否するため、skill・CLI・`$schema` の版を揃えてから下の[旧設定の移行](#旧設定の移行)を行う。
 

package/plugins/shinaps-codex/references/request-scope.md

@@ -15,7 +15,7 @@
 
 依頼範囲の内側で到達点へ進むために必要な操作は、操作ごとの許可を求めずに行う。到達点を越える操作は依頼範囲を広げる操作として、下の「確認する操作」に従う。
 
-通常操作には、ローカル環境の準備と依存の導入、開発・検証、Issueの更新、Claude CLIの起動と同じsessionの再開、devの既定の経路（登録済みの役割）での委託、隔離のためのworktree、stage・commit、push、PRの作成・更新、マージ、指定された先への配備・公開を含む。操作の前に、必要なレビュー・QAなどの前工程が揃っていることを確かめる（下の「工程の条件」）。
+通常操作には、ローカル環境の準備と依存の導入、開発・検証、Issueの更新、Claude CLIの起動と同じsessionの再開、devと `review` の既定の経路（登録済みの役割）での委託、隔離のためのworktree、stage・commit、push、PRの作成・更新、マージ、指定された先への配備・公開を含む。操作の前に、必要なレビュー・QAなどの前工程が揃っていることを確かめる（下の「工程の条件」）。
 
 一つの操作に伴う副作用も、目的・対象・到達点・制約の内側にあることを確かめる。たとえばマージをきっかけに本番へ自動で配備される場合は、その配備まで依頼範囲に含まれている必要がある。含まれていなければ、その操作の前で止まる。
 

package/plugins/shinaps-codex/references/review-standalone.md

@@ -0,0 +1,58 @@
+# 単独レビューの手順
+
+`review` を単独で起動するときの、実行環境によらない手順。担当の構成・対象の固定・担当へ渡すもの・独立性・機械検査・完了の判定・指摘の採否・報告は[レビューの共通契約](review.md)に従う。担当の起動と修正の引き継ぎ先は実行環境ごとに `review` のスキルに書く。
+
+利用者が明示して起動したレビューはdevの工程とは別の作業で、同じセッションでdevが完了した後でも、devの体制とレビューの回数を引き継がない。
+
+## 1. 対象
+
+依頼された対象を、追跡状態によらず全て確認する。体制・種類・到達点の語（「修正まで」など）を除いた引数を次の順に判定する（残らなければ指定なし）。
+
+1. 数字またはPRのURLならPR。
+2. 存在するパスならパス。
+3. `..` を含むなら範囲。ローカルまたはリモート追跡のブランチ名なら、ベースブランチからそのブランチまでの範囲（`<base>...<ブランチ>`）。それ以外で `git rev-parse --verify <引数>^{commit}` で解決できるなら単一のコミット。
+4. どれでもなければ、対象を一問で確認する。
+
+| 対象 | 固定する版 | ファイルの列挙 | 変更範囲の確認コマンド |
+| --- | --- | --- | --- |
+| PR | `gh pr view <番号> --json baseRefOid,headRefOid` の head のSHA（ローカルに無ければ fetch する） | `git diff --name-only <base のSHA>...<head のSHA>` | `git diff <base のSHA>...<head のSHA> -- <path>` |
+| 単一のコミット（最初のコミットとマージコミットを含む） | そのSHA | `git show --format= --first-parent --name-only <SHA>` | `git show --format= --first-parent <SHA> -- <path>` |
+| 範囲 | 両端のSHA | `git diff --name-only <範囲>` | `git diff <範囲> -- <path>` |
+| ファイル・ディレクトリ | HEADのSHAと内容のハッシュ | 下の「パスの列挙」 | 無し（範囲判定なし） |
+| 指定なし | merge-base のSHA、HEADのSHA、内容のハッシュ | `git diff --name-only <merge-base のSHA>` と `git ls-files --others --exclude-standard` の和 | `git diff <merge-base のSHA> -- <path>` |
+
+指定なしの場合、merge-base はベースブランチとHEADから1回だけ解決し、解決したSHAをコマンドに書いて担当へ渡す（コミット済みと未コミットの変更を今回の変更として判定するため）。差分を対象にして差分が空なら、差分が無いと報告して止まる。削除されたファイルは列挙から外す。ファイル数で対象を減らさない。
+
+作業ツリーがその版でなければ、その版の一時worktreeを作って担当と機械検査に読ませ、終わったら取り除く。
+
+### パスの列挙
+
+指定された各パスについて、追跡中と未追跡のファイルを `git ls-files --cached --others --exclude-standard -- <path>` で列挙し、存在するものを対象にする。
+
+- 明示されたパス自体が ignore 対象なら、ファイルシステムから列挙して対象にする。
+- 指定したディレクトリの中で一部だけ ignore されて対象から外れたものは `git ls-files --others --ignored --exclude-standard --directory -- <path>` で確かめ、未確認の範囲として報告する。
+- Gitの作業ツリーの外なら、ファイルシステムから列挙する。
+
+## 2. 体制
+
+依頼に書かれていれば聞き直さない。種類が限定されていれば、体制を聞かず契約のとおりの人数で行う。どちらも無ければ[実装体制の判断](dev/staffing.md)の「推奨の目安」に沿った推奨と理由を添えて、LITE・BASIC・ULTRA を一問で確認する。
+
+## 3. 記録
+
+記録は `.shinaps/work/reviews/{YYYYMMDD-HHMMSS}-{対象}/` に置き、[作業記録の共通手順](work-records.md)に従う。`input.md` に対象・固定した版・列挙したファイル・体制を書き、担当の応答は全文を `raw/review-{round}-{n}.md` に保存し、全指摘の採否を `findings.md` に書く。関連する既存の spec・調査記録があれば要約して担当へ渡す。
+
+## 4. 規約と機械検査
+
+[Shinaps規約の取得](rules.md)に従い、対象ファイルについて規約全文を取得し、同じ手順の「照合結果に書くこと」を報告に含める。取得できなければ規約照合を未確認として報告し、照合済みとしない（コードのレビューは続ける）。`checks` を持つ規約があれば[規約の機械検査](lint.md)の「照合で使う」を行う。プロジェクトの `AGENTS.md`・`CLAUDE.md` と関連 docs も担当へ渡す。その後、スキルの「担当の起動」に従って担当を起動する。
+
+## 5. 検証と報告
+
+契約の「指摘の検証と統合」に従い、メインが全指摘を実コードで確かめて採否を決める。指摘の独立検証を依頼されたとき、またはメインと指摘元の根拠の対立が解消しないときは、別の担当に「指摘の検証」を依頼する。テストに関わる指摘は[テスト方針](testing.md)に従う。契約の「報告」と `findings.md` のパスを報告する。
+
+## 6. 到達点
+
+依頼に修正まで含まれていなければ、報告で終わる。ファイルの修正・コミット・PRへの投稿・公開をしない。
+
+- **修正**: 明示的に修正まで依頼された場合、採用した指摘が1件以上あれば、指摘（`findings.md` のパスと本文）・固定した版・選んだ体制（選んでいれば）・依頼範囲と制約を開発の担当へ渡す。作業ツリーが固定した版でなければ（別のブランチのPR、過去のコミットなど）、修正する場所を先に一問で確認する。開発の担当がdevの修正サイクルで修正と再レビューを行い、未コミットの差分を返す。採用した指摘が無ければ引き継がず報告で終わる。コミット・PR・公開は、それぞれ依頼に含まれている場合だけ別の工程で行う。
+- **PRへの投稿**: 明示的に依頼された場合だけ、本文を確認してから投稿する。
+- **規約の登録・更新**: 利用者がその場で依頼した場合だけ、[Shinaps規約の書き方](rule-writing.md)に従って行う。指摘から自動で登録しない。

package/plugins/shinaps-codex/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/references/rule-writing.md

@@ -2,6 +2,8 @@
 
 Shinaps AIへ個人規約を登録・更新するときの書き方。短さそのものではなく、1回読めば判断と行動が分かることを目的にする。
 
+規約の登録・更新は、利用者がその場で依頼したときだけ行う。レビューの指摘などから自動で登録しない。
+
 ## 1件1判断
 
 1件には1つの判断だけを書く。別々に適用・変更できる判断は分ける。
@@ -75,3 +77,10 @@ coding の規約は、使えるlintのルールで検査できるかを判断し
 | `examples` の good・bad | 各300字、15行 |
 
 上限はサーバーが入力を拒否する値で、目標ではない。値はMCPツールの入力の説明に従う。超過はエラーになり保存されないので、切り詰めずに書き直す。record_rulesは1件でも超えると全体が保存されない。
+
+## 書き込みのエラー
+
+- `RULE_TOO_LARGE`: その呼出し分は全体として保存されていない。details の limit・actual・title を確かめ、該当する本文・例を短くしてから同じ呼出しをやり直す。
+- `RULE_UPDATE_CONFLICT`: 全文を読み直してから再試行する。
+- `RULE_LIMIT_REACHED`: 書き込みを止める。残りの枠が足りない `record_rules` はその呼出し分が全体として保存されない（それより前の呼出しの分は保存されている）。details の `limit` と `actual` から残りの枠を示し、件数を絞るか既存の規約を整理するかを利用者に確認する。
+- `RATE_LIMITED`: 制限の時間枠が切り替わるまで待ってから、同じ呼出しを1回だけ再試行する。再び拒否されたら中断して報告する。

package/plugins/shinaps-codex/references/rules.md

@@ -10,7 +10,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 ## 対象の技術を選ぶ
 
-対象ファイルが確定した照合（`refine`・`review`）は、ファイルごとに `languages`・`platforms`・`frameworks` の各軸を「確定（slugの集合。空でもよい）」か「不明」に判定する。
+対象ファイルが確定した照合（`review`）は、対象全体を規約と広く照らすので `kind` で絞らない（絞ると見落としが増える）。ファイルごとに `languages`・`platforms`・`frameworks` の各軸を「確定（slugの集合。空でもよい）」か「不明」に判定する。
 
 **確定と言えるのは、そのファイルに当てはまる規約のその軸のlabelが、必ずその集合に入るときだけ。** サーバーは指定した軸のどれか1つでも不一致の規約を除くので、この条件が満たせない軸は不明にする。