@shinaps/skills 0.41.0 → 0.43.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (17) hide show
  1. package/docs/install.md +1 -1
  2. package/package.json +1 -1
  3. package/plugins/shinaps-claude/.claude-plugin/plugin.json +1 -1
  4. package/plugins/shinaps-claude/references/linear/configuration.md +1 -1
  5. package/plugins/shinaps-claude/references/rule-writing.md +29 -1
  6. package/plugins/shinaps-claude/references/rules.md +52 -20
  7. package/plugins/shinaps-claude/skills/debug/SKILL.md +1 -1
  8. package/plugins/shinaps-claude/skills/extract-rules/SKILL.md +6 -5
  9. package/plugins/shinaps-claude/skills/refine/SKILL.md +7 -6
  10. package/plugins/shinaps-claude/skills/review/SKILL.md +1 -1
  11. package/plugins/shinaps-codex/.codex-plugin/plugin.json +1 -1
  12. package/plugins/shinaps-codex/references/linear/configuration.md +1 -1
  13. package/plugins/shinaps-codex/references/rule-writing.md +29 -1
  14. package/plugins/shinaps-codex/references/rules.md +52 -20
  15. package/plugins/shinaps-codex/skills/extract-rules/SKILL.md +3 -3
  16. package/plugins/shinaps-codex/skills/refine/SKILL.md +2 -2
  17. package/plugins/shinaps-codex/skills/review/SKILL.md +1 -1
package/docs/install.md CHANGED
@@ -26,7 +26,7 @@ npx @shinaps/skills@latest recover codex
26
26
  設定の検証（`validate-linear-config`・`validate-managed-config`）と Managed Agents の操作（`managed`）には、配布 CLI `shinaps-skills` を使います。CLI は plugin に含まれないため、利用中のスキルと同じ版を導入します。
27
27
 
28
28
  ```sh
29
- npm install -g @shinaps/skills@0.41.0
29
+ npm install -g @shinaps/skills@0.43.0
30
30
  shinaps-skills --version
31
31
  ```
32
32
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@shinaps/skills",
3
- "version": "0.41.0",
3
+ "version": "0.43.0",
4
4
  "description": "Install Shinaps AI workflows and custom agents for Codex",
5
5
  "type": "module",
