@shinaps/skills 0.48.0 → 0.49.0

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) に従う。