@shinaps/skills 0.47.0 → 0.49.0

package/plugins/shinaps-codex/skills/linear-plan/SKILL.md

@@ -5,14 +5,14 @@ description: アイデアの相談・調査・仕様整理を行い、LinearのI
 
 # 相談を実行可能なIssueへまとめる
 
-相談の目的を確認し、既存の会話・仕様・Issue・コードから分かる内容は再質問しない。仕様が曖昧なら `shinaps:spec`、既存挙動や影響の調査なら `shinaps:explore` を使う。明確な小さな作業は直接整理し、毎回これらのスキルを必須にしない。委託やworktreeの作成は既存の許可に従う。
+相談の目的を確認し、既存の会話・仕様・Issue・コードから分かる内容は再質問しない。仕様が曖昧なら `shinaps:spec`、既存挙動や影響の調査なら `shinaps:explore` を使う。明確な小さな作業は直接整理し、毎回これらのスキルを必須にしない。委託やworktreeの作成は[依頼範囲と操作](../../references/request-scope.md)に従う。
 
 ## 整理と保存
 
-- [設定](../../references/linear/configuration.md)で作業先・Linearの対象・許可を確認する。設定がなくても相談・読み取り・整理案の提示と、利用者が明示的に依頼したIssue更新はできる。別プロジェクトの設定を借用しない。
+- [設定](../../references/linear/configuration.md)で作業先・Linearの対象・終了地点・制約を確認する。設定がなくても相談・読み取り・整理案の提示と、利用者が明示的に依頼したIssue更新はできる。別プロジェクトの設定を借用しない。
 - [Issueの整理と記録](../../references/linear/issue.md)に従い既存Issueを検索して再利用する。目的・範囲・受入条件・依存・未決事項を整理し、必要ならレビューできる到達点で分割する。要件の正本やspec/exploreの成果物へ参照を付ける。
 - spec/exploreから実装へ進む案内があっても、この入口では実装を始めない。調査中の確認や読み取りを、製品コードの変更に広げない。
-- Issueの作成・更新は、利用者の明示依頼または設定の `issue_update` が許可する範囲で行う。Claudeは利用者の明示依頼の範囲だけで更新する。チーム設定変更は別の合意が必要。
+- Issueの作成・更新は、利用者が依頼した整理の目的・対象の範囲で行い、設定があることだけを根拠にしない。Claudeは利用者の明示依頼の範囲だけで更新する。チーム設定変更は別の合意が必要。
 - 計画対象の調査自体をIssueで管理する規約がある場合も、同じ目的の既存Issueを使い、細かな手順ごとのIssueは増やさない。相談の結果、Issueを作らず保留・見送りにしてもよい。
 
 ## 設定の初期作成・変更
@@ -21,4 +21,4 @@ description: アイデアの相談・調査・仕様整理を行い、LinearのI
 
 ## 終了と引き渡し
 
-作成・更新したIssue、決定事項、未決事項と依存を示して終了する。相談だけなら結論を返す。開発用ゴールの設定、実装、コミット・公開には進まない。設定のために `linear-execute` から移った場合は、保存・確認後に元の依頼へ戻り、設定と既存の許可の範囲で再開する。それ以外では、利用者が続けて実行を明示的に依頼したときだけ `shinaps:linear-execute` へIssueと成果物を渡し、実行範囲を確定する。
+作成・更新したIssue、決定事項、未決事項と依存を示して終了する。相談だけなら結論を返す。開発用ゴールの設定、実装、コミット・公開には進まない。設定のために `linear-execute` から移った場合は、保存・確認後に元の依頼へ戻り、設定と元の依頼の範囲で再開する。それ以外では、利用者が続けて実行を明示的に依頼したときだけ `shinaps:linear-execute` へIssueと成果物を渡し、実行範囲を確定する。

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

@@ -1,6 +1,6 @@
 ---
 name: release
-description: プロジェクトの公開手順と完了条件に従ってリリースし、対象バージョンが利用可能なことを検証する。公開・配布・本番デプロイの依頼または合意済みの継続許可があるときに使う。
+description: プロジェクトの公開手順と完了条件に従ってリリースし、対象バージョンが利用可能なことを検証する。公開・配布・本番デプロイを依頼されたとき、またはLinear進行の実効到達点に含まれるときに使う。
 ---
 
 ## 作業記録の保存先