6
6
  "bin": {
package/plugins/shinaps-claude/.claude-plugin/plugin.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "shinaps",
3
3
  "description": "Shinaps AIの開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・レビュー・コミット・PR・リリースとLinearでの開発進行を支援する。",
4
- "version": "0.41.0",
4
+ "version": "0.43.0",
5
5
  "author": {
6
6
  "name": "shinaps"
7
7
  },
package/plugins/shinaps-claude/references/linear/configuration.md CHANGED
@@ -4,7 +4,7 @@
4
4
 
5
5
  ## 検証CLIと契約版
6
6
 
7
- 利用中のskillとCLIの版を確認し、0.41.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.41.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
7
+ 利用中のskillとCLIの版を確認し、0.43.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.43.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
8
8
 
9
9
  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にする。
10
10
 
package/plugins/shinaps-claude/references/rule-writing.md CHANGED
@@ -4,7 +4,35 @@ Shinaps AIへ個人規約を登録・更新するときの書き方。短さそ
4
4
 
5
5
  ## 1件1判断
6
6
 
7
- 1件には1つの判断だけを書く。別々に適用・変更できる判断は分ける。登録の前に[Shinaps規約の取得](rules.md)で既存の規約を確かめ、同じ判断があれば新規に増やさず更新を検討する。
7
+ 1件には1つの判断だけを書く。別々に適用・変更できる判断は分ける。
8
+
9
+ ## 書き込む前に既存の規約と比べる
10
+
11
+ `record_rule`・`record_rules`・`update_rule` の前に、書き込む全文（scope・labelを含み、更新では更新後の全文）を既存の規約の全文と比べる。比べるのは呼出し元のAIで、類似度の点数は作らない。既存の規約は[Shinaps規約の取得](rules.md)の「書き込む前に取得する」で取得する。全文や範囲が変わったら比べ直す。
12
+
13
+ 比べるのは次の2つ。
14
+
15
+ - **判断**: 適用条件・求める行動・例外・強さ（強制か推奨か）。文面が違っても全て同じなら同じ判断で、文面が似ていても一つ違えば別の判断とする。適用条件の広さの違いは判断の違いに数えず、範囲で比べる。
16
+ - **範囲**: scope・技術のlabel・公式規約の版の条件・適用条件の広さ。
17
+
18
+ 候補ごとに読んだ既存の規約の全てを見て、次の順で最初に当てはまる結果にする。公式規約は読むだけで、書き込み先にしない。
19
+
20
+ 1. **提示**: 同じ場面で既存の規約と両方には従えない、候補に従うと既存の規約の例外や強さが意味を持たなくなる、更新先を一つに決められない、または結果を判断できない。
21
+ 2. **書かない**: 同じ判断で範囲が候補を含む既存の規約があり、候補に加える情報が無い（言い換えは情報に数えない）。または、同じ判断で範囲が候補を含むのが公式規約だけである（補足があれば報告する）。
22
+ 3. **提示**: 取得が未完了である。「重複なし」とせず、未取得の範囲を示す。
23
+ 4. **更新**: 同じ判断で範囲が候補を含む個人規約があり、候補の補足（理由・例・出典）が判断を変えず、その規約の範囲全体に当てはまる。判断・範囲・kindは変えない。
24
+ 5. **提示**: 同じ判断の個人規約と範囲が重なるが候補を含まない、または補足がその規約の範囲の一部にしか当てはまらない。
25
+ 6. **新規**: それ以外。別の判断で既存の規約と両立するもの、公式規約より範囲が広い同じ判断を含む。
26
+
27
+ `update_rule` の依頼では更新対象自身を比較の相手から外し、他の規約で1〜3に当たらなければ結果を更新とする。当たるときは結果を提示とし、更新対象を変えず、更新前の全文のまま残ることを示す。更新対象の削除や他の規約との統合は、利用者が選んだときだけ行う。判断や範囲を変える更新は、更新前後の全文の差分と範囲の変化を示して同意を受ける。
28
+
29
+ 同じ作業で保存前の候補同士は、範囲が広い方（決まらなければ先の候補）を既存の規約とみなして同じ順で比べる。結果が提示なら両方を提示する。更新は相手の候補の下書きへ補足を足すことで、`update_rule` は呼ばず、許可は相手の候補の結果で判断する。書かないと更新は、相手の候補が保存されたときに確定する。相手の全文が変わる、または書かれないときは、書かないまたは更新とした候補を比べ直す。範囲は足し合わせず、呼出しのscopeに揃えるために候補のscopeを変えない。
30
+
31
+ 提示では候補と既存の規約の全文の違い、推奨する結果と理由、その候補を相手とした他の候補を示し、利用者の判断を受ける。提示した全文のまま利用者が選んだ操作は、比べ直さずに書く。同じtitleの既存があるなどで書けなかった候補も提示する。
32
+
33
+ 比較の結果は書き込みの許可にならない。更新・新規は結果が許可された操作・対象と一致するときだけ書き、違えば書かずに提示する。比べた他の規約は変更しない。
34
+
35
+ 結果は候補ごとに、比べた既存の規約のidまたは相手の候補、未確定ならその旨、取得の条件、未完了の範囲と返らない範囲を添えて報告する。
8
36
 
9
37
  ## 項目の役割
10
38
 
package/plugins/shinaps-claude/references/rules.md CHANGED
@@ -1,50 +1,82 @@
1
1
  # Shinaps規約の取得
2
2
 
3
- Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メイン）だけが行い、担当へは全文を渡す。保存できる規約は必ず1応答に収まり、1応答は100件かつ32,000 bytes（MCPのcontent textのUTF-8）までに分かれるので、下の手順で全件を辿る。
3
+ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メイン）だけが行い、担当へは全文を渡す。保存できる規約は必ず1応答に収まり、1応答は100件かつ32,000 bytes（MCPのcontent textのUTF-8）までに分かれるので、下の順に全件を辿る。
4
4
 
5
- ## 一覧を取る
5
+ ## 語彙を確認する
6
+
7
+ `list_search_facets` を呼び、`languages`・`platforms`・`frameworks`・`topics` の語彙と `versionTargets` を確かめる。以降で渡すslugと版のtargetは、この応答にあるものだけにする。語彙に無いfacetのslugはエラーにならず、結果が黙って変わる。
8
+
9
+ 件数の確認でfacetを渡さないときは、この節と次の節を省く。
10
+
11
+ ## 対象の技術を選ぶ
6
12
 
7
- `list_search_facets` で語彙と `versionTargets` を確認し、`search_rules` を `fields: "summary"` で呼ぶ。
13
+ 対象ファイルが確定した照合（`refine`・`review`）は、ファイルごとに `languages`・`platforms`・`frameworks` の各軸を「確定（slugの集合。空でもよい）」か「不明」に判定する。
8
14
 
9
- - `repoOwner`・`repoName` は現在のGit workspaceから渡す。facetを1つも渡さないと公式ルールは返らない。
10
- - `projectVersions` にはmanifest・lockfile・compiler config・deployment targetから確認できた版だけを渡す。確認できないときは省き、条件付きの公式ルールが除外されて共通ルールだけの照合になったことを結果に書く。
11
- - `nextCursor` がnullになるまで、他の入力を変えず `cursor` に渡して続きを取得する。途中で止めた範囲は未取得として扱う。
15
+ **確定と言えるのは、そのファイルに当てはまる規約のその軸のlabelが、必ずその集合に入るときだけ。** サーバーは指定した軸のどれか1つでも不一致の規約を除くので、この条件が満たせない軸は不明にする。
12
16
 
13
- ## 個人規約を対象ファイルの技術で絞る
17
+ - **framework**: 対象が動くパッケージのコードが実行時に使う技術の和にする（対象がライブラリなら利用側のパッケージも含める）。対象は呼出元の文脈でも動くので、直接importしない技術の規約も当てはまる。workspaceパッケージは公開入口まで辿り（再公開に注意する）、書かれないimportやフレームワークが内包する技術（JSX、Nextのreactなど）も含める。型だけのimportは辿らず、manifestにあるだけの依存は入れない。実行時の利用側を確認できないパッケージ（型だけのパッケージ、外部へ公開するライブラリ）は不明にする。
18
+ - **language**: TypeScriptとJavaScriptのコードは `typescript` と `javascript` の両方にする（片方のlabelの規約がもう片方にも当てはまる）。
19
+ - **platform**: 使うAPIではなく実行環境で判定する。配備先のentryから読み込まれるコードはそのslugにする。ブラウザだけで動くコードは空にする。
20
+ - **設定・生成物・スタイル**（`wrangler.jsonc`、`tsconfig.json`、migration、CSSなど）: 対象のパッケージのコードと同じ値にする。配備設定のplatformは配備先のslugにする。**文書**は全軸を空にする。
21
+ - **語彙外の技術**: 語彙のslugと同じ役割なら不明にする（Prisma、Kotlin、Android、Nodeのサーバー、フレームワークなしのサーバー実装、生SQLなど。類似のslugで置き換えない）。役割が重ならない補助ライブラリは数えない。
22
+ - 辿っていない・確かめられない軸は不明にする。
23
+
24
+ **合成**: 全ファイルが確定で、和が1〜8件の軸だけを検索に渡す。不明なファイルがある軸と9件以上の軸は省略する。和が空の軸は検索で表せないので、全文の選択で使う。
25
+
26
+ 対象が確定していない工程（devの入口・`spec`・`explore`・`debug`）は、論点の技術を語彙から推定してよい。`filterUserRulesByLabels` は指定しない。
27
+
28
+ ## 一覧を取る
14
29
 
15
- 対象ファイルが確定した照合（`refine`・`review`）では、`search_rules` に `filterUserRulesByLabels: true` を渡し、対象の技術と明確に異なる個人規約を一覧から除く。それ以外（devの入口・`spec`・`explore`・`debug`、既存規約との重複の確認）では指定しない。対象ファイルの技術が増えたら取り直す。
30
+ `search_rules` を `fields: "summary"` で呼ぶ。`repoOwner`・`repoName` は現在のGit workspaceから渡す。対象が確定した照合では `filterUserRulesByLabels: true` を渡す。
16
31
 
17
32
  ```json
18
- { "fields": "summary", "repoOwner": "...", "repoName": "...", "languages": ["typescript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
33
+ { "fields": "summary", "repoOwner": "...", "repoName": "...", "languages": ["typescript", "javascript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
19
34
  ```
20
35
 
21
- サーバーは同じ軸をOR、指定した軸の間をANDで判定する。未指定の軸、規約にlabelが無い軸、topic、未知・別軸・無効なslugを含む軸、無効なlabelしかない軸では除外しない。除外の判定に使う語彙は `list_search_facets` が返すものだけ。
22
-
23
- - 渡すのは、対象が使う技術そのものか、その別名か、実際の依存・基盤として使うことを確認できたslugだけにする。確認には対象ファイルの内容・パスと、そのファイルが属するパッケージの設定（manifest・`wrangler.jsonc` など）を使う。manifestにあるだけの依存は、そのファイルで使うと確認できなければ渡さない。リポジトリ全体の技術を一つのファイルに流用しない。同じ役割や類似の技術のslugに置き換えない。
24
- - 複数のファイルは全ファイルの技術の和を渡す。1ファイルでも不明な技術や語彙外の技術があり、確認できたslugでは表しきれない軸は省略する。8件を超える軸も省略する。Markdownや一般の設定ファイルのように技術を持たないファイルは不明に数えない。
25
- - facetは公式ルールの検索と共有する。軸を省略すると、その軸で絞られなくなるので公式ルールの件数も増える。全ての軸を省略して `topics` も無ければ公式ルールは空なので、公式ルールは未照合と報告するか、`topics` を渡す。
26
- - 件数で規約の登録の有無を判断するときは、この指定なしの結果を使う。
27
- - サーバーが除外した規約のidは返らないので、照合結果には指定したfacetと `filterUserRulesByLabels: true` を書く。
36
+ - サーバーは同じ軸をOR、指定した軸の間をANDで判定する。
37
+ - `nextCursor` がnullになるまで、他の入力を変えず `cursor` に渡す。途中で止めた範囲は未取得として扱う。
38
+ - **渡せる軸が無いと公式ルールは0件で返り、照合したことにならない。** 不明なファイルを除いて選び直し、`filterUserRulesByLabels` なしで取得する（個人規約は全件返る）。除いたファイルの公式ルールは未照合になる。それでも渡せる軸が無ければ、全ての公式ルールが未照合になる。`topics` は一致必須なので、渡すと部分的な照合になる。
39
+ - **版**: 対象が使う技術のうち `versionTargets` にあるものは、lockfile・compiler config・deployment target、または完全固定のmanifestで確定した版を `projectVersions` に渡す（`^19` のような範囲は渡さない）。渡していないtargetの条件付き公式ルールは全て除外される。同じtargetで対象ごとに版が違うなら、対象を分けて取得してidの和を取る。`VERSION_TARGET_NOT_FOUND` は全体の失敗なので、targetを直して先頭から取り直す。
40
+ - 対象ファイルの技術が増えたら取り直す。件数で規約の登録の有無を判断するときは、`filterUserRulesByLabels` なしの結果を使う。既存規約との重複は「書き込む前に取得する」で確かめる。
28
41
 
29
42
  ## 全文を取る規約を選ぶ
30
43
 
31
44
  一覧は全文を選ぶためのものであり、一覧だけで規約を満たした、または非該当と判断しない。
32
45
 
33
- - 除外できるのは、labelの language・platform・framework が対象と明確に異なる規約だけ。その軸のlabelが無い規約は軸に依存しない規約として残す。slugの種類は `list_search_facets` で確かめる。
34
- - titleとtopicでは除外しない。判断できない規約は全文を取得する。
46
+ - 除外できるのは、全ファイルが確定で和が空の軸にlabelを持つ規約だけ（ブラウザだけで動くコードと `cloudflare-workers` など）。labelの軸は `list_search_facets` で確かめる。
47
+ - titleとtopicでは除外しない。
35
48
  - 除外した規約はidと理由を記録する。
36
49
 
37
50
  ## 全文を取る
38
51
 
39
52
  選んだidを100件までに分けて `get_rules` へ渡す。
40
53
 
41
- - `remainingIds` が空になるまで、そのまま `ids` に渡して続きを取得する。
54
+ - `remainingIds` が空になるまで、そのまま `ids` に渡して続きを取得してから、次のidへ進む。1応答の大きさの上限があるので、100件より少なく返ることが多い。
42
55
  - `notFoundIds` は削除済みまたは参照できない規約なので、idを記録して照合の対象から外す。
43
56
  - 全件が必要と分かっているときは、`search_rules` の `fields: "full"` を `nextCursor` がnullになるまで辿ってもよい。
44
57
  - `RATE_LIMITED` は短い時間を置いて、同じ `cursor` または `remainingIds` から再開する。
45
58
 
59
+ ## 書き込む前に取得する
60
+
61
+ [Shinaps規約の書き方](rule-writing.md)の比較に使う規約は、次の条件で取得する。
62
+
63
+ - `search_rules` は `fields: "summary"` で全ページ取得し、`filterUserRulesByLabels` と `kind` を渡さない。`repoOwner`・`repoName` は、登録先のowner・repoがあればその値、無い分は現在のGit workspaceの値にする。
64
+ - 公式規約も一覧に載るよう、`list_search_facets` の語彙が8件以内の技術軸（`languages` など）を一つ選び、その全slugを渡す。技術軸はその軸のlabelが無い公式規約にも一致する。`topics` は一致必須で別のtopicの公式規約が返らなくなるので渡さない。渡せる軸が無ければ公式規約の取得は未完了とする。
65
+ - `projectVersions` には確定した版だけを渡す。渡しても渡さなくても、条件に合わない条件付きの公式規約は返らない。
66
+ - 一覧のtitleとlabelから同じ場面を扱う可能性を否定できない規約を選び、「全文を取る」で全文を取得する。文字列の一致で選ばない（公式規約のtitleは英語）。「全文を取る規約を選ぶ」は対象ファイルとの照合の基準で、ここには適用しない。
67
+ - 同じ条件の結果は、規約を書き込むまでの間、候補の間で再利用してよい。他の工程で `filterUserRulesByLabels`・`kind`・`topics` を使って絞った結果は使わない。
68
+
69
+ 選んだ条件の一覧と選んだ全文を読み終えていなければ未完了とする。他のリポジトリ・ownerの個人規約と版の条件で除かれた公式規約は検索で返らない範囲で、未完了に数えずに報告する。どちらの場合も「全体に重複が無い」とは言わない。
70
+
46
71
  ## 担当へ渡す
47
72
 
48
73
  全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
49
74
 
50
- 取得・受渡し・読了のいずれかが終わらなかった規約は、idまたは条件を挙げて未照合と報告し、照合済みにしない。
75
+ ## 照合結果に書くこと
76
+
77
+ - 渡した全てのfacet・`projectVersions`・`filterUserRulesByLabels`。サーバーが除外した規約のidは返らないので、除外の条件として残す。
78
+ - 全文の選択で除外した規約のidと理由、`notFoundIds`。
79
+ - 省略した軸・版と理由、未照合になった公式ルールの範囲。
80
+ - 取得・受渡し・読了のいずれかが終わらなかった規約のidまたは条件。これらは照合済みにしない。
81
+
82
+ この手順は判定の基準を示すが、規約の漏れが無いことの証明にはならない。「漏れなし」と報告しない。
package/plugins/shinaps-claude/skills/debug/SKILL.md CHANGED
@@ -77,7 +77,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
77
77
 
78
78
  #### 前準備 (メインスレッド)
79
79
 
80
- [Shinaps規約の取得](../../references/rules.md) に従い、`topics: ["debugging", ...推定 topic]` で一覧を取って必要な規約全文を取得する。
80
+ [Shinaps規約の取得](../../references/rules.md) に従い、症状と起点から確認・推定した技術の language / platform / framework で一覧を取って必要な規約全文を取得する。`topics` は論点を意図して絞るときだけ渡す。
81
81
 
82
82
  #### プロンプト
83
83
 
package/plugins/shinaps-claude/skills/extract-rules/SKILL.md CHANGED
@@ -63,7 +63,7 @@ PR description (本文) は対象外。あくまで「レビュー観点」を
63
63
 
64
64
  ## Step 6. 既存 rules 把握
65
65
 
66
- 100 PR を 1 ブロックとして処理する。ブロックの開始時に必ず shinaps-ai MCP server の `search_rules({ fields: "summary", repoOwner, repoName })` を `nextCursor` が null になるまで呼んで、既存 userRules の一覧を取得する (facet を渡さないので officialRules は空、userRules は継承マージで scope=user / repo_owner / repo の全件)。全文は Step 7 で候補ごとに確かめる。これを「新規 (= `record_rules` の投入対象に含める) か、既存 rule を更新する `update_rule` か」を判断する材料にする。
66
+ 100 PR を 1 ブロックとして処理する。ブロックの開始時に必ず [Shinaps規約の取得](../../references/rules.md) の「書き込む前に取得する」に従って一覧を最後のページまで取得する (userRules は継承マージで scope=user / repo_owner / repo の全件)。全文は Step 7 で候補ごとに確かめる。
67
67
 
68
68
  ## Step 7. rules 生成と投入
69
69
 
@@ -87,13 +87,13 @@ Good/Bad サンプルコード (examples) の付け方:
87
87
 
88
88
  投入手順:
89
89
 
90
- - 候補ごとに、title か label が重なる既存 rule の全文を `get_rules` で確かめて照合する (重複確認のための絞り込みで、照合対象の除外ではない)。判断できなければ全文を取得する。同じ判断の既存 rule があれば下の差分確認へ回し、それ以外の**新規**候補だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, rules: [{ title, why, recommend?, avoid?, kind?, labels?, examples?, sourceUrls? }, ...] })` で **1 call bulk 投入** する。本文の書き方は [Shinaps規約の書き方](../../references/rule-writing.md)、上限は MCP ツールの入力の説明に従う。`labels` は language / platform / framework / topic の slug 配列 (`list_search_facets` が返す公式カタログの slug のみ、language/platform/framework は 1 rule に各 1 つまで) (1 call 最大 100 件、超えたら分割。同一 title の重複は入力の schema 検証で拒否される)。
91
- - extract-rules は対象 repo の PR レビューから抽出する性質上 scope=repo (当該 repo 限定) がデフォルト。横断ルールとして残したい場合だけユーザー判断で `scope: 'user'` に格上げ。**格上げするときは why / recommend / avoid / examples を当該 repo の固有文脈 (内部 API 名・モジュール構成・ドメイン固有の識別子) から切り離し、他プロジェクトでも適用場面を想定できる汎用的な表現・汎用サンプルに解釈し直してから登録する** (scope=repo のままなら repo 固有の具体的な記述・コード片で良い)
90
+ - 候補を確定してから、[Shinaps規約の書き方](../../references/rule-writing.md) の「書き込む前に既存の規約と比べる」で候補ごとに結果を決める。既存の規約への**更新**は下の差分確認へ進める。**提示** はブロックの終わりにまとめて利用者へ示し、残りの投入は止めない。**新規**候補だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, 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 検証で拒否される)。
91
+ - extract-rules は対象 repo の PR レビューから抽出する性質上 scope=repo (当該 repo 限定) がデフォルト。横断ルールとして残したい場合だけユーザー判断で `scope: 'user'` に格上げし、書き直した全文で比べ直す。**格上げするときは why / recommend / avoid / examples を当該 repo の固有文脈 (内部 API 名・モジュール構成・ドメイン固有の識別子) から切り離し、他プロジェクトでも適用場面を想定できる汎用的な表現・汎用サンプルに解釈し直してから登録する** (scope=repo のままなら repo 固有の具体的な記述・コード片で良い)
92
92
  - `RULE_TOO_LARGE` が返ったら、その呼出し分は全体として保存されていない。details の limit・actual・title を確かめ、該当候補の本文・例・出典を短くしてから同じ呼出しをやり直す。`update_rule` の `RULE_UPDATE_CONFLICT` は全文を読み直してから再試行する。
93
93
  - `RULE_LIMIT_REACHED` が返ったら投入を止める。個人ルールの保存数には上限があり、残りの枠が足りない `record_rules` はその呼出し分が全体として失敗し、一部も保存されない (件数を減らして一部だけ登録する手順へ自動では切り替えない)。それより前の呼出しで投入した分は保存されている。details の `limit` と `actual` から残りの枠を示し、投入する件数を絞るか既存ルールを整理するかのどちらにするかを利用者に確認する。以降のブロックの抽出・投入にも進まず、利用者の選択を待つ。
94
94
  - `RATE_LIMITED` (再試行可能) が返ったら、制限の時間枠が切り替わるまで待ってから、同じ呼出しを1回だけ再試行する。再び拒否されたら、連続して再試行せずに中断し、その状況を利用者に報告する。
95
- - 戻り値は入力の `rules` の位置と id だけ (`inserted: { index, ruleId }[]`、`skipped: { index, existingRuleId }[]`)。`skipped` は「既存と title 重複して投入されなかった候補」で、title は入力の `rules[index]` から分かる。`get_rules` で既存の全文を取得する。
96
- - 事前の照合で一致した候補と `skipped` の両方について、why/recommend/avoid/examples が既存と異なるなら **ユーザーに diff を提示して同意を取る**:
95
+ - 戻り値は入力の `rules` の位置と id だけ (`inserted: { index, ruleId }[]`、`skipped: { index, existingRuleId }[]`)。`skipped` は「既存と title 重複して投入されなかった候補」で、title は入力の `rules[index]` から分かる。上書きせず**提示**へ進める。
96
+ - 既存の規約への**更新**の候補について、**ユーザーに diff を提示して同意を取る**:
97
97
 
98
98
  > 既存 rule "no-unused-vars" が見つかりました。why/recommend/avoid/examples の差分:
99
99
  > ```
