@shinaps/skills 0.35.2 → 0.36.0

package/plugins/shinaps-codex/managed-agents/agents/shinaps-reviewer.md

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

package/plugins/shinaps-codex/managed-agents/skills/dev-managed-cc/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: dev-managed-cc
-description: Claude Managed Agents のセッションで、作業に応じた担当と人数を決めて計画・実装・検証・独立レビューを進め、範囲を限ったコミット・push・draft PR で終える。
+description: Claude Managed Agents のセッションで、初回メッセージで受けた体制（LITE・BASIC・ULTRA）の担当で進め、BASIC・ULTRAでは作業に応じて追加の担当を決めて計画・実装・検証・独立レビューを進め、範囲を限ったコミット・push・draft PR で終える。
 ---
 
 # Managed Agents で開発する
 
-[体制の判断](references/staffing.md)・[工程](references/workflow.md)・[起動手順](references/launch.md)を読んで進める。人数を固定しない。初回メッセージに初期体制があれば引き継ぎ、なければ lead が関連コードを確認して設計前に決める。途中でも必要な役割・人数を追加する。
+[体制の判断](references/staffing.md)・[工程](references/workflow.md)・[起動手順](references/launch.md)を読んで進める。初回メッセージの体制の担当で進め、BASIC・ULTRAでは lead が関連コードを確認して計画の前に追加の担当を決める。継続のターンでは初回の体制を引き継ぎ、利用者がメッセージに体制を書けばそれに従う。途中でも必要な役割・人数を追加する（BASIC・ULTRA。LITEで足りないときは `状態: 質問` で体制の変更を相談する）。
 
 ## 初回メッセージ
 
@@ -15,6 +15,7 @@ description: Claude Managed Agents のセッションで、作業に応じた担
 - base ブランチと、その比較元の SHA
 - head ブランチ名
 - 範囲と受入条件
+- 体制（LITE・BASIC・ULTRA）
 - 許可（commit・push・draft PR 作成のうち、明示されたものだけ）
 - 予算
 
@@ -26,7 +27,7 @@ description: Claude Managed Agents のセッションで、作業に応じた担
 
 必須入力が一つでも欠けていれば作業を始めず、欠落を列挙して `状態: 質問` でターンを終える。次の利用者メッセージで揃えば始める。許可は利用者のメッセージで明示された操作だけとし、構成の導入やリポジトリの設定から推定しない。
 
-予算はセッション作成時の `max_list_cost` でだけ強制される。lead は消費額を観測できないので、体制と再確認の回数を決める目安として扱う。
+予算はセッション作成時の `max_list_cost` でだけ強制される。lead は消費額を観測できないので、追加の担当と再確認の回数を決める目安として扱う。
 
 ## 規約
 
@@ -46,7 +47,7 @@ description: Claude Managed Agents のセッションで、作業に応じた担
 - PR の URL
 - 検証結果
 - 独立レビューの結果と未解決の指摘
-- 体制と、途中で変えた場合の理由
+- 体制（必須担当の完了・未完了と、合意による未実施を含む）と、途中で変えた場合の理由
 - 書き込み制限の比較で見つかった違い
 - 未検証の事項
 - Shinaps AI rule: 未照合

package/plugins/shinaps-codex/managed-agents/skills/dev-managed-cc/references/launch.md

@@ -15,7 +15,7 @@
 
 役割定義は Claude Code 向けの記述を含むので、全ての依頼の冒頭に次を入れる。
 
-> このセッションでは Shinaps AI の rule を取得しないので、役割定義にある rule の検索結果は渡されない。規約の全文はリポジトリの `AGENTS.md`・`CLAUDE.md` とその参照先である。役割定義の `~/.claude/CLAUDE.md` は `/mnt/session/uploads/CLAUDE.md` を指す（添付されていなければ無い）。refine 担当はいないので、規約照合はコードレビュー担当が行う。explorer と verifier の担当もいない。探索は設計担当、いなければ実装担当が自分で行う。担当は commit・push・PR 作成・GitHub の操作をしない。
+> このセッションでは Shinaps AI の rule を取得しないので、役割定義にある rule の検索結果は渡されない。規約の全文はリポジトリの `AGENTS.md`・`CLAUDE.md` とその参照先である。役割定義の `~/.claude/CLAUDE.md` は `/mnt/session/uploads/CLAUDE.md` を指す（添付されていなければ無い）。explorer の担当はいない。探索は設計担当が自分で行う。担当は commit・push・PR 作成・GitHub の操作をしない。
 
 ## 書き込みの制限と比較
 

package/plugins/shinaps-codex/managed-agents/skills/dev-managed-cc/references/staffing.md

@@ -1,42 +1,55 @@
 # 実装体制の判断
 
-人数を入口名や変更行数で固定しない。lead が設計担当の起動前に初期体制を決める。初回メッセージに初期体制があれば引き継ぐ。
+体制はLITE・BASIC・ULTRAの3段階で、初回メッセージで受け取る。lead は体制の種類を確認・選び直しせず、BASIC・ULTRAでは受け取った体制の必須担当を下限に作業に応じて担当を追加でき、LITEは表の2名だけで進める。継続のターンでは初回の体制を引き継ぎ、利用者がメッセージに体制を書けばそれに従う。
 