@@ -15,7 +15,7 @@ description: プロジェクトの公開手順と完了条件に従ってリリ
 
 既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
 
-Linearの開発進行から受けた依頼では、[共通設定](../../references/linear/configuration.md)の合意済みの許可と[担当・工程](../../references/linear/workflow.md)を引き継ぐ。操作後は進行役へ結果を返し、[終了条件](../../references/linear/execution.md)に従って次工程を判断する。単独の依頼にはLinear進行や新しいゴールを必須にしない。
+操作の判断は[依頼範囲と操作](../../references/request-scope.md)に従う。Linearの開発進行から受けた依頼では、実効到達点・`constraints` と[担当・工程](../../references/linear/workflow.md)を引き継ぐ。操作後は進行役へ結果を返し、[終了条件](../../references/linear/execution.md)に従って次工程を判断する。単独の依頼にはLinear進行や新しいゴールを必須にしない。
 
 ## 公開前に条件を確定する
 
@@ -23,7 +23,7 @@ Linearの開発進行から受けた依頼では、[共通設定](../../referenc
 
 完了条件は公開物の性質と変更の影響から決める。Web、配布アプリ、ライブラリ、CLIで同じ端末検証を強制しない。マイグレーション、バックエンド連携、実機導入、配布ストアの処理、運用ログは、対象に関係する場合の条件として扱う。不要な項目を形式的に増やさず、必要な条件を使えるツールに合わせて弱めない。
 
-公開・認証・破壊的操作の許可はユーザーの依頼と実行環境の規則に従う。リリース依頼から別環境への展開、データ削除、課金変更、対外告知、ストア審査提出の許可を推測しない。
+公開先はプロジェクトの公開手順・資料に書かれた先とし、本人の操作が必要な認証と実行環境の規則に従う。リリース依頼から別環境への展開、データ削除、課金変更、対外告知、ストア審査提出を推測しない（[確認する操作](../../references/request-scope.md#確認する操作)）。
 
 ## 実行
 
@@ -31,7 +31,7 @@ Linearの開発進行から受けた依頼では、[共通設定](../../referenc
 2. プロジェクトが定める検証とビルドを行い、公開する成果物の識別情報を記録する。
 3. 文書化された公開経路を実行する。処理中・配布可能・利用確認済みを区別する。
 4. 同じrevision／バージョンに対して完了条件を確認する。関連システムがある場合は整合も確認し、別revisionの正常応答を今回の成功と扱わない。
-5. 失敗した段階、外部への反映状況、復旧手順を保持する。再試行前に反映状態を確認し、二重公開を避ける。復旧も既存の許可範囲で行う。
+5. 失敗した段階、外部への反映状況、復旧手順を保持する。再試行前に反映状態を確認し、二重公開を避ける。復旧も依頼範囲の中で行う。
 
 ## 完了
 

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作成を暗黙に許可しない。
+契約の構成で登録済みの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-codex/skills/spec/SKILL.md

@@ -14,7 +14,7 @@ description: 曖昧な要望を対話と既存実装・実現可能性の調査
 
 既存構造との適合と技術的な実現可能性を調べる。外部仕様が判断に必要なら公式資料を確認する。候補の数を埋めず、目的に合う推奨案と意味のある代案を示す。プロトタイプは依頼された範囲で必要な場合に行い、仕様相談を本番への変更へ拡大しない。
 
-委託が許可されている場合、登録済みのshinaps-explorer、shinaps-tech-surveyor、shinaps-survey-validatorに調査を依頼し、shinaps-spec-writerで結果を構造化できる。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。提供されていない担当やツールは仮定せず、同じ観点を現在のセッションで確認する。
+委託できる場合、登録済みのshinaps-explorer、shinaps-tech-surveyor、shinaps-survey-validatorに調査を依頼し、shinaps-spec-writerで結果を構造化できる。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。提供されていない担当やツールは仮定せず、同じ観点を現在のセッションで確認する。
 
 [Shinaps規約の取得](../../references/rules.md)に従って取得したShinapsルールを制約の根拠に含める。利用できないときはルール照合を未確認とし、実現可能性や仕様確定に残る影響を明記する。
 

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は明示された許可がある場合だけ行う。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。独立レビューがプロジェクトの必須条件なら未完了として扱う。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`) によって投入できなかった候補の件数 (あれば)