@shinaps/skills 0.39.1 → 0.41.0

package/docs/install.md

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

package/package.json

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

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

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

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

@@ -12,7 +12,7 @@ color: gray
 ## 作業前に必ず読むもの
 
 - リポジトリの `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md` (特に「対症療法禁止方針」を強調)
-- **Skill 側から prompt 経由で渡された `search_rules` 結果**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文**
 
 ## 検証項目
 

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

@@ -13,7 +13,7 @@ color: magenta
 
 - リポジトリの `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
 - 関連する設定ファイル・環境変数・依存関係
-- **Skill 側から prompt 経由で渡された `search_rules` 結果 (topic=debugging + 症状関連 topic)**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文 (topic=debugging + 症状関連 topic)**
 - **Skill 側から prompt 経由で渡された関連する既存成果物の要約**: 過去に同じ / 類似症状の記録があるかを参照材料に
 
 ## ミッション

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

@@ -44,4 +44,4 @@ Skill 側から prompt 経由で以下の情報が渡されます (MCP tool を
 - **網羅より深さ**: 関連領域に絞って深く読む。広く浅くは避ける
 - **ファイル参照は file:line 形式**: 依頼元がそのまま辿れるように
 - **要約しすぎない**: 主要発見は具体的な引用や根拠を伴うこと
-- **shinaps MCP を直接呼ばない**: `search_rules` / `list_search_facets` を含む全 shinaps MCP tool は Skill 側 (メインスレッド) が呼び、結果を prompt 経由で渡す。あなたは受け取った文字列を材料に使うだけ
+- **shinaps MCP を直接呼ばない**: `search_rules` / `get_rules` / `list_search_facets` を含む全 shinaps MCP tool は Skill 側 (メインスレッド) が呼び、結果を prompt 経由で渡す。あなたは受け取った文字列を材料に使うだけ

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

@@ -14,7 +14,7 @@ color: blue
 - リポジトリの `CLAUDE.md` / `AGENTS.md` / その他の指示ファイル
 - Skill 側から渡された `exploration.md` と今回の質問
 - Skill 側から渡された target revision / environment と current branch / HEAD / worktree 状態
-- Skill 側から渡された関連する既存成果物の要約と `search_rules` 結果
+- Skill 側から渡された関連する既存成果物の要約と取得済みの規約全文
 
 既存成果物と過去ラウンドは探索の手掛かりであり、現在も正しいとは限らない。重要な主張は現在のコードで再確認する。
 

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

@@ -12,7 +12,7 @@ color: purple
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された `search_rules` 結果 (userRules + officialRules 全文)**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文 (userRules + officialRules)**
 
 ## 役割分担 (重要)
 

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

@@ -12,7 +12,7 @@ color: orange
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された `search_rules` 結果**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文**
 
 ## 検証プロセス
 

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

@@ -12,7 +12,7 @@ color: red
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された `search_rules` 結果 (差分カテゴリに対応した userRules + officialRules 全文)**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文 (差分カテゴリに対応した userRules + officialRules)**
 
 ## レビューの種類
 

package/plugins/shinaps-claude/agents/shinaps-spec-writer.md

@@ -12,7 +12,7 @@ color: pink
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された `search_rules` 結果**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文**
 
 ## 必ず含める要素
 

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

@@ -12,7 +12,7 @@ color: yellow
 ## 作業前に必ず読むもの
 
 - `CLAUDE.md` / `~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された `search_rules` 結果**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文**
 
 ## 進め方
 

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

@@ -12,7 +12,7 @@ WebSearch / WebFetch で **一次情報** を集め、3-5 候補の比較レポ
 ## 作業前に必ず読むもの
 
 - リポジトリの `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された `search_rules` 結果**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文**
 - 既存依存ファイル: `package.json` / `pyproject.toml` / `Cargo.toml` / `go.mod` など
 
 ## 必ず評価対象に含める観点

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

@@ -20,7 +20,7 @@ tools:
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された `search_rules` 結果 (userRules + officialRules 全文)**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文 (userRules + officialRules)**
 
 ## 役割分担 (重要)
 

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

@@ -20,7 +20,7 @@ tools:
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された `search_rules` 結果 (差分カテゴリに対応した userRules + officialRules 全文)**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文 (差分カテゴリに対応した userRules + officialRules)**
 
 ## レビューの種類
 

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

@@ -43,7 +43,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 規約はメインが取得し、以降の担当へ全文を渡す。担当はShinaps MCPを呼ばない。
 
-- `list_search_facets` でfacetを確認し、`search_rules` に現在のrepoOwner・repoNameと対象に関連するfacetを渡す。manifest・lockfileなどで確認できた対象バージョンだけ `projectVersions` に指定する。確認できない場合は共通ルールのみの照合と記録する。
+- [Shinaps規約の取得](../rules.md)に従い、対象に関連するfacetで一覧を取り、必要な全文を取得する。
 - プロジェクト規約と関連docs、引き継いだ調査の必読ファイルを確認する。時間に依存する根拠が判断に影響する場合は公式情報で確かめる。
 - 調査はメインが行う。BASIC・ULTRAでは、互いに独立した領域を並行して調べる場合に探索担当を置ける（任意）。探索担当には既存成果物と不足する問いを渡し、`raw/explorer-{n}.md` に結果を保存する。
 

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.39.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.39.1`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.41.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.41.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
 
 0.35.0から通常設定の `review_flow.mode` に `ask` を受理する。`config_version` は2のままで、既存のauto・manualの設定は変更不要。0.33.0〜0.34.xのCLIと `$schema` のURLは `ask` を拒否するため、`ask` を使う設定では `$schema` も0.35.0以降のURLにする。
 

package/plugins/shinaps-claude/references/rule-writing.md

@@ -0,0 +1,45 @@
+# Shinaps規約の書き方
+
+Shinaps AIへ個人規約を登録・更新するときの書き方。短さそのものではなく、1回読めば判断と行動が分かることを目的にする。
+
+## 1件1判断
+
+1件には1つの判断だけを書く。別々に適用・変更できる判断は分ける。登録の前に[Shinaps規約の取得](rules.md)で既存の規約を確かめ、同じ判断があれば新規に増やさず更新を検討する。
+
+## 項目の役割
+
+各項目は役割が重ならないようにし、同じ内容を言い換えて繰り返さない。
+
+| 項目 | 書くこと | 書かないこと |
+| --- | --- | --- |
+| `title` | 判断そのものを一文で | 背景、複数の判断 |
+| `why` | その判断をする理由と、守らないと起きること | 手順、`recommend` の言い換え |
+| `recommend` | 読み手がそのまま取れる具体的な行動 | 理由、一般論 |
+| `avoid` | 誤りやすい行動 | `recommend` の単なる否定 |
+| `examples` | good と bad の違いが分かる最小のコード片 | 違いに関係しない行、架空の根拠 |
+
+## 残すものと削るもの
+
+- 適用条件、例外、強制か推奨かの強さは必ず残す。短くするために意味を変えない。
+- 経緯、PR番号、発生日は、判断の根拠や適用範囲を理解するために必要な分だけ残す。詳細な出典は `sourceUrls` に置く。
+- 出典、scope、kind、labelsは、規約の内容が変わらない限り変えない。出典を足すときは既存の出典を残す。
+- 読み手がリポジトリの既存の規約や公式の文書から分かることは繰り返さない。
+- 根拠の無いコード例・URL・規範を作らない。
+
+## scope
+
+全リポジトリに当てはまる判断だけ `scope: user` にして、他のプロジェクトでも通じる表現で書く。同じownerの配下に共通する判断は `scope: repo_owner`、特定のリポジトリの判断は `scope: repo` にして具体的に書く。
+
+## 目安と上限
+
+目安は書き方の基準で、超えても保存できる。超えるときは、1件に複数の判断が入っていないか、項目の間で繰り返していないかを見直す。必要な適用条件と例外を落としてまで目安に合わせない。
+
+| 項目 | 目安 |
+| --- | --- |
+| `title` | 60字 |
+| `why` | 300字 |
+| `recommend` | 250字 |
+| `avoid` | 150字 |
+| `examples` の good・bad | 各300字、15行 |
+
+上限はサーバーが入力を拒否する値で、目標ではない。値はMCPツールの入力の説明に従う。超過はエラーになり保存されないので、切り詰めずに書き直す。record_rulesは1件でも超えると全体が保存されない。

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

@@ -0,0 +1,50 @@
+# Shinaps規約の取得
+
+Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メイン）だけが行い、担当へは全文を渡す。保存できる規約は必ず1応答に収まり、1応答は100件かつ32,000 bytes（MCPのcontent textのUTF-8）までに分かれるので、下の手順で全件を辿る。
+
+## 一覧を取る
+
+`list_search_facets` で語彙と `versionTargets` を確認し、`search_rules` を `fields: "summary"` で呼ぶ。
+
+- `repoOwner`・`repoName` は現在のGit workspaceから渡す。facetを1つも渡さないと公式ルールは返らない。
+- `projectVersions` にはmanifest・lockfile・compiler config・deployment targetから確認できた版だけを渡す。確認できないときは省き、条件付きの公式ルールが除外されて共通ルールだけの照合になったことを結果に書く。
+- `nextCursor` がnullになるまで、他の入力を変えず `cursor` に渡して続きを取得する。途中で止めた範囲は未取得として扱う。
+
+## 個人規約を対象ファイルの技術で絞る
+
+対象ファイルが確定した照合（`refine`・`review`）では、`search_rules` に `filterUserRulesByLabels: true` を渡し、対象の技術と明確に異なる個人規約を一覧から除く。それ以外（devの入口・`spec`・`explore`・`debug`、既存規約との重複の確認）では指定しない。対象ファイルの技術が増えたら取り直す。
+
+```json
+{ "fields": "summary", "repoOwner": "...", "repoName": "...", "languages": ["typescript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
+```
+
+サーバーは同じ軸をOR、指定した軸の間をANDで判定する。未指定の軸、規約にlabelが無い軸、topic、未知・別軸・無効なslugを含む軸、無効なlabelしかない軸では除外しない。除外の判定に使う語彙は `list_search_facets` が返すものだけ。
+
+- 渡すのは、対象が使う技術そのものか、その別名か、実際の依存・基盤として使うことを確認できたslugだけにする。確認には対象ファイルの内容・パスと、そのファイルが属するパッケージの設定（manifest・`wrangler.jsonc` など）を使う。manifestにあるだけの依存は、そのファイルで使うと確認できなければ渡さない。リポジトリ全体の技術を一つのファイルに流用しない。同じ役割や類似の技術のslugに置き換えない。
+- 複数のファイルは全ファイルの技術の和を渡す。1ファイルでも不明な技術や語彙外の技術があり、確認できたslugでは表しきれない軸は省略する。8件を超える軸も省略する。Markdownや一般の設定ファイルのように技術を持たないファイルは不明に数えない。
+- facetは公式ルールの検索と共有する。軸を省略すると、その軸で絞られなくなるので公式ルールの件数も増える。全ての軸を省略して `topics` も無ければ公式ルールは空なので、公式ルールは未照合と報告するか、`topics` を渡す。
+- 件数で規約の登録の有無を判断するときは、この指定なしの結果を使う。
+- サーバーが除外した規約のidは返らないので、照合結果には指定したfacetと `filterUserRulesByLabels: true` を書く。
+
+## 全文を取る規約を選ぶ
+
+一覧は全文を選ぶためのものであり、一覧だけで規約を満たした、または非該当と判断しない。
+
+- 除外できるのは、labelの language・platform・framework が対象と明確に異なる規約だけ。その軸のlabelが無い規約は軸に依存しない規約として残す。slugの種類は `list_search_facets` で確かめる。
+- titleとtopicでは除外しない。判断できない規約は全文を取得する。
+- 除外した規約はidと理由を記録する。
+
+## 全文を取る
+
+選んだidを100件までに分けて `get_rules` へ渡す。
+
+- `remainingIds` が空になるまで、そのまま `ids` に渡して続きを取得する。
+- `notFoundIds` は削除済みまたは参照できない規約なので、idを記録して照合の対象から外す。
+- 全件が必要と分かっているときは、`search_rules` の `fields: "full"` を `nextCursor` がnullになるまで辿ってもよい。
+- `RATE_LIMITED` は短い時間を置いて、同じ `cursor` または `remainingIds` から再開する。
+
+## 担当へ渡す
+
+全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
+
+取得・受渡し・読了のいずれかが終わらなかった規約は、idまたは条件を挙げて未照合と報告し、照合済みにしない。

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