@@ -117,4 +117,5 @@ since 期間内の merged PR を消化し終えたら、以下を user に報告
117
117
  - `record_rules` で新規投入した rule 件数 (inserted 合計) + タイトル一覧
118
118
  - `update_rule` で更新した rule 件数 + タイトル一覧
119
119
  - `no` または skip-all で残した候補件数 (あれば)
120
+ - 比較の結果が「書かない」「提示」だった候補の件数と、[Shinaps規約の書き方](../../references/rule-writing.md) の比較が求める報告
120
121
  - 保存上限 (`RULE_LIMIT_REACHED`)・回数制限 (`RATE_LIMITED`) によって投入できなかった候補の件数 (あれば)
package/plugins/shinaps-claude/skills/refine/SKILL.md CHANGED
@@ -53,12 +53,12 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
53
53
 
54
54
  **ファイル数による一律の上限は設けない**。確定した対象集合を維持し、件数の多さだけを理由に対象の縮小やユーザーへの分割確認を求めない。対象の内容量が大きい場合は、ファイルの行数・内容量と関連性（ディレクトリ、機能、依存関係）を見て自動的にバッチへ分ける。小規模なら分割は不要。関連ファイルはできるだけ同じバッチにまとめ、バッチをまたぐ契約は集約時に照合する。
