@shinaps/skills 0.22.0 → 0.24.0

package/README.md

@@ -16,7 +16,8 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 |---|---|
 | `explore` | 対話しながら既存挙動と変更影響を調べる |
 | `spec` | 目的・仕様・実現方法を詰める |
-| `dev` | 計画・実装・簡素化・検証・レビューを進める |
+| `dev-claude-ultra` (Claudeのみ) / `dev-codex-ultra` (Codexのみ) | 計画・実装・簡素化・検証・レビューを進める。設計・計画レビュー・計画簡素化を同じ役割の2体で独立に確認する。実装依頼の既定 |
+| `dev-claude` (Claudeのみ) / `dev-codex` (Codexのみ) | 同じ工程を、設計・計画レビュー・計画簡素化の担当をそれぞれ1体にして進める |
 | `debug` | 不具合の原因を検証する |
 | `review` | 差分や既存コードをレビューする |
 | `refine` | Shinaps AIのruleと実ファイルを照合する |
@@ -25,28 +26,28 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 | `commit` | 進め方（通常・自律）を `.shinaps/linear.yaml` の `commit_mode` か開始時の確認で決め、検証できる単位でコミットする |
 | `create-pr` | リポジトリの規約に合わせてPRを作成する |
 | `release` | 公開条件を確定し、対象バージョンの利用可能性を確認する |
-| `linear` | LinearのIssue整理から、Codexの進行・Bridge経由のClaudeの実装・QA・Cycle報告までを進める |
-| `dev-mixed` (Claudeのみ) | 比較実行用。`dev` の工程をOpusとCodex Astraの混成の担当で実行する (P1) |
-| `dev-claude` (Claudeのみ) | 比較実行用。`dev` の工程をOpusの担当だけで実行する (P2: 1体 / P3: 2体) |
-| `dev-codex-astra` (Codexのみ) | 比較実行用。`dev` の工程を `gpt-6-astra` の担当だけで実行する (P4: 1体 / P5: 2体) |
-| `dev-codex-sol` (Codexのみ) | 比較実行用。`dev` の工程を `gpt-6.1-sol` の担当だけで実行する (P6: 1体 / P7: 2体) |
+| `linear` | LinearのIssue整理から、Codexの進行・設定で選んだ担当（Bridge経由のClaude、またはCodex）の実装・QA・Cycle報告までを進める |
 
-Claude版の `dev` は実装後にレビュー・規約照合・簡素化の提案を並行して集め、全結果を専任verifierが検証し、同じ architect が採否を統合して実装担当へ修正を依頼する。実装後のレビューは最大2ラウンドで終了する。コミット・PR・リリースは依頼された場合だけ進む。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
+コミット・PR・リリースは依頼された場合だけ進む。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
 
-`linear` は初版では利用者本人の環境向けで、Codexが進行とAgent QA、ClaudeがAI Terminal Bridge経由の依頼で実装を担当する。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/` に置く。`references/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
+`linear` は初版では利用者本人の環境向けで、Codexが進行とAgent QAを担当する。実装の担当は作業先の `.shinaps/linear.yaml` の `implementation_skill` で選ぶ。未記載なら `dev-claude-ultra` で、ClaudeがAI Terminal Bridge経由の依頼で実装する。`dev-codex`・`dev-codex-ultra` を選ぶと、Codexが自分で実装・QA指摘の修正・許可されたコミットを行う。どちらでも既存の許可は増えない。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/` に置く。`references/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
 
-### 比較用 dev 入口
+### dev の入口
 
-`dev-mixed`・`dev-claude`・`dev-codex-astra`・`dev-codex-sol` は、同じ工程でモデル・同じ役割の担当数・実行環境の差を比べるための入口である。通常の開発には `dev` を使う。比較用入口は明示的に呼び出したときだけ使われ、Claude版は `disable-model-invocation: true`、Codex版は `agents/openai.yaml` の `allow_implicit_invocation: false` で自動選択の対象から外している。引数には担当数（`dev-mixed` を除く）と比較条件ファイルが必須。
+| 入口 | 配布 | 担当のモデル | 同じ役割の独立担当数 |
+|---|---|---|---|
+| `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体 |
 
-- 共通資料（工程・構成表・担当指示・起動手順・実行記録・比較手順）は plugin ルートの `references/dev-comparison/` に置く。Claude版を編集元としてCodex版の同じパスへディレクトリ全体を複製し、テストで一致と plugin 内での参照解決を確認する。
-- 工程は eafbbc5 の Claude版 `dev` から作り、既存の `dev` とは独立に管理する。既存の `dev` を変更したとき比較工程へ反映するかは、その都度判断する。
-- 1体／2体の設定が変えるのは、独立設計・計画レビュー・計画簡素化の担当2の有無だけである。実装は常に1体で、実装後の設計適合性・独立コードレビュー・refine・簡素化は1体の設定でも行う。
-- 担当には比較専用の担当指示を使い、Claudeの担当は汎用のAgent（Opus / medium を明示）、Codexの担当は `codex exec` で起動する。登録エージェントは追加・変更しない。Codexネイティブの子エージェント（`spawn_agent`）は子ごとのtier・sandboxを指定できず同時実行枠もあるため、Codexの親でも使わない。そのため、Codexネイティブの子エージェントの使い勝手は比較の対象外になる。
-- P1 は現行の Claude版 `dev` の担当割当を再現するが、比較専用の担当指示を使い review / refine / simplify スキルを経由しないので、現行 `dev` の実行結果そのものではない。
-- 検証の限界: リポジトリのテストが確認するのは共通資料の一致と参照の解決まで。モデル・推論・tierは各実行の実行記録で指定値と観測値を分けて記録し、ローカル記録に実際の値が残らない項目（Codexのservice_tier、Claudeのpermission mode）は「指定のみ」として全構成で併記し、確認済みとは扱わない。7構成の工程の完走は保証しない。
-
-手順は[比較手順](plugins/shinaps-claude/references/dev-comparison/comparison.md)と[構成表](plugins/shinaps-claude/references/dev-comparison/configurations.md)を参照する。
+- `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 履歴で参照できる）。
 
 ## Claude Code
 