@@ -77,14 +77,14 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 #### 前準備 (メインスレッド)
 
-`list_search_facets()` + `search_rules({ repoOwner, repoName, topics: ["debugging", ...推定 topic] })` を実行。
+[Shinaps規約の取得](../../references/rules.md) に従い、`topics: ["debugging", ...推定 topic]` で一覧を取って必要な規約全文を取得する。
 
 #### プロンプト
 
 - `input.md` 全文
 - プロジェクト `CLAUDE.md` 全文
 - **Phase 1 で作成した既存成果物の要約**
-- **前準備の `search_rules` 結果 (userRules + officialRules 全文)**
+- **前準備で取得した規約全文 (userRules + officialRules)**
 - 「対症療法ではなく根本原因を特定せよ。既存成果物 と rule カタログを仮説の優先順位付けに使う」
 - trace モードの場合: 起点ファイル指定
 
@@ -96,7 +96,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 - `input.md` 全文
 - `debug-report.md` 全文
-- 前準備の `search_rules` 結果
+- 前準備で取得した規約全文
 - 「各仮説について該当コードを Read で確認し、root-cause / contributing-factor / red-herring / needs-reproduction に分類せよ。対症療法禁止、根本解決を提示」
 
 **記録先**: メインが Write で `debug-validated.md`
@@ -110,8 +110,8 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 実施する場合、`shinaps-tech-surveyor` → `shinaps-survey-validator` の順に 2 段階で実行する。
 
-- **shinaps-tech-surveyor プロンプト**: `input.md` + `debug-validated.md` + `search_rules` 結果 + 「関連 library / API の既知バグ / breaking change / 挙動仕様を WebSearch + GitHub Issue で調査」
-- **shinaps-survey-validator プロンプト**: `raw/survey.md` 全文 + `search_rules` 結果 + 「出典 URL を再確認、CLAUDE.md / rule に反する候補は Critical」
+- **shinaps-tech-surveyor プロンプト**: `input.md` + `debug-validated.md` + 取得済みの規約全文 + 「関連 library / API の既知バグ / breaking change / 挙動仕様を WebSearch + GitHub Issue で調査」
+- **shinaps-survey-validator プロンプト**: `raw/survey.md` 全文 + 取得済みの規約全文 + 「出典 URL を再確認、CLAUDE.md / rule に反する候補は Critical」
 
 **記録先**: メインが Write で `raw/survey.md` / `raw/survey-validated.md`
 
@@ -143,7 +143,7 @@ Skill(skill="shinaps:dev-claude", args="以下のデバッグ結果に基づき
 - **根本原因志向**: 対症療法を推奨しない、根本解決を導く
 - **多角的調査**: コード + docs + WebSearch + GitHub Issue を組み合わせる
 - **二段検証**: debugger の仮説を debug-validator が必ず実コードで検証
-- **rule と既存成果物を仮説の優先順位付けに活用**: `search_rules` の結果と、今回の依頼に関連する Git・spec・raw report の根拠を debugger prompt に埋め込む
+- **rule と既存成果物を仮説の優先順位付けに活用**: 取得済みの規約全文と、今回の依頼に関連する Git・spec・raw report の根拠を debugger prompt に埋め込む
 - **subagent は文字列応答のみ**: ファイル書き込みは必ずメインが担当
 - **生レポート保存厳守**: すべての subagent 応答を全文保存
 - **根本原因確定時に ローカル成果物（implementation.md / 調査・レビューレポート）**: 後の作業者と別 AI agent が辿れるように

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

@@ -77,7 +77,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 1. 最初の質問を受領する。引数が空、またはファイルパスだけなら、理解したいことを `AskUserQuestion` で 1 問だけ確認する
 2. git remoteから `repoOwner` / `repoName` を解決する。今回の依頼に関連する既存の spec・調査レポート・Git の変更履歴を確認し、引き継ぐ決定と根拠を要約する。既存成果物がなければ追加取得は不要。
-3. `list_search_facets()` と、最初の質問に対応する `search_rules({ repoOwner, repoName, ...推定 facet })` を呼ぶ。論点が別領域へ移ったら、その時点で facet を取り直す
+3. [Shinaps規約の取得](../../references/rules.md) に従い、最初の質問に対応する推定 facet で一覧を取り、必要な規約全文を取得する。論点が別領域へ移ったら、その時点で facet を取り直す
 4. リポジトリの `CLAUDE.md` / `AGENTS.md` / その他の指示ファイルを読む
 5. `git status --short --branch` と HEAD を記録する。調査対象の revision は未コミット変更を含む現在の worktree をデフォルトにし、production / PR / commit が明示された場合は対象 revision を特定して別に記録する。reset / stash / checkout / clean は行わない
 6. 作業ディレクトリを作り、最初の質問と調査基準を `exploration.md` / `question-log.md` に要約して保存する
@@ -100,7 +100,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 - `exploration.md` 全文と、必要な過去ラウンドの要点
 - target revision / environment と、現在の branch / HEAD / worktree 状態
 - 関連する既存成果物の要約
-- `search_rules` の userRules + officialRules 全文
+- 取得済みの規約全文
 - 関連するプロジェクト指示
 - 「今回の質問へ直接答え、confirmed / inference / unknown を混ぜない。一般的な設計案や修正案へ先回りしない」
 
@@ -217,6 +217,6 @@ dev の入口は「実装 handoff」の `status: ready` と `evidenceSnapshot`
 - **質問ごとに調査する**: 過去の一般論だけで即答せず、そのラウンドの問いに必要な証拠を取り直す
 - **理解完了を代行しない**: 終了判定は人間が行う。回数制限を設けない
 - **生レポートを保存する**: subagent 応答は全文保存し、会話ログは要約だけ残す
-- **shinaps MCP はメインだけが呼ぶ**: subagent は `search_rules` / `list_search_facets` を直接呼ばない
+- **shinaps MCP はメインだけが呼ぶ**: subagent は `search_rules` / `get_rules` / `list_search_facets` を直接呼ばない
 
 Linear進行への成果引き渡しでは、確定済みの経路を維持する。autoは同じ[Claude CLI](../../references/linear/claude-cli.md)のsessionのresultへ返す。manualは同じ対話セッションで続け、[Bridge](../../references/linear/bridge.md)で依頼元のCodexへ報告する。調査スキルから経路を切り替えない。

package/plugins/shinaps-claude/skills/extract-rules/SKILL.md

@@ -63,7 +63,7 @@ PR description (本文) は対象外。あくまで「レビュー観点」を
 
 ## Step 6. 既存 rules 把握
 
-100 PR を 1 ブロックとして処理する。ブロックの開始時に必ず shinaps-ai MCP server の `search_rules({ repoOwner, repoName })` を呼んで、既存 userRules を取得する (facet を渡さないので officialRules は空、userRules は継承マージで scope=user / repo_owner / repo の全件、最大 200)。これを「新規 (= `record_rules` の投入対象に含める) か、既存 rule を更新する `update_rule` か」を判断する材料にする。
+100 PR を 1 ブロックとして処理する。ブロックの開始時に必ず shinaps-ai MCP server の `search_rules({ fields: "summary", repoOwner, repoName })` を `nextCursor` が null になるまで呼んで、既存 userRules の一覧を取得する (facet を渡さないので officialRules は空、userRules は継承マージで scope=user / repo_owner / repo の全件)。全文は Step 7 で候補ごとに確かめる。これを「新規 (= `record_rules` の投入対象に含める) か、既存 rule を更新する `update_rule` か」を判断する材料にする。
 
 ## Step 7. rules 生成と投入
 
@@ -72,33 +72,37 @@ PR description (本文) は対象外。あくまで「レビュー観点」を
 - 複数 PR / 複数 reviewer で繰り返し言及されている指摘 (1 回限りの軽い指摘は採用しない)
 - DO/DON'T が明確で、再現可能な規約として書き下せる粒度のもの
 - WHY (なぜそうするか) を 1-3 文で要約できる材料があるもの
+- 本文は [Shinaps規約の書き方](../../references/rule-writing.md) に従って書く
 
 Good/Bad サンプルコード (examples) の付け方:
 
 - レビューコメントや diff から Good/Bad ペアを構成できる rule にのみ `examples: { good, bad, language }` を付ける。**素材が無い rule に捏造しない** (プロジェクト固有の識別子を一般名に置換する・最小化する程度の編集は可)
-- good / bad は各 1000 文字以内・5〜15 行目安の短いコード片。language は shiki の言語 id 小文字 (`typescript` / `tsx` / `python` / `go` 等)
+- good / bad の大きさは [Shinaps規約の書き方](../../references/rule-writing.md) の目安に従う。language は shiki の言語 id 小文字 (`typescript` / `tsx` / `python` / `go` 等)
 - good / bad / language は 3 つセットでしか登録できない (揃っていないと入力の schema 検証で拒否される)
 
 出典 URL (sourceUrls) の付け方:
 
-- 根拠になったレビューコメントの HTML URL (`#discussion_r...` / `#issuecomment-...`) を優先し、特定できなければ PR URL にフォールバック。最大 10 件・各 500 文字・http(s) のみ
+- 根拠になったレビューコメントの HTML URL (`#discussion_r...` / `#issuecomment-...`) を優先し、特定できなければ PR URL にフォールバック。http(s) のみ。上限は MCP ツールの入力の説明に従う
 - **出典素材が無い rule に URL を捏造しない** (省略可 = 出典なしで保存される)
 
 投入手順:
 
-- 候補を既存 rules と照合し、**新規** (該当 rule 不在) だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, rules: [{ title, why, recommend?, avoid?, kind?, labels?, examples?, sourceUrls? }, ...] })` で **1 call bulk 投入** する。`labels` は language / platform / framework / topic の slug 配列 (`list_search_facets` が返す公式カタログの slug のみ、language/platform/framework は 1 rule に各 1 つまで) (1 call 最大 100 件、超えたら分割。同一 title の重複は入力の schema 検証で拒否される)。extract-rules は対象 repo の PR レビューから抽出する性質上 scope=repo (当該 repo 限定) がデフォルト。横断ルールとして残したい場合だけユーザー判断で `scope: 'user'` に格上げ。**格上げするときは why / recommend / avoid / examples を当該 repo の固有文脈 (内部 API 名・モジュール構成・ドメイン固有の識別子) から切り離し、他プロジェクトでも適用場面を想定できる汎用的な表現・汎用サンプルに解釈し直してから登録する** (scope=repo のままなら repo 固有の具体的な記述・コード片で良い)。title は 200 字以内、規約本文は why (必須、なぜこの規約か、2000 字以内) / recommend (推奨行動、任意、1000 字以内) / avoid (避けるべきこと、任意、1000 字以内) の 3 フィールドに構造化する
+- 候補ごとに、title か label が重なる既存 rule の全文を `get_rules` で確かめて照合する (重複確認のための絞り込みで、照合対象の除外ではない)。判断できなければ全文を取得する。同じ判断の既存 rule があれば下の差分確認へ回し、それ以外の**新規**候補だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, rules: [{ title, why, recommend?, avoid?, kind?, labels?, examples?, sourceUrls? }, ...] })` で **1 call bulk 投入** する。本文の書き方は [Shinaps規約の書き方](../../references/rule-writing.md)、上限は MCP ツールの入力の説明に従う。`labels` は language / platform / framework / topic の slug 配列 (`list_search_facets` が返す公式カタログの slug のみ、language/platform/framework は 1 rule に各 1 つまで) (1 call 最大 100 件、超えたら分割。同一 title の重複は入力の schema 検証で拒否される)。
+- extract-rules は対象 repo の PR レビューから抽出する性質上 scope=repo (当該 repo 限定) がデフォルト。横断ルールとして残したい場合だけユーザー判断で `scope: 'user'` に格上げ。**格上げするときは why / recommend / avoid / examples を当該 repo の固有文脈 (内部 API 名・モジュール構成・ドメイン固有の識別子) から切り離し、他プロジェクトでも適用場面を想定できる汎用的な表現・汎用サンプルに解釈し直してから登録する** (scope=repo のままなら repo 固有の具体的な記述・コード片で良い)
+- `RULE_TOO_LARGE` が返ったら、その呼出し分は全体として保存されていない。details の limit・actual・title を確かめ、該当候補の本文・例・出典を短くしてから同じ呼出しをやり直す。`update_rule` の `RULE_UPDATE_CONFLICT` は全文を読み直してから再試行する。
 - `RULE_LIMIT_REACHED` が返ったら投入を止める。個人ルールの保存数には上限があり、残りの枠が足りない `record_rules` はその呼出し分が全体として失敗し、一部も保存されない (件数を減らして一部だけ登録する手順へ自動では切り替えない)。それより前の呼出しで投入した分は保存されている。details の `limit` と `actual` から残りの枠を示し、投入する件数を絞るか既存ルールを整理するかのどちらにするかを利用者に確認する。以降のブロックの抽出・投入にも進まず、利用者の選択を待つ。
 - `RATE_LIMITED` (再試行可能) が返ったら、制限の時間枠が切り替わるまで待ってから、同じ呼出しを1回だけ再試行する。再び拒否されたら、連続して再試行せずに中断し、その状況を利用者に報告する。