-## 判断すること
+## 体制の種類
 
-- **不確実性**: 要件と既存の解法が明確か。責務・依存方向・設計案の比較に独立した検討が必要か。
+| 役割 | LITE | BASIC | ULTRA |
+| --- | --- | --- | --- |
+| 設計 | 置かない（実装担当が短い計画と検証方針を作る） | 1名（設計担当1） | 2名（独立に設計し、担当1が統合） |
+| 計画レビュー | 置かない | 1名 | 2名 |
+| 計画簡素化 | 置かない | 1名 | 2名 |
+| 実装 | 1名 | 1名 | 1名 |
+| 実装後の設計適合性 | 独立レビュー担当（design 観点で計画と実コードを照合する） | 設計担当1 | 設計担当1 |
+| 実装後の独立コードレビュー | 独立したOpusの1名（正しさ・可読性・慣習・規約照合・簡素化を兼ねる） | 独立した1名（可読性・慣習と規約照合も兼ねる） | 1名 |
+| 実装後の refine | （独立レビュー担当が兼ねる） | （独立コードレビューの担当が兼ねる） | 1名 |
+| 実装後の可読性・慣習 | （独立レビュー担当が兼ねる） | （独立コードレビューの担当が兼ねる） | 技術領域ごとに1名 |
+| 実装後の簡素化 | （独立レビュー担当が兼ねる） | 独立した1名 | 1名 |
+| 指摘の整理 | 実装担当（設計責任者） | 設計担当1（計画と実装後） | 計画と実装後の各検証ラウンドで、新規の指摘検証担当1名 |
+| 採否 | 実装担当（設計責任者） | 設計担当1 | 設計担当1 |
+
+設計責任者は設計担当1、設計担当を置かない体制（LITE）では実装担当とする。各役割の定義・継続・新規にする単位は[工程](workflow.md)の「役割と継続」に従う。探索の担当は置けないので、設計担当（LITEでは実装担当）が設計に必要な範囲を調べる。lead は体制を決める材料だけを確認する。
+
+## lead の裁量
+
+lead は受け取った体制の必須担当に加えて、役割の追加、技術領域ごとの割り当て、並列化、複数担当の範囲分担を決める。BASIC・ULTRAでは、追加を次の基準で判断する。
+
+- **不確実性**: 要件と既存の解法が明確か。責務・依存方向・設計案の比較に、下限を超える独立した検討が必要か。
 - **影響範囲**: 局所的で利用側を追えるか。複数機能・共通基盤・実行環境をまたぐか。
 - **失敗時の影響と検証可能性**: 容易に戻せて既存テストで確認できるか。認証・課金・データ保全などの重要な契約や、再現・検証が難しい挙動に関わるか。
 
-点数・行数・一律の大小ラベルで人数を自動決定せず、未解決の問いと必要な独立確認に担当を対応させる。初期確認だけで分からなければ、まず探索の範囲を決め、その結果で設計前に体制を更新する。担当を起動するためだけの調査や計画書は増やさない。
+点数・行数・一律の大小ラベルで人数を自動決定せず、未解決の問いと必要な独立確認に担当を対応させる。担当を起動するためだけの調査や計画書は増やさない。追加は必要な役割だけにし、どれか一つを増やすために全役割を増やさない。
 
-| 役割 | 専任を置く判断と人数 | 専任を置かない場合 |
-| --- | --- | --- |
-| 設計 | 責務・依存・方式の判断が必要なら配置。競合する案や重大な見落としを独立に比較する必要があれば複数 | 実装担当が短い技術計画と検証方針を作り、設計責任者を兼ねる |
-| 計画レビュー | 実装前に検証すべき設計リスクがあれば配置。異なる観点の独立確認が必要なら複数 | 計画を作った担当が要件カバーと実現可能性の根拠を計画に書き、独立コードレビューが計画自体も誤りうるものとして確かめる |
-| 計画／実装の簡素化 | 状態・抽象化・変更範囲の複雑さに専門の検討が必要なら配置。計画と実装で別々に判断 | 計画は設計責任者、実装は実装担当とコードレビュー担当が確認 |
-| 実装 | 1体。修正も同じ担当に戻す | 委任できない場合も lead は代行しない。再開・交代し、できなければ `状態: 未完了` で必要な判断を返す（[起動手順](launch.md)） |
-| 独立コードレビュー | 最低1体。重要な契約や複数領域の見落としを独立に確認する必要があれば追加 | 起動不能なら独立レビュー未完了。自己レビューで代替完了にしない |
+LITEでは、探索を含む担当を追加しない。必要な調査・設計・簡素化・テスト・指摘の根拠の確認と修正は実装担当が、独立した確認は独立レビュー担当が担う。2名で足りないと分かったら、理由を添えて `状態: 質問` でBASIC・ULTRAへの変更を利用者に相談する。
 