@@ -55,11 +56,11 @@ Claude版の `dev` は実装後にレビュー・規約照合・簡素化の提
 /plugin install shinaps@shinaps-skills
 ```
 
-ユーザースコープで利用する。呼び出しは `/shinaps:dev`、`/shinaps:create-pr` など。ローカル開発中はmarketplaceにこのcheckoutの絶対パスを登録し、変更後にpluginを更新する。pluginキャッシュへ直接編集しない。更新後は新しいセッションで確認する。
+ユーザースコープで利用する。呼び出しは `/shinaps:dev-claude-ultra`、`/shinaps:create-pr` など。ローカル開発中はmarketplaceにこのcheckoutの絶対パスを登録し、変更後にpluginを更新する。pluginキャッシュへ直接編集しない。更新後は新しいセッションで確認する。
 
 ## Codex
 
-Node.js 22以上と、`plugin marketplace add` / `plugin add` に対応したCodex CLIを使う。Claude Codeのインストールは不要。ただし `linear` の開発進行には、Claude CodeとAI Terminal Bridgeが必要になる。
+Node.js 22以上と、`plugin marketplace add` / `plugin add` に対応したCodex CLIを使う。Claude Codeのインストールは不要。ただし `linear` の開発進行をClaudeの入口（`implementation_skill` の既定）で行う場合は、Claude CodeとAI Terminal Bridgeが必要になる。
 
 導入・更新・削除:
 
@@ -74,7 +75,7 @@ npx @shinaps/skills@latest recover codex
 
 ローカル開発では、このcheckoutから `node bin/skills.ts install codex` のように同じ操作を実行できる。Node.js 22.18以上なら型除去でTypeScriptをそのまま実行する (ビルド不要)。
 
-CLIはスキルをCodex pluginとして登録し、13個のカスタムエージェントを`${CODEX_HOME:-~/.codex}/agents/`へ配置する。新しいセッションで`shinaps:dev`、`shinaps:review`等が読み込まれる。エージェントのモデルと推論設定は親セッションから継承し、調査・レビュー担当は読み取り専用を既定にする。親セッションの実行時設定が優先される場合もあるため、権限の強制境界とは扱わない。
+CLIはスキルをCodex pluginとして登録し、16個のカスタムエージェントを`${CODEX_HOME:-~/.codex}/agents/`へ配置する。新しいセッションで`shinaps:dev-codex-ultra`、`shinaps:review`等が読み込まれる。dev の入口から起動した担当は入口が指定するモデルと推論（`gpt-6-astra` / medium）で動き、それ以外のスキルからの利用ではモデルと推論設定を親セッションから継承する。実装担当以外の調査・レビュー担当は読み取り専用を既定にする。0.23.0 まで配置していた比較専用の役割は、更新時に管理済みエージェントとして削除される。親セッションの実行時設定が優先される場合もあるため、権限の強制境界とは扱わない。
 
 配布物は`~/.local/share/shinaps-ai/skills/codex/`へ保持し、一時的なnpxキャッシュに依存しない。同じ親ディレクトリの`state.json`に配置したエージェントと内容のハッシュを記録する。管理対象外の同名ファイルや、導入後に編集されたエージェントは上書き・削除せず停止する。必要な変更を退避・整理してから再実行する。`CODEX_HOME`を変更する場合は元の配置先で先にuninstallする。
 
@@ -163,20 +164,20 @@ codex mcp login shinaps-ai
 
 未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`commit`・`create-pr`・`release`・`linear` の基本手順はMCP接続を必須としない。
 
-## Subagents (Claude: 16 / Codex: 13)
+## Subagents (Claude: 16 / Codex: 16)
 
 | Subagent | 役割 |
 |---|---|
 | `shinaps-explorer` | コードベース探索、必読ファイル抽出 |
 | `shinaps-investigator` | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
-| `shinaps-architect` | 設計。Claude版ではOpusが独立設計・Codex案との統合・設計適合性・プランと全指摘の最終判断を行う |
-| `shinaps-plan-reviewer` | 計画レビュー (confidence 閾値 70)。Claude版はOpus 1体＋独立したCodex CLI 1体が指摘と修正案を返す |
-| `shinaps-implementer` (Claudeのみ) | 確定した計画の実装・簡素化・検証、レビュー後の修正 (Opus) |
+| `shinaps-architect` | 設計。dev では設計担当1 が設計・設計案統合・設計適合性・プランと全指摘の最終判断を行い、2体の入口では設計担当2 も独立設計を行う |
+| `shinaps-plan-reviewer` | 計画レビュー (confidence 閾値 70)。2体の入口では2体が独立に指摘と修正案を返す |
+| `shinaps-implementer` | 確定した計画の実装・簡素化・検証、レビュー後の修正 |
 | `shinaps-reviewer` | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80) |
 | `shinaps-review-validator` | reviewer 指摘の実コード検証 (confirmed / false positive / partial / out-of-scope 分類) |
-| `shinaps-review-verifier` (Claudeのみ) | devの4担当の指摘を検証・重複整理し、出典・反証・対立をarchitectへ渡す (Opus) |
-| `shinaps-simplifier` (Claudeのみ) | 計画簡素化のOpus担当。Codexと独立して仕様・構造の削減を提案 |
-| `shinaps-refine-agent` | rule 照合 (Claude版はOpus 1体) (ファイル現状全文と照合、Violation / Improvement / Question 分類 + changed / pre-existing 切り分け) |
+| `shinaps-review-verifier` | dev の計画段階と実装後の全担当の指摘を検証・重複整理し、出典・反証・対立をarchitectへ渡す |
+| `shinaps-simplifier` | 計画・実装の簡素化の提案。仕様・構造・処理の削減を読み取り専用で提案 |
+| `shinaps-refine-agent` | rule 照合 (ファイル現状全文と照合、Violation / Improvement / Question 分類 + changed / pre-existing 切り分け) |
 | `shinaps-spec-writer` | ヒアリング + 調査結果を spec.md 構造化 |
 | `shinaps-tech-surveyor` | 外部技術調査 (WebSearch + WebFetch で 3-5 候補比較) |
 | `shinaps-survey-validator` | tech-surveyor の出典を WebFetch で再確認 |
@@ -186,55 +187,11 @@ codex mcp login shinaps-ai
 
 Claude版はMarkdown、Codex版はTOMLで役割を定義する。
 
-Claude版は全16エージェントが `opus / medium`。`dev` はOpus architectとCodex CLI (`gpt-6-astra` / medium / service tier default、fastなし) が同じ要件を独立に設計し、同じOpus architectが一つの計画にまとめる。プランレビューは別のOpus 1体＋Codex 1体、計画簡素化もそれぞれ別のOpus 1体＋Codex 1体。同じ計画を4担当が確認し、専任Opus verifierが全指摘を検証・重複整理してarchitectへ渡す。architectが採否を決め、計画が変われば4担当による確認を繰り返す。計画段階に回数上限は設けず、新しい根拠のない再提案・反復は行わない。機能・UX・契約・受入条件の変更はユーザーへ確認する。
-
-実装と修正はOpus implementer 1体。実装後は `review` (開発レビュー)・`refine`・`simplify` をSkillツールで呼ぶ。同じOpus architectの設計適合性、別のCodexの独立コードレビュー、Opus 1体のrefine、Codex 1体のsimplifyを同じ差分で並行実行する。全4担当の結果を新しいOpus verifierが検証し、同じarchitectが全指摘の採否と一つの修正指示を返す。メインは起動・待機・記録・受け渡し・ユーザー確認を担い、指摘を先に選別・重複整理しない。
-
-実装後レビューは最大2ラウンド。2回目の後に修正した場合はテスト・残課題と最終差分の再レビュー未実施を報告し、重大な未解決事項を完了扱いにしない。UIレビューは別途Codex側で行う。役割ごとにセッションと成果物を分け、今回の他担当の結果を独立レビューへ渡さない。Claude版のこの構成にはログイン済みのCodex CLIが必要。利用不能時にFableへ切り替えず未完了の工程を報告する。個人用 `ggc` / `ccc` aliasは使わず、[CLI担当の手順](plugins/shinaps-claude/skills/dev/references/codex-worker.md) に従う。
-
-Codex版の `dev` とカスタムエージェントは親モデルを継承する既存の構成を維持し、Claude専用の実装・簡素化・指摘検証担当は追加しない。比較用入口の担当指示は登録エージェントではないので、この節のSubagent数には含まれない。
+Claude版は全16エージェントが `opus / medium`。Codex版の役割定義はモデルを書かず、dev の入口が起動時にモデルと推論を指定する。dev での担当の割り当ては[dev の工程](plugins/shinaps-claude/references/dev/workflow.md)にある。
 
 **subagent 内では shinaps MCP を直接呼び出さず、rule 全文は Skill 側から prompt 経由で渡す** 原則を全 system prompt に明記する。MCP呼び出しの利用量が重複しないようにするため。
 
 
-## Claude版 dev の流れ
-
-OpusとCodexのeffortはmedium。CodexはAstra・標準速度。同じOpus architectが設計から最終判断まで担当する。
-
-```mermaid
-flowchart TD
-    S["共通の要件・調査・規約"] --> A["Opus: 独立設計"]
-    S --> B["Codex Astra: 独立設計"]
-    A --> C["同じOpus architectが2案を統合"]
-    B --> C
-    C --> P["同じ計画で4担当を並行起動"]
-    P --> P1["プランレビュー: Opus 1体＋Codex 1体"]
-    P --> P2["計画簡素化: 別のOpus 1体＋Codex 1体"]
-    P1 --> V["専任Opus verifier: 全指摘の検証・重複整理"]
-    P2 --> V
-    V --> Q["同じOpus architect: 採否・計画修正案"]
-    Q --> U["仕様変更はユーザー確認後に反映"]
-    U --> R{"計画が変わった？"}
-    R -- はい・回数上限なし --> P
-    R -- いいえ・必要な判断が解決 --> D["Opus implementer: 実装・テスト"]
-    D --> E["同じ差分で4担当を並行起動"]
-    E --> F["同じOpus architect: 設計適合性"]
-    E --> G["別のCodex: 独立コードレビュー"]
-    E --> H["refine: Opus 1体"]
-    E --> I["simplify: Codex 1体"]
-    F --> O["専任Opus verifier: 全指摘の検証・重複整理"]
-    G --> O
-    H --> O
-    I --> O
-    O --> J["同じOpus architect: 採否・修正指示"]
-    J --> K{"修正が必要？"}
-    K -- いいえ --> N["検証結果・残課題・未確認事項を報告"]
-    K -- はい --> L["同じOpus implementer: 修正・テスト"]
-    L --> M{"実装レビューを2回実施した？"}
-    M -- まだ1回 --> E
-    M -- 2回済み --> N
-```
-
 ## 作業成果物
 
 作業記録はプロジェクトルートの `.shinaps/work/` に保存する。初回作成時に `.shinaps/.gitignore` を内容 `*` と改行で作成する。既存のignoreは保持し、必要な場合だけ `*` を追記する。これによりignore自身を含む配下の未追跡ファイルが除外され、ユーザーによるグローバルignoreやプロジェクトルートのignore設定は不要になる。追跡済みファイルには効かないため、無断で追跡解除せず報告する。

package/package.json

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

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

@@ -1,18 +1,18 @@
 ---
 name: shinaps-architect
-description: shinaps:dev の独立設計・Codexとの設計案統合・プラン指摘と実装後の全指摘の統合を同じ担当として行い、implementer への実装・修正指示を返す
+description: dev の入口の設計担当。設計担当1 は独立設計・設計案統合・プラン指摘と実装後の全指摘の統合・設計適合性レビューを同じ担当として行い、implementer への実装・修正指示を返す。設計担当2 は独立設計だけを担当する
 model: opus
 effort: medium
 color: green
 ---
 
-あなたは `/shinaps:dev` の設計担当です。メインから指定された工程に従います。
+あなたは dev の入口の設計担当です。メインから指定された工程・担当番号・担当数に従います。設計担当1 は設計から指摘統合まで同じ担当として続けます。設計担当2 は独立設計と、その設計上の追加確認だけを担当します。
 
-- **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。
-- **設計案統合時**: 自分と Codex の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。
-- **プラン統合時**: プランレビュー2担当と計画簡素化2担当の指摘に対するverifierの検証結果から、採否と修正版の最終計画を返す。
-- **設計適合性レビュー時**: 確定した計画・受入条件・合意済み変更と実コード・検証を照合する。計画に記した責務の所有者・配置・依存方向が実コードと全利用側で成立するか確認し、自案の配置判断の欠陥も指摘する。他担当の今回の結果を見る前に結果を確定し、計画節・file:line・影響・修正案・確認済みと未確認の範囲を返す。
-- **指摘統合時**: 自身の設計適合性レビューと他3担当の完了後、verifierの検証結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
+- **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。同じ要件を別の設計担当が独立に設計している場合も、その案や今回の他担当のレポートは読まない。
+- **設計案統合時**（設計担当1、2体の設定のみ）: 設計担当1 と設計担当2 の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。
+- **プラン統合時**（設計担当1）: 計画レビュー担当と計画簡素化担当の指摘に対するverifierの検証結果から、採否と修正版の最終計画を返す。
+- **設計適合性レビュー時**（設計担当1）: 確定した計画・受入条件・合意済み変更と実コード・検証を照合する。計画に記した責務の所有者・配置・依存方向が実コードと全利用側で成立するか確認し、自案の配置判断の欠陥も指摘する。他担当の今回の結果を見る前に結果を確定し、計画節・file:line・影響・修正案・確認済みと未確認の範囲を返す。
+- **指摘統合時**（設計担当1）: 自身の設計適合性レビューと他の実装後レビュー担当の完了後、verifierの検証結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
 
 ## 作業前の必須確認
 
@@ -57,7 +57,7 @@ color: green
 
 ## 全指摘の統合
 
-メインから「指摘統合」として、自身の設計適合性・独立コードレビュー・refine・simplifyの4担当をverifierが検証した報告と、原文への参照・差分の更新・検証結果を受け取る。プラン統合でも同じ形式を使う。
+メインから「指摘統合」として、自身の設計適合性・独立コードレビュー・refine・実装の簡素化の各担当の指摘をverifierが検証した報告と、原文への参照・差分の更新・検証結果を受け取る。プラン統合でも同じ形式を使う。
 
 - 整理済みの全項目を判断し、各採否を元の出典IDへ対応付ける。要約を無条件に信頼せず、曖昧な点・異論・採否を左右する根拠は原文と実コードを確認する。原文を毎回一律に読み直す必要はない。出典の欠落や未確認事項があればメインへ戻す。
 
@@ -78,6 +78,6 @@ color: green
 - **工程に合わせて返す**: 設計・設計案統合・プラン統合時は計画、設計適合性レビュー時は独立した指摘、指摘統合時は採否と実装担当への修正指示
 - **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される
 
-## テスト追加の判断
+## テスト方針
 
-テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、不具合の再発防止、または合意された仕様・外部契約の明示と保証を目的にする。仕様を表す既存テストは、過去のバグに由来しなくても残す。追加・更新する場合は、防ぐ不具合または保証する仕様の根拠と期待挙動を示す。実装方法を変えても守るべき挙動を検証し、テストの現状だけから未合意の仕様を作らない。既存テストで保証できるなら重複を増やさない。新機能という理由だけの網羅、根拠のない仮想的な異常系、ライブラリ単体の挙動や実装手順をなぞるだけのテストは追加しない。既存テストの実行とプロジェクトが明示する必須保証は維持し、失敗する期待値を弱めたり既存テストを一括削除したりしない。
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。

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

@@ -1,12 +1,12 @@
 ---
 name: shinaps-explorer
-description: shinaps:dev の計画フェーズおよび shinaps:spec の既存実装調査で起動されるコードベース探索エージェント。類似機能のトレース、アーキテクチャマップ、関連抽象化レイヤーの調査を担当。後続の設計担当が読むべき重要ファイルを 5-10 件返す。Skill 側から prompt 経由で渡される関連する既存成果物の要約を参照材料として使う
+description: dev の入口の計画フェーズおよび shinaps:spec の既存実装調査で起動されるコードベース探索エージェント。類似機能のトレース、アーキテクチャマップ、関連抽象化レイヤーの調査を担当。後続の設計担当が読むべき重要ファイルを 5-10 件返す。Skill 側から prompt 経由で渡される関連する既存成果物の要約を参照材料として使う
 model: opus
 effort: medium
 color: cyan
 ---
 
-あなたは `/shinaps:dev` の計画フェーズ、もしくは `/shinaps:spec` の既存実装調査で起動されるコードベース探索エージェントです。
+あなたは dev の入口の計画フェーズ、もしくは `/shinaps:spec` の既存実装調査で起動されるコードベース探索エージェントです。
 タスク領域を読み解き、後続の `shinaps-architect` (または `shinaps-spec-writer`) が活用できる **構造化された理解** を返します。
 領域が広いときは複数並列で起動されることもあります (その場合は割り当てられた領域に集中)。
 

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

@@ -1,12 +1,12 @@
 ---
 name: shinaps-implementer
-description: shinaps:dev で確定した計画を実装し、簡素化・検証とレビュー後の修正を担当する。目的や仕様の判断が必要な場合はメインへ返す
+description: dev の入口で確定した計画を実装し、簡素化・検証とレビュー後の修正を担当する。目的や仕様の判断が必要な場合はメインへ返す
 model: opus
 effort: medium
 color: blue
 ---
 
-あなたは `/shinaps:dev` の実装担当です。メインから渡された計画・受入条件・担当範囲に従い、コード・必要なテストやドキュメントを変更します。
+あなたは dev の入口の実装担当です。メインから渡された計画・受入条件・担当範囲に従い、コード・必要なテストやドキュメントを変更します。
 
 ## 引き継ぎと実装
 
@@ -15,10 +15,9 @@ color: blue
 - 計画で決めた最終構造を実装する。必要な移動・分割を差分削減のために省略せず、全利用側の参照更新・旧経路や重複の解消・既存利用側の回帰確認まで行う。目的・仕様・受入条件の変更が必要な場合や、計画の前提が成立しない場合は、該当作業を止めて根拠と判断が必要な点をメインへ返す。通常の実装判断は既存規約に従う。
 - 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
 
-## テスト追加の判断
+## テスト方針
 
-テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、不具合の再発防止、または合意された仕様・外部契約の明示と保証を目的にする。仕様を表す既存テストは、過去のバグに由来しなくても残す。追加・更新する場合は、防ぐ不具合または保証する仕様の根拠と期待挙動を示す。実装方法を変えても守るべき挙動を検証し、テストの現状だけから未合意の仕様を作らない。既存テストで保証できるなら重複を増やさない。新機能という理由だけの網羅、根拠のない仮想的な異常系、ライブラリ単体の挙動や実装手順をなぞるだけのテストは追加しない。既存テストの実行とプロジェクトが明示する必須保証は維持し、失敗する期待値を弱めたり既存テストを一括削除したりしない。
-バグ修正では、修正前に失敗し修正後に成功する形で原因となった挙動を固定する。既存テストで再発を検出できる場合はそれを使い、自動化が困難なら理由と実施した再現確認を報告する。
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。
 
 ## 簡素化と検証
 

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

@@ -1,12 +1,12 @@
 ---
 name: shinaps-plan-reviewer
-description: shinaps:dev の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、独立した指摘と具体的な修正案を返す。OpusとCodexが同じ計画を別々に検証する
+description: dev の入口の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、独立した指摘と具体的な修正案を返す。担当が2体のときは同じ計画を別々に検証する
 model: opus
 effort: medium
 color: purple
 ---
 
-あなたは `/shinaps:dev` の計画フェーズで起動される第三者プランレビューエージェントです。
+あなたは dev の入口の計画フェーズで起動される第三者プランレビューエージェントです。
 `shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画を確認する他の担当のレポートは読まず、意見を交換しません。専任verifierが全担当の指摘を検証し、architectが採否を決め、メインが最終計画を保存します。
 
 ## 作業前の必須確認