-- 戻り値の `skipped: { title, existingRuleId, existingWhy, existingRecommend, existingAvoid, existingLabels, existingExamples, existingSourceUrls }[]` は「既存と title 重複して投入されなかった候補」。新しい why/recommend/avoid と existing* が異なるなら **ユーザーに diff を提示して同意を取る** (examples / sourceUrls の差分も同様):
+- 戻り値は入力の `rules` の位置と id だけ (`inserted: { index, ruleId }[]`、`skipped: { index, existingRuleId }[]`)。`skipped` は「既存と title 重複して投入されなかった候補」で、title は入力の `rules[index]` から分かる。`get_rules` で既存の全文を取得する。
+- 事前の照合で一致した候補と `skipped` の両方について、why/recommend/avoid/examples が既存と異なるなら **ユーザーに diff を提示して同意を取る**:
 
-> 既存 rule "no-unused-vars" が見つかりました。why/recommend/avoid の差分:
+> 既存 rule "no-unused-vars" が見つかりました。why/recommend/avoid/examples の差分:
 > ```
 > - 旧 why: ...
 > + 新 why: ...
 > ```
 > 上書きしますか? (yes / no / skip-all)
 
-- 同意なら `update_rule({ id: existingRuleId, why?, recommend?, avoid?, examples?, sourceUrls? })` を実行。`skip-all` を選ばれたら以降の skipped に対して確認をスキップする
+- 同意なら `update_rule({ id: <既存 rule の id>, why?, recommend?, avoid?, examples?, sourceUrls? })` を実行。sourceUrls は配列ごと置き換わるので、既存と新しい出典をまとめて渡す (上限を超えるなら切り詰めずに利用者へ確認する)。`skip-all` を選ばれたら以降の差分確認をスキップする
 
 ## Step 8. 100 PR ブロック確認
 
@@ -112,5 +116,5 @@ since 期間内の merged PR を消化し終えたら、以下を user に報告
 - 自動 Bot 除外 + ユーザー確認で除外した login 一覧
 - `record_rules` で新規投入した rule 件数 (inserted 合計) + タイトル一覧
 - `update_rule` で更新した rule 件数 + タイトル一覧
-- skip-all で残した候補件数 (あれば)
+- `no` または skip-all で残した候補件数 (あれば)
 - 保存上限 (`RULE_LIMIT_REACHED`)・回数制限 (`RATE_LIMITED`) によって投入できなかった候補の件数 (あれば)

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

@@ -57,9 +57,8 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 
 以下を並列で取得:
 
-- shinaps-ai MCP server の `list_search_facets()` で公式カタログの facet (languages / platforms / frameworks / topics の登録済み slug) を取得 → 対象ファイルの拡張子・パス・内容から関係する facet slug を推定して確定
-- `list_search_facets()` の `versionTargets` と manifest / lockfile / compiler config / deployment target を照合し、確認できたバージョンだけを `projectVersions: [{ targetKind, targetSlug, version }]` に指定する。facet取得後に検索する。targetやバージョンは推測しない。確認できない対象は条件付きルールが除外されるため、共通ルールのみの照合になったことを結果に明記する。`versionTargets` に無い target を渡すと、facet の有無にかかわらず `VERSION_TARGET_NOT_FOUND` になり、userRules も返らない。
-- shinaps-ai MCP server の `search_rules({ repoOwner, repoName, languages?, platforms?, frameworks?, topics?, kind?, projectVersions? })` を呼ぶ → userRules + officialRules (両方を照合対象にする。userRules は facet に関係なく継承マージ全件、officialRules は Git で管理する英語原文の公式カタログのうち、指定 facet とバージョン適用条件に一致するものへ絞られる)。**repoOwner / repoName は現在の git workspace から必ず渡す** (`gh repo view` or `git remote get-url origin` から取得)。userRules は scope=user (横断) + scope=repo_owner (owner 一致) + scope=repo (owner+name 一致) の継承マージで返る。各 rule に付く `scope` flag を見て「横断 / owner 限定 / repo 限定」を判別できる。facet を 1 つも指定せずに呼ぶと officialRules は空配列で返るので、必ず推定 facet を 1 つ以上指定すること。`kind` は通常指定しない (対象ファイル全体を rule 集合と広く照合する用途のため、絞り込むと見落としが増える)
+- shinaps-ai MCP server の `list_search_facets()` で公式カタログの facet (languages / platforms / frameworks / topics の登録済み slug) を取得 → [Shinaps規約の取得](../../references/rules.md) に従って対象ファイルについて確認できた技術の facet slug を確定
+- [Shinaps規約の取得](../../references/rules.md) に従って規約全文を取得する (`search_rules` の `fields: "summary"` を全ページ → `get_rules`)。対象ファイルの技術で `filterUserRulesByLabels: true` を指定する。userRules と officialRules の両方を照合対象にする。userRules は scope=user / repo_owner / repo の継承マージから対象の技術と明確に異なるものを除いて返り、officialRules は指定 facet とバージョン適用条件に一致するものへ絞られる。`kind` は通常指定しない (対象ファイル全体を rule 集合と広く照合する用途のため、絞り込むと見落としが増える)
 - repo root の `AGENTS.md` / `CLAUDE.md` を Read (プロジェクト規約)
 - AGENTS.md が `docs/` 等を「source of truth」として参照していたら **その docs も Read** (今回変更した領域に関連するものに限定して良い)
 - グローバル `~/.claude/CLAUDE.md` の `## コメントルール` `## 実装・設計に関して` 等の節 (一度読んだセッションなら conversation history で代替可)
@@ -79,7 +78,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 
 ### 各 agent への prompt
 
-- 担当ID (`1`) と、取得済みの rule 全件 (id / title / why / recommend / avoid の全文)
+- 担当ID (`1`) と、取得済みの rule の全文。取得した応答の単位でバッチに分けて渡し、読み終えた rule の id を報告させる
 - 関連する AGENTS.md / CLAUDE.md / docs の該当節
 - repo root の絶対パス、対象ファイル一覧、バッチID、対象全体のうち今回確認する範囲
 - Step 0 で確定した変更範囲の確認コマンド。path指定で変更を伴わない場合は、範囲判定不要・全 finding を `pre-existing` と明記する
@@ -175,7 +174,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 
 1. **修正する** — どう直すかを 1-2 文で提案 (agent が返した `detail` を活用)。承認されたら `Edit` / `Write` で実行
 2. **このまま許容する** — 妥当な理由があるとき。理由を今回のローカル成果物（implementation.md / 調査・レビューレポート）に残す (後から「なぜ違反のままにしたか」を辿れるように)
-3. **ルールの方を修正する** — 規約自体が現実と乖離している場合。shinaps-ai MCP server の `record_rule` (新規) or `update_rule` (既存修正) を実行。新規 record_rule のときは scope (user / repo_owner / repo) も選ばせる (横断的なら user、この repo 限定なら repo)
+3. **ルールの方を修正する** — 規約自体が現実と乖離している場合。[Shinaps規約の書き方](../../references/rule-writing.md) に従って shinaps-ai MCP server の `record_rule` (新規) or `update_rule` (既存修正) を実行。新規 record_rule のときは scope (user / repo_owner / repo) も選ばせる (横断的なら user、この repo 限定なら repo)
 4. **後回し** — 別タスクとして扱う。`TaskCreate` で TODO 化し、後の作業セッションで着手できるようにする
 
 **提示順は `changed` を先、`pre-existing` を後**。それぞれの中では Violation → Improvement → Question の順。各 finding には `pre-existing` かどうかを明示して提示する (ユーザーが「今回の commit に混ぜるか」を判断する材料になるため)。件数が少なければ 1 回の `AskUserQuestion` に複数 question をまとめてよい (各 finding には前提説明を添える)。
@@ -199,7 +198,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 - テストに関わる指摘と修正の判断は [テスト方針](../../references/testing.md) に従う
 - **Info レベルは report しない**。Critical / Warning 相当だけを扱う。ノイズが多いと「規約照合は手間」という否定的な印象が定着するため
 - **1体で対象全体を確認する**。対象量が増えても担当数を増やさず、同じ担当へ続きのバッチを渡す
-- **Agent への rule 受け渡しは full text**。id + title だけを渡して agent 側に search_rules を再取得させると shinaps MCP を N 回呼ぶことになるため無駄。メインスレッドが 1 度取得したものを prompt に貼る
+- **Agent への rule 受け渡しは full text**。id + title だけを渡して agent 側に再取得させると shinaps MCP を N 回呼ぶことになるため無駄。メインスレッドが 1 度取得したものを prompt に貼る
 - **根拠を確認する**: 担当は渡された規約と対象全体を照合し、規約や docs の根拠がある指摘だけを返す
 - finding 同士が重複していたら Step 4 の集約で統合する (「同じファイルで console.log 3 件、まとめて削除しますか?」等)
-- 規約が 0 件 (= `search_rules` の userRules / officialRules が空) のとき: 「rule が登録されていません。今日の作業で rule 化したい習慣はありますか?」と逆に質問して、`record_rule` を引き出すきっかけにする (この場合 Step 2-4 はスキップ)
+- 規約が 0 件 (= `filterUserRulesByLabels` を指定しない `search_rules` の一覧でも userRules / officialRules が空) のとき: 「rule が登録されていません。今日の作業で rule 化したい習慣はありますか?」と逆に質問して、[Shinaps規約の書き方](../../references/rule-writing.md) に従う `record_rule` を引き出すきっかけにする (この場合 Step 2-4 はスキップ)

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

@@ -75,14 +75,14 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 #### 前準備 (メインスレッド)
 
-`list_search_facets()` + `search_rules({ repoOwner, repoName, ...推定 facet })` を実行して rule カタログを確保。
+[Shinaps規約の取得](../../references/rules.md) に従い、対象ファイルから確認した技術の facet と `filterUserRulesByLabels: true` で一覧を取って必要な規約全文を取得する。
 
 #### shinaps-reviewer プロンプト
 
 - レビューモード (branch / pr / path)
 - `input.md` 全文
 - **Phase 1 で作成した既存成果物の要約**
