@shinaps/skills 0.42.0 → 0.44.0

package/docs/development.md

@@ -7,7 +7,7 @@
 - Claude 版: `plugins/shinaps-claude/`、marketplace は `.claude-plugin/marketplace.json`
 - Codex 版: `plugins/shinaps-codex/`、marketplace は `.agents/plugins/marketplace.json`。サブエージェントは `plugins/shinaps-codex/agents/`
 - Claude Managed Agents 版: 両 plugin の `managed-agents/`。plugin と一緒に配布され、npm パッケージの `plugins/` にも含まれる
-- 配布 CLI: ソースは `bin/skills.ts` と `lib/*.ts`。`npm run build`（`tsc`）で `dist/` に JS を出力し、npm にはそれを配布する。Node.js は `node_modules` 配下の `.ts` に型除去を適用しないため、ソースのままは配布できない。checkout では型除去で直接実行するので、`enum` など型除去で消せない構文は使わない（`tsconfig.json` の `erasableSyntaxOnly`）
+- 配布 CLI: ソースは `bin/skills.ts` と `lib/*.ts`。規約の機械検査（`lint`）は ESLint の Node API を使い、仕組みと同梱ルールの追加手順は [規約の機械検査](lint.md) にある。TypeScript は typescript-eslint が対応する 6 系を実行時の依存に持ち、開発用の `tsc` も同じ版を使う（typescript-eslint が 7 に対応したら上げる）。`npm run build`（`tsc`）で `dist/` に JS を出力し、npm にはそれを配布する。Node.js は `node_modules` 配下の `.ts` に型除去を適用しないため、ソースのままは配布できない。checkout では型除去で直接実行するので、`enum` など型除去で消せない構文は使わない（`tsconfig.json` の `erasableSyntaxOnly`）
 
 品質基準とプロジェクト設定の方針は両版で揃え、クライアント固有の実行手順とエージェントの形式は別々に管理する。スキルを追加・変更したら各版への適用可否を判断する。
 

package/docs/install.md

@@ -4,7 +4,7 @@ Claude Code 版の更新と、Codex 版の導入・更新・削除・macOS で
 
 ## 導入・更新・削除
 
-Node.js 22 以上と、`plugin marketplace add` / `plugin add` に対応した Codex CLI が必要です。Codex のスキルだけを使う場合、Claude Code のインストールは不要です。
+Node.js 22.13 以上の 22 系または 24 以上と、`plugin marketplace add` / `plugin add` に対応した Codex CLI が必要です。Codex のスキルだけを使う場合、Claude Code のインストールは不要です。
 
 ```sh
 npx @shinaps/skills@latest install codex
@@ -23,10 +23,10 @@ npx @shinaps/skills@latest recover codex
 
 ## 配布 CLI
 
-設定の検証（`validate-linear-config`・`validate-managed-config`）と Managed Agents の操作（`managed`）には、配布 CLI `shinaps-skills` を使います。CLI は plugin に含まれないため、利用中のスキルと同じ版を導入します。
+設定の検証（`validate-linear-config`・`validate-managed-config`）、Managed Agents の操作（`managed`）、規約の機械検査（`lint`、[規約の機械検査](lint.md)）には、配布 CLI `shinaps-skills` を使います。CLI は plugin に含まれないため、利用中のスキルと同じ版を導入します。
 
 ```sh
