@shinaps/skills 0.43.0 → 0.45.0

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` は配列ごと置換し、`[]` で外す。検査を持つ規約の内容（出典とrepoの表示名以外。適用先はscope、repo_ownerのowner、repoのrepoIdで比べる）を変える更新では、更新後の全文で検査を見直し、同じ要求で `checks` を渡す。渡さないと `CHECKS_REQUIRED` で保存されない。見直した結果が同じなら同じ配列を渡す。

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

@@ -4,7 +4,7 @@ Managed Agents は配布CLI `shinaps-skills managed` で導入・依頼・観測
 
 ## アカウント
 
-アカウントは、APIキー1つが属する組織・workspace に利用者が付ける名前で、英小文字・数字と単独のハイフン（`^[a-z0-9]+(-[a-z0-9]+)*$`）にする。同じマシンでは、同じ名前は常に同じ組織・workspace を表すようにする。lock がアカウント名で引かれるので、別の組織に同じ名前を使うと別の組織の lock で適用しようとする（`ant apply` は lock と違う組織・workspace の資格情報を拒否して止まる）。
+アカウントは、APIキー1つが属する組織・workspace に利用者が付ける名前で、先頭は英小文字または数字、以降は英小文字・数字とハイフン（`^[a-z0-9][a-z0-9-]*$`）にする。同じマシンでは、同じ名前は常に同じ組織・workspace を表すようにする。lock がアカウント名で引かれるので、別の組織に同じ名前を使うと別の組織の lock で適用しようとする（`ant apply` は lock と違う組織・workspace の資格情報を拒否して止まる）。
 
 ### APIキー
 

package/plugins/shinaps-claude/references/managed/configuration.schema.json

@@ -30,7 +30,7 @@
       "type": "object",
       "minProperties": 1,
       "propertyNames": {
-        "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$"
+        "pattern": "^[a-z0-9][a-z0-9-]*$"
       },
       "additionalProperties": {
         "type": "object",

package/plugins/shinaps-claude/references/managed/execute.md

@@ -63,7 +63,7 @@ shinaps-skills managed collect --account <name> --session <ID>
 ```
 
 - セッションに紐づく Files（`changes.patch` と作業記録の tar）を、そのアカウントの `sessions/<ID>/outputs/` へ保存し、保存したパスを表示する。同じ名前のファイルは最新のものだけを保存する（lead は毎ターン `changes.patch` を比較元からの全体の差分で置き換える）。名前がファイル名だけでないものは保存せずに止まる。保存したサイズは一覧の値と比べる。
-- CLI は差分を適用しない。ローカルの CLI は git を呼ばず、自分では push しない。push と draft PR の作成は、許可した場合にセッション内の lead が行う。`changes.patch` は合意した base の SHA のチェックアウトで `git apply --check` してから、範囲と受入条件に対する差分を確かめる。適用するかは利用者と決める。
+- collect は差分を適用せず、保存だけを行い、自分では push しない。ローカルsnapshotのprepare・importはGitを使い、importは新しいディレクトリにだけ差分を適用する。既存の作業ツリーへは適用しない。push と draft PR の作成は、許可した場合にセッション内の lead が行う。`changes.patch` は合意した base の SHA のチェックアウトで `git apply --check` してから、範囲と受入条件に対する差分を確かめる。適用するかは利用者と決める。
 - `コミット:` と push 先がある場合は `git fetch origin <head>` で head ブランチを取得し、base の SHA からのコミットと差分を確かめる。
 - `PR:` がある場合は `gh pr view <PR の URL> --json isDraft,baseRefName,headRefName` または GitHub MCP の読み取りで、draft であること・base と head が合意どおりであることを確かめる。
 
@@ -74,9 +74,33 @@ shinaps-skills managed collect --account <name> --session <ID>
 ## 未検証の境界
 
 - `managed setup`・`run`・`status`・`reply`・`collect` のコマンド・フラグ・stdin の本文・出力の形は ant 2.4.0 の公式ソースで照合し、偽の `ant` を使うテストで確かめた。実際の `ant` とクラウドではまだ実行していない。
-- API の側で決まり、ant のソースでは確かめられないこと: 予算 `max_list_cost.amount` がセント単位か、`mount_path: /CLAUDE.md` が `/mnt/session/uploads/CLAUDE.md` に置かれるか、Files の upload・一覧・取得に `files-api-2025-04-14` と `managed-agents-2026-04-01` の両方の beta を付ければよいか（ant の `--beta` は既定の beta を置き換えるので、全ての呼び出しで明示している）、Files の応答の `filename`・`size_bytes`・`created_at`、events の一覧に役割のスレッドの `agent.message` が混ざるか。lock が無い状態での skill の重複は、同じ setup で作る lead の同名確認で止まる。
+- API の側で決まり、ant のソースでは確かめられないこと: `mount_path: /CLAUDE.md` が `/mnt/session/uploads/CLAUDE.md` に置かれるか、Files の upload・一覧・取得に `files-api-2025-04-14` と `managed-agents-2026-04-01` の両方の beta を付ければよいか（ant の `--beta` は既定の beta を置き換えるので、全ての呼び出しで明示している）、Files の応答の `filename`・`size_bytes`・`created_at`、events の一覧に役割のスレッドの `agent.message` が混ざるか。lock が無い状態での skill の重複は、同じ setup で作る lead の同名確認で止まる。
 - マウントしたリポジトリの remote へ `git push` できるか（`authorization_token` が push に使われるか）。最初のセッションで最優先に確かめ、できなければ GitHub MCP の push 用ツール（`create_branch`・`push_files`）を有効にするかを利用者と相談する。
 - commit をチェックアウトしてマウントした作業先から、origin の head ブランチを取得できるか（clone の深さと fetch の資格情報）。
 - GitHub MCP で draft PR を作れるか。`draft: true` は lead への指示でしか担保されない。
 - vault に資格情報を登録できたことは、上の3点の確認にならない。
 - 完了したスレッドが同時実行の枠（25本）を空けるか。ULTRAでは、ラウンドごとに新しく起動する担当を含めて、同時に保つスレッドが多い。
