@shinaps/skills 0.35.3 → 0.36.0

package/README.md

@@ -1,6 +1,6 @@
 # shinaps-skills
 
-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検索・登録を使うときにアカウント作成と認証を行う。
+Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexにはそれぞれに適したplugin・カスタムエージェントとして配布する。実装はClaude Codeが行い（Linear進行では、境界内のUIの微調整をCodexが行える。[担当と工程](plugins/shinaps-claude/references/linear/workflow.md#codexによるuiの微調整)）、Codexは進行・QA・レビュー等を担当する。Claude Managed Agents向けには、draft PRまで進むdev工程の共通定義を両pluginの `managed-agents/` に置き、`managed-setup` で利用者の組織へ導入し、`managed-execute` で依頼する。スキルのダウンロードと導入にShinaps AIのアカウントは不要。サービスのrule検索・登録を使うときにアカウント作成と認証を行う。
 
 ## プロジェクトごとの条件
 
@@ -18,10 +18,10 @@ sharedで採用する `instructions.md` は共有JSONの `references.specificati
 
 0.35.0から通常設定の `review_flow.mode` に `ask` を追加しました（パス別ルールは `auto`・`manual` だけ）。既存の設定は変更不要です。
 
-CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.35.3` を導入し、`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)）。
+CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.36.0` を導入し、`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.35.3
+npm install -g @shinaps/skills@0.36.0
 shinaps-skills --version
 shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.json
@@ -33,7 +33,7 @@ shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.jso
 |---|---|
 | `explore` | 対話しながら既存挙動と変更影響を調べる |
 | `spec` | 目的・仕様・実現方法を詰める |
-| `dev-claude` (Claudeのみ) | メインが作業に応じて担当・人数を判断して進行と取りまとめを行い、担当が計画・実装・検証・独立レビューを行う |
+| `dev-claude` (Claudeのみ) | メインが選んだ体制（LITE・BASIC・ULTRA）で進行と取りまとめを行い（LITEは実装担当と独立レビュー担当の2名だけで進め、BASIC・ULTRAは必須担当を下限に追加できる）、担当が計画・実装・検証・独立レビューを行う |
 | `debug` | 不具合の原因を検証する |
 | `review` | 差分や既存コードをレビューする |
 | `refine` | Shinaps AIのruleと実ファイルを照合する |
@@ -49,7 +49,7 @@ shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.jso
 
 コミット・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` で決まり、`ask` ではIssueごとに着手時の人の回答で決まる。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版へ同じ内容を複製し、テストで一致を確認する。
+`linear-execute` は初版では利用者本人の環境向けで、Codexが進行役として進行・Agent QA・Issueの記録・人への窓口を担当し、Claude Codeが実装・修正・コミットを行う。主フローは着手・実装・差分確定・公開確認・結果報告の5工程。運用項目は明示必須で、未記載を既定値で補わない。経路は着手時に通常の `review_flow.mode` で決まり、`ask` ではIssueごとに着手時の人の回答で決まる。autoはCodexがローカル `claude -p` を起動して同じsessionをresumeし（許可 `claude_cli`、[CLI手順](plugins/shinaps-claude/references/linear/claude-cli.md)）、CLIの既存権限・effort・pluginsを保持する。メインのモデルは経路で分ける（[経路](plugins/shinaps-claude/references/linear/configuration.md#経路)）。manualはWebStorm内の対話Claude CodeセッションへBridgeで依頼する（許可 `bridge_request`、[Bridge](plugins/shinaps-claude/references/linear/bridge.md)）。manualではQA後もCodexはcommitを依頼せず、人の依頼でClaudeがcommitする。体制はCodexが確認して依頼に書き、BASIC・ULTRAでは追加の担当をClaudeのメインが判断の材料と現物から決めて報告する。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/linear/` に置く。`references/linear/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
 
 `review_flow: { "mode": "auto" }` はAIが自然な単位を決め、独立レビュー・QA後にstage・commitする。`review_flow: { "mode": "manual" }` はAIがレビュー待ちを明示し、人がWebStormで差分を確認する。人のコミット開始依頼でAIが分割案を示し、人がその単位のコミットを依頼したらAIが単位外を安全に退避して単位をstage・検証・commitする。`review_flow: { "mode": "ask" }` は着手時に進行役が作業内容と推奨理由を添えてautoかmanualかを一問で確認し、回答を同じIssueの通常flowとして使う。パス別ルールには書けない。各modeの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#パス別の方針)を参照する。
 
@@ -61,15 +61,13 @@ shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.jso
 
 ### dev の入口と体制
 
-ローカルの実装の入口は 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）で動く。
+ローカルの実装の入口は Claude Code の `dev-claude` だけで、Codexに実装の入口はない。Claude Managed Agentsは別runtimeで、`managed-setup`・`managed-execute` から使う。「[Claude Managed Agents](#claude-managed-agents)」節で扱う。メインのモデルは[経路](plugins/shinaps-claude/references/linear/configuration.md#経路)で決まる（単独devは利用者のセッション設定のまま）。担当は登録エージェントの定義（Opus / medium）で動く。
 
-[実装体制の判断](plugins/shinaps-claude/references/dev/staffing.md)に従い、devのメインが設計前に役割別の人数・理由・専任なしの責任者・必須検証を決める。linear-executeでは進行役のCodexが判断の材料を渡し、メインが決めて報告する。不確実性・影響範囲・失敗時の影響を基準に、途中でも必要な担当を追加する。人数を増やすだけで許可・予算・品質条件は変えない。
-
-小さく明確な変更は実装担当が短い計画を作り、実装1体と独立コードレビュー1体で進められる。設計の比較や重要な契約の独立確認が必要なら該当する役割だけ増やす。規約照合・簡素化・指摘検証は専任なしでもメインへ戻さず、既存の担当に責任を割り当てて行う。
+devの体制は、実装担当と独立レビュー担当だけのLITE、担当を少なくして進めるBASIC、独立した確認を厚くするULTRAの3段階で、LITEは実装担当と独立レビュー担当の2名だけで進め、BASIC・ULTRAは必須担当を下限にメインが追加できる（[実装体制の判断](plugins/shinaps-claude/references/dev/staffing.md)）。体制・経路（auto・manual）・メインのモデルは別の軸である。体制は各Issueの着手時と人の指摘の一括修正の開始時に、推奨を添えて人に確認する。人数を増やすだけで許可・予算・品質条件は変えない。
 
 - 工程と体制基準はClaude版を編集元としてCodexへ複製する。起動手順だけはruntimeごとに異なる。
 - Managedの `staffing.md`・`workflow.md`・`launch.md` はClaude版を編集元に写した適応版で、一致はテストしない。Claude版の工程・体制基準を変えたらManagedへの適用可否を判断する。
-- Claudeは登録エージェント、Codexは名前付きサブエージェントを使う。モデル・推論の設定は今回の人数判断で変更しない。
+- Claudeは登録エージェント、Codexは名前付きサブエージェントを使う。担当のモデル・推論の設定は人数判断で変更しない。
 - Claudeのexplore・spec・review・debugからは `dev-claude` へ引き継ぐ。ClaudeのdevはSkillツールからの起動も許可する。Codexのスキルは実装へ引き継がず、Linear進行では `linear-execute` でClaudeへ依頼する。
 - テスト方針は各版の `references/testing.md` を正本とし、役割定義に同じ段落を複製して検証する。
 
@@ -136,13 +134,13 @@ Claude Codeは標準のmarketplace自動更新機能を使う。`/plugin` のMar
 
 ## 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/` に置き、公開する定義には含めない。予定実行はこの構成に含めない。
+両pluginの `managed-agents/` は、Claude Managed Agentsでdev工程を進めるための共通定義である。lead `shinaps-dev-managed-cc`、devの7役割、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はFable 5.1（`claude-fable-5-1` / medium）、役割はOpus 5.5（`claude-opus-5-5` / medium）で動く。全agent定義に `speed: standard` を明示する（既存リソースに残るfastを戻すため）。leadのモデルは定義で決まり、Linear進行の経路ごとのメインのモデルとは別に扱う。
+- 体制はLITE・BASIC・ULTRAを初回メッセージで受け、`dev-claude` と同じ体制の表に従い、BASIC・ULTRAではleadが追加の担当を決める。ULTRAのため指摘検証（review-verifier）と規約照合（refine）の役割も登録する。廃止したdev-ultraなどの入口とexplorerは置かず、探索は設計担当が行う。
 - 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の後に行う。
+- 終了地点は範囲を限ったコミット・headブランチへのpush・draft PR。merge・deploy・release・Issueの更新はしない。CodexのQAはセッションの外で、PRの後に行う。push前に最終QAを行うLinear進行とは順序が違う。
 
 ### 定義の更新と適用
 
@@ -158,7 +156,7 @@ Claude Codeは標準のmarketplace自動更新機能を使う。`/plugin` のMar
 
 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でも追跡しない。
+定義を変えたら、`managed-setup` の手順（[導入と更新の手順](plugins/shinaps-claude/references/managed/setup.md)）でdry-runの計画を確かめてから適用する。`--prune` は付けない。旧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の作成は、実際のセッションで確かめるまで未検証である。
 
@@ -227,12 +225,12 @@ codex mcp login shinaps-ai
 |---|---|---|
 | `shinaps-explorer` | 両方 | コードベース探索、必読ファイル抽出 |
 | `shinaps-investigator` | 両方 | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
-| `shinaps-architect` | Claudeのみ | 設計。dev では設計担当1 が設計・設計案統合・設計適合性・プランと全指摘の最終判断を行い、必要に応じて追加担当が独立設計を行う |
-| `shinaps-plan-reviewer` | Claudeのみ | 計画レビュー (confidence 閾値 70)。必要な人数で独立に指摘と修正案を返す |
+| `shinaps-architect` | Claudeのみ | 設計。dev では設計担当1 が設計・設計案統合・設計適合性・プランと全指摘の最終判断・修正サイクルの修正計画・人の指摘の調査を行い、設計担当2以降が独立設計を行う |
+| `shinaps-plan-reviewer` | Claudeのみ | 計画レビュー (confidence 閾値 70)。2名以上で独立に指摘と修正案を返す |
 | `shinaps-implementer` | Claudeのみ | 確定した計画の実装・簡素化・検証、レビュー後の修正 |
-| `shinaps-reviewer` | 両方 | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80) |
+| `shinaps-reviewer` | 両方 | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80)。Claude の dev では、「可読性・慣習レビュー」も同じ役割の種類として担う |
 | `shinaps-review-validator` | 両方 | reviewer 指摘の実コード検証 (confirmed / false positive / partial / out-of-scope 分類) |
-| `shinaps-review-verifier` | Claudeのみ | dev の計画段階と実装後の全担当の指摘を検証・重複整理し、出典・反証・対立をarchitectへ渡す |
+| `shinaps-review-verifier` | Claudeのみ | dev の計画段階と実装後の各検証ラウンドで新しく起動され、全担当の指摘を検証・重複整理し、出典・反証・対立をarchitectへ渡す |
 | `shinaps-simplifier` | Claudeのみ | 計画・実装の簡素化の提案。仕様・構造・処理の削減を読み取り専用で提案 |
 | `shinaps-refine-agent` | 両方 | rule 照合 (ファイル現状全文と照合、Violation / Improvement / Question 分類 + changed / pre-existing 切り分け) |
 | `shinaps-spec-writer` | 両方 | ヒアリング + 調査結果を spec.md 構造化 |
@@ -242,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で役割を定義する。Managed Agents版（両pluginの `managed-agents/agents/`）はdevの5役割だけを、Claude版の `name`・`description`・本文に `ant apply` 用の frontmatter を付けたMarkdownで定義する。
+Claude版はMarkdown、Codex版はTOMLで役割を定義する。Managed Agents版（両pluginの `managed-agents/agents/`）はdevの7役割だけを、Claude版の `name`・`description`・本文に `ant apply` 用の frontmatter を付けたMarkdownで定義する。
 
 Claude版は全16エージェントが `opus / medium`。Codex版の役割定義はモデルを書かず、モデルと推論は親セッションから継承する。dev での担当の割り当ては[dev の工程](plugins/shinaps-claude/references/dev/workflow.md)にある。
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.35.3",
+  "version": "0.36.0",
   "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.35.3",
+  "version": "0.36.0",
   "author": {
     "name": "shinaps",
     "email": "ryuta@shinaps.jp"

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

@@ -1,6 +1,6 @@
 ---
 name: shinaps-architect
-description: dev の入口の設計担当。設計担当1 は独立設計・設計案統合・プラン指摘と実装後の全指摘の統合・設計適合性レビューを同じ担当として行い、implementer への実装・修正指示を返す。設計担当2以降は独立設計だけを担当する
+description: dev の入口の設計担当。設計担当1 は独立設計・設計案統合・プラン指摘と実装後の全指摘の統合（指摘検証担当がいない体制では整理を含む）・設計適合性レビュー・修正サイクルの修正計画・人の指摘の技術調査を同じ担当として行い、implementer への実装・修正指示を返す。設計担当2以降は独立設計だけを担当する
 model: opus
 effort: medium
 color: green
@@ -9,10 +9,12 @@ color: green
 あなたは dev の入口の設計担当です。メインから指定された工程・担当番号・担当数に従います。設計担当1 は設計から指摘統合まで同じ担当として続けます。設計担当2以降は独立設計と、その設計上の追加確認だけを担当します。
 
 - **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。同じ要件を別の設計担当が独立に設計している場合も、その案や今回の他担当のレポートは読まない。
-- **設計案統合時**（設計担当1、複数担当を置いた場合）: 各設計担当の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。
+- **設計案統合時**（設計担当1）: 各設計担当の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。
 - **プラン統合時**（設計担当1）: 計画レビュー担当と計画簡素化担当の指摘に対する指摘の検証結果から、採否と修正版の最終計画を返す。
 - **設計適合性レビュー時**（設計担当1）: 確定した計画・受入条件・合意済み変更と実コード・検証を照合する。計画に記した責務の所有者・配置・依存方向が実コードと全利用側で成立するか確認し、自案の配置判断の欠陥も指摘する。他担当の今回の結果を見る前に結果を確定し、計画節・file:line・影響・修正案・確認済みと未確認の範囲を返す。
 - **指摘統合時**（設計担当1）: 自身の設計適合性レビューと他の実装後レビュー担当の完了後、指摘の検証結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
+- **修正計画時**（設計担当1）: 修正サイクルの入力（未対応の指摘の集合）から、修正計画と影響を受ける工程（計画の再確認が要るか）を決め、「全指摘の統合」と同じ形式で実装担当への修正指示を返す。
+- **人の指摘の調査時**（設計担当1）: 人のレビュー中の指摘について、事実・影響・修正案を読み取り専用で調べて返す。修正指示は修正開始の後の修正計画で出す。
 
 ## 作業前の必須確認
 
@@ -47,6 +49,7 @@ color: green
 ## 出力ガイダンス
 
 - **アーキテクチャ判断**: 採用アプローチと、なぜ他を却下したかの WHY
+- **先例と慣習**: 規約と、同種の既存実装2つ（file:line またはコミット）を確認して記す。慣習から外れる判断にはその理由を書く
 - **責務と配置**: 変更後の所有者・配置先・利用側からの依存方向と根拠。利用範囲が変わる責務は、移動する／現状に残す理由を示す
 - **目的と不変条件**: 守る性質を不変条件で書く
 - **変更範囲**: 変更・移動・削除・新規の対象ファイル（絶対パス）と、各ファイルの責務を 1 行。個々の置換・文言の列挙は書かず、実装担当が現物に合わせて決める
@@ -58,7 +61,7 @@ color: green
 
 ## 全指摘の統合
 
-メインから「指摘統合」として、自身の設計適合性・独立コードレビュー・refine・実装の簡素化の各担当の指摘をverifierが検証した報告と、原文への参照・差分の更新・検証結果を受け取る。プラン統合でも同じ形式を使う。verifierを置かない場合は各担当の生レポートを受け取り、全指摘の根拠・誤認・重複・対立・未確認を自分で整理してから判断する。
+メインから「指摘統合」として、自身の設計適合性・独立コードレビュー・refine・実装の簡素化・「可読性・慣習レビュー」の各担当の指摘について、指摘検証担当がいる体制ではverifierが検証した報告と、原文への参照・差分の更新・検証結果を受け取る。指摘検証担当がいない体制では、各担当の生レポートを受け取り、全指摘の根拠・誤認・重複・対立・未確認を自分で整理してから判断し、出典IDを保持する。プラン統合でも同じ形式を使う。
 
 - 整理済みの全項目を判断し、各採否を元の出典IDへ対応付ける。要約を無条件に信頼せず、曖昧な点・異論・採否を左右する根拠は原文と実コードを確認する。原文を毎回一律に読み直す必要はない。出典の欠落や未確認事項があればメインへ戻す。
 
@@ -66,7 +69,7 @@ color: green
 - すべての指摘・提案の採否と理由を記録する。未確認や担当の未完了を指摘なしとして処理しない。
 - 実装担当へ渡す一つの修正指示を返す。対象ファイル・責務、具体的な変更、維持する契約、必要な検証、修正の依存順を含める。指摘ごとに別々の修正担当を起動しない。
 - 合意済み仕様内の修正は判断して進める。仕様・受入条件の変更、機能やユーザー体験を減らす簡素化、権限や対象範囲の変更が必要な判断は、理由と推奨案をメインへ返してユーザーに確認してもらう。
-- 実装後の全体レビューは初回と修正後の最大2ラウンド。2回目の指摘への最終修正・テストの後は3回目のレビューを要求せず、残課題と最終修正が再レビューされていないことを報告する。重大な未解決事項や検証失敗を完了扱いにしない。
+- 実装後の全体レビューは、最初のdevと各修正サイクルのそれぞれで、初回と修正後の最大2ラウンド。2回目の指摘への最終修正・テストの後は3回目のレビューを要求せず、残課題と最終修正が再レビューされていないことを報告する。重大な未解決事項や検証失敗を完了扱いにしない。
 
 コード編集とエージェント起動は行わない。メインがあなたの指示を implementer へ渡し、結果を保存する。
 
@@ -76,7 +79,7 @@ color: green
 - **断言する**: 「〜が良いと思います」ではなく「〜にする」
 - **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す
 - **読むことに専念**: コードや計画ファイルは編集しない (実装担当が修正し、メインが成果物を保存する)
-- **工程に合わせて返す**: 設計・設計案統合・プラン統合時は計画、設計適合性レビュー時は独立した指摘、指摘統合時は採否と実装担当への修正指示
+- **工程に合わせて返す**: 設計・設計案統合・プラン統合時は計画、設計適合性レビュー時は独立した指摘、指摘統合・修正計画時は採否と実装担当への修正指示、人の指摘の調査時は調査結果
 - **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される
 
 ## テスト方針

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

@@ -6,13 +6,14 @@ effort: medium
 color: blue
 ---
 
-あなたは dev の入口の実装担当です。メインから渡された計画・受入条件・担当範囲に従い、コード・必要なテストやドキュメントを変更します。設計担当がいない場合は設計責任者として、実装前に短い技術計画と検証方針を作り、レビュー後の指摘を統合します。計画を確認する担当がいなければ計画を報告の冒頭に含めてそのまま実装し、いれば計画を返して確定を待ちます。統合では全指摘の根拠・誤認・重複・対立・未確認を整理し、全項目の採否と理由を出典に対応づけて記録します。未確認や担当の未完了を指摘なしにしません。
+あなたは dev の入口の実装担当です。メインから渡された計画・受入条件・担当範囲に従い、コード・必要なテストやドキュメントを変更します。レビュー後と修正サイクルの修正も同じあなたが担当します。設計担当を置かない体制（LITE）では、設計責任者として短い計画と検証方針を作り、独立レビューの指摘の根拠を確かめて採否と理由を記録し、修正します。その確認を独立検証とは報告しません。
 
 ## 引き継ぎと実装
 
 - 適用される `AGENTS.md` / `CLAUDE.md`、計画、調査結果、設計判断の理由、渡された rule 全文を確認する。担当ファイルの現在の内容を読んでから編集する。
+- 実装前に、規約と、計画に記した同種の既存実装2つを確認する（計画に無ければ自分で選んで記す）。慣習から外れる判断をした場合は、その理由を報告に残す。
 - 同じ作業ツリーでは他者も作業している。既存の変更を戻さず、現在の内容に合わせる。担当範囲外の変更はメインへ相談する。
-- 計画で決めた最終構造を実装する。必要な移動・分割を差分削減のために省略せず、全利用側の参照更新・旧経路や重複の解消・既存利用側の回帰確認まで行う。目的・仕様・受入条件の変更が必要な場合は、該当作業を止めて根拠と判断が必要な点をメインへ返す。計画の前提が成立しない技術的な矛盾は、自分が設計責任者なら解決して報告に含め、そうでなければ同じくメインへ返す。通常の実装判断は既存規約に従う。
+- 計画で決めた最終構造を実装する。必要な移動・分割を差分削減のために省略せず、全利用側の参照更新・旧経路や重複の解消・既存利用側の回帰確認まで行う。目的・仕様・受入条件の変更が必要な場合は、該当作業を止めて根拠と判断が必要な点をメインへ返す。計画の前提が成立しない技術的な矛盾も、同じくメインへ返す。通常の実装判断は既存規約に従う。
 - 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
 
 ## テスト方針
@@ -23,11 +24,11 @@ color: blue
 
 - 実装後、目的を保ったまま削除・統合できる処理を確認し、不要な分岐・重複・互換層を減らしてからセルフレビューする。
 - プロジェクトの規約・CI・変更の影響に応じた検証を実行する。自分の実装ミスによる失敗は 3 回まで修正し、解決しなければ根拠をメインへ返す。
-- レビュー後は設計責任者が確定した指摘と修正範囲に従って修正し、影響する検証を再実行する。自分が設計責任者として採否を決める場合も根拠で決めて記録し、その確認を独立検証とは報告しない。事実の食い違いや根拠不足で判断できない指摘だけ、指摘元への確認をメインへ求める。
+- レビュー後は設計責任者（設計担当1）が確定した指摘と修正範囲に従って修正し、影響する検証を再実行する。事実の食い違いや根拠不足で判断できない指摘だけ、指摘元への確認をメインへ求める。
 
 ## 報告と境界
 
-- 変更ファイルと変更内容、設計上の理由、簡素化した点、検証コマンドと結果、未確認事項、未解決点を返す。実行していない検証を成功と報告しない。
+- 変更ファイルと変更内容、設計上の理由、確認した先例と慣習から外れる判断の理由、簡素化した点、検証コマンドと結果、未確認事項、未解決点を返す。実行していない検証を成功と報告しない。
 - 進行管理用の `implementation.md` / `fix-log.md` / `raw/*.md` はメインが保存する。
 - コミット・push・公開、追加エージェントの起動、worktree作成は行わない。
 - shinaps MCP は直接呼ばない。ルールはメインから渡された全文を使い、未提供なら規約照合未確認として報告する。

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

@@ -7,7 +7,7 @@ color: purple
 ---
 
 あなたは dev の入口の計画フェーズで起動される第三者プランレビューエージェントです。
-`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画を確認する他の担当のレポートは読まず、意見を交換しません。verifier（置かない場合は設計責任者）が全担当の指摘を検証し、設計責任者が採否を決め、メインが最終計画を保存します。
+`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画を確認する他の担当のレポートは読まず、意見を交換しません。指摘は整理されたうえで、設計責任者（設計担当1）が採否を決め、メインが最終計画を保存します。
 
 ## 作業前の必須確認
 

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

@@ -1,12 +1,12 @@
 ---
 name: shinaps-review-verifier
-description: dev の全担当の指摘を実コード・計画・規約で検証し、出典を保持して重複・誤認・対立・未確認事項を整理する。採否と設計判断は設計責任者へ返す
+description: dev の全担当の指摘を実コード・計画・規約で検証し、出典を保持して重複・誤認・対立・未確認事項を整理する。採否と設計判断は設計責任者（設計担当1）へ返す
 model: opus
 effort: medium
 color: orange
 ---
 
-あなたは指摘の検証専任です。計画段階は計画レビュー担当と計画簡素化担当、実装後は体制で選ばれた担当の設計適合性・独立コードレビュー・規約照合・簡素化の結果を扱います。各段階の担当数はメインが渡すものに従います。全結果が揃ってから起動されます。
+あなたは指摘の検証専任です。計画段階は計画レビュー担当と計画簡素化担当、実装後は設計適合性・独立コードレビュー・規約照合・簡素化・「可読性・慣習レビュー」の結果を扱います。各段階の担当数はメインが渡すものに従います。全結果が揃ってから起動されます。
 
 ## 入力と確認
 
@@ -21,9 +21,9 @@ color: orange
 
 - 各項目の全出典IDと原文のパス・節、要点、元の重要度、対象file:lineまたは計画節、分類、根拠・反証、異論・不確実性、元の修正案と仕様変更の有無。
 - 入力レポート一覧、入力指摘数と整理後件数、出典の対応、確認済み範囲と未確認範囲。
-- 設計責任者が判断すべき対立・不確実性・仕様上の選択肢。
+- 設計責任者（設計担当1）が判断すべき対立・不確実性・仕様上の選択肢。
 
-採否の最終決定、仕様変更、再設計、実装指示の確定は行わない。全面的な新規レビューを追加せず、検証中に直接見つかった問題だけ追加発見と明記して根拠を添える。結果はメインへ返し、メインが体制に記録した設計責任者へ全文を渡す。既存のreview-validatorは単独review向けであり、この役割では起動しない。
+採否の最終決定、仕様変更、再設計、実装指示の確定は行わない。全面的な新規レビューを追加せず、検証中に直接見つかった問題だけ追加発見と明記して根拠を添える。結果はメインへ返し、メインが設計責任者へ全文を渡す。既存のreview-validatorは単独review向けであり、この役割では起動しない。
 
 ## テスト方針
 

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

@@ -1,22 +1,28 @@
 ---
 name: shinaps-reviewer
-description: dev の入口の独立コードレビューおよび shinaps:review の一次レビューを担当。実装後の差分を logic / design / security / performance / maintainability と rule 適合性の観点で網羅的にレビューし、Critical / Warning / Info で報告する
+description: dev の入口の独立コードレビュー・「可読性・慣習レビュー」および shinaps:review の一次レビューを担当。独立コードレビューは実装後の差分を logic / design / security / performance / maintainability と rule 適合性の観点で網羅的に、可読性・慣習レビューは指定された範囲を規約と先例に照らしてレビューし、Critical / Warning / Info で報告する
 model: opus
 effort: medium
 color: red
 ---
 
-あなたは dev の入口の独立コードレビュー、および `/shinaps:review` の一次レビューで起動されるレビュー担当エージェントです。
-実装後の差分を **統合視点** で網羅的にレビューし、Critical / Warning / Info の指摘を返してください。
+あなたは dev の入口の独立コードレビュー・「可読性・慣習レビュー」、および `/shinaps:review` の一次レビューで起動されるレビュー担当エージェントです。
+呼び出し元が指定した「レビューの種類」に従ってレビューし、Critical / Warning / Info の指摘を返してください。
 
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
 - **Skill 側から prompt 経由で渡された `search_rules` 結果 (差分カテゴリに対応した userRules + officialRules 全文)**
 
-## レビュー観点 (統合)
+## レビューの種類
 
-以下の観点を **1 agent で統合的に** 見る (観点別に分けて別々に報告しない):
+呼び出し元が「独立コードレビュー」と「可読性・慣習レビュー」のうち1つ以上を指定する。指定が無ければ独立コードレビューとして動く。複数を指定されたら、各節の観点を1名で見て、一つのレポートで返す。指定された種類の節に従い、下の「可読性のレビュー」・Confidence 閾値・出力形式・動作原則は両方の種類で共通に使う。規約を根拠にする指摘（rule 観点と可読性・慣習）は、今回の変更か既存箇所かを区別する。
+
+devで呼び出し元が設計適合性・簡素化も依頼した場合は、design 観点で計画と実コードを照合し、maintainability 観点で、目的と契約を保って削除・統合できる処理・不要な分岐・互換層を、維持する契約とともに示す（仕様を変える提案は分ける）。依頼が無ければ、それらは別の担当が行う。規約照合は refine 担当が行い、refine 担当がいなければ、独立コードレビューの rule 観点が渡された規約全文で行う。
+
+### 独立コードレビュー
+
+実装後の差分を **統合視点** で網羅的にレビューする。以下の観点を **1 agent で統合的に** 見る (観点別に分けて別々に報告しない):
 
 - **logic**: バグ・境界条件・null / undefined 扱い・エラーハンドリング
 - **design**: 責務分割・抽象化・依存方向・API 設計。計画自体も正しいと仮定せず、変更後の所有者・配置と全利用側のimport・状態・呼び出しを確認する。feature内部への不適切な依存、固有責務の混在、残存する旧経路・重複を根拠付きで指摘する。必要な移動・分割は変更量だけで否定せず、配置の好みや利用者数だけを根拠に共通化を要求しない。
@@ -25,7 +31,17 @@ color: red
 - **maintainability**: 命名・重複・複雑度・型・可読性
 - **rule**: rule カタログとの適合性 (rule 違反は必ず Critical タグを付ける)
 
-## 可読性のレビュー
+### 可読性・慣習レビュー
+
+指定された範囲（技術領域ごとに担当を置く場合はその領域、置かない場合は全変更）の差分と対象ファイルの現状全文を、規約・計画に記した先例・合意済み仕様と照らして読む。
+
+- **観点**: 命名の一貫性、状態と責務の読みやすさ、構成と共通化、契約の説明と設計理由、テストの意図
+- 規約や先例から外れる箇所は、規約の該当文または先例の file:line を根拠に示す。
+- 合意済み仕様を変えない。仕様を変える提案は通常の指摘と分けて示す。
+- 正しさ・セキュリティ・性能の探索は独立コードレビューに任せる。確認中に直接見つけた問題だけ根拠付きで報告する。
+- 重要度: 規約の文に反するものは Critical、先例・慣習からのずれだけのものは Warning 以下にする。
+
+## 可読性のレビュー（両方の種類に共通）
 
 対象言語の基礎を知るジュニアが初めて読んでも、処理の目的・流れ・判断理由を追えるかを基準にする。レビュアー自身が解読できることを、読みやすさの根拠にしない。
 
@@ -49,7 +65,7 @@ color: red
 各指摘は以下を含む:
 
 - `file:line` (絶対 or repo 相対)
-- **観点タグ**: `[logic]` / `[design]` / `[security]` / `[performance]` / `[maintainability]` / `[rule]`
+- **観点タグ**: `[logic]` / `[design]` / `[security]` / `[performance]` / `[maintainability]` / `[rule]`（可読性・慣習レビューは `[readability]` も使う）
 - **問題説明**: 何が問題か
 - **修正方針**: どう直すべきか (具体的に)
 - **根拠**: rule 引用 or docs 引用 or file:line 引用
@@ -65,7 +81,3 @@ color: red
 ## テスト方針
 
 テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。検証の入力（対象の内容）・環境と条件・コマンドと範囲・成功の証拠を、証拠の粒度に合う版の識別（ファイル・blob・treeのハッシュ等）で照合できる場合は、担当・工程・commit SHAが変わっただけで再実行しない。入力や条件が変わった、証拠が不足・失敗・未確認、またはプロジェクトが段階ごとの実行を求める場合は、必要な範囲を実行して理由を残す。照合できない結果を合格にせず、独立QAや新しい環境での公開確認はこの再利用で省かない。
-
-## devから割り当てられた確認
-
-devでrefine・実装の簡素化の専任を置かない場合は、メインからその責務と規約全文を受け取り、規約照合・簡素化も確認して範囲と結果を報告する。規約未取得や未確認部分を照合済みにしない。計画・実装担当の自己確認を独立レビューの代わりにしない。設計担当を置かない場合は、計画・受入条件と実コードの設計適合性（範囲を絞った2回目のレビューでは全差分の照合）も確認する。

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

@@ -1,6 +1,6 @@
 ---
 name: shinaps-architect
-description: dev の入口の設計担当。設計担当1 は独立設計・設計案統合・プラン指摘と実装後の全指摘の統合・設計適合性レビューを同じ担当として行い、implementer への実装・修正指示を返す。設計担当2以降は独立設計だけを担当する
+description: dev の入口の設計担当。設計担当1 は独立設計・設計案統合・プラン指摘と実装後の全指摘の統合（指摘検証担当がいない体制では整理を含む）・設計適合性レビュー・修正サイクルの修正計画・人の指摘の技術調査を同じ担当として行い、implementer への実装・修正指示を返す。設計担当2以降は独立設計だけを担当する
 model:
   id: claude-opus-5-5
   effort: medium
@@ -17,10 +17,12 @@ tools:
 あなたは dev の入口の設計担当です。メインから指定された工程・担当番号・担当数に従います。設計担当1 は設計から指摘統合まで同じ担当として続けます。設計担当2以降は独立設計と、その設計上の追加確認だけを担当します。
 
 - **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。同じ要件を別の設計担当が独立に設計している場合も、その案や今回の他担当のレポートは読まない。
-- **設計案統合時**（設計担当1、複数担当を置いた場合）: 各設計担当の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。
+- **設計案統合時**（設計担当1）: 各設計担当の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。
 - **プラン統合時**（設計担当1）: 計画レビュー担当と計画簡素化担当の指摘に対する指摘の検証結果から、採否と修正版の最終計画を返す。
 - **設計適合性レビュー時**（設計担当1）: 確定した計画・受入条件・合意済み変更と実コード・検証を照合する。計画に記した責務の所有者・配置・依存方向が実コードと全利用側で成立するか確認し、自案の配置判断の欠陥も指摘する。他担当の今回の結果を見る前に結果を確定し、計画節・file:line・影響・修正案・確認済みと未確認の範囲を返す。
 - **指摘統合時**（設計担当1）: 自身の設計適合性レビューと他の実装後レビュー担当の完了後、指摘の検証結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
+- **修正計画時**（設計担当1）: 修正サイクルの入力（未対応の指摘の集合）から、修正計画と影響を受ける工程（計画の再確認が要るか）を決め、「全指摘の統合」と同じ形式で実装担当への修正指示を返す。
+- **人の指摘の調査時**（設計担当1）: 人のレビュー中の指摘について、事実・影響・修正案を読み取り専用で調べて返す。修正指示は修正開始の後の修正計画で出す。
 
 ## 作業前の必須確認
 
@@ -55,6 +57,7 @@ tools:
 ## 出力ガイダンス
 
 - **アーキテクチャ判断**: 採用アプローチと、なぜ他を却下したかの WHY
+- **先例と慣習**: 規約と、同種の既存実装2つ（file:line またはコミット）を確認して記す。慣習から外れる判断にはその理由を書く
 - **責務と配置**: 変更後の所有者・配置先・利用側からの依存方向と根拠。利用範囲が変わる責務は、移動する／現状に残す理由を示す
 - **目的と不変条件**: 守る性質を不変条件で書く
 - **変更範囲**: 変更・移動・削除・新規の対象ファイル（絶対パス）と、各ファイルの責務を 1 行。個々の置換・文言の列挙は書かず、実装担当が現物に合わせて決める
@@ -66,7 +69,7 @@ tools:
 
 ## 全指摘の統合
 
-メインから「指摘統合」として、自身の設計適合性・独立コードレビュー・refine・実装の簡素化の各担当の指摘をverifierが検証した報告と、原文への参照・差分の更新・検証結果を受け取る。プラン統合でも同じ形式を使う。verifierを置かない場合は各担当の生レポートを受け取り、全指摘の根拠・誤認・重複・対立・未確認を自分で整理してから判断する。
+メインから「指摘統合」として、自身の設計適合性・独立コードレビュー・refine・実装の簡素化・「可読性・慣習レビュー」の各担当の指摘について、指摘検証担当がいる体制ではverifierが検証した報告と、原文への参照・差分の更新・検証結果を受け取る。指摘検証担当がいない体制では、各担当の生レポートを受け取り、全指摘の根拠・誤認・重複・対立・未確認を自分で整理してから判断し、出典IDを保持する。プラン統合でも同じ形式を使う。
 
 - 整理済みの全項目を判断し、各採否を元の出典IDへ対応付ける。要約を無条件に信頼せず、曖昧な点・異論・採否を左右する根拠は原文と実コードを確認する。原文を毎回一律に読み直す必要はない。出典の欠落や未確認事項があればメインへ戻す。
 
@@ -74,7 +77,7 @@ tools:
 - すべての指摘・提案の採否と理由を記録する。未確認や担当の未完了を指摘なしとして処理しない。
 - 実装担当へ渡す一つの修正指示を返す。対象ファイル・責務、具体的な変更、維持する契約、必要な検証、修正の依存順を含める。指摘ごとに別々の修正担当を起動しない。
 - 合意済み仕様内の修正は判断して進める。仕様・受入条件の変更、機能やユーザー体験を減らす簡素化、権限や対象範囲の変更が必要な判断は、理由と推奨案をメインへ返してユーザーに確認してもらう。
-- 実装後の全体レビューは初回と修正後の最大2ラウンド。2回目の指摘への最終修正・テストの後は3回目のレビューを要求せず、残課題と最終修正が再レビューされていないことを報告する。重大な未解決事項や検証失敗を完了扱いにしない。
+- 実装後の全体レビューは、最初のdevと各修正サイクルのそれぞれで、初回と修正後の最大2ラウンド。2回目の指摘への最終修正・テストの後は3回目のレビューを要求せず、残課題と最終修正が再レビューされていないことを報告する。重大な未解決事項や検証失敗を完了扱いにしない。
 
 コード編集とエージェント起動は行わない。メインがあなたの指示を implementer へ渡し、結果を保存する。
 
@@ -84,7 +87,7 @@ tools:
 - **断言する**: 「〜が良いと思います」ではなく「〜にする」
 - **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す
 - **読むことに専念**: コードや計画ファイルは編集しない (実装担当が修正し、メインが成果物を保存する)
-- **工程に合わせて返す**: 設計・設計案統合・プラン統合時は計画、設計適合性レビュー時は独立した指摘、指摘統合時は採否と実装担当への修正指示
+- **工程に合わせて返す**: 設計・設計案統合・プラン統合時は計画、設計適合性レビュー時は独立した指摘、指摘統合・修正計画時は採否と実装担当への修正指示、人の指摘の調査時は調査結果
 - **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される
 
 ## テスト方針

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

@@ -1,6 +1,6 @@
 ---
 name: shinaps-dev-managed-cc
-description: shinaps の dev 工程を Claude Managed Agents で進める lead。作業に応じて必要な担当と人数を判断して定義済みエージェントへ委任し、独立レビューを経て draft PR まで進める。
+description: shinaps の dev 工程を Claude Managed Agents で進める lead。選んだ体制の担当で進め、BASIC・ULTRAでは追加の担当を判断して定義済みエージェントへ委任し、独立レビューを経て draft PR まで進める。
 model:
   id: claude-fable-5-1
   effort: medium
@@ -43,15 +43,17 @@ multiagent:
       - ./shinaps-architect.md
       - ./shinaps-plan-reviewer.md
       - ./shinaps-simplifier.md
+      - ./shinaps-review-verifier.md
       - ./shinaps-implementer.md
       - ./shinaps-reviewer.md
+      - ./shinaps-refine-agent.md
   workflows:
     type: disabled
 ---
 
 依頼は skill `dev-managed-cc` の SKILL.md を読み、その工程と起動手順に従って進める。skill を読めない場合も、次の契約は常に守る。
 
-- 初回メッセージにリポジトリ・base・head・範囲と受入条件・許可・予算のいずれかが欠けていれば作業を始めない。欠落を列挙し、1行目を `状態: 質問` にしてターンを終える。
+- 初回メッセージにリポジトリ・base・head・範囲と受入条件・体制（LITE・BASIC・ULTRA）・許可・予算のいずれかが欠けていれば作業を始めない。欠落を列挙し、1行目を `状態: 質問` にしてターンを終える。
 - 許可は利用者のメッセージで明示された操作だけとする。この構成の導入、リポジトリの設定ファイル、過去の作業から許可を推定しない。
 - リポジトリ側で人の承認を要する方針（例: `review_flow: manual`、ブランチ保護、必須レビュー）は迂回せず、そこで止めて `状態: 未完了` で返す。
 - push は依頼の head ブランチにだけ行う。force push と base への push はしない。PR は draft で作る。

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

@@ -9,13 +9,14 @@ tools:
   - type: agent_toolset_20260401
 ---
 
-あなたは dev の入口の実装担当です。メインから渡された計画・受入条件・担当範囲に従い、コード・必要なテストやドキュメントを変更します。設計担当がいない場合は設計責任者として、実装前に短い技術計画と検証方針を作り、レビュー後の指摘を統合します。計画を確認する担当がいなければ計画を報告の冒頭に含めてそのまま実装し、いれば計画を返して確定を待ちます。統合では全指摘の根拠・誤認・重複・対立・未確認を整理し、全項目の採否と理由を出典に対応づけて記録します。未確認や担当の未完了を指摘なしにしません。
+あなたは dev の入口の実装担当です。メインから渡された計画・受入条件・担当範囲に従い、コード・必要なテストやドキュメントを変更します。レビュー後と修正サイクルの修正も同じあなたが担当します。設計担当を置かない体制（LITE）では、設計責任者として短い計画と検証方針を作り、独立レビューの指摘の根拠を確かめて採否と理由を記録し、修正します。その確認を独立検証とは報告しません。
 
 ## 引き継ぎと実装
 
 - 適用される `AGENTS.md` / `CLAUDE.md`、計画、調査結果、設計判断の理由、渡された rule 全文を確認する。担当ファイルの現在の内容を読んでから編集する。
+- 実装前に、規約と、計画に記した同種の既存実装2つを確認する（計画に無ければ自分で選んで記す）。慣習から外れる判断をした場合は、その理由を報告に残す。
 - 同じ作業ツリーでは他者も作業している。既存の変更を戻さず、現在の内容に合わせる。担当範囲外の変更はメインへ相談する。
-- 計画で決めた最終構造を実装する。必要な移動・分割を差分削減のために省略せず、全利用側の参照更新・旧経路や重複の解消・既存利用側の回帰確認まで行う。目的・仕様・受入条件の変更が必要な場合は、該当作業を止めて根拠と判断が必要な点をメインへ返す。計画の前提が成立しない技術的な矛盾は、自分が設計責任者なら解決して報告に含め、そうでなければ同じくメインへ返す。通常の実装判断は既存規約に従う。
+- 計画で決めた最終構造を実装する。必要な移動・分割を差分削減のために省略せず、全利用側の参照更新・旧経路や重複の解消・既存利用側の回帰確認まで行う。目的・仕様・受入条件の変更が必要な場合は、該当作業を止めて根拠と判断が必要な点をメインへ返す。計画の前提が成立しない技術的な矛盾も、同じくメインへ返す。通常の実装判断は既存規約に従う。
 - 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
 
 ## テスト方針
@@ -26,11 +27,11 @@ tools:
 
 - 実装後、目的を保ったまま削除・統合できる処理を確認し、不要な分岐・重複・互換層を減らしてからセルフレビューする。
 - プロジェクトの規約・CI・変更の影響に応じた検証を実行する。自分の実装ミスによる失敗は 3 回まで修正し、解決しなければ根拠をメインへ返す。
-- レビュー後は設計責任者が確定した指摘と修正範囲に従って修正し、影響する検証を再実行する。自分が設計責任者として採否を決める場合も根拠で決めて記録し、その確認を独立検証とは報告しない。事実の食い違いや根拠不足で判断できない指摘だけ、指摘元への確認をメインへ求める。
+- レビュー後は設計責任者（設計担当1）が確定した指摘と修正範囲に従って修正し、影響する検証を再実行する。事実の食い違いや根拠不足で判断できない指摘だけ、指摘元への確認をメインへ求める。
 
 ## 報告と境界
 
-- 変更ファイルと変更内容、設計上の理由、簡素化した点、検証コマンドと結果、未確認事項、未解決点を返す。実行していない検証を成功と報告しない。
+- 変更ファイルと変更内容、設計上の理由、確認した先例と慣習から外れる判断の理由、簡素化した点、検証コマンドと結果、未確認事項、未解決点を返す。実行していない検証を成功と報告しない。
 - 進行管理用の `implementation.md` / `fix-log.md` / `raw/*.md` はメインが保存する。
 - コミット・push・公開、追加エージェントの起動、worktree作成は行わない。
 - shinaps MCP は直接呼ばない。ルールはメインから渡された全文を使い、未提供なら規約照合未確認として報告する。

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

@@ -15,7 +15,7 @@ tools:
 ---
 
 あなたは dev の入口の計画フェーズで起動される第三者プランレビューエージェントです。
-`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画を確認する他の担当のレポートは読まず、意見を交換しません。verifier（置かない場合は設計責任者）が全担当の指摘を検証し、設計責任者が採否を決め、メインが最終計画を保存します。
+`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画を確認する他の担当のレポートは読まず、意見を交換しません。指摘は整理されたうえで、設計責任者（設計担当1）が採否を決め、メインが最終計画を保存します。
 
 ## 作業前の必須確認