@shinaps/skills 0.16.0 → 0.16.1

package/README.md

@@ -165,7 +165,7 @@ Claude版はMarkdown、Codex版はTOMLで役割を定義する。
 
 Claude版の `dev` は、委託が許可されている場合に `shinaps-implementer` 1体へ実装と修正を渡す。architect は `best / medium`、プランレビューは `opus / medium` 2体、実装担当は `opus / medium` を使う。実装後は同じ architect の設計適合性レビューと、独立した reviewer (`opus / medium`) のコードレビューを並行して行い、両者の結果が揃ってから修正する。
 
-Claude版の `dev` は `review` (開発レビュー)・`refine`・`simplify` を Skill ツールで明示的に呼び、担当のバックグラウンド起動後に全結果を待つ。`simplify` と `refine` はそれぞれ Opus / medium の2体で同じ対象を独立して確認する。architect が提案・指摘を根拠から統合し、実装担当へ一つの修正指示を返す。メインは起動・待機・記録とユーザーへの確認を担う。実装後のレビューは初回と修正後の最大2ラウンドとし、2回目の修正後はテスト結果と残課題を報告する。最終修正が再レビューされていないことを明示し、重大な未解決事項を完了扱いにしない。UIレビューは別途Codex側で行う。
+Claude版の `dev` は `review` (開発レビュー)・`refine`・`simplify` を Skill ツールで明示的に呼び、担当のバックグラウンド起動後に全結果を待つ。`simplify` と `refine` はそれぞれ Opus / medium の2体で同じ対象を独立して確認する。architect が提案・指摘を根拠から統合し、実装担当へ一つの修正指示を返す。メインは Opus / medium で起動・待機・記録・指摘の重複整理とユーザーへの確認を担う。全指摘の出典・根拠・異論を残した整理結果を architect へ渡し、採否は architect が判断する。生レポートは保存し、必要な原文を参照できるようにする。実装後のレビューは初回と修正後の最大2ラウンドとし、2回目の修正後はテスト結果と残課題を報告する。最終修正が再レビューされていないことを明示し、重大な未解決事項を完了扱いにしない。UIレビューは別途Codex側で行う。
 
 Codex版は親モデルを継承する既存の構成を維持し、Claude専用の実装・簡素化担当は追加しない。
 
