@shinaps/skills 0.47.0 → 0.49.0

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

@@ -1,209 +0,0 @@
----
-name: refine
-description: 対象ファイルの現状全文と規約を Opus / medium 1担当で照合する。今回の変更と既存箇所を区別して修正・報告する。
-argument-hint: "[<file/dir path> | <PR URL> | <commit SHA> | <range>] (省略時は git diff HEAD の変更ファイル)"
----
-
-## 作業記録の保存先
-
-作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
-
-## 実行環境とプロジェクト条件
-
-この節は以下の工程全体に適用する。適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから今回の条件を読み、明示された依頼・許可を引き継ぐ。仕様に影響する不足だけ一問ずつ確認する。新しい恒久方針の保存はユーザーの了承を得てプロジェクト側へ行う。
-
-Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用できる場合は対応するツールを使う。現在のセッションで提供されていないツールは仮定しない。質問は一問ずつ確認して回答を待つ。
-
-別セッションへの委託・新しいworktreeは明示された許可がある場合だけ行う。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。独立レビューがプロジェクトの必須条件なら未完了として扱う。Shinapsのエージェント名はClaudeのpluginで公開された名前を使う。サービスのrule照合が必要な工程でMCPを利用できなければ、その工程を未確認として報告し、照合済みとしない。
-
-# shinaps:refine — 規約照合の checkpoint
-
-呼び出し時に「照合のみ」と指定された場合は、以下の修正工程を実行せず、findings と修正案を呼び出し元へ返す。並行レビューが同じ差分を確認できるよう、対象ファイルとルールを変更せず、修正の質問も呼び出し元に集約する。
-
-このスキルは「commit / report 直前の self-review」を確実に行うためのバッチ照合手順書。CLAUDE.md に「セルフレビュー直前 → search_rules で規約照合」と書かれていても AI (あなた) が頻繁にスキップするので、その対策としてユーザーが手動で起動するためにある。
-
-照合対象は **ファイルの現状全文** であって diff ではない。diff の hunk だけでは「この関数全体の責務が正しいか」「この命名は周囲と揃っているか」「規約が要求する構造がファイル内に揃っているか」を判断できず、追加行だけ見て規約準拠に見えても、ファイル全体としては規約から外れているケースを見落とすため。git は **どのファイルを見るか** を決める用途と、finding が **今回の変更に含まれる箇所か** を判定する用途に使う。
-
-計画段階では起動しない。rule の大半はコメントの WHY / 命名 / import 経路といったコードレベルの規約で、自然言語の計画テキストからは検出できないため。計画段階で指摘する価値がある設計レベルの規約違反は `shinaps-plan-reviewer` が担当する。
-
-shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて Claude Code 側のあなたが手元の `git` / `Read` / 既存 MCP tools で実行する (private repo の内容をサーバ境界に渡さない設計)。
-
-## 全体アーキテクチャ
-
-メインスレッド (あなた) は **オーケストレータ** に徹する:
-
-1. 対象ファイル集合の確定、規約カタログの集約 (Step 0-1)
-2. 機械検査で静的に保証できた組を照合から外し、規約・対象ファイルを担当へ渡せる形に整理する (Step 2)
-3. Opus / medium 1体を起動し、全対象を照合する (Step 3)
-4. 返ってきた findings を集約 → 変更箇所 / 既存箇所で振り分け (Step 4-5)
-
-## Step 0. 対象ファイルを確定する (MUST)
-
-以下の優先順位で **対象ファイル集合** を決める:
-
-1. **ユーザーが対象を明示していたらそれを最優先**。`/shinaps:refine` と一緒に以下を書いてくることがある:
-   - **ファイル / ディレクトリ path** (例: `apps/api/src/mcp/`) → その path 配下のファイルをそのまま対象集合にする (変更の有無を問わない)。ディレクトリなら `git ls-files <path>` で列挙する
-   - **PR URL** (例: `https://github.com/owner/repo/pull/123`) → `gh pr diff 123 --repo owner/repo --name-only` で変更ファイル一覧を取得。カレント repo と同じなら `--repo` は省略可
-   - **commit SHA / range** (例: `abc123` / `main..feature` / `HEAD~3..HEAD`) → `git diff --name-only <range>` で変更ファイル一覧を取得
-2. 明示指定がなければ `git diff --name-only HEAD` (= staged + unstaged の合計、ローカルで変更したファイルすべて)
-3. それでも 0 件なら **ユーザーに確認**: 「変更がありません。直近の commit (`git diff --name-only HEAD~`) または特定のファイル / commit / PR を対象にしますか?」
-4. 削除されたファイルは対象集合から除く (現状が存在しない)
-
-対象が決まったらユーザーに「以下 N ファイルの現状を refine します」と 1 行で宣言してから先に進む。**Step 3 で各 agent に渡すファイル一覧と「変更範囲の確認コマンド」も、ここで決めた集合に必ず合わせること** (agent が独立に `git diff HEAD` を実行して対象を取り違えないよう prompt に具体コマンドを埋め込む)。
-
-**ファイル数による一律の上限は設けない**。確定した対象集合を維持し、件数の多さだけを理由に対象の縮小やユーザーへの分割確認を求めない。対象の内容量が大きい場合は、ファイルの行数・内容量と関連性（ディレクトリ、機能、依存関係）を見て自動的にバッチへ分ける。小規模なら分割は不要。関連ファイルはできるだけ同じバッチにまとめ、バッチをまたぐ契約は集約時に照合する。
-
-## Step 1. 規約と context を集約する
-
-[Shinaps規約の取得](../../references/rules.md) に従い、対象ファイルについて規約全文を取得する。userRules と officialRules の両方を照合対象にする。`kind` は通常指定しない (対象ファイル全体を rule 集合と広く照合する用途のため、絞り込むと見落としが増える)。
-
-次の資料は検索と並行して取得してよい:
-
-- repo root の `AGENTS.md` / `CLAUDE.md` を Read (プロジェクト規約)
-- AGENTS.md が `docs/` 等を「source of truth」として参照していたら **その docs も Read** (今回変更した領域に関連するものに限定して良い)
-- グローバル `~/.claude/CLAUDE.md` の `## コメントルール` `## 実装・設計に関して` 等の節 (一度読んだセッションなら conversation history で代替可)
-- 該当 repo の auto-memory `~/.claude/projects/<slug>/memory/MEMORY.md` がもしあれば Read
-
-これらを Step 2 で担当へ渡す共通の照合資料とする。
-
-## Step 2. 共通の照合対象を準備する
-
-取得した rule 全文に `checks` を持つ規約があれば、先に [規約の機械検査](../../references/lint.md) の「照合で使う」を行う。`covered`・`violation` の組（規約×ファイル）はそのファイルについて担当の照合対象から外し、`violation`・`partial` の findings は lint 由来の指摘として Step 4 に加える。担当には、ファイルごとに照合から外した規約の id を伝え、`partial` の組には lint の指摘を添える。
-
-取得した rule 全文と関連する AGENTS.md / CLAUDE.md / docs、対象ファイル、変更範囲を担当へ渡す。対象が大きい場合は関連するファイルをまとめてバッチに分け、対象全体の一覧を維持する。カテゴリ数やバッチ数を起動するエージェント数に置き換えない。
-
-## Step 3. Opus 1体で照合する
-
-委託が許可されている場合、`shinaps-refine-agent` (Opus / medium) 1体だけを起動する。担当IDは1とし、以下の資料・手順・JSON形式を渡す。他工程の今回の結果を読ませず、全規約と対象を照合させる。完了まで対象を編集しない。
-
-分割が必要なら同じ担当を再開して次のバッチを渡す。再開できなければ確認済み・未確認範囲を後任へ引き継ぐ。委託不可ならメインが同じ照合を行い、独立確認とは報告しない。
-
-### 各 agent への prompt
-
-- 担当ID (`1`) と、取得済みの rule の全文。取得した応答の単位でバッチに分けて渡し、読み終えた rule の id を報告させる
-- 関連する AGENTS.md / CLAUDE.md / docs の該当節
-- repo root の絶対パス、対象ファイル一覧、バッチID、対象全体のうち今回確認する範囲
-- Step 0 で確定した変更範囲の確認コマンド。path指定で変更を伴わない場合は、範囲判定不要・全 finding を `pre-existing` と明記する
-- 「読み取り専用で照合し、他工程の結果は読まない。対象やルールを編集しない。未確認範囲を明記する」
-
-### 各 agent が踏む手順 (prompt 内に明記する)
-
-1. 渡された全ファイルについて適用される規約を確認する。照合できない場合や規約が非該当の場合は理由を記録する
-2. 選んだファイルを利用可能な読み取りツールで **現状全文** 取得する (diff の hunk ではなく、いま repo にある状態そのもの)
-3. 「変更範囲の確認コマンド」を `<path>` に差し替えて実行し、そのファイルの **どの行が今回の変更に含まれるか** を把握する
-4. ファイル全体を渡された規約と突き合わせ、findings を分類する。**変更行の周辺だけに絞らない** — ファイル全体として規約に反していないかを見る
-5. 各 finding が手順 3 で把握した変更行に該当するかで `scope` を決める (`changed` / `pre-existing`)
-
-**finding 分類基準** (subagent 側の system prompt でも解釈済み):
-
-- **Violation**: 現状のコードが rule に既に反している
-- **Improvement**: 違反ではないが規約の趣旨に沿った改善余地がある
-- **Question**: 規約が曖昧 or 規約に載っていない判断
-
-各 finding には **根拠** を必ず添える (rule id + title / docs 引用)。根拠なしは report しない。
-
-### Agent の返却フォーマット (JSON 構造で返させる)
-
-各 agent には以下の JSON を返すよう prompt 末尾で指示する:
-
-```json
-{
-  "reviewer_id": "1",
-  "batch_id": "<割り当てられたバッチID>",
-  "reviewed_files": ["<全文の照合を完了したファイル>"],
-  "skipped_files": [{ "file": "<未照合の担当ファイル>", "reason": "<規約非該当・読み取り失敗・未完了などの理由>" }],
-  "findings": [
-    {
-      "severity": "violation" | "improvement" | "question",
-      "scope": "changed" | "pre-existing",
-      "file": "<repo root からの相対 path>",
-      "line": <該当行番号 or null。現状ファイル内の行番号>,
-      "summary": "<1 文で何が問題か>",
-      "detail": "<どう直すべきかの提案 (1-3 文)>",
-      "rule_id": "<引用した rule の id (docs だけを根拠にした場合は null)>",
-      "rule_title": "<引用した rule / docs 節のタイトル>",
-      "evidence": "<引用元 rule / docs の該当文 (最大 200 字)>"
-    }
-  ],
-  "notes": "<担当範囲で気になったが finding には昇格しなかった観察 (optional)>"
-}
-```
-
-**Info レベルは含めない** (Critical / Warning 相当だけを扱う)。findings が 0 件でも空配列で返す。
-
-## Step 4. findings を集約する
-
-全 agent の返却を受け取ったら、メインスレッドで以下を実施:
-
-- **対象の照合状況**: 担当ID × バッチと `reviewed_files` / `skipped_files` を照合し、担当が対象全体を確認したことを確かめる。報告から抜けた範囲や未完了分は同じ担当へ戻す。読み切れない場合はバッチを小さくし、指摘が空という理由だけで完了扱いにしない。非該当のファイルは理由を記録し、バッチをまたぐ契約も確認する。
-
-- **重複マージ**: 同じ file + line で意味が重なる finding は 1 件に統合し、根拠を両方併記する (バッチ間で同じ問題が報告される場合がある)
-- **scope 整合**: 同じ箇所の `scope` がバッチ間で異なる場合は実際の変更範囲を確認して判断し、不明なら `pre-existing` とする
-- **優先度整列**: Violation → Improvement → Question の順に並べ、Violation 内は影響範囲が大きいものから
-- **注意**: Info レベルは元々含まれない前提だが、agent 出力に混じっていたら破棄する
-- **lint 由来の指摘**: 根拠は規約 id とルール ID。メインが該当位置を読んで違反か確かめてから他の finding と同じ基準で扱う。誤報告と判断したものは理由を記録して除く
-
-集約結果の総数と内訳を 1 行で報告してから Step 5 に進む (`changed` / `pre-existing` の件数も併記する)。
-
-## Step 5. 自動修正と要確認に振り分ける
-
-集約後の finding を振り分ける。**`scope` が第一の分岐**:
-
-- **`changed`** (今回の変更に含まれる箇所) → 以下の「自明な修正」なら自動適用、それ以外は要確認
-- **`pre-existing`** (今回変更していない既存箇所) → severity を問わず **必ず要確認に回す**。自動修正しない
-
-`pre-existing` を自動修正しないのは、今回の作業と無関係な差分が commit に混入して、レビュアーが「この変更は何のためか」を追えなくなるため。既存箇所の指摘は「別 commit に分ける」「後回しにする」判断がユーザー側にある。
-
-### 自明な修正 (auto-apply、`changed` のみ)
-
-lint 由来の指摘は auto-apply にしない (ルールは構文で判定するので、意図した例外も報告しうる)。修正方法が一意で設計判断を伴わない finding は、ユーザーに確認せず `Edit` / `Write` で即修正する:
-
-- コメント / 文言 / typo の修正 (規約が指す直し方が一つしかない)
-- 既存パターンへの機械的な追従 (隣接コードと同じ流儀に揃えるだけ)
-- import 経路や命名の規約違反で、直し先が明白なもの
-
-自動修正を終えたら型 / lint / test を回して、すべて成功することを確認する。修正内容は Step 6 のサマリで「何をどう直したか」を file 単位で必ず一覧報告する (ユーザーが事後確認できるように)。
-
-### 判断が必要なもの (要確認)
-
-以下に該当する finding は `AskUserQuestion` で確認する。**迷ったら要確認にする**:
-
-- **`scope` が `pre-existing` のもの全般** (今回の変更と切り離して判断すべきなので、自明に見えても確認する)
-- 設計トレードオフがある (複数の修正方針があり得る / 影響範囲が広い / 構造変更を伴う)
-- 規約側が現実と乖離している可能性がある (finding の severity=question 全般)
-- 修正コストが大きく「後回し」が現実的な選択肢になるもの
-
-選択肢は 4 つ:
-
-1. **修正する** — どう直すかを 1-2 文で提案 (agent が返した `detail` を活用)。承認されたら `Edit` / `Write` で実行
-2. **このまま許容する** — 妥当な理由があるとき。理由を今回のローカル成果物（implementation.md / 調査・レビューレポート）に残す (後から「なぜ違反のままにしたか」を辿れるように)
-3. **ルールの方を修正する** — 規約自体が現実と乖離している場合。[Shinaps規約の書き方](../../references/rule-writing.md) に従って書き込む全文を作る。新規のときは scope (user / repo_owner / repo) も選ばせる (横断的なら user、この repo 限定なら repo。repo は [Shinaps規約の取得](../../references/rules.md) の「リポジトリを特定する」で得た `repoId` を添える)。同じ文書の「書き込む前に既存の規約と比べる」で比べ (Step 1 の結果はファイルの技術で絞っているので使わない)、結果と全文の差分を示して同意を受けてから shinaps-ai MCP server の `record_rule` (新規) or `update_rule` (既存修正) を実行
-4. **後回し** — 別タスクとして扱う。`TaskCreate` で TODO 化し、後の作業セッションで着手できるようにする
-
-**提示順は `changed` を先、`pre-existing` を後**。それぞれの中では Violation → Improvement → Question の順。各 finding には `pre-existing` かどうかを明示して提示する (ユーザーが「今回の commit に混ぜるか」を判断する材料になるため)。件数が少なければ 1 回の `AskUserQuestion` に複数 question をまとめてよい (各 finding には前提説明を添える)。
-
-## Step 6. 完了サマリ
-
-処理が一巡したら、最後にユーザーへ箇条書きでサマリ報告する。
-
-- 対象ファイル数と、その決め方 (`git diff HEAD` の変更ファイル / PR / commit range / path 指定のどれか) を冒頭に明示
-- [Shinaps規約の取得](../../references/rules.md) の「照合結果に書くこと」
-- 機械検査を使った場合は、状態ごとの組の数 (照合から外した `covered`・`violation` を含む)、`not-run` の理由。使えなかった場合はその理由
-- 実際の担当数・バッチ数と各担当の finding 件数、照合済みファイル数、非該当・未完了のファイルと理由
-- 検出 / 処理した finding の総数と内訳 (自動修正 X 件 / 確認の上修正 Y 件 / 許容 Z 件 / rule 更新 W 件 / 後回し V 件)
-- **`changed` と `pre-existing` の内訳** (既存箇所の指摘が何件あり、そのうち何件を今回直したか。今回の変更に無関係な修正がどれだけ混ざったかをユーザーが把握できるように)
-- **自動修正した内容の一覧** (file + 1 行の何をどう直したか。ユーザーが事後確認する唯一の接点なので省略しない)
-- 新しく `record_rule` / `update_rule` した内容があれば「次セッション以降に適用されます」と明示
-- まだ未処理の Question / 後回しの TaskCreate id を列挙
-
-この後 user は通常 `git add` / commit に進む想定なので、refine 自体は commit しない (commit はユーザーが行う操作として残す)。
-
-## 注意点
-
-- テストに関わる指摘と修正の判断は [テスト方針](../../references/testing.md) に従う
-- **Info レベルは report しない**。Critical / Warning 相当だけを扱う。ノイズが多いと「規約照合は手間」という否定的な印象が定着するため
-- **1体で対象全体を確認する**。対象量が増えても担当数を増やさず、同じ担当へ続きのバッチを渡す
-- **Agent への rule 受け渡しは full text**。id + title だけを渡して agent 側に再取得させると shinaps MCP を N 回呼ぶことになるため無駄。メインスレッドが 1 度取得したものを prompt に貼る
-- **根拠を確認する**: 担当は渡された規約と対象全体を照合し、規約や docs の根拠がある指摘だけを返す
-- finding 同士が重複していたら Step 4 の集約で統合する (「同じファイルで console.log 3 件、まとめて削除しますか?」等)
-- 照合する規約が無いときは Step 2-4 を省き、公式ルールの未照合を報告する。`filterUserRulesByLabels` なしの一覧で userRules が 0 件と確認できたときに限り、個人ルールが未登録であることも伝え、[Shinaps規約の書き方](../../references/rule-writing.md) に従う `record_rule` を希望するか質問する

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