+
+## Routerとローカルコードの往復
+
+Claude Account Routerを使う場合は、アプリでAPIキーとクラウド用アカウントを登録し、アプリ内CLIの `cloud managed` 経由で同じmanagedコマンドを呼ぶ。setupとrunはRouterの選択アカウントを使える。status・reply・collect・importは作成結果のaccountとsession_idを明示し、途中の選択変更を引き継がない。キーを取得して会話や設定へ書き出さない。
+
+GitHubへpushしていないコードも渡す場合は、先にローカルで固定する。
+
+```sh
+shinaps-skills managed prepare --source /path/to/repository
+```
+
+戻り値のfilesとmanifestを確認する。追跡中の現在の内容と、Gitで無視されていない新規ファイルを含む。履歴・Git設定・node_modules・.local・.shinapsは含まない。資格情報ファイルやcheckout外へのシンボリックリンクは拒否する。内容の秘密検出は行わないので、送信対象の確認は必要。submoduleはこの方式では扱わない。
+
+合意済みのrunに `--snapshot <manifest>` を付ける。比較元のSHAは保存済みsnapshotから決まり、`--base-sha` は不要。体制・許可・予算・範囲は通常どおり明示する。ローカル方式はpush・draft_prを受理しない。snapshotはFiles APIで送り、GitHubリポジトリのマウントやGitHub tokenを使わない。元のGit履歴は含まれない。
+
+collectの後、保存されたセッションを新しいローカルcheckoutへ戻せる。
+
+```sh
+shinaps-skills managed import --account personal --session SESSION_ID --destination /path/to/new-checkout
+```
+
+importはAPIキー不要。保存された送信時点のコード（`~/.local/share/shinaps-ai/skills/snapshots/<SHA>/`。アカウントに属さない。prepareごとに複製とbundleが残るので、importと確認が済んだら削除してよい）を復元し、そのセッションのchanges.patchをindexへ適用する。既存のdestinationや元の作業ツリーは上書きしない。適用失敗時は作成したディレクトリを削除してエラーにする。復元先で差分とreport.mdの報告を読み、ローカルの検証を行って作業を再開する。元のブランチへの統合は別途差分を確認して行う。
+
+実クラウドへの送信・実行・回収は未検証。ローカルの代替antと実Gitでの往復テストは、クラウド環境でのgit利用や成果物生成の保証ではない。予算amountのセント単位は[公式仕様](https://platform.claude.com/docs/en/managed-agents/budgets)で確認済みで、リクエスト途中では停止しないため厳密な請求上限とは異なる。

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

@@ -34,6 +34,10 @@ Shinaps AIへ個人規約を登録・更新するときの書き方。短さそ
 
 結果は候補ごとに、比べた既存の規約のidまたは相手の候補、未確定ならその旨、取得の条件、未完了の範囲と返らない範囲を添えて報告する。
 
+## 機械検査
+
+coding の規約は、使えるlintのルールで検査できるかを判断し、できるものには `checks` を付ける。coverageの決め方・補助の確認・書き込みと、検査を持つ規約の内容を変えるときの見直しは[規約の機械検査](lint.md)の「検査を登録・更新する」に従う。
+
 ## 項目の役割
 
 各項目は役割が重ならないようにし、同じ内容を言い換えて繰り返さない。
@@ -56,7 +60,7 @@ Shinaps AIへ個人規約を登録・更新するときの書き方。短さそ
 
 ## scope
 
-全リポジトリに当てはまる判断だけ `scope: user` にして、他のプロジェクトでも通じる表現で書く。同じownerの配下に共通する判断は `scope: repo_owner`、特定のリポジトリの判断は `scope: repo` にして具体的に書く。
+全リポジトリに当てはまる判断だけ `scope: user` にして、他のプロジェクトでも通じる表現で書く。同じownerの配下に共通する判断は `scope: repo_owner`、特定のリポジトリの判断は `scope: repo` にして具体的に書く。`scope: repo` で書くには、[Shinaps規約の取得](rules.md)の「リポジトリを特定する」でrepositoryの `id` を得る。
 
 ## 目安と上限
 

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

@@ -25,12 +25,25 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 対象が確定していない工程（devの入口・`spec`・`explore`・`debug`）は、論点の技術を語彙から推定してよい。`filterUserRulesByLabels` は指定しない。
 
+## リポジトリを特定する
+
+`scope: repo` の規約はGitHubのrepositoryの`id`で識別し、owner・名前は表示にだけ使う。名前は改名で変わり、旧名は別のrepositoryやforkが使えるので、名前の一致を同じrepositoryの根拠にしない。
+
+1. 対象のownerと名前を決める。既定は現在のGit workspaceの `git remote get-url origin`（`github.com/<owner>/<repo>(.git)?` の形）。登録先が別のrepositoryなら、その値にする。この形に当たらなければ（GitHub以外のremoteなど）、`repoOwner`・`repoName`・`repoId` のどれも渡さない。
+2. `gh api repos/<owner>/<repo> --jq '{id, full_name}'` を1回呼ぶ。改名前の名前でもGitHubは改名後のrepositoryを返すので、`id` を `repoId`、`full_name` の `/` の前後を `repoOwner`・`repoName` にする。
+3. 呼出しが失敗したら（`gh` が無い、認証が無い、404など。理由は区別しない）、`repoId`・`repoName` は渡さない。1で決めたownerだけを `repoOwner` にする。
+
+- **取得**: `search_rules` には `repoOwner` と `repoId` を渡し、`repoName` は渡さない（入力エラーになる）。`repoId` が無いときは `scope: repo` の規約が返らないので、「リポジトリを特定できず、このrepositoryの規約は取得していない」と1文で報告する。
+- **新規の書込み**: `scope: repo` の `record_rule`・`record_rules` には `repoOwner`・`repoName`・`repoId` をそろえて渡す。
+- **更新**: `update_rule` で `scope: "repo"` と3つをそろえて渡すのは、適用先を repo にするとき、別のrepositoryに変えるとき、表示名を現在の名前にするとき（2の `full_name` が規約の `repoOwner`・`repoName` と違うとき）だけ。内容だけの更新では適用先の項目を渡さない（`scope` なしで渡すと入力エラーになる）。
+- **`repoId` が得られないとき**: `scope: repo` では書き込まず、`scope: user`・`scope: repo_owner` に変えるか中止するかを利用者に確認する。範囲を変えるときは、[Shinaps規約の書き方](rule-writing.md)の比較をやり直す。
+
 ## 一覧を取る
 
-`search_rules` を `fields: "summary"` で呼ぶ。`repoOwner`・`repoName` は現在のGit workspaceから渡す。対象が確定した照合では `filterUserRulesByLabels: true` を渡す。
+`search_rules` を `fields: "summary"` で呼ぶ。`repoOwner`・`repoId` は「リポジトリを特定する」で決めた値を渡す。対象が確定した照合では `filterUserRulesByLabels: true` を渡す。
 
 ```json
-{ "fields": "summary", "repoOwner": "...", "repoName": "...", "languages": ["typescript", "javascript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
+{ "fields": "summary", "repoOwner": "...", "repoId": 123456789, "languages": ["typescript", "javascript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
 ```
 
 - サーバーは同じ軸をOR、指定した軸の間をANDで判定する。
@@ -60,7 +73,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 [Shinaps規約の書き方](rule-writing.md)の比較に使う規約は、次の条件で取得する。
 
-- `search_rules` は `fields: "summary"` で全ページ取得し、`filterUserRulesByLabels` と `kind` を渡さない。`repoOwner`・`repoName` は、登録先のowner・repoがあればその値、無い分は現在のGit workspaceの値にする。
+- `search_rules` は `fields: "summary"` で全ページ取得し、`filterUserRulesByLabels` と `kind` を渡さない。`repoOwner`・`repoId` は「リポジトリを特定する」で決めた値にする。
 - 公式規約も一覧に載るよう、`list_search_facets` の語彙が8件以内の技術軸（`languages` など）を一つ選び、その全slugを渡す。技術軸はその軸のlabelが無い公式規約にも一致する。`topics` は一致必須で別のtopicの公式規約が返らなくなるので渡さない。渡せる軸が無ければ公式規約の取得は未完了とする。
 - `projectVersions` には確定した版だけを渡す。渡しても渡さなくても、条件に合わない条件付きの公式規約は返らない。
 - 一覧のtitleとlabelから同じ場面を扱う可能性を否定できない規約を選び、「全文を取る」で全文を取得する。文字列の一致で選ばない（公式規約のtitleは英語）。「全文を取る規約を選ぶ」は対象ファイルとの照合の基準で、ここには適用しない。
@@ -70,7 +83,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 ## 担当へ渡す
 
-全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
+`checks` を持つ規約がある照合では、渡す前に[規約の機械検査](lint.md)の「照合で使う」を行い、照合から外す組を決める。全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
 
 ## 照合結果に書くこと
 

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

@@ -76,7 +76,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 ### Phase 1: セッション初期化
 
 1. 最初の質問を受領する。引数が空、またはファイルパスだけなら、理解したいことを `AskUserQuestion` で 1 問だけ確認する
-2. git remoteから `repoOwner` / `repoName` を解決する。今回の依頼に関連する既存の spec・調査レポート・Git の変更履歴を確認し、引き継ぐ決定と根拠を要約する。既存成果物がなければ追加取得は不要。
+2. [Shinaps規約の取得](../../references/rules.md) の「リポジトリを特定する」で `repoOwner` / `repoId` を解決する。今回の依頼に関連する既存の spec・調査レポート・Git の変更履歴を確認し、引き継ぐ決定と根拠を要約する。既存成果物がなければ追加取得は不要。
 3. [Shinaps規約の取得](../../references/rules.md) に従い、最初の質問に対応する推定 facet で一覧を取り、必要な規約全文を取得する。論点が別領域へ移ったら、その時点で facet を取り直す
 4. リポジトリの `CLAUDE.md` / `AGENTS.md` / その他の指示ファイルを読む
 5. `git status --short --branch` と HEAD を記録する。調査対象の revision は未コミット変更を含む現在の worktree をデフォルトにし、production / PR / commit が明示された場合は対象 revision を特定して別に記録する。reset / stash / checkout / clean は行わない

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

@@ -28,7 +28,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 2. 失敗したら `git remote get-url origin` を parse (`github.com/<owner>/<repo>(.git)?` 形式)
 3. それでも決まらないなら **ユーザーにチャットで確認** (「対象は `<owner>/<repo>` でいいですか?」)
 
-解決した `<owner>/<repo>` をユーザーに **必ず提示** し、誤りなら別の repo を入力してもらう。
+解決した `<owner>/<repo>` をユーザーに **必ず提示** し、誤りなら別の repo を入力してもらう。確定した repo を [Shinaps規約の取得](../../references/rules.md) の「リポジトリを特定する」で特定し、`repoId` と現在の `repoOwner`・`repoName` を得る。`repoId` が得られなければ `scope: repo` では投入できないので、ここで止めて利用者に確認する。
 
 ## Step 1. since (期間) をチャットで確認
 
@@ -87,7 +87,7 @@ Good/Bad サンプルコード (examples) の付け方:
 
 投入手順:
 
-- 候補を確定してから、[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 検証で拒否される)。
+- 候補を確定してから、[Shinaps規約の書き方](../../references/rule-writing.md) の「書き込む前に既存の規約と比べる」で候補ごとに結果を決める。既存の規約への**更新**は下の差分確認へ進める。**提示** はブロックの終わりにまとめて利用者へ示し、残りの投入は止めない。**新規**候補だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, repoId, 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` から残りの枠を示し、投入する件数を絞るか既存ルールを整理するかのどちらにするかを利用者に確認する。以降のブロックの抽出・投入にも進まず、利用者の選択を待つ。

package/plugins/shinaps-claude/skills/managed-execute/SKILL.md

@@ -9,10 +9,16 @@ description: Claude Managed Agents の lead へ、アカウントを選んで de
 
 # Managed Agents へ依頼する
 
-[設定とアカウント](../../references/managed/configuration.md)と[依頼と観測の手順](../../references/managed/execute.md)を読んで進める。操作は配布CLIの `managed run`・`status`・`reply`・`collect` で行う。
+[設定とアカウント](../../references/managed/configuration.md)と[依頼と観測の手順](../../references/managed/execute.md)を読んで進める。操作は配布CLIの `managed prepare`・`run`・`status`・`reply`・`collect`・`import` で行う。
 
 - 呼び出しのたびにアカウント・base ブランチと SHA・head ブランチ・範囲と受入条件・体制（LITE・BASIC・ULTRA）・許可・予算を利用者と合意し、引数で明示する。設定・lock・過去の作業から推定しない。
 - 設定（`.shinaps/managed.json`）が無いか旧版なら、手順の「設定を用意する」に従って一問ずつ確認して作る。設定から読むのは `repository` とアカウントの `vault_id` だけで、lead と環境の ID はアカウントの lock から読む。lock が無ければ止め、導入は managed-setup で行う。
 - 計画・実装・レビューの工程と追加の担当は lead に任せ、ここでは指示しない。
-- 回収した差分は適用しない。確認と適用の判断は利用者と行う。push・merge・deploy・release・Issue の更新・セッションのアーカイブは行わない。Linear の進行とは独立した入口である。
+- 回収した差分を既存の作業ツリーへ適用しない（importは新しいディレクトリにだけ復元する）。確認と統合の判断は利用者と行う。push・merge・deploy・release・Issue の更新・セッションのアーカイブは行わない。Linear の進行とは独立した入口である。
 - キーと token は利用者が環境変数に設定する。受け取らない・表示しない・記録しない。
+
+## Routerとローカルでの再開
+
+利用者がClaude Account Routerとの連携を選んだ場合は、アプリ内CLIの `cloud managed` を使う。APIキーを読み出して会話へ返さない。作成結果のaccountとsession_idを保存し、後続操作でその組を使う。
+
+未コミットのローカルコードを渡す依頼では、[ローカルコードの往復](../../references/managed/execute.md#routerとローカルコードの往復)に従ってprepareし、送信する一覧・内容を確認してからsnapshotを指定する。比較元はsnapshotのSHA。collect後、ローカルでの再開が許可されていればimportで新規checkoutへ復元し、差分と報告を確認してQAへ進む。元の作業ツリーには自動適用しない。

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) に従って書き込む全文を作る。新規のときは scope (user / repo_owner / repo) も選ばせる (横断的なら user、この repo 限定なら repo)。同じ文書の「書き込む前に既存の規約と比べる」で比べ (Step 1 の結果はファイルの技術で絞っているので使わない)、結果と全文の差分を示して同意を受けてから shinaps-ai MCP server の `record_rule` (新規) or `update_rule` (既存修正) を実行
+3. **ルールの方を修正する** — 規約自体が現実と乖離している場合。[Shinaps規約の書き方](../../references/rule-writing.md) に従って書き込む全文を作る。新規のときは scope (user / repo_owner / repo) も選ばせる (横断的なら user、この repo 限定なら repo。repo は [Shinaps規約の取得](../../references/rules.md) の「リポジトリを特定する」で得た `repoId` を添える)。同じ文書の「書き込む前に既存の規約と比べる」で比べ (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.43.0",
+  "version": "0.45.0",
   "description": "Shinaps AIのCodex向け開発ワークフロー",
   "skills": "./skills/"
 }

package/plugins/shinaps-codex/managed-agents/skills/dev-managed-cc/references/launch.md

@@ -71,3 +71,7 @@ PR: <draft PR の URL。無ければ なし>
 | hooks | 未対応 |
 | permission mode | 定義の `permission_policy` で固定 |
 | セッション予算 | セッション作成時の `max_list_cost` で付ける |
+
+## ローカルsnapshotで始める場合
+
+初回メッセージにsource.bundleが指定されている場合は、通常のHEAD確認より先に `/mnt/session/uploads/source.bundle` を指定された作業先へcloneする。比較元は初回メッセージのsnapshot SHAとし、GitHubへのアクセスや元の履歴を前提にしない。成果物は上記の一時indexで比較元からの全差分を出力する手順に従い、変更内容・検証結果・未完了事項を `/mnt/session/outputs/report.md` にも残す。

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.43.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.43.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.45.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.45.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` は配列ごと置換し、`[]` で外す。検査を持つ規約の内容（出典とrepoの表示名以外。適用先はscope、repo_ownerのowner、repoのrepoIdで比べる）を変える更新では、更新後の全文で検査を見直し、同じ要求で `checks` を渡す。渡さないと `CHECKS_REQUIRED` で保存されない。見直した結果が同じなら同じ配列を渡す。

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

@@ -4,7 +4,7 @@ Managed Agents は配布CLI `shinaps-skills managed` で導入・依頼・観測
 
 ## アカウント
 
-アカウントは、APIキー1つが属する組織・workspace に利用者が付ける名前で、英小文字・数字と単独のハイフン（`^[a-z0-9]+(-[a-z0-9]+)*$`）にする。同じマシンでは、同じ名前は常に同じ組織・workspace を表すようにする。lock がアカウント名で引かれるので、別の組織に同じ名前を使うと別の組織の lock で適用しようとする（`ant apply` は lock と違う組織・workspace の資格情報を拒否して止まる）。
+アカウントは、APIキー1つが属する組織・workspace に利用者が付ける名前で、先頭は英小文字または数字、以降は英小文字・数字とハイフン（`^[a-z0-9][a-z0-9-]*$`）にする。同じマシンでは、同じ名前は常に同じ組織・workspace を表すようにする。lock がアカウント名で引かれるので、別の組織に同じ名前を使うと別の組織の lock で適用しようとする（`ant apply` は lock と違う組織・workspace の資格情報を拒否して止まる）。
 
 ### APIキー
 

package/plugins/shinaps-codex/references/managed/configuration.schema.json

@@ -30,7 +30,7 @@
       "type": "object",
       "minProperties": 1,
       "propertyNames": {
-        "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$"
+        "pattern": "^[a-z0-9][a-z0-9-]*$"
       },
       "additionalProperties": {
         "type": "object",

package/plugins/shinaps-codex/references/managed/execute.md

@@ -63,7 +63,7 @@ shinaps-skills managed collect --account <name> --session <ID>
 ```
 
 - セッションに紐づく Files（`changes.patch` と作業記録の tar）を、そのアカウントの `sessions/<ID>/outputs/` へ保存し、保存したパスを表示する。同じ名前のファイルは最新のものだけを保存する（lead は毎ターン `changes.patch` を比較元からの全体の差分で置き換える）。名前がファイル名だけでないものは保存せずに止まる。保存したサイズは一覧の値と比べる。
-- CLI は差分を適用しない。ローカルの CLI は git を呼ばず、自分では push しない。push と draft PR の作成は、許可した場合にセッション内の lead が行う。`changes.patch` は合意した base の SHA のチェックアウトで `git apply --check` してから、範囲と受入条件に対する差分を確かめる。適用するかは利用者と決める。
+- collect は差分を適用せず、保存だけを行い、自分では push しない。ローカルsnapshotのprepare・importはGitを使い、importは新しいディレクトリにだけ差分を適用する。既存の作業ツリーへは適用しない。push と draft PR の作成は、許可した場合にセッション内の lead が行う。`changes.patch` は合意した base の SHA のチェックアウトで `git apply --check` してから、範囲と受入条件に対する差分を確かめる。適用するかは利用者と決める。
 - `コミット:` と push 先がある場合は `git fetch origin <head>` で head ブランチを取得し、base の SHA からのコミットと差分を確かめる。
 - `PR:` がある場合は `gh pr view <PR の URL> --json isDraft,baseRefName,headRefName` または GitHub MCP の読み取りで、draft であること・base と head が合意どおりであることを確かめる。
 
@@ -74,9 +74,33 @@ shinaps-skills managed collect --account <name> --session <ID>
 ## 未検証の境界
 
 - `managed setup`・`run`・`status`・`reply`・`collect` のコマンド・フラグ・stdin の本文・出力の形は ant 2.4.0 の公式ソースで照合し、偽の `ant` を使うテストで確かめた。実際の `ant` とクラウドではまだ実行していない。
-- API の側で決まり、ant のソースでは確かめられないこと: 予算 `max_list_cost.amount` がセント単位か、`mount_path: /CLAUDE.md` が `/mnt/session/uploads/CLAUDE.md` に置かれるか、Files の upload・一覧・取得に `files-api-2025-04-14` と `managed-agents-2026-04-01` の両方の beta を付ければよいか（ant の `--beta` は既定の beta を置き換えるので、全ての呼び出しで明示している）、Files の応答の `filename`・`size_bytes`・`created_at`、events の一覧に役割のスレッドの `agent.message` が混ざるか。lock が無い状態での skill の重複は、同じ setup で作る lead の同名確認で止まる。
+- API の側で決まり、ant のソースでは確かめられないこと: `mount_path: /CLAUDE.md` が `/mnt/session/uploads/CLAUDE.md` に置かれるか、Files の upload・一覧・取得に `files-api-2025-04-14` と `managed-agents-2026-04-01` の両方の beta を付ければよいか（ant の `--beta` は既定の beta を置き換えるので、全ての呼び出しで明示している）、Files の応答の `filename`・`size_bytes`・`created_at`、events の一覧に役割のスレッドの `agent.message` が混ざるか。lock が無い状態での skill の重複は、同じ setup で作る lead の同名確認で止まる。
 - マウントしたリポジトリの remote へ `git push` できるか（`authorization_token` が push に使われるか）。最初のセッションで最優先に確かめ、できなければ GitHub MCP の push 用ツール（`create_branch`・`push_files`）を有効にするかを利用者と相談する。
 - commit をチェックアウトしてマウントした作業先から、origin の head ブランチを取得できるか（clone の深さと fetch の資格情報）。
 - GitHub MCP で draft PR を作れるか。`draft: true` は lead への指示でしか担保されない。
 - vault に資格情報を登録できたことは、上の3点の確認にならない。
 - 完了したスレッドが同時実行の枠（25本）を空けるか。ULTRAでは、ラウンドごとに新しく起動する担当を含めて、同時に保つスレッドが多い。
+
+## Routerとローカルコードの往復
+
+Claude Account Routerを使う場合は、アプリでAPIキーとクラウド用アカウントを登録し、アプリ内CLIの `cloud managed` 経由で同じmanagedコマンドを呼ぶ。setupとrunはRouterの選択アカウントを使える。status・reply・collect・importは作成結果のaccountとsession_idを明示し、途中の選択変更を引き継がない。キーを取得して会話や設定へ書き出さない。
+
+GitHubへpushしていないコードも渡す場合は、先にローカルで固定する。
+
+```sh
+shinaps-skills managed prepare --source /path/to/repository
+```
+
+戻り値のfilesとmanifestを確認する。追跡中の現在の内容と、Gitで無視されていない新規ファイルを含む。履歴・Git設定・node_modules・.local・.shinapsは含まない。資格情報ファイルやcheckout外へのシンボリックリンクは拒否する。内容の秘密検出は行わないので、送信対象の確認は必要。submoduleはこの方式では扱わない。
+
+合意済みのrunに `--snapshot <manifest>` を付ける。比較元のSHAは保存済みsnapshotから決まり、`--base-sha` は不要。体制・許可・予算・範囲は通常どおり明示する。ローカル方式はpush・draft_prを受理しない。snapshotはFiles APIで送り、GitHubリポジトリのマウントやGitHub tokenを使わない。元のGit履歴は含まれない。
+
+collectの後、保存されたセッションを新しいローカルcheckoutへ戻せる。
+
+```sh
+shinaps-skills managed import --account personal --session SESSION_ID --destination /path/to/new-checkout
+```
+
+importはAPIキー不要。保存された送信時点のコード（`~/.local/share/shinaps-ai/skills/snapshots/<SHA>/`。アカウントに属さない。prepareごとに複製とbundleが残るので、importと確認が済んだら削除してよい）を復元し、そのセッションのchanges.patchをindexへ適用する。既存のdestinationや元の作業ツリーは上書きしない。適用失敗時は作成したディレクトリを削除してエラーにする。復元先で差分とreport.mdの報告を読み、ローカルの検証を行って作業を再開する。元のブランチへの統合は別途差分を確認して行う。
+
+実クラウドへの送信・実行・回収は未検証。ローカルの代替antと実Gitでの往復テストは、クラウド環境でのgit利用や成果物生成の保証ではない。予算amountのセント単位は[公式仕様](https://platform.claude.com/docs/en/managed-agents/budgets)で確認済みで、リクエスト途中では停止しないため厳密な請求上限とは異なる。

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

@@ -34,6 +34,10 @@ Shinaps AIへ個人規約を登録・更新するときの書き方。短さそ
 
 結果は候補ごとに、比べた既存の規約のidまたは相手の候補、未確定ならその旨、取得の条件、未完了の範囲と返らない範囲を添えて報告する。
 
+## 機械検査
+
+coding の規約は、使えるlintのルールで検査できるかを判断し、できるものには `checks` を付ける。coverageの決め方・補助の確認・書き込みと、検査を持つ規約の内容を変えるときの見直しは[規約の機械検査](lint.md)の「検査を登録・更新する」に従う。
+
 ## 項目の役割
 
 各項目は役割が重ならないようにし、同じ内容を言い換えて繰り返さない。
@@ -56,7 +60,7 @@ Shinaps AIへ個人規約を登録・更新するときの書き方。短さそ
 
 ## scope
 
-全リポジトリに当てはまる判断だけ `scope: user` にして、他のプロジェクトでも通じる表現で書く。同じownerの配下に共通する判断は `scope: repo_owner`、特定のリポジトリの判断は `scope: repo` にして具体的に書く。
+全リポジトリに当てはまる判断だけ `scope: user` にして、他のプロジェクトでも通じる表現で書く。同じownerの配下に共通する判断は `scope: repo_owner`、特定のリポジトリの判断は `scope: repo` にして具体的に書く。`scope: repo` で書くには、[Shinaps規約の取得](rules.md)の「リポジトリを特定する」でrepositoryの `id` を得る。
 
 ## 目安と上限
 

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

@@ -25,12 +25,25 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 対象が確定していない工程（devの入口・`spec`・`explore`・`debug`）は、論点の技術を語彙から推定してよい。`filterUserRulesByLabels` は指定しない。
 
+## リポジトリを特定する
+
+`scope: repo` の規約はGitHubのrepositoryの`id`で識別し、owner・名前は表示にだけ使う。名前は改名で変わり、旧名は別のrepositoryやforkが使えるので、名前の一致を同じrepositoryの根拠にしない。
+
+1. 対象のownerと名前を決める。既定は現在のGit workspaceの `git remote get-url origin`（`github.com/<owner>/<repo>(.git)?` の形）。登録先が別のrepositoryなら、その値にする。この形に当たらなければ（GitHub以外のremoteなど）、`repoOwner`・`repoName`・`repoId` のどれも渡さない。
+2. `gh api repos/<owner>/<repo> --jq '{id, full_name}'` を1回呼ぶ。改名前の名前でもGitHubは改名後のrepositoryを返すので、`id` を `repoId`、`full_name` の `/` の前後を `repoOwner`・`repoName` にする。
+3. 呼出しが失敗したら（`gh` が無い、認証が無い、404など。理由は区別しない）、`repoId`・`repoName` は渡さない。1で決めたownerだけを `repoOwner` にする。
+
+- **取得**: `search_rules` には `repoOwner` と `repoId` を渡し、`repoName` は渡さない（入力エラーになる）。`repoId` が無いときは `scope: repo` の規約が返らないので、「リポジトリを特定できず、このrepositoryの規約は取得していない」と1文で報告する。
+- **新規の書込み**: `scope: repo` の `record_rule`・`record_rules` には `repoOwner`・`repoName`・`repoId` をそろえて渡す。
+- **更新**: `update_rule` で `scope: "repo"` と3つをそろえて渡すのは、適用先を repo にするとき、別のrepositoryに変えるとき、表示名を現在の名前にするとき（2の `full_name` が規約の `repoOwner`・`repoName` と違うとき）だけ。内容だけの更新では適用先の項目を渡さない（`scope` なしで渡すと入力エラーになる）。
+- **`repoId` が得られないとき**: `scope: repo` では書き込まず、`scope: user`・`scope: repo_owner` に変えるか中止するかを利用者に確認する。範囲を変えるときは、[Shinaps規約の書き方](rule-writing.md)の比較をやり直す。
+
 ## 一覧を取る
 
-`search_rules` を `fields: "summary"` で呼ぶ。`repoOwner`・`repoName` は現在のGit workspaceから渡す。対象が確定した照合では `filterUserRulesByLabels: true` を渡す。
+`search_rules` を `fields: "summary"` で呼ぶ。`repoOwner`・`repoId` は「リポジトリを特定する」で決めた値を渡す。対象が確定した照合では `filterUserRulesByLabels: true` を渡す。
 
 ```json
-{ "fields": "summary", "repoOwner": "...", "repoName": "...", "languages": ["typescript", "javascript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
+{ "fields": "summary", "repoOwner": "...", "repoId": 123456789, "languages": ["typescript", "javascript"], "platforms": ["cloudflare-workers"], "frameworks": ["hono"], "filterUserRulesByLabels": true }
 ```
 
 - サーバーは同じ軸をOR、指定した軸の間をANDで判定する。
@@ -60,7 +73,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 [Shinaps規約の書き方](rule-writing.md)の比較に使う規約は、次の条件で取得する。
 
-- `search_rules` は `fields: "summary"` で全ページ取得し、`filterUserRulesByLabels` と `kind` を渡さない。`repoOwner`・`repoName` は、登録先のowner・repoがあればその値、無い分は現在のGit workspaceの値にする。
+- `search_rules` は `fields: "summary"` で全ページ取得し、`filterUserRulesByLabels` と `kind` を渡さない。`repoOwner`・`repoId` は「リポジトリを特定する」で決めた値にする。
 - 公式規約も一覧に載るよう、`list_search_facets` の語彙が8件以内の技術軸（`languages` など）を一つ選び、その全slugを渡す。技術軸はその軸のlabelが無い公式規約にも一致する。`topics` は一致必須で別のtopicの公式規約が返らなくなるので渡さない。渡せる軸が無ければ公式規約の取得は未完了とする。
 - `projectVersions` には確定した版だけを渡す。渡しても渡さなくても、条件に合わない条件付きの公式規約は返らない。
 - 一覧のtitleとlabelから同じ場面を扱う可能性を否定できない規約を選び、「全文を取る」で全文を取得する。文字列の一致で選ばない（公式規約のtitleは英語）。「全文を取る規約を選ぶ」は対象ファイルとの照合の基準で、ここには適用しない。
@@ -70,7 +83,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 ## 担当へ渡す
 
-全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
+`checks` を持つ規約がある照合では、渡す前に[規約の機械検査](lint.md)の「照合で使う」を行い、照合から外す組を決める。全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
 
 ## 照合結果に書くこと
 

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

@@ -10,7 +10,7 @@ description: GitHubの過去PRレビューから繰り返し適用できる規
 1. `gh`で期間内のマージ済みPRを取得する。ページングし、並び順と日付フィルターの関係を守る。更新日時順の一覧で古いマージ日時を一件見つけても、それ以降の取得を打ち切らない。
 2. PRのreview本文・inline comment・conversation commentを取得する。PR descriptionはレビュー指摘として扱わない。APIのBot種別は除外し、判断が必要な投稿者は確認する。認証情報やリポジトリ全体をサービスへ送信しない。
 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を示して、件数を絞るか既存ルールを整理するかを利用者に確認する。それより前の呼出しで投入した分は保存されている。以降のまとまりの抽出・投入にも進まず、利用者の選択を待つ。
+4. 候補を[Shinaps規約の書き方](../../references/rule-writing.md)に従って書き、同じ文書の「書き込む前に既存の規約と比べる」で候補ごとに結果を決める。提示の候補はまとまりの終わりに示し、残りの投入は止めない。新規の候補だけを対象repoのスコープへ、実際のMCPツールのスキーマに従って登録する。対象repoは[Shinaps規約の取得](../../references/rules.md)の「リポジトリを特定する」でrepositoryの`id`を得て指定し、得られなければrepoのスコープでは登録せず利用者に確認する。応答は入力の位置と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)に従って初期化・保全する。

package/plugins/shinaps-codex/skills/managed-execute/SKILL.md

@@ -9,10 +9,16 @@ description: Claude Managed Agents の lead へ、アカウントを選んで de
 
 # Managed Agents へ依頼する
 
-[設定とアカウント](../../references/managed/configuration.md)と[依頼と観測の手順](../../references/managed/execute.md)を読んで進める。操作は配布CLIの `managed run`・`status`・`reply`・`collect` で行う。
+[設定とアカウント](../../references/managed/configuration.md)と[依頼と観測の手順](../../references/managed/execute.md)を読んで進める。操作は配布CLIの `managed prepare`・`run`・`status`・`reply`・`collect`・`import` で行う。
 
 - 呼び出しのたびにアカウント・base ブランチと SHA・head ブランチ・範囲と受入条件・体制（LITE・BASIC・ULTRA）・許可・予算を利用者と合意し、引数で明示する。設定・lock・過去の作業から推定しない。
 - 設定（`.shinaps/managed.json`）が無いか旧版なら、手順の「設定を用意する」に従って一問ずつ確認して作る。設定から読むのは `repository` とアカウントの `vault_id` だけで、lead と環境の ID はアカウントの lock から読む。lock が無ければ止め、導入は managed-setup で行う。
 - 計画・実装・レビューの工程と追加の担当は lead に任せ、ここでは指示しない。
-- 回収した差分は適用しない。確認と適用の判断は利用者と行う。push・merge・deploy・release・Issue の更新・セッションのアーカイブは行わない。Linear の進行とは独立した入口である。
+- 回収した差分を既存の作業ツリーへ適用しない（importは新しいディレクトリにだけ復元する）。確認と統合の判断は利用者と行う。push・merge・deploy・release・Issue の更新・セッションのアーカイブは行わない。Linear の進行とは独立した入口である。
 - キーと token は利用者が環境変数に設定する。受け取らない・表示しない・記録しない。
+
+## Routerとローカルでの再開
+
+利用者がClaude Account Routerとの連携を選んだ場合は、アプリ内CLIの `cloud managed` を使う。APIキーを読み出して会話へ返さない。作成結果のaccountとsession_idを保存し、後続操作でその組を使う。
+
+未コミットのローカルコードを渡す依頼では、[ローカルコードの往復](../../references/managed/execute.md#routerとローカルコードの往復)に従ってprepareし、送信する一覧・内容を確認してからsnapshotを指定する。比較元はsnapshotのSHA。collect後、ローカルでの再開が許可されていればimportで新規checkoutへ復元し、差分と報告を確認してQAへ進む。元の作業ツリーには自動適用しない。

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

@@ -7,6 +7,8 @@ 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)に従う。結果は現在のコードで検証し重複をまとめる。独立検証をしなければそのように報告する。