@shinaps/skills 0.36.0 → 0.36.1
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/README.md +2 -2
- package/package.json +1 -1
- package/plugins/shinaps-claude/.claude-plugin/plugin.json +1 -1
- package/plugins/shinaps-claude/agents/shinaps-refine-agent.md +2 -2
- package/plugins/shinaps-claude/managed-agents/agents/shinaps-refine-agent.md +2 -2
- package/plugins/shinaps-claude/references/linear/configuration.md +1 -1
- package/plugins/shinaps-claude/skills/extract-rules/SKILL.md +5 -2
- package/plugins/shinaps-claude/skills/refine/SKILL.md +4 -4
- package/plugins/shinaps-codex/.codex-plugin/plugin.json +1 -1
- package/plugins/shinaps-codex/agents/shinaps-refine-agent.toml +2 -2
- package/plugins/shinaps-codex/managed-agents/agents/shinaps-refine-agent.md +2 -2
- package/plugins/shinaps-codex/references/linear/configuration.md +1 -1
- package/plugins/shinaps-codex/skills/extract-rules/SKILL.md +2 -2
package/README.md
CHANGED
|
@@ -18,10 +18,10 @@ sharedで採用する `instructions.md` は共有JSONの `references.specificati
|
|
|
18
18
|
|
|
19
19
|
0.35.0から通常設定の `review_flow.mode` に `ask` を追加しました（パス別ルールは `auto`・`manual` だけ）。既存の設定は変更不要です。
|
|
20
20
|
|
|
21
|
-
CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.36.
|
|
21
|
+
CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.36.1` を導入し、`shinaps-skills --version` で確認します。`shinaps-skills validate-linear-config <明示ファイル>` は同梱schemaだけで検証し、ネットワーク取得・正本探索・Git操作・入力変更は行いません。`$schema` は固定URLによるエディタ補助で、契約の正本は[同梱schema](plugins/shinaps-claude/references/linear/configuration.schema.json)です。0.34.0から、Managed Agentsの `.shinaps/managed.json`（`config_version: 1`）も `shinaps-skills validate-managed-config <明示ファイル>` で同じ方式で検証します（[Managedの設定](plugins/shinaps-claude/references/managed/configuration.md)）。
|
|
22
22
|
|
|
23
23
|
```sh
|
|
24
|
-
npm install -g @shinaps/skills@0.36.
|
|
24
|
+
npm install -g @shinaps/skills@0.36.1
|
|
25
25
|
shinaps-skills --version
|
|
26
26
|
shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
|
|
27
27
|
shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.json
|
package/package.json
CHANGED
|
@@ -9,9 +9,9 @@ color: blue
|
|
|
9
9
|
あなたは dev の入口の実装後レビュー、または `/shinaps:refine` で起動される **rule 照合エージェント** です。
|
|
10
10
|
Skill 側から渡された「rule 全件」と「対象ファイルの現状全文」を **1 件ずつ突き合わせて** 分類し、JSON で返してください。
|
|
11
11
|
|
|
12
|
-
## 絶対原則 (
|
|
12
|
+
## 絶対原則 (MCP の呼出しはメインだけ)
|
|
13
13
|
|
|
14
|
-
**subagent 内で shinaps MCP tool を直接呼ばない**。rule 全文・docs 該当節・repo root・対象ファイル一覧はすべて Skill 側から prompt 経由で渡される。あなたはそれを材料に使うだけ。
|
|
14
|
+
**subagent 内で shinaps MCP tool を直接呼ばない**。rule 全文・docs 該当節・repo root・対象ファイル一覧はすべて Skill 側から prompt 経由で渡される。あなたはそれを材料に使うだけ。subagent が同じ検索を繰り返すと、利用者ごとに共有される短時間の操作の上限を消費し、同じ結果を重ねて取得することになるため。
|
|
15
15
|
|
|
16
16
|
## 対象の取得
|
|
17
17
|
|
|
@@ -17,9 +17,9 @@ tools:
|
|
|
17
17
|
あなたは dev の入口の実装後レビュー、または `/shinaps:refine` で起動される **rule 照合エージェント** です。
|
|
18
18
|
Skill 側から渡された「rule 全件」と「対象ファイルの現状全文」を **1 件ずつ突き合わせて** 分類し、JSON で返してください。
|
|
19
19
|
|
|
20
|
-
## 絶対原則 (
|
|
20
|
+
## 絶対原則 (MCP の呼出しはメインだけ)
|
|
21
21
|
|
|
22
|
-
**subagent 内で shinaps MCP tool を直接呼ばない**。rule 全文・docs 該当節・repo root・対象ファイル一覧はすべて Skill 側から prompt 経由で渡される。あなたはそれを材料に使うだけ。
|
|
22
|
+
**subagent 内で shinaps MCP tool を直接呼ばない**。rule 全文・docs 該当節・repo root・対象ファイル一覧はすべて Skill 側から prompt 経由で渡される。あなたはそれを材料に使うだけ。subagent が同じ検索を繰り返すと、利用者ごとに共有される短時間の操作の上限を消費し、同じ結果を重ねて取得することになるため。
|
|
23
23
|
|
|
24
24
|
## 対象の取得
|
|
25
25
|
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
## 検証CLIと契約版
|
|
6
6
|
|
|
7
|
-
利用中のskillとCLIの版を確認し、0.36.
|
|
7
|
+
利用中のskillとCLIの版を確認し、0.36.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.36.1`）。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
|
|
|
@@ -77,7 +77,7 @@ Good/Bad サンプルコード (examples) の付け方:
|
|
|
77
77
|
|
|
78
78
|
- レビューコメントや diff から Good/Bad ペアを構成できる rule にのみ `examples: { good, bad, language }` を付ける。**素材が無い rule に捏造しない** (プロジェクト固有の識別子を一般名に置換する・最小化する程度の編集は可)
|
|
79
79
|
- good / bad は各 1000 文字以内・5〜15 行目安の短いコード片。language は shiki の言語 id 小文字 (`typescript` / `tsx` / `python` / `go` 等)
|
|
80
|
-
- good / bad / language は 3 つセットでしか登録できない (
|
|
80
|
+
- good / bad / language は 3 つセットでしか登録できない (揃っていないと入力の schema 検証で拒否される)
|
|
81
81
|
|
|
82
82
|
出典 URL (sourceUrls) の付け方:
|
|
83
83
|
|
|
@@ -86,7 +86,9 @@ Good/Bad サンプルコード (examples) の付け方:
|
|
|
86
86
|
|
|
87
87
|
投入手順:
|
|
88
88
|
|
|
89
|
-
- 候補を既存 rules と照合し、**新規** (該当 rule 不在) だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, rules: [{ title, why, recommend?, avoid?, kind?, labels?, examples?, sourceUrls? }, ...] })` で **1 call bulk 投入** する。`labels` は language / platform / framework / topic の slug 配列 (`list_search_facets`
|
|
89
|
+
- 候補を既存 rules と照合し、**新規** (該当 rule 不在) だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, rules: [{ title, why, recommend?, avoid?, kind?, labels?, examples?, sourceUrls? }, ...] })` で **1 call bulk 投入** する。`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 固有の具体的な記述・コード片で良い)。title は 200 字以内、規約本文は why (必須、なぜこの規約か、2000 字以内) / recommend (推奨行動、任意、1000 字以内) / avoid (避けるべきこと、任意、1000 字以内) の 3 フィールドに構造化する
|
|
90
|
+
- `RULE_LIMIT_REACHED` が返ったら投入を止める。個人ルールの保存数には上限があり、残りの枠が足りない `record_rules` はその呼出し分が全体として失敗し、一部も保存されない (件数を減らして一部だけ登録する手順へ自動では切り替えない)。それより前の呼出しで投入した分は保存されている。details の `limit` と `actual` から残りの枠を示し、投入する件数を絞るか既存ルールを整理するかのどちらにするかを利用者に確認する。以降のブロックの抽出・投入にも進まず、利用者の選択を待つ。
|
|
91
|
+
- `RATE_LIMITED` (再試行可能) が返ったら、制限の時間枠が切り替わるまで待ってから、同じ呼出しを1回だけ再試行する。再び拒否されたら、連続して再試行せずに中断し、その状況を利用者に報告する。
|
|
90
92
|
- 戻り値の `skipped: { title, existingRuleId, existingWhy, existingRecommend, existingAvoid, existingLabels, existingExamples, existingSourceUrls }[]` は「既存と title 重複して投入されなかった候補」。新しい why/recommend/avoid と existing* が異なるなら **ユーザーに diff を提示して同意を取る** (examples / sourceUrls の差分も同様):
|
|
91
93
|
|
|
92
94
|
> 既存 rule "no-unused-vars" が見つかりました。why/recommend/avoid の差分:
|
|
@@ -111,3 +113,4 @@ since 期間内の merged PR を消化し終えたら、以下を user に報告
|
|
|
111
113
|
- `record_rules` で新規投入した rule 件数 (inserted 合計) + タイトル一覧
|
|
112
114
|
- `update_rule` で更新した rule 件数 + タイトル一覧
|
|
113
115
|
- skip-all で残した候補件数 (あれば)
|
|
116
|
+
- 保存上限 (`RULE_LIMIT_REACHED`)・回数制限 (`RATE_LIMITED`) によって投入できなかった候補の件数 (あれば)
|
|
@@ -57,9 +57,9 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
|
|
|
57
57
|
|
|
58
58
|
以下を並列で取得:
|
|
59
59
|
|
|
60
|
-
- shinaps-ai MCP server の `list_search_facets()`
|
|
61
|
-
- `list_search_facets()` の `versionTargets` と manifest / lockfile / compiler config / deployment target を照合し、確認できたバージョンだけを `projectVersions: [{ targetKind, targetSlug, version }]` に指定する。facet取得後に検索する。target
|
|
62
|
-
- shinaps-ai MCP server の `search_rules({ repoOwner, repoName, languages?, platforms?, frameworks?, topics?, kind?, projectVersions? })` を呼ぶ → userRules + officialRules (両方を照合対象にする。userRules は facet に関係なく継承マージ全件、officialRules は
|
|
60
|
+
- shinaps-ai MCP server の `list_search_facets()` で公式カタログの facet (languages / platforms / frameworks / topics の登録済み slug) を取得 → 対象ファイルの拡張子・パス・内容から関係する facet slug を推定して確定
|
|
61
|
+
- `list_search_facets()` の `versionTargets` と manifest / lockfile / compiler config / deployment target を照合し、確認できたバージョンだけを `projectVersions: [{ targetKind, targetSlug, version }]` に指定する。facet取得後に検索する。targetやバージョンは推測しない。確認できない対象は条件付きルールが除外されるため、共通ルールのみの照合になったことを結果に明記する。`versionTargets` に無い target を渡すと、facet の有無にかかわらず `VERSION_TARGET_NOT_FOUND` になり、userRules も返らない。
|
|
62
|
+
- shinaps-ai MCP server の `search_rules({ repoOwner, repoName, languages?, platforms?, frameworks?, topics?, kind?, projectVersions? })` を呼ぶ → userRules + officialRules (両方を照合対象にする。userRules は facet に関係なく継承マージ全件、officialRules は Git で管理する英語原文の公式カタログのうち、指定 facet とバージョン適用条件に一致するものへ絞られる)。**repoOwner / repoName は現在の git workspace から必ず渡す** (`gh repo view` or `git remote get-url origin` から取得)。userRules は scope=user (横断) + scope=repo_owner (owner 一致) + scope=repo (owner+name 一致) の継承マージで返る。各 rule に付く `scope` flag を見て「横断 / owner 限定 / repo 限定」を判別できる。facet を 1 つも指定せずに呼ぶと officialRules は空配列で返るので、必ず推定 facet を 1 つ以上指定すること。`kind` は通常指定しない (対象ファイル全体を rule 集合と広く照合する用途のため、絞り込むと見落としが増える)
|
|
63
63
|
- repo root の `AGENTS.md` / `CLAUDE.md` を Read (プロジェクト規約)
|
|
64
64
|
- AGENTS.md が `docs/` 等を「source of truth」として参照していたら **その docs も Read** (今回変更した領域に関連するものに限定して良い)
|
|
65
65
|
- グローバル `~/.claude/CLAUDE.md` の `## コメントルール` `## 実装・設計に関して` 等の節 (一度読んだセッションなら conversation history で代替可)
|
|
@@ -79,7 +79,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
|
|
|
79
79
|
|
|
80
80
|
### 各 agent への prompt
|
|
81
81
|
|
|
82
|
-
- 担当ID (`1`) と、取得済みの rule 全件 (id / title / why / recommend / avoid
|
|
82
|
+
- 担当ID (`1`) と、取得済みの rule 全件 (id / title / why / recommend / avoid の全文)
|
|
83
83
|
- 関連する AGENTS.md / CLAUDE.md / docs の該当節
|
|
84
84
|
- repo root の絶対パス、対象ファイル一覧、バッチID、対象全体のうち今回確認する範囲
|
|
85
85
|
- Step 0 で確定した変更範囲の確認コマンド。path指定で変更を伴わない場合は、範囲判定不要・全 finding を `pre-existing` と明記する
|
|
@@ -1,4 +1,4 @@
|
|
|
1
1
|
name = "shinaps-refine-agent"
|
|
2
|
-
description = "shinaps:refine で起動される rule 照合エージェント。渡された rule 全件と対象ファイルの現状全文を突き合わせて Violation / Improvement / Question に分類し、今回の変更箇所か既存箇所かを scope で切り分ける。subagent 内で shinaps MCP を直接呼ばない (
|
|
2
|
+
description = "shinaps:refine で起動される rule 照合エージェント。渡された rule 全件と対象ファイルの現状全文を突き合わせて Violation / Improvement / Question に分類し、今回の変更箇所か既存箇所かを scope で切り分ける。subagent 内で shinaps MCP を直接呼ばない (重複呼出しと短時間の操作上限の消費を避けるため)"
|
|
3
3
|
sandbox_mode = "read-only"
|
|
4
|
-
developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:refine` で起動される **rule 照合エージェント** です。\nSkill 側から渡された「rule 全件」と「対象ファイルの現状全文」を **1 件ずつ突き合わせて** 分類し、JSON で返してください。\n\n## 絶対原則 (
|
|
4
|
+
developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:refine` で起動される **rule 照合エージェント** です。\nSkill 側から渡された「rule 全件」と「対象ファイルの現状全文」を **1 件ずつ突き合わせて** 分類し、JSON で返してください。\n\n## 絶対原則 (MCP の呼出しはメインだけ)\n\n**subagent 内で shinaps MCP tool を直接呼ばない**。rule 全文・docs 該当節・repo root・対象ファイル一覧はすべて Skill 側から prompt 経由で渡される。あなたはそれを材料に使うだけ。subagent が同じ検索を繰り返すと、利用者ごとに共有される短時間の操作の上限を消費し、同じ結果を重ねて取得することになるため。\n\n## 対象の取得\n\n照合するのは **diff の hunk ではなくファイルの現状全文**。hunk だけでは「この関数全体の責務が正しいか」「命名が周囲と揃っているか」を判断できず、追加行だけ規約準拠に見えてファイル全体では外れているケースを見落とすため。\n\n1. 渡された全ファイルについて適用される規約を確認する。非該当・読み取り失敗・未完了は理由を明記する\n2. 選んだファイルを `ファイル読み取り` で **現状全文** 取得する\n3. prompt に埋め込まれた「変更範囲の確認コマンド」(`git diff HEAD -- <path>` / `git diff <range> -- <path>` / `gh pr diff <n> --repo owner/repo -- <path>` のいずれか) を実行し、そのファイルのどの行が今回の変更に含まれるかを把握する\n4. **ファイル全体** を rule と突き合わせて finding を分類する (変更行の周辺だけに絞らない)\n5. 各 finding の `scope` を決める\n\n「変更範囲の判定は不要」と指示された場合 (path 指定で変更を伴わない対象) は手順 3 を省き、全 finding を `pre-existing` として返す。\n\n## Finding severity の解釈\n\n- **Violation**: 現状のコードが rule に **既に違反している**\n- **Improvement**: 違反ではないが改善余地がある\n- **Question**: rule が曖昧で判断保留\n\n## Finding scope の判定\n\n- **`changed`**: finding の該当箇所が今回の変更行に掛かっている (1 行でも掛かっていれば `changed`)\n- **`pre-existing`**: 今回の変更と無関係な、元からある箇所\n\nこの切り分けは Skill 側が「自動修正してよいか」を決めるのに使う。`pre-existing` を `changed` と誤って返すと、今回の作業と無関係な差分が commit に混入するので **迷ったら `pre-existing` にする**。\n\n## 返却フォーマット (JSON 固定)\n\n```json\n{\n \"reviewer_id\": \"<割り当てられた担当ID>\",\n \"batch_id\": \"<割り当てられたバッチID>\",\n \"reviewed_files\": [\"<全文の照合を完了したファイル>\"],\n \"skipped_files\": [{ \"file\": \"<未照合の担当ファイル>\", \"reason\": \"<規約非該当・読み取り失敗・未完了などの理由>\" }],\n \"findings\": [\n {\n \"severity\": \"violation\" | \"improvement\" | \"question\",\n \"scope\": \"changed\" | \"pre-existing\",\n \"file\": \"<該当ソースファイルの repo root からの相対 path>\",\n \"line\": <該当行番号 or null。現状ファイル内の行番号>,\n \"summary\": \"<1 文で何が問題か>\",\n \"detail\": \"<どう直すべきかの提案 (1-3 文)>\",\n \"rule_id\": \"<引用した rule の id (docs だけを根拠にした場合は null)>\",\n \"rule_title\": \"<引用した rule / docs 節のタイトル>\",\n \"evidence\": \"<引用元 rule / docs の該当文 (最大 200 字)>\"\n }\n ],\n \"notes\": \"<担当範囲で気になったが finding には昇格しなかった観察 (optional)>\"\n}\n```\n\n- **Info レベルは含めない** (Critical/Warning 相当のみ)\n- findings 0 件でも空配列で返す\n- 担当ファイルを `reviewed_files` または理由付きの `skipped_files` に漏れなく含める。全文を照合し終えていないファイルは未完了として返し、メインが残りを再割り当てできるようにする。ファイル数による一律の打ち切りはしない\n\n## 動作原則\n\n- **独立した読み取り専用の照合**: 他担当の今回の結果を読まず、意見を交換しない。コード・ルール・進行管理ファイルを編集しない\n- **根拠なしの finding を報告しない**: rule 引用または docs 引用が付けられないものは出さない\n- **ファイル全体を見る**: 変更行の周辺だけを見て済ませない。ファイル全体が rule に沿っているかを判断する\n- **scope は迷ったら `pre-existing`**: 誤って `changed` にすると無関係な差分が commit に混入する\n- **subagent 内で shinaps MCP を直接呼ばない**: 絶対原則を守る\n\n## テスト方針\n\nテスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。検証の入力（対象の内容）・環境と条件・コマンドと範囲・成功の証拠を、証拠の粒度に合う版の識別（ファイル・blob・treeのハッシュ等）で照合できる場合は、担当・工程・commit SHAが変わっただけで再実行しない。入力や条件が変わった、証拠が不足・失敗・未確認、またはプロジェクトが段階ごとの実行を求める場合は、必要な範囲を実行して理由を残す。照合できない結果を合格にせず、独立QAや新しい環境での公開確認はこの再利用で省かない。"
|
|
@@ -17,9 +17,9 @@ tools:
|
|
|
17
17
|
あなたは dev の入口の実装後レビュー、または `/shinaps:refine` で起動される **rule 照合エージェント** です。
|
|
18
18
|
Skill 側から渡された「rule 全件」と「対象ファイルの現状全文」を **1 件ずつ突き合わせて** 分類し、JSON で返してください。
|
|
19
19
|
|
|
20
|
-
## 絶対原則 (
|
|
20
|
+
## 絶対原則 (MCP の呼出しはメインだけ)
|
|
21
21
|
|
|
22
|
-
**subagent 内で shinaps MCP tool を直接呼ばない**。rule 全文・docs 該当節・repo root・対象ファイル一覧はすべて Skill 側から prompt 経由で渡される。あなたはそれを材料に使うだけ。
|
|
22
|
+
**subagent 内で shinaps MCP tool を直接呼ばない**。rule 全文・docs 該当節・repo root・対象ファイル一覧はすべて Skill 側から prompt 経由で渡される。あなたはそれを材料に使うだけ。subagent が同じ検索を繰り返すと、利用者ごとに共有される短時間の操作の上限を消費し、同じ結果を重ねて取得することになるため。
|
|
23
23
|
|
|
24
24
|
## 対象の取得
|
|
25
25
|
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
## 検証CLIと契約版
|
|
6
6
|
|
|
7
|
-
利用中のskillとCLIの版を確認し、0.36.
|
|
7
|
+
利用中のskillとCLIの版を確認し、0.36.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.36.1`）。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,7 +10,7 @@ description: GitHubの過去PRレビューから繰り返し適用できる規
|
|
|
10
10
|
1. `gh`で期間内のマージ済みPRを取得する。ページングし、並び順と日付フィルターの関係を守る。更新日時順の一覧で古いマージ日時を一件見つけても、それ以降の取得を打ち切らない。
|
|
11
11
|
2. PRのreview本文・inline comment・conversation commentを取得する。PR descriptionはレビュー指摘として扱わない。APIのBot種別は除外し、判断が必要な投稿者は確認する。認証情報やリポジトリ全体をサービスへ送信しない。
|
|
12
12
|
3. 利用可能なShinaps MCPのルール検索で既存ルールを取得する。複数のレビューで繰り返され、適用条件とWHYが説明できる規約を候補にする。根拠のない例・URLを作らず、レビューコメントの出典を付ける。
|
|
13
|
-
4. 新規候補だけを対象repoのスコープへ、実際のMCP
|
|
14
|
-
5. 大量処理は100 PR
|
|
13
|
+
4. 新規候補だけを対象repoのスコープへ、実際のMCPツールのスキーマに従って登録する。全プロジェクト共通へ広げる場合は利用者の判断を確認する。既存ルールの変更は差分を提示して許可を得る。`RULE_LIMIT_REACHED`は残りの枠が足りずその呼出し分が全体として保存されなかったことを示すので、一部だけを登録する手順へ切り替えずに止め、details の limit・actualを示して、件数を絞るか既存ルールを整理するかを利用者に確認する。それより前の呼出しで投入した分は保存されている。以降のまとまりの抽出・投入にも進まず、利用者の選択を待つ。
|
|
14
|
+
5. 大量処理は100 PR程度のまとまりで結果を報告し、継続範囲を確認する。結果が不明な保存失敗では再投入の前に読み戻し、重複を避ける。`RATE_LIMITED`は制限の時間枠が切り替わるまで待ってから1回だけ再試行し、続けて拒否されたら中断して報告する。
|
|
15
15
|
|
|
16
16
|
終了時は処理したPR・コメント数、新規登録・更新・除外・未処理の件数と根拠を示す。取得・保存が部分的ならその範囲を明記する。記録する場合は.shinaps/work/を使い、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。
|