-npm install -g @shinaps/skills@0.42.0
+npm install -g @shinaps/skills@0.44.0
 shinaps-skills --version
 ```
 

package/docs/lint.md

@@ -0,0 +1,71 @@
+# 規約の機械検査（`shinaps-skills lint`）
+
+Shinaps AIの規約が持つ機械検査（`checks`）を手元で実行し、規約×ファイルの組ごとに、AI照合を省けるかを判定するCLIです。エージェント向けの使い方は plugin の `references/lint.md` にあります。
+
+## 前提と保証
+
+- プロジェクトの変更は要りません。プロジェクトのlint設定（`eslint.config.*`・`.oxlintrc.json`・`bunfig.toml` など）・`package.json` のscript・`node_modules` のパッケージは読み込みません。ESLintのNode APIを `overrideConfigFile: true` で使い、パーサーとプラグインはこのパッケージの依存から渡します。読むのは対象ファイルと、型情報を使うルールのための `tsconfig.json`・型宣言だけです（実行はしません）。
+- 対象ファイルへ書き込みません（自動修正はしません）。結果はローカルのファイルに書き、サーバーへは送りません。
+- プロジェクトの `eslint-disable` コメントでは検査を抑止しません（`allowInlineConfig: false`）。プロジェクトの都合の例外は、指摘を確認する側で扱います。
+- 組をAI照合から外してよいのは、coverage が `full` の検査が、ESLintの判定でそのファイルに適用され、検査の実行単位が完了し、そのファイルに致命的な報告もruleIdの無い報告も無いときだけです。それ以外の組は `not-run`（または `partial`）として返し、合格にしません。coverage は検査を登録したときの判断で、このCLIは値を読むだけです。
+
+## 使い方
+
+```sh
+shinaps-skills lint --checks <checks.json> --root <project> --out <result.json> -- <files...>
+```
+
+- `--checks`・`--out` のパスは、コマンドを実行したディレクトリが基準です。
+- `--checks`: `{ "rules": [{ "id": "<規約id>", "checks": [{ "rule": "...", "options": [...], "files": ["**/*.ts"], "coverage": "full" }] }] }`。形が違えば何も書かずに終了コード1で終わります。
+- `--root`: 対象プロジェクトのルート。ESLintの `cwd` と、結果のパスの基準になります。
+- `<files...>`: 対象ファイル（`--root` からの相対パスか絶対パス）。どの検査も適用されないファイルはESLintに渡しません。渡すファイルが無ければESLintを起動しません（ファイルを省くとESLintはルート配下を全て検査するため）。
+- `--out`: 結果のJSON。
+
+結果:
+
+```json
+{
+  "root": "/path/to/project",
+  "units": [{ "id": "syntax-0", "typed": false, "rules": ["@typescript-eslint/method-signature-style"], "fileCount": 3 }],
+  "pairs": [
+    { "ruleId": "<規約id>", "file": "src/a.ts", "state": "covered", "findings": [] },
+    { "ruleId": "<規約id>", "file": "src/b.ts", "state": "violation", "findings": [{ "rule": "@typescript-eslint/method-signature-style", "line": 2, "column": 3, "message": "..." }] },
+    { "ruleId": "<規約id>", "file": "tests/c.ts", "state": "not-run", "reason": "...", "findings": [] }
+  ]
+}
+```
+
+| state | 意味 | 照合 |
+| --- | --- | --- |
+| `covered` | `full` の検査が実行され、違反が無い | 外す |
+| `violation` | `full` の検査が実行され、指摘がある（同じ規約の `partial` の検査の指摘を含む） | 外し、`findings` を指摘にする |
+| `partial` | `partial` の検査だけが実行された | 残し、`findings` も指摘にする |
+| `not-run` | 実行していない（`reason` に理由） | 残す |
+
+## 実行の仕組み
+
+1. 各検査のルールを、ESLint core・`@typescript-eslint`・`vue`・同梱の `shinaps` から引きます。この版に無いルールの検査は `not-run` になり、他の検査は止まりません。
+2. 検査ごとに、その検査の設定だけを入れたESLintで `calculateConfigForFile` を呼び、ルールが有効なファイルを適用先にします。globの解釈はESLintだけが行います。ESLintが設定を拒否した検査（不正なoptionsなど）は、ここで `not-run` になります。
+3. 同じルール・同じoptionsの検査は1つの設定にまとめ、同じルールでoptionsが違うものだけを別の実行単位にします。型情報を使うルール（`meta.docs.requiresTypeChecking`）は `projectService` を使う単位に分けます。この単位は全てのファイルを typescript-eslint で読み、型の得られないファイル（`tsconfig.json` に含まれないTS・JS、Vue）はそのファイルだけが `not-run` になります。型なしの検査と、他のファイルの型付きの検査は影響を受けません。型情報を使うルールはVueのファイルでは実行できません。
+4. 実行単位ごとに `lintFiles` を1回呼び、組を分類します。指摘は、ESLintがそのファイルに適用すると判定した検査の規約にだけ付けます。
+
+## 同梱ルール
+
+| ルールID | 内容 | 型情報 |
+| --- | --- | --- |
+| `shinaps/prefer-promise-with-resolvers` | Promiseのexecutorが受け取る `resolve`・`reject` を、executorの外で使うために変数・プロパティへ代入する書き方（deferred promise）を報告する。`Promise.withResolvers()` で書ける。包んだ関数の代入や、値として渡す呼び出しは報告しない | 不要 |
+
+### 同梱ルールの追加
+
+規約の検査に既存のルールが使えないとき、レビュー済みでテスト済みのルールをこのパッケージに同梱します。サーバーにはルールのIDとoptionsだけを保存し、コードは配布しません。同梱していないルールは、実装・テスト・レビュー・リリースを経るまで使えません（それまでは、その規約はAI照合のままです）。
+
+1. `lib/lint-rules.ts` にルールを足し、`shinapsPlugin.rules` に登録します。IDは意味を変えずに使い続けます（規約の検査はIDで保存され、登録時の意味のレビューがその挙動を前提にするため）。意味が変わるなら別のIDにします。型情報を使うルールには `meta.docs.requiresTypeChecking: true` を付けます（付けないと型なしの実行単位に入り、その単位の検査が全て `not-run` になります）。
+2. `test/lint.test.ts` に、ESLintの `RuleTester` で報告する例・しない例を書きます。規約の good・bad の例と、誤って報告しやすい形（同じ名前の別の変数など）を含めます。型情報を使わないルールは、型情報なしの `RuleTester` で動くことがそのまま確認になります。型情報を使うルールは、`languageOptions.parserOptions` に `projectService` を付けた `RuleTester` で試します。
+3. この文書の「同梱ルール」の表に追加し、通常の変更と同じくレビュー・リリースします。
+4. 規約に検査を付けるのはリリースの後です。規約の全文を読んで coverage を決めます（plugin の `references/lint.md`）。
+
+実例: `shinaps/prefer-promise-with-resolvers`（`lib/lint-rules.ts`）。右辺の識別子をscopeで解決し、Promiseのexecutorの引数そのものかを確かめることで、内側の関数の同じ名前の引数を取り違えないようにしています。テストは `test/lint.test.ts` の末尾にあります。
+
+## 依存
+
+ESLint・typescript-eslint・TypeScript・vue-eslint-parser・eslint-plugin-vue を完全一致の版で依存に持ちます（パッケージの導入が約50MB増えます）。typescript-eslint は TypeScript 7 に対応していないため、TypeScript は6系です（開発用の `tsc` も同じ版を使います）。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.42.0",
+  "version": "0.44.0",
   "description": "Install Shinaps AI workflows and custom agents for Codex",
   "type": "module",
   "bin": {
@@ -15,7 +15,7 @@
     "LICENSE"
   ],
   "engines": {
-    "node": ">=22"
+    "node": "^22.13.0 || >=24"
   },
   "scripts": {
     "build": "tsc -p tsconfig.build.json",
@@ -36,10 +36,14 @@
   },
   "devDependencies": {
     "@biomejs/biome": "2.5.15",
-    "@types/node": "^26.6.4",
-    "typescript": "^7.0.2"
+    "@types/node": "^26.6.4"
   },
   "dependencies": {
-    "ajv": "^8.20.0"
+    "ajv": "^8.20.0",
+    "eslint": "10.14.0",
+    "eslint-plugin-vue": "10.12.0",
+    "typescript": "6.0.3",
+    "typescript-eslint": "8.72.1",
+    "vue-eslint-parser": "10.4.1"
   }
 }

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

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

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.42.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.42.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.44.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.44.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

@@ -0,0 +1,34 @@
+# 規約の機械検査（Shinaps lint）
+
+Shinaps AIの規約は、機械検査（`checks`）を持てる。検査は配布CLI `shinaps-skills lint` が、プロジェクトのlint設定・script・依存を使わずに手元で実行する。プロジェクトの変更は要らない。対象のコード・差分・結果はサーバーへ送らない。CLIの入出力と同梱ルールの追加手順は、配布パッケージの `docs/lint.md` にある。
+
+検査で照合を省いてよいのは、静的に保証できた組（規約×ファイル）だけ。未実行・対象外・エラー・一部だけの検査は合格にせず、AI照合に回す。
+
+## 照合で使う
+
+[Shinaps規約の取得](rules.md)で全文を取得した後、照合の担当へ渡す前に行う。
+
+1. 全文の `checks` を持つ規約を、`{ "rules": [{ "id": "<規約id>", "checks": [<全文のchecksのまま>] }] }` の形で作業記録の下（例: `.shinaps/work/<作業>/lint-checks.json`）に書く。checksを書き換えない。持つ規約が無ければこの節を省く。
+2. 対象ファイル（照合の対象として確定したもの。削除されたファイルを除く）を付けて1回実行する。
+
+   ```sh
+   shinaps-skills lint --checks <lint-checks.json> --root <リポジトリのルート> --out <lint-result.json> -- <対象ファイル...>
+   ```
+
+   コマンドが無い、終了コードが0でない、または結果を読めないときは、全ての規約をAI照合に回し、理由を報告する。CLIは利用中のスキルと同じ版を使う。
+3. 結果の `pairs` は規約×ファイルの組ごとに状態を持つ。
+   - `covered`: 全体を検査する検査（coverage `full`）が実行され、違反が無い。この組は担当の照合から外す。
+   - `violation`: 全体を検査する検査が実行され、指摘がある（同じ規約の一部だけを検査する検査の指摘を含む）。照合から外し、`findings` を指摘にする。
+   - `partial`: 一部だけを検査する検査だけが実行された。`findings` を指摘にし、規約はそのファイルの照合に残す（担当にはlintの指摘も渡す）。
+   - `not-run`: 実行していない（対象外、この版に無いルール、ESLintが設定を拒否した、型が得られない、致命的な報告など）。照合に残し、`reason` を記録する。
+4. lint由来の指摘は、根拠に規約idとルールID（`findings[].rule`）を付けて集約に入れる。誤報告がありうるので自動修正にせず、メインがその位置を読んで確認してから扱う。
+5. 報告に、状態ごとの組の数、`not-run` の理由、`units[].error` を書く。照合から外した組を「AIが照合した」と書かない。
+
+## 検査を登録・更新する
+
+[Shinaps規約の書き方](rule-writing.md)で書き込む規約に、検査を付けられるかを判断する。
+
+- **使えるルール**: ESLint core、`@typescript-eslint/*`（型情報を使うものを含む）、`vue/*`、同梱の `shinaps/*`（`docs/lint.md` の一覧）。版によって違うので、同じ版のCLIで確かめる。使えるルールが無い規約には検査を付けない（AI照合のまま）。同梱ルールの追加は `docs/lint.md` の手順で別の作業として提案する。
+- **coverageの判断**: 規約の全文（scope・labelsを含み、更新では更新後の全文）と、検査の `rule`・`options`・`files` を照らす。`files` の範囲で、規約が求めることへの違反をこのルールが全て報告すると言えるときだけ `full`、見逃しが一つでもありうれば `partial`。lintが規約より広く報告する（例外も報告する）ことは `full` の妨げにならない（指摘はメインが確認する）。例で通ることは根拠にならない。
+- **補助の確認**: 規約のgood・badの例を一時ディレクトリにファイルとして書き、同じ入口で実行して、badで報告され、goodで報告されないことを確かめる。対象プロジェクトのコードを写さない。
+- **書き込み**: `record_rule`・`update_rule` の `checks` に渡す。一括の `record_rules` は `checks` を受け取らない（付けると呼出し全体が入力エラーになる）ので、検査は登録後に `update_rule` で付ける。`update_rule` は配列ごと置換し、`[]` で外す。検査を持つ規約の内容（出典以外）を変える更新では、更新後の全文で検査を見直し、同じ要求で `checks` を渡す。渡さないと `CHECKS_REQUIRED` で保存されない。見直した結果が同じなら同じ配列を渡す。

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

@@ -4,7 +4,39 @@ Shinaps AIへ個人規約を登録・更新するときの書き方。短さそ
 
 ## 1件1判断
 
-1件には1つの判断だけを書く。別々に適用・変更できる判断は分ける。登録の前に[Shinaps規約の取得](rules.md)で既存の規約を確かめ、同じ判断があれば新規に増やさず更新を検討する。
+1件には1つの判断だけを書く。別々に適用・変更できる判断は分ける。
+
+## 書き込む前に既存の規約と比べる
+
+`record_rule`・`record_rules`・`update_rule` の前に、書き込む全文（scope・labelを含み、更新では更新後の全文）を既存の規約の全文と比べる。比べるのは呼出し元のAIで、類似度の点数は作らない。既存の規約は[Shinaps規約の取得](rules.md)の「書き込む前に取得する」で取得する。全文や範囲が変わったら比べ直す。
+
+比べるのは次の2つ。
+
+- **判断**: 適用条件・求める行動・例外・強さ（強制か推奨か）。文面が違っても全て同じなら同じ判断で、文面が似ていても一つ違えば別の判断とする。適用条件の広さの違いは判断の違いに数えず、範囲で比べる。
+- **範囲**: scope・技術のlabel・公式規約の版の条件・適用条件の広さ。
+
+候補ごとに読んだ既存の規約の全てを見て、次の順で最初に当てはまる結果にする。公式規約は読むだけで、書き込み先にしない。
+
+1. **提示**: 同じ場面で既存の規約と両方には従えない、候補に従うと既存の規約の例外や強さが意味を持たなくなる、更新先を一つに決められない、または結果を判断できない。
+2. **書かない**: 同じ判断で範囲が候補を含む既存の規約があり、候補に加える情報が無い（言い換えは情報に数えない）。または、同じ判断で範囲が候補を含むのが公式規約だけである（補足があれば報告する）。
+3. **提示**: 取得が未完了である。「重複なし」とせず、未取得の範囲を示す。
+4. **更新**: 同じ判断で範囲が候補を含む個人規約があり、候補の補足（理由・例・出典）が判断を変えず、その規約の範囲全体に当てはまる。判断・範囲・kindは変えない。
+5. **提示**: 同じ判断の個人規約と範囲が重なるが候補を含まない、または補足がその規約の範囲の一部にしか当てはまらない。
+6. **新規**: それ以外。別の判断で既存の規約と両立するもの、公式規約より範囲が広い同じ判断を含む。
+
+`update_rule` の依頼では更新対象自身を比較の相手から外し、他の規約で1〜3に当たらなければ結果を更新とする。当たるときは結果を提示とし、更新対象を変えず、更新前の全文のまま残ることを示す。更新対象の削除や他の規約との統合は、利用者が選んだときだけ行う。判断や範囲を変える更新は、更新前後の全文の差分と範囲の変化を示して同意を受ける。
+
+同じ作業で保存前の候補同士は、範囲が広い方（決まらなければ先の候補）を既存の規約とみなして同じ順で比べる。結果が提示なら両方を提示する。更新は相手の候補の下書きへ補足を足すことで、`update_rule` は呼ばず、許可は相手の候補の結果で判断する。書かないと更新は、相手の候補が保存されたときに確定する。相手の全文が変わる、または書かれないときは、書かないまたは更新とした候補を比べ直す。範囲は足し合わせず、呼出しのscopeに揃えるために候補のscopeを変えない。
+
+提示では候補と既存の規約の全文の違い、推奨する結果と理由、その候補を相手とした他の候補を示し、利用者の判断を受ける。提示した全文のまま利用者が選んだ操作は、比べ直さずに書く。同じtitleの既存があるなどで書けなかった候補も提示する。
+
+比較の結果は書き込みの許可にならない。更新・新規は結果が許可された操作・対象と一致するときだけ書き、違えば書かずに提示する。比べた他の規約は変更しない。
+
+結果は候補ごとに、比べた既存の規約のidまたは相手の候補、未確定ならその旨、取得の条件、未完了の範囲と返らない範囲を添えて報告する。
+
+## 機械検査
+
+coding の規約は、使えるlintのルールで検査できるかを判断し、できるものには `checks` を付ける。coverageの決め方・補助の確認・書き込みと、検査を持つ規約の内容を変えるときの見直しは[規約の機械検査](lint.md)の「検査を登録・更新する」に従う。
 
 ## 項目の役割
 

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

@@ -6,7 +6,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 `list_search_facets` を呼び、`languages`・`platforms`・`frameworks`・`topics` の語彙と `versionTargets` を確かめる。以降で渡すslugと版のtargetは、この応答にあるものだけにする。語彙に無いfacetのslugはエラーにならず、結果が黙って変わる。
 
-重複や件数の確認でfacetを渡さないときは、この節と次の節を省く。
+件数の確認でfacetを渡さないときは、この節と次の節を省く。
 
 ## 対象の技術を選ぶ
 
@@ -37,7 +37,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 - `nextCursor` がnullになるまで、他の入力を変えず `cursor` に渡す。途中で止めた範囲は未取得として扱う。
 - **渡せる軸が無いと公式ルールは0件で返り、照合したことにならない。** 不明なファイルを除いて選び直し、`filterUserRulesByLabels` なしで取得する（個人規約は全件返る）。除いたファイルの公式ルールは未照合になる。それでも渡せる軸が無ければ、全ての公式ルールが未照合になる。`topics` は一致必須なので、渡すと部分的な照合になる。
 - **版**: 対象が使う技術のうち `versionTargets` にあるものは、lockfile・compiler config・deployment target、または完全固定のmanifestで確定した版を `projectVersions` に渡す（`^19` のような範囲は渡さない）。渡していないtargetの条件付き公式ルールは全て除外される。同じtargetで対象ごとに版が違うなら、対象を分けて取得してidの和を取る。`VERSION_TARGET_NOT_FOUND` は全体の失敗なので、targetを直して先頭から取り直す。
-- 対象ファイルの技術が増えたら取り直す。件数で規約の登録の有無を判断するとき、既存規約との重複を確かめるときは、`filterUserRulesByLabels` なしの結果を使う。
+- 対象ファイルの技術が増えたら取り直す。件数で規約の登録の有無を判断するときは、`filterUserRulesByLabels` なしの結果を使う。既存規約との重複は「書き込む前に取得する」で確かめる。
 
 ## 全文を取る規約を選ぶ
 
@@ -56,9 +56,21 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 - 全件が必要と分かっているときは、`search_rules` の `fields: "full"` を `nextCursor` がnullになるまで辿ってもよい。
 - `RATE_LIMITED` は短い時間を置いて、同じ `cursor` または `remainingIds` から再開する。
 
+## 書き込む前に取得する
+
+[Shinaps規約の書き方](rule-writing.md)の比較に使う規約は、次の条件で取得する。
+
+- `search_rules` は `fields: "summary"` で全ページ取得し、`filterUserRulesByLabels` と `kind` を渡さない。`repoOwner`・`repoName` は、登録先のowner・repoがあればその値、無い分は現在のGit workspaceの値にする。
+- 公式規約も一覧に載るよう、`list_search_facets` の語彙が8件以内の技術軸（`languages` など）を一つ選び、その全slugを渡す。技術軸はその軸のlabelが無い公式規約にも一致する。`topics` は一致必須で別のtopicの公式規約が返らなくなるので渡さない。渡せる軸が無ければ公式規約の取得は未完了とする。
+- `projectVersions` には確定した版だけを渡す。渡しても渡さなくても、条件に合わない条件付きの公式規約は返らない。
+- 一覧のtitleとlabelから同じ場面を扱う可能性を否定できない規約を選び、「全文を取る」で全文を取得する。文字列の一致で選ばない（公式規約のtitleは英語）。「全文を取る規約を選ぶ」は対象ファイルとの照合の基準で、ここには適用しない。
+- 同じ条件の結果は、規約を書き込むまでの間、候補の間で再利用してよい。他の工程で `filterUserRulesByLabels`・`kind`・`topics` を使って絞った結果は使わない。
+
+選んだ条件の一覧と選んだ全文を読み終えていなければ未完了とする。他のリポジトリ・ownerの個人規約と版の条件で除かれた公式規約は検索で返らない範囲で、未完了に数えずに報告する。どちらの場合も「全体に重複が無い」とは言わない。
+
 ## 担当へ渡す
 
-全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
+`checks` を持つ規約がある照合では、渡す前に[規約の機械検査](lint.md)の「照合で使う」を行い、照合から外す組を決める。全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
 
 ## 照合結果に書くこと
 

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

@@ -63,7 +63,7 @@ PR description (本文) は対象外。あくまで「レビュー観点」を
 
 ## Step 6. 既存 rules 把握
 
-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` か」を判断する材料にする。
+100 PR を 1 ブロックとして処理する。ブロックの開始時に必ず [Shinaps規約の取得](../../references/rules.md) の「書き込む前に取得する」に従って一覧を最後のページまで取得する (userRules は継承マージで scope=user / repo_owner / repo の全件)。全文は Step 7 で候補ごとに確かめる。
 
 ## Step 7. rules 生成と投入
 
@@ -87,13 +87,13 @@ Good/Bad サンプルコード (examples) の付け方:
 
 投入手順:
 
-- 候補ごとに、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 検証で拒否される)。
-- extract-rules は対象 repo の PR レビューから抽出する性質上 scope=repo (当該 repo 限定) がデフォルト。横断ルールとして残したい場合だけユーザー判断で `scope: 'user'` に格上げ。**格上げするときは why / recommend / avoid / examples を当該 repo の固有文脈 (内部 API 名・モジュール構成・ドメイン固有の識別子) から切り離し、他プロジェクトでも適用場面を想定できる汎用的な表現・汎用サンプルに解釈し直してから登録する** (scope=repo のままなら repo 固有の具体的な記述・コード片で良い)
+- 候補を確定してから、[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 検証で拒否される)。
+- 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_LIMIT_REACHED` が返ったら投入を止める。個人ルールの保存数には上限があり、残りの枠が足りない `record_rules` はその呼出し分が全体として失敗し、一部も保存されない (件数を減らして一部だけ登録する手順へ自動では切り替えない)。それより前の呼出しで投入した分は保存されている。details の `limit` と `actual` から残りの枠を示し、投入する件数を絞るか既存ルールを整理するかのどちらにするかを利用者に確認する。以降のブロックの抽出・投入にも進まず、利用者の選択を待つ。
 - `RATE_LIMITED` (再試行可能) が返ったら、制限の時間枠が切り替わるまで待ってから、同じ呼出しを1回だけ再試行する。再び拒否されたら、連続して再試行せずに中断し、その状況を利用者に報告する。
-- 戻り値は入力の `rules` の位置と id だけ (`inserted: { index, ruleId }[]`、`skipped: { index, existingRuleId }[]`)。`skipped` は「既存と title 重複して投入されなかった候補」で、title は入力の `rules[index]` から分かる。`get_rules` で既存の全文を取得する。
-- 事前の照合で一致した候補と `skipped` の両方について、why/recommend/avoid/examples が既存と異なるなら **ユーザーに diff を提示して同意を取る**:
+- 戻り値は入力の `rules` の位置と id だけ (`inserted: { index, ruleId }[]`、`skipped: { index, existingRuleId }[]`)。`skipped` は「既存と title 重複して投入されなかった候補」で、title は入力の `rules[index]` から分かる。上書きせず**提示**へ進める。
+- 既存の規約への**更新**の候補について、**ユーザーに diff を提示して同意を取る**:
 
 > 既存 rule "no-unused-vars" が見つかりました。why/recommend/avoid/examples の差分:
 > ```
@@ -117,4 +117,5 @@ since 期間内の merged PR を消化し終えたら、以下を user に報告
 - `record_rules` で新規投入した rule 件数 (inserted 合計) + タイトル一覧
 - `update_rule` で更新した rule 件数 + タイトル一覧
 - `no` または skip-all で残した候補件数 (あれば)
+- 比較の結果が「書かない」「提示」だった候補の件数と、[Shinaps規約の書き方](../../references/rule-writing.md) の比較が求める報告
 - 保存上限 (`RULE_LIMIT_REACHED`)・回数制限 (`RATE_LIMITED`) によって投入できなかった候補の件数 (あれば)

package/plugins/shinaps-claude/skills/refine/SKILL.md

@@ -33,7 +33,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 メインスレッド (あなた) は **オーケストレータ** に徹する:
 
 1. 対象ファイル集合の確定、規約カタログの集約 (Step 0-1)
-2. 規約・対象ファイルを担当へ渡せる形に整理する (Step 2)
+2. 機械検査で静的に保証できた組を照合から外し、規約・対象ファイルを担当へ渡せる形に整理する (Step 2)
 3. Opus / medium 1体を起動し、全対象を照合する (Step 3)
 4. 返ってきた findings を集約 → 変更箇所 / 既存箇所で振り分け (Step 4-5)
 
@@ -68,6 +68,8 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 
 ## Step 2. 共通の照合対象を準備する
 
+取得した rule 全文に `checks` を持つ規約があれば、先に [規約の機械検査](../../references/lint.md) の「照合で使う」を行う。`covered`・`violation` の組（規約×ファイル）はそのファイルについて担当の照合対象から外し、`violation`・`partial` の findings は lint 由来の指摘として Step 4 に加える。担当には、ファイルごとに照合から外した規約の id を伝え、`partial` の組には lint の指摘を添える。
+
 取得した rule 全文と関連する AGENTS.md / CLAUDE.md / docs、対象ファイル、変更範囲を担当へ渡す。対象が大きい場合は関連するファイルをまとめてバッチに分け、対象全体の一覧を維持する。カテゴリ数やバッチ数を起動するエージェント数に置き換えない。
 
 ## Step 3. Opus 1体で照合する
@@ -139,6 +141,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 - **scope 整合**: 同じ箇所の `scope` がバッチ間で異なる場合は実際の変更範囲を確認して判断し、不明なら `pre-existing` とする
 - **優先度整列**: Violation → Improvement → Question の順に並べ、Violation 内は影響範囲が大きいものから
 - **注意**: Info レベルは元々含まれない前提だが、agent 出力に混じっていたら破棄する
+- **lint 由来の指摘**: 根拠は規約 id とルール ID。メインが該当位置を読んで違反か確かめてから他の finding と同じ基準で扱う。誤報告と判断したものは理由を記録して除く
 
 集約結果の総数と内訳を 1 行で報告してから Step 5 に進む (`changed` / `pre-existing` の件数も併記する)。
 
@@ -153,7 +156,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 
 ### 自明な修正 (auto-apply、`changed` のみ)
 
-修正方法が一意で設計判断を伴わない finding は、ユーザーに確認せず `Edit` / `Write` で即修正する:
+lint 由来の指摘は auto-apply にしない (ルールは構文で判定するので、意図した例外も報告しうる)。修正方法が一意で設計判断を伴わない finding は、ユーザーに確認せず `Edit` / `Write` で即修正する:
 
 - コメント / 文言 / typo の修正 (規約が指す直し方が一つしかない)
 - 既存パターンへの機械的な追従 (隣接コードと同じ流儀に揃えるだけ)
@@ -174,7 +177,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 
 1. **修正する** — どう直すかを 1-2 文で提案 (agent が返した `detail` を活用)。承認されたら `Edit` / `Write` で実行
 2. **このまま許容する** — 妥当な理由があるとき。理由を今回のローカル成果物（implementation.md / 調査・レビューレポート）に残す (後から「なぜ違反のままにしたか」を辿れるように)
-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)
+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` (既存修正) を実行
 4. **後回し** — 別タスクとして扱う。`TaskCreate` で TODO 化し、後の作業セッションで着手できるようにする
 
 **提示順は `changed` を先、`pre-existing` を後**。それぞれの中では Violation → Improvement → Question の順。各 finding には `pre-existing` かどうかを明示して提示する (ユーザーが「今回の commit に混ぜるか」を判断する材料になるため)。件数が少なければ 1 回の `AskUserQuestion` に複数 question をまとめてよい (各 finding には前提説明を添える)。
@@ -185,6 +188,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 
 - 対象ファイル数と、その決め方 (`git diff HEAD` の変更ファイル / PR / commit range / path 指定のどれか) を冒頭に明示
 - [Shinaps規約の取得](../../references/rules.md) の「照合結果に書くこと」
+- 機械検査を使った場合は、状態ごとの組の数 (照合から外した `covered`・`violation` を含む)、`not-run` の理由。使えなかった場合はその理由
 - 実際の担当数・バッチ数と各担当の finding 件数、照合済みファイル数、非該当・未完了のファイルと理由
 - 検出 / 処理した finding の総数と内訳 (自動修正 X 件 / 確認の上修正 Y 件 / 許容 Z 件 / rule 更新 W 件 / 後回し V 件)
 - **`changed` と `pre-existing` の内訳** (既存箇所の指摘が何件あり、そのうち何件を今回直したか。今回の変更に無関係な修正がどれだけ混ざったかをユーザーが把握できるように)

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

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

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.42.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.42.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.44.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.44.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

@@ -0,0 +1,34 @@
+# 規約の機械検査（Shinaps lint）
+
+Shinaps AIの規約は、機械検査（`checks`）を持てる。検査は配布CLI `shinaps-skills lint` が、プロジェクトのlint設定・script・依存を使わずに手元で実行する。プロジェクトの変更は要らない。対象のコード・差分・結果はサーバーへ送らない。CLIの入出力と同梱ルールの追加手順は、配布パッケージの `docs/lint.md` にある。
+
+検査で照合を省いてよいのは、静的に保証できた組（規約×ファイル）だけ。未実行・対象外・エラー・一部だけの検査は合格にせず、AI照合に回す。
+
+## 照合で使う
+
+[Shinaps規約の取得](rules.md)で全文を取得した後、照合の担当へ渡す前に行う。
+
+1. 全文の `checks` を持つ規約を、`{ "rules": [{ "id": "<規約id>", "checks": [<全文のchecksのまま>] }] }` の形で作業記録の下（例: `.shinaps/work/<作業>/lint-checks.json`）に書く。checksを書き換えない。持つ規約が無ければこの節を省く。
+2. 対象ファイル（照合の対象として確定したもの。削除されたファイルを除く）を付けて1回実行する。
+
+   ```sh
+   shinaps-skills lint --checks <lint-checks.json> --root <リポジトリのルート> --out <lint-result.json> -- <対象ファイル...>
+   ```
+
+   コマンドが無い、終了コードが0でない、または結果を読めないときは、全ての規約をAI照合に回し、理由を報告する。CLIは利用中のスキルと同じ版を使う。
+3. 結果の `pairs` は規約×ファイルの組ごとに状態を持つ。
+   - `covered`: 全体を検査する検査（coverage `full`）が実行され、違反が無い。この組は担当の照合から外す。
+   - `violation`: 全体を検査する検査が実行され、指摘がある（同じ規約の一部だけを検査する検査の指摘を含む）。照合から外し、`findings` を指摘にする。
+   - `partial`: 一部だけを検査する検査だけが実行された。`findings` を指摘にし、規約はそのファイルの照合に残す（担当にはlintの指摘も渡す）。
+   - `not-run`: 実行していない（対象外、この版に無いルール、ESLintが設定を拒否した、型が得られない、致命的な報告など）。照合に残し、`reason` を記録する。
+4. lint由来の指摘は、根拠に規約idとルールID（`findings[].rule`）を付けて集約に入れる。誤報告がありうるので自動修正にせず、メインがその位置を読んで確認してから扱う。
+5. 報告に、状態ごとの組の数、`not-run` の理由、`units[].error` を書く。照合から外した組を「AIが照合した」と書かない。
+
+## 検査を登録・更新する
+
+[Shinaps規約の書き方](rule-writing.md)で書き込む規約に、検査を付けられるかを判断する。
+
+- **使えるルール**: ESLint core、`@typescript-eslint/*`（型情報を使うものを含む）、`vue/*`、同梱の `shinaps/*`（`docs/lint.md` の一覧）。版によって違うので、同じ版のCLIで確かめる。使えるルールが無い規約には検査を付けない（AI照合のまま）。同梱ルールの追加は `docs/lint.md` の手順で別の作業として提案する。
+- **coverageの判断**: 規約の全文（scope・labelsを含み、更新では更新後の全文）と、検査の `rule`・`options`・`files` を照らす。`files` の範囲で、規約が求めることへの違反をこのルールが全て報告すると言えるときだけ `full`、見逃しが一つでもありうれば `partial`。lintが規約より広く報告する（例外も報告する）ことは `full` の妨げにならない（指摘はメインが確認する）。例で通ることは根拠にならない。
+- **補助の確認**: 規約のgood・badの例を一時ディレクトリにファイルとして書き、同じ入口で実行して、badで報告され、goodで報告されないことを確かめる。対象プロジェクトのコードを写さない。
+- **書き込み**: `record_rule`・`update_rule` の `checks` に渡す。一括の `record_rules` は `checks` を受け取らない（付けると呼出し全体が入力エラーになる）ので、検査は登録後に `update_rule` で付ける。`update_rule` は配列ごと置換し、`[]` で外す。検査を持つ規約の内容（出典以外）を変える更新では、更新後の全文で検査を見直し、同じ要求で `checks` を渡す。渡さないと `CHECKS_REQUIRED` で保存されない。見直した結果が同じなら同じ配列を渡す。

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

@@ -4,7 +4,39 @@ Shinaps AIへ個人規約を登録・更新するときの書き方。短さそ
 
 ## 1件1判断
 
-1件には1つの判断だけを書く。別々に適用・変更できる判断は分ける。登録の前に[Shinaps規約の取得](rules.md)で既存の規約を確かめ、同じ判断があれば新規に増やさず更新を検討する。
+1件には1つの判断だけを書く。別々に適用・変更できる判断は分ける。
+
+## 書き込む前に既存の規約と比べる
+
+`record_rule`・`record_rules`・`update_rule` の前に、書き込む全文（scope・labelを含み、更新では更新後の全文）を既存の規約の全文と比べる。比べるのは呼出し元のAIで、類似度の点数は作らない。既存の規約は[Shinaps規約の取得](rules.md)の「書き込む前に取得する」で取得する。全文や範囲が変わったら比べ直す。
+
+比べるのは次の2つ。
+
+- **判断**: 適用条件・求める行動・例外・強さ（強制か推奨か）。文面が違っても全て同じなら同じ判断で、文面が似ていても一つ違えば別の判断とする。適用条件の広さの違いは判断の違いに数えず、範囲で比べる。
+- **範囲**: scope・技術のlabel・公式規約の版の条件・適用条件の広さ。
+
+候補ごとに読んだ既存の規約の全てを見て、次の順で最初に当てはまる結果にする。公式規約は読むだけで、書き込み先にしない。
+
+1. **提示**: 同じ場面で既存の規約と両方には従えない、候補に従うと既存の規約の例外や強さが意味を持たなくなる、更新先を一つに決められない、または結果を判断できない。
+2. **書かない**: 同じ判断で範囲が候補を含む既存の規約があり、候補に加える情報が無い（言い換えは情報に数えない）。または、同じ判断で範囲が候補を含むのが公式規約だけである（補足があれば報告する）。
+3. **提示**: 取得が未完了である。「重複なし」とせず、未取得の範囲を示す。
+4. **更新**: 同じ判断で範囲が候補を含む個人規約があり、候補の補足（理由・例・出典）が判断を変えず、その規約の範囲全体に当てはまる。判断・範囲・kindは変えない。
+5. **提示**: 同じ判断の個人規約と範囲が重なるが候補を含まない、または補足がその規約の範囲の一部にしか当てはまらない。
+6. **新規**: それ以外。別の判断で既存の規約と両立するもの、公式規約より範囲が広い同じ判断を含む。
+
+`update_rule` の依頼では更新対象自身を比較の相手から外し、他の規約で1〜3に当たらなければ結果を更新とする。当たるときは結果を提示とし、更新対象を変えず、更新前の全文のまま残ることを示す。更新対象の削除や他の規約との統合は、利用者が選んだときだけ行う。判断や範囲を変える更新は、更新前後の全文の差分と範囲の変化を示して同意を受ける。
+
+同じ作業で保存前の候補同士は、範囲が広い方（決まらなければ先の候補）を既存の規約とみなして同じ順で比べる。結果が提示なら両方を提示する。更新は相手の候補の下書きへ補足を足すことで、`update_rule` は呼ばず、許可は相手の候補の結果で判断する。書かないと更新は、相手の候補が保存されたときに確定する。相手の全文が変わる、または書かれないときは、書かないまたは更新とした候補を比べ直す。範囲は足し合わせず、呼出しのscopeに揃えるために候補のscopeを変えない。
+
+提示では候補と既存の規約の全文の違い、推奨する結果と理由、その候補を相手とした他の候補を示し、利用者の判断を受ける。提示した全文のまま利用者が選んだ操作は、比べ直さずに書く。同じtitleの既存があるなどで書けなかった候補も提示する。
+
+比較の結果は書き込みの許可にならない。更新・新規は結果が許可された操作・対象と一致するときだけ書き、違えば書かずに提示する。比べた他の規約は変更しない。
+
+結果は候補ごとに、比べた既存の規約のidまたは相手の候補、未確定ならその旨、取得の条件、未完了の範囲と返らない範囲を添えて報告する。
+
+## 機械検査
+
+coding の規約は、使えるlintのルールで検査できるかを判断し、できるものには `checks` を付ける。coverageの決め方・補助の確認・書き込みと、検査を持つ規約の内容を変えるときの見直しは[規約の機械検査](lint.md)の「検査を登録・更新する」に従う。
 
 ## 項目の役割
 

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

@@ -6,7 +6,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 `list_search_facets` を呼び、`languages`・`platforms`・`frameworks`・`topics` の語彙と `versionTargets` を確かめる。以降で渡すslugと版のtargetは、この応答にあるものだけにする。語彙に無いfacetのslugはエラーにならず、結果が黙って変わる。
 
-重複や件数の確認でfacetを渡さないときは、この節と次の節を省く。
+件数の確認でfacetを渡さないときは、この節と次の節を省く。
 
 ## 対象の技術を選ぶ
 
@@ -37,7 +37,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 - `nextCursor` がnullになるまで、他の入力を変えず `cursor` に渡す。途中で止めた範囲は未取得として扱う。
 - **渡せる軸が無いと公式ルールは0件で返り、照合したことにならない。** 不明なファイルを除いて選び直し、`filterUserRulesByLabels` なしで取得する（個人規約は全件返る）。除いたファイルの公式ルールは未照合になる。それでも渡せる軸が無ければ、全ての公式ルールが未照合になる。`topics` は一致必須なので、渡すと部分的な照合になる。
 - **版**: 対象が使う技術のうち `versionTargets` にあるものは、lockfile・compiler config・deployment target、または完全固定のmanifestで確定した版を `projectVersions` に渡す（`^19` のような範囲は渡さない）。渡していないtargetの条件付き公式ルールは全て除外される。同じtargetで対象ごとに版が違うなら、対象を分けて取得してidの和を取る。`VERSION_TARGET_NOT_FOUND` は全体の失敗なので、targetを直して先頭から取り直す。
-- 対象ファイルの技術が増えたら取り直す。件数で規約の登録の有無を判断するとき、既存規約との重複を確かめるときは、`filterUserRulesByLabels` なしの結果を使う。
+- 対象ファイルの技術が増えたら取り直す。件数で規約の登録の有無を判断するときは、`filterUserRulesByLabels` なしの結果を使う。既存規約との重複は「書き込む前に取得する」で確かめる。
 
 ## 全文を取る規約を選ぶ
 
@@ -56,9 +56,21 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 - 全件が必要と分かっているときは、`search_rules` の `fields: "full"` を `nextCursor` がnullになるまで辿ってもよい。
 - `RATE_LIMITED` は短い時間を置いて、同じ `cursor` または `remainingIds` から再開する。
 
+## 書き込む前に取得する
+
+[Shinaps規約の書き方](rule-writing.md)の比較に使う規約は、次の条件で取得する。
+
+- `search_rules` は `fields: "summary"` で全ページ取得し、`filterUserRulesByLabels` と `kind` を渡さない。`repoOwner`・`repoName` は、登録先のowner・repoがあればその値、無い分は現在のGit workspaceの値にする。
+- 公式規約も一覧に載るよう、`list_search_facets` の語彙が8件以内の技術軸（`languages` など）を一つ選び、その全slugを渡す。技術軸はその軸のlabelが無い公式規約にも一致する。`topics` は一致必須で別のtopicの公式規約が返らなくなるので渡さない。渡せる軸が無ければ公式規約の取得は未完了とする。
+- `projectVersions` には確定した版だけを渡す。渡しても渡さなくても、条件に合わない条件付きの公式規約は返らない。
+- 一覧のtitleとlabelから同じ場面を扱う可能性を否定できない規約を選び、「全文を取る」で全文を取得する。文字列の一致で選ばない（公式規約のtitleは英語）。「全文を取る規約を選ぶ」は対象ファイルとの照合の基準で、ここには適用しない。
+- 同じ条件の結果は、規約を書き込むまでの間、候補の間で再利用してよい。他の工程で `filterUserRulesByLabels`・`kind`・`topics` を使って絞った結果は使わない。
+
+選んだ条件の一覧と選んだ全文を読み終えていなければ未完了とする。他のリポジトリ・ownerの個人規約と版の条件で除かれた公式規約は検索で返らない範囲で、未完了に数えずに報告する。どちらの場合も「全体に重複が無い」とは言わない。
+
 ## 担当へ渡す
 
-全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
+`checks` を持つ規約がある照合では、渡す前に[規約の機械検査](lint.md)の「照合で使う」を行い、照合から外す組を決める。全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
 
 ## 照合結果に書くこと
 

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

@@ -9,8 +9,8 @@ description: GitHubの過去PRレビューから繰り返し適用できる規
 
 1. `gh`で期間内のマージ済みPRを取得する。ページングし、並び順と日付フィルターの関係を守る。更新日時順の一覧で古いマージ日時を一件見つけても、それ以降の取得を打ち切らない。
 2. PRのreview本文・inline comment・conversation commentを取得する。PR descriptionはレビュー指摘として扱わない。APIのBot種別は除外し、判断が必要な投稿者は確認する。認証情報やリポジトリ全体をサービスへ送信しない。
-3. [Shinaps規約の取得](../../references/rules.md)に従って既存ルールの一覧を全ページ取得する。候補ごとに、titleかlabelが重なるルールの全文を確かめ、判断できなければ全文を取得する。複数のレビューで繰り返され、適用条件とWHYが説明できる規約を候補にする。根拠のない例・URLを作らず、レビューコメントの出典を付ける。
-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を示して、件数を絞るか既存ルールを整理するかを利用者に確認する。それより前の呼出しで投入した分は保存されている。以降のまとまりの抽出・投入にも進まず、利用者の選択を待つ。
+3. 複数のレビューで繰り返され、適用条件とWHYが説明できる規約を候補にする。根拠のない例・URLを作らず、レビューコメントの出典を付ける。
+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を示して、件数を絞るか既存ルールを整理するかを利用者に確認する。それより前の呼出しで投入した分は保存されている。以降のまとまりの抽出・投入にも進まず、利用者の選択を待つ。
 5. 大量処理は100 PR程度のまとまりで結果を報告し、継続範囲を確認する。結果が不明な保存失敗では再投入の前に読み戻し、重複を避ける。`RATE_LIMITED`は制限の時間枠が切り替わるまで待ってから1回だけ再試行し、続けて拒否されたら中断して報告する。
 
-終了時は処理したPR・コメント数、新規登録・更新・除外・未処理の件数と根拠を示す。取得・保存が部分的ならその範囲を明記する。記録する場合は.shinaps/work/を使い、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。
+終了時は処理したPR・コメント数、新規登録・更新・書かない・提示・除外・未処理の件数と根拠を示す。取得・保存が部分的ならその範囲を明記する。記録する場合は.shinaps/work/を使い、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。

package/plugins/shinaps-codex/skills/refine/SKILL.md

@@ -7,8 +7,10 @@ description: 対象ファイルとShinaps AIのルールを照合し、違反・
 
 指定されたパス・PR・コミット範囲から対象を決める。作業中の変更ならstaged、unstaged、関連するuntrackedを含める。適用されるプロジェクトの指示を読み、[Shinaps規約の取得](../../references/rules.md)に従って、対象ファイルについて規約全文を取得する。MCPが使えない場合は照合を実施できないと報告し、推測でルールを作らない。アカウント作成・接続は利用者の標準認証フローを案内する。
 
+取得した規約に `checks` があれば、照合の前に[規約の機械検査](../../references/lint.md)の「照合で使う」に従い、静的に保証できた組（`covered`・`violation`）をその規約の照合から外し、lintの指摘は位置を読んで確かめてから扱う（自動修正しない）。照合から外した組と `not-run` の理由を報告する。
+
 対象ファイルの現状全文を読み、ルールごとに適用条件と実際のコードを比較する。指摘には根拠となるルール、該当箇所、影響と修正案を付ける。違反・改善・仕様判断を区別し、今回の変更と元からある問題を分ける。テストに関わる指摘と修正の判断は [テスト方針](../../references/testing.md) に従う。
 
 委託を許可されている場合は登録済みのshinaps-refine-agentへ重ならない範囲とルール全文を渡せる。担当の起動・継続は[担当の起動](../../references/dev/launch.md)に従う。結果は現在のコードで検証し重複をまとめる。独立検証をしなければそのように報告する。
 
-修正が依頼範囲に含まれる場合、今回の変更の自明な修正を適用し、必要な検証を行う。既存箇所や仕様に関係する判断は一問ずつ確認する。ルール自体の書き換え・外部Issueの作成を無断で行わない。ルールの書き換えが許可されたら[Shinaps規約の書き方](../../references/rule-writing.md)に従う。未処理事項を残し、照合結果と未確認、[Shinaps規約の取得](../../references/rules.md)の「照合結果に書くこと」を報告する。
+修正が依頼範囲に含まれる場合、今回の変更の自明な修正を適用し、必要な検証を行う。既存箇所や仕様に関係する判断は一問ずつ確認する。ルール自体の書き換え・外部Issueの作成を無断で行わない。ルールの書き換えが許可されたら[Shinaps規約の書き方](../../references/rule-writing.md)に従って全文を作り、同じ文書の「書き込む前に既存の規約と比べる」で比べる（照合用に対象の技術で絞った結果は使わない）。結果と全文の差分を示して同意を受けてから書き込む。未処理事項を残し、照合結果と未確認、[Shinaps規約の取得](../../references/rules.md)の「照合結果に書くこと」を報告する。