-探索・指摘検証・規約照合の専任は置けない。専任を置かない責務は lead へ戻さず、成果物を作った担当から独立している必要があるかで既存の担当へ割り当てる。
+## 技術領域
 
-- 探索は設計担当1、いなければ実装担当が計画・実装に必要な範囲を調べる。lead は体制を決める材料だけを確認する。
-- 指摘検証は設計責任者が全指摘の根拠・出典・重複・対立・未確認を整理して採否を決め、再現や検証が必要なら実装担当へ依頼する。設計担当がいなければ実装担当が整理する。採否は[工程](workflow.md)の「指摘の検証と統合」に従う。対立・不確実な指摘を黙って消さない。
-- 規約照合はコードレビュー担当に規約全文と照合責務を渡す。
+技術領域は、Web・API・iOSのように技術や実装慣習が違う領域とする。配布先・写し・文書の分類は、別の技術領域に数えない。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属するようにする。
 
-明確で局所的な変更なら、実装担当が短い計画を作り、実装1体・独立コードレビュー1体で進められる。設計が難しければ設計担当や計画レビューを追加し、設計案の独立比較が必要なら設計担当を複数にする。コードのリスクが高い場合はコードレビューを増やす。どれか一つを増やすために全役割を複数にしない。
+## 記録
 
-起動前に、判断の根拠、工程ごとの役割・人数・確認範囲、専任なしの責任者、必須検証、設計と指摘の統合責任者を作業記録へ短く残す。設計担当がいれば担当1が設計・統合を継続し、いなければ実装担当が設計責任者になる。
+計画の前に、受け取った体制、追加した担当とその根拠、工程ごとの役割・人数・確認範囲、技術領域ごとに担当を置く場合はその割り当て、必須検証を作業記録へ短く残す。
 
 ## 途中の増員
 
-初期体制は上限ではない。設計上の新しい不確実性、影響領域の追加、重要な契約への影響、検証失敗、指摘の対立が判明した時点で lead が必要な役割・人数・確認範囲を増やし、理由と体制の変更を記録する。担当からの提案は lead が判断する。追加担当の確認が必要な工程は結果が揃うまで完了にしない。
+BASIC・ULTRAでは、受け取った体制は上限ではない。LITEでは増やさず、上の相談に従う。設計上の新しい不確実性、影響領域の追加、重要な契約への影響、検証失敗、指摘の対立が判明した時点で lead が必要な役割・人数・確認範囲を増やし、理由と体制の変更を記録する。担当からの提案は lead が判断する。追加担当の確認が必要な工程は結果が揃うまで完了にしない。
 
-- 新しい担当には現在の要件・同じ版の対象・規約・確定済み判断を渡す。独立確認を求める場合、他担当の今回の未確定結果は渡さない。
-- 設計担当を途中で置く場合は担当1を統合責任者として引き継ぎ、実装担当の旧計画も検討対象にする。既存担当の仕事を理由なく最初から繰り返さない。
+- 新しい担当には現在の要件・同じ版の対象・規約・確定済み判断を渡す。独立確認を求める場合、他担当の今回の未確定結果は渡さない。既存担当の仕事を理由なく最初から繰り返さない。
 - 増員で既存の未完了・不利な指摘を消さない。同じ対象への増員・交代でレビューラウンドの上限をリセットしない。枠不足は順番に起動し、人数を黙って減らさない。
 - 体制判断は操作・予算の許可を作らない。仕様・範囲・明示された人数制限・許可・予算を変える必要がある場合だけ、`状態: 質問` で利用者に一問で確認する。
 
-## 人数によらず維持する条件
+## 維持する条件
+
+受け取った体制の必須担当を、自己確認・体制の表に無い兼務・lead の代行で完了扱いにせず、委任できない・起動できないなら未完了とする。予算・明示された人数制限が下限を満たさない場合は、`状態: 質問` で利用者に一問で確認する。合意があれば、実施しない必須担当を未実施として記録・報告し、品質上の完了とは報告しない。合意が無ければ `状態: 未完了` で返す。独立レビュー担当の確認を、実装担当の自己確認で代えない。
 
-要件と影響範囲の確認、必要なテストとプロジェクトの必須検証、実装者と独立したコードレビュー、適用規約の照合、全指摘の採否と根拠の記録を維持する。専任なしは責務の省略ではない。自己レビューや設計責任者の検証は、実装者と独立したコードレビュー（最低1体）の代わりにならない。担当が未完了、必須検証が失敗した場合はその状態を報告し、確認済みと偽らない。重大な未解決事項を完了にしない。
+要件と影響範囲の確認、必要なテストとプロジェクトの必須検証、適用規約の照合、全指摘の採否と根拠の記録を維持する。担当が未完了、必須検証が失敗した場合はその状態を報告し、確認済みと偽らない。重大な未解決事項を完了にしない。

package/plugins/shinaps-codex/managed-agents/skills/dev-managed-cc/references/workflow.md

@@ -1,39 +1,47 @@
 # dev の工程（Managed Agents）
 
