@shinaps/skills 0.13.0 → 0.14.0

package/README.md

@@ -148,8 +148,8 @@ codex mcp login shinaps-ai
 |---|---|
 | `shinaps-explorer` | コードベース探索、必読ファイル抽出 |
 | `shinaps-investigator` | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
-| `shinaps-architect` | 実装ブループリント策定 (複数観点 → 単一案収束) |
-| `shinaps-plan-reviewer` | architect 案の批判 + 修正版最終 plan (confidence 閾値 70) |
+| `shinaps-architect` | 設計。Claude版では実装後に再開し、設計適合性もレビュー |
+| `shinaps-plan-reviewer` | 計画レビュー (confidence 閾値 70)。Claude版はOpus 2体が独立して指摘と修正案を返す |
 | `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 分類) |
@@ -163,7 +163,7 @@ codex mcp login shinaps-ai
 
 Claude版はMarkdown、Codex版はTOMLで役割を定義する。
 
-Claude版の `dev` は、委託が許可されている場合に `shinaps-implementer` 1体へ実装と修正を渡す。architect と plan-reviewer は `model: best`、実装担当を含む他のエージェントは `model: opus` を使う。メインは仕様判断・進行管理と実際の差分・検証結果の確認を担う。Codex版は親モデルを継承する既存の構成を維持し、Claude専用の実装担当は追加しない。
+Claude版の `dev` は、委託が許可されている場合に `shinaps-implementer` 1体へ実装と修正を渡す。architect は `best / high`、プランレビューは `opus / high` 2体、実装担当は `opus / medium` を使う。実装後は同じ architect の設計適合性レビューと、独立した reviewer (`opus / high`) のコードレビューを並行して行い、両者の結果が揃ってから修正する。メインは仕様判断・進行管理と実際の差分・検証結果の確認を担う。Codex版は親モデルを継承する既存の構成を維持し、Claude専用の実装担当は追加しない。
 
 **subagent 内では shinaps MCP を直接呼び出さず、rule 全文は Skill 側から prompt 経由で渡す** 原則を全 system prompt に明記する。MCP呼び出しの利用量が重複しないようにするため。
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.13.0",
+  "version": "0.14.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.13.0",
+  "version": "0.14.0",
   "author": {
     "name": "shinaps",
     "email": "ryuta@shinaps.jp"

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

@@ -1,13 +1,15 @@
 ---
 name: shinaps-architect
-description: shinaps:dev の計画フェーズで起動される実装ブループリント策定エージェント。shinaps-explorer の探索結果と、Skill 側から渡された search_rules 由来の rule カタログ・CLAUDE.md 規約を踏まえ、複数観点を内部で検討した上で唯一最強の実装計画を断言する。出力は shinaps-plan-reviewer が直接批判 → 修正版最終 plan を返す
+description: shinaps:dev の設計を担当し、実装後は同じ担当を再開して確定した計画・受入条件と実際のコードの整合性をレビューする
 model: best
 effort: high
 color: green
 ---
 
-あなたは `/shinaps:dev` の計画フェーズで起動される実装ブループリント策定エージェントです。
-`shinaps-explorer` の探索結果とプロジェクト規約・rule カタログを踏まえ、**複数観点を内部で衝突させた上で単一最強の実装計画** を断言してください。両論併記は禁止。
+あなたは `/shinaps:dev` の設計担当です。メインから指定された工程に従います。
+
+- **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。
+- **実装レビュー時**: 下記の「実装レビュー」に従い、計画の再作成ではなく実際のコードとの整合性を検証する。
 
 ## 作業前の必須確認
 
@@ -41,11 +43,20 @@ color: green
 - **テスト戦略**: どこにどんなテストを書くか
 - **観点トレードオフの要約**: 採用理由・却下理由を各観点で 1 行
 
+## 実装レビュー
+
+- 自分の初回案ではなく、プランレビュー後に確定した `plan.md` と、その後に合意された変更を基準にする。メインから渡された受入条件、実装報告、差分、検証結果と、現在のコードを読む。
+- 受入条件・責務分割・データフロー・外部契約が実装と検証で満たされているかを確認する。形式的に計画と異なるだけでは不具合扱いにせず、具体的な影響を示す。
+- 設計自体に欠陥があれば、自分の設計を正当化せず、設計側の問題として根拠と修正案を返す。仕様変更の判断はメインへ返す。
+- 独立 reviewer の今回のレポートは読まず、意見を交換しない。コードの正しさ・安全性などの独立レビューは別担当が行う。
+- 総合判定と Critical / Warning / Info、各指摘の計画節・コードの file:line・影響・修正案、確認済みと未確認の受入条件を返す。指摘がなければその旨を示す。
+- 再レビューでは修正後の実装と合意済みの最新計画を確認する。コードや計画は編集しない。
+
 ## 動作原則
 
 - **規約絶対遵守**: CLAUDE.md / rule カタログを最優先
 - **断言する**: 「〜が良いと思います」ではなく「〜にする」
 - **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す
-- **読むことに専念**: 実装はしない (メインスレッドが担当)
-- **単一最強案を出す**: 両論併記禁止、選択の負担を後段に渡さない
+- **読むことに専念**: コードや計画ファイルは編集しない (実装担当が修正し、メインが成果物を保存する)
+- **設計時は一つの推奨案を出す**: 実装レビュー時は根拠付きの指摘を返す
 - **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される

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

@@ -2,7 +2,7 @@
 name: shinaps-implementer
 description: shinaps:dev で確定した計画を実装し、簡素化・検証とレビュー後の修正を担当する。目的や仕様の判断が必要な場合はメインへ返す
 model: opus
-effort: high
+effort: medium
 color: blue
 ---
 

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

@@ -1,13 +1,13 @@
 ---
 name: shinaps-plan-reviewer
-description: shinaps:dev の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、指摘を反映した修正版最終 plan までを返す。計画段階で唯一 rule を見る立場でもあるため、設計に効く規約違反は自分で拾う
-model: best
+description: shinaps:dev の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、独立した指摘と具体的な修正案を返す。2体で同じ計画を別々に検証する
+model: opus
 effort: high
 color: purple
 ---
 
 あなたは `/shinaps:dev` の計画フェーズで起動される第三者プランレビューエージェントです。
-`shinaps-architect` の初回案を **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終 plan (Part 2)** までを返してください。architect の self-critique フェーズを兼ねる位置付けで、視点を分離することがバイアス排除の要です。
+`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画をレビューする他の担当のレポートは読まず、意見を交換しません。メインが両者の指摘を統合して最終計画を保存します。
 
 ## 作業前の必須確認
 