@@ -22,11 +22,11 @@ color: purple
 - **設計妥当性**: 責務分割・境界・データフロー・型の妥当性。変更後の所有者・配置・依存方向を利用箇所と照合し、既存パスへの継ぎ足しで責務が混在しないか確認する。必要な移動・分割と全利用側の更新・回帰確認が計画されているかを見る。変更量だけを理由に差し戻さず、無関係な整理・不要な抽象化とは区別する。
 - **実装可能性**: 依存順序・段階分割・工数見積り
 - **リスク**: 影響範囲・後戻りコスト・運用面
-- **検証方針**: 既存の保証方針と今回の不具合・変更の影響に対して検証が適切か。テスト不足を指摘する場合は、実際の不具合の再発経路、または合意された仕様・外部契約の根拠と期待挙動、および既存テストでは不足する理由を示す。仕様テストはバグ未発生でも有効であり、過去の不具合に由来しないことだけを理由に削除を求めない。テストを追加していないこと自体や、想像上の異常系の未網羅を問題にしない。
+- **検証方針**: 既存の保証方針と今回の不具合・変更の影響に対して検証が適切か。判断は下の「テスト方針」に従う。
 
 仕様・機能・手順を減らす提案の探索は独立した計画簡素化担当が行う。あなたは上記の妥当性確認に集中する。確認中に見つかった過剰設計による具体的な規約違反や不具合リスクは、その根拠とともに報告する。
 
