@shinaps/skills 0.12.2 → 0.13.0

package/README.md

@@ -142,7 +142,7 @@ codex mcp login shinaps-ai
 
 未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`verify-ui`・`commit`・`create-pr`・`release` の基本手順はMCP接続を必須としない。
 
-## Subagents (13)
+## Subagents (Claude: 14 / Codex: 13)
 
 | Subagent | 役割 |
 |---|---|
@@ -150,6 +150,7 @@ codex mcp login shinaps-ai
 | `shinaps-investigator` | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
 | `shinaps-architect` | 実装ブループリント策定 (複数観点 → 単一案収束) |
 | `shinaps-plan-reviewer` | architect 案の批判 + 修正版最終 plan (confidence 閾値 70) |
+| `shinaps-implementer` (Claudeのみ) | 確定した計画の実装・簡素化・検証、レビュー後の修正 (Opus) |
 | `shinaps-reviewer` | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80) |
 | `shinaps-review-validator` | reviewer 指摘の実コード検証 (confirmed / false positive / partial / out-of-scope 分類) |
 | `shinaps-refine-agent` | rule 照合の並列 dispatch (ファイル現状全文と照合、Violation / Improvement / Question 分類 + changed / pre-existing 切り分け) |
@@ -160,7 +161,11 @@ 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で役割を定義する。**subagent 内では shinaps MCP を直接呼び出さず、rule 全文は Skill 側から prompt 経由で渡す** 原則を全 system prompt に明記する。MCP呼び出しの利用量が重複しないようにするため。
+Claude版はMarkdown、Codex版はTOMLで役割を定義する。
+
+Claude版の `dev` は、委託が許可されている場合に `shinaps-implementer` 1体へ実装と修正を渡す。architect と plan-reviewer は `model: best`、実装担当を含む他のエージェントは `model: opus` を使う。メインは仕様判断・進行管理と実際の差分・検証結果の確認を担う。Codex版は親モデルを継承する既存の構成を維持し、Claude専用の実装担当は追加しない。
+
+**subagent 内では shinaps MCP を直接呼び出さず、rule 全文は Skill 側から prompt 経由で渡す** 原則を全 system prompt に明記する。MCP呼び出しの利用量が重複しないようにするため。
 
 
 ## 作業成果物

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.12.2",
+  "version": "0.13.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の開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・UI検証・レビュー・コミット・PR・リリースを支援する12スキル。",
-  "version": "0.12.2",
+  "version": "0.13.0",
   "author": {
     "name": "shinaps",
     "email": "ryuta@shinaps.jp"

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

@@ -1,7 +1,7 @@
 ---
 name: shinaps-architect
 description: shinaps:dev の計画フェーズで起動される実装ブループリント策定エージェント。shinaps-explorer の探索結果と、Skill 側から渡された search_rules 由来の rule カタログ・CLAUDE.md 規約を踏まえ、複数観点を内部で検討した上で唯一最強の実装計画を断言する。出力は shinaps-plan-reviewer が直接批判 → 修正版最終 plan を返す
-model: opus
+model: best
 effort: high
 color: green
 ---

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

@@ -0,0 +1,29 @@
+---
+name: shinaps-implementer
+description: shinaps:dev で確定した計画を実装し、簡素化・検証とレビュー後の修正を担当する。目的や仕様の判断が必要な場合はメインへ返す
+model: opus
+effort: high
+color: blue
+---
+
+あなたは `/shinaps:dev` の実装担当です。メインから渡された計画・受入条件・担当範囲に従い、コード・テスト・必要なドキュメントを変更します。
+
+## 引き継ぎと実装
+
+- 適用される `AGENTS.md` / `CLAUDE.md`、計画、調査結果、設計判断の理由、渡された rule 全文を確認する。担当ファイルの現在の内容を読んでから編集する。
+- 同じ作業ツリーでは他者も作業している。既存の変更を戻さず、現在の内容に合わせる。担当範囲外の変更はメインへ相談する。
+- 既存の構造を活かして実装する。目的・仕様・受入条件の変更が必要な場合や、計画の前提が成立しない場合は、該当作業を止めて根拠と判断が必要な点をメインへ返す。通常の実装判断は既存規約に従う。
+- 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
+
+## 簡素化と検証
+
+- 実装後、目的を保ったまま削除・統合できる処理を確認し、不要な分岐・重複・互換層を減らしてからセルフレビューする。
+- プロジェクトの規約・CI・変更の影響に応じた検証を実行する。自分の実装ミスによる失敗は 3 回まで修正し、解決しなければ根拠をメインへ返す。
+- レビュー後はメインが確定した指摘と修正範囲に従って修正し、影響する検証を再実行する。
+
+## 報告と境界
+
+- 変更ファイルと変更内容、設計上の理由、簡素化した点、検証コマンドと結果、未確認事項、未解決点を返す。実行していない検証を成功と報告しない。
+- 進行管理用の `implementation.md` / `fix-log.md` / `raw/*.md` はメインが保存する。
+- コミット・push・公開、追加エージェントの起動、worktree作成は行わない。
+- shinaps MCP は直接呼ばない。ルールはメインから渡された全文を使い、未提供なら規約照合未確認として報告する。

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

@@ -1,7 +1,7 @@
 ---
 name: shinaps-plan-reviewer
 description: shinaps:dev の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、指摘を反映した修正版最終 plan までを返す。計画段階で唯一 rule を見る立場でもあるため、設計に効く規約違反は自分で拾う
-model: opus
+model: best
 effort: high
 color: purple
 ---

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

@@ -34,9 +34,10 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 | Shinaps Explorer | `shinaps-explorer` | コードベース探索、必読ファイル抽出 (spec / explore の事前調査が十分なら再起動しない) |
 | Shinaps Architect | `shinaps-architect` | 複数観点を内包した実装ブループリント策定 |
 | Shinaps Plan Reviewer | `shinaps-plan-reviewer` | architect 初回案を批判 + Critical/Warning を反映した修正版最終 plan までを返す |
+| Shinaps Implementer | `shinaps-implementer` | 確定した計画の実装・検証と、レビュー後に決まった修正 (Opus) |
 | Shinaps Reviewer | `shinaps-reviewer` | logic / design / security / performance / maintainability / rule の統合観点でレビュー |
 
-実装フェーズ (Phase 5) は **メインスレッドが直接 Edit/Write で行う**。explorer / architect / plan-review で築いた文脈・設計判断の意図をそのまま実装に持ち込むことで、レビュー指摘の文脈共有と修正ループの精度を最大化する狙い。
+委託が許可されている場合、実装と修正は **`shinaps-implementer` (Opus) 1 体**が担当し、メインは仕様判断・進行管理・成果物の確認を担う。設計判断を実装へ引き継ぎつつモデルの利用を分けるため、確定した計画・判断理由・規約を実装担当へ渡す。委託不可またはエージェントを利用できない場合はメインが担当し、その旨を報告する。
 
 ## ディレクトリ規約
 
@@ -144,42 +145,42 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 | **条件付き承認** | Part 2 で確定した plan.md をそのまま Phase 5 へ (条件は Phase 5 実装時に判断) |
 | **差し戻し** | `AskUserQuestion` で「再策定する / 指摘を未解決リスクとして明記して進む / タスク見直し」を確認。再策定の場合は Part 1 の差し戻し理由を渡して `shinaps-architect` を再起動、`raw/architect-revised-{n}.md` に保存 → 再度 plan-reviewer を起動 |
 
-### Phase 5: 実装フェーズ (メインスレッド直接実装)
+### Phase 5: 実装フェーズ
 
-メインスレッドが Phase 4 で確定した `plan.md` の実装を **直接 Edit/Write で行う**。
+#### A. 引き継ぎ
 
-#### A. 事前整合性チェック
+メインが `plan.md` を再読し、ビルド順序を `TaskCreate` で展開する。委託が許可されている場合は `shinaps-implementer` を 1 体起動し、以下を渡す:
 
-1. `plan.md` を再読し、ビルド順序を `TaskCreate` で展開
-2. Phase 2-4 で確定した必読ファイル・plan-reviewer 指摘は既にメイン context に保有済み。再 Read は不要 — 新たに発生した疑問だけ Read で補う
-3. 既存実装との衝突や前提の不一致を発見した場合は `AskUserQuestion` で「plan を上書く / 既存に合わせる / Phase 4 に戻って plan-reviewer に再策定させる」を確認
+- タスクの目的・受入条件、確定した `plan.md` 全文
+- Phase 2 の調査結果と必読ファイル、Phase 4 のレビュー指摘と設計判断の理由
+- 適用するプロジェクト規約と Phase 2 の search_rules 結果 (userRules + officialRules 全文)
+- 作業ディレクトリ、担当するファイル・責務、既存の未コミット変更、必要な検証
+- 「同じ作業ツリーには他の作業があるため、他者の変更を戻さず、現在の内容に合わせて実装する」
 
-#### B. 実装
+実装担当が作業している間は、メインも同じ範囲を編集しない。実装担当のモデルを起動時に上書きせず、定義の `model: opus` を使う。
 
-- ビルド順序に従って Edit / Write で実装
-- 目的・仕様を左右する不明点だけ一問ずつ確認する。命名等の通常の実装判断は既存規約に合わせて進める
-- plan からの逸脱は `AskUserQuestion` で確認した上で `implementation.md` に経緯を記録
-- 1 サブタスク完了ごとに `TaskUpdate` で `completed` に進める
-- **判断 / ブロッカー / 方針転換で ローカル成果物（implementation.md / 調査・レビューレポート）** を残す
+#### B. 実装と確認
 
-#### C. `implementation.md` 執筆
+実装担当は確定した計画を実装し、仕様を保つ簡素化と必要な検証まで行う。メインは報告と実際の差分を確認し、完了した項目を `TaskUpdate` で更新する。
 
-実装と並行して `implementation.md` を更新し、以下を全文記録する:
+目的・仕様を左右する不明点、計画と既存実装の不一致があれば、実装担当は変更を広げずメインへ返す。メインが既存の合意で解決できない点だけ `AskUserQuestion` で一問ずつ確認し、決定を実装担当へ返す。通常の実装判断は既存規約に従って進める。
 
-- 変更ファイル一覧 (パス + 1 行サマリ)
-- 各ファイルでの **設計上の WHY** (なぜこの設計を選んだか / plan からの逸脱があれば理由)
-- 実装中に判断した重要事項
-- 残課題・規約衝突・未解決の論点
+実装担当の実装ミスによる検証失敗は 3 回まで自己修正する。それを超える場合はメインへ失敗の根拠と未解決点を返し、メインが「さらに修正試行 / Phase 6 のレビュー対象として diff を渡す / Phase 4 に戻って再策定する」を確認する。
+
+#### C. 記録と検証
 
-#### D. 動作確認
+メインが実装担当の報告を `implementation.md` に保存する:
+
+- 変更ファイルと変更内容、設計上の理由
+- 実装中の重要な判断、計画からの変更とその合意
+- 実行した検証コマンドと結果、未実施の確認
+- 残課題・規約衝突・未解決の論点
 
-- プロジェクト規約・CI・変更の影響から必要な検証を実行する。UI変更は `verify-ui` で対象環境を確定して実画面を確認する。全案件に同じコマンド・端末構成を強制しない
-- 結果を `implementation.md` の「動作確認結果」セクションに記録
-- 自分の実装ミスによる失敗は **3 回まで自己修正**。それを超える場合は `AskUserQuestion` で「さらに修正試行 / Phase 6 のレビュー対象として diff を渡す / Phase 4 に戻って plan-reviewer に再策定させる」を確認
+必要な検証はプロジェクト規約・CI・変更の影響から決める。UI変更は `verify-ui` で対象環境を確定して実画面を確認する。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
 
 ### Phase 6: 簡素化後のセルフレビュー + refine
 
-まず `simplify` を適用し、目的を維持できる削除・簡素化をメインセッションで実施する。仕様変更の提案は確認してから進める。影響する検証を再実行し、その結果を `raw/simplify.md` に残す。
+まず `simplify` を適用し、実装担当が行った簡素化を確認する。追加で必要な削除・統合は同じ実装担当に依頼し、仕様変更の提案は確認してから進める。影響する検証を再実行した結果をメインが `raw/simplify.md` に残す。委託不可の場合はメインが実施する。
 
 その後、最終差分（staged / unstaged / untrackedを含む）と現在のファイル、plan、implementation、ruleカタログを使ってレビューする。許可された独立レビューでは `shinaps-reviewer` に読み取りだけを依頼し、`refine` で規約と照合する。委託できなければメインで両観点を確認し、独立レビュー済みとは報告しない。
 
@@ -188,15 +189,15 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 ### Phase 7: 修正ループ
 
 - **Critical は必ず自動修正** (reviewer Critical + refine の `scope=changed` な Violation、承認不要 — 動作を壊している / 規約違反の指摘)
-- **Phase 5 サブフェーズ D で検出された動作確認の失敗** も Critical として修正
+- **Phase 5 で検出された検証の失敗** も Critical として修正
 - **Warning は `AskUserQuestion` で確認**: 「全部修正 / 個別に確認 / 後回し (Issue 化) / スコープ外として記録」 (reviewer Warning + refine Improvement)
 - **refine の `scope=pre-existing` な finding は自動修正しない**。今回の実装と無関係な差分が commit に混ざるため、Violation でも `AskUserQuestion` で「今回直す / 別タスクにする」を確認する
 - **Info は記録のみで修正しない**
-- **簡素化レビューの「仕様を変えない削除・統合」は自動適用**し、Phase 5 サブフェーズ D の動作確認を再実行する。削除は追加より検証しやすく、残すほうが保守の負債になるため。**「仕様変更を伴う提案」は `AskUserQuestion` で確認**: 「採用して仕様を変える / 現状維持 / 別タスクにする」
+- **簡素化レビューの「仕様を変えない削除・統合」は自動適用**し、Phase 5 の動作確認を再実行する。削除は追加より検証しやすく、残すほうが保守の負債になるため。**「仕様変更を伴う提案」は `AskUserQuestion` で確認**: 「採用して仕様を変える / 現状維持 / 別タスクにする」
 
 修正を行った場合、`fix-log.md` に「指摘 → 修正内容 → 該当ファイル」を記録。修正判断も `fix-log.md` に残す。
 
-修正実装はメインが直接 Edit/Write で行う (Phase 5 と同じ主体)。reviewer / refine の指摘文脈をメインがそのまま保持しているため、修正判断のブレが起きにくい。大規模な再実装が必要な場合は `AskUserQuestion` で「メインで修正継続 / Phase 4 に戻って plan-reviewer に再策定させる」を確認する。
+修正実装は Phase 5 の `shinaps-implementer` を再開して依頼する。メインは確定した指摘・修正判断・現在の差分・必要な再検証を渡す。再開できなければ Phase 5 の引き継ぎ情報と実装・修正履歴を新しい実装担当へ渡す。委託不可の場合はメインが修正する。大規模な再実装が必要な場合は、メインが「現行の計画で修正継続 / Phase 4 に戻って再策定」を確認する。
 
 ### Phase 8: 修正後の再レビュー (Critical / Warning 修正時のみ)
 
@@ -218,8 +219,8 @@ Phase 7 で **Critical または Warning を修正した場合のみ**、もう
 ## 動作原則
 
 - **EnterPlanMode は使わない**: bypassPermissions モード (リモート実行など) と両立させるため
-- **実装はメインスレッドが担う**: explorer / architect / plan-review で築いた文脈・設計判断の WHY をそのまま実装と修正ループに引き継ぐため。サブエージェント委譲は計画フェーズとレビューフェーズに限定
-- **subagent は文字列応答のみを返す**: raw/*.md への Write / Edit は必ずメインスレッドが担当
+- **実装と修正は同じ担当へ引き継ぐ**: 委託が許可されている場合は Opus の `shinaps-implementer` を使い、メインが確定した計画・規約・判断理由を渡して差分を確認する
+- **レポートの保存はメインが担当**: subagent は結果を文字列で返す。実装担当は担当範囲のコード・テスト・必要なドキュメントを編集し、raw/*.md など進行管理の成果物はメインが保存する
 - **rule 照合を各 Phase に bake**: Phase 2 の `search_rules` → Phase 3 の architect prompt 埋め込み → Phase 4 の plan-reviewer (設計レベルの違反) → Phase 6 の refine 並列 (コードレベルの違反)
 - **判断・方針転換で ローカル成果物（implementation.md / 調査・レビューレポート）**
 - **目的・仕様を左右する不明点を確認**: 既存の指示で分かることや任された細部は再質問しない

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

@@ -1,6 +1,6 @@
 {
   "name": "shinaps",
-  "version": "0.12.2",
+  "version": "0.13.0",
   "description": "Shinaps AIのCodex向け開発ワークフロー",
   "skills": "./skills/"
 }