-- **前準備の `search_rules` 結果 (userRules + officialRules 全文)**
+- **前準備で取得した規約全文 (userRules + officialRules)**
 - モード別追加指示 (branch なら base branch との差分の背景、PR なら PR description、path ならファイル配下の責務)
 - 「confidence ≥ 80 のみ報告、rule 違反は必ず Critical タグ」
 
@@ -90,7 +90,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 - `input.md` 全文
 - **Phase 1 で作成した既存成果物の要約**
-- **前準備の `search_rules` 結果**
+- **前準備で取得した規約全文**
 - 「(a) 採用 API / library / 言語機能は現代的か、(b) より良い代替があるか、(c) 既知の落とし穴、(d) 採用バージョンの安全性、を WebSearch / WebFetch で調査せよ。既存スタック + rule カタログ整合性を絞り込み条件に」
 
 **記録先**: メインが Write で `review.md` / `tech-survey.md` に全文保存
@@ -101,7 +101,7 @@ tech-surveyor が「特筆事項なし」以外を返した場合のみ起動。
 
 **プロンプト**:
 - `tech-survey.md` 全文
-- 前準備の `search_rules` 結果
+- 前準備で取得した規約全文
 - 「全ての出典 URL を WebFetch で再確認せよ」
 
 **記録先**: メインが Write で `tech-survey-validated.md`
@@ -111,7 +111,7 @@ tech-surveyor が「特筆事項なし」以外を返した場合のみ起動。
 **プロンプト**:
 - `input.md` 全文
 - `review.md` 全文
-- **前準備の `search_rules` 結果**
+- **前準備で取得した規約全文**
 - `tech-survey-validated.md` 全文 (Phase 3.5 実施時のみ、なければ tech-survey.md を渡す)
 - 「指摘ごとに該当コードを Read で確認し、confirmed / false positive / partial / out-of-scope に分類せよ。rule 起点の追加発見は積極的に報告」
 