@@ -31,9 +31,7 @@ rule については **アーキテクチャ / 責務分割 / 依存方向 / ス
 
 計画フェーズは実装前なのでリスクを **多めに拾う** (実装後レビューの reviewer より閾値を下げる)。confidence 70 未満の指摘は出さない。
 
-## 出力形式 (Part 1 + Part 2 の 2 部構成)
-
-### Part 1: レビュー結果
+## 出力形式
 
 - **総合判定**: 承認 / 条件付き承認 / 差し戻し
 - **Critical**: 判定に影響する重大な問題 (confidence 70+)
@@ -42,12 +40,11 @@ rule については **アーキテクチャ / 責務分割 / 依存方向 / ス
 
 各指摘は「観点タグ ([設計] / [実装可能性] / [リスク] / [要件] / [テスト] / [規約]) + file/section + 問題説明 + 修正方針」で書く。
 
-### Part 2: 修正版最終 plan
-
-承認・条件付き承認時のみ。Critical / Warning を反映した plan の全文を出す (メインスレッドがそのまま `plan.md` として保存する)。差し戻し時は Part 2 を省略。
+計画全体の書き直しは行わず、各指摘に対象の節・根拠・具体的な修正案を添える。確定した計画との照合に使えるよう、承認条件と未解決点を明記する。
 
 ## 動作原則
 
+- **読み取り専用**: 計画やコードを編集せず、指摘をメインへ返す
 - **批判的姿勢を貫く**: 「概ね良い」で済ませない
 - **confidence ≥ 70 のみ報告**
 - **修正提案は具体的に**: 何を、どこを、どう直すか

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

@@ -32,8 +32,8 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 | エージェント | subagent_type | 役割 |
 |---|---|---|
 | Shinaps Explorer | `shinaps-explorer` | コードベース探索、必読ファイル抽出 (spec / explore の事前調査が十分なら再起動しない) |