55
55
 
56
- ## Step 1. 規約と context を集約する (並列取得)
56
+ ## Step 1. 規約と context を集約する
57
57
 
58
- 以下を並列で取得:
58
+ [Shinaps規約の取得](../../references/rules.md) に従い、対象ファイルについて規約全文を取得する。userRules と officialRules の両方を照合対象にする。`kind` は通常指定しない (対象ファイル全体を rule 集合と広く照合する用途のため、絞り込むと見落としが増える)。
59
+
60
+ 次の資料は検索と並行して取得してよい:
59
61
 
60
- - shinaps-ai MCP server の `list_search_facets()` で公式カタログの facet (languages / platforms / frameworks / topics の登録済み slug) を取得 → [Shinaps規約の取得](../../references/rules.md) に従って対象ファイルについて確認できた技術の facet slug を確定
61
- - [Shinaps規約の取得](../../references/rules.md) に従って規約全文を取得する (`search_rules` の `fields: "summary"` を全ページ → `get_rules`)。対象ファイルの技術で `filterUserRulesByLabels: true` を指定する。userRules と officialRules の両方を照合対象にする。userRules は scope=user / repo_owner / repo の継承マージから対象の技術と明確に異なるものを除いて返り、officialRules は指定 facet とバージョン適用条件に一致するものへ絞られる。`kind` は通常指定しない (対象ファイル全体を rule 集合と広く照合する用途のため、絞り込むと見落としが増える)
62
62
  - repo root の `AGENTS.md` / `CLAUDE.md` を Read (プロジェクト規約)
63
63
  - AGENTS.md が `docs/` 等を「source of truth」として参照していたら **その docs も Read** (今回変更した領域に関連するものに限定して良い)
64
64
  - グローバル `~/.claude/CLAUDE.md` の `## コメントルール` `## 実装・設計に関して` 等の節 (一度読んだセッションなら conversation history で代替可)
@@ -174,7 +174,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
174
174
 
175
175
  1. **修正する** — どう直すかを 1-2 文で提案 (agent が返した `detail` を活用)。承認されたら `Edit` / `Write` で実行
176
176
  2. **このまま許容する** — 妥当な理由があるとき。理由を今回のローカル成果物（implementation.md / 調査・レビューレポート）に残す (後から「なぜ違反のままにしたか」を辿れるように)