@@ -179,17 +179,19 @@ Codex版は親モデルを継承する既存の構成を維持し、Claude専用
 ```mermaid
 flowchart TD
     A["architect: best / medium<br/>設計・実装計画"] --> B["プランレビュー: Opus / medium × 2"]
-    B --> C["同じ architect が統合・計画確定"]
+    B --> P["Opus のメインが指摘を重複整理"]
+    P --> C["同じ architect が統合・計画確定"]
     C --> D["implementer: Opus / medium<br/>実装・テスト"]
     D --> E["同じ差分でレビュー開始"]
     E --> F["同じ architect: 設計適合性"]
     E --> G["review: Opus / medium × 1"]
     E --> H["refine: Opus / medium × 2"]
     E --> I["simplify: Opus / medium × 2"]
-    F --> J["同じ architect が全指摘を統合"]
-    G --> J
-    H --> J
-    I --> J
+    F --> O["Opus のメインが指摘を重複整理"]
+    G --> O
+    H --> O
+    I --> O
+    O --> J["同じ architect が全指摘を判断・統合"]
     J --> K{"修正が必要？"}
     K -- いいえ --> N["検証結果・残課題を報告"]
     K -- はい --> L["同じ implementer が修正・テスト"]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.16.0",
+  "version": "0.16.1",
   "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・リリースを支援する11スキル。",
-  "version": "0.16.0",
+  "version": "0.16.1",
   "author": {
     "name": "shinaps",
     "email": "ryuta@shinaps.jp"

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

@@ -9,8 +9,8 @@ color: green
 あなたは `/shinaps:dev` の設計担当です。メインから指定された工程に従います。
 
 - **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。
-- **プラン統合時**: 2体のプランレビュー指摘を根拠から検証し、採否と修正版の最終計画を返す。
-- **指摘統合時**: 自分の実装レビュー完了後に全担当の結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
+- **プラン統合時**: メインが事前整理した2体のプランレビュー指摘を根拠から検証し、採否と修正版の最終計画を返す。
+- **指摘統合時**: 自分の実装レビュー完了後にメインが整理した全担当の指摘を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
 - **実装レビュー時**: 下記の「実装レビュー」に従い、計画の再作成ではなく実際のコードとの整合性を検証する。
 
 ## 作業前の必須確認
@@ -56,7 +56,9 @@ color: green
 
 ## 全指摘の統合
 
-メインから「指摘統合」として、自分のレビュー、独立 reviewer、refine 2体、simplify 2体の全結果と最新の差分・検証結果を受け取る。
+メインから「指摘統合」として、自分のレビュー、独立 reviewer、refine 2体、simplify 2体の全指摘を重複整理した一覧と、原文への参照・差分の更新・検証結果を受け取る。プラン統合でも同じ形式を使う。
+
+- 整理済みの全項目を判断し、各採否を元の出典IDへ対応付ける。要約を無条件に信頼せず、曖昧な点・異論・採否を左右する根拠は原文と実コードを確認する。原文を毎回一律に読み直す必要はない。出典の欠落や未確認事項があればメインへ戻す。
 
 - 各指摘・提案を要件・コード・規約と照合する。重複をまとめ、対立は多数決ではなく根拠から判断する。自分の初期設計も修正対象に含める。
 - すべての指摘・提案の採否と理由を記録する。未確認や担当の未完了を指摘なしとして処理しない。

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

@@ -39,6 +39,17 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 委託が許可されている場合、実装と修正は **`shinaps-implementer` (Opus) 1 体**が担当し、architect が設計判断と全指摘の統合を担い、メインはスキル呼び出し・エージェントの起動と再開・待機・記録・ユーザーへの確認を担う。設計判断を実装へ引き継ぎつつモデルの利用を分けるため、確定した計画・判断理由・規約を実装担当へ渡す。委託不可またはエージェントを利用できない場合はメインが担当し、その旨を報告する。
 
+## モデルと指摘の事前整理
+
+メインは Opus / medium、architect は定義の best / medium を使う構成を推奨する。スキルからユーザーのモデル設定を変更しない。メインが別モデルの場合は Opus で整理したとは報告しない。
+
+プランレビューと実装後レビューの全結果が揃ったら、メインが次の形で整理してから architect へ渡す。整理専用のエージェントは追加しない。
+
+- 生レポートは全文保存し、全指摘に出典ID（担当・ラウンド・項番）を付ける。同じ原因・影響・修正方針の指摘だけまとめ、元の全IDと原文のパス・節を残す。判断が割れる指摘や同じ場所の別問題は統合しない。
+- 各項目に要点、重要度、対象の file:line、根拠、修正案、維持する契約、異論・不確実性を残す。全出典IDが整理後の項目に対応することを照合し、確認範囲・未確認事項も引き継ぐ。件数や文字数で指摘を落とさない。
+- メインは採否・重要度の引き下げ・対立の解消を行わない。architect が全項目を判断し、曖昧な要約や対立は原文・実コードで確かめる。
+- 整理結果はプラン用 `raw/plan-findings-{round}.md`、実装用 `raw/findings-{round}.md` に保存する。architect には整理結果と原文への参照、前回からの変更・検証結果を渡す。既に渡した計画・規約・レポート全文を毎回貼り直さず、変更部分を示す。再開できず文脈を失った場合は必要な情報を引き継ぐ。
+
 ## ディレクトリ規約
 
 ```