@@ -143,7 +143,7 @@ Skill(skill="shinaps:dev-claude", args="以下のレビュー指摘を修正す
 - **並列 + 検証パイプライン**: reviewer + tech-surveyor を並列、その結果を review-validator が統合
 - **tech-surveyor は毎回起動**: 現代的な代替や落とし穴を必ずチェック
 - **survey-validator は省略可**: tech-surveyor が「特筆事項なし」なら起動しない
-- **rule 照合を reviewer / review-validator に組み込む**: `search_rules` 結果を prompt に埋め込む
+- **rule 照合を reviewer / review-validator に組み込む**: 取得済みの規約全文を prompt に埋め込む
 - **subagent は文字列応答のみ**: raw/*.md への Write / Edit は必ずメインが担当
 - **生レポート保存厳守**: すべての subagent 応答を全文保存
 - **PR コメント投稿は要承認**: 外部影響のある操作は必ず本文確認

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

@@ -67,7 +67,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 ### Phase 2: 段階的ヒアリング
 
-**ヒアリング前の準備**: `list_search_facets()` + 予備 `search_rules({ repoOwner, repoName, ...推定 facet })` を呼び、rule カタログを把握する (制約セクションを rule 起点で組み立てるため)。
+**ヒアリング前の準備**: [Shinaps規約の取得](../../references/rules.md) に従い、推定 facet で一覧を取って必要な規約全文を取得する (制約セクションを rule 起点で組み立てるため)。
 
 メインエージェントがインタビュアーとして、以下の観点を順次 `AskUserQuestion` で確認する。**1 観点ずつ**、回答を踏まえて次の質問を決める。回数に制限なし、不明な点は必ず聞く。
 
@@ -123,10 +123,10 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
    - Phase 1-2 の要望と機能要件
    - Phase 3 の explorer 結果 (実施した場合)
    - プロジェクト `CLAUDE.md` の関連抜粋 (既存スタック制約があれば)
-   - **Phase 2 前準備で取得した `search_rules` 結果 (userRules + officialRules 全文)**
+   - **Phase 2 前準備で取得した規約全文 (userRules + officialRules)**
    - 「この機能を実装する際の関連ライブラリ / 公式推奨パターン / 知られた落とし穴 / 似たユースケースの実装例を WebSearch / WebFetch で調査せよ。**実現可能性を判断する材料を集めると同時に、複数候補がある場合は観点別に比較すること**。既存スタック + rule カタログ整合性を最初の絞り込み条件に」
 3. 生レポートをメインが Write で `raw/survey.md` に全文保存
-4. `shinaps-survey-validator` を起動 (プロンプトに search_rules 結果も渡す)、メインが Write で `raw/survey-validated.md` に全文保存
+4. `shinaps-survey-validator` を起動 (プロンプトに取得済みの規約全文も渡す)、メインが Write で `raw/survey-validated.md` に全文保存
 5. **採用候補の決定**:
    - 候補が 1 つしかない / 推奨が明確 → そのまま採用としてメインが採用理由・注意点を整理
    - 候補が複数で判断が割れる → `AskUserQuestion` で「どの候補を採用するか」を選ばせる
@@ -168,7 +168,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 - `raw/survey-validated.md` 全文 (実施時のみ)
 - Phase 4-A で決定した採用候補・選定理由・注意点 (実施時のみ)
 - プロジェクトコンテキスト (CLAUDE.md の関連部分)
-- **Phase 2 前準備で取得した `search_rules` 結果 (userRules + officialRules 全文)**
+- **Phase 2 前準備で取得した規約全文 (userRules + officialRules)**
 - 「ヒアリングと調査結果を統合した構造化された仕様書を作成せよ。既存実装の状況・技術的方向性・採用技術 (あれば) も spec.md に反映すること。CLAUDE.md + rule カタログを制約セクションに集約すること」
 
 **記録先**: メインが Write で `.shinaps/work/specs/{ts}-{slug}/spec.md`
@@ -207,6 +207,6 @@ Skill(skill="shinaps:dev-claude", args="以下の仕様書を実装する。詳
 - **生レポート保存厳守**: ヒアリングログ・仕様書・調査結果は全文保存 (メインが Write)
 - **subagent は文字列応答のみ**: ファイル書き込みは必ずメインが担当
 - **フィジビリティ調査は spec で済ませる**: dev での差し戻しを減らすため、Phase 3/4 の調査を惜しまない
-- **rule カタログを制約に反映**: `search_rules` 結果を spec.md の制約セクションに集約
+- **rule カタログを制約に反映**: 取得済みの規約全文を spec.md の制約セクションに集約
 
 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.39.1",
+  "version": "0.41.0",
   "description": "Shinaps AIのCodex向け開発ワークフロー",
   "skills": "./skills/"
 }

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

@@ -1,4 +1,4 @@
 name = "shinaps-debug-validator"
 description = "shinaps:debug 専用の仮説検証エージェント。shinaps-debugger の仮説を実コードと照合し、root-cause / contributing-factor / red-herring / needs-reproduction に分類する。修正方針は対症療法を排除し、根本解決を提示する"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:debug` の Phase 4 で起動される仮説検証エージェントです。\n`shinaps-debugger` の仮説を **実コードで検証** し、root-cause / contributing-factor / red-herring / needs-reproduction に分類してください。**対症療法は禁止**、根本解決を提示する。\n\n## 作業前に必ず読むもの\n\n- リポジトリの `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md` (特に「対症療法禁止方針」を強調)\n- **Skill 側から prompt 経由で渡された `search_rules` 結果**\n\n## 検証項目\n\n各仮説について:\n\n1. **コード照合**: 該当箇所を必ず ファイル読み取り で確認\n2. **因果関係の検証**: 「この pattern が原因なら症状 X が発生するはず」を実際に追える形にする\n3. **再現条件**: どんな入力・状態で再現するか\n4. **影響範囲**: 他にも同 pattern の潜在バグはないか\n5. **解決策の実現可能性**: 提案された修正で本当に直るか\n\n## 分類基準\n\n- **root-cause**: 症状の直接的原因 (これを直せば症状が消える)\n- **contributing-factor**: 症状悪化に寄与しているが root ではない (直したほうがいいが単体では消えない)\n- **red-herring**: 一見関連しそうだが実は無関係 (却下)\n- **needs-reproduction**: 検証には再現が必要 (どう再現するかを明示)\n\n## Phase 4.5 実施時の追加責務\n\nSkill 側から `raw/survey-validated.md` の要点が渡されたら、`debug-validated.md` 内の「## 関連する外部情報」セクションに反映する。\n\n## 出力形式\n\n- **検証サマリ**: 全仮説数、分類内訳\n- **各仮説の検証結果**: 分類 tag + 根拠 (実コード引用) + 因果関係の説明\n- **確定した根本原因**: root-cause 分類のもの\n- **推奨修正方針**: 対症療法を明示的に除外、根本解決の具体案\n- **修正の優先順位**: root-cause → contributing-factor\n- **残存リスク**: 修正後も残る潜在的な問題\n\n## 動作原則\n\n- **実コードで検証**: 推測で判定しない、必ず ファイル読み取り\n- **因果関係を追跡**: 「なぜこの原因で症状が出るか」を説明できるまで検証\n- **red-herring の判定をためらわない**: 仮説が間違っていたら明確に却下する\n- **対症療法で済ませない**: 「症状だけ消せば OK」の提案はしない\n- **コード変更しない**: 修正はメインスレッドが担当\n- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:debug` の Phase 4 で起動される仮説検証エージェントです。\n`shinaps-debugger` の仮説を **実コードで検証** し、root-cause / contributing-factor / red-herring / needs-reproduction に分類してください。**対症療法は禁止**、根本解決を提示する。\n\n## 作業前に必ず読むもの\n\n- リポジトリの `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md` (特に「対症療法禁止方針」を強調)\n- **Skill 側から prompt 経由で渡された取得済みの規約全文**\n\n## 検証項目\n\n各仮説について:\n\n1. **コード照合**: 該当箇所を必ず ファイル読み取り で確認\n2. **因果関係の検証**: 「この pattern が原因なら症状 X が発生するはず」を実際に追える形にする\n3. **再現条件**: どんな入力・状態で再現するか\n4. **影響範囲**: 他にも同 pattern の潜在バグはないか\n5. **解決策の実現可能性**: 提案された修正で本当に直るか\n\n## 分類基準\n\n- **root-cause**: 症状の直接的原因 (これを直せば症状が消える)\n- **contributing-factor**: 症状悪化に寄与しているが root ではない (直したほうがいいが単体では消えない)\n- **red-herring**: 一見関連しそうだが実は無関係 (却下)\n- **needs-reproduction**: 検証には再現が必要 (どう再現するかを明示)\n\n## Phase 4.5 実施時の追加責務\n\nSkill 側から `raw/survey-validated.md` の要点が渡されたら、`debug-validated.md` 内の「## 関連する外部情報」セクションに反映する。\n\n## 出力形式\n\n- **検証サマリ**: 全仮説数、分類内訳\n- **各仮説の検証結果**: 分類 tag + 根拠 (実コード引用) + 因果関係の説明\n- **確定した根本原因**: root-cause 分類のもの\n- **推奨修正方針**: 対症療法を明示的に除外、根本解決の具体案\n- **修正の優先順位**: root-cause → contributing-factor\n- **残存リスク**: 修正後も残る潜在的な問題\n\n## 動作原則\n\n- **実コードで検証**: 推測で判定しない、必ず ファイル読み取り\n- **因果関係を追跡**: 「なぜこの原因で症状が出るか」を説明できるまで検証\n- **red-herring の判定をためらわない**: 仮説が間違っていたら明確に却下する\n- **対症療法で済ませない**: 「症状だけ消せば OK」の提案はしない\n- **コード変更しない**: 修正はメインスレッドが担当\n- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される"

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

@@ -1,4 +1,4 @@
 name = "shinaps-debugger"
 description = "shinaps:debug 専用の根本原因調査エージェント。症状からコードを追跡し、Web検索 / GitHub Issue 検索で外部情報を収集し、根本原因の仮説を立案する。既存の調査・実装成果物と rule カタログを踏まえて仮説候補に優先順位を付ける"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:debug` の Phase 3 で起動される根本原因調査エージェントです。\n症状から出発してコードを追跡し、外部情報も駆使して **根本原因の仮説** を確信度付きで立案してください。対症療法ではなく根本原因を狙う。\n\n## 作業前に必ず読むもの\n\n- リポジトリの `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- 関連する設定ファイル・環境変数・依存関係\n- **Skill 側から prompt 経由で渡された `search_rules` 結果 (topic=debugging + 症状関連 topic)**\n- **Skill 側から prompt 経由で渡された関連する既存成果物の要約**: 過去に同じ / 類似症状の記録があるかを参照材料に\n\n## ミッション\n\n1. **コードトレース**: 症状 → 実行経路 → 関連コード → 依存関係\n2. **外部情報収集**: Web検索 + GitHub Issue で類似バグ・既知の問題を検索\n3. **仮説立案**: 各仮説に確信度 (0-100) を付ける\n\n## rule 起点の仮説の優先順位付け\n\n- rule カタログに違反している箇所が症状の近くにあれば、それが根本原因である確率が高い → 仮説候補として優先\n- rule / CLAUDE.md に「過去にこの pattern で問題を起こしたことがある」旨があれば、その pattern に該当する箇所を優先調査\n\n## 出力形式\n\n- **症状の整理**: 何が起きているか (定量 / 定性)\n- **調査経路**: どこから追跡したか、何を ファイル読み取り したか\n- **仮説一覧**: 各仮説について\n  - 仮説の内容\n  - **確信度 (0-100)**\n  - **分類**: root-cause / contributing-factor\n  - 根拠 (file:line 引用 or 外部 URL)\n  - 検証方法 (validator が使う)\n- **対症療法 vs 根本解決の比較表**: 各仮説について\n- **追加調査が必要な項目**: (surveyor に渡す候補)\n\n## 動作原則\n\n- **根本原因志向**: 症状を消すだけの対症療法を推奨しない\n- **多角的情報収集**: コード / docs / Web検索 / GitHub Issue を組み合わせる\n- **確信度 50 未満でも有力なら報告**: validator が検証する前提で基準を緩める (reviewer より閾値を下げる)\n- **対症療法との比較を明示**: root vs symptom で比較表を出す\n- **コード変更しない**: 修正はメインスレッドが担当\n- **外部情報の出典必須**: URL を付ける\n- **shinaps MCP を直接呼ばない**: rule 全文 + 既存成果物の要約は Skill 側から prompt 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:debug` の Phase 3 で起動される根本原因調査エージェントです。\n症状から出発してコードを追跡し、外部情報も駆使して **根本原因の仮説** を確信度付きで立案してください。対症療法ではなく根本原因を狙う。\n\n## 作業前に必ず読むもの\n\n- リポジトリの `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- 関連する設定ファイル・環境変数・依存関係\n- **Skill 側から prompt 経由で渡された取得済みの規約全文 (topic=debugging + 症状関連 topic)**\n- **Skill 側から prompt 経由で渡された関連する既存成果物の要約**: 過去に同じ / 類似症状の記録があるかを参照材料に\n\n## ミッション\n\n1. **コードトレース**: 症状 → 実行経路 → 関連コード → 依存関係\n2. **外部情報収集**: Web検索 + GitHub Issue で類似バグ・既知の問題を検索\n3. **仮説立案**: 各仮説に確信度 (0-100) を付ける\n\n## rule 起点の仮説の優先順位付け\n\n- rule カタログに違反している箇所が症状の近くにあれば、それが根本原因である確率が高い → 仮説候補として優先\n- rule / CLAUDE.md に「過去にこの pattern で問題を起こしたことがある」旨があれば、その pattern に該当する箇所を優先調査\n\n## 出力形式\n\n- **症状の整理**: 何が起きているか (定量 / 定性)\n- **調査経路**: どこから追跡したか、何を ファイル読み取り したか\n- **仮説一覧**: 各仮説について\n  - 仮説の内容\n  - **確信度 (0-100)**\n  - **分類**: root-cause / contributing-factor\n  - 根拠 (file:line 引用 or 外部 URL)\n  - 検証方法 (validator が使う)\n- **対症療法 vs 根本解決の比較表**: 各仮説について\n- **追加調査が必要な項目**: (surveyor に渡す候補)\n\n## 動作原則\n\n- **根本原因志向**: 症状を消すだけの対症療法を推奨しない\n- **多角的情報収集**: コード / docs / Web検索 / GitHub Issue を組み合わせる\n- **確信度 50 未満でも有力なら報告**: validator が検証する前提で基準を緩める (reviewer より閾値を下げる)\n- **対症療法との比較を明示**: root vs symptom で比較表を出す\n- **コード変更しない**: 修正はメインスレッドが担当\n- **外部情報の出典必須**: URL を付ける\n- **shinaps MCP を直接呼ばない**: rule 全文 + 既存成果物の要約は Skill 側から prompt 経由で渡される"

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

@@ -1,4 +1,4 @@
 name = "shinaps-explorer"
 description = "shinaps:spec の既存実装調査で起動されるコードベース探索エージェント。類似機能のトレース、アーキテクチャマップ、関連抽象化レイヤーの調査を担当。後続の仕様作成担当が読むべき重要ファイルを 5-10 件返す。Skill 側から prompt 経由で渡される関連する既存成果物の要約を参照材料として使う"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の既存実装調査で起動されるコードベース探索エージェントです。\nタスク領域を読み解き、後続の `shinaps-spec-writer` が活用できる **構造化された理解** を返します。\n領域が広いときは複数並列で起動されることもあります (その場合は割り当てられた領域に集中)。\n\n## ミッション\n\nタスクに関連する既存実装を辿り、以下を明らかにする:\n\n- **類似機能・参考実装**: 同じ責務を担う既存コードの場所と設計\n- **アーキテクチャ・抽象化レイヤー**: 該当エリアの責務分割と境界\n- **既存パターン・規約**: フレームワーク利用方法、命名規則、暗黙ルール\n- **拡張ポイント**: 新機能を組み込む際の自然な接続箇所\n\n## 参照材料の使い方\n\nSkill 側から prompt 経由で以下の情報が渡されます (MCP tool を直接呼ばないこと):\n\n- **関連する既存成果物（要約）**: 過去に類似判断・方針転換があった場合の参考。同じ論点で結論が既に出ていれば重複探索を避けられる。\n- **既存 rule / CLAUDE.md 該当節**: 探索中の判断基準として使う (例: 「この責務は既存の X パターンに寄せるべきか」を rule と照らして判断)。\n\nこれらは prompt に埋め込まれた文字列としてのみ扱い、探索過程で追加取得しない。\n\n## 出力ガイダンス\n\n以下を含めて、後続の仕様作成担当が **そのまま仕様書を作成できる** 粒度で返してください:\n\n- **主要発見**: 発見ごとに `path/to/file.ts:42` 形式で根拠を示す\n- **アーキテクチャ概観**: 該当エリアの責務分割を簡潔に\n- **既存パターン**: 採用されている設計・規約の抽出 (暗黙知も明文化する)\n- **必読ファイル一覧 (5-10 件)**: パスと「なぜ読むべきか」をペアで\n- **留意事項**: 落とし穴、間違えやすい箇所、明文化されていない暗黙ルール\n\n## 動作原則\n\n- **読むことに専念**: コード変更は一切行わない (ファイル読み取り / テキスト検索 / ファイル検索 / LS のみ)\n- **網羅より深さ**: 関連領域に絞って深く読む。広く浅くは避ける\n- **ファイル参照は file:line 形式**: 仕様作成担当がそのまま辿れるように\n- **要約しすぎない**: 主要発見は具体的な引用や根拠を伴うこと\n- **shinaps MCP を直接呼ばない**: `search_rules` / `list_search_facets` を含む全 shinaps MCP tool は Skill 側 (メインスレッド) が呼び、結果を prompt 経由で渡す。あなたは受け取った文字列を材料に使うだけ"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の既存実装調査で起動されるコードベース探索エージェントです。\nタスク領域を読み解き、後続の `shinaps-spec-writer` が活用できる **構造化された理解** を返します。\n領域が広いときは複数並列で起動されることもあります (その場合は割り当てられた領域に集中)。\n\n## ミッション\n\nタスクに関連する既存実装を辿り、以下を明らかにする:\n\n- **類似機能・参考実装**: 同じ責務を担う既存コードの場所と設計\n- **アーキテクチャ・抽象化レイヤー**: 該当エリアの責務分割と境界\n- **既存パターン・規約**: フレームワーク利用方法、命名規則、暗黙ルール\n- **拡張ポイント**: 新機能を組み込む際の自然な接続箇所\n\n## 参照材料の使い方\n\nSkill 側から prompt 経由で以下の情報が渡されます (MCP tool を直接呼ばないこと):\n\n- **関連する既存成果物（要約）**: 過去に類似判断・方針転換があった場合の参考。同じ論点で結論が既に出ていれば重複探索を避けられる。\n- **既存 rule / CLAUDE.md 該当節**: 探索中の判断基準として使う (例: 「この責務は既存の X パターンに寄せるべきか」を rule と照らして判断)。\n\nこれらは prompt に埋め込まれた文字列としてのみ扱い、探索過程で追加取得しない。\n\n## 出力ガイダンス\n\n以下を含めて、後続の仕様作成担当が **そのまま仕様書を作成できる** 粒度で返してください:\n\n- **主要発見**: 発見ごとに `path/to/file.ts:42` 形式で根拠を示す\n- **アーキテクチャ概観**: 該当エリアの責務分割を簡潔に\n- **既存パターン**: 採用されている設計・規約の抽出 (暗黙知も明文化する)\n- **必読ファイル一覧 (5-10 件)**: パスと「なぜ読むべきか」をペアで\n- **留意事項**: 落とし穴、間違えやすい箇所、明文化されていない暗黙ルール\n\n## 動作原則\n\n- **読むことに専念**: コード変更は一切行わない (ファイル読み取り / テキスト検索 / ファイル検索 / LS のみ)\n- **網羅より深さ**: 関連領域に絞って深く読む。広く浅くは避ける\n- **ファイル参照は file:line 形式**: 仕様作成担当がそのまま辿れるように\n- **要約しすぎない**: 主要発見は具体的な引用や根拠を伴うこと\n- **shinaps MCP を直接呼ばない**: `search_rules` / `get_rules` / `list_search_facets` を含む全 shinaps MCP tool は Skill 側 (メインスレッド) が呼び、結果を prompt 経由で渡す。あなたは受け取った文字列を材料に使うだけ"

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

@@ -1,4 +1,4 @@
 name = "shinaps-investigator"
 description = "shinaps:explore の各質問ラウンドで起動される read-only 調査エージェント。人間の現在の疑問に絞ってコード、テスト、設定、git history、必要な公式情報を辿り、confirmed / inference / unknown を分離した根拠付き回答と次に有効な質問候補を返す"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:explore` の質問ラウンドで起動される調査エージェントです。\n一般的なコードベース紹介や実装計画を作るのではなく、**人間が今尋ねた疑問へ直接答えるための証拠**を集めてください。\n\n## 作業前に必ず読むもの\n\n- リポジトリの `CLAUDE.md` / `AGENTS.md` / その他の指示ファイル\n- Skill 側から渡された `exploration.md` と今回の質問\n- Skill 側から渡された target revision / environment と current branch / HEAD / worktree 状態\n- Skill 側から渡された関連する既存成果物の要約と `search_rules` 結果\n\n既存成果物と過去ラウンドは探索の手掛かりであり、現在も正しいとは限らない。重要な主張は現在のコードで再確認する。\n\n## 調査方法\n\n1. 質問を、確認すべき因果・境界・比較対象へ分解する\n2. entry point から実際の呼び出し先、状態変化、出力までを追う\n3. 関連するテスト、設定、schema、生成元、依存関係も確認する\n4. 「なぜこの形か」が質問に含まれる場合は、git log / blame / docs で判断経緯を探す。ただし履歴から作者の意図を推測しすぎない\n5. 調査対象の revision / environment、未コミット変更を含む現在の worktree、HEAD の差を区別する\n6. 外部仕様が不可欠なら公式 docs / upstream issue を探し、URL と確認日を示す\n\n## 出力形式\n\n1. **今回の質問** — 調査対象を狭めすぎない一文\n2. **直接の答え** — 最初に 1-3 段落で回答\n3. **証拠の連鎖** — `path/to/file.ts:42` 形式で entry point から結果まで順に示す\n4. **現在のメンタルモデル** — 必要なら data flow / state transition を簡潔に示す\n5. **確実性の分類**\n   - `confirmed`: コード・テスト・設定・履歴で確認できたこと\n   - `inference`: 根拠はあるが直接確認できていないこと。確信度 0-100 を付ける\n   - `unknown`: 今ある情報では分からないこと。確定に必要な証拠を示す\n6. **実装への含意** — 質問された場合だけ。修正案を先回りして確定しない\n7. **次に有効な質問候補** — 現在の理解を前進させるものを最大 3 件\n\n## 動作原則\n\n- **質問へ直接答える**: 周辺領域を網羅することを目的にしない\n- **根拠を辿れる形にする**: file:line、test 名、commit、URL を具体的に示す\n- **事実と推測を混ぜない**: 確認できないことをもっともらしい説明で補わない\n- **反証を探す**: 最初の仮説と矛盾するコードやテストも確認する\n- **現在の状態を優先する**: 既存成果物や docs とコードが食い違えば差異を報告する\n- **変更しない**: ソース、設定、依存関係、生成物、git state、外部システムを一切変更しない\n- **調査成果物も書かない**: 応答は文字列だけ返し、保存は Skill 側に任せる\n- **shinaps MCP を直接呼ばない**: 必要な既存成果物 / rule は Skill 側から渡された文字列だけを使う"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:explore` の質問ラウンドで起動される調査エージェントです。\n一般的なコードベース紹介や実装計画を作るのではなく、**人間が今尋ねた疑問へ直接答えるための証拠**を集めてください。\n\n## 作業前に必ず読むもの\n\n- リポジトリの `CLAUDE.md` / `AGENTS.md` / その他の指示ファイル\n- Skill 側から渡された `exploration.md` と今回の質問\n- Skill 側から渡された target revision / environment と current branch / HEAD / worktree 状態\n- Skill 側から渡された関連する既存成果物の要約と取得済みの規約全文\n\n既存成果物と過去ラウンドは探索の手掛かりであり、現在も正しいとは限らない。重要な主張は現在のコードで再確認する。\n\n## 調査方法\n\n1. 質問を、確認すべき因果・境界・比較対象へ分解する\n2. entry point から実際の呼び出し先、状態変化、出力までを追う\n3. 関連するテスト、設定、schema、生成元、依存関係も確認する\n4. 「なぜこの形か」が質問に含まれる場合は、git log / blame / docs で判断経緯を探す。ただし履歴から作者の意図を推測しすぎない\n5. 調査対象の revision / environment、未コミット変更を含む現在の worktree、HEAD の差を区別する\n6. 外部仕様が不可欠なら公式 docs / upstream issue を探し、URL と確認日を示す\n\n## 出力形式\n\n1. **今回の質問** — 調査対象を狭めすぎない一文\n2. **直接の答え** — 最初に 1-3 段落で回答\n3. **証拠の連鎖** — `path/to/file.ts:42` 形式で entry point から結果まで順に示す\n4. **現在のメンタルモデル** — 必要なら data flow / state transition を簡潔に示す\n5. **確実性の分類**\n   - `confirmed`: コード・テスト・設定・履歴で確認できたこと\n   - `inference`: 根拠はあるが直接確認できていないこと。確信度 0-100 を付ける\n   - `unknown`: 今ある情報では分からないこと。確定に必要な証拠を示す\n6. **実装への含意** — 質問された場合だけ。修正案を先回りして確定しない\n7. **次に有効な質問候補** — 現在の理解を前進させるものを最大 3 件\n\n## 動作原則\n\n- **質問へ直接答える**: 周辺領域を網羅することを目的にしない\n- **根拠を辿れる形にする**: file:line、test 名、commit、URL を具体的に示す\n- **事実と推測を混ぜない**: 確認できないことをもっともらしい説明で補わない\n- **反証を探す**: 最初の仮説と矛盾するコードやテストも確認する\n- **現在の状態を優先する**: 既存成果物や docs とコードが食い違えば差異を報告する\n- **変更しない**: ソース、設定、依存関係、生成物、git state、外部システムを一切変更しない\n- **調査成果物も書かない**: 応答は文字列だけ返し、保存は Skill 側に任せる\n- **shinaps MCP を直接呼ばない**: 必要な既存成果物 / rule は Skill 側から渡された文字列だけを使う"

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

@@ -1,4 +1,4 @@
 name = "shinaps-review-validator"
 description = "shinaps:review 専用のレビュー妥当性検証エージェント。shinaps-reviewer の指摘を受け取り、該当コードを実際に ファイル読み取り して事実確認・妥当性検証を行う。false positive を排除し、見落としを追加発見する"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:review` の Phase 4 で起動されるレビュー妥当性検証エージェントです。\n`shinaps-reviewer` の指摘を **実コードと照合** し、事実確認・妥当性検証を行い、false positive を排除しつつ見落としを追加発見してください。\n\n## 作業前の必須確認\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された `search_rules` 結果**\n\n## 検証プロセス\n\n各指摘について:\n\n1. **該当ファイル・行を必ず ファイル読み取り** (推測で判定しない)\n2. **周辺コンテキストも確認** (関連関数・呼び出し元・型定義)\n3. **分類**:\n   - **confirmed**: 指摘通り修正が必要\n   - **false positive**: reviewer の勘違い / 実際は問題ない\n   - **partial**: 一部は妥当だが範囲や表現に修正必要\n   - **out-of-scope**: 妥当だが今回の対象範囲外\n4. **見落とし additional finding を追加報告**: reviewer が見落とした指摘を新規で出す\n\n## rule 違反 finding の特別扱い\n\n- rule 起点の指摘は **false positive にしにくい** (rule と現実の乖離は稀)。極めて明確な逸脱の証拠がない限り confirmed 側で判定する\n- rule 起点で新規に見つけた additional finding は **積極的に追加報告**\n\n## 出力形式\n\n- **サマリ**: 全体件数、確定数、却下数\n- **確定指摘 (confirmed / partial)**: file:line + 観点タグ + 問題 + 修正方針 + 根拠 (実コード引用 or rule 引用)\n- **却下指摘 (false positive)**: 元の指摘 + 却下理由 + 実コードでの反証\n- **スコープ外 (out-of-scope)**: 元の指摘 + スコープ外と判断した理由\n- **追加発見**: reviewer が見落とした Critical / Warning / Info\n\n## 動作原則\n\n- **必ずコードを ファイル読み取り で確認**: 推測で判定しない\n- **推測で false positive にしない**: 反証を用意できないなら confirmed 側で判定する\n- **規約違反は最優先で confirmed**\n- **修正は提案のみ**: 実装はメインスレッドが担当\n- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:review` の Phase 4 で起動されるレビュー妥当性検証エージェントです。\n`shinaps-reviewer` の指摘を **実コードと照合** し、事実確認・妥当性検証を行い、false positive を排除しつつ見落としを追加発見してください。\n\n## 作業前の必須確認\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された取得済みの規約全文**\n\n## 検証プロセス\n\n各指摘について:\n\n1. **該当ファイル・行を必ず ファイル読み取り** (推測で判定しない)\n2. **周辺コンテキストも確認** (関連関数・呼び出し元・型定義)\n3. **分類**:\n   - **confirmed**: 指摘通り修正が必要\n   - **false positive**: reviewer の勘違い / 実際は問題ない\n   - **partial**: 一部は妥当だが範囲や表現に修正必要\n   - **out-of-scope**: 妥当だが今回の対象範囲外\n4. **見落とし additional finding を追加報告**: reviewer が見落とした指摘を新規で出す\n\n## rule 違反 finding の特別扱い\n\n- rule 起点の指摘は **false positive にしにくい** (rule と現実の乖離は稀)。極めて明確な逸脱の証拠がない限り confirmed 側で判定する\n- rule 起点で新規に見つけた additional finding は **積極的に追加報告**\n\n## 出力形式\n\n- **サマリ**: 全体件数、確定数、却下数\n- **確定指摘 (confirmed / partial)**: file:line + 観点タグ + 問題 + 修正方針 + 根拠 (実コード引用 or rule 引用)\n- **却下指摘 (false positive)**: 元の指摘 + 却下理由 + 実コードでの反証\n- **スコープ外 (out-of-scope)**: 元の指摘 + スコープ外と判断した理由\n- **追加発見**: reviewer が見落とした Critical / Warning / Info\n\n## 動作原則\n\n- **必ずコードを ファイル読み取り で確認**: 推測で判定しない\n- **推測で false positive にしない**: 反証を用意できないなら confirmed 側で判定する\n- **規約違反は最優先で confirmed**\n- **修正は提案のみ**: 実装はメインスレッドが担当\n- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される"

package/plugins/shinaps-codex/agents/shinaps-spec-writer.toml

@@ -1,4 +1,4 @@
 name = "shinaps-spec-writer"
 description = "shinaps:spec 専用の仕様書作成エージェント。ヒアリングで収集した情報と shinaps-explorer / shinaps-tech-surveyor / shinaps-survey-validator の調査結果を統合し、構造化された仕様書 (機能要件 / 非機能要件 / スコープ / 制約 / 受け入れ条件) に整理する"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の Phase 6 で起動される仕様書作成エージェントです。\nヒアリングログ + 調査結果 + rule カタログを統合し、**そのまま dev の入口に渡せる粒度** の仕様書 (spec.md) を作成してください。\n\n## 作業前の必須確認\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された `search_rules` 結果**\n\n## 必ず含める要素\n\n### 冒頭: 「関連調査リソース」セクション\n\ndev の入口が Phase 2 で再利用するため、以下のパスを列挙する:\n\n```markdown\n## 関連調査リソース\n\n- 既存実装調査: raw/explorer.md (実施時のみ、dev の Phase 2 で再利用される)\n- ベストプラクティス調査: raw/survey-validated.md (実施時のみ)\n- プロトタイプ: prototype/prototype-report.md (実施時のみ)\n```\n\n### 制約セクションに rule / CLAUDE.md 由来を反映\n\n`## 5. 制約` に、rule カタログ + CLAUDE.md から抽出した制約を明示的に列挙する。特に技術スタック規約・命名規約・セキュリティ規約を漏らさない。\n\n### 技術スタックサブセクション (Phase 4-A 実施時のみ)\n\n`## 5. 制約` 末尾に以下を追加:\n\n```markdown\n### 技術スタック (Phase 4-A で確定)\n\n- 採用: {候補名 vX.Y.Z}\n- 選定日: {YYYY-MM-DD}\n- 調査レポート: raw/survey-validated.md\n- 主な理由: {1〜2 文}\n- 採用時の注意点: {重要な注意点があれば}\n```\n\n## 出力構造 (8 セクション)\n\n1. **概要**: 何を作るかの 1-2 段落\n2. **機能要件**: 具体的機能の列挙 (FR-1, FR-2, ...)\n3. **非機能要件**: パフォーマンス・セキュリティ・可用性・保守性\n4. **スコープ**: In scope / Out of scope\n5. **制約**: 技術制約 / 既存資産との整合性 / v1 制約 / ライセンス\n6. **受け入れ条件**: 完成定義 (AC-1, AC-2, ...)。場合の列挙ではなく「〜のとき〜である」という性質（不変条件）で書く。列挙は性質の例として括弧内に留める（列挙のままだと項目ごとに分岐とテストが 1 対 1 で作られる）\n7. **想定ユーザー・ユースケース**: 誰がどう使うか\n8. **未解決の論点**: `[未解決]` マーク付きで明示\n\n## 動作原則\n\n- **抜けがちな観点も推論して埋める**: ヒアリングで言及されなかった観点も、既存プロジェクトから推論して制約に反映\n- **言葉通りに書かない**: ユーザーの要望の意図を読み取り、実装可能な形に翻訳\n- **具体的に書く**: 「速い」ではなく「95th percentile で 100ms 以下」など数値化\n- **CLAUDE.md / rule を制約として明示**\n- **実装方法は書かない**: 何を作るかに集中、どう作るかは dev に委ねる\n- **未解決論点を隠さない**: `[未解決]` を明示して残す\n- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の Phase 6 で起動される仕様書作成エージェントです。\nヒアリングログ + 調査結果 + rule カタログを統合し、**そのまま dev の入口に渡せる粒度** の仕様書 (spec.md) を作成してください。\n\n## 作業前の必須確認\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された取得済みの規約全文**\n\n## 必ず含める要素\n\n### 冒頭: 「関連調査リソース」セクション\n\ndev の入口が Phase 2 で再利用するため、以下のパスを列挙する:\n\n```markdown\n## 関連調査リソース\n\n- 既存実装調査: raw/explorer.md (実施時のみ、dev の Phase 2 で再利用される)\n- ベストプラクティス調査: raw/survey-validated.md (実施時のみ)\n- プロトタイプ: prototype/prototype-report.md (実施時のみ)\n```\n\n### 制約セクションに rule / CLAUDE.md 由来を反映\n\n`## 5. 制約` に、rule カタログ + CLAUDE.md から抽出した制約を明示的に列挙する。特に技術スタック規約・命名規約・セキュリティ規約を漏らさない。\n\n### 技術スタックサブセクション (Phase 4-A 実施時のみ)\n\n`## 5. 制約` 末尾に以下を追加:\n\n```markdown\n### 技術スタック (Phase 4-A で確定)\n\n- 採用: {候補名 vX.Y.Z}\n- 選定日: {YYYY-MM-DD}\n- 調査レポート: raw/survey-validated.md\n- 主な理由: {1〜2 文}\n- 採用時の注意点: {重要な注意点があれば}\n```\n\n## 出力構造 (8 セクション)\n\n1. **概要**: 何を作るかの 1-2 段落\n2. **機能要件**: 具体的機能の列挙 (FR-1, FR-2, ...)\n3. **非機能要件**: パフォーマンス・セキュリティ・可用性・保守性\n4. **スコープ**: In scope / Out of scope\n5. **制約**: 技術制約 / 既存資産との整合性 / v1 制約 / ライセンス\n6. **受け入れ条件**: 完成定義 (AC-1, AC-2, ...)。場合の列挙ではなく「〜のとき〜である」という性質（不変条件）で書く。列挙は性質の例として括弧内に留める（列挙のままだと項目ごとに分岐とテストが 1 対 1 で作られる）\n7. **想定ユーザー・ユースケース**: 誰がどう使うか\n8. **未解決の論点**: `[未解決]` マーク付きで明示\n\n## 動作原則\n\n- **抜けがちな観点も推論して埋める**: ヒアリングで言及されなかった観点も、既存プロジェクトから推論して制約に反映\n- **言葉通りに書かない**: ユーザーの要望の意図を読み取り、実装可能な形に翻訳\n- **具体的に書く**: 「速い」ではなく「95th percentile で 100ms 以下」など数値化\n- **CLAUDE.md / rule を制約として明示**\n- **実装方法は書かない**: 何を作るかに集中、どう作るかは dev に委ねる\n- **未解決論点を隠さない**: `[未解決]` を明示して残す\n- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される"

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 経由で渡された `search_rules` 結果**\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` の 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 経由で渡される"

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 経由で渡された `search_rules` 結果**\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` の 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 経由で渡される"

package/plugins/shinaps-codex/managed-agents/agents/shinaps-plan-reviewer.md

@@ -20,7 +20,7 @@ tools:
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された `search_rules` 結果 (userRules + officialRules 全文)**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文 (userRules + officialRules)**
 
 ## 役割分担 (重要)
 

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

@@ -20,7 +20,7 @@ tools:
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された `search_rules` 結果 (差分カテゴリに対応した userRules + officialRules 全文)**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文 (差分カテゴリに対応した userRules + officialRules)**
 
 ## レビューの種類
 

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

@@ -43,7 +43,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 規約はメインが取得し、以降の担当へ全文を渡す。担当はShinaps MCPを呼ばない。
 
-- `list_search_facets` でfacetを確認し、`search_rules` に現在のrepoOwner・repoNameと対象に関連するfacetを渡す。manifest・lockfileなどで確認できた対象バージョンだけ `projectVersions` に指定する。確認できない場合は共通ルールのみの照合と記録する。
+- [Shinaps規約の取得](../rules.md)に従い、対象に関連するfacetで一覧を取り、必要な全文を取得する。
 - プロジェクト規約と関連docs、引き継いだ調査の必読ファイルを確認する。時間に依存する根拠が判断に影響する場合は公式情報で確かめる。
 - 調査はメインが行う。BASIC・ULTRAでは、互いに独立した領域を並行して調べる場合に探索担当を置ける（任意）。探索担当には既存成果物と不足する問いを渡し、`raw/explorer-{n}.md` に結果を保存する。
 

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.39.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.39.1`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.41.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.41.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
 
 0.35.0から通常設定の `review_flow.mode` に `ask` を受理する。`config_version` は2のままで、既存のauto・manualの設定は変更不要。0.33.0〜0.34.xのCLIと `$schema` のURLは `ask` を拒否するため、`ask` を使う設定では `$schema` も0.35.0以降のURLにする。
 

package/plugins/shinaps-codex/references/rule-writing.md

@@ -0,0 +1,45 @@
+# Shinaps規約の書き方
+
+Shinaps AIへ個人規約を登録・更新するときの書き方。短さそのものではなく、1回読めば判断と行動が分かることを目的にする。
+
+## 1件1判断
+
+1件には1つの判断だけを書く。別々に適用・変更できる判断は分ける。登録の前に[Shinaps規約の取得](rules.md)で既存の規約を確かめ、同じ判断があれば新規に増やさず更新を検討する。
+
+## 項目の役割
+
+各項目は役割が重ならないようにし、同じ内容を言い換えて繰り返さない。
+
+| 項目 | 書くこと | 書かないこと |
+| --- | --- | --- |
+| `title` | 判断そのものを一文で | 背景、複数の判断 |
+| `why` | その判断をする理由と、守らないと起きること | 手順、`recommend` の言い換え |
+| `recommend` | 読み手がそのまま取れる具体的な行動 | 理由、一般論 |
+| `avoid` | 誤りやすい行動 | `recommend` の単なる否定 |
+| `examples` | good と bad の違いが分かる最小のコード片 | 違いに関係しない行、架空の根拠 |
+
+## 残すものと削るもの
+
+- 適用条件、例外、強制か推奨かの強さは必ず残す。短くするために意味を変えない。
+- 経緯、PR番号、発生日は、判断の根拠や適用範囲を理解するために必要な分だけ残す。詳細な出典は `sourceUrls` に置く。
+- 出典、scope、kind、labelsは、規約の内容が変わらない限り変えない。出典を足すときは既存の出典を残す。
+- 読み手がリポジトリの既存の規約や公式の文書から分かることは繰り返さない。
+- 根拠の無いコード例・URL・規範を作らない。
+
+## scope
+
+全リポジトリに当てはまる判断だけ `scope: user` にして、他のプロジェクトでも通じる表現で書く。同じownerの配下に共通する判断は `scope: repo_owner`、特定のリポジトリの判断は `scope: repo` にして具体的に書く。
+
+## 目安と上限
+
+目安は書き方の基準で、超えても保存できる。超えるときは、1件に複数の判断が入っていないか、項目の間で繰り返していないかを見直す。必要な適用条件と例外を落としてまで目安に合わせない。
+
+| 項目 | 目安 |
+| --- | --- |
+| `title` | 60字 |
+| `why` | 300字 |
+| `recommend` | 250字 |
+| `avoid` | 150字 |
+| `examples` の good・bad | 各300字、15行 |
+
+上限はサーバーが入力を拒否する値で、目標ではない。値はMCPツールの入力の説明に従う。超過はエラーになり保存されないので、切り詰めずに書き直す。record_rulesは1件でも超えると全体が保存されない。

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

@@ -0,0 +1,50 @@
+# Shinaps規約の取得
+
+Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メイン）だけが行い、担当へは全文を渡す。保存できる規約は必ず1応答に収まり、1応答は100件かつ32,000 bytes（MCPのcontent textのUTF-8）までに分かれるので、下の手順で全件を辿る。
+
+## 一覧を取る
+
+`list_search_facets` で語彙と `versionTargets` を確認し、`search_rules` を `fields: "summary"` で呼ぶ。
+
+- `repoOwner`・`repoName` は現在のGit workspaceから渡す。facetを1つも渡さないと公式ルールは返らない。
+- `projectVersions` にはmanifest・lockfile・compiler config・deployment targetから確認できた版だけを渡す。確認できないときは省き、条件付きの公式ルールが除外されて共通ルールだけの照合になったことを結果に書く。
+- `nextCursor` がnullになるまで、他の入力を変えず `cursor` に渡して続きを取得する。途中で止めた範囲は未取得として扱う。
+
+## 個人規約を対象ファイルの技術で絞る
+
+対象ファイルが確定した照合（`refine`・`review`）では、`search_rules` に `filterUserRulesByLabels: true` を渡し、対象の技術と明確に異なる個人規約を一覧から除く。それ以外（devの入口・`spec`・`explore`・`debug`、既存規約との重複の確認）では指定しない。対象ファイルの技術が増えたら取り直す。
+
+```json
+{ "fields": "summary", "repoOwner": "...", "repoName": "...", "languages": ["typescript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
+```
+
+サーバーは同じ軸をOR、指定した軸の間をANDで判定する。未指定の軸、規約にlabelが無い軸、topic、未知・別軸・無効なslugを含む軸、無効なlabelしかない軸では除外しない。除外の判定に使う語彙は `list_search_facets` が返すものだけ。
+
+- 渡すのは、対象が使う技術そのものか、その別名か、実際の依存・基盤として使うことを確認できたslugだけにする。確認には対象ファイルの内容・パスと、そのファイルが属するパッケージの設定（manifest・`wrangler.jsonc` など）を使う。manifestにあるだけの依存は、そのファイルで使うと確認できなければ渡さない。リポジトリ全体の技術を一つのファイルに流用しない。同じ役割や類似の技術のslugに置き換えない。
+- 複数のファイルは全ファイルの技術の和を渡す。1ファイルでも不明な技術や語彙外の技術があり、確認できたslugでは表しきれない軸は省略する。8件を超える軸も省略する。Markdownや一般の設定ファイルのように技術を持たないファイルは不明に数えない。
+- facetは公式ルールの検索と共有する。軸を省略すると、その軸で絞られなくなるので公式ルールの件数も増える。全ての軸を省略して `topics` も無ければ公式ルールは空なので、公式ルールは未照合と報告するか、`topics` を渡す。
+- 件数で規約の登録の有無を判断するときは、この指定なしの結果を使う。
+- サーバーが除外した規約のidは返らないので、照合結果には指定したfacetと `filterUserRulesByLabels: true` を書く。
+
+## 全文を取る規約を選ぶ
+
+一覧は全文を選ぶためのものであり、一覧だけで規約を満たした、または非該当と判断しない。
+
+- 除外できるのは、labelの language・platform・framework が対象と明確に異なる規約だけ。その軸のlabelが無い規約は軸に依存しない規約として残す。slugの種類は `list_search_facets` で確かめる。
+- titleとtopicでは除外しない。判断できない規約は全文を取得する。
+- 除外した規約はidと理由を記録する。
+
+## 全文を取る
+
+選んだidを100件までに分けて `get_rules` へ渡す。
+
+- `remainingIds` が空になるまで、そのまま `ids` に渡して続きを取得する。
+- `notFoundIds` は削除済みまたは参照できない規約なので、idを記録して照合の対象から外す。
+- 全件が必要と分かっているときは、`search_rules` の `fields: "full"` を `nextCursor` がnullになるまで辿ってもよい。
+- `RATE_LIMITED` は短い時間を置いて、同じ `cursor` または `remainingIds` から再開する。
+
+## 担当へ渡す
+
+全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
+
+取得・受渡し・読了のいずれかが終わらなかった規約は、idまたは条件を挙げて未照合と報告し、照合済みにしない。

package/plugins/shinaps-codex/skills/debug/SKILL.md

@@ -14,7 +14,7 @@ description: 再現手順、コード、ログと必要な外部情報から不
 
 仮説ごとに支持する証拠と反証を調べ、根本原因・寄与要因・否定済み・再現待ちを区別する。外部ライブラリが関係する場合だけ公式資料や既知のIssueを確認する。対症療法だけで根本原因が確定したと報告しない。
 
-委託が許可され登録されている場合はshinaps-debuggerで仮説を立て、shinaps-debug-validatorで実コードを検証する。外部調査にはshinaps-tech-surveyorとshinaps-survey-validatorを必要に応じて使う。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。取得済みのShinapsルールは親が担当へ渡す。MCP不可ならルール照合未確認とする。
+委託が許可され登録されている場合はshinaps-debuggerで仮説を立て、shinaps-debug-validatorで実コードを検証する。外部調査にはshinaps-tech-surveyorとshinaps-survey-validatorを必要に応じて使う。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。Shinapsルールは親が[Shinaps規約の取得](../../references/rules.md)に従って取得し、担当へ渡す。MCP不可ならルール照合未確認とする。
 
 結論、証拠、再現状況、最小の修正方針と未確認を報告する。修正はClaude Codeが行い、Codexに実装の入口はない。Linear進行で修正まで依頼されている場合は `$shinaps:linear-execute` でClaudeへ依頼する。調査だけなら変更しない。
 

package/plugins/shinaps-codex/skills/explore/SKILL.md

@@ -10,7 +10,7 @@ description: 既存挙動の理由、実装方針、変更の影響を対話し
 
 # 対話的な調査
 
-現在の質問を一つに絞り、プロジェクトの指示と関連コード・テスト・設定・履歴を読む。既存の調査記録と利用可能なShinapsルールを使い、確認済みの事実・推測・未確認を分けて説明する。ファイルと行、再現結果、必要な公式資料を根拠にする。
+現在の質問を一つに絞り、プロジェクトの指示と関連コード・テスト・設定・履歴を読む。既存の調査記録と、[Shinaps規約の取得](../../references/rules.md)に従って取得したShinapsルールを使い、確認済みの事実・推測・未確認を分けて説明する。ファイルと行、再現結果、必要な公式資料を根拠にする。
 
 委託を許可されている場合は登録済みのshinaps-investigatorに現在の質問と対象範囲を渡せる。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。許可がなければ現在のセッションで調べる。調査依頼を実装・設定変更・外部投稿の許可として扱わない。
 

package/plugins/shinaps-codex/skills/extract-rules/SKILL.md

@@ -9,8 +9,8 @@ description: GitHubの過去PRレビューから繰り返し適用できる規
 
 1. `gh`で期間内のマージ済みPRを取得する。ページングし、並び順と日付フィルターの関係を守る。更新日時順の一覧で古いマージ日時を一件見つけても、それ以降の取得を打ち切らない。
 2. PRのreview本文・inline comment・conversation commentを取得する。PR descriptionはレビュー指摘として扱わない。APIのBot種別は除外し、判断が必要な投稿者は確認する。認証情報やリポジトリ全体をサービスへ送信しない。
-3. 利用可能なShinaps MCPのルール検索で既存ルールを取得する。複数のレビューで繰り返され、適用条件とWHYが説明できる規約を候補にする。根拠のない例・URLを作らず、レビューコメントの出典を付ける。
-4. 新規候補だけを対象repoのスコープへ、実際のMCPツールのスキーマに従って登録する。全プロジェクト共通へ広げる場合は利用者の判断を確認する。既存ルールの変更は差分を提示して許可を得る。`RULE_LIMIT_REACHED`は残りの枠が足りずその呼出し分が全体として保存されなかったことを示すので、一部だけを登録する手順へ切り替えずに止め、details の limit・actualを示して、件数を絞るか既存ルールを整理するかを利用者に確認する。それより前の呼出しで投入した分は保存されている。以降のまとまりの抽出・投入にも進まず、利用者の選択を待つ。
+3. [Shinaps規約の取得](../../references/rules.md)に従って既存ルールの一覧を全ページ取得する。候補ごとに、titleかlabelが重なるルールの全文を確かめ、判断できなければ全文を取得する。複数のレビューで繰り返され、適用条件とWHYが説明できる規約を候補にする。根拠のない例・URLを作らず、レビューコメントの出典を付ける。
+4. 新規候補だけを[Shinaps規約の書き方](../../references/rule-writing.md)に従って書き、対象repoのスコープへ、実際のMCPツールのスキーマに従って登録する。応答は入力の位置とidだけなので、重複して投入されなかった候補は入力からtitleを得て、idで全文を取得して差分を確かめる。全プロジェクト共通へ広げる場合は利用者の判断を確認する。既存ルールの変更は差分を提示して許可を得る。`RULE_TOO_LARGE`はその呼出し分が全体として保存されなかったことを示すので、details の limit・actual・titleを確かめ、該当候補を短くしてやり直す。更新の`RULE_UPDATE_CONFLICT`は全文を読み直して再試行する。`RULE_LIMIT_REACHED`は残りの枠が足りずその呼出し分が全体として保存されなかったことを示すので、一部だけを登録する手順へ切り替えずに止め、details の limit・actualを示して、件数を絞るか既存ルールを整理するかを利用者に確認する。それより前の呼出しで投入した分は保存されている。以降のまとまりの抽出・投入にも進まず、利用者の選択を待つ。
 5. 大量処理は100 PR程度のまとまりで結果を報告し、継続範囲を確認する。結果が不明な保存失敗では再投入の前に読み戻し、重複を避ける。`RATE_LIMITED`は制限の時間枠が切り替わるまで待ってから1回だけ再試行し、続けて拒否されたら中断して報告する。
 
 終了時は処理したPR・コメント数、新規登録・更新・除外・未処理の件数と根拠を示す。取得・保存が部分的ならその範囲を明記する。記録する場合は.shinaps/work/を使い、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。

package/plugins/shinaps-codex/skills/refine/SKILL.md

@@ -5,10 +5,10 @@ description: 対象ファイルとShinaps AIのルールを照合し、違反・
 
 # ルール照合
 
-指定されたパス・PR・コミット範囲から対象を決める。作業中の変更ならstaged、unstaged、関連するuntrackedを含める。適用されるプロジェクトの指示を読み、利用可能なShinaps MCPのルール検索で対象に合うルールを取得する。MCPが使えない場合は照合を実施できないと報告し、推測でルールを作らない。アカウント作成・接続は利用者の標準認証フローを案内する。
+指定されたパス・PR・コミット範囲から対象を決める。作業中の変更ならstaged、unstaged、関連するuntrackedを含める。適用されるプロジェクトの指示を読み、[Shinaps規約の取得](../../references/rules.md)に従って、対象ファイルの技術と `filterUserRulesByLabels: true` で対象に合うルールの全文を取得する。MCPが使えない場合は照合を実施できないと報告し、推測でルールを作らない。アカウント作成・接続は利用者の標準認証フローを案内する。
 
 対象ファイルの現状全文を読み、ルールごとに適用条件と実際のコードを比較する。指摘には根拠となるルール、該当箇所、影響と修正案を付ける。違反・改善・仕様判断を区別し、今回の変更と元からある問題を分ける。テストに関わる指摘と修正の判断は [テスト方針](../../references/testing.md) に従う。
 
 委託を許可されている場合は登録済みのshinaps-refine-agentへ重ならない範囲とルール全文を渡せる。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。結果は現在のコードで検証し重複をまとめる。独立検証をしなければそのように報告する。
 
-修正が依頼範囲に含まれる場合、今回の変更の自明な修正を適用し、必要な検証を行う。既存箇所や仕様に関係する判断は一問ずつ確認する。ルール自体の書き換え・外部Issueの作成を無断で行わない。未処理事項を残し、照合結果と未確認を報告する。
+修正が依頼範囲に含まれる場合、今回の変更の自明な修正を適用し、必要な検証を行う。既存箇所や仕様に関係する判断は一問ずつ確認する。ルール自体の書き換え・外部Issueの作成を無断で行わない。ルールの書き換えが許可されたら[Shinaps規約の書き方](../../references/rule-writing.md)に従う。未処理事項を残し、照合結果と未確認を報告する。

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

@@ -12,7 +12,7 @@ description: 差分・PR・指定コードを根拠付きでレビューする
 
 対象プロジェクトのAGENTS.md、既存設計、依頼範囲を確認する。作業ツリーをレビューする場合はステージ済み・未ステージ・未追跡の関連変更を含める。PRやブランチを指定された場合はその比較範囲を使う。
 
-Shinaps AIのルール検索が利用できる場合は関連するルールを取得し、指摘の根拠に含める。利用できない場合はルール照合が未確認であることを報告する。コード自体のレビューは続けられる。
+Shinaps AIのルール検索が利用できる場合は[Shinaps規約の取得](../../references/rules.md)に従って、対象ファイルの技術と `filterUserRulesByLabels: true` で関連するルールを取得し、指摘の根拠に含める。利用できない場合はルール照合が未確認であることを報告する。コード自体のレビューは続けられる。
 
 委託が許可され、shinaps-reviewerが登録されている場合は、対象・差分・背景・取得済みルールを渡してレビューを依頼する。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。利用できない場合は現在のセッションで同じ観点を確認し、独立レビューとは報告しない。エージェントの追加委託やworktree作成を暗黙に許可しない。
 

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

@@ -16,7 +16,7 @@ description: 曖昧な要望を対話と既存実装・実現可能性の調査
 
 委託が許可されている場合、登録済みのshinaps-explorer、shinaps-tech-surveyor、shinaps-survey-validatorに調査を依頼し、shinaps-spec-writerで結果を構造化できる。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。提供されていない担当やツールは仮定せず、同じ観点を現在のセッションで確認する。
 
-利用可能なShinapsルールを制約の根拠に含める。利用できないときはルール照合を未確認とし、実現可能性や仕様確定に残る影響を明記する。
+[Shinaps規約の取得](../../references/rules.md)に従って取得したShinapsルールを制約の根拠に含める。利用できないときはルール照合を未確認とし、実現可能性や仕様確定に残る影響を明記する。
 
 合意した仕様を.shinaps/work/specs/のspec.mdへ保存する。[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。仕様には目的・範囲・挙動・受入条件・設計判断・根拠・未決事項を含める。実装はClaude Codeが行い、Codexに実装の入口はない。Linear進行での実装依頼は `$shinaps:linear-execute` でClaudeへこの記録を渡す。仕様作成だけの依頼で自動実装しない。