@shinaps/skills 0.48.0 → 0.49.0

package/plugins/shinaps-claude/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-claude/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-claude/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-claude/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-claude/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-claude/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/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-claude/references/rules.md

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

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は、依頼の範囲で必要な場合だけ行う（[依頼範囲と操作](../../references/request-scope.md)）。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。独立レビューがプロジェクトの必須条件なら未完了として扱う。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-codex/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "shinaps",
-  "version": "0.48.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 経由で渡される"