@shinaps/skills 0.29.1 → 0.30.0

package/README.md

@@ -1,6 +1,6 @@
 # shinaps-skills
 
-Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれぞれに適したplugin・カスタムエージェントとして配布する。スキルのダウンロードと導入にShinaps AIのアカウントは不要。サービスのrule検索・登録を使うときにアカウント作成と認証を行う。
+Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexにはそれぞれに適したplugin・カスタムエージェントとして配布し、Claude Managed Agentsには `ant apply` で作るエージェント・skill・環境の定義として提供する。スキルのダウンロードと導入にShinaps AIのアカウントは不要。サービスのrule検索・登録を使うときにアカウント作成と認証を行う。
 
 ## プロジェクトごとの条件
 
@@ -18,8 +18,7 @@ sharedで採用する `instructions.md` は共有YAMLの `references.specificati
 |---|---|
 | `explore` | 対話しながら既存挙動と変更影響を調べる |
 | `spec` | 目的・仕様・実現方法を詰める |
-| `dev-claude-ultra` (Claudeのみ) / `dev-codex-ultra` (Codexのみ) | 計画・実装・簡素化・検証・レビューを進める。設計・計画レビュー・計画簡素化を同じ役割の2体で独立に確認する。実装依頼の既定 |
-| `dev-claude` (Claudeのみ) / `dev-codex` (Codexのみ) | 同じ工程を、設計・計画レビュー・計画簡素化の担当をそれぞれ1体にして進める |
+| `dev-claude` (Claudeのみ) / `dev-codex` (Codexのみ) / `dev-managed-cc` (Managed Agentsのみ) | メインが作業に応じて担当・人数を判断し、計画・実装・検証・独立レビューを進める |
 | `debug` | 不具合の原因を検証する |
 | `review` | 差分や既存コードをレビューする |
 | `refine` | Shinaps AIのruleと実ファイルを照合する |
@@ -33,7 +32,7 @@ sharedで採用する `instructions.md` は共有YAMLの `references.specificati
 
 コミット・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を担当する。運用項目は明示必須で、既存設定の `config_storage`・`path_policy_overrides` 欠落は共通設定の説明に従い、それ以外は未記載を既定値で補わない。実装の担当は作業先の `.shinaps/linear.yaml` の `implementation_skill` で選ぶ。`dev-claude`・`dev-claude-ultra` を選ぶと、ClaudeがAI Terminal Bridge経由の依頼で実装する。`dev-codex`・`dev-codex-ultra` を選ぶと、会話側はゴール・進行・Agent QAを担当し、Issueごとの別Codexタスクが実装・QA指摘の修正・許可されたコミットを行う。タスク作成・連絡には `codex_task` とツールが要求する明示依頼が必要。どちらでも既存の許可は増えない。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/linear/` に置く。`references/linear/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
+`linear-execute` は初版では利用者本人の環境向けで、進行とAgent QAは会話側が担当する（Claude・Codexの入口ではCodex、Managedの入口では linear-execute を実行する Claude Code または Codex）。運用項目は明示必須で、既存設定の `config_storage`・`path_policy_overrides` 欠落は共通設定の説明に従い、それ以外は未記載を既定値で補わない。実装の担当は作業先の `.shinaps/linear.yaml` の `implementation_skill` で選ぶ。`dev-claude` を選ぶと、ClaudeがAI Terminal Bridge経由の依頼で実装する。`dev-codex` を選ぶと、会話側はゴール・進行・Agent QAを担当し、Issueごとの別Codexタスクが実装・QA指摘の修正・許可されたコミットを行う。タスク作成・連絡には `codex_task` とツールが要求する明示依頼が必要。`dev-managed-cc` を選ぶと、Issueごとの Managed Agents セッションが実装し、進行役が差分を適用してQA・コミットを行う。`managed_session:<USD>` と `dev_delegation` が必要で、Bridge は不要。どの入口でも `implementation_skill` は許可を増やさない。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/linear/` に置く。`references/linear/` はClaude版を編集元としてCodex版とManaged Agents版へ同じ内容を複製し、テストで一致を確認する。
 
 `path_policy_overrides` で、合意したパスの範囲に限り人レビュー・AIコミット許可・コミットモードを個別に上書きできる。たとえば `paths: ["docs/**", "README.md"]` と `human_code_review: skip` を指定すると、予定コミットの全変更がその範囲に収まる場合だけ人レビューを省く。同じコミットに対象外が混ざれば、そのコミット全体を通常方針とし、改名・移動は旧新両パスを判定する。同じ依頼でも自然な責務分割で独立した範囲内コミットには例外を適用できる。stage・push・公開の許可や必要なQAは変わらない。設定例と競合・照合の手順は[パス別の方針](plugins/shinaps-claude/references/linear/configuration.md#パス別の方針)を参照する。
 
@@ -43,22 +42,24 @@ sharedで採用する `instructions.md` は共有YAMLの `references.specificati
 
 旧 `linear` の入口は廃止した。相談・Issue整理・設定変更は `linear-plan`、実行は `linear-execute` を使う。YAMLの名前・運用項目は変わらない。実行範囲は毎回の依頼で確定し、バックログではブロッカー到達と報告を終了条件にできる。人レビュー・Human QA待ちは予定工程として待機する。
 
-### dev の入口
+### dev の入口と体制
 
-| 入口 | 配布 | 担当のモデル | 同じ役割の独立担当数 |
-|---|---|---|---|
-| `dev-claude` | Claude | Opus / medium（登録エージェントの定義） | 1体 |
-| `dev-claude-ultra` | Claude | Opus / medium（登録エージェントの定義） | 2体 |
-| `dev-codex` | Codex | `gpt-6-astra` / medium（起動時に指定） | 1体 |
-| `dev-codex-ultra` | Codex | `gpt-6-astra` / medium（起動時に指定） | 2体 |
+| 入口 | 実行環境 | 担当のモデル |
+| --- | --- | --- |
+| `dev-claude` | Claude Code | Opus / medium（登録エージェントの定義） |
+| `dev-codex` | Codex | `gpt-6-astra` / medium（起動時に指定） |
+| `dev-managed-cc` | Managed Agents | leadはFable 5.1 / medium、担当はOpus / medium・fast |
 