177
- 3. **ルールの方を修正する** — 規約自体が現実と乖離している場合。[Shinaps規約の書き方](../../references/rule-writing.md) に従って shinaps-ai MCP server の `record_rule` (新規) or `update_rule` (既存修正) を実行。新規 record_rule のときは scope (user / repo_owner / repo) も選ばせる (横断的なら user、この repo 限定なら repo)
177
+ 3. **ルールの方を修正する** — 規約自体が現実と乖離している場合。[Shinaps規約の書き方](../../references/rule-writing.md) に従って書き込む全文を作る。新規のときは scope (user / repo_owner / repo) も選ばせる (横断的なら user、この repo 限定なら repo)。同じ文書の「書き込む前に既存の規約と比べる」で比べ (Step 1 の結果はファイルの技術で絞っているので使わない)、結果と全文の差分を示して同意を受けてから shinaps-ai MCP server の `record_rule` (新規) or `update_rule` (既存修正) を実行
178
178
  4. **後回し** — 別タスクとして扱う。`TaskCreate` で TODO 化し、後の作業セッションで着手できるようにする
179
179
 
180
180
  **提示順は `changed` を先、`pre-existing` を後**。それぞれの中では Violation → Improvement → Question の順。各 finding には `pre-existing` かどうかを明示して提示する (ユーザーが「今回の commit に混ぜるか」を判断する材料になるため)。件数が少なければ 1 回の `AskUserQuestion` に複数 question をまとめてよい (各 finding には前提説明を添える)。
@@ -184,6 +184,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
184
184
  処理が一巡したら、最後にユーザーへ箇条書きでサマリ報告する。
185
185
 
186
186
  - 対象ファイル数と、その決め方 (`git diff HEAD` の変更ファイル / PR / commit range / path 指定のどれか) を冒頭に明示
187
+ - [Shinaps規約の取得](../../references/rules.md) の「照合結果に書くこと」
187
188
  - 実際の担当数・バッチ数と各担当の finding 件数、照合済みファイル数、非該当・未完了のファイルと理由
188
189
  - 検出 / 処理した finding の総数と内訳 (自動修正 X 件 / 確認の上修正 Y 件 / 許容 Z 件 / rule 更新 W 件 / 後回し V 件)
189
190
  - **`changed` と `pre-existing` の内訳** (既存箇所の指摘が何件あり、そのうち何件を今回直したか。今回の変更に無関係な修正がどれだけ混ざったかをユーザーが把握できるように)
@@ -201,4 +202,4 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
201
202
  - **Agent への rule 受け渡しは full text**。id + title だけを渡して agent 側に再取得させると shinaps MCP を N 回呼ぶことになるため無駄。メインスレッドが 1 度取得したものを prompt に貼る
202
203
  - **根拠を確認する**: 担当は渡された規約と対象全体を照合し、規約や docs の根拠がある指摘だけを返す
203
204
  - finding 同士が重複していたら Step 4 の集約で統合する (「同じファイルで console.log 3 件、まとめて削除しますか?」等)
204
- - 規約が 0 件 (= `filterUserRulesByLabels` を指定しない `search_rules` の一覧でも userRules / officialRules が空) のとき: 「rule が登録されていません。今日の作業で rule 化したい習慣はありますか?」と逆に質問して、[Shinaps規約の書き方](../../references/rule-writing.md) に従う `record_rule` を引き出すきっかけにする (この場合 Step 2-4 はスキップ)
205
+ - 照合する規約が無いときは Step 2-4 を省き、公式ルールの未照合を報告する。`filterUserRulesByLabels` なしの一覧で userRules が 0 件と確認できたときに限り、個人ルールが未登録であることも伝え、[Shinaps規約の書き方](../../references/rule-writing.md) に従う `record_rule` を希望するか質問する
package/plugins/shinaps-claude/skills/review/SKILL.md CHANGED
@@ -75,7 +75,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
75
75
 
76
76
  #### 前準備 (メインスレッド)
77
77
 
78
- [Shinaps規約の取得](../../references/rules.md) に従い、対象ファイルから確認した技術の facet と `filterUserRulesByLabels: true` で一覧を取って必要な規約全文を取得する。
78
+ [Shinaps規約の取得](../../references/rules.md) に従い、対象ファイルについて規約全文を取得する。同じ手順の「照合結果に書くこと」をレビュー結果に含める。
79
79
 
80
80
  #### shinaps-reviewer プロンプト
81
81
 
package/plugins/shinaps-codex/.codex-plugin/plugin.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "shinaps",
3
- "version": "0.41.0",
3
+ "version": "0.43.0",
4
4
  "description": "Shinaps AIのCodex向け開発ワークフロー",
5
5
  "skills": "./skills/"
6
6
  }
package/plugins/shinaps-codex/references/linear/configuration.md CHANGED
@@ -4,7 +4,7 @@
4
4
 
5
5
  ## 検証CLIと契約版
6
6
 
7
- 利用中のskillとCLIの版を確認し、0.41.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.41.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
7
+ 利用中のskillとCLIの版を確認し、0.43.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.43.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
8
8
 
9
9
  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にする。
10
10
 
package/plugins/shinaps-codex/references/rule-writing.md CHANGED
@@ -4,7 +4,35 @@ Shinaps AIへ個人規約を登録・更新するときの書き方。短さそ
4
4
 
5
5
  ## 1件1判断
6
6
 
7
- 1件には1つの判断だけを書く。別々に適用・変更できる判断は分ける。登録の前に[Shinaps規約の取得](rules.md)で既存の規約を確かめ、同じ判断があれば新規に増やさず更新を検討する。
7
+ 1件には1つの判断だけを書く。別々に適用・変更できる判断は分ける。
8
+
9
+ ## 書き込む前に既存の規約と比べる
10
+
11
+ `record_rule`・`record_rules`・`update_rule` の前に、書き込む全文（scope・labelを含み、更新では更新後の全文）を既存の規約の全文と比べる。比べるのは呼出し元のAIで、類似度の点数は作らない。既存の規約は[Shinaps規約の取得](rules.md)の「書き込む前に取得する」で取得する。全文や範囲が変わったら比べ直す。
12
+
13
+ 比べるのは次の2つ。
14
+
15
+ - **判断**: 適用条件・求める行動・例外・強さ（強制か推奨か）。文面が違っても全て同じなら同じ判断で、文面が似ていても一つ違えば別の判断とする。適用条件の広さの違いは判断の違いに数えず、範囲で比べる。
16
+ - **範囲**: scope・技術のlabel・公式規約の版の条件・適用条件の広さ。
17
+
18
+ 候補ごとに読んだ既存の規約の全てを見て、次の順で最初に当てはまる結果にする。公式規約は読むだけで、書き込み先にしない。
19
+
20
+ 1. **提示**: 同じ場面で既存の規約と両方には従えない、候補に従うと既存の規約の例外や強さが意味を持たなくなる、更新先を一つに決められない、または結果を判断できない。
21
+ 2. **書かない**: 同じ判断で範囲が候補を含む既存の規約があり、候補に加える情報が無い（言い換えは情報に数えない）。または、同じ判断で範囲が候補を含むのが公式規約だけである（補足があれば報告する）。
22
+ 3. **提示**: 取得が未完了である。「重複なし」とせず、未取得の範囲を示す。
23
+ 4. **更新**: 同じ判断で範囲が候補を含む個人規約があり、候補の補足（理由・例・出典）が判断を変えず、その規約の範囲全体に当てはまる。判断・範囲・kindは変えない。
24
+ 5. **提示**: 同じ判断の個人規約と範囲が重なるが候補を含まない、または補足がその規約の範囲の一部にしか当てはまらない。
25
+ 6. **新規**: それ以外。別の判断で既存の規約と両立するもの、公式規約より範囲が広い同じ判断を含む。
26
+
27
+ `update_rule` の依頼では更新対象自身を比較の相手から外し、他の規約で1〜3に当たらなければ結果を更新とする。当たるときは結果を提示とし、更新対象を変えず、更新前の全文のまま残ることを示す。更新対象の削除や他の規約との統合は、利用者が選んだときだけ行う。判断や範囲を変える更新は、更新前後の全文の差分と範囲の変化を示して同意を受ける。
28
+
29
+ 同じ作業で保存前の候補同士は、範囲が広い方（決まらなければ先の候補）を既存の規約とみなして同じ順で比べる。結果が提示なら両方を提示する。更新は相手の候補の下書きへ補足を足すことで、`update_rule` は呼ばず、許可は相手の候補の結果で判断する。書かないと更新は、相手の候補が保存されたときに確定する。相手の全文が変わる、または書かれないときは、書かないまたは更新とした候補を比べ直す。範囲は足し合わせず、呼出しのscopeに揃えるために候補のscopeを変えない。
30
+
31
+ 提示では候補と既存の規約の全文の違い、推奨する結果と理由、その候補を相手とした他の候補を示し、利用者の判断を受ける。提示した全文のまま利用者が選んだ操作は、比べ直さずに書く。同じtitleの既存があるなどで書けなかった候補も提示する。
32
+
33
+ 比較の結果は書き込みの許可にならない。更新・新規は結果が許可された操作・対象と一致するときだけ書き、違えば書かずに提示する。比べた他の規約は変更しない。
34
+
35
+ 結果は候補ごとに、比べた既存の規約のidまたは相手の候補、未確定ならその旨、取得の条件、未完了の範囲と返らない範囲を添えて報告する。
8
36
 