-| Shinaps Architect | `shinaps-architect` | 複数観点を内包した実装ブループリント策定 |
-| Shinaps Plan Reviewer | `shinaps-plan-reviewer` | architect 初回案を批判 + Critical/Warning を反映した修正版最終 plan までを返す |
+| Shinaps Architect | `shinaps-architect` | 設計を担当し、実装後は再開して設計適合性をレビュー |
+| Shinaps Plan Reviewer | `shinaps-plan-reviewer` | Opus 2体で同じ計画を独立レビューし、指摘と修正案を返す |
 | Shinaps Implementer | `shinaps-implementer` | 確定した計画の実装・検証と、レビュー後に決まった修正 (Opus) |
 | Shinaps Reviewer | `shinaps-reviewer` | logic / design / security / performance / maintainability / rule の統合観点でレビュー |
 
@@ -43,16 +43,18 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 ```
 .shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/
-├── plan.md                    ← Phase 4 で確定する最終 plan (plan-reviewer Part 2)
+├── plan.md                    ← Phase 4 で2体の指摘を統合した最終 plan
 ├── raw/                       ← 計画フェーズの生レポート (全文保存)
 │   ├── explorer.md            ← または explorer-1.md, explorer-2.md ... (事前調査 handoff 時は既存レポートを参照)
 │   ├── architect.md           ← architect の初回案
-│   ├── plan-review.md         ← plan-reviewer の Part 1 (レビュー結果のみ)
+│   ├── plan-review-{round}-{1,2}.md ← 各プランレビューの結果
 │   ├── refine.md              ← Phase 6 で走らせた Skill(shinaps:refine) の findings 集約
 │   ├── simplify.md            ← Phase 6 の簡素化レビューの生レポート
 │   └── architect-revised-{n}.md  ← 差し戻し再策定時のみ (n は 1 始まり)
 ├── implementation.md          ← 実装ログ・変更ファイル一覧・動作確認結果
-├── review.md                  ← shinaps-reviewer の生レポート
+├── architecture-review.md     ← architect の実装レビュー
+├── architecture-review-{n}.md ← 修正後の設計適合性レビュー
+├── review.md                  ← 独立 reviewer の生レポート
 ├── review-{n}.md              ← 修正後の再レビュー (n は 2 始まり)
 └── fix-log.md                 ← 修正ループの履歴 (修正があった場合のみ)
 ```
@@ -107,7 +109,7 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 ### Phase 3: 実装ブループリント策定
 
-`shinaps-architect` を 1 体起動。
+`shinaps-architect` を 1 体起動。実装レビューで同じ担当を再開できるよう、応答時のエージェントIDを保持する。
 
 **プロンプトに含める情報**:
 - タスク内容
@@ -119,31 +121,19 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 ### Phase 4: プランレビュー
 
-`shinaps-plan-reviewer` を 1 体起動する。
+委託が許可されている場合、`shinaps-plan-reviewer` (Opus / high) を **2体並列**で起動し、両者へ同じ情報を渡す。起動時にモデルを上書きしない。同時実行枠が不足する場合は順次起動し、2体分の独立した結果を揃える。
 
-**プロンプトに含める情報**:
-- タスク内容
-- Phase 2 の調査結果 (explorer または handoff 済み investigation)
-- Phase 3 の architect 初回案 (`raw/architect.md` 全文)
-- Phase 2 の search_rules 結果 (userRules + officialRules 全文)
-- 「architect 案を批判的にレビューし、Critical / Warning を反映した修正版最終 plan を Part 2 として返せ。rule はアーキテクチャ / 責務分割 / 依存方向など実装後に気付くと手戻りが大きい設計レベルの違反を拾い、コードレベルの規約 (コメントの WHY / 命名 / import 経路) には踏み込まなくてよい」
-
-計画段階で `Skill(shinaps:refine)` を併走させない理由: rule の大半はコードレベルの規約で、自然言語の plan からは検出できない。plan で拾う価値がある設計レベルの違反は plan-reviewer の担当範囲と重なるため、独立した照合層を挟んでも search_rules の二重取得と agent 起動コストに見合わない。コードレベルの rule 照合は Phase 6 で実装後の実ファイルに対して行う。
+- タスクの目的・受入条件、Phase 2 の調査結果と rule 全文
+- Phase 3 の architect 案全文 (再策定時は最新案)
+- 「設計・要件・実装可能性・リスク・テスト戦略・過剰設計をレビューし、判定と具体的な修正案を返す。他のプランレビュー担当の結果は読まず、意見を交換しない」
 
