@shinaps/skills 0.48.0 → 0.49.0

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

@@ -1,27 +1,28 @@
 ---
 name: review
-description: 差分・PR・指定コードを根拠付きでレビューする。Shinapsのレビュー担当を利用できる場合は一次レビューと指摘の検証を分ける。
+description: 差分・PR・コミット範囲・既存コードをレビューする。LITE・BASIC・ULTRAの体制を開発時の体制と関係なく選べ、規約照合・可読性・慣習・実装の簡素化も同じ入口で扱う。「レビューして」「規約に合っているか確かめて」「簡素化できるか見て」と依頼されたとき、追加修正の後に確かめたいときに使う。指摘の検証と報告までを行い、修正は明示の依頼があるときだけClaude Codeの開発担当へ引き継ぐ。
 ---
 
 ## 質問の実行経路（全工程に優先）
 
 対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
 
-
 # レビュー
 
-対象プロジェクトのAGENTS.md、既存設計、依頼範囲を確認する。作業ツリーをレビューする場合はステージ済み・未ステージ・未追跡の関連変更を含める。PRやブランチを指定された場合はその比較範囲を使う。
+対象プロジェクトのAGENTS.md、既存設計、依頼範囲を確認する。[単独レビューの手順](../../references/review-standalone.md)と[レビューの共通契約](../../references/review.md)を先に読み、その順に進める。ここには Codex 固有の部分だけを書く。
 
-Shinaps AIのルール検索が利用できる場合は[Shinaps規約の取得](../../references/rules.md)に従って、対象ファイルについて規約全文を取得し、指摘の根拠に含める。同じ手順の「照合結果に書くこと」を報告する。利用できない場合はルール照合が未確認であることを報告する。コード自体のレビューは続けられる。
+## 担当の起動
 
-委託でき、shinaps-reviewerが登録されている場合は、対象・差分・背景・取得済みルールを渡してレビューを依頼する。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。利用できない場合は現在のセッションで同じ観点を確認し、独立レビューとは報告しない。worktreeは依頼の範囲で必要な場合だけ作る（[依頼範囲と操作](../../references/request-scope.md)）。
+契約の構成で登録済みのshinaps-reviewerを起動する。起動・継続は[担当の起動](../../references/dev/launch.md)に従い、委託の数や範囲をユーザーが制限した場合はそれに従う。委託できなければ担当を未完了とし、現在のセッションで同じ観点を確認した結果を独立レビューとは報告しない。
 
-指摘の独立検証が依頼の範囲に含まれる場合は、登録済みのshinaps-review-validatorへ元の対象と一次指摘を渡す。外部APIの仕様が判断を左右する場合はshinaps-tech-surveyorで調査し、具体的な推奨の出典をshinaps-survey-validatorで確認できる。委託の数や範囲をユーザーが制限した場合はそれに従う。
+外部のAPI・ライブラリ・版の仕様が判断を左右するとき、または外部調査を依頼されたときは、shinaps-tech-surveyorに調査を依頼し、具体的な推奨を採る前にshinaps-survey-validatorで出典を確かめる。
 
-返された指摘を実コードと照合してから、挙動への影響や根拠のある保守上の負担を優先度順に報告する。対象箇所、発生条件、影響、最小の修正案を含める。推測と確認済みの事実、実施した検証と未実施を区別する。指摘を埋めるための好みの変更は加えない。
+## 修正の引き継ぎ
 
-可読性は、対象言語の基礎を知るジュニアが初めて読んでも目的・流れ・判断理由を追えるかで判断する。推測する意味、同時に覚える状態、理解のための往復を減らし、短さや分割数、特定構文を目標にしない。正しさ・型の保証・既存の性能とプロジェクト規約を維持する。指摘には読み手の具体的な負担と軽減する修正案を示し、ほぼ同等の表現や好みだけの差は修正要求にしない。性能への影響が不明なら必要な検証を示す。委託する場合もこの判断軸を渡す。テストに関わる指摘は [テスト方針](../../references/testing.md) に従う。
+Codexに実装の入口はなく、修正はClaude Codeが行う。手順の「到達点」で修正へ進むときは、Codexがファイルを編集せず、次の経路でClaudeへ渡して進める。
 