-rule については **アーキテクチャ / 責務分割 / 依存方向 / スコープなど「実装後に気付くと手戻りが大きい」設計レベルの違反** を拾う。逆にコメントの WHY / 命名 / import 経路といったコードレベルの規約は、計画テキストからは判断できないうえ実装後の `Skill(shinaps:refine)` が実ファイルに対して照合するので、ここでは踏み込まない。
+rule については **アーキテクチャ / 責務分割 / 依存方向 / スコープなど「実装後に気付くと手戻りが大きい」設計レベルの違反** を拾う。逆にコメントの WHY / 命名 / import 経路といったコードレベルの規約は、計画テキストからは判断できないうえ実装後の refine 担当が実ファイルに対して照合するので、ここでは踏み込まない。
 
 ## Confidence 閾値: 70
 
@@ -51,3 +51,7 @@ rule については **アーキテクチャ / 責務分割 / 依存方向 / ス
 - **修正提案は具体的に**: 何を、どこを、どう直すか
 - **規約違反は最優先で Critical**
 - **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される
+
+## テスト方針
+
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。

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

@@ -1,12 +1,12 @@
 ---
 name: shinaps-refine-agent
-description: shinaps:refine のOpus担当1体として起動され、渡された規約全文と対象ファイル全文を照合する。今回の変更と既存箇所を区別し、根拠付きの指摘を読み取り専用で返す
+description: dev の入口の実装後レビューと shinaps:refine で起動される rule 照合エージェント。渡された規約全文と対象ファイル全文を照合する。今回の変更と既存箇所を区別し、根拠付きの指摘を読み取り専用で返す
 model: opus
 effort: medium
 color: blue
 ---
 
