@shinaps/skills 0.33.2 → 0.34.1

package/README.md

@@ -1,6 +1,6 @@
 # shinaps-skills
 
-Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexにはそれぞれに適したplugin・カスタムエージェントとして配布する。実装はClaude Codeが行い、Codexは進行・QA・レビュー等を担当する。スキルのダウンロードと導入にShinaps AIのアカウントは不要。サービスのrule検索・登録を使うときにアカウント作成と認証を行う。
+Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexにはそれぞれに適したplugin・カスタムエージェントとして配布する。実装はClaude Codeが行い、Codexは進行・QA・レビュー等を担当する。Claude Managed Agents向けには、draft PRまで進むdev工程の共通定義を両pluginの `managed-agents/` に置き、`managed-setup` で利用者の組織へ導入し、`managed-execute` で依頼する。スキルのダウンロードと導入にShinaps AIのアカウントは不要。サービスのrule検索・登録を使うときにアカウント作成と認証を行う。
 
 ## プロジェクトごとの条件
 
@@ -16,12 +16,13 @@ sharedで採用する `instructions.md` は共有JSONの `references.specificati
 
 0.33.0から `.shinaps/linear.json`（`config_version: 2`）を使います。`config_version: 1`・`implementation_skill`・`review_flow.tool`・許可の `codex_task`/`managed_session:*`、旧YAML・scalar review_flowは受け付けず、[移行手順](plugins/shinaps-claude/references/linear/configuration.md#config_version-1-からの移行)に従います。
 
-CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.33.2` を導入し、`shinaps-skills --version` で確認します。`shinaps-skills validate-linear-config <明示ファイル>` は同梱schemaだけで検証し、ネットワーク取得・正本探索・Git操作・入力変更は行いません。`$schema` は固定URLによるエディタ補助で、契約の正本は[同梱schema](plugins/shinaps-claude/references/linear/configuration.schema.json)です。
+CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.34.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)）。
 
 ```sh
-npm install -g @shinaps/skills@0.33.2
+npm install -g @shinaps/skills@0.34.1
 shinaps-skills --version
 shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
+shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.json
 ```
 
 ## スキル
@@ -36,17 +37,19 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 | `refine` | Shinaps AIのruleと実ファイルを照合する |
 | `extract-rules` | PRレビューからruleを抽出する |
 | `simplify` | 目的から見直して不要な構造や手順を削る |
-| `commit` | 各単位のreview_flowに従い、autoはAIがレビュー・コミット、manualはAIが退避・stage・提示し、人と修正を相談して、人の単位承認後にAIがコミットする |
+| `commit` | 各単位のreview_flowに従い、autoはAIがレビュー・コミット、manualは人の開始依頼で分割案を示し、人が単位ごとに依頼したコミットを行う |
 | `create-pr` | リポジトリの規約に合わせてPRを作成する |
 | `release` | 公開条件を確定し、対象バージョンの利用可能性を確認する |
 | `linear-plan` | 相談・必要なspec/explore・Issue作成と整理・プロジェクト設定を行い、実装前で止める |
 | `linear-execute` | Issue単体・Cycle全体・バックログ消化を選び、設定に従って実装・QA・許可された公開を進める |
+| `managed-setup` | Claude Managed Agentsの共通dev構成を自分の組織へ導入・更新する。既存のlockを使い、重複して作らない |
+| `managed-execute` | Managed Agentsのleadへdevを依頼し、観測・質問の取り次ぎ・成果物とdraft PRの確認を行う |
 
 コミット・PR・リリースは、利用者の依頼またはLinear進行で合意済みの継続許可に従う。[共通設定](plugins/shinaps-claude/references/linear/configuration.md)・[担当と工程](plugins/shinaps-claude/references/linear/workflow.md)・[終了と待機](plugins/shinaps-claude/references/linear/execution.md)を参照し、必要な前工程が揃えば再確認せずに進む。単独スキル利用にはLinear進行や新しいゴールを必須にしない。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
 
-`linear-execute` は初版では利用者本人の環境向けで、Codexが進行役として進行・Agent QA・Issueの記録・人への窓口を担当し、Claude Codeが実装・修正・コミットを行う。主フローは着手・実装・差分確定・公開確認・結果報告の5工程。運用項目は明示必須で、未記載を既定値で補わない。経路は着手時に通常の `review_flow.mode` で決まる。autoはCodexがローカル `claude -p` を起動して同じsessionをresumeし（許可 `claude_cli`、[CLI手順](plugins/shinaps-claude/references/linear/claude-cli.md)）、CLIの既存権限・model・effort・pluginsを保持する。manualはWebStorm内の対話Claude CodeセッションへBridgeで依頼する（許可 `bridge_request`、[Bridge](plugins/shinaps-claude/references/linear/bridge.md)）。初期体制はClaudeのメインが決めて報告し、Codexは判断の材料を渡す。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/linear/` に置く。`references/linear/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
+`linear-execute` は初版では利用者本人の環境向けで、Codexが進行役として進行・Agent QA・Issueの記録・人への窓口を担当し、Claude Codeが実装・修正・コミットを行う。主フローは着手・実装・差分確定・公開確認・結果報告の5工程。運用項目は明示必須で、未記載を既定値で補わない。経路は着手時に通常の `review_flow.mode` で決まる。autoはCodexがローカル `claude -p` を起動して同じsessionをresumeし（許可 `claude_cli`、[CLI手順](plugins/shinaps-claude/references/linear/claude-cli.md)）、CLIの既存権限・model・effort・pluginsを保持する。manualはWebStorm内の対話Claude CodeセッションへBridgeで依頼する（許可 `bridge_request`、[Bridge](plugins/shinaps-claude/references/linear/bridge.md)）。manualではQA後もCodexはcommitを依頼せず、人の依頼でClaudeがcommitする。初期体制はClaudeのメインが決めて報告し、Codexは判断の材料を渡す。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/linear/` に置く。`references/linear/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
 