-修正・コミット・PR投稿はユーザーに依頼された範囲だけ行う。記録が必要ならプロジェクトの.shinaps/work/に保存し、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。
+- Linear進行では `$shinaps:linear-execute` の確定した経路で、採用した指摘と `findings.md` を渡す。
+- Linear進行でなければ、[Claude CLI](../../references/linear/claude-cli.md)の「起動と観測」「操作権限」のとおり作業先でローカルの `claude -p` を起動する。promptには `shinaps:dev-claude`、指摘（`findings.md` のパスと本文）、固定した版、体制（選んでいれば）、exact cwd・branch・HEAD・既存差分、必須検証、依頼範囲と制約（今回の範囲限定を含む）、「修正と再レビューをして未コミットの差分を返す」という到達点、依頼にない commit・push・公開をしないことを書く。同じ文書のとおり、質問への回答と追加の修正は同じsessionのresumeで行う。
+- 終了後はresultと実際の差分・再レビューの結果を確かめて報告する。CLIが無い、または必要な指定を使えないときは、その状態と渡す内容を報告して止まる。
 
 Linear進行への成果引き渡しでは、確定済みの経路を維持する。autoは同じ[Claude CLI](../../references/linear/claude-cli.md)のsessionのresultへ返す。manualは同じ対話セッションで続け、[Bridge](../../references/linear/bridge.md)で依頼元のCodexへ報告する。調査スキルから経路を切り替えない。

package/plugins/shinaps-claude/agents/shinaps-refine-agent.md

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

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

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

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

@@ -1,36 +0,0 @@
----
-name: shinaps-simplifier
-description: shinaps:simplify で、計画または実装から目的と外部契約を保てる削除・統合を読み取り専用で提案する。適用判断は呼び出し元へ返す
-model: opus
-effort: medium
-color: cyan
----
-
-あなたは簡素化の提案を担当します。呼び出し元が「計画の簡素化」または「実装の簡素化」のどちらかを指定します。指定されたモードの節だけに従い、もう一方の手順は使いません。
-
-## 計画の簡素化
-
-目的・受入条件・制約、最新計画、関連する既存実装と調査、規約、承認済み変更を読み、作るものや維持するものを減らす提案に専念する。一般的なプランレビューや実装コードレビューを兼務しない。他担当の今回の案やレポートを読まず、編集・追加委託・shinaps MCPの直接呼び出しは行わない。
-
-- 目的と現在選ばれた仕様を区別し、不要な機能・例外対応・状態・選択肢・操作手順・互換性・実装構造を減らせないか検討する。既存挙動の維持を無条件の前提としないが、契約を黙って変えない。
-- 各提案に計画の該当節、減らすもの、根拠、変わるユーザー体験、失う機能、残す目的・契約、実装・テスト・運用の負担がどう減るか、仕様や受入条件の変更の有無を記す。数値効果は根拠なしに断言しない。
-- 仕様を維持する簡素化と仕様変更が必要な案を区別する。未実装コードがないことを不具合にせず、必要なら関連する既存コードを読む。
-- 修正計画では前回の採否とユーザー判断を踏まえる。新しい根拠なしに却下案を繰り返さない。提案がなければ指摘なしと確認範囲を返す。
-
-提案とその根拠、確認済み・未確認の範囲を返す。採否の決定、計画やコードの書き換え、ユーザーへの直接確認は行わない。
-
-## 実装の簡素化
-
-渡された目的・受入条件・計画・規約と、対象の現在のコードや利用箇所を確認してください。
-
-- 目的と必要な外部契約を保ちながら削除・統合できる処理、重複、不要な分岐・互換層・抽象化を探す。行数だけを減らして責務を混ぜない。
-- 変更の効果と、挙動を保てる根拠を file:line と利用箇所で示す。仕様を変える提案は通常の簡素化と区別する。提案を埋めるために変更を増やさない。
-- 同じ対象を確認する他の担当の結果を読まず、意見を交換しない。コード・設定・ルール・進行管理ファイルを編集しない。
-- 対象全体を確認し、未確認のファイルと理由を明記する。分割して渡された場合は、続きと関連箇所の整合性も確認する。
-- 各提案について対象、削除・統合の内容、理由、維持する契約、必要な検証、仕様判断の要否を返す。提案がなければその旨を返す。
-- shinaps MCP は直接呼ばない。規約は呼び出し元から受け取ったものを使い、未提供のルールとの照合済みとは報告しない。
-- 追加委託、worktree作成、コミット・公開は行わない。変更の適用と検証は呼び出し元が担当する。
-
-## テスト方針
-
-テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。検証の入力（対象の内容）・環境と条件・コマンドと範囲・成功の証拠を、証拠の粒度に合う版の識別（ファイル・blob・treeのハッシュ等）で照合できる場合は、担当・工程・commit SHAが変わっただけで再実行しない。入力や条件が変わった、証拠が不足・失敗・未確認、またはプロジェクトが段階ごとの実行を求める場合は、必要な範囲を実行して理由を残す。照合できない結果を合格にせず、独立QAや新しい環境での公開確認はこの再利用で省かない。

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