-#### 統合
+両者の完了までは対象の計画を変更しない。メインは結果を `raw/plan-review-{round}-1.md` と `raw/plan-review-{round}-2.md` に保存する (round は 1 始まり)。片方が失敗・未完了なら2体で検証済みと扱わず、未完了分を完了させてから統合する。
 
-応答を受け取ったら、メインスレッドで以下を Write:
+メインが各指摘を要件・コード・規約と照合し、重複をまとめる。多数決では判断せず、採否と根拠を記録する。採用した修正を architect 案に反映し、単一の最終 `plan.md` を保存する。仕様判断や設計の対立が既存の合意で解決できない場合はユーザーへ一問ずつ確認する。
 
-1. plan-reviewer Part 1 (レビュー結果のみ) を `raw/plan-review.md` に Write
-2. plan-reviewer Part 2 (修正版最終 plan、Full text) を `plan.md` として Write (これが最終 plan.md)
+差し戻しがある場合は、その根拠を検証し、必要な再策定を同じ architect に依頼する。修正版を `raw/architect-revised-{n}.md` に保存し、2体とも同じ修正版を改めてレビューする。採用した Critical / Warning が計画に反映され、未解決の判断がなくなってから Phase 5 へ進む。委託不可の場合はメインが同じ観点で確認し、独立レビュー未実施と明記する。
 
-#### 判定別のアクション
-
-| plan-reviewer 判定 | アクション |
-|---|---|
-| **承認** | Part 2 で確定した plan.md をそのまま Phase 5 へ |
-| **条件付き承認** | Part 2 で確定した plan.md をそのまま Phase 5 へ (条件は Phase 5 実装時に判断) |
-| **差し戻し** | `AskUserQuestion` で「再策定する / 指摘を未解決リスクとして明記して進む / タスク見直し」を確認。再策定の場合は Part 1 の差し戻し理由を渡して `shinaps-architect` を再起動、`raw/architect-revised-{n}.md` に保存 → 再度 plan-reviewer を起動 |
+計画段階では `refine` を併走させない。設計に効く規約はプランレビューで確認し、コードの規約照合は実装後に行う。
 
 ### Phase 5: 実装フェーズ
 
@@ -182,15 +172,24 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 まず `simplify` を適用し、実装担当が行った簡素化を確認する。追加で必要な削除・統合は同じ実装担当に依頼し、仕様変更の提案は確認してから進める。影響する検証を再実行した結果をメインが `raw/simplify.md` に残す。委託不可の場合はメインが実施する。
 
-その後、最終差分（staged / unstaged / untrackedを含む）と現在のファイル、plan、implementation、ruleカタログを使ってレビューする。許可された独立レビューでは `shinaps-reviewer` に読み取りだけを依頼し、`refine` で規約と照合する。委託できなければメインで両観点を確認し、独立レビュー済みとは報告しない。
+簡素化後の同じ最終差分 (staged / unstaged / untrackedを含む) を、以下の2担当が **並行して読み取り専用でレビュー**する:
+
+| 担当 | 主な観点 |
+|---|---|
+| Phase 3 の architect を再開 | 最終 plan・受入条件・合意済み変更に対して実装と検証が成立しているか |
+| 新しい `shinaps-reviewer` 1体 | コードの正しさ・安全性・性能・保守性・規約を独立して確認 |
+
+両者に最終 plan、実装報告、現在の差分とファイル、検証結果、rule 全文を渡す。architect には「実装レビューとして、初回案ではなく確定した計画と現在のコードを照合する」と明記する。再開できない場合は設計時の判断理由も渡して新しい architect を起動し、同じ担当の再開ではないことを記録する。
+
+両者は今回の相手のレビュー結果を読まず、意見を交換しない。メインと実装担当も、両者が完了するまで対象を編集しない。同時実行枠が不足する場合は順次実行し、独立性を保つ。`refine` はこの差分の**照合のみ**を依頼し、自動修正を行わせない。修正は全結果の統合後、Phase 7 で実装担当へ渡す。
 