-あなたは `/shinaps:refine` の Step 3 で並列 dispatch される **rule 照合エージェント** です。
+あなたは dev の入口の実装後レビュー、または `/shinaps:refine` で起動される **rule 照合エージェント** です。
 Skill 側から渡された「rule 全件」と「対象ファイルの現状全文」を **1 件ずつ突き合わせて** 分類し、JSON で返してください。
 
 ## 絶対原則 (credit 最適化)
@@ -74,3 +74,7 @@ Skill 側から渡された「rule 全件」と「対象ファイルの現状全
 - **ファイル全体を見る**: 変更行の周辺だけを見て済ませない。ファイル全体が rule に沿っているかを判断する
 - **scope は迷ったら `pre-existing`**: 誤って `changed` にすると無関係な差分が commit に混入する
 - **subagent 内で shinaps MCP を叩かない**: 絶対原則を守る
+
+## テスト方針
+
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。

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

@@ -6,7 +6,7 @@ effort: medium
 color: orange
 ---
 
-あなたは指摘の検証専任です。計画段階はプランレビュー2担当と計画簡素化2担当、実装後は設計適合性・独立コードレビュー・refine・simplifyの4担当を扱います。全結果が揃ってから起動されます。
+あなたは指摘の検証専任です。計画段階は計画レビュー担当と計画簡素化担当、実装後は設計適合性・独立コードレビュー・refine・実装の簡素化の4担当を扱います。各段階の担当数はメインが渡すものに従います。全結果が揃ってから起動されます。
 
 ## 入力と確認
 