@@ -1,118 +0,0 @@
----
-name: extract-rules
-description: 過去 PR のレビューコメントから shinaps-ai の rules を bulk 生成する skill。新規リポジトリ着手時、または search_rules の userRules が空 / 少ない (5 件未満) ときに提案・起動。owner / repo / since を確認し、bot 除外 + gh api pulls で 100 PR ブロック単位に fetch → LLM で規約抽出 → record_rules で投入 → 続行確認 → 完了 report まで実行する。shinaps-ai server 未登録時は search_rules 呼び出しが自動で失敗して abort する。
-argument-hint: (引数なし、対話で owner-repo / since を確認)
----
-
-## 作業記録の保存先
-
-作業記録は現在の作業先の `.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:extract-rules — 過去 PR review から rules を bulk 生成
-
-新規リポジトリ着手時、または既存 userRules が少ないときに、過去 PR のレビューコメントから規約を bulk import する skill。shinaps-ai サーバは GitHub API も LLM も呼ばず、すべて Claude Code 側のあなた (= AI) が `gh` / 既存 MCP tools 経由で実行する (token / repo 内容をサーバ境界に置かない)。
-
-## Step 0. 対象 repo を環境から決定する (MUST)
-
-引数は受け取らない。以下の順で対象 `<owner>/<repo>` を解決:
-
-1. `gh repo view --json owner,name` を実行 → `owner.login` と `name` を組み合わせる
-2. 失敗したら `git remote get-url origin` を parse (`github.com/<owner>/<repo>(.git)?` 形式)
-3. それでも決まらないなら **ユーザーにチャットで確認** (「対象は `<owner>/<repo>` でいいですか?」)
-
-解決した `<owner>/<repo>` をユーザーに **必ず提示** し、誤りなら別の repo を入力してもらう。確定した repo を [Shinaps規約の取得](../../references/rules.md) の「リポジトリを特定する」で特定し、`repoId` と現在の `repoOwner`・`repoName` を得る。`repoId` が得られなければ `scope: repo` では投入できないので、ここで止めて利用者に確認する。
-
-## Step 1. since (期間) をチャットで確認
-
-デフォルトは **直近 6 ヶ月**。「直近 6 ヶ月の merged PR を対象にしますか? それとも別の期間 (例: 3 ヶ月 / 1 年 / 特定日付以降) を指定しますか?」とユーザーに聞く。回答に応じて以下のように扱う:
-
-- 「6 ヶ月で OK」「お任せ」 → 直近 6 ヶ月 (= 現在日から 6 ヶ月遡る)
-- ISO 8601 (例: `2026-01-01`) → そのまま使用
-- 相対 (例: `3 months ago`) → 現在日から相対計算
-
-## Step 2. ignore_logins (除外する commenter) のポリシー
-
-- GitHub API が返す `user.type === "Bot"` のコメントは **自動で除外**
-- それ以外の Bot 疑い User (CodeRabbit / SonarCloud / login に "bot" / "ai" / "review" を含むアカウント) は、PR を眺める中で発見次第ユーザーに **「これも Bot 扱いしますか?」** と確認 → 確定したら以降の処理で除外
-
-## Step 3. merged PR の fetch
-
-`gh api 'repos/<owner>/<repo>/pulls?state=closed&sort=updated&direction=desc&per_page=100'` で closed PR を最新順に取得する。`merged_at IS NOT NULL` でフィルタして **merged 済の PR だけ** に絞り込む (closed-without-merge は対象外)。`Link` ヘッダの `rel="next"` を follow して pagination する。`merged_at` が Step 1 で確定した since を下回った時点で fetch 停止。
-
-## Step 4. コメント収集
-
-各 PR について、以下の 3 source を **すべて** 取得して flatten する:
-
-- `gh api 'repos/<owner>/<repo>/pulls/{n}/reviews'` — PR Review 本文
-- `gh api 'repos/<owner>/<repo>/pulls/{n}/comments'` — Files Changed タブの inline review comment
-- `gh api 'repos/<owner>/<repo>/issues/{n}/comments'` — PR 本文下の Conversation スレッド一般コメント
-
-PR description (本文) は対象外。あくまで「レビュー観点」を抽出するため。
-
-## Step 5. Bot 除外
-
-`user.type === "Bot"` のコメントは自動で除外。Step 2 で確定済の suspicious User もここで除外。新規の Bot 疑い login が出てきたら Step 2 のルールで都度ユーザー確認。
-
-## Step 6. 既存 rules 把握
-
-100 PR を 1 ブロックとして処理する。ブロックの開始時に必ず [Shinaps規約の取得](../../references/rules.md) の「書き込む前に取得する」に従って一覧を最後のページまで取得する (userRules は継承マージで scope=user / repo_owner / repo の全件)。全文は Step 7 で候補ごとに確かめる。
-
-## Step 7. rules 生成と投入
-
-各 PR ブロックから rules 候補を抽出する基準:
-
-- 複数 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 の大きさは [Shinaps規約の書き方](../../references/rule-writing.md) の目安に従う。language は shiki の言語 id 小文字 (`typescript` / `tsx` / `python` / `go` 等)
-- good / bad / language は 3 つセットでしか登録できない (揃っていないと入力の schema 検証で拒否される)
-
-出典 URL の一覧は保存しない (本文にも移さない)。判断の根拠や適用範囲の理解に要る経緯・PR 番号は、[Shinaps規約の書き方](../../references/rule-writing.md) に従って本文に必要な分だけ残す。
-
-投入手順:
-
-- 候補を確定してから、[Shinaps規約の書き方](../../references/rule-writing.md) の「書き込む前に既存の規約と比べる」で候補ごとに結果を決める。既存の規約への**更新**は下の差分確認へ進める。**提示** はブロックの終わりにまとめて利用者へ示し、残りの投入は止めない。**新規**候補だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, repoId, rules: [{ title, why, recommend?, avoid?, kind?, labels?, examples? }, ...] })` で **1 call bulk 投入** する。上限は 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回だけ再試行する。再び拒否されたら、連続して再試行せずに中断し、その状況を利用者に報告する。
-- 戻り値は入力の `rules` の位置と id だけ (`inserted: { index, ruleId }[]`、`skipped: { index, existingRuleId }[]`)。`skipped` は「既存と title 重複して投入されなかった候補」で、title は入力の `rules[index]` から分かる。上書きせず**提示**へ進める。
-- 既存の規約への**更新**の候補について、**ユーザーに diff を提示して同意を取る**:
-
-> 既存 rule "no-unused-vars" が見つかりました。why/recommend/avoid/examples の差分:
-> ```
-> - 旧 why: ...
-> + 新 why: ...
-> ```
-> 上書きしますか? (yes / no / skip-all)
-
-- 同意なら `update_rule({ id: <既存 rule の id>, why?, recommend?, avoid?, examples? })` を実行。`skip-all` を選ばれたら以降の差分確認をスキップする
-
-## Step 8. 100 PR ブロック確認
-
-100 PR ブロックの処理が終わるたびに、ユーザーに **「次の 100 PR ブロックに進むか」を確認** する (LLM のコンテキスト窓保護と判断点の挿入)。「続ける」なら次ブロックの fetch + コメント収集 + 既存 rules 再取得 + 抽出 + 投入を繰り返す。「やめる」なら現時点までの結果でレポートに進む。
-
-## Step 9. 完了レポート
-
-since 期間内の merged PR を消化し終えたら、以下を user に報告:
-
-- 処理した PR 件数 / コメント件数
-- 自動 Bot 除外 + ユーザー確認で除外した login 一覧
-- `record_rules` で新規投入した rule 件数 (inserted 合計) + タイトル一覧
-- `update_rule` で更新した rule 件数 + タイトル一覧
-- `no` または skip-all で残した候補件数 (あれば)
-- 比較の結果が「書かない」「提示」だった候補の件数と、[Shinaps規約の書き方](../../references/rule-writing.md) の比較が求める報告
-- 保存上限 (`RULE_LIMIT_REACHED`)・回数制限 (`RATE_LIMITED`) によって投入できなかった候補の件数 (あれば)

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