@@ -1,37 +0,0 @@
----
-name: simplify
-description: 計画の簡素化は2担当、実装の簡素化は1担当（いずれも Opus / medium）で検討する。提案を統合し、依頼範囲内で適用・検証する。実装後や複雑さの見直しに使う。
----
-
-## 作業記録の保存先
-
-作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
-
-# 目的から見直して減らす
-
-## プロジェクトの条件を読む
-
-適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
-
-既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
-
-## 担当とモード
-
-- **「計画の簡素化」**: `shinaps-simplifier` (Opus / medium) 2体（担当1・2）を、設計・プランレビューとは別の担当として並行起動する。「計画の簡素化」と指定し、同じ要件・目的・受入条件・最新計画・規約・調査結果を両者へ渡す。コードの一般レビューは依頼しない。
-- **それ以外（実装の簡素化）**: `shinaps-simplifier` (Opus / medium) 1体。「実装の簡素化」と指定し、目的・外部契約・対象コード・最新計画・規約を渡す。
-
-全担当は読み取り専用で、他担当の今回の結果を読まない。完了まで計画・対象コードを変更しない。バッチ継続や修正計画の再確認は同じ担当を再開し、再開不能なら同じ役割へ確認済み・未確認範囲を引き継ぐ。
-
-全結果と確認範囲を待つ。失敗・未完了を指摘なしと扱わない。委託不可なら制約と独立確認未実施を報告する。「提案のみ」または「計画の簡素化」では、全提案・根拠・仕様変更の有無・未確認事項を返して終了する。
-
-単独の実装簡素化で適用も依頼されている場合だけ、以下へ進む。
-
-## 判断と実行
-
-- 目的、守る外部契約、現在の実装方法を区別する。今の構造を要件として正当化しない。
-- 根拠の弱い前提、不要な分岐・互換層・重複、丸ごと消せる手順を実物から探す。削除 → 簡素化 → 最適化 → 自動化の順で考え、必要な段階だけ実施する。
-- 利用箇所と契約を調べ、依頼範囲内で挙動を保つ削除を適用する。行数だけを減らして責務を混ぜない。仕様を変えることで簡単になる場合は、変わる挙動と推奨案を示して先に確認する。
-- 変更の影響に合う検証を行う。問題がなければ変更を作らず終了する。
-- 削ったもの、判断理由、確認結果を短く報告する。コミットや公開はこの工程の許可に含めない。
-
-- テストの判断は [テスト方針](../../references/testing.md) に従う。