-Claude Code の dev の工程を、Managed Agents のセッション向けに絞ったもの。役割・人数は[実装体制の判断](staffing.md)に従って作業ごとに決め、担当の委任・継続・作業先・出力は[起動手順](launch.md)に従う。
+Claude Code の dev の工程を、Managed Agents のセッション向けに絞ったもの。役割・人数は初回メッセージの体制（[実装体制の判断](staffing.md)）の担当で進め（BASIC・ULTRAでは必須担当を下限に追加できる）、担当の委任・継続・作業先・出力は[起動手順](launch.md)に従う。
 
 ## 役割と継続
 
-下の表は必須起動一覧ではない。
+下の表は各役割の工程と継続を定める。起動する担当と人数は、受け取った体制の表（`staffing.md`）に従う。
 
 | 工程 | 役割定義 | 継続と責任 |
 | --- | --- | --- |
-| Phase 3・4・6・7 | `shinaps-architect` | 担当1は設計・統合・設計適合性を継続。担当2以降は独立設計と追加確認のみ |
+| Phase 3・4・6・7 | `shinaps-architect` | 担当1は設計・統合・設計適合性・指摘統合・修正計画を継続。担当2以降は独立設計と追加確認のみ |
 | Phase 4 | `shinaps-plan-reviewer` | 修正版の再確認も同じ担当 |
-| Phase 4・6 | `shinaps-simplifier` | 計画の再確認は継続。実装の簡素化は別担当 |
-| Phase 3・5・7 | `shinaps-implementer` | 1体。同じ担当へ修正を返す。設計担当がいなければ計画と指摘の統合も担う |
-| Phase 6 | `shinaps-reviewer` | 実装担当とは別。レビューラウンドごとに新規。規約照合も担う |
+| Phase 4・6 | `shinaps-simplifier` | 計画の簡素化は修正版の再確認も同じ担当。実装の簡素化は計画とは別の担当で、ラウンドと修正サイクルをまたいで継続 |
+| Phase 4・6 | `shinaps-review-verifier` | 指摘検証担当を置く体制で、検証ラウンド（計画確認と実装後レビューの各ラウンドに1回）ごとに新規。今回の指摘を出した担当を流用しない |
+| Phase 3・5・7 | `shinaps-implementer` | 1体。修正も同じ担当。設計担当を置かない体制（LITE）では、設計責任者として計画と指摘の整理・採否も担う |
+| Phase 6 | `shinaps-reviewer` | 独立コードレビューは実装担当とは別で、レビューラウンドごとに新規。独立コードレビューを含む複数の種類を兼ねる場合は、独立コードレビューの規則に従う。可読性・慣習レビューを技術領域ごとに置く場合は、ラウンドと修正サイクルをまたいで継続し、技術領域が増えたら追加 |
+| Phase 6 | `shinaps-refine-agent` | refine 担当を置く体制で、ラウンドと修正サイクルをまたいで継続 |
 
-- 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版を依頼に渡す。実装担当にはファイルの所有範囲を明記する。
+- 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・成果物のパス・引き継ぎ先を依頼に渡す。実装担当にはファイルの所有範囲を明記する。
 - 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませない。対象を編集中にレビューせず、全結果が揃うまで lead と実装担当も対象を変えない。
-- lead は体制と工程の調整、委任・待機・引き渡し、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。実装・修正、指摘の技術的検証と採否、設計適合性の実コード照合、既存の証拠がある検証の再実行は引き取らない。継続のターンで来る質問・修正も同じで、修正は同じ実装担当へ返す。
+- lead は体制と工程の調整、委任・待機・引き渡し、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。実装・修正、指摘の技術的検証と採否、設計適合性の実コード照合、既存の証拠がある検証の再実行は引き取らない。継続のターンで来る質問・修正も同じ分担で扱う。
+- **修正サイクル**: 継続のターンで実装の修正が必要になったら、契機によらず、未対応の指摘の集合を一つの入力にして次の順に進める。
+  1. 設計責任者が修正計画と、影響を受ける工程を決める。
+  2. 設計・契約・検証条件を変える場合だけ、Phase 4 の扱いで再確認する。
+  3. 同じ実装担当が修正する（Phase 5）。
+  4. Phase 6 の担当（受け取った体制のとおり）と、指摘検証担当を置く体制ではその新規の担当が確認する。範囲は修正とその影響範囲とし、確定できなければ広げる。
+  5. Phase 7 で統合・修正する。
 - 起動失敗・空回答・未確認範囲を「指摘なし」にしない。
 
-## Phase 1: タスクと初期体制
+## Phase 1: タスクと体制
 
-初回メッセージの必須入力が揃っていることを確かめ、目的・受入条件・範囲を確定する。作業先を[起動手順](launch.md)に従って用意し、関連コードと検証方法を必要な範囲だけ確認して初期体制を決め、作業記録に残す。
+初回メッセージの必須入力が揃っていることを確かめ、目的・受入条件・範囲を確定する。作業先を[起動手順](launch.md)に従って用意し、関連コードと検証方法を必要な範囲だけ確認して、初回メッセージの体制の担当で進め、BASIC・ULTRAでは追加の担当を決め、作業記録に残す。
 
 ## Phase 2: 規約と必要な探索
 