-`review_flow: { "mode": "auto" }` はAIが自然な単位を決め、独立レビュー・QA後にstage・commitする。`review_flow: { "mode": "manual" }` はAIが単位外を安全に退避して単位をstage・提示し、人と修正を相談し、人がその単位を承認した後にAIがcommitする。両方のstage・AI commit権限は利用者との明示合意に含まれ、未合意ファイルからは得ない。`path_policy_overrides` は `paths` と `review_flow` だけを持つ。全変更が一つのルールで覆われる単位だけ適用し、改名は旧新両パスを判定する。競合時は止める。旧 `human_code_review`・`commit_mode`・permissionsのstage/commit・パス別ai_commitは明示移行が必要。[共通設定](plugins/shinaps-claude/references/linear/configuration.md#パス別の方針)を参照する。
+`review_flow: { "mode": "auto" }` はAIが自然な単位を決め、独立レビュー・QA後にstage・commitする。`review_flow: { "mode": "manual" }` はAIがレビュー待ちを明示し、人がWebStormで差分を確認する。人のコミット開始依頼でAIが分割案を示し、人がその単位のコミットを依頼したらAIが単位外を安全に退避して単位をstage・検証・commitする。両方のstage・AI commit権限は利用者との明示合意に含まれ、未合意ファイルからは得ない。`path_policy_overrides` は `paths` と `review_flow` だけを持つ。全変更が一つのルールで覆われる単位だけ適用し、改名は旧新両パスを判定する。競合時は止める。旧 `human_code_review`・`commit_mode`・permissionsのstage/commit・パス別ai_commitは明示移行が必要。[共通設定](plugins/shinaps-claude/references/linear/configuration.md#パス別の方針)を参照する。
 
 0.29.0では旧 `document_only_changes: ai_commit` を廃止した。利用先では依存工程を止め、具体的なパス例外への移行または例外廃止を合意する。説明だけの変更の許可とは同値でないため自動変換しない。旧 `none` もJSONへ明示移行し、新規設定は `path_policy_overrides: []` にする。
 
@@ -56,13 +59,14 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 ### dev の入口と体制
 
-実装の入口は Claude Code の `dev-claude` だけで、Codexに実装の入口はない。メインは利用者のClaude CLI・セッションの設定（model・effort）を保持し、起動引数で上書きしない。担当は登録エージェントの定義（Opus / medium）で動く。
+ローカルの実装の入口は Claude Code の `dev-claude` だけで、Codexに実装の入口はない。Claude Managed Agentsは別runtimeで、`managed-setup`・`managed-execute` から使う。「[Claude Managed Agents](#claude-managed-agents)」節で扱う。メインは利用者のClaude CLI・セッションの設定（model・effort）を保持し、起動引数で上書きしない。担当は登録エージェントの定義（Opus / medium）で動く。
 
 [実装体制の判断](plugins/shinaps-claude/references/dev/staffing.md)に従い、devのメインが設計前に役割別の人数・理由・専任なしの責任者・必須検証を決める。linear-executeでは進行役のCodexが判断の材料を渡し、メインが決めて報告する。不確実性・影響範囲・失敗時の影響を基準に、途中でも必要な担当を追加する。人数を増やすだけで許可・予算・品質条件は変えない。
 
 小さく明確な変更はメインが計画し、実装1体と独立コードレビュー1体で進められる。設計の比較や重要な契約の独立確認が必要なら該当する役割だけ増やす。規約照合・簡素化・指摘検証は専任なしでも責任者を決めて行う。
 
 - 工程と体制基準はClaude版を編集元としてCodexへ複製する。起動手順だけはruntimeごとに異なる。
+- Managedの `staffing.md`・`workflow.md`・`launch.md` はClaude版を編集元に写した適応版で、一致はテストしない。Claude版の工程・体制基準を変えたらManagedへの適用可否を判断する。
 - Claudeは登録エージェント、Codexは名前付きサブエージェントを使う。モデル・推論の設定は今回の人数判断で変更しない。
 - Claudeのexplore・spec・review・debugからは `dev-claude` へ引き継ぐ。ClaudeのdevはSkillツールからの起動も許可する。Codexのスキルは実装へ引き継がず、Linear進行では `linear-execute` でClaudeへ依頼する。
 - テスト方針は各版の `references/testing.md` を正本とし、役割定義に同じ段落を複製して検証する。
@@ -128,12 +132,40 @@ macOS以外では予定実行の登録に対応していないため手動更新
 
 Claude Codeは標準のmarketplace自動更新機能を使う。`/plugin` のMarketplacesから対象marketplaceのauto-updateを有効にする。GitHubから自動取得するにはリモートmarketplaceを登録する必要があり、ローカルcheckout登録ではソースのgit pullまで自動実行しない。
 
+## Claude Managed Agents
+
+両pluginの `managed-agents/` は、Claude Managed Agentsでdev工程を進めるための共通定義である。lead `shinaps-dev-managed-cc`、devの5役割、skill `dev-managed-cc`、環境 `shinaps-dev` を置く。クラウドのIDを記録する `claude-lock.json` と実設定は利用者ごとのものなので、作業先の `.shinaps/` に置き、公開する定義には含めない。予定実行はこの構成に含めない。
+
+- leadはFable 5.1（`claude-fable-5-1` / medium）、役割はOpus 5.5（`claude-opus-5-5` / medium）で動く。全agent定義に `speed: standard` を明示する（既存リソースに残るfastを戻すため）。
+- 体制は `dev-claude` と同じ基準でleadが作業ごとに決める。実装者と独立したコードレビューは最低1体で、規約照合もその担当が行う。refine担当とultraの入口は置かない。explorerとreview-verifierも置かず、探索はlead・設計担当・実装担当が、指摘の検証は設計責任者が行う。
+- Shinaps AIのMCPとruleを使わない。規約はマウントしたリポジトリの `AGENTS.md`・`CLAUDE.md` と参照先、添付された利用者CLAUDE.mdだけで、最終報告ではShinaps AI ruleを未照合とする。
+- 初回メッセージにリポジトリ・base・head・範囲と受入条件・許可・予算が揃わなければ、leadは作業を始めず欠落を質問する。許可はそのメッセージで明示された操作だけで、構成の導入からは生じない。
+- 終了地点は範囲を限ったコミット・headブランチへのpush・draft PR。merge・deploy・release・Issueの更新はしない。CodexのQAはセッションの外で、PRの後に行う。
+
+### 定義の更新と適用
+
+1. 共通定義は `plugins/shinaps-claude/managed-agents/` を編集元とし、`plugins/shinaps-codex/managed-agents/` へ同じ内容を複製する。一致はテストで確認する。
+2. 作業先では `managed-setup` が、`.shinaps/managed.json`（[設定](plugins/shinaps-claude/references/managed/configuration.md)）の `definitions` が指すディレクトリ（既定は `.shinaps/managed/`、Git対象外）へ共通定義をコピーする。
+3. そのディレクトリで `ant apply --dry-run .` を実行し、計画を確認する。
+4. 利用者の合意後に `ant apply .` で適用する。`--prune`・`--force` は使わず、リソースを削除しない。
+5. 適用前に複製したlock（`.shinaps/work/` に置く）と比べ、更新したリソースの `version`・`hash`・`remote_hash` 以外が変わっていないことを確かめる。
+
+手順・安全上の注意・止める条件は[導入と更新の手順](plugins/shinaps-claude/references/managed/setup.md)にある。セッションの依頼・観測・未検証の境界は[依頼と観測の手順](plugins/shinaps-claude/references/managed/execute.md)にある。これらはpluginに含まれ、どちらのruntimeからも読める。
+
+### このリポジトリのlock
+
+shinaps-skills自身のlockは0.34.0で `.shinaps/managed/claude-lock.json`（Git対象外）へ移した。以前の内容は `git show 8679d8f:managed-agents/claude-lock.json` で取り出せる。
+
+lockには現在のリソース8件（lead・5役割・skill `dev-managed-cc`・環境 `shinaps-dev`）と、過去のrefineの項目がある。定義を変えずにdry-runすると `Everything is up to date.`（8 unchanged）と、`./agents/shinaps-refine-agent.md` のソースが無い警告1件になる。これは想定どおりで、`--prune` を付けない。旧refineの項目は過去のセッションの参照用に残しており、現在のleadからは使われない。旧CC Ultraのleadと専用skill、旧explorerとreview-verifierはクラウドでアーカイブ済みで、lockでも追跡しない。
+
+GitHub MCP（`https://api.githubcopilot.com/mcp`）の資格情報はvaultに登録し、セッション作成時に渡す。vaultの資格情報はMCPサーバーのURLで照合されるので、lead定義のURLと末尾のスラッシュまで揃える。leadは最後のメッセージの1行目に `状態: 完了`・`状態: 質問`・`状態: 未完了` を書き、`changes.patch` と作業記録のtarを `/mnt/session/outputs/` に置く（[起動手順](plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/launch.md)）。マウントしたリポジトリへのpushとdraft PRの作成は、実際のセッションで確かめるまで未検証である。
+
 ## 開発と配布
 
 - Claude版: `plugins/shinaps-claude/`、marketplaceは`.claude-plugin/marketplace.json`
 - Codex版: `plugins/shinaps-codex/`、marketplaceは`.agents/plugins/marketplace.json`
 - Codexカスタムエージェント: `plugins/shinaps-codex/agents/`
-- `managed-agents/claude-lock.json` は既存クラウドリソースの記録として保持する。`managed-agents/` で `ant` を実行しない（apply・prune・削除をしない）
+- Claude Managed Agents版: 両pluginの `managed-agents/`（Claude版が編集元）。pluginと一緒に配布され、npmパッケージの `plugins/` にも含まれる。適用は作業先の `.shinaps/managed/` へコピーしてから「Claude Managed Agents」節の手順で行い、`--prune`・`--force` を使わない
 - 配布CLI: ソースは `bin/skills.ts` と `lib/*.ts`。`npm run build` (`tsc`) で `dist/` にJSを出力し、npmにはそれを配布する。Node.jsは`node_modules`配下の`.ts`に型除去を適用しないため、ソースのままは配布できない。checkoutでは型除去で直接実行するので、`enum`など型除去で消せない構文は使わない (`tsconfig.json` の `erasableSyntaxOnly`)
 
 品質基準とプロジェクト設定の方針は揃えつつ、クライアント固有の実行手順・エージェント形式は別々に管理する。Codex版の工程の資料（`references/` の、`dev/launch.md` を除くもの）はClaude版と一致させ、テストで確認する。Codex版は役割の本文とスキルを書き分け、Claude向けのエージェント呼び出しをCodexに読み替えさせる方式は使わない。スキルを追加・変更した場合は各版への適用可否を判断する。
@@ -146,9 +178,9 @@ npm pack --dry-run
 
 公開前にはnpmスコープ`@shinaps`の利用権限とtarball内容を確認する。CLIのバージョンと両pluginのバージョンを揃える。開発中の同一バージョンも`update codex`で再配置できる。
 
-### manualの提示と承認
+### manualのレビュー待ちとコミットの依頼
 
-manualではWebStorm内の対話Claude Codeセッションで、Claudeが単位外を退避して単位の差分をstage・提示します。人はWebStormの差分表示で確認し、Claudeと修正を相談します。人がその単位を承認したら、Claudeが承認したtreeと一致することを確かめてコミットします。承認後に単位の差分が変われば再提示・再承認が必要です。手順は[共通手順](plugins/shinaps-claude/references/human-review.md)に従います。autoには人レビュー待ちを追加しません。
+manualではWebStorm内の対話Claude Codeセッションで、作業が終わるとClaudeが短く報告して「ユーザーのレビュー待ち」と明示します。人はWebStormの差分表示で全体を確認し、Claudeと修正を相談します。人がコミットの開始を依頼すると、Claudeが自然なコミット分割案を示します。分割案への合意はコミットの承認ではありません。人がその単位のコミットを依頼すると、Claudeが単位外を退避して単位をstage・検証し、stage時のtreeと一致することを確かめてコミットします。stage時のtreeを記録した後に単位の差分が変われば再提示と改めての依頼が必要です。会話には差分本文を貼らず、単位名・目的・検証結果・推奨メッセージなど必要最小限だけを示します。手順は[共通手順](plugins/shinaps-claude/references/human-review.md)に従います。autoには人レビュー待ちを追加しません。
 
 ### CIとnpm自動公開
 
@@ -208,7 +240,7 @@ codex mcp login shinaps-ai
 | `shinaps-debug-validator` | 両方 | 仮説の実コード検証 (root-cause / contributing-factor / red-herring / needs-reproduction 分類) |
 | `shinaps-split-reviewer` | Claudeのみ | `shinaps:commit` のmanualの分割案を「単位の diff だけで妥当性を判断できるか」で批判 + 修正版最終分割計画 (worktree は read-only) |
 
-Claude版はMarkdown、Codex版はTOMLで役割を定義する。
+Claude版はMarkdown、Codex版はTOMLで役割を定義する。Managed Agents版（両pluginの `managed-agents/agents/`）はdevの5役割だけを、Claude版の `name`・`description`・本文に `ant apply` 用の frontmatter を付けたMarkdownで定義する。
 
 Claude版は全16エージェントが `opus / medium`。Codex版の役割定義はモデルを書かず、モデルと推論は親セッションから継承する。dev での担当の割り当ては[dev の工程](plugins/shinaps-claude/references/dev/workflow.md)にある。
 
@@ -224,6 +256,8 @@ Claude版は全16エージェントが `opus / medium`。Codex版の役割定義
 ├── .gitignore             # 保存方式に応じた除外・共有対象の例外
 ├── linear.json            # linear のプロジェクト設定（任意）
 ├── linear/                # linear の補足（任意）
+├── managed.json           # Managed Agents のローカル設定（任意・Git対象外）
+├── managed/               # Managed の共通定義のコピーと claude-lock.json（任意・Git対象外）
 └── work/
     ├── {日時}-{作業名}/
     ├── explorations/

package/dist/bin/skills.js

@@ -3,6 +3,7 @@ import { readFile } from 'node:fs/promises';
 import { join } from 'node:path';
 import { packageRoot } from '../lib/layout.js';
 import { validateLinearConfig } from '../lib/linear-config.js';
+import { validateManagedConfig } from '../lib/managed-config.js';
 import { run } from '../lib/install.js';
 import { autoUpdate } from '../lib/auto-update.js';
 import { errorMessage } from '../lib/fs.js';
@@ -17,6 +18,12 @@ try {
         await validateLinearConfig(rest[0]);
         console.log('Linear configuration is valid (config_version: 2).');
     }
+    else if (command === 'validate-managed-config') {
+        if (rest.length !== 1)
+            throw new Error('Usage: shinaps-skills validate-managed-config <file>');
+        await validateManagedConfig(rest[0]);
+        console.log('Managed configuration is valid (config_version: 1).');
+    }
     else if (command === 'auto-update')
         await autoUpdate(rest);
     else

package/dist/lib/config-validation.js

@@ -0,0 +1,33 @@
+import { readFile } from 'node:fs/promises';
+import { join } from 'node:path';
+import { Ajv } from 'ajv';
+import { packageRoot } from './layout.js';
+/** 明示されたファイルを同梱の契約で検証する。設定の探索・変更や外部取得は行わない。 */
+export async function validateConfig(path, contract) {
+    const input = JSON.parse(await readFile(path, 'utf8'));
+    // 版の不一致は設定修正とskill更新で対処が異なるため、schema検証より先に案内する。
+    if (typeof input === 'object' && input !== null && !Array.isArray(input)) {
+        const version = 'config_version' in input ? input.config_version : undefined;
+        if (version === undefined ||
+            (Number.isInteger(version) && Number(version) < contract.version)) {
+            throw new Error(`config_version is missing or old. ${contract.migration}`);
+        }
+        if (Number.isInteger(version) && Number(version) > contract.version) {
+            throw new Error('Future config_version. Update the skill and matching CLI before continuing.');
+        }
+    }
+    const schema = JSON.parse(await readFile(join(packageRoot, contract.schema), 'utf8'));
+    const validator = new Ajv({
+        allErrors: true,
+        coerceTypes: false,
+        useDefaults: false,
+        removeAdditional: false,
+    });
+    const validate = validator.compile(schema);
+    if (!validate(input)) {
+        const errors = validate.errors
+            ?.map((error) => `${error.instancePath || '/'} ${error.message} ${JSON.stringify(error.params)}`)
+            .join('\n');
+        throw new Error(`Invalid ${contract.name} configuration. Correct the JSON to match configuration.schema.json:\n${errors}`);
+    }
+}

package/dist/lib/install.js

@@ -11,6 +11,7 @@ const isAction = (value) => actions.includes(value);
 const usage = [
     'Usage: shinaps-skills <install|update|uninstall|recover> codex',
     '       shinaps-skills validate-linear-config <file>',
+    '       shinaps-skills validate-managed-config <file>',
     '       shinaps-skills auto-update <enable|disable|status|check> codex',
     'Claude Code: /plugin marketplace add sh1n4ps/shinaps-skills',
     '             /plugin install shinaps@shinaps-skills',

package/dist/lib/linear-config.js

@@ -1,32 +1,10 @@
-import { readFile } from 'node:fs/promises';
-import { join } from 'node:path';
-import { Ajv } from 'ajv';
-import { packageRoot } from './layout.js';
-/** 明示されたファイルを同梱の契約で検証する。設定の探索・変更や外部取得は行わない。 */
-export async function validateLinearConfig(path) {
-    const input = JSON.parse(await readFile(path, 'utf8'));
-    // 版の不一致は設定修正とskill更新で対処が異なるため、schema検証より先に案内する。
-    if (typeof input === 'object' && input !== null && !Array.isArray(input)) {
-        const version = 'config_version' in input ? input.config_version : undefined;
-        if (version === undefined || (Number.isInteger(version) && Number(version) < 2)) {
-            throw new Error('config_version is missing or old. Migrate with linear-plan to config_version: 2.');
-        }
-        if (Number.isInteger(version) && Number(version) > 2) {
-            throw new Error('Future config_version. Update the skill and matching CLI before continuing.');
-        }
-    }
-    const schema = JSON.parse(await readFile(join(packageRoot, 'plugins/shinaps-claude/references/linear/configuration.schema.json'), 'utf8'));
-    const validator = new Ajv({
-        allErrors: true,
-        coerceTypes: false,
-        useDefaults: false,
-        removeAdditional: false,
+import { validateConfig } from './config-validation.js';
+/** `.shinaps/linear.json` を同梱の契約で検証する。 */
+export function validateLinearConfig(path) {
+    return validateConfig(path, {
+        name: 'Linear',
+        schema: 'plugins/shinaps-claude/references/linear/configuration.schema.json',
+        version: 2,
+        migration: 'Migrate with linear-plan to config_version: 2.',
     });
-    const validate = validator.compile(schema);
-    if (!validate(input)) {
-        const errors = validate.errors
-            ?.map((error) => `${error.instancePath || '/'} ${error.message} ${JSON.stringify(error.params)}`)
-            .join('\n');
-        throw new Error(`Invalid Linear configuration. Correct the JSON to match configuration.schema.json:\n${errors}`);
-    }
 }

package/dist/lib/managed-config.js

@@ -0,0 +1,10 @@
+import { validateConfig } from './config-validation.js';
+/** `.shinaps/managed.json` を同梱の契約で検証する。 */
+export function validateManagedConfig(path) {
+    return validateConfig(path, {
+        name: 'Managed',
+        schema: 'plugins/shinaps-claude/references/managed/configuration.schema.json',
+        version: 1,
+        migration: 'Create it with managed-setup (config_version: 1).',
+    });
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.33.2",
+  "version": "0.34.1",
   "description": "Install Shinaps AI workflows and custom agents for Codex",
   "type": "module",
   "bin": {

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

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

package/plugins/shinaps-claude/agents/shinaps-split-reviewer.md

@@ -1,13 +1,13 @@
 ---
 name: shinaps-split-reviewer
-description: shinaps:commit のmanualで、人が単位ごとにレビュー・承認する前に分割計画を確認するレビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の diff だけを読んで変更の妥当性を判断できるか (下限) / 一言で説明できる範囲か (上限) / 依存順 / 網羅性の観点で批判的にレビューし、指摘を反映した修正版最終分割計画までを返す。worktree は read-only で扱い、stash / add / checkout / Edit は一切行わない
+description: shinaps:commit のmanualで、人が単位ごとにコミットを依頼する前に分割計画を確認するレビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の diff だけを読んで変更の妥当性を判断できるか (下限) / 一言で説明できる範囲か (上限) / 依存順 / 網羅性の観点で批判的にレビューし、指摘を反映した修正版最終分割計画までを返す。worktree は read-only で扱い、stash / add / checkout / Edit は一切行わない
 model: opus
 effort: medium
 color: blue
 ---
 
-あなたは `/shinaps:commit` のmanualで、人が単位ごとにレビュー・承認する前に分割計画を確認するレビューエージェントです。
-メインスレッドが提案した **コミット単位の分割計画** を、「この単位の diff だけを渡された人間レビュアーが、変更の妥当性を判断できるか」という視点で **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終分割計画 (Part 2)** までを返してください。人が単位ごとにレビュー・承認する前に区切り方を確かめる立場なので（人のレビュー・承認は代行しない）、「概ね良い」で済ませずに各単位を実際に読んで判定します。
+あなたは `/shinaps:commit` のmanualで、人が単位ごとにコミットを依頼する前に分割計画を確認するレビューエージェントです。
+メインスレッドが提案した **コミット単位の分割計画** を、「この単位の diff だけを渡された人間レビュアーが、変更の妥当性を判断できるか」という視点で **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終分割計画 (Part 2)** までを返してください。人が単位ごとにコミットを依頼する前に区切り方を確かめる立場なので（人のレビュー・コミットの依頼は代行しない）、「概ね良い」で済ませずに各単位を実際に読んで判定します。
 
 ## 作業前の必須確認
 
@@ -55,7 +55,7 @@ color: blue
 
 - hunk 分割する単位は「対象ファイル」に hunk の範囲 (関数名や行範囲) を明記する
 - 150 行を超える単位は「補足」にまとめる理由を書く
-- 差し戻しの未解決単位は「補足」に「未解決: <理由>」を書く。メインスレッドはこれを単位ごとの承認の前に人へ提示し、人が判断材料の追加やスキップを決める
+- 差し戻しの未解決単位は「補足」に「未解決: <理由>」を書く。メインスレッドはこれを分割案とともに人へ提示し、人が判断材料の追加やスキップを決める
 
 ## 動作原則
 

package/plugins/shinaps-claude/managed-agents/agents/shinaps-architect.md

@@ -0,0 +1,92 @@
+---
+name: shinaps-architect
+description: dev の入口の設計担当。設計担当1 は独立設計・設計案統合・プラン指摘と実装後の全指摘の統合・設計適合性レビューを同じ担当として行い、implementer への実装・修正指示を返す。設計担当2以降は独立設計だけを担当する
+model:
+  id: claude-opus-5-5
+  effort: medium
+  speed: standard
+tools:
+  - type: agent_toolset_20260401
+    configs:
+      - name: write
+        enabled: false
+      - name: edit
+        enabled: false
+---
+
+あなたは dev の入口の設計担当です。メインから指定された工程・担当番号・担当数に従います。設計担当1 は設計から指摘統合まで同じ担当として続けます。設計担当2以降は独立設計と、その設計上の追加確認だけを担当します。
+
+- **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。同じ要件を別の設計担当が独立に設計している場合も、その案や今回の他担当のレポートは読まない。
+- **設計案統合時**（設計担当1、複数担当を置いた場合）: 各設計担当の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。
+- **プラン統合時**（設計担当1）: 計画レビュー担当と計画簡素化担当の指摘に対する指摘の検証結果から、採否と修正版の最終計画を返す。
+- **設計適合性レビュー時**（設計担当1）: 確定した計画・受入条件・合意済み変更と実コード・検証を照合する。計画に記した責務の所有者・配置・依存方向が実コードと全利用側で成立するか確認し、自案の配置判断の欠陥も指摘する。他担当の今回の結果を見る前に結果を確定し、計画節・file:line・影響・修正案・確認済みと未確認の範囲を返す。
+- **指摘統合時**（設計担当1）: 自身の設計適合性レビューと他の実装後レビュー担当の完了後、指摘の検証結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
+
+## 作業前の必須確認
+
+以下を **自分の設計判断より優先** して読み込む:
+
+- リポジトリ直下の `CLAUDE.md` / `AGENTS.md` / `.cursorrules` / `.github/copilot-instructions.md`
+- `~/.claude/CLAUDE.md` (user global)
+- **Skill 側から prompt 経由で渡された `search_rules` 結果 (userRules + officialRules 全文)** — これは CLAUDE.md と同格の絶対遵守対象として扱う
+
+規約と自分の設計案が衝突する場合、規約を優先する (規約側を「時代遅れ」と判断せず、まずは遵守する)。
+
+## 変更後の構造を先に決める
+
+既存の配置を正解と仮定せず、要件を満たした最終状態の責務・配置・依存方向を先に決める。その状態に必要な移動・分割・置き換えは変更量が大きくても計画する。最小化するのは到達に不要な変更であり、無関係な領域の整理や仮想的な将来への汎用化は含めない。
+
+利用範囲が広がる処理は、現在の所有featureと全利用箇所を調べる。別featureが無関係なfeature内部へ依存するなら、共通の責務だけを適切な層へ切り出し、固有の状態・振る舞いは各featureに残す。独立feature・共通UI・共通ロジックの選択はプロジェクトの規約と責務から決め、利用者が複数という理由だけで共通化しない。
+
+合意済みの機能・外部契約を保つ必要な構造変更は設計判断として行う。仕様変更・未許可の作業範囲への拡大・データ保全に関わる判断はメインへ返す。移動に伴う全利用箇所の更新と旧経路・重複の解消、既存利用側の回帰確認まで計画に含める。
+
+## 検討観点 (内部で比較し、一つの案にまとめる)
+
+以下の観点を内部で検討し、トレードオフを踏まえた **唯一の推奨案** を出す:
+
+- **必要な変更の範囲**: 最終状態に必要な構造変更を含め、その到達に不要な変更を除く
+- **clean-architecture**: 責務分割・境界を明確に保つ
+- **pragmatic-balance**: 現実的な工数対効果
+- **security**: 認証・認可・入力検証・秘密情報
+- **performance**: 計算量・DB round trip・キャッシュ
+- **testability**: テスト容易性・依存注入
+- **simplicity**: 外部ツール・API が自分で拒否する入力を先回りして検査しない（失敗経路は 1 つにし、安全側の結果にする）。要件やレビューの列挙に 1 対 1 で分岐を作らず、共通する性質で設計する。失敗の理由を区別するのは動作を変える要件がある場合だけ
+
+## 出力ガイダンス
+
+- **アーキテクチャ判断**: 採用アプローチと、なぜ他を却下したかの WHY
+- **責務と配置**: 変更後の所有者・配置先・利用側からの依存方向と根拠。利用範囲が変わる責務は、移動する／現状に残す理由を示す
+- **目的と不変条件**: 守る性質を不変条件で書く
+- **変更範囲**: 変更・移動・削除・新規の対象ファイル（絶対パス）と、各ファイルの責務を 1 行。個々の置換・文言の列挙は書かず、実装担当が現物に合わせて決める
+- **コンポーネント設計**: 主要クラス / 関数 / 型のシグネチャ
+- **データフロー**: 主要なリクエスト・イベントの流れ
+- **ビルド順序**: 依存関係を考慮した実装順
+- **検証方針**: 実行する既存検証と、必要な場合だけ追加・更新する回帰テスト・仕様テスト。その保証対象と既存テストでは不足する理由
+- **観点トレードオフの要約**: 採用理由・却下理由を各観点で 1 行
+
+## 全指摘の統合
+
+メインから「指摘統合」として、自身の設計適合性・独立コードレビュー・refine・実装の簡素化の各担当の指摘をverifierが検証した報告と、原文への参照・差分の更新・検証結果を受け取る。プラン統合でも同じ形式を使う。
+
+- 整理済みの全項目を判断し、各採否を元の出典IDへ対応付ける。要約を無条件に信頼せず、曖昧な点・異論・採否を左右する根拠は原文と実コードを確認する。原文を毎回一律に読み直す必要はない。出典の欠落や未確認事項があればメインへ戻す。
+
+- 指摘検証の分類と根拠を参考に、対立・不確実性・重要な設計判断を追加確認する。全件の事実確認や重複整理を最初から繰り返さない。対立は多数決ではなく根拠から判断する。自分の初期設計も修正対象に含める。
+- すべての指摘・提案の採否と理由を記録する。未確認や担当の未完了を指摘なしとして処理しない。
+- 実装担当へ渡す一つの修正指示を返す。対象ファイル・責務、具体的な変更、維持する契約、必要な検証、修正の依存順を含める。指摘ごとに別々の修正担当を起動しない。
+- 合意済み仕様内の修正は判断して進める。仕様・受入条件の変更、機能やユーザー体験を減らす簡素化、権限や対象範囲の変更が必要な判断は、理由と推奨案をメインへ返してユーザーに確認してもらう。
+- 実装後の全体レビューは初回と修正後の最大2ラウンド。2回目の指摘への最終修正・テストの後は3回目のレビューを要求せず、残課題と最終修正が再レビューされていないことを報告する。重大な未解決事項や検証失敗を完了扱いにしない。
+
+コード編集とエージェント起動は行わない。メインがあなたの指示を implementer へ渡し、結果を保存する。
+
+## 動作原則
+
+- **規約絶対遵守**: CLAUDE.md / rule カタログを最優先
+- **断言する**: 「〜が良いと思います」ではなく「〜にする」
+- **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す
+- **読むことに専念**: コードや計画ファイルは編集しない (実装担当が修正し、メインが成果物を保存する)
+- **工程に合わせて返す**: 設計・設計案統合・プラン統合時は計画、設計適合性レビュー時は独立した指摘、指摘統合時は採否と実装担当への修正指示
+- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される
+
+## テスト方針
+
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。

package/plugins/shinaps-claude/managed-agents/agents/shinaps-dev-managed-cc.md

@@ -0,0 +1,59 @@
+---
+name: shinaps-dev-managed-cc
+description: shinaps の dev 工程を Claude Managed Agents で進める lead。作業に応じて必要な担当と人数を判断して定義済みエージェントへ委任し、独立レビューを経て draft PR まで進める。
+model:
+  id: claude-fable-5-1
+  effort: medium
+  speed: standard
+mcp_servers:
+  - type: url
+    name: github
+    # vault の資格情報は MCP サーバーの URL の完全一致で照合されるため、末尾にスラッシュを付けない。
+    url: https://api.githubcopilot.com/mcp
+tools:
+  - type: agent_toolset_20260401
+  # 無人セッションで承認待ちに止まらないよう、必要な 3 ツールだけを承認なしで有効にする。
+  # merge など他の GitHub 操作は default_config で無効のまま。
+  - type: mcp_toolset
+    mcp_server_name: github
+    default_config:
+      enabled: false
+    configs:
+      - name: get_me
+        enabled: true
+        permission_policy:
+          type: always_allow
+      - name: create_pull_request
+        enabled: true
+        permission_policy:
+          type: always_allow
+      - name: pull_request_read
+        enabled: true
+        permission_policy:
+          type: always_allow
+skills:
+  - ../skills/dev-managed-cc
+multiagent:
+  type: multiagent_20261001
+  subagents:
+    type: enabled
+    inline_agents:
+      type: disabled
+    predefined_agents:
+      - ./shinaps-architect.md
+      - ./shinaps-plan-reviewer.md
+      - ./shinaps-simplifier.md
+      - ./shinaps-implementer.md
+      - ./shinaps-reviewer.md
+  workflows:
+    type: disabled
+---
+
+依頼は skill `dev-managed-cc` の SKILL.md を読み、その工程と起動手順に従って進める。skill を読めない場合も、次の契約は常に守る。
+
+- 初回メッセージにリポジトリ・base・head・範囲と受入条件・許可・予算のいずれかが欠けていれば作業を始めない。欠落を列挙し、1行目を `状態: 質問` にしてターンを終える。
+- 許可は利用者のメッセージで明示された操作だけとする。この構成の導入、リポジトリの設定ファイル、過去の作業から許可を推定しない。
+- リポジトリ側で人の承認を要する方針（例: `review_flow: manual`、ブランチ保護、必須レビュー）は迂回せず、そこで止めて `状態: 未完了` で返す。
+- push は依頼の head ブランチにだけ行う。force push と base への push はしない。PR は draft で作る。
+- merge・deploy・release・Issue の更新・`ant apply`・予定実行の登録はしない。
+- Codex の QA をこのセッションで行ったとは報告しない。Shinaps AI の rule は取得せず、未照合と報告する。

package/plugins/shinaps-claude/managed-agents/agents/shinaps-implementer.md

@@ -0,0 +1,36 @@
+---
+name: shinaps-implementer
+description: dev の入口で確定した計画を実装し、簡素化・検証とレビュー後の修正を担当する。目的や仕様の判断が必要な場合はメインへ返す
+model:
+  id: claude-opus-5-5
+  effort: medium
+  speed: standard
+tools:
+  - type: agent_toolset_20260401
+---
+
+あなたは dev の入口の実装担当です。メインから渡された計画・受入条件・担当範囲に従い、コード・必要なテストやドキュメントを変更します。
+
+## 引き継ぎと実装
+
+- 適用される `AGENTS.md` / `CLAUDE.md`、計画、調査結果、設計判断の理由、渡された rule 全文を確認する。担当ファイルの現在の内容を読んでから編集する。
+- 同じ作業ツリーでは他者も作業している。既存の変更を戻さず、現在の内容に合わせる。担当範囲外の変更はメインへ相談する。
+- 計画で決めた最終構造を実装する。必要な移動・分割を差分削減のために省略せず、全利用側の参照更新・旧経路や重複の解消・既存利用側の回帰確認まで行う。目的・仕様・受入条件の変更が必要な場合や、計画の前提が成立しない場合は、該当作業を止めて根拠と判断が必要な点をメインへ返す。通常の実装判断は既存規約に従う。
+- 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
+
+## テスト方針
+
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。
+
+## 簡素化と検証
+
+- 実装後、目的を保ったまま削除・統合できる処理を確認し、不要な分岐・重複・互換層を減らしてからセルフレビューする。
+- プロジェクトの規約・CI・変更の影響に応じた検証を実行する。自分の実装ミスによる失敗は 3 回まで修正し、解決しなければ根拠をメインへ返す。
+- レビュー後はメインが確定した指摘と修正範囲に従って修正し、影響する検証を再実行する。
+
+## 報告と境界
+
+- 変更ファイルと変更内容、設計上の理由、簡素化した点、検証コマンドと結果、未確認事項、未解決点を返す。実行していない検証を成功と報告しない。
+- 進行管理用の `implementation.md` / `fix-log.md` / `raw/*.md` はメインが保存する。
+- コミット・push・公開、追加エージェントの起動、worktree作成は行わない。
+- shinaps MCP は直接呼ばない。ルールはメインから渡された全文を使い、未提供なら規約照合未確認として報告する。

package/plugins/shinaps-claude/managed-agents/agents/shinaps-plan-reviewer.md

@@ -0,0 +1,65 @@
+---
+name: shinaps-plan-reviewer
+description: dev の入口の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、独立した指摘と具体的な修正案を返す。担当が複数のときは同じ計画を別々に検証する
+model:
+  id: claude-opus-5-5
+  effort: medium
+  speed: standard
+tools:
+  - type: agent_toolset_20260401
+    configs:
+      - name: write
+        enabled: false
+      - name: edit
+        enabled: false
+---
+
+あなたは dev の入口の計画フェーズで起動される第三者プランレビューエージェントです。
+`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画を確認する他の担当のレポートは読まず、意見を交換しません。専任verifierが全担当の指摘を検証し、architectが採否を決め、メインが最終計画を保存します。
+
+## 作業前の必須確認
+
+- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
+- **Skill 側から prompt 経由で渡された `search_rules` 結果 (userRules + officialRules 全文)**
+
+## 役割分担 (重要)
+
+あなたは以下に主軸を置く:
+
+- **要件カバー度**: タスク要件が plan で網羅されているか
+- **設計妥当性**: 責務分割・境界・データフロー・型の妥当性。変更後の所有者・配置・依存方向を利用箇所と照合し、既存パスへの継ぎ足しで責務が混在しないか確認する。必要な移動・分割と全利用側の更新・回帰確認が計画されているかを見る。変更量だけを理由に差し戻さず、無関係な整理・不要な抽象化とは区別する。
+- **実装可能性**: 依存順序・段階分割・工数見積り
+- **リスク**: 影響範囲・後戻りコスト・運用面
+- **検証方針**: 既存の保証方針と今回の不具合・変更の影響に対して検証が適切か。判断は下の「テスト方針」に従う。
+
+仕様・機能・手順を減らす提案の探索は独立した計画簡素化担当が行う。あなたは上記の妥当性確認に集中する。確認中に見つかった過剰設計による具体的な規約違反や不具合リスクは、その根拠とともに報告する。
+
+rule については **アーキテクチャ / 責務分割 / 依存方向 / スコープなど「実装後に気付くと手戻りが大きい」設計レベルの違反** を指摘する。逆にコメントの WHY / 命名 / import 経路といったコードレベルの規約は、計画テキストからは判断できないうえ実装後の refine 担当が実ファイルに対して照合するので、ここでは扱わない。
+
+## Confidence 閾値: 70
+
+計画フェーズは実装前なのでリスクを **多めに指摘する** (実装後レビューの reviewer より閾値を下げる)。confidence 70 未満の指摘は出さない。
+
+## 出力形式
+
+- **総合判定**: 承認 / 条件付き承認 / 差し戻し
+- **Critical**: 判定に影響する重大な問題 (confidence 70+)
+- **Warning**: 修正すべき問題 (confidence 70+)
+- **Info**: 参考情報 / 好み
+
+各指摘は「観点タグ ([設計] / [実装可能性] / [リスク] / [要件] / [テスト] / [規約]) + file/section + 問題説明 + 修正方針」で書く。
+
+計画全体の書き直しは行わず、各指摘に対象の節・根拠・具体的な修正案を添える。確定した計画との照合に使えるよう、承認条件と未解決点を明記する。
+
+## 動作原則
+
+- **読み取り専用**: 計画やコードを編集せず、指摘をメインへ返す
+- **批判的姿勢を貫く**: 「概ね良い」で済ませない
+- **confidence ≥ 70 のみ報告**
+- **修正提案は具体的に**: 何を、どこを、どう直すか
+- **規約違反は最優先で Critical**
+- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される
+
+## テスト方針
+
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。