-- `ultra` は同じ役割の独立担当数が2体という意味で、推論・速度・権限は変えない。担当数が変えるのは、独立設計・計画レビュー・計画簡素化の担当2の有無だけである。実装は常に1体で、実装後の設計適合性・独立コードレビュー・refine・実装の簡素化・指摘の検証は1体の入口でも行う。
-- 工程は両版で同じ[dev の工程](plugins/shinaps-claude/references/dev/workflow.md)を使い、担当の起動手順だけを各版の `references/dev/launch.md` に分ける。工程はClaude版を編集元としてCodex版の同じパスへ複製し、テストで一致を確認する。
-- Claude版は登録エージェントを直接起動し、Codex CLIを使わない。Codex版は名前付きのカスタムエージェントをサブエージェントとして起動し、CLIで起動しない。どちらも親セッションの設定を変更しない。
-- 実装依頼と他スキル（explore・spec・review・debug）からの引き継ぎは、同じ runtime の `*-ultra` を既定にする。利用者が1体を指定した場合は1体の入口を使う。以前の dev 入口の別名は残さない。
-- Claude版の入口は、利用者が委託したCodexがAI Terminal Bridgeで依頼してSkillツールから起動できるよう、モデルからの呼び出しを許可している（`disable-model-invocation: true` を付けない）。
-- テスト方針の正本は両版の `references/testing.md`（同じ内容）で、dev の各役割の定義に同じ段落を写し、テストで一致を確認する。
-- 4つの入口は、SHINAPS-98・SHINAPS-108 の比較（同じ工程で担当のモデルと担当数を変えた比較）の結果から採用した。比較用の入口・資料・役割は v0.23.0 まで同梱していた（Git 履歴で参照できる）。
+人数による通常／ultraの区別は廃止した。`implementation_skill` は実行環境だけを選ぶ。旧名は対応する通常名へ設定・呼び出しを移行し、互換の入口は残さない。
+
+[実装体制の判断](plugins/shinaps-claude/references/dev/staffing.md)に従い、executeの進行役が各Issue開始時に関連コードを確認し、設計前に役割別の人数・理由・専任なしの責任者・必須検証を決めて渡す。単独devではメインが判断する。不確実性・影響範囲・失敗時の影響を基準に、途中でも必要な担当を追加する。人数を増やすだけで許可・予算・品質条件は変えない。
+
+小さく明確な変更はメインが計画し、実装1体と独立コードレビュー1体で進められる。設計の比較や重要な契約の独立確認が必要なら該当する役割だけ増やす。規約照合・簡素化・指摘検証は専任なしでも責任者を決めて行う。
+
+- 工程と体制基準はClaude版を編集元としてCodex・Managedへ複製する。起動手順だけはruntimeごとに異なる。
+- Claudeは登録エージェント、Codexは名前付きサブエージェント、Managedは定義済みエージェントを使う。モデル・推論の設定は今回の人数判断で変更しない。
+- explore・spec・review・debugからは同じruntimeのdevへ引き継ぐ。ClaudeのdevはSkillツールからの起動も許可する。
+- テスト方針は各版の `references/testing.md` を正本とし、役割定義に同じ段落を複製して検証する。
 
 ## Claude Code
 
@@ -67,11 +68,11 @@ sharedで採用する `instructions.md` は共有YAMLの `references.specificati
 /plugin install shinaps@shinaps-skills
 ```
 
-ユーザースコープで利用する。呼び出しは `/shinaps:dev-claude-ultra`、`/shinaps:create-pr` など。ローカル開発中はmarketplaceにこのcheckoutの絶対パスを登録し、変更後にpluginを更新する。pluginキャッシュへ直接編集しない。更新後は新しいセッションで確認する。
+ユーザースコープで利用する。呼び出しは `/shinaps:dev-claude`、`/shinaps:create-pr` など。ローカル開発中はmarketplaceにこのcheckoutの絶対パスを登録し、変更後にpluginを更新する。pluginキャッシュへ直接編集しない。更新後は新しいセッションで確認する。
 
 ## Codex
 
-Node.js 22以上と、`plugin marketplace add` / `plugin add` に対応したCodex CLIを使う。Claude Codeのインストールは不要。ただし `linear-execute` の開発進行をClaudeの入口で行う場合は、Claude CodeとAI Terminal Bridgeが必要になる。
+Node.js 22以上と、`plugin marketplace add` / `plugin add` に対応したCodex CLIを使う。Claude Codeのインストールは不要。ただし `linear-execute` の開発進行をClaudeの入口で行う場合は、Claude CodeとAI Terminal Bridgeが必要になる。Managedの入口で進める場合は `ant` CLI が必要になる。
 
 導入・更新・削除:
 
@@ -86,7 +87,7 @@ npx @shinaps/skills@latest recover codex
 
 ローカル開発では、このcheckoutから `node bin/skills.ts install codex` のように同じ操作を実行できる。Node.js 22.18以上なら型除去でTypeScriptをそのまま実行する (ビルド不要)。
 
-CLIはスキルをCodex pluginとして登録し、16個のカスタムエージェントを`${CODEX_HOME:-~/.codex}/agents/`へ配置する。新しいセッションで`shinaps:dev-codex-ultra`、`shinaps:review`等が読み込まれる。dev の入口から起動した担当は入口が指定するモデルと推論（`gpt-6-astra` / medium）で動き、それ以外のスキルからの利用ではモデルと推論設定を親セッションから継承する。実装担当以外の調査・レビュー担当は読み取り専用を既定にする。0.23.0 まで配置していた比較専用の役割は、更新時に管理済みエージェントとして削除される。親セッションの実行時設定が優先される場合もあるため、権限の強制境界とは扱わない。
+CLIはスキルをCodex pluginとして登録し、16個のカスタムエージェントを`${CODEX_HOME:-~/.codex}/agents/`へ配置する。新しいセッションで`shinaps:dev-codex`、`shinaps:review`等が読み込まれる。dev の入口から起動した担当は入口が指定するモデルと推論（`gpt-6-astra` / medium）で動き、それ以外のスキルからの利用ではモデルと推論設定を親セッションから継承する。実装担当以外の調査・レビュー担当は読み取り専用を既定にする。0.23.0 まで配置していた比較専用の役割は、更新時に管理済みエージェントとして削除される。親セッションの実行時設定が優先される場合もあるため、権限の強制境界とは扱わない。
 
 配布物は`~/.local/share/shinaps-ai/skills/codex/`へ保持し、一時的なnpxキャッシュに依存しない。同じ親ディレクトリの`state.json`に配置したエージェントと内容のハッシュを記録する。管理対象外の同名ファイルや、導入後に編集されたエージェントは上書き・削除せず停止する。必要な変更を退避・整理してから再実行する。`CODEX_HOME`を変更する場合は元の配置先で先にuninstallする。
 
