@shinaps/skills 0.48.0 → 0.50.0

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