package/plugins/shinaps-codex/agents/shinaps-refine-agent.toml

@@ -1,4 +0,0 @@
-name = "shinaps-refine-agent"
-description = "shinaps:refine で起動される rule 照合エージェント。渡された rule 全件と対象ファイルの現状全文を突き合わせて Violation / Improvement / Question に分類し、今回の変更箇所か既存箇所かを scope で切り分ける。subagent 内で shinaps MCP を直接呼ばない (重複呼出しと短時間の操作上限の消費を避けるため)"
-sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:refine` で起動される **rule 照合エージェント** です。\nSkill 側から渡された「rule 全件」と「対象ファイルの現状全文」を **1 件ずつ突き合わせて** 分類し、JSON で返してください。\n\n## 絶対原則 (MCP の呼出しはメインだけ)\n\n**subagent 内で shinaps MCP tool を直接呼ばない**。rule 全文・docs 該当節・repo root・対象ファイル一覧はすべて Skill 側から prompt 経由で渡される。あなたはそれを材料に使うだけ。subagent が同じ検索を繰り返すと、利用者ごとに共有される短時間の操作の上限を消費し、同じ結果を重ねて取得することになるため。\n\n## 対象の取得\n\n照合するのは **diff の hunk ではなくファイルの現状全文**。hunk だけでは「この関数全体の責務が正しいか」「命名が周囲と揃っているか」を判断できず、追加行だけ規約準拠に見えてファイル全体では外れているケースを見落とすため。\n\n1. 渡された全ファイルについて適用される規約を確認する。非該当・読み取り失敗・未完了は理由を明記する\n2. 選んだファイルを `ファイル読み取り` で **現状全文** 取得する\n3. prompt に埋め込まれた「変更範囲の確認コマンド」(`git diff HEAD -- <path>` / `git diff <range> -- <path>` / `gh pr diff <n> --repo owner/repo -- <path>` のいずれか) を実行し、そのファイルのどの行が今回の変更に含まれるかを把握する\n4. **ファイル全体** を rule と突き合わせて finding を分類する (変更行の周辺だけに絞らない)\n5. 各 finding の `scope` を決める\n\n「変更範囲の判定は不要」と指示された場合 (path 指定で変更を伴わない対象) は手順 3 を省き、全 finding を `pre-existing` として返す。\n\n## Finding severity の解釈\n\n- **Violation**: 現状のコードが rule に **既に違反している**\n- **Improvement**: 違反ではないが改善余地がある\n- **Question**: rule が曖昧で判断保留\n\n## Finding scope の判定\n\n- **`changed`**: finding の該当箇所が今回の変更行に掛かっている (1 行でも掛かっていれば `changed`)\n- **`pre-existing`**: 今回の変更と無関係な、元からある箇所\n\nこの切り分けは Skill 側が「自動修正してよいか」を決めるのに使う。`pre-existing` を `changed` と誤って返すと、今回の作業と無関係な差分が commit に混入するので **迷ったら `pre-existing` にする**。\n\n## 返却フォーマット (JSON 固定)\n\n```json\n{\n  \"reviewer_id\": \"<割り当てられた担当ID>\",\n  \"batch_id\": \"<割り当てられたバッチID>\",\n  \"reviewed_files\": [\"<全文の照合を完了したファイル>\"],\n  \"skipped_files\": [{ \"file\": \"<未照合の担当ファイル>\", \"reason\": \"<規約非該当・読み取り失敗・未完了などの理由>\" }],\n  \"findings\": [\n    {\n      \"severity\": \"violation\" | \"improvement\" | \"question\",\n      \"scope\": \"changed\" | \"pre-existing\",\n      \"file\": \"<該当ソースファイルの repo root からの相対 path>\",\n      \"line\": <該当行番号 or null。現状ファイル内の行番号>,\n      \"summary\": \"<1 文で何が問題か>\",\n      \"detail\": \"<どう直すべきかの提案 (1-3 文)>\",\n      \"rule_id\": \"<引用した rule の id (docs だけを根拠にした場合は null)>\",\n      \"rule_title\": \"<引用した rule / docs 節のタイトル>\",\n      \"evidence\": \"<引用元 rule / docs の該当文 (最大 200 字)>\"\n    }\n  ],\n  \"notes\": \"<担当範囲で気になったが finding には昇格しなかった観察 (optional)>\"\n}\n```\n\n- **Info レベルは含めない** (Critical/Warning 相当のみ)\n- findings 0 件でも空配列で返す\n- 担当ファイルを `reviewed_files` または理由付きの `skipped_files` に漏れなく含める。全文を照合し終えていないファイルは未完了として返し、メインが残りを再割り当てできるようにする。ファイル数による一律の打ち切りはしない\n\n## 動作原則\n\n- **独立した読み取り専用の照合**: 他担当の今回の結果を読まず、意見を交換しない。コード・ルール・進行管理ファイルを編集しない\n- **根拠なしの finding を報告しない**: rule 引用または docs 引用が付けられないものは出さない\n- **ファイル全体を見る**: 変更行の周辺だけを見て済ませない。ファイル全体が rule に沿っているかを判断する\n- **scope は迷ったら `pre-existing`**: 誤って `changed` にすると無関係な差分が commit に混入する\n- **subagent 内で shinaps MCP を直接呼ばない**: 絶対原則を守る\n\n## テスト方針\n\nテスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。検証の入力（対象の内容）・環境と条件・コマンドと範囲・成功の証拠を、証拠の粒度に合う版の識別（ファイル・blob・treeのハッシュ等）で照合できる場合は、担当・工程・commit SHAが変わっただけで再実行しない。入力や条件が変わった、証拠が不足・失敗・未確認、またはプロジェクトが段階ごとの実行を求める場合は、必要な範囲を実行して理由を残す。照合できない結果を合格にせず、独立QAや新しい環境での公開確認はこの再利用で省かない。"

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

@@ -1,4 +0,0 @@
-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 経由で渡された取得済みの規約全文**\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/skills/extract-rules/SKILL.md

@@ -1,16 +0,0 @@
----
-name: extract-rules
-description: GitHubの過去PRレビューから繰り返し適用できる規約を抽出し、Shinaps AIへ登録する。ルール抽出・登録を依頼された場合に使う。
----
-
-# PRレビューからルールを抽出する
-
-対象リポジトリと期間、Shinaps AIへの登録範囲を依頼・Git設定から確定する。不足は一問ずつ確認する。新しいリポジトリだからという理由だけで登録を開始しない。MCP接続と認証が必要であり、使えない場合はアカウント作成・認証を案内し、保存したと報告しない。
-
-1. `gh`で期間内のマージ済みPRを取得する。ページングし、並び順と日付フィルターの関係を守る。更新日時順の一覧で古いマージ日時を一件見つけても、それ以降の取得を打ち切らない。
-2. PRのreview本文・inline comment・conversation commentを取得する。PR descriptionはレビュー指摘として扱わない。APIのBot種別は除外し、判断が必要な投稿者は確認する。認証情報やリポジトリ全体をサービスへ送信しない。
-3. 複数のレビューで繰り返され、適用条件とWHYが説明できる規約を候補にする。根拠のない例・URLを作らない。出典URLの一覧は保存しない（本文にも移さない）。
-4. 候補を[Shinaps規約の書き方](../../references/rule-writing.md)に従って書き、同じ文書の「書き込む前に既存の規約と比べる」で候補ごとに結果を決める。提示の候補はまとまりの終わりに示し、残りの投入は止めない。新規の候補だけを対象repoのスコープへ、実際のMCPツールのスキーマに従って登録する。対象repoは[Shinaps規約の取得](../../references/rules.md)の「リポジトリを特定する」でrepositoryの`id`を得て指定し、得られなければrepoのスコープでは登録せず利用者に確認する。応答は入力の位置とidだけなので、重複して投入されなかった候補は入力からtitleを得て、上書きせず提示へ進める。全プロジェクト共通へ広げる場合は利用者の判断を確認し、書き直した全文で比べ直す。既存の規約への更新の候補は差分を提示して許可を得る。`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

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

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

@@ -1,26 +0,0 @@
----
-name: simplify
-description: 実装・設計・手順を目的と必要条件から見直し、不要な要素を削除して簡素化する。実装後のセルフレビュー前や、複雑さの見直しを求められたときに使う。
----
-
-## 作業記録の保存先
-
-作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
-
-# 目的から見直して減らす
-
-## プロジェクトの条件を読む
-
-適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
-
-既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
-
-## 判断と実行
-
-- 目的、守る外部契約、現在の実装方法を区別する。今の構造を要件として正当化しない。
-- 根拠の弱い前提、不要な分岐・互換層・重複、丸ごと消せる手順を実物から探す。削除 → 簡素化 → 最適化 → 自動化の順で考え、必要な段階だけ実施する。
-- 利用箇所と契約を調べ、依頼範囲内で挙動を保つ削除を適用する。行数だけを減らして責務を混ぜない。仕様を変えることで簡単になる場合は、変わる挙動と推奨案を示して先に確認する。
-- 変更の影響に合う検証を行う。問題がなければ変更を作らず終了する。
-- 削ったもの、判断理由、確認結果を短く報告する。コミットや公開はこの工程の許可に含めない。
-
-- テストの判断は [テスト方針](../../references/testing.md) に従う。