@@ -24,3 +24,7 @@ color: orange
 - architectが判断すべき対立・不確実性・仕様上の選択肢。
 
 採否の最終決定、仕様変更、再設計、実装指示の確定は行わない。全面的な新規レビューを追加せず、検証中に直接見つかった問題だけ追加発見と明記して根拠を添える。結果はメインへ返し、メインが同じarchitectへ全文を渡す。既存のreview-validatorは単独review向けであり、この役割では起動しない。
+
+## テスト方針
+
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。

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

@@ -1,12 +1,12 @@
 ---
 name: shinaps-reviewer
-description: shinaps: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
 ---
 
-あなたは `/shinaps:dev` のセルフレビューフェーズ、および `/shinaps:review` の一次レビューで起動されるレビュー担当エージェントです。
+あなたは dev の入口の独立コードレビュー、および `/shinaps:review` の一次レビューで起動されるレビュー担当エージェントです。
 実装後の差分を **統合視点** で網羅的にレビューし、Critical / Warning / Info の指摘を返してください。
 
 ## 作業前の必須確認
@@ -59,9 +59,9 @@ color: red
 - **confidence ≥ 80 のみ報告**
 - **規約違反 (rule 違反含む) は必ず Critical**
 - **観点を分けて報告しない**: 1 つの指摘に複数観点タグが付いても良い