-規約の範囲は [SKILL.md の規約](../SKILL.md#規約)に従う。lead が読んで以降の担当へ全文を渡す。探索は[実装体制の判断](staffing.md)の割り当てに従い、専任は委任しない。
+規約の範囲は [SKILL.md の規約](../SKILL.md#規約)に従う。lead が読んで以降の担当へ全文を渡す。探索は各設計担当が自分の設計に必要な範囲で行う。
 
 ## Phase 3: 設計と計画
 
-設計責任者は設計担当1、専任なしなら実装担当とする。計画には目的・不変条件・変更範囲（対象ファイルと責務）・実装順・検証を書く。設計担当が複数なら同じ入力で独立に検討させ、担当1が根拠で一つの案へ統合する。
+設計責任者は設計担当1、設計担当を置かない体制（LITE）では実装担当とする。計画には目的・不変条件・変更範囲（対象ファイルと責務）・実装順・検証を書く。設計担当が複数なら同じ入力で独立に検討させ、担当1が根拠で一つの案へ統合する。LITEでは実装担当が短い計画と検証方針を作り、報告の冒頭に書く。
 
 ## Phase 4: 計画の確認
 
-選んだ計画レビュー・計画簡素化の担当へ同じ計画を渡し、指摘を「指摘の検証と統合」に従って扱う。同じ対象について初回を1として最大2ラウンドとする。上限到達後に計画を修正した場合は、未再確認の変更と残課題を記録する。重大な設計リスク、仕様・許可の未決事項、必要な担当の未完了があれば Phase 5 へ進まず未完了で返す。
+計画レビュー・計画簡素化の担当へ同じ計画を渡し、指摘を「指摘の検証と統合」に従って扱う。LITEではこの工程を起動せず、計画はPhase 6の独立レビュー担当が、計画自体も誤りうる前提で確かめる。同じ対象について初回を1として最大2ラウンドとする。上限到達後に計画を修正した場合は、未再確認の変更と残課題を記録する。重大な設計リスク、仕様・許可の未決事項、必要な担当の未完了があれば Phase 5 へ進まず未完了で返す。
 
 ## Phase 5: 実装と検証
 
@@ -41,15 +49,23 @@ Claude Code の dev の工程を、Managed Agents のセッション向けに絞
 
 ## Phase 6: 実装後の確認
 
-同じ差分を固定し、選んだ担当を並行して委任する。実装者と独立したコードレビューは最低1体。設計適合性は設計担当1（専任なしならコードレビュー担当）、規約照合はコードレビュー担当、実装の簡素化は選んだ simplifier（専任なしなら実装担当とコードレビュー担当）が確認する。staged・unstaged・untracked を含めて対象を特定する。
+同じ差分を固定し、受け取った体制の担当と追加した担当を並行して委任する。技術領域ごとに可読性担当を置く場合は、全変更ファイルがちょうど1名の範囲に属することを確かめ、足りない技術領域があれば担当を足す。staged・unstaged・untracked を含めて対象を特定する。
+
+- 設計適合性: 設計担当1（LITEでは独立レビュー担当）が計画・受入条件・責務・依存方向と実コードを照合する。
+- 独立コードレビュー: 新規の `shinaps-reviewer`（独立コードレビュー）が、計画自体も誤りうるものとして正しさ・安全性・性能を確認する。
+- 規約照合: refine 担当を置く体制では `shinaps-refine-agent` へ、規約（`AGENTS.md`・`CLAUDE.md` とその参照先）の全文を rule として、比較元からの差分コマンド（`git diff <比較元> -- <path>`）を変更範囲の確認コマンドとして渡す。未追跡の新規ファイルは全行を今回の変更として扱う。BASIC・LITEでは独立コードレビューの担当が、同じ規約全文で行う。
+- 実装の簡素化: 実装の簡素化の `shinaps-simplifier`（LITEでは独立レビュー担当が兼ねる）が、目的・契約を保って削除・統合できる内容を確認する。
+- 可読性・慣習: 体制の表の担当（ULTRAでは技術領域ごとの `shinaps-reviewer`（可読性・慣習レビュー）、BASIC・LITEでは独立コードレビューの担当が種類を複数指定されて兼ねる）へ、担当する範囲の差分と対象ファイルの現状全文、規約、計画に記した先例、合意済み仕様を渡す。
+
+LITEでは、独立レビュー担当を両方の種類で委任し、設計適合性と簡素化もあわせて依頼する。
 
 ## 指摘の検証と統合（Phase 4・6）
 
-設計責任者（設計担当1、専任なしなら実装担当）が全指摘の根拠・誤認・重複・対立・未確認を区別し、全項目の採否と理由、必要な修正と検証をまとめる。自分の成果物への指摘も根拠で採否を決め、その確認を独立検証とは報告しない。事実の食い違いや根拠不足で判断できない指摘だけ指摘元に確認する。指摘元への確認は同じ担当の継続で行い、レビューのラウンドに数えない。再現・検証が必要なら実装担当へ依頼する。仕様・受入条件の変更や許可範囲の拡大は利用者の合意前に採用しない。
+指摘の整理は、設計責任者が採否を決める前に、指摘検証担当を置く体制では検証ラウンドごとに新規の `shinaps-review-verifier` が行い、いない体制では設計責任者が行う。全レポート・出典・確認範囲を使って全指摘の根拠・誤認・重複・対立・未確認を区別し、出典IDを保持して整理する。設計責任者がその結果から全項目の採否と理由、必要な修正と検証をまとめる。自分の成果物への指摘も根拠で採否を決め、その確認を独立検証とは報告しない。事実の食い違いや根拠不足で判断できない指摘だけ指摘元に確認する。指摘元への確認は同じ担当の継続で行い、レビューのラウンドに数えない。再現・検証が必要なら実装担当へ依頼する。仕様・受入条件の変更や許可範囲の拡大は利用者の合意前に採用しない。
 
 ## Phase 7〜8: 修正と終了判定
 
-修正指示を同じ実装担当へ返す。実装後の全体レビューは初回を1として最大2ラウンド。2回目の後に修正したら必要なテストを行い、最終差分が再レビューされていないことを報告する。重大な未解決事項、必須検証の失敗、必要な担当の未完了が残れば品質上の完了とは報告しない。
+修正指示を同じ実装担当へ返す。実装後の全体レビューは、最初の dev と各修正サイクルのそれぞれで、初回を1として最大2ラウンド。同じサイクルの中の増員・交代・計画変更では上限をリセットしない。2回目の後に修正したら必要なテストを行い、最終差分が再レビューされていないことを報告する。重大な未解決事項、必須検証の失敗、必要な担当の未完了が残れば品質上の完了とは報告しない。
 
 ## Phase 9: コミット・push・draft PR と報告
 

package/plugins/shinaps-codex/references/dev/staffing.md

@@ -1,45 +1,72 @@
 # 実装体制の判断
 
-人数を入口名や変更行数で固定しない。devのメインが設計担当の起動前に初期体制を決める。linear-execute の進行役は各Issue開始時に受入条件・関連範囲・既存検証・リスクを材料として渡し、体制は決めない。「メイン」はdevを実行するClaude Codeのセッション（CLIまたは対話）を指し、linear-executeの進行役とは区別する。
+devの体制はLITE・BASIC・ULTRAの3段階で、作業ごとに人が選ぶ。BASIC・ULTRAでは選んだ体制の必須担当を下限にメインが担当を追加でき、LITEは表の2名だけで進める。「メイン」はdevを実行するClaude Codeのセッション（CLIまたは対話）を指し、linear-executeの進行役とは区別する。linear-execute の進行役は各Issue開始時に、確認した体制と、受入条件・関連範囲・既存検証・リスクを材料として渡す。
 
-## 判断すること
+## 体制の種類
 
-- **不確実性**: 要件と既存の解法が明確か。責務・依存方向・設計案の比較に独立した検討が必要か。
+| 役割 | LITE | BASIC | ULTRA |
+| --- | --- | --- | --- |
+| 設計 | 置かない（実装担当が短い計画と検証方針を作る） | 1名（設計担当1） | 2名（独立に設計し、担当1が統合） |
+| 計画レビュー | 置かない | 1名 | 2名 |
+| 計画簡素化 | 置かない | 1名 | 2名 |
+| 実装 | 1名 | 1名 | 1名 |
+| 実装後の設計適合性 | 独立レビュー担当（design 観点で計画と実コードを照合する） | 設計担当1 | 設計担当1 |
+| 実装後の独立コードレビュー | 独立したOpusの1名（正しさ・可読性・慣習・規約照合・簡素化を兼ねる） | 独立した1名（可読性・慣習と規約照合も兼ねる） | 1名 |
+| 実装後の refine | （独立レビュー担当が兼ねる） | （独立コードレビューの担当が兼ねる） | 1名 |
+| 実装後の可読性・慣習 | （独立レビュー担当が兼ねる） | （独立コードレビューの担当が兼ねる） | 技術領域ごとに1名 |
+| 実装後の簡素化 | （独立レビュー担当が兼ねる） | 独立した1名 | 1名 |
+| 指摘の整理 | 実装担当（設計責任者） | 設計担当1（計画と実装後） | 計画と実装後の各検証ラウンドで、新規の指摘検証担当1名 |
+| 採否 | 実装担当（設計責任者） | 設計担当1 | 設計担当1 |
+
+設計責任者は設計担当1、設計担当を置かない体制（LITE）では実装担当とする。各役割の定義・継続・新規にする単位は[工程](workflow.md)の「役割と継続」に従う。探索は必須にしない。探索担当を置かない場合は、設計担当（LITEでは実装担当）が設計に必要な範囲を調べる。体制・経路（auto・manual）・メインのモデルは別の項目で、互いに影響しない。
+
+## 体制の選択
+
+体制は人が3択で選ぶ。確認する側は、下の「メインの裁量」の3つの基準にもとづく推奨と理由を添えて、経路の確認とは別の一問で聞く。推奨の目安は次のとおり。
+
+- LITE: 明確で局所的で、既存のテストで確かめやすい作業。
+- ULTRA: 重要な契約、複数の技術領域、検証が難しい挙動に関わる作業。
+- BASIC: それ以外の作業。
+
+確認の規則は次のとおり。
+
+- 確認するのは人への確認の窓口とする。Linear進行では[停止と人への確認](../linear/workflow.md)の経路の規則に従い、単独のdevではメインが行う。
+- 各Issueの着手時と、人の指摘の一括修正を始めるたびに確認する。次の場合は聞き直さない: 依頼に体制が書かれている、利用者が範囲全体に体制を指定している、同じ修正単位を再開する、QAの差し戻しやコミット中の指摘で修正する、個々の指摘。
+- 人の修正開始以外で始まる修正サイクルは、その作業で直近に選んだ体制を使う。
+- 体制を変えたときは、新しく必要になった担当を新規に起動し、既存の成果と確定済みの判断・採否を引き継ぐ。レビューの回数はリセットしない。
+
+## メインの裁量
+
+メインは選んだ体制の必須担当に加えて、探索担当の配置、役割の追加、技術領域ごとの割り当て、並列化、複数担当の範囲分担を決める。BASIC・ULTRAでは、追加を次の基準で判断する（体制の推奨にも使う）。
+
+- **不確実性**: 要件と既存の解法が明確か。責務・依存方向・設計案の比較に、下限を超える独立した検討が必要か。
 - **影響範囲**: 局所的で利用側を追えるか。複数機能・共通基盤・実行環境をまたぐか。
 - **失敗時の影響と検証可能性**: 容易に戻せて既存テストで確認できるか。認証・課金・データ保全などの重要な契約や、再現・検証が難しい挙動に関わるか。
 
-点数・行数・一律の大小ラベルで人数を自動決定せず、未解決の問いと必要な独立確認に担当を対応させる。初期確認だけで分からなければ、まず探索の範囲を決め、その結果で設計前に体制を更新する。担当を起動するためだけの調査や計画書は増やさない。
+点数・行数・一律の大小ラベルで人数を自動決定せず、未解決の問いと必要な独立確認に担当を対応させる。初期確認だけで分からなければ、まず探索の範囲を決め、その結果で設計前に体制を更新する。担当を起動するためだけの調査や計画書は増やさない。追加は必要な役割だけにし、どれか一つを増やすために全役割を増やさない。
 
-| 役割 | 専任を置く判断と人数 | 専任を置かない場合 |
-| --- | --- | --- |
-| 探索 | メインの初期確認では根拠が足りない領域に配置。独立に調べられる領域なら分担 | 設計担当1、いなければ実装担当が計画・実装に必要な範囲を調べる |
-| 設計 | 責務・依存・方式の判断が必要なら配置。競合する案や重大な見落としを独立に比較する必要があれば複数 | 実装担当が短い技術計画と検証方針を作り、設計責任者を兼ねる |
-| 計画レビュー | 実装前に検証すべき設計リスクがあれば配置。異なる観点の独立確認が必要なら複数 | 計画を作った担当が要件カバーと実現可能性の根拠を計画に書き、独立コードレビューが計画自体も誤りうるものとして確かめる |
-| 計画／実装の簡素化 | 状態・抽象化・変更範囲の複雑さに専門の検討が必要なら配置。計画と実装で別々に判断 | 計画は設計責任者、実装は実装担当とコードレビュー担当が確認 |
-| 実装 | 1体。修正も同じ担当に戻す | 委託が許可されない、または起動できない場合もメインは代行しない。再開・交代し、できなければ未完了として必要な判断を求める（[工程](workflow.md)の§1・§2） |
-| 独立コードレビュー | 最低1体。重要な契約や複数領域の見落としを独立に確認する必要があれば追加 | 委託不可・起動不能なら独立レビュー未完了。自己レビューで代替完了にしない |
-| refine | 規約の量・領域の広さから別担当での照合が有効なら配置 | コードレビュー担当に規約全文と照合責務を渡す。サービス規約未取得なら未照合と明示 |
-| 指摘検証（verifier） | 指摘が多い、相互に矛盾する、根拠の確認が難しい場合に配置。計画と実装の各ラウンドで判断 | 設計担当1、いなければ実装担当が全指摘の根拠・出典・未確認事項を整理して採否を決める（採否は[工程](workflow.md)の「指摘の検証と統合」に従う） |
+LITEでは、探索を含む担当を追加しない。必要な調査・設計・簡素化・テスト・指摘の根拠の確認と修正は実装担当が、独立した確認は独立レビュー担当が担う。2名で足りないと分かったら、理由を添えて、人への確認の窓口からBASIC・ULTRAへの変更を相談する（変更の扱いは「体制の選択」のとおり）。
 
-専任を置かない責務はメインへ戻さず、成果物を作った担当から独立している必要があるかで既存の担当へ割り当てる。
+## 技術領域
 
-明確で局所的な変更なら、実装担当が短い計画を作り、実装1体・独立コードレビュー1体で進められる。設計が難しければ設計担当や計画レビューを追加し、設計案の独立比較が必要なら設計担当を複数にする。コードのリスクが高い場合はコードレビューを増やす。どれか一つを増やすために全役割を複数にしない。
+技術領域は、Web・API・iOSのように技術や実装慣習が違う領域とする。配布先・写し・文書の分類は、別の技術領域に数えない。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属するようにする。
 
-## 体制の記録と引き渡し
+## 記録と引き渡し
 
-起動前に、判断の根拠、工程ごとの役割・人数・確認範囲、専任なしの責任者、必須検証、設計と指摘の統合責任者を短く記録する。設計担当がいれば担当1が設計・統合を継続し、いなければ実装担当が設計責任者になる。独立レビュー担当は実装担当と別のコンテキストにする。
+設計を始める前に、選んだ体制、追加した担当とその根拠、工程ごとの役割・人数・確認範囲、技術領域ごとに担当を置く場合はその割り当て、必須検証を短く記録する。独立レビュー担当は実装担当と別のコンテキストにする。
 
-linear-executeから受けた作業では、メインが決めた初期体制と根拠を進行役へ報告する。通常の体制判断で人の承認を待たない。材料が欠けていれば既定の人数へ戻さず、初期確認して体制を決める。ローカル記録は `.shinaps/work/` 以下へ保存する。別セッションへは本文も渡し、相手から見えないパスだけに依存しない。
+linear-executeから受けた作業では、選んだ体制と追加した担当を進行役へ報告する。追加の判断では人の承認を待たない。材料が欠けていれば初期確認して、BASIC・ULTRAでは追加の担当を決める。ローカル記録は `.shinaps/work/` 以下へ保存する。別セッションへは本文も渡し、相手から見えないパスだけに依存しない。
 
 ## 途中の増員
 
-初期体制は上限ではない。設計上の新しい不確実性、影響領域の追加、重要な契約への影響、検証失敗、指摘の対立が判明した時点でdevのメインが必要な役割・人数・確認範囲を増やす。担当からの提案はメインが判断する。理由と体制の変更を記録し、linear-executeでは進行役へ報告する。初期判断や報告のために作業を止める必要はないが、追加担当の確認が必要な工程は結果が揃うまで完了にしない。
+BASIC・ULTRAでは、選んだ体制は上限ではない。LITEでは増やさず、上の相談に従う。設計上の新しい不確実性、影響領域の追加、重要な契約への影響、検証失敗、指摘の対立が判明した時点でdevのメインが必要な役割・人数・確認範囲を増やす。担当からの提案はメインが判断する。理由と体制の変更を記録し、linear-executeでは進行役へ報告する。判断や報告のために作業を止める必要はないが、追加担当の確認が必要な工程は結果が揃うまで完了にしない。
 
-- 新しい担当には現在の要件・同じ版の対象・規約・確定済み判断を渡す。独立確認を求める場合、他担当の今回の未確定結果は渡さない。
-- 設計担当を途中で置く場合は担当1を統合責任者として引き継ぎ、実装担当の旧計画も検討対象にする。既存担当の仕事を理由なく最初から繰り返さない。
+- 新しい担当には現在の要件・同じ版の対象・規約・確定済み判断を渡す。独立確認を求める場合、他担当の今回の未確定結果は渡さない。既存担当の仕事を理由なく最初から繰り返さない。
 - 増員で既存の未完了・不利な指摘を消さない。同じ対象への増員・交代でレビューラウンドの上限をリセットしない。枠不足は順番に起動し、人数を黙って減らさない。
 - 体制判断は委託・モデル変更・操作・予算の許可を作らない。既存の許可と予算内の増員は再承認不要。仕様・範囲・明示された人数制限・許可・予算を変える必要がある場合だけ、人へ理由と選択肢を一問で確認する。
 
-## 人数によらず維持する条件
+## 維持する条件
+
+選んだ体制の必須担当を、自己確認・体制の表に無い兼務・メインの代行で完了扱いにせず、委託不可・起動不能なら未完了とする。明示された人数制限・予算が下限を満たさない場合は、人へ一問で確認する。合意があれば、実施しない必須担当を未実施として記録・報告し、品質上の完了とは報告しない。合意が無ければ未完了とする。独立レビュー担当の確認を、実装担当の自己確認で代えない。
 
-要件と影響範囲の確認、必要なテストとプロジェクトの必須検証、実装者と独立したコードレビュー、適用規約の照合、全指摘の採否と根拠の記録を維持する。専任なしは責務の省略ではない。サービス規約を取得できない、担当が未完了、必須検証が失敗した場合はその状態を報告し、確認済みと偽らない。重大な未解決事項を完了にしない。linear-executeのLocal Agent QA、人レビュー、公開条件、終了地点は体制によって変えない。
+要件と影響範囲の確認、必要なテストとプロジェクトの必須検証、適用規約の照合、全指摘の採否と根拠の記録を維持する。サービス規約を取得できない、担当が未完了、必須検証が失敗した場合はその状態を報告し、確認済みと偽らない。重大な未解決事項を完了にしない。linear-executeのLocal Agent QA、人レビュー、公開条件、終了地点は体制によって変えない。