@shinaps/skills 0.46.0 → 0.47.0

package/docs/install.md

@@ -26,7 +26,7 @@ npx @shinaps/skills@latest recover codex
 設定の検証（`validate-linear-config`・`validate-managed-config`）、Managed Agents の操作（`managed`）、規約の機械検査（`lint`、[規約の機械検査](lint.md)）には、配布 CLI `shinaps-skills` を使います。CLI は plugin に含まれないため、利用中のスキルと同じ版を導入します。
 
 ```sh
-npm install -g @shinaps/skills@0.46.0
+npm install -g @shinaps/skills@0.47.0
 shinaps-skills --version
 ```
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.46.0",
+  "version": "0.47.0",
   "description": "Install Shinaps AI workflows and custom agents for Codex",
   "type": "module",
   "bin": {

package/plugins/shinaps-claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "shinaps",
   "description": "Shinaps AIの開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・レビュー・コミット・PR・リリースとLinearでの開発進行を支援する。",
-  "version": "0.46.0",
+  "version": "0.47.0",
   "author": {
     "name": "shinaps"
   },

package/plugins/shinaps-claude/references/linear/configuration.md

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.46.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.46.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.47.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.47.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
 
 0.35.0から通常設定の `review_flow.mode` に `ask` を受理する。`config_version` は2のままで、既存のauto・manualの設定は変更不要。0.33.0〜0.34.xのCLIと `$schema` のURLは `ask` を拒否するため、`ask` を使う設定では `$schema` も0.35.0以降のURLにする。
 

package/plugins/shinaps-claude/references/lint.md

@@ -31,4 +31,4 @@ Shinaps AIの規約は、機械検査（`checks`）を持てる。検査は配
 - **使えるルール**: ESLint core、`@typescript-eslint/*`（型情報を使うものを含む）、`vue/*`、`react-x/*` のうち `rules-of-hooks`・`exhaustive-deps`・`no-array-index-key`・`no-missing-key`・`no-nested-component-definitions`・`no-unstable-context-value`、`regexp/*`、同梱の `shinaps/*`（`docs/lint.md` の一覧）。版によって違うので、同じ版のCLIで確かめる。使えるルールが無い規約には検査を付けない（AI照合のまま）。同梱ルールの追加は `docs/lint.md` の手順で別の作業として提案する。
 - **coverageの判断**: 規約の全文（scope・labelsを含み、更新では更新後の全文）と、検査の `rule`・`options`・`files` を照らす。`files` の範囲で、規約が求めることへの違反をこのルールが全て報告すると言えるときだけ `full`、見逃しが一つでもありうれば `partial`。lintが規約より広く報告する（例外も報告する）ことは `full` の妨げにならない（指摘はメインが確認する）。例で通ることは根拠にならない。Vueのテンプレートを見るルール（`vue/*` のテンプレート用、`shinaps/vue-no-index-key`）は、HTML以外のテンプレート（`lang="pug"` など）を解析せず報告なしで終わるので、それだけでは `.vue` を対象に `full` にできない。
 - **補助の確認**: 規約のgood・badの例を一時ディレクトリにファイルとして書き、同じ入口で実行して、badで報告され、goodで報告されないことを確かめる。対象プロジェクトのコードを写さない。
-- **書き込み**: `record_rule`・`update_rule` の `checks` に渡す。一括の `record_rules` は `checks` を受け取らない（付けると呼出し全体が入力エラーになる）ので、検査は登録後に `update_rule` で付ける。`update_rule` は配列ごと置換し、`[]` で外す。検査を持つ規約の内容（出典とrepoの表示名以外。適用先はscope、repo_ownerのowner、repoのrepoIdで比べる）を変える更新では、更新後の全文で検査を見直し、同じ要求で `checks` を渡す。渡さないと `CHECKS_REQUIRED` で保存されない。見直した結果が同じなら同じ配列を渡す。
+- **書き込み**: `record_rule`・`update_rule` の `checks` に渡す。一括の `record_rules` は `checks` を受け取らない（付けると呼出し全体が入力エラーになる）ので、検査は登録後に `update_rule` で付ける。`update_rule` は配列ごと置換し、`[]` で外す。検査を持つ規約の内容（repoの表示名以外。適用先はscope、repo_ownerのowner、repoのrepoIdで比べる）を変える更新では、更新後の全文で検査を見直し、同じ要求で `checks` を渡す。渡さないと `CHECKS_REQUIRED` で保存されない。見直した結果が同じなら同じ配列を渡す。

package/plugins/shinaps-claude/references/rule-writing.md

@@ -20,7 +20,7 @@ Shinaps AIへ個人規約を登録・更新するときの書き方。短さそ
 1. **提示**: 同じ場面で既存の規約と両方には従えない、候補に従うと既存の規約の例外や強さが意味を持たなくなる、更新先を一つに決められない、または結果を判断できない。
 2. **書かない**: 同じ判断で範囲が候補を含む既存の規約があり、候補に加える情報が無い（言い換えは情報に数えない）。または、同じ判断で範囲が候補を含むのが公式規約だけである（補足があれば報告する）。
 3. **提示**: 取得が未完了である。「重複なし」とせず、未取得の範囲を示す。
-4. **更新**: 同じ判断で範囲が候補を含む個人規約があり、候補の補足（理由・例・出典）が判断を変えず、その規約の範囲全体に当てはまる。判断・範囲・kindは変えない。
+4. **更新**: 同じ判断で範囲が候補を含む個人規約があり、候補の補足（理由・例）が判断を変えず、その規約の範囲全体に当てはまる。判断・範囲・kindは変えない。
 5. **提示**: 同じ判断の個人規約と範囲が重なるが候補を含まない、または補足がその規約の範囲の一部にしか当てはまらない。
 6. **新規**: それ以外。別の判断で既存の規約と両立するもの、公式規約より範囲が広い同じ判断を含む。
 
@@ -53,8 +53,8 @@ coding の規約は、使えるlintのルールで検査できるかを判断し
 ## 残すものと削るもの
 
 - 適用条件、例外、強制か推奨かの強さは必ず残す。短くするために意味を変えない。
-- 経緯、PR番号、発生日は、判断の根拠や適用範囲を理解するために必要な分だけ残す。詳細な出典は `sourceUrls` に置く。
-- 出典、scope、kind、labelsは、規約の内容が変わらない限り変えない。出典を足すときは既存の出典を残す。
+- 経緯、PR番号、発生日は、判断の根拠や適用範囲を理解するために必要な分だけ本文に残す。判断に要る資料は本文で引用してよい（URLを含めてよい）。出典URLの一覧は保存せず、本文にも移さない。
+- scope、kind、labelsは、規約の内容が変わらない限り変えない。
 - 読み手がリポジトリの既存の規約や公式の文書から分かることは繰り返さない。
 - 根拠の無いコード例・URL・規範を作らない。
 

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

@@ -80,16 +80,13 @@ Good/Bad サンプルコード (examples) の付け方:
 - good / bad の大きさは [Shinaps規約の書き方](../../references/rule-writing.md) の目安に従う。language は shiki の言語 id 小文字 (`typescript` / `tsx` / `python` / `go` 等)
 - good / bad / language は 3 つセットでしか登録できない (揃っていないと入力の schema 検証で拒否される)
 
-出典 URL (sourceUrls) の付け方:
-
-- 根拠になったレビューコメントの HTML URL (`#discussion_r...` / `#issuecomment-...`) を優先し、特定できなければ PR URL にフォールバック。http(s) のみ。上限は MCP ツールの入力の説明に従う
-- **出典素材が無い rule に URL を捏造しない** (省略可 = 出典なしで保存される)
+出典 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?, sourceUrls? }, ...] })` で **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 検証で拒否される)。
+- 候補を確定してから、[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_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]` から分かる。上書きせず**提示**へ進める。
@@ -102,7 +99,7 @@ Good/Bad サンプルコード (examples) の付け方:
 > ```
 > 上書きしますか? (yes / no / skip-all)
 
-- 同意なら `update_rule({ id: <既存 rule の id>, why?, recommend?, avoid?, examples?, sourceUrls? })` を実行。sourceUrls は配列ごと置き換わるので、既存と新しい出典をまとめて渡す (上限を超えるなら切り詰めずに利用者へ確認する)。`skip-all` を選ばれたら以降の差分確認をスキップする
+- 同意なら `update_rule({ id: <既存 rule の id>, why?, recommend?, avoid?, examples? })` を実行。`skip-all` を選ばれたら以降の差分確認をスキップする
 
 ## Step 8. 100 PR ブロック確認
 

package/plugins/shinaps-codex/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "shinaps",
-  "version": "0.46.0",
+  "version": "0.47.0",
   "description": "Shinaps AIのCodex向け開発ワークフロー",
   "skills": "./skills/"
 }

package/plugins/shinaps-codex/references/linear/configuration.md

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.46.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.46.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.47.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.47.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
 
 0.35.0から通常設定の `review_flow.mode` に `ask` を受理する。`config_version` は2のままで、既存のauto・manualの設定は変更不要。0.33.0〜0.34.xのCLIと `$schema` のURLは `ask` を拒否するため、`ask` を使う設定では `$schema` も0.35.0以降のURLにする。
 

package/plugins/shinaps-codex/references/lint.md

@@ -31,4 +31,4 @@ Shinaps AIの規約は、機械検査（`checks`）を持てる。検査は配
 - **使えるルール**: ESLint core、`@typescript-eslint/*`（型情報を使うものを含む）、`vue/*`、`react-x/*` のうち `rules-of-hooks`・`exhaustive-deps`・`no-array-index-key`・`no-missing-key`・`no-nested-component-definitions`・`no-unstable-context-value`、`regexp/*`、同梱の `shinaps/*`（`docs/lint.md` の一覧）。版によって違うので、同じ版のCLIで確かめる。使えるルールが無い規約には検査を付けない（AI照合のまま）。同梱ルールの追加は `docs/lint.md` の手順で別の作業として提案する。
 - **coverageの判断**: 規約の全文（scope・labelsを含み、更新では更新後の全文）と、検査の `rule`・`options`・`files` を照らす。`files` の範囲で、規約が求めることへの違反をこのルールが全て報告すると言えるときだけ `full`、見逃しが一つでもありうれば `partial`。lintが規約より広く報告する（例外も報告する）ことは `full` の妨げにならない（指摘はメインが確認する）。例で通ることは根拠にならない。Vueのテンプレートを見るルール（`vue/*` のテンプレート用、`shinaps/vue-no-index-key`）は、HTML以外のテンプレート（`lang="pug"` など）を解析せず報告なしで終わるので、それだけでは `.vue` を対象に `full` にできない。
 - **補助の確認**: 規約のgood・badの例を一時ディレクトリにファイルとして書き、同じ入口で実行して、badで報告され、goodで報告されないことを確かめる。対象プロジェクトのコードを写さない。
-- **書き込み**: `record_rule`・`update_rule` の `checks` に渡す。一括の `record_rules` は `checks` を受け取らない（付けると呼出し全体が入力エラーになる）ので、検査は登録後に `update_rule` で付ける。`update_rule` は配列ごと置換し、`[]` で外す。検査を持つ規約の内容（出典とrepoの表示名以外。適用先はscope、repo_ownerのowner、repoのrepoIdで比べる）を変える更新では、更新後の全文で検査を見直し、同じ要求で `checks` を渡す。渡さないと `CHECKS_REQUIRED` で保存されない。見直した結果が同じなら同じ配列を渡す。
+- **書き込み**: `record_rule`・`update_rule` の `checks` に渡す。一括の `record_rules` は `checks` を受け取らない（付けると呼出し全体が入力エラーになる）ので、検査は登録後に `update_rule` で付ける。`update_rule` は配列ごと置換し、`[]` で外す。検査を持つ規約の内容（repoの表示名以外。適用先はscope、repo_ownerのowner、repoのrepoIdで比べる）を変える更新では、更新後の全文で検査を見直し、同じ要求で `checks` を渡す。渡さないと `CHECKS_REQUIRED` で保存されない。見直した結果が同じなら同じ配列を渡す。

package/plugins/shinaps-codex/references/rule-writing.md

@@ -20,7 +20,7 @@ Shinaps AIへ個人規約を登録・更新するときの書き方。短さそ
 1. **提示**: 同じ場面で既存の規約と両方には従えない、候補に従うと既存の規約の例外や強さが意味を持たなくなる、更新先を一つに決められない、または結果を判断できない。
 2. **書かない**: 同じ判断で範囲が候補を含む既存の規約があり、候補に加える情報が無い（言い換えは情報に数えない）。または、同じ判断で範囲が候補を含むのが公式規約だけである（補足があれば報告する）。
 3. **提示**: 取得が未完了である。「重複なし」とせず、未取得の範囲を示す。
-4. **更新**: 同じ判断で範囲が候補を含む個人規約があり、候補の補足（理由・例・出典）が判断を変えず、その規約の範囲全体に当てはまる。判断・範囲・kindは変えない。
+4. **更新**: 同じ判断で範囲が候補を含む個人規約があり、候補の補足（理由・例）が判断を変えず、その規約の範囲全体に当てはまる。判断・範囲・kindは変えない。
 5. **提示**: 同じ判断の個人規約と範囲が重なるが候補を含まない、または補足がその規約の範囲の一部にしか当てはまらない。
 6. **新規**: それ以外。別の判断で既存の規約と両立するもの、公式規約より範囲が広い同じ判断を含む。
 
@@ -53,8 +53,8 @@ coding の規約は、使えるlintのルールで検査できるかを判断し
 ## 残すものと削るもの
 
 - 適用条件、例外、強制か推奨かの強さは必ず残す。短くするために意味を変えない。
-- 経緯、PR番号、発生日は、判断の根拠や適用範囲を理解するために必要な分だけ残す。詳細な出典は `sourceUrls` に置く。
-- 出典、scope、kind、labelsは、規約の内容が変わらない限り変えない。出典を足すときは既存の出典を残す。
+- 経緯、PR番号、発生日は、判断の根拠や適用範囲を理解するために必要な分だけ本文に残す。判断に要る資料は本文で引用してよい（URLを含めてよい）。出典URLの一覧は保存せず、本文にも移さない。
+- scope、kind、labelsは、規約の内容が変わらない限り変えない。
 - 読み手がリポジトリの既存の規約や公式の文書から分かることは繰り返さない。
 - 根拠の無いコード例・URL・規範を作らない。
 

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

@@ -9,7 +9,7 @@ description: GitHubの過去PRレビューから繰り返し適用できる規
 
 1. `gh`で期間内のマージ済みPRを取得する。ページングし、並び順と日付フィルターの関係を守る。更新日時順の一覧で古いマージ日時を一件見つけても、それ以降の取得を打ち切らない。
 2. PRのreview本文・inline comment・conversation commentを取得する。PR descriptionはレビュー指摘として扱わない。APIのBot種別は除外し、判断が必要な投稿者は確認する。認証情報やリポジトリ全体をサービスへ送信しない。
-3. 複数のレビューで繰り返され、適用条件とWHYが説明できる規約を候補にする。根拠のない例・URLを作らず、レビューコメントの出典を付ける。
+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回だけ再試行し、続けて拒否されたら中断して報告する。