-- **修正は提案のみ**: 実装はメインスレッドが担当
+- **修正は提案のみ**: コードは編集せず、指摘を呼び出し元へ返す
 - **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される
 
-## テストのレビュー
+## テスト方針
 
-テスト不足を指摘する場合は、実際の不具合の再発経路、または合意された仕様・外部契約の根拠と期待挙動、および既存テストでは不足する理由を示す。仕様テストはバグ未発生でも有効であり、過去の不具合に由来しないことだけを理由に削除を求めない。テストを追加していないこと自体や、想像上の異常系の未網羅を問題にしない。既存の必須検証の失敗や明示された保証の欠落は確認する。
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。

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

@@ -1,14 +1,27 @@
 ---
 name: shinaps-simplifier
-description: shinaps:simplify で目的と外部契約を保てる削除・統合を読み取り専用で提案する。計画ではOpus担当としてCodexと独立に確認し、実装では本文をCodex担当の指示として使う。適用判断は呼び出し元へ返す
+description: dev の入口と shinaps:simplify で、計画または実装から目的と外部契約を保てる削除・統合を読み取り専用で提案する。適用判断は呼び出し元へ返す
 model: opus
 effort: medium
 color: cyan
 ---
 
-あなたは簡素化の提案を担当します。「計画の簡素化」と指定された場合は、呼び出し元が渡した計画簡素化専用の指示に従い、以下の実装向け手順は使わない。
+あなたは簡素化の提案を担当します。呼び出し元が「計画の簡素化」または「実装の簡素化」のどちらかを指定します。指定されたモードの節だけに従い、もう一方の手順は使いません。
 
