@shinaps/skills 0.40.0 → 0.41.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.
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.41.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.41.0",
4
4
  "description": "Install Shinaps AI workflows and custom agents for Codex",
5
5
  "type": "module",
6
6
  "bin": {
@@ -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.41.0",
5
5
  "author": {
6
6
  "name": "shinaps"
7
7
  },
@@ -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.41.0のskillには同じ版のnpm CLIを導入する(`npm install -g @shinaps/skills@0.41.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
 
@@ -10,6 +10,22 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元(メ
10
10
  - `projectVersions` にはmanifest・lockfile・compiler config・deployment targetから確認できた版だけを渡す。確認できないときは省き、条件付きの公式ルールが除外されて共通ルールだけの照合になったことを結果に書く。
11
11
  - `nextCursor` がnullになるまで、他の入力を変えず `cursor` に渡して続きを取得する。途中で止めた範囲は未取得として扱う。
12
12
 
13
+ ## 個人規約を対象ファイルの技術で絞る
14
+
15
+ 対象ファイルが確定した照合(`refine`・`review`)では、`search_rules` に `filterUserRulesByLabels: true` を渡し、対象の技術と明確に異なる個人規約を一覧から除く。それ以外(devの入口・`spec`・`explore`・`debug`、既存規約との重複の確認)では指定しない。対象ファイルの技術が増えたら取り直す。
16
+
17
+ ```json
18
+ { "fields": "summary", "repoOwner": "...", "repoName": "...", "languages": ["typescript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
19
+ ```
20
+
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` を書く。
28
+
13
29
  ## 全文を取る規約を選ぶ
14
30
 
15
31
  一覧は全文を選ぶためのものであり、一覧だけで規約を満たした、または非該当と判断しない。
@@ -57,8 +57,8 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
57
57
 
58
58
  以下を並列で取得:
59
59
 
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 集合と広く照合する用途のため、絞り込むと見落としが増える)
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 で代替可)
@@ -201,4 +201,4 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
201
201
  - **Agent への rule 受け渡しは full text**。id + title だけを渡して agent 側に再取得させると shinaps MCP を N 回呼ぶことになるため無駄。メインスレッドが 1 度取得したものを prompt に貼る
202
202
  - **根拠を確認する**: 担当は渡された規約と対象全体を照合し、規約や docs の根拠がある指摘だけを返す
203
203
  - finding 同士が重複していたら Step 4 の集約で統合する (「同じファイルで console.log 3 件、まとめて削除しますか?」等)
204
- - 規約が 0 件 (= `search_rules` の一覧で userRules / officialRules が空) のとき: 「rule が登録されていません。今日の作業で rule 化したい習慣はありますか?」と逆に質問して、[Shinaps規約の書き方](../../references/rule-writing.md) に従う `record_rule` を引き出すきっかけにする (この場合 Step 2-4 はスキップ)
204
+ - 規約が 0 件 (= `filterUserRulesByLabels` を指定しない `search_rules` の一覧でも userRules / officialRules が空) のとき: 「rule が登録されていません。今日の作業で rule 化したい習慣はありますか?」と逆に質問して、[Shinaps規約の書き方](../../references/rule-writing.md) に従う `record_rule` を引き出すきっかけにする (この場合 Step 2-4 はスキップ)
@@ -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) に従い、対象ファイルから確認した技術の facet と `filterUserRulesByLabels: true` で一覧を取って必要な規約全文を取得する。
79
79
 
80
80
  #### shinaps-reviewer プロンプト
81
81
 
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "shinaps",
3
- "version": "0.40.0",
3
+ "version": "0.41.0",
4
4
  "description": "Shinaps AIのCodex向け開発ワークフロー",
5
5
  "skills": "./skills/"
6
6
  }
@@ -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.41.0のskillには同じ版のnpm CLIを導入する(`npm install -g @shinaps/skills@0.41.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
 
@@ -10,6 +10,22 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元(メ
10
10
  - `projectVersions` にはmanifest・lockfile・compiler config・deployment targetから確認できた版だけを渡す。確認できないときは省き、条件付きの公式ルールが除外されて共通ルールだけの照合になったことを結果に書く。
11
11
  - `nextCursor` がnullになるまで、他の入力を変えず `cursor` に渡して続きを取得する。途中で止めた範囲は未取得として扱う。
12
12
 
13
+ ## 個人規約を対象ファイルの技術で絞る
14
+
15
+ 対象ファイルが確定した照合(`refine`・`review`)では、`search_rules` に `filterUserRulesByLabels: true` を渡し、対象の技術と明確に異なる個人規約を一覧から除く。それ以外(devの入口・`spec`・`explore`・`debug`、既存規約との重複の確認)では指定しない。対象ファイルの技術が増えたら取り直す。
16
+
17
+ ```json
18
+ { "fields": "summary", "repoOwner": "...", "repoName": "...", "languages": ["typescript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
19
+ ```
20
+
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` を書く。
28
+
13
29
  ## 全文を取る規約を選ぶ
14
30
 
15
31
  一覧は全文を選ぶためのものであり、一覧だけで規約を満たした、または非該当と判断しない。
@@ -5,7 +5,7 @@ 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)に従って、対象ファイルの技術と `filterUserRulesByLabels: true` で対象に合うルールの全文を取得する。MCPが使えない場合は照合を実施できないと報告し、推測でルールを作らない。アカウント作成・接続は利用者の標準認証フローを案内する。
9
9
 
10
10
  対象ファイルの現状全文を読み、ルールごとに適用条件と実際のコードを比較する。指摘には根拠となるルール、該当箇所、影響と修正案を付ける。違反・改善・仕様判断を区別し、今回の変更と元からある問題を分ける。テストに関わる指摘と修正の判断は [テスト方針](../../references/testing.md) に従う。
11
11
 
@@ -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)に従って、対象ファイルの技術と `filterUserRulesByLabels: true` で関連するルールを取得し、指摘の根拠に含める。利用できない場合はルール照合が未確認であることを報告する。コード自体のレビューは続けられる。
16
16
 
17
17
  委託が許可され、shinaps-reviewerが登録されている場合は、対象・差分・背景・取得済みルールを渡してレビューを依頼する。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。利用できない場合は現在のセッションで同じ観点を確認し、独立レビューとは報告しない。エージェントの追加委託やworktree作成を暗黙に許可しない。
18
18