@@ -129,7 +140,7 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 両者の完了までは対象の計画を変更しない。メインは結果を `raw/plan-review-{round}-1.md` と `raw/plan-review-{round}-2.md` に保存する (round は 1 始まり)。片方が失敗・未完了なら2体で検証済みと扱わず、未完了分を完了させてから統合する。
 
-メインが同じ architect を「プラン統合」として再開し、2体の全指摘を渡す。architect が根拠を検証して重複・対立を整理し、採否と修正版の最終計画を返す。メインは結果を保存し、単一の `plan.md` を確定する。architect が仕様判断や範囲拡大の相談を返した場合だけ、メインがユーザーへ一問ずつ確認して決定を戻す。
+メインが同じ architect を「プラン統合」として再開し、メインが事前整理した全指摘と原文への参照を渡す。architect が根拠を検証して対立を判断し、採否と修正版の最終計画を返す。メインは結果を保存し、単一の `plan.md` を確定する。architect が仕様判断や範囲拡大の相談を返した場合だけ、メインがユーザーへ一問ずつ確認して決定を戻す。
 
 差し戻しがある場合は、その根拠を検証し、必要な再策定を同じ architect に依頼する。修正版を `raw/architect-revised-{n}.md` に保存し、2体とも同じ修正版を改めてレビューする。採用した Critical / Warning が計画に反映され、未解決の判断がなくなってから Phase 5 へ進む。委託不可の場合はメインが同じ観点で確認し、独立レビュー未実施と明記する。
 
@@ -186,11 +197,11 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 
 各スキルの確認範囲・未完了報告を確認し、未確認部分は同じ担当へ戻す。対象が大きい場合も継続または後任への引き継ぎで全対象を確認する。失敗・未完了を「指摘なし」として処理しない。
 
-自分のレビューを確定した architect と全担当の結果を保存する。初回は `architecture-review.md` / `review.md` / `raw/refine.md` / `raw/simplify.md`、2回目は各ファイル名に `-2` を付ける。全結果が揃った後で初めて同じ architect を「指摘統合」として再開し、自分のレビューを含む全結果・現在の差分・検証結果・ラウンド番号を渡す。独立レビュー中に他担当の結果を渡さない。
+自分のレビューを確定した architect と全担当の結果を保存する。初回は `architecture-review.md` / `review.md` / `raw/refine.md` / `raw/simplify.md`、2回目は各ファイル名に `-2` を付ける。全結果が揃った後、メインが architect 自身の確定済みレビューも含めて事前整理する。その後で同じ architect を「指摘統合」として再開し、整理した全指摘・原文への参照・差分の更新・検証結果・ラウンド番号を渡す。独立レビュー中に他担当の結果を渡さない。
 
 ### Phase 7: architect が統合し、implementer が修正
 
-architect が review・refine・simplify の全指摘を根拠から検証し、重複・対立を整理する。全指摘の採否と理由、採用した修正の対象・責務・具体的な変更・維持する契約・必要な検証を、一つの修正指示として返す。メインはそのまま記録し、仕様・受入条件の変更や未許可の範囲拡大が必要な点だけユーザーに確認する。通常の設計・修正判断をメインでやり直さない。
+architect が review・refine・simplify の整理された全指摘を根拠から検証し、対立を判断する。全指摘の採否と理由、採用した修正の対象・責務・具体的な変更・維持する契約・必要な検証を、一つの修正指示として返す。メインはそのまま記録し、仕様・受入条件の変更や未許可の範囲拡大が必要な点だけユーザーに確認する。通常の設計・修正判断をメインでやり直さない。
 
 修正不要なら Phase 9 へ進む。修正があれば、メインが同じ `shinaps-implementer` を再開し、architect の修正指示・確定した計画・現在の差分・規約・検証条件を渡す。再開できなければ実装履歴と採否を新しい担当へ引き継ぐ。architect は次のレビューに備えて保持し、自分でコードを編集したり、実装担当を追加起動したりしない。
 

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

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