@shinaps/skills 0.40.0 → 0.42.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 (13) 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/rules.md +45 -9
  6. package/plugins/shinaps-claude/skills/debug/SKILL.md +1 -1
  7. package/plugins/shinaps-claude/skills/refine/SKILL.md +6 -5
  8. package/plugins/shinaps-claude/skills/review/SKILL.md +1 -1
  9. package/plugins/shinaps-codex/.codex-plugin/plugin.json +1 -1
  10. package/plugins/shinaps-codex/references/linear/configuration.md +1 -1
  11. package/plugins/shinaps-codex/references/rules.md +45 -9
  12. package/plugins/shinaps-codex/skills/refine/SKILL.md +2 -2
  13. 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.40.0
29
+ npm install -g @shinaps/skills@0.42.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.40.0",
3
+ "version": "0.42.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.40.0",
4
+ "version": "0.42.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.40.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.40.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
7
+ 利用中のskillとCLIの版を確認し、0.42.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.42.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/rules.md CHANGED
@@ -1,28 +1,57 @@
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
+
5
+ ## 語彙を確認する
6
+
7
+ `list_search_facets` を呼び、`languages`・`platforms`・`frameworks`・`topics` の語彙と `versionTargets` を確かめる。以降で渡すslugと版のtargetは、この応答にあるものだけにする。語彙に無いfacetのslugはエラーにならず、結果が黙って変わる。
8
+
9
+ 重複や件数の確認でfacetを渡さないときは、この節と次の節を省く。
10
+
11
+ ## 対象の技術を選ぶ
12
+
13
+ 対象ファイルが確定した照合（`refine`・`review`）は、ファイルごとに `languages`・`platforms`・`frameworks` の各軸を「確定（slugの集合。空でもよい）」か「不明」に判定する。
14
+
15
+ **確定と言えるのは、そのファイルに当てはまる規約のその軸のlabelが、必ずその集合に入るときだけ。** サーバーは指定した軸のどれか1つでも不一致の規約を除くので、この条件が満たせない軸は不明にする。
16
+
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` は指定しない。
4
27
 
5
28
  ## 一覧を取る
6
29
 
7
- `list_search_facets` で語彙と `versionTargets` を確認し、`search_rules` を `fields: "summary"` で呼ぶ。
30
+ `search_rules` を `fields: "summary"` で呼ぶ。`repoOwner`・`repoName` は現在のGit workspaceから渡す。対象が確定した照合では `filterUserRulesByLabels: true` を渡す。
8
31
 
9
- - `repoOwner`・`repoName` は現在のGit workspaceから渡す。facetを1つも渡さないと公式ルールは返らない。
10
- - `projectVersions` にはmanifest・lockfile・compiler config・deployment targetから確認できた版だけを渡す。確認できないときは省き、条件付きの公式ルールが除外されて共通ルールだけの照合になったことを結果に書く。
11
- - `nextCursor` がnullになるまで、他の入力を変えず `cursor` に渡して続きを取得する。途中で止めた範囲は未取得として扱う。
32
+ ```json
33
+ { "fields": "summary", "repoOwner": "...", "repoName": "...", "languages": ["typescript", "javascript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
34
+ ```
35
+
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` なしの結果を使う。
12
41
 
13
42
  ## 全文を取る規約を選ぶ
14
43
 
15
44
  一覧は全文を選ぶためのものであり、一覧だけで規約を満たした、または非該当と判断しない。
16
45
 
17
- - 除外できるのは、labelの language・platform・framework が対象と明確に異なる規約だけ。その軸のlabelが無い規約は軸に依存しない規約として残す。slugの種類は `list_search_facets` で確かめる。
18
- - titleとtopicでは除外しない。判断できない規約は全文を取得する。
46
+ - 除外できるのは、全ファイルが確定で和が空の軸にlabelを持つ規約だけ（ブラウザだけで動くコードと `cloudflare-workers` など）。labelの軸は `list_search_facets` で確かめる。
47
+ - titleとtopicでは除外しない。
19
48
  - 除外した規約はidと理由を記録する。
20
49
 
21
50
  ## 全文を取る
22
51
 
23
52
  選んだidを100件までに分けて `get_rules` へ渡す。
24
53
 
25
- - `remainingIds` が空になるまで、そのまま `ids` に渡して続きを取得する。
54
+ - `remainingIds` が空になるまで、そのまま `ids` に渡して続きを取得してから、次のidへ進む。1応答の大きさの上限があるので、100件より少なく返ることが多い。
26
55
  - `notFoundIds` は削除済みまたは参照できない規約なので、idを記録して照合の対象から外す。
27
56
  - 全件が必要と分かっているときは、`search_rules` の `fields: "full"` を `nextCursor` がnullになるまで辿ってもよい。
28
57
  - `RATE_LIMITED` は短い時間を置いて、同じ `cursor` または `remainingIds` から再開する。
@@ -31,4 +60,11 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
31
60
 
32
61
  全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
33
62
 
34
- 取得・受渡し・読了のいずれかが終わらなかった規約は、idまたは条件を挙げて未照合と報告し、照合済みにしない。
63
+ ## 照合結果に書くこと
64
+
65
+ - 渡した全てのfacet・`projectVersions`・`filterUserRulesByLabels`。サーバーが除外した規約のidは返らないので、除外の条件として残す。
66
+ - 全文の選択で除外した規約のidと理由、`notFoundIds`。
67
+ - 省略した軸・版と理由、未照合になった公式ルールの範囲。
68
+ - 取得・受渡し・読了のいずれかが終わらなかった規約のidまたは条件。これらは照合済みにしない。
69
+
70
+ この手順は判定の基準を示すが、規約の漏れが無いことの証明にはならない。「漏れなし」と報告しない。
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/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) を取得 → 対象ファイルの拡張子・パス・内容から関係する facet slug を推定して確定
61
- - [Shinaps規約の取得](../../references/rules.md) に従って規約全文を取得する (`search_rules` の `fields: "summary"` を全ページ → `get_rules`)。userRules と officialRules の両方を照合対象にする。userRules は facet に関係なく 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 で代替可)
@@ -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 件 (= `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 で一覧を取って必要な規約全文を取得する。
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.40.0",
3
+ "version": "0.42.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.40.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.40.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
7
+ 利用中のskillとCLIの版を確認し、0.42.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.42.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/rules.md CHANGED
@@ -1,28 +1,57 @@
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
+
5
+ ## 語彙を確認する
6
+
7
+ `list_search_facets` を呼び、`languages`・`platforms`・`frameworks`・`topics` の語彙と `versionTargets` を確かめる。以降で渡すslugと版のtargetは、この応答にあるものだけにする。語彙に無いfacetのslugはエラーにならず、結果が黙って変わる。
8
+
9
+ 重複や件数の確認でfacetを渡さないときは、この節と次の節を省く。
10
+
11
+ ## 対象の技術を選ぶ
12
+
13
+ 対象ファイルが確定した照合（`refine`・`review`）は、ファイルごとに `languages`・`platforms`・`frameworks` の各軸を「確定（slugの集合。空でもよい）」か「不明」に判定する。
14
+
15
+ **確定と言えるのは、そのファイルに当てはまる規約のその軸のlabelが、必ずその集合に入るときだけ。** サーバーは指定した軸のどれか1つでも不一致の規約を除くので、この条件が満たせない軸は不明にする。
16
+
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` は指定しない。
4
27
 
5
28
  ## 一覧を取る
6
29
 
7
- `list_search_facets` で語彙と `versionTargets` を確認し、`search_rules` を `fields: "summary"` で呼ぶ。
30
+ `search_rules` を `fields: "summary"` で呼ぶ。`repoOwner`・`repoName` は現在のGit workspaceから渡す。対象が確定した照合では `filterUserRulesByLabels: true` を渡す。
8
31
 
9
- - `repoOwner`・`repoName` は現在のGit workspaceから渡す。facetを1つも渡さないと公式ルールは返らない。
10
- - `projectVersions` にはmanifest・lockfile・compiler config・deployment targetから確認できた版だけを渡す。確認できないときは省き、条件付きの公式ルールが除外されて共通ルールだけの照合になったことを結果に書く。
11
- - `nextCursor` がnullになるまで、他の入力を変えず `cursor` に渡して続きを取得する。途中で止めた範囲は未取得として扱う。
32
+ ```json
33
+ { "fields": "summary", "repoOwner": "...", "repoName": "...", "languages": ["typescript", "javascript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
34
+ ```
35
+
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` なしの結果を使う。
12
41
 
13
42
  ## 全文を取る規約を選ぶ
14
43
 
15
44
  一覧は全文を選ぶためのものであり、一覧だけで規約を満たした、または非該当と判断しない。
16
45
 
17
- - 除外できるのは、labelの language・platform・framework が対象と明確に異なる規約だけ。その軸のlabelが無い規約は軸に依存しない規約として残す。slugの種類は `list_search_facets` で確かめる。
18
- - titleとtopicでは除外しない。判断できない規約は全文を取得する。
46
+ - 除外できるのは、全ファイルが確定で和が空の軸にlabelを持つ規約だけ（ブラウザだけで動くコードと `cloudflare-workers` など）。labelの軸は `list_search_facets` で確かめる。
47
+ - titleとtopicでは除外しない。
19
48
  - 除外した規約はidと理由を記録する。
20
49
 
21
50
  ## 全文を取る
22
51
 
23
52
  選んだidを100件までに分けて `get_rules` へ渡す。
24
53
 
25
- - `remainingIds` が空になるまで、そのまま `ids` に渡して続きを取得する。
54
+ - `remainingIds` が空になるまで、そのまま `ids` に渡して続きを取得してから、次のidへ進む。1応答の大きさの上限があるので、100件より少なく返ることが多い。
26
55
  - `notFoundIds` は削除済みまたは参照できない規約なので、idを記録して照合の対象から外す。
27
56
  - 全件が必要と分かっているときは、`search_rules` の `fields: "full"` を `nextCursor` がnullになるまで辿ってもよい。
28
57
  - `RATE_LIMITED` は短い時間を置いて、同じ `cursor` または `remainingIds` から再開する。
@@ -31,4 +60,11 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
31
60
 
32
61
  全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
33
62
 
34
- 取得・受渡し・読了のいずれかが終わらなかった規約は、idまたは条件を挙げて未照合と報告し、照合済みにしない。
63
+ ## 照合結果に書くこと
64
+
65
+ - 渡した全てのfacet・`projectVersions`・`filterUserRulesByLabels`。サーバーが除外した規約のidは返らないので、除外の条件として残す。
66
+ - 全文の選択で除外した規約のidと理由、`notFoundIds`。
67
+ - 省略した軸・版と理由、未照合になった公式ルールの範囲。
68
+ - 取得・受渡し・読了のいずれかが終わらなかった規約のidまたは条件。これらは照合済みにしない。
69
+
70
+ この手順は判定の基準を示すが、規約の漏れが無いことの証明にはならない。「漏れなし」と報告しない。
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)に従って対象に合うルールの全文を取得する。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)に従って関連するルールを取得し、指摘の根拠に含める。利用できない場合はルール照合が未確認であることを報告する。コード自体のレビューは続けられる。
15
+ Shinaps AIのルール検索が利用できる場合は[Shinaps規約の取得](../../references/rules.md)に従って、対象ファイルについて規約全文を取得し、指摘の根拠に含める。同じ手順の「照合結果に書くこと」を報告する。利用できない場合はルール照合が未確認であることを報告する。コード自体のレビューは続けられる。
16
16
 
17
17
  委託が許可され、shinaps-reviewerが登録されている場合は、対象・差分・背景・取得済みルールを渡してレビューを依頼する。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。利用できない場合は現在のセッションで同じ観点を確認し、独立レビューとは報告しない。エージェントの追加委託やworktree作成を暗黙に許可しない。
18
18