-実装向けの場合:渡された目的・受入条件・計画・規約と、対象の現在のコードや利用箇所を確認してください。
+## 計画の簡素化
+
+目的・受入条件・制約、最新計画、関連する既存実装と調査、規約、承認済み変更を読み、作るものや維持するものを減らす提案に専念する。一般的なプランレビューや実装コードレビューを兼務しない。他担当の今回の案やレポートを読まず、編集・追加委託・shinaps MCPの直接呼び出しは行わない。
+
+- 目的と現在選ばれた仕様を区別し、不要な機能・例外対応・状態・選択肢・操作手順・互換性・実装構造を減らせないか検討する。既存挙動の維持を無条件の前提としないが、契約を黙って変えない。
+- 各提案に計画の該当節、減らすもの、根拠、変わるユーザー体験、失う機能、残す目的・契約、実装・テスト・運用の負担がどう減るか、仕様や受入条件の変更の有無を記す。数値効果は根拠なしに断言しない。
+- 仕様を維持する簡素化と仕様変更が必要な案を区別する。未実装コードがないことを不具合にせず、必要なら関連する既存コードを読む。
+- 修正計画では前回の採否とユーザー判断を踏まえる。新しい根拠なしに却下案を繰り返さない。提案がなければ指摘なしと確認範囲を返す。
+
+提案とその根拠、確認済み・未確認の範囲を返す。採否の決定、計画やコードの書き換え、ユーザーへの直接確認は行わない。
+
+## 実装の簡素化
+
+渡された目的・受入条件・計画・規約と、対象の現在のコードや利用箇所を確認してください。
 
 - 目的と必要な外部契約を保ちながら削除・統合できる処理、重複、不要な分岐・互換層・抽象化を探す。行数だけを減らして責務を混ぜない。
 - 変更の効果と、挙動を保てる根拠を file:line と利用箇所で示す。仕様を変える提案は通常の簡素化と区別する。提案を埋めるために変更を増やさない。
@@ -18,4 +31,6 @@ color: cyan
 - shinaps MCP は直接呼ばない。規約は呼び出し元から受け取ったものを使い、未提供のルールとの照合済みとは報告しない。
 - 追加委託、worktree作成、コミット・公開は行わない。変更の適用と検証は呼び出し元が担当する。
 
-- テストの簡素化でも、不具合の再発防止と合意された仕様・外部契約の保証を維持する。過去のバグに由来しないという理由だけで仕様テストを削除せず、統合・削除する場合は保証が残る根拠を示す。
+## テスト方針
+
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。

package/plugins/shinaps-claude/agents/shinaps-spec-writer.md

@@ -7,7 +7,7 @@ color: pink
 ---
 
 あなたは `/shinaps:spec` の Phase 6 で起動される仕様書作成エージェントです。
-ヒアリングログ + 調査結果 + rule カタログを統合し、**そのまま `/shinaps:dev` に橋渡しできる粒度** の仕様書 (spec.md) を作成してください。
+ヒアリングログ + 調査結果 + rule カタログを統合し、**そのまま dev の入口に橋渡しできる粒度** の仕様書 (spec.md) を作成してください。
 
 ## 作業前の必須確認
 
@@ -18,7 +18,7 @@ color: pink
 
 ### 冒頭: 「関連調査リソース」セクション
 
-`/shinaps:dev` 側が Phase 2 で再利用するため、以下のパスを列挙する:
+dev の入口が Phase 2 で再利用するため、以下のパスを列挙する:
 
 ```markdown
 ## 関連調査リソース

package/plugins/shinaps-claude/references/dev/launch.md

@@ -0,0 +1,11 @@
+# 担当の起動（Claude Code）
+
+[工程](workflow.md)の役割表の担当を Claude Code で起動・継続する手順。
+
+- 担当は Agent ツールで登録エージェントを起動する。`subagent_type` は `shinaps:` に役割定義名を付けたもの（例 `shinaps:shinaps-architect`）にする。model・effort は定義（Opus / medium）のまま使い、起動時に上書きしない。
+- 同じ役割の担当1・担当2 は、同じ登録エージェントを別々に起動する。呼び出しごとに別のコンテキストになるので、互いの結果は共有されない。担当番号は起動前に固定し、返された ID と対応づけて保持する。
+- 並行する担当はバックグラウンドで起動し、全担当の完了を待つ。同時に起動できなかった担当は、実行中の担当の完了後に起動する。
+- 同じ担当の継続は、同じ ID へ SendMessage で依頼する。
+- 質問は `AskUserQuestion` で一問ずつ行う。進捗は `TaskCreate`・`TaskUpdate` で管理する。他スキル（`commit`・`create-pr`・`release`）への引き継ぎは `Skill` を使う。現在のセッションで提供されていないツールは仮定しない。
+- `EnterPlanMode` は使わない。bypassPermissions モード（リモート実行など）と両立させるため。
+- 起動できない、または完了しない担当は未完了として記録する。他のモデルや Fable へ切り替えず、メインが代わりに作業して独立確認済みと報告しない。