9
37
  ## 項目の役割
10
38
 
package/plugins/shinaps-codex/references/rules.md CHANGED
@@ -1,50 +1,82 @@
1
1
  # Shinaps規約の取得
2
2
 
3
- Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メイン）だけが行い、担当へは全文を渡す。保存できる規約は必ず1応答に収まり、1応答は100件かつ32,000 bytes（MCPのcontent textのUTF-8）までに分かれるので、下の手順で全件を辿る。
3
+ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メイン）だけが行い、担当へは全文を渡す。保存できる規約は必ず1応答に収まり、1応答は100件かつ32,000 bytes（MCPのcontent textのUTF-8）までに分かれるので、下の順に全件を辿る。
4
4
 
5
- ## 一覧を取る
5
+ ## 語彙を確認する
6
+
7
+ `list_search_facets` を呼び、`languages`・`platforms`・`frameworks`・`topics` の語彙と `versionTargets` を確かめる。以降で渡すslugと版のtargetは、この応答にあるものだけにする。語彙に無いfacetのslugはエラーにならず、結果が黙って変わる。
8
+
9
+ 件数の確認でfacetを渡さないときは、この節と次の節を省く。
10
+
11
+ ## 対象の技術を選ぶ
6
12
 
7
- `list_search_facets` で語彙と `versionTargets` を確認し、`search_rules` を `fields: "summary"` で呼ぶ。
13
+ 対象ファイルが確定した照合（`refine`・`review`）は、ファイルごとに `languages`・`platforms`・`frameworks` の各軸を「確定（slugの集合。空でもよい）」か「不明」に判定する。
8
14
 
9
- - `repoOwner`・`repoName` は現在のGit workspaceから渡す。facetを1つも渡さないと公式ルールは返らない。
10
- - `projectVersions` にはmanifest・lockfile・compiler config・deployment targetから確認できた版だけを渡す。確認できないときは省き、条件付きの公式ルールが除外されて共通ルールだけの照合になったことを結果に書く。
11
- - `nextCursor` がnullになるまで、他の入力を変えず `cursor` に渡して続きを取得する。途中で止めた範囲は未取得として扱う。
15
+ **確定と言えるのは、そのファイルに当てはまる規約のその軸のlabelが、必ずその集合に入るときだけ。** サーバーは指定した軸のどれか1つでも不一致の規約を除くので、この条件が満たせない軸は不明にする。
12
16
 
13
- ## 個人規約を対象ファイルの技術で絞る
17
+ - **framework**: 対象が動くパッケージのコードが実行時に使う技術の和にする（対象がライブラリなら利用側のパッケージも含める）。対象は呼出元の文脈でも動くので、直接importしない技術の規約も当てはまる。workspaceパッケージは公開入口まで辿り（再公開に注意する）、書かれないimportやフレームワークが内包する技術（JSX、Nextのreactなど）も含める。型だけのimportは辿らず、manifestにあるだけの依存は入れない。実行時の利用側を確認できないパッケージ（型だけのパッケージ、外部へ公開するライブラリ）は不明にする。
18
+ - **language**: TypeScriptとJavaScriptのコードは `typescript` と `javascript` の両方にする（片方のlabelの規約がもう片方にも当てはまる）。
19
+ - **platform**: 使うAPIではなく実行環境で判定する。配備先のentryから読み込まれるコードはそのslugにする。ブラウザだけで動くコードは空にする。
20
+ - **設定・生成物・スタイル**（`wrangler.jsonc`、`tsconfig.json`、migration、CSSなど）: 対象のパッケージのコードと同じ値にする。配備設定のplatformは配備先のslugにする。**文書**は全軸を空にする。
21
+ - **語彙外の技術**: 語彙のslugと同じ役割なら不明にする（Prisma、Kotlin、Android、Nodeのサーバー、フレームワークなしのサーバー実装、生SQLなど。類似のslugで置き換えない）。役割が重ならない補助ライブラリは数えない。
22
+ - 辿っていない・確かめられない軸は不明にする。
23
+
24
+ **合成**: 全ファイルが確定で、和が1〜8件の軸だけを検索に渡す。不明なファイルがある軸と9件以上の軸は省略する。和が空の軸は検索で表せないので、全文の選択で使う。
25
+
26
+ 対象が確定していない工程（devの入口・`spec`・`explore`・`debug`）は、論点の技術を語彙から推定してよい。`filterUserRulesByLabels` は指定しない。
27
+
28
+ ## 一覧を取る
14
29
 
15
- 対象ファイルが確定した照合（`refine`・`review`）では、`search_rules` に `filterUserRulesByLabels: true` を渡し、対象の技術と明確に異なる個人規約を一覧から除く。それ以外（devの入口・`spec`・`explore`・`debug`、既存規約との重複の確認）では指定しない。対象ファイルの技術が増えたら取り直す。
30
+ `search_rules` を `fields: "summary"` で呼ぶ。`repoOwner`・`repoName` は現在のGit workspaceから渡す。対象が確定した照合では `filterUserRulesByLabels: true` を渡す。
16
31
 
17
32
  ```json
18
- { "fields": "summary", "repoOwner": "...", "repoName": "...", "languages": ["typescript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
33
+ { "fields": "summary", "repoOwner": "...", "repoName": "...", "languages": ["typescript", "javascript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
19
34
  ```
20
35
 