@@ -121,14 +122,122 @@ macOS以外では予定実行の登録に対応していないため手動更新
 
 Claude Codeは標準のmarketplace自動更新機能を使う。`/plugin` のMarketplacesから対象marketplaceのauto-updateを有効にする。GitHubから自動取得するにはリモートmarketplaceを登録する必要があり、ローカルcheckout登録ではソースのgit pullまで自動実行しない。
 
+## Claude Managed Agents
+
+`managed-agents/` に、lead `shinaps-dev-managed-cc`、devの8役割、skill `dev-managed-cc`、環境 `shinaps-dev` の定義を置く。leadが体制を引き継いで必要な担当へ委任する。
+
+lead は Fable 5.1（`claude-fable-5-1` / medium）、役割は Opus 5.5 の fast（`speed: fast`）で動く。人数と再確認によって費用は変わるため、固定体制時の費用を現在の見積りに使わない。セッションの合意済み予算内で体制を決め、増員のために予算を自動で増やさない。計画の再確認はManagedの起動手順に従い最大2ラウンドとする。QA修正も同じセッションの予算に含める。
+
+前提は `ant` CLI 1.42.0 以上と `ant auth login` 済みであること。定義の作成・更新は次の npm script だけで行う。
+
+```sh
+npm run managed:plan          # 送信内容の確認。全項目は npm run managed:plan -- -v
+npm run managed:apply         # 作成・更新。確認に対話で答えられない実行では、先に managed:plan の出力を確認してから -- --yes を付ける
+```
+
+`ant apply` を直接実行しない。`ant apply` は指定したディレクトリを再帰的に走査し、`agents/` の下のファイルと `SKILL.md` を持つディレクトリを送信対象にするので、リポジトリ直下を対象にすると `plugins/` の下にある Claude 版・Codex 版の定義も送信対象に含まれる。また lockfile は実行した場所から上へ探し、キーは lockfile のディレクトリからの相対パスになる。別の場所から実行すると、既存の lockfile と対応づかずに同じリソースが重複して作られる。npm script は `managed-agents/` に移動してから実行するので、対象と lockfile の位置が常に同じになる。
+
+`managed-agents/claude-lock.json` は apply が書き出す。リソースの ID を記録しているので commit する。lockfile は shinaps 組織のリソースの記録である。別の組織で使う場合は、lockfile を消してから実行するか、`npm run managed:apply -- --lock-file claude-lock.<組織名>.json` のように別の lockfile を指定する。パスは `managed-agents/` から見た位置で、lockfile は `managed-agents/` の中に置く（外に置くとキーの形が変わり、下の jq の例と合わなくなる）。ID は次のように引ける。
+
+```sh
+jq -r '.resources["./agents/shinaps-dev-managed-cc.md"].id' managed-agents/claude-lock.json
+jq -r '.resources["./environments/shinaps-dev.yaml"].id' managed-agents/claude-lock.json
+```
+
+旧ultraのクラウドリソースとlockの対応は過去セッションの参照用に保持する。新規実行には使わず、通常の更新で `--prune` による削除を行わない。
+
+定義を変えたら `npm run managed:apply` を実行する。lead が参照する役割と skill の版も同じ実行で更新される。
+
+### セッション
+
+linear-execute の Managed の入口では、セッションの作成・観測・取り出し・差分の適用を、進行役が [Managedセッション](plugins/shinaps-claude/references/linear/managed-session.md) の手順で行う。以下は手動で作る場合の例である。
+
+lead は shinaps-ai MCP の `list_search_facets`・`search_rules` を使う。規約を取得するには、shinaps-ai の API トークンが使えるようになってから、利用者が vault を作って資格情報を登録する。vault はセッションの作成時にしか渡せない。vault を渡さないセッションでも作業は進むが、規約照合は未確認になる。
+
+```sh
+ant beta:vaults create --display-name shinaps-ai --transform id --raw-output   # 返された ID を VAULT_ID にする
+read -rs SHINAPS_AI_TOKEN                                                     # 画面に表示せずに入力する
+ant beta:vaults:credentials create --vault-id "$VAULT_ID" --display-name shinaps-ai <<YAML
+auth:
+  type: static_bearer
+  mcp_server_url: https://app.shinaps.ai/mcp
+  token: "$SHINAPS_AI_TOKEN"
+YAML
+unset SHINAPS_AI_TOKEN
+```
+
+token は stdin の YAML で渡す。`--auth.token` の引数で渡すと、シェルの履歴とプロセスの一覧に見える（`ant` 自身も、引数で資格情報を渡すことを非推奨にしている）。YAML の値を二重引用符で囲むので、token に `"` や `\` が含まれる場合は、その文字の前に `\` を付けてから入力する。
+
+作業先を git bundle にして添付する。利用者共通方針（`~/.claude/CLAUDE.md`）も同じようにアップロードして添付する。どちらもリポジトリには入れない。
+
+```sh
+git bundle create /tmp/<repo>.bundle <branch>
+BUNDLE_ID=$(ant files upload --file /tmp/<repo>.bundle --expires-in-seconds 604800 --transform id --raw-output)
+CLAUDE_MD_ID=$(ant files upload --file ~/.claude/CLAUDE.md --expires-in-seconds 604800 --transform id --raw-output)
+ant beta:sessions create \
+  --agent "$LEAD_ID" \
+  --environment-id "$ENV_ID" \
+  --vault-id "$VAULT_ID" \
+  --budget '{type: limit, max_list_cost: {amount: "4000", currency: USD}}' <<YAML
+resources:
+  - {type: file, file_id: $BUNDLE_ID, mount_path: /<repo>.bundle}
+  - {type: file, file_id: $CLAUDE_MD_ID, mount_path: /CLAUDE.md}
+YAML
+ant beta:sessions connect --web "$SESSION_ID"
+```
+
+- 最初のメッセージで、作業先の bundle（`/mnt/session/uploads/<repo>.bundle`）、ブランチ、比較元の SHA を伝える。lead は起動手順に従って `/workspace/<repo>` に clone してから工程を始める。
+- bundle の代わりに GitHub のリポジトリをマウントすることもできる。その場合は resources の bundle を次に置き換える。token は Contents: Read だけを許可した fine-grained token にする。
+
+  ```yaml
+  - type: github_repository
+    url: https://github.com/<owner>/<repo>
+    authorization_token: <Contents: Read だけを許可した fine-grained token>
+    checkout: {type: branch, name: <branch>}
+  ```
+
+- 予算はセッション作成時にしか付けられない（後から変更・削除はできる）。金額はセント単位の文字列で、`"4000"` は 40 USD である。
+- lead の model を上書きするときは、`--agent` を外し、stdin の YAML に次を加える。上書きすると定義の effort は引き継がれないので、effort も指定する。
+
+  ```yaml
+  agent:
+    type: agent_with_overrides
+    id: <LEAD_ID>
+    model: {id: <model>, effort: <effort>}
+  ```
+
+- `ant beta:sessions connect --web` は全スレッドを見られるビューアを開く。lead の質問には、次のメッセージで答える。
+
+作業記録は、lead が終了時に `/mnt/session/outputs/` へ tar.gz でまとめる。正本はサンドボックス内の `.shinaps/work/` である。あわせて、比較元からの差分の全体を `changes.patch` として同じ場所に置く。
+
+```sh
+ant beta:files list --scope-id "$SESSION_ID" --beta managed-agents-2026-04-01
+ant files download --file-id <file ID> -o <保存先>
+```
+
+ファイルはセッションが待機状態になってから数秒遅れて一覧に現れることがある。予算に達して止まったセッションでは、予算を引き上げて lead が終了処理を行うまで tar は作られない。
+
+担当の委任・継続の方法と、Claude Code 固有の手段の置き換え・未対応のものは、[起動手順](managed-agents/skills/dev-managed-cc/references/dev/launch.md)にある。
+
+### ネットワークと危険
+
+環境 `shinaps-dev` のネットワークは制限しない（`unrestricted`）。
+
+- bash の実行は承認なし（`always_allow`）なので、サンドボックスにあるもの（マウントしたコード、添付した CLAUDE.md）は外へ送ることができる。
+- 取得した Web ページやリポジトリの内容に書かれた指示に従ってしまう危険（プロンプトインジェクション）がある。
+- bash を `always_ask` か `auto` にすれば軽減できるが、担当ごとの承認待ちで工程が止まるので採らない。
+- 秘密情報はサンドボックスに置かない。マウントするリポジトリの token は読み取りだけに限る。
+- bundle で送るのはコミット済みの内容だけで、ignore 済みのファイルや作業記録は送らない。
+
 ## 開発と配布
 
 - 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版: `managed-agents/`。npmパッケージには含めない
 - 配布CLI: ソースは `bin/skills.ts` と `lib/*.ts`。`npm run build` (`tsc`) で `dist/` にJSを出力し、npmにはそれを配布する。Node.jsは`node_modules`配下の`.ts`に型除去を適用しないため、ソースのままは配布できない。checkoutでは型除去で直接実行するので、`enum`など型除去で消せない構文は使わない (`tsconfig.json` の `erasableSyntaxOnly`)
 
-品質基準とプロジェクト設定の方針は揃えつつ、クライアント固有の実行手順・エージェント形式は別々に管理する。Claude向けのエージェント呼び出しをCodexに読み替えさせる方式は使わない。スキルを追加・変更した場合は両版への適用可否を判断する。
+品質基準とプロジェクト設定の方針は揃えつつ、クライアント固有の実行手順・エージェント形式は別々に管理する。Managed Agents版は、役割の本文・`name`・`description` と工程の資料（`references/` の、`dev/launch.md` を除くもの）をClaude版と一致させ、テストで確認する。版ごとに内容を変えるのは役割の frontmatter（model・tools）と `references/dev/launch.md` で、Managed Agents版はこのほかに lead の定義、skill の `SKILL.md`、環境の定義を持つ。Codex版は役割の本文とスキルを書き分け、Claude向けのエージェント呼び出しをCodexに読み替えさせる方式は使わない。スキルを追加・変更した場合は各版への適用可否を判断する。
 
 ```sh
 npm test
@@ -138,6 +247,10 @@ npm pack --dry-run
 
 公開前にはnpmスコープ`@shinaps`の利用権限とtarball内容を確認する。CLIのバージョンと両pluginのバージョンを揃える。開発中の同一バージョンも`update codex`で再配置できる。
 
+### Codexでの人レビュー
+
+人レビューやコミット単位の承認を依頼する際、CodexはPlasmaで対象checkoutと差分を提示します。変更の目的と確認点は会話に示し、利用者の明示的なレビュー完了を待ちます。Plasmaは別途導入するツールで、未導入時も人レビューを省略しません。表示差分とコミット対象の照合、修正後の再確認は[共通手順](plugins/shinaps-codex/references/human-review.md)に従います。人レビューを省略するプロジェクトへ新たなレビュー待ちは追加しません。
+
 ### CIとnpm自動公開
 
 `.github/workflows/publish.yml` はmainへのpush・PR・手動実行でテストと配布内容を検証する。通常のGitHub Releaseを公開すると、検証成功後に同じtagのパッケージをnpmへpublic公開する。prereleaseは公開しない。手動実行は検証専用で、npmへの公開は行わない。
@@ -175,14 +288,14 @@ codex mcp login shinaps-ai
 
 未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`commit`・`create-pr`・`release`・`linear-plan`・`linear-execute` の基本手順はMCP接続を必須としない。
 
-## Subagents (Claude: 16 / Codex: 16)
+## Subagents (Claude: 16 / Codex: 16 / Managed: 8)
 
 | Subagent | 役割 |
 |---|---|
 | `shinaps-explorer` | コードベース探索、必読ファイル抽出 |
 | `shinaps-investigator` | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
-| `shinaps-architect` | 設計。dev では設計担当1 が設計・設計案統合・設計適合性・プランと全指摘の最終判断を行い、2体の入口では設計担当2 も独立設計を行う |
-| `shinaps-plan-reviewer` | 計画レビュー (confidence 閾値 70)。2体の入口では2体が独立に指摘と修正案を返す |
+| `shinaps-architect` | 設計。dev では設計担当1 が設計・設計案統合・設計適合性・プランと全指摘の最終判断を行い、必要に応じて追加担当が独立設計を行う |
+| `shinaps-plan-reviewer` | 計画レビュー (confidence 閾値 70)。必要な人数で独立に指摘と修正案を返す |
 | `shinaps-implementer` | 確定した計画の実装・簡素化・検証、レビュー後の修正 |
 | `shinaps-reviewer` | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80) |
 | `shinaps-review-validator` | reviewer 指摘の実コード検証 (confirmed / false positive / partial / out-of-scope 分類) |
@@ -196,7 +309,7 @@ codex mcp login shinaps-ai
 | `shinaps-debug-validator` | 仮説の実コード検証 (root-cause / contributing-factor / red-herring / needs-reproduction 分類) |
 | `shinaps-split-reviewer` | `shinaps:commit` の通常モードの分割案を「単位の diff だけで妥当性を判断できるか」で批判 + 修正版最終分割計画 (worktree は read-only) |
 
-Claude版はMarkdown、Codex版はTOMLで役割を定義する。
+Claude版はMarkdown、Codex版はTOMLで役割を定義する。Managed Agents版は dev で使う8役割だけを、Claude版の本文に `ant apply` 用の frontmatter を付けたMarkdownで定義する。
 
 Claude版は全16エージェントが `opus / medium`。Codex版の役割定義はモデルを書かず、dev の入口が起動時にモデルと推論を指定する。dev での担当の割り当ては[dev の工程](plugins/shinaps-claude/references/dev/workflow.md)にある。
 
@@ -205,7 +318,7 @@ Claude版は全16エージェントが `opus / medium`。Codex版の役割定義
 
 ## 作業成果物
 
-作業記録は現在の作業先の `.shinaps/work/` に保存する。[作業記録の共通手順](plugins/shinaps-claude/references/work-records.md)に従い、既存の共有例外を保持し、workの除外が不足する場合だけ `/work/` を追加する。設定の共有方式は記録作成では変更しない。共通手順はClaude版を編集元としてCodex版へ複製し、テストで一致を確認する。
+作業記録は現在の作業先の `.shinaps/work/` に保存する。[作業記録の共通手順](plugins/shinaps-claude/references/work-records.md)に従い、既存の共有例外を保持し、workの除外が不足する場合だけ `/work/` を追加する。設定の共有方式は記録作成では変更しない。共通手順はClaude版を編集元としてCodex版とManaged Agents版へ複製し、テストで一致を確認する。
 
 ```text
 .shinaps/

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.29.1",
+  "version": "0.30.0",
   "description": "Install Shinaps AI workflows and custom agents for Codex",
   "type": "module",
   "bin": {
@@ -22,6 +22,8 @@
     "test": "node --test \"test/*.test.ts\"",
     "check": "npm run format:check && tsc --noEmit",
     "verify:package": "node scripts/verify-package.ts",
+    "managed:plan": "cd managed-agents && ant apply --dry-run .",
+    "managed:apply": "cd managed-agents && ant apply .",
     "format": "biome format --write .",
     "format:check": "biome format ."
   },

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

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

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

@@ -1,18 +1,18 @@
 ---
 name: shinaps-architect
-description: dev の入口の設計担当。設計担当1 は独立設計・設計案統合・プラン指摘と実装後の全指摘の統合・設計適合性レビューを同じ担当として行い、implementer への実装・修正指示を返す。設計担当2 は独立設計だけを担当する
+description: dev の入口の設計担当。設計担当1 は独立設計・設計案統合・プラン指摘と実装後の全指摘の統合・設計適合性レビューを同じ担当として行い、implementer への実装・修正指示を返す。設計担当2以降は独立設計だけを担当する
 model: opus
 effort: medium
 color: green
 ---
 
-あなたは dev の入口の設計担当です。メインから指定された工程・担当番号・担当数に従います。設計担当1 は設計から指摘統合まで同じ担当として続けます。設計担当2 は独立設計と、その設計上の追加確認だけを担当します。
+あなたは dev の入口の設計担当です。メインから指定された工程・担当番号・担当数に従います。設計担当1 は設計から指摘統合まで同じ担当として続けます。設計担当2以降は独立設計と、その設計上の追加確認だけを担当します。
 
 - **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。同じ要件を別の設計担当が独立に設計している場合も、その案や今回の他担当のレポートは読まない。
-- **設計案統合時**（設計担当1、2体の設定のみ）: 設計担当1 と設計担当2 の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。
-- **プラン統合時**（設計担当1）: 計画レビュー担当と計画簡素化担当の指摘に対するverifierの検証結果から、採否と修正版の最終計画を返す。
+- **設計案統合時**（設計担当1、複数担当を置いた場合）: 各設計担当の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。
+- **プラン統合時**（設計担当1）: 計画レビュー担当と計画簡素化担当の指摘に対する指摘の検証結果から、採否と修正版の最終計画を返す。
 - **設計適合性レビュー時**（設計担当1）: 確定した計画・受入条件・合意済み変更と実コード・検証を照合する。計画に記した責務の所有者・配置・依存方向が実コードと全利用側で成立するか確認し、自案の配置判断の欠陥も指摘する。他担当の今回の結果を見る前に結果を確定し、計画節・file:line・影響・修正案・確認済みと未確認の範囲を返す。
-- **指摘統合時**（設計担当1）: 自身の設計適合性レビューと他の実装後レビュー担当の完了後、verifierの検証結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
+- **指摘統合時**（設計担当1）: 自身の設計適合性レビューと他の実装後レビュー担当の完了後、指摘の検証結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
 
 ## 作業前の必須確認
 
@@ -32,17 +32,17 @@ color: green
 
 合意済みの機能・外部契約を保つ必要な構造変更は設計判断として行う。仕様変更・未許可の作業範囲への拡大・データ保全に関わる判断はメインへ返す。移動に伴う全利用箇所の更新と旧経路・重複の解消、既存利用側の回帰確認まで計画に含める。
 
-## 検討観点 (内部で衝突させ、単一案に収束)
+## 検討観点 (内部で比較し、一つの案にまとめる)
 
 以下の観点を内部で検討し、トレードオフを踏まえた **唯一の推奨案** を出す:
 
 - **必要な変更の範囲**: 最終状態に必要な構造変更を含め、その到達に不要な変更を除く
-- **clean-architecture**: 責務分割・境界を綺麗に保つ
+- **clean-architecture**: 責務分割・境界を明確に保つ
 - **pragmatic-balance**: 現実的な工数対効果
 - **security**: 認証・認可・入力検証・秘密情報
 - **performance**: 計算量・DB round trip・キャッシュ
 - **testability**: テスト容易性・依存注入
-- **simplicity**: 外部ツール・API が自分で拒否する入力を先回りして検査しない（失敗経路は 1 つ、安全側に倒す）。要件やレビューの列挙に 1 対 1 で分岐を作らず、共通する性質で設計する。失敗の理由を区別するのは動作を変える要件がある場合だけ
+- **simplicity**: 外部ツール・API が自分で拒否する入力を先回りして検査しない（失敗経路は 1 つにし、安全側の結果にする）。要件やレビューの列挙に 1 対 1 で分岐を作らず、共通する性質で設計する。失敗の理由を区別するのは動作を変える要件がある場合だけ
 
 ## 出力ガイダンス
 
@@ -61,7 +61,7 @@ color: green
 
 - 整理済みの全項目を判断し、各採否を元の出典IDへ対応付ける。要約を無条件に信頼せず、曖昧な点・異論・採否を左右する根拠は原文と実コードを確認する。原文を毎回一律に読み直す必要はない。出典の欠落や未確認事項があればメインへ戻す。
 
-- verifierの分類と根拠を参考に、対立・不確実性・重要な設計判断を追加確認する。全件の事実確認や重複整理を最初から繰り返さない。対立は多数決ではなく根拠から判断する。自分の初期設計も修正対象に含める。
+- 指摘検証の分類と根拠を参考に、対立・不確実性・重要な設計判断を追加確認する。全件の事実確認や重複整理を最初から繰り返さない。対立は多数決ではなく根拠から判断する。自分の初期設計も修正対象に含める。
 - すべての指摘・提案の採否と理由を記録する。未確認や担当の未完了を指摘なしとして処理しない。
 - 実装担当へ渡す一つの修正指示を返す。対象ファイル・責務、具体的な変更、維持する契約、必要な検証、修正の依存順を含める。指摘ごとに別々の修正担当を起動しない。
 - 合意済み仕様内の修正は判断して進める。仕様・受入条件の変更、機能やユーザー体験を減らす簡素化、権限や対象範囲の変更が必要な判断は、理由と推奨案をメインへ返してユーザーに確認してもらう。
@@ -76,7 +76,7 @@ color: green
 - **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す
 - **読むことに専念**: コードや計画ファイルは編集しない (実装担当が修正し、メインが成果物を保存する)
 - **工程に合わせて返す**: 設計・設計案統合・プラン統合時は計画、設計適合性レビュー時は独立した指摘、指摘統合時は採否と実装担当への修正指示
-- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される
+- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される
 
 ## テスト方針
 

package/plugins/shinaps-claude/agents/shinaps-debug-validator.md

@@ -48,7 +48,7 @@ Skill 側から `raw/survey-validated.md` の要点が渡されたら、`debug-v
 
 - **実コードで検証**: 推測で判定しない、必ず Read
 - **因果関係を追跡**: 「なぜこの原因で症状が出るか」を説明できるまで検証
-- **red-herring を恐れない**: 仮説が間違っていたら堂々と却下する
-- **対症療法に流れない**: 「症状だけ消せば OK」の提案はしない
+- **red-herring の判定をためらわない**: 仮説が間違っていたら明確に却下する
+- **対症療法で済ませない**: 「症状だけ消せば OK」の提案はしない
 - **コード変更しない**: 修正はメインスレッドが担当
-- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される
+- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される

package/plugins/shinaps-claude/agents/shinaps-debugger.md

@@ -1,6 +1,6 @@
 ---
 name: shinaps-debugger
-description: shinaps:debug 専用の根本原因調査エージェント。症状からコードを追跡し、WebSearch / GitHub Issue 検索で外部情報を収集し、根本原因の仮説を立案する。既存の調査・実装成果物と rule カタログを踏まえて仮説候補を予選する
+description: shinaps:debug 専用の根本原因調査エージェント。症状からコードを追跡し、WebSearch / GitHub Issue 検索で外部情報を収集し、根本原因の仮説を立案する。既存の調査・実装成果物と rule カタログを踏まえて仮説候補に優先順位を付ける
 model: opus
 effort: medium
 color: magenta
@@ -22,7 +22,7 @@ color: magenta
 2. **外部情報収集**: WebSearch + GitHub Issue で類似バグ・既知の問題を検索
 3. **仮説立案**: 各仮説に確信度 (0-100) を付ける
 
-## rule 起点の仮説予選
+## rule 起点の仮説の優先順位付け
 
 - rule カタログに違反している箇所が症状の近くにあれば、それが根本原因である確率が高い → 仮説候補として優先
 - rule / CLAUDE.md に「過去にこの pattern で問題を起こしたことがある」旨があれば、その pattern に該当する箇所を優先調査
@@ -44,8 +44,8 @@ color: magenta
 
 - **根本原因志向**: 症状を消すだけの対症療法を推奨しない
 - **多角的情報収集**: コード / docs / WebSearch / GitHub Issue を組み合わせる
-- **確信度 50 未満でも有力なら報告**: validator が検証する前提で緩め (reviewer より閾値を下げる)
+- **確信度 50 未満でも有力なら報告**: validator が検証する前提で基準を緩める (reviewer より閾値を下げる)
 - **対症療法との比較を明示**: root vs symptom で比較表を出す
 - **コード変更しない**: 修正はメインスレッドが担当
 - **外部情報の出典必須**: URL を付ける
-- **shinaps MCP を自分で叩かない**: rule 全文 + 既存成果物の要約は Skill 側から prompt 経由で渡される
+- **shinaps MCP を直接呼ばない**: rule 全文 + 既存成果物の要約は Skill 側から prompt 経由で渡される

package/plugins/shinaps-claude/agents/shinaps-explorer.md

@@ -21,7 +21,7 @@ color: cyan
 
 ## 参照材料の使い方
 
-Skill 側から prompt 経由で以下の情報が渡されます (自分で MCP tool を叩かないこと):
+Skill 側から prompt 経由で以下の情報が渡されます (MCP tool を直接呼ばないこと):
 
 - **関連する既存成果物（要約）**: 過去に類似判断・方針転換があった場合の参考。同じ論点で結論が既に出ていれば重複探索を避けられる。
 - **既存 rule / CLAUDE.md 該当節**: 探索中の判断基準として使う (例: 「この責務は既存の X パターンに寄せるべきか」を rule と照らして判断)。
@@ -36,7 +36,7 @@ Skill 側から prompt 経由で以下の情報が渡されます (自分で MCP
 - **アーキテクチャ概観**: 該当エリアの責務分割を簡潔に
 - **既存パターン**: 採用されている設計・規約の抽出 (暗黙知も明文化する)
 - **必読ファイル一覧 (5-10 件)**: パスと「なぜ読むべきか」をペアで
-- **留意事項**: 落とし穴、トリッキーな箇所、明文化されていない暗黙ルール
+- **留意事項**: 落とし穴、間違えやすい箇所、明文化されていない暗黙ルール
 
 ## 動作原則
 
@@ -44,4 +44,4 @@ Skill 側から prompt 経由で以下の情報が渡されます (自分で MCP
 - **網羅より深さ**: 関連領域に絞って深く読む。広く浅くは避ける
 - **ファイル参照は file:line 形式**: 設計担当がそのまま辿れるように
 - **要約しすぎない**: 主要発見は具体的な引用や根拠を伴うこと
-- **shinaps MCP を自分で叩かない**: `search_rules` / `list_search_facets` を含む全 shinaps MCP tool は Skill 側 (メインスレッド) が呼び、結果を prompt 経由で渡す。あなたは受け取った文字列を材料に使うだけ
+- **shinaps MCP を直接呼ばない**: `search_rules` / `list_search_facets` を含む全 shinaps MCP tool は Skill 側 (メインスレッド) が呼び、結果を prompt 経由で渡す。あなたは受け取った文字列を材料に使うだけ

package/plugins/shinaps-claude/agents/shinaps-investigator.md

@@ -44,7 +44,7 @@ color: blue
 
 - **質問へ直接答える**: 周辺領域を網羅することを目的にしない
 - **根拠を辿れる形にする**: file:line、test 名、commit、URL を具体的に示す
-- **事実と推測を混ぜない**: 確認できないことを自然な物語で埋めない
+- **事実と推測を混ぜない**: 確認できないことをもっともらしい説明で補わない
 - **反証を探す**: 最初の仮説と矛盾するコードやテストも確認する
 - **現在の状態を優先する**: 既存成果物や docs とコードが食い違えば差異を報告する
 - **変更しない**: ソース、設定、依存関係、生成物、git state、外部システムを一切変更しない

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

@@ -1,6 +1,6 @@
 ---
 name: shinaps-plan-reviewer
-description: dev の入口の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、独立した指摘と具体的な修正案を返す。担当が2体のときは同じ計画を別々に検証する
+description: dev の入口の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、独立した指摘と具体的な修正案を返す。担当が複数のときは同じ計画を別々に検証する
 model: opus
 effort: medium
 color: purple
@@ -26,11 +26,11 @@ color: purple
 
 仕様・機能・手順を減らす提案の探索は独立した計画簡素化担当が行う。あなたは上記の妥当性確認に集中する。確認中に見つかった過剰設計による具体的な規約違反や不具合リスクは、その根拠とともに報告する。
 
-rule については **アーキテクチャ / 責務分割 / 依存方向 / スコープなど「実装後に気付くと手戻りが大きい」設計レベルの違反** を拾う。逆にコメントの WHY / 命名 / import 経路といったコードレベルの規約は、計画テキストからは判断できないうえ実装後の refine 担当が実ファイルに対して照合するので、ここでは踏み込まない。
+rule については **アーキテクチャ / 責務分割 / 依存方向 / スコープなど「実装後に気付くと手戻りが大きい」設計レベルの違反** を指摘する。逆にコメントの WHY / 命名 / import 経路といったコードレベルの規約は、計画テキストからは判断できないうえ実装後の refine 担当が実ファイルに対して照合するので、ここでは扱わない。
 
 ## Confidence 閾値: 70
 
-計画フェーズは実装前なのでリスクを **多めに拾う** (実装後レビューの reviewer より閾値を下げる)。confidence 70 未満の指摘は出さない。
+計画フェーズは実装前なのでリスクを **多めに指摘する** (実装後レビューの reviewer より閾値を下げる)。confidence 70 未満の指摘は出さない。
 
 ## 出力形式
 
@@ -50,7 +50,7 @@ rule については **アーキテクチャ / 責務分割 / 依存方向 / ス
 - **confidence ≥ 70 のみ報告**
 - **修正提案は具体的に**: 何を、どこを、どう直すか
 - **規約違反は最優先で Critical**
-- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される
+- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される
 
 ## テスト方針
 

package/plugins/shinaps-claude/agents/shinaps-refine-agent.md

@@ -11,11 +11,11 @@ Skill 側から渡された「rule 全件」と「対象ファイルの現状全
 
 ## 絶対原則 (credit 最適化)
 
-**subagent 内で shinaps MCP tool を叩かない**。rule 全文・docs 該当節・repo root・対象ファイル一覧はすべて Skill 側から prompt 経由で渡される。あなたはそれを材料に使うだけ。
+**subagent 内で shinaps MCP tool を直接呼ばない**。rule 全文・docs 該当節・repo root・対象ファイル一覧はすべて Skill 側から prompt 経由で渡される。あなたはそれを材料に使うだけ。
 
 ## 対象の取得
 
-照合するのは **diff の hunk ではなくファイルの現状全文**。hunk だけでは「この関数全体の責務が正しいか」「命名が周囲と揃っているか」を判断できず、追加行だけ規約準拠に見えてファイル全体では外れているケースを取り逃すため。
+照合するのは **diff の hunk ではなくファイルの現状全文**。hunk だけでは「この関数全体の責務が正しいか」「命名が周囲と揃っているか」を判断できず、追加行だけ規約準拠に見えてファイル全体では外れているケースを見落とすため。
 
 1. 渡された全ファイルについて適用される規約を確認する。非該当・読み取り失敗・未完了は理由を明記する
 2. 選んだファイルを `Read` で **現状全文** 取得する
@@ -36,7 +36,7 @@ Skill 側から渡された「rule 全件」と「対象ファイルの現状全
 - **`changed`**: finding の該当箇所が今回の変更行に掛かっている (1 行でも掛かっていれば `changed`)
 - **`pre-existing`**: 今回の変更と無関係な、元からある箇所
 
-この切り分けは Skill 側が「自動修正してよいか」を決めるのに使う。`pre-existing` を `changed` と誤って返すと、今回の作業と無関係な差分が commit に混入するので **迷ったら `pre-existing` に倒す**。
+この切り分けは Skill 側が「自動修正してよいか」を決めるのに使う。`pre-existing` を `changed` と誤って返すと、今回の作業と無関係な差分が commit に混入するので **迷ったら `pre-existing` にする**。
 
 ## 返却フォーマット (JSON 固定)
 
@@ -73,7 +73,7 @@ Skill 側から渡された「rule 全件」と「対象ファイルの現状全
 - **根拠なしの finding を報告しない**: rule 引用または docs 引用が付けられないものは出さない
 - **ファイル全体を見る**: 変更行の周辺だけを見て済ませない。ファイル全体が rule に沿っているかを判断する
 - **scope は迷ったら `pre-existing`**: 誤って `changed` にすると無関係な差分が commit に混入する
-- **subagent 内で shinaps MCP を叩かない**: 絶対原則を守る
+- **subagent 内で shinaps MCP を直接呼ばない**: 絶対原則を守る
 
 ## テスト方針
 

package/plugins/shinaps-claude/agents/shinaps-review-validator.md

@@ -25,11 +25,11 @@ color: orange
    - **false positive**: reviewer の勘違い / 実際は問題ない
    - **partial**: 一部は妥当だが範囲や表現に修正必要
    - **out-of-scope**: 妥当だが今回の対象範囲外
-4. **見落とし additional finding を追加報告**: reviewer が拾えなかった指摘を新規で出す
+4. **見落とし additional finding を追加報告**: reviewer が見落とした指摘を新規で出す
 
 ## rule 違反 finding の特別扱い
 
-- rule 起点の指摘は **false positive にしにくい** (rule と現実の乖離は稀)。よほど明確な逸脱の証拠がない限り confirmed 側に倒す
+- rule 起点の指摘は **false positive にしにくい** (rule と現実の乖離は稀)。極めて明確な逸脱の証拠がない限り confirmed 側で判定する
 - rule 起点で新規に見つけた additional finding は **積極的に追加報告**
 
 ## 出力形式
@@ -38,12 +38,12 @@ color: orange
 - **確定指摘 (confirmed / partial)**: file:line + 観点タグ + 問題 + 修正方針 + 根拠 (実コード引用 or rule 引用)
 - **却下指摘 (false positive)**: 元の指摘 + 却下理由 + 実コードでの反証
 - **スコープ外 (out-of-scope)**: 元の指摘 + スコープ外と判断した理由
-- **追加発見**: reviewer が拾えなかった Critical / Warning / Info
+- **追加発見**: reviewer が見落とした Critical / Warning / Info
 
 ## 動作原則
 
 - **必ずコードを Read で確認**: 推測で判定しない
-- **推測で false positive にしない**: 反証を用意できないなら confirmed に倒す
+- **推測で false positive にしない**: 反証を用意できないなら confirmed 側で判定する
 - **規約違反は最優先で confirmed**
 - **修正は提案のみ**: 実装はメインスレッドが担当
-- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される
+- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される

package/plugins/shinaps-claude/agents/shinaps-review-verifier.md

@@ -1,19 +1,19 @@
 ---
 name: shinaps-review-verifier
-description: dev の全担当の指摘を実コード・計画・規約で検証し、出典を保持して重複・誤認・対立・未確認事項を整理する。採否と設計判断はarchitectへ返す
+description: dev の全担当の指摘を実コード・計画・規約で検証し、出典を保持して重複・誤認・対立・未確認事項を整理する。採否と設計判断は設計責任者へ返す
 model: opus
 effort: medium
 color: orange
 ---
 
-あなたは指摘の検証専任です。計画段階は計画レビュー担当と計画簡素化担当、実装後は設計適合性・独立コードレビュー・refine・実装の簡素化の4担当を扱います。各段階の担当数はメインが渡すものに従います。全結果が揃ってから起動されます。
+あなたは指摘の検証専任です。計画段階は計画レビュー担当と計画簡素化担当、実装後は体制で選ばれた担当の設計適合性・独立コードレビュー・規約照合・簡素化の結果を扱います。各段階の担当数はメインが渡すものに従います。全結果が揃ってから起動されます。
 
 ## 入力と確認
 
 目的・受入条件・最新計画・合意済み変更、対象コードと差分、検証結果、規約全文、各担当の生レポートと確認範囲、ラウンド番号を受け取る。AGENTS.md / CLAUDE.mdと関係する仕様を確認する。読み取り専用で、編集・追加委託・shinaps MCPの直接呼び出しは行わない。
 
 - 各指摘に担当・ラウンド・項番の出典IDを付け、実コード・利用箇所・計画・規約から根拠や反証を確認する。計画段階の未実装コードが存在しないだけでは誤認としない。
-- 「根拠あり / 誤認 / 判断が対立 / 検証できず」に分類する。証拠不足を根拠ありや誤認に寄せない。一部だけ成立する場合は成立部分と未確認部分を残す。簡素化の価値判断は事実確認と区別する。
+- 「根拠あり / 誤認 / 判断が対立 / 検証できず」に分類する。証拠不足のまま根拠ありや誤認に分類しない。一部だけ成立する場合は成立部分と未確認部分を残す。簡素化の価値判断は事実確認と区別する。
 - 同じ原因・影響・修正方針の指摘だけまとめる。同じ場所の別問題や異なる仕様案はまとめず、対立点を明示する。元の重要度・提案内容を保持する。
 - 全出典IDが整理後の項目へ対応することを照合する。誤認・範囲外と判断した指摘も根拠付きで残す。件数や文字数で落とさない。
 
@@ -21,9 +21,9 @@ color: orange
 
 - 各項目の全出典IDと原文のパス・節、要点、元の重要度、対象file:lineまたは計画節、分類、根拠・反証、異論・不確実性、元の修正案と仕様変更の有無。
 - 入力レポート一覧、入力指摘数と整理後件数、出典の対応、確認済み範囲と未確認範囲。
-- architectが判断すべき対立・不確実性・仕様上の選択肢。
+- 設計責任者が判断すべき対立・不確実性・仕様上の選択肢。
 
-採否の最終決定、仕様変更、再設計、実装指示の確定は行わない。全面的な新規レビューを追加せず、検証中に直接見つかった問題だけ追加発見と明記して根拠を添える。結果はメインへ返し、メインが同じarchitectへ全文を渡す。既存のreview-validatorは単独review向けであり、この役割では起動しない。
+採否の最終決定、仕様変更、再設計、実装指示の確定は行わない。全面的な新規レビューを追加せず、検証中に直接見つかった問題だけ追加発見と明記して根拠を添える。結果はメインへ返し、メインが設計責任者（設計担当1、専任なしならメイン）へ全文を渡す。既存のreview-validatorは単独review向けであり、この役割では起動しない。
 
 ## テスト方針
 

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

@@ -60,8 +60,12 @@ color: red
 - **規約違反 (rule 違反含む) は必ず Critical**
 - **観点を分けて報告しない**: 1 つの指摘に複数観点タグが付いても良い
 - **修正は提案のみ**: コードは編集せず、指摘を呼び出し元へ返す
-- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される
+- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される
 
 ## テスト方針
 
 テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。
+
+## devから割り当てられた確認
+
+devでrefine・実装の簡素化の専任を置かない場合は、メインからその責務と規約全文を受け取り、規約照合・簡素化も確認して範囲と結果を報告する。規約未取得や未確認部分を照合済みにしない。計画・実装担当の自己確認を独立レビューの代わりにしない。