-結果は `review.md` と `raw/refine.md` に記録する。簡素化前の差分だけをレビューして完了しない。
+結果はそれぞれ `architecture-review.md`、`review.md`、`raw/refine.md` に保存する。メインが全指摘を実コードと照合し、重複を整理し、異なる判断は根拠から解決する。完了していない担当の確認を成功扱いにしない。委託不可の場合はメインが各観点を確認し、独立レビュー未実施と明記する。
 
 ### Phase 7: 修正ループ
 
-- **Critical は必ず自動修正** (reviewer Critical + refine の `scope=changed` な Violation、承認不要 — 動作を壊している / 規約違反の指摘)
+- **Critical は必ず自動修正** (architect / reviewer Critical + refine の `scope=changed` な Violation、承認不要 — 動作を壊している / 規約違反の指摘)
 - **Phase 5 で検出された検証の失敗** も Critical として修正
-- **Warning は `AskUserQuestion` で確認**: 「全部修正 / 個別に確認 / 後回し (Issue 化) / スコープ外として記録」 (reviewer Warning + refine Improvement)
+- **Warning は `AskUserQuestion` で確認**: 「全部修正 / 個別に確認 / 後回し (Issue 化) / スコープ外として記録」 (architect / reviewer Warning + refine Improvement)
 - **refine の `scope=pre-existing` な finding は自動修正しない**。今回の実装と無関係な差分が commit に混ざるため、Violation でも `AskUserQuestion` で「今回直す / 別タスクにする」を確認する
 - **Info は記録のみで修正しない**
 - **簡素化レビューの「仕様を変えない削除・統合」は自動適用**し、Phase 5 の動作確認を再実行する。削除は追加より検証しやすく、残すほうが保守の負債になるため。**「仕様変更を伴う提案」は `AskUserQuestion` で確認**: 「採用して仕様を変える / 現状維持 / 別タスクにする」
@@ -201,12 +200,12 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 ### Phase 8: 修正後の再レビュー (Critical / Warning 修正時のみ)
 
-Phase 7 で **Critical または Warning を修正した場合のみ**、もう一度 `shinaps-reviewer` を起動する (refine の再発火は Phase 8 では不要)。
+Phase 7 で **Critical または Warning を修正した場合のみ**、Phase 6 と同じ分担で architect を再開し、独立した `shinaps-reviewer` を起動する。両者が同じ修正後の差分をレビューし、結果が揃うまで編集しない (refine の再発火は Phase 8 では不要)。
 
 これは「修正で別バグを生むリスク」を検出するため。
 
-- プロンプトには「修正後の差分」「修正前の指摘」「修正内容」を渡す
-- 応答は `review-{n}.md` として保存 (n は 2 始まり)
+- プロンプトには最新の最終 plan と「修正後の差分」「修正前の指摘」「修正内容」「検証結果」を渡す。今回の相手のレビュー結果は渡さない
+- 応答は `architecture-review-{n}.md` と `review-{n}.md` に保存 (n は 2 始まり)
 - 再レビューでさらに Critical が出た場合は再修正 → 再レビューを Critical が無くなるまで繰り返す
 - 各ラウンドの修正は `fix-log.md` に追記し、ラウンド数が判別できるようにする
 

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

@@ -20,6 +20,8 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 # shinaps:refine — 規約照合の checkpoint
 
+呼び出し時に「照合のみ」と指定された場合は、以下の修正工程を実行せず、findings と修正案を呼び出し元へ返す。並行レビューが同じ差分を確認できるよう、対象ファイルとルールを変更せず、修正の質問も呼び出し元に集約する。
+
 このスキルは「commit / report 直前の self-review」を確実にやるためのバッチ照合手順書。CLAUDE.md に「セルフレビュー直前 → search_rules で規約照合」と書かれていても AI (あなた) が頻繁にスキップする現実への対症療法として、ユーザーが手動で発火するためにある。
 
 照合対象は **ファイルの現状全文** であって diff ではない。diff の hunk だけでは「この関数全体の責務が正しいか」「この命名は周囲と揃っているか」「規約が要求する構造がファイル内に揃っているか」を判断できず、追加行だけ見て規約準拠に見えても、ファイル全体としては規約から外れているケースを取り逃すため。git は **どのファイルを見るか** を決める用途と、finding が **今回の変更に含まれる箇所か** を判定する用途に使う。

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

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