21
- サーバーは同じ軸をOR、指定した軸の間をANDで判定する。未指定の軸、規約にlabelが無い軸、topic、未知・別軸・無効なslugを含む軸、無効なlabelしかない軸では除外しない。除外の判定に使う語彙は `list_search_facets` が返すものだけ。
22
-
23
- - 渡すのは、対象が使う技術そのものか、その別名か、実際の依存・基盤として使うことを確認できたslugだけにする。確認には対象ファイルの内容・パスと、そのファイルが属するパッケージの設定（manifest・`wrangler.jsonc` など）を使う。manifestにあるだけの依存は、そのファイルで使うと確認できなければ渡さない。リポジトリ全体の技術を一つのファイルに流用しない。同じ役割や類似の技術のslugに置き換えない。
24
- - 複数のファイルは全ファイルの技術の和を渡す。1ファイルでも不明な技術や語彙外の技術があり、確認できたslugでは表しきれない軸は省略する。8件を超える軸も省略する。Markdownや一般の設定ファイルのように技術を持たないファイルは不明に数えない。
25
- - facetは公式ルールの検索と共有する。軸を省略すると、その軸で絞られなくなるので公式ルールの件数も増える。全ての軸を省略して `topics` も無ければ公式ルールは空なので、公式ルールは未照合と報告するか、`topics` を渡す。
26
- - 件数で規約の登録の有無を判断するときは、この指定なしの結果を使う。
27
- - サーバーが除外した規約のidは返らないので、照合結果には指定したfacetと `filterUserRulesByLabels: true` を書く。
36
+ - サーバーは同じ軸をOR、指定した軸の間をANDで判定する。
37
+ - `nextCursor` がnullになるまで、他の入力を変えず `cursor` に渡す。途中で止めた範囲は未取得として扱う。
38
+ - **渡せる軸が無いと公式ルールは0件で返り、照合したことにならない。** 不明なファイルを除いて選び直し、`filterUserRulesByLabels` なしで取得する（個人規約は全件返る）。除いたファイルの公式ルールは未照合になる。それでも渡せる軸が無ければ、全ての公式ルールが未照合になる。`topics` は一致必須なので、渡すと部分的な照合になる。
39
+ - **版**: 対象が使う技術のうち `versionTargets` にあるものは、lockfile・compiler config・deployment target、または完全固定のmanifestで確定した版を `projectVersions` に渡す（`^19` のような範囲は渡さない）。渡していないtargetの条件付き公式ルールは全て除外される。同じtargetで対象ごとに版が違うなら、対象を分けて取得してidの和を取る。`VERSION_TARGET_NOT_FOUND` は全体の失敗なので、targetを直して先頭から取り直す。
40
+ - 対象ファイルの技術が増えたら取り直す。件数で規約の登録の有無を判断するときは、`filterUserRulesByLabels` なしの結果を使う。既存規約との重複は「書き込む前に取得する」で確かめる。
28
41
 
29
42
  ## 全文を取る規約を選ぶ
30
43
 
31
44
  一覧は全文を選ぶためのものであり、一覧だけで規約を満たした、または非該当と判断しない。
32
45
 
33
- - 除外できるのは、labelの language・platform・framework が対象と明確に異なる規約だけ。その軸のlabelが無い規約は軸に依存しない規約として残す。slugの種類は `list_search_facets` で確かめる。
34
- - titleとtopicでは除外しない。判断できない規約は全文を取得する。
46
+ - 除外できるのは、全ファイルが確定で和が空の軸にlabelを持つ規約だけ（ブラウザだけで動くコードと `cloudflare-workers` など）。labelの軸は `list_search_facets` で確かめる。
47
+ - titleとtopicでは除外しない。
35
48
  - 除外した規約はidと理由を記録する。
36
49
 
37
50
  ## 全文を取る
38
51
 
39
52
  選んだidを100件までに分けて `get_rules` へ渡す。
40
53
 
41
- - `remainingIds` が空になるまで、そのまま `ids` に渡して続きを取得する。
54
+ - `remainingIds` が空になるまで、そのまま `ids` に渡して続きを取得してから、次のidへ進む。1応答の大きさの上限があるので、100件より少なく返ることが多い。
42
55
  - `notFoundIds` は削除済みまたは参照できない規約なので、idを記録して照合の対象から外す。
43
56
  - 全件が必要と分かっているときは、`search_rules` の `fields: "full"` を `nextCursor` がnullになるまで辿ってもよい。
44
57
  - `RATE_LIMITED` は短い時間を置いて、同じ `cursor` または `remainingIds` から再開する。
45
58
 
59
+ ## 書き込む前に取得する
60
+
61
+ [Shinaps規約の書き方](rule-writing.md)の比較に使う規約は、次の条件で取得する。
62
+
63
+ - `search_rules` は `fields: "summary"` で全ページ取得し、`filterUserRulesByLabels` と `kind` を渡さない。`repoOwner`・`repoName` は、登録先のowner・repoがあればその値、無い分は現在のGit workspaceの値にする。
64
+ - 公式規約も一覧に載るよう、`list_search_facets` の語彙が8件以内の技術軸（`languages` など）を一つ選び、その全slugを渡す。技術軸はその軸のlabelが無い公式規約にも一致する。`topics` は一致必須で別のtopicの公式規約が返らなくなるので渡さない。渡せる軸が無ければ公式規約の取得は未完了とする。
65
+ - `projectVersions` には確定した版だけを渡す。渡しても渡さなくても、条件に合わない条件付きの公式規約は返らない。
66
+ - 一覧のtitleとlabelから同じ場面を扱う可能性を否定できない規約を選び、「全文を取る」で全文を取得する。文字列の一致で選ばない（公式規約のtitleは英語）。「全文を取る規約を選ぶ」は対象ファイルとの照合の基準で、ここには適用しない。
67
+ - 同じ条件の結果は、規約を書き込むまでの間、候補の間で再利用してよい。他の工程で `filterUserRulesByLabels`・`kind`・`topics` を使って絞った結果は使わない。
68
+
69
+ 選んだ条件の一覧と選んだ全文を読み終えていなければ未完了とする。他のリポジトリ・ownerの個人規約と版の条件で除かれた公式規約は検索で返らない範囲で、未完了に数えずに報告する。どちらの場合も「全体に重複が無い」とは言わない。
70
+
46
71
  ## 担当へ渡す
47
72
 
48
73
  全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
49
74
 
50
- 取得・受渡し・読了のいずれかが終わらなかった規約は、idまたは条件を挙げて未照合と報告し、照合済みにしない。
75
+ ## 照合結果に書くこと
76
+
77
+ - 渡した全てのfacet・`projectVersions`・`filterUserRulesByLabels`。サーバーが除外した規約のidは返らないので、除外の条件として残す。
78
+ - 全文の選択で除外した規約のidと理由、`notFoundIds`。
79
+ - 省略した軸・版と理由、未照合になった公式ルールの範囲。
80
+ - 取得・受渡し・読了のいずれかが終わらなかった規約のidまたは条件。これらは照合済みにしない。
81
+
82
+ この手順は判定の基準を示すが、規約の漏れが無いことの証明にはならない。「漏れなし」と報告しない。
package/plugins/shinaps-codex/skills/extract-rules/SKILL.md CHANGED
@@ -9,8 +9,8 @@ description: GitHubの過去PRレビューから繰り返し適用できる規
9
9
 
10
10
  1. `gh`で期間内のマージ済みPRを取得する。ページングし、並び順と日付フィルターの関係を守る。更新日時順の一覧で古いマージ日時を一件見つけても、それ以降の取得を打ち切らない。
11
11
  2. PRのreview本文・inline comment・conversation commentを取得する。PR descriptionはレビュー指摘として扱わない。APIのBot種別は除外し、判断が必要な投稿者は確認する。認証情報やリポジトリ全体をサービスへ送信しない。
12
- 3. [Shinaps規約の取得](../../references/rules.md)に従って既存ルールの一覧を全ページ取得する。候補ごとに、titleかlabelが重なるルールの全文を確かめ、判断できなければ全文を取得する。複数のレビューで繰り返され、適用条件とWHYが説明できる規約を候補にする。根拠のない例・URLを作らず、レビューコメントの出典を付ける。
13
- 4. 新規候補だけを[Shinaps規約の書き方](../../references/rule-writing.md)に従って書き、対象repoのスコープへ、実際のMCPツールのスキーマに従って登録する。応答は入力の位置とidだけなので、重複して投入されなかった候補は入力からtitleを得て、idで全文を取得して差分を確かめる。全プロジェクト共通へ広げる場合は利用者の判断を確認する。既存ルールの変更は差分を提示して許可を得る。`RULE_TOO_LARGE`はその呼出し分が全体として保存されなかったことを示すので、details の limit・actual・titleを確かめ、該当候補を短くしてやり直す。更新の`RULE_UPDATE_CONFLICT`は全文を読み直して再試行する。`RULE_LIMIT_REACHED`は残りの枠が足りずその呼出し分が全体として保存されなかったことを示すので、一部だけを登録する手順へ切り替えずに止め、details の limit・actualを示して、件数を絞るか既存ルールを整理するかを利用者に確認する。それより前の呼出しで投入した分は保存されている。以降のまとまりの抽出・投入にも進まず、利用者の選択を待つ。
12
+ 3. 複数のレビューで繰り返され、適用条件とWHYが説明できる規約を候補にする。根拠のない例・URLを作らず、レビューコメントの出典を付ける。
13
+ 4. 候補を[Shinaps規約の書き方](../../references/rule-writing.md)に従って書き、同じ文書の「書き込む前に既存の規約と比べる」で候補ごとに結果を決める。提示の候補はまとまりの終わりに示し、残りの投入は止めない。新規の候補だけを対象repoのスコープへ、実際のMCPツールのスキーマに従って登録する。応答は入力の位置とidだけなので、重複して投入されなかった候補は入力からtitleを得て、上書きせず提示へ進める。全プロジェクト共通へ広げる場合は利用者の判断を確認し、書き直した全文で比べ直す。既存の規約への更新の候補は差分を提示して許可を得る。`RULE_TOO_LARGE`はその呼出し分が全体として保存されなかったことを示すので、details の limit・actual・titleを確かめ、該当候補を短くしてやり直す。更新の`RULE_UPDATE_CONFLICT`は全文を読み直して再試行する。`RULE_LIMIT_REACHED`は残りの枠が足りずその呼出し分が全体として保存されなかったことを示すので、一部だけを登録する手順へ切り替えずに止め、details の limit・actualを示して、件数を絞るか既存ルールを整理するかを利用者に確認する。それより前の呼出しで投入した分は保存されている。以降のまとまりの抽出・投入にも進まず、利用者の選択を待つ。
14
14
  5. 大量処理は100 PR程度のまとまりで結果を報告し、継続範囲を確認する。結果が不明な保存失敗では再投入の前に読み戻し、重複を避ける。`RATE_LIMITED`は制限の時間枠が切り替わるまで待ってから1回だけ再試行し、続けて拒否されたら中断して報告する。
15
15
 
16
- 終了時は処理したPR・コメント数、新規登録・更新・除外・未処理の件数と根拠を示す。取得・保存が部分的ならその範囲を明記する。記録する場合は.shinaps/work/を使い、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。
16
+ 終了時は処理したPR・コメント数、新規登録・更新・書かない・提示・除外・未処理の件数と根拠を示す。取得・保存が部分的ならその範囲を明記する。記録する場合は.shinaps/work/を使い、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。
package/plugins/shinaps-codex/skills/refine/SKILL.md CHANGED
@@ -5,10 +5,10 @@ description: 対象ファイルとShinaps AIのルールを照合し、違反・
5
5
 
6
6
  # ルール照合
7
7
 
8
- 指定されたパス・PR・コミット範囲から対象を決める。作業中の変更ならstaged、unstaged、関連するuntrackedを含める。適用されるプロジェクトの指示を読み、[Shinaps規約の取得](../../references/rules.md)に従って、対象ファイルの技術と `filterUserRulesByLabels: true` で対象に合うルールの全文を取得する。MCPが使えない場合は照合を実施できないと報告し、推測でルールを作らない。アカウント作成・接続は利用者の標準認証フローを案内する。
8
+ 指定されたパス・PR・コミット範囲から対象を決める。作業中の変更ならstaged、unstaged、関連するuntrackedを含める。適用されるプロジェクトの指示を読み、[Shinaps規約の取得](../../references/rules.md)に従って、対象ファイルについて規約全文を取得する。MCPが使えない場合は照合を実施できないと報告し、推測でルールを作らない。アカウント作成・接続は利用者の標準認証フローを案内する。
9
9
 
10
10
  対象ファイルの現状全文を読み、ルールごとに適用条件と実際のコードを比較する。指摘には根拠となるルール、該当箇所、影響と修正案を付ける。違反・改善・仕様判断を区別し、今回の変更と元からある問題を分ける。テストに関わる指摘と修正の判断は [テスト方針](../../references/testing.md) に従う。
11
11
 
12
12
  委託を許可されている場合は登録済みのshinaps-refine-agentへ重ならない範囲とルール全文を渡せる。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。結果は現在のコードで検証し重複をまとめる。独立検証をしなければそのように報告する。
13
13
 
14
- 修正が依頼範囲に含まれる場合、今回の変更の自明な修正を適用し、必要な検証を行う。既存箇所や仕様に関係する判断は一問ずつ確認する。ルール自体の書き換え・外部Issueの作成を無断で行わない。ルールの書き換えが許可されたら[Shinaps規約の書き方](../../references/rule-writing.md)に従う。未処理事項を残し、照合結果と未確認を報告する。
14
+ 修正が依頼範囲に含まれる場合、今回の変更の自明な修正を適用し、必要な検証を行う。既存箇所や仕様に関係する判断は一問ずつ確認する。ルール自体の書き換え・外部Issueの作成を無断で行わない。ルールの書き換えが許可されたら[Shinaps規約の書き方](../../references/rule-writing.md)に従って全文を作り、同じ文書の「書き込む前に既存の規約と比べる」で比べる（照合用に対象の技術で絞った結果は使わない）。結果と全文の差分を示して同意を受けてから書き込む。未処理事項を残し、照合結果と未確認、[Shinaps規約の取得](../../references/rules.md)の「照合結果に書くこと」を報告する。
package/plugins/shinaps-codex/skills/review/SKILL.md CHANGED
@@ -12,7 +12,7 @@ description: 差分・PR・指定コードを根拠付きでレビューする
12
12
 
13
13
  対象プロジェクトのAGENTS.md、既存設計、依頼範囲を確認する。作業ツリーをレビューする場合はステージ済み・未ステージ・未追跡の関連変更を含める。PRやブランチを指定された場合はその比較範囲を使う。
14
14
 
15
- Shinaps AIのルール検索が利用できる場合は[Shinaps規約の取得](../../references/rules.md)に従って、対象ファイルの技術と `filterUserRulesByLabels: true` で関連するルールを取得し、指摘の根拠に含める。利用できない場合はルール照合が未確認であることを報告する。コード自体のレビューは続けられる。
15
+ Shinaps AIのルール検索が利用できる場合は[Shinaps規約の取得](../../references/rules.md)に従って、対象ファイルについて規約全文を取得し、指摘の根拠に含める。同じ手順の「照合結果に書くこと」を報告する。利用できない場合はルール照合が未確認であることを報告する。コード自体のレビューは続けられる。
16
16
 
17
17
  委託が許可され、shinaps-reviewerが登録されている場合は、対象・差分・背景・取得済みルールを渡してレビューを依頼する。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。利用できない場合は現在のセッションで同じ観点を確認し、独立レビューとは報告しない。エージェントの追加委託やworktree作成を暗黙に許可しない。
18
18