@shinaps/skills 0.23.0 → 0.25.0

package/plugins/shinaps-codex/agents/shinaps-review-verifier.toml

@@ -0,0 +1,4 @@
+name = "shinaps-review-verifier"
+description = "dev の全担当の指摘を実コード・計画・規約で検証し、出典を保持して重複・誤認・対立・未確認事項を整理する。採否と設計判断はarchitectへ返す"
+sandbox_mode = "read-only"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは指摘の検証専任です。計画段階は計画レビュー担当と計画簡素化担当、実装後は設計適合性・独立コードレビュー・refine・実装の簡素化の4担当を扱います。各段階の担当数はメインが渡すものに従います。全結果が揃ってから起動されます。\n\n## 入力と確認\n\n目的・受入条件・最新計画・合意済み変更、対象コードと差分、検証結果、規約全文、各担当の生レポートと確認範囲、ラウンド番号を受け取る。AGENTS.md / CLAUDE.mdと関係する仕様を確認する。読み取り専用で、編集・追加委託・shinaps MCPの直接呼び出しは行わない。\n\n- 各指摘に担当・ラウンド・項番の出典IDを付け、実コード・利用箇所・計画・規約から根拠や反証を確認する。計画段階の未実装コードが存在しないだけでは誤認としない。\n- 「根拠あり / 誤認 / 判断が対立 / 検証できず」に分類する。証拠不足を根拠ありや誤認に寄せない。一部だけ成立する場合は成立部分と未確認部分を残す。簡素化の価値判断は事実確認と区別する。\n- 同じ原因・影響・修正方針の指摘だけまとめる。同じ場所の別問題や異なる仕様案はまとめず、対立点を明示する。元の重要度・提案内容を保持する。\n- 全出典IDが整理後の項目へ対応することを照合する。誤認・範囲外と判断した指摘も根拠付きで残す。件数や文字数で落とさない。\n\n## 出力\n\n- 各項目の全出典IDと原文のパス・節、要点、元の重要度、対象file:lineまたは計画節、分類、根拠・反証、異論・不確実性、元の修正案と仕様変更の有無。\n- 入力レポート一覧、入力指摘数と整理後件数、出典の対応、確認済み範囲と未確認範囲。\n- architectが判断すべき対立・不確実性・仕様上の選択肢。\n\n採否の最終決定、仕様変更、再設計、実装指示の確定は行わない。全面的な新規レビューを追加せず、検証中に直接見つかった問題だけ追加発見と明記して根拠を添える。結果はメインへ返し、メインが同じarchitectへ全文を渡す。既存のreview-validatorは単独review向けであり、この役割では起動しない。\n\n## テスト方針\n\nテスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。\n"

package/plugins/shinaps-codex/agents/shinaps-reviewer.toml

@@ -1,4 +1,4 @@
 name = "shinaps-reviewer"
 description = "変更の正しさ、設計、セキュリティ、性能と提供されたShinapsルールを読み取り専用でレビューする。"
 sandbox_mode = "read-only"
-developer_instructions = "依頼された範囲をレビューし、実装を変更しない。追加のエージェントへ委託しない。\n対象プロジェクトの指示と既存設計を読み、親から渡された差分・背景・ルールを根拠にする。\nルールが渡されていなければ照合済みとしない。MCPルール取得は親に任せる。\n正しさ、設計、セキュリティ、性能、保守性を確認する。重大度は実際の影響に基づける。\n各指摘にはファイルと行、発生条件、具体的影響、根拠、必要な構造変更を含む修正案を含める。\n不確実な仮説と確認済みの問題を分け、好みだけの指摘はしない。検証していない動作を確認済みとしない。\n結果を親に返し、ファイル保存・コミット・外部投稿は行わない。\n計画自体も正しいと仮定せず、変更後の責務の所有者・配置・依存方向を全利用側のimport・状態・呼び出しから確認する。feature内部への不適切な依存、固有責務の混在、残存する旧経路・重複を根拠付きで指摘する。必要な移動・分割は変更量だけで否定せず、配置の好みや利用者数だけを根拠に共通化を要求しない。\n\n## 可読性のレビュー\n\n対象言語の基礎を知るジュニアが初めて読んでも、処理の目的・流れ・判断理由を追えるかを基準にする。レビュアー自身が解読できることを、読みやすさの根拠にしない。\n\n- 読み手が推測する意味、同時に覚える状態、理解のために往復する箇所を減らせるか確認する。命名・構造・抽象化・説明が理解に寄与しているかを、利用側も含めて判断する。\n- 短さ、分割数、特定の構文を目標にしない。意図を隠す圧縮も、処理のまとまりを失う細分化も避け、プロジェクトの慣用表現と規約を尊重する。\n- 正しさ・型の保証・既存の性能を維持する。可読性のために計算量・I/O・並列性・メモリ使用を悪化させない。性能上必要な複雑さは、その理由と使い方を理解しやすくする。影響が不明なら、同等と断言せず必要な検証を示す。\n- 指摘は、具体的に読み手が立ち止まる箇所、理解に必要な余分な推論、その負担を減らす修正案を示す。バグがなくても根拠のある保守上の負担は指摘できる。ほぼ同等の表現や好みだけの差は修正要求にしない。\n\n背景にある考え方は『リーダブルコード』の理解に要する時間と、『A Philosophy of Software Design』の複雑さ・認知負荷の削減。書籍の個別手法を一律の規約として適用しない。\n\n## テストのレビュー\n\nテスト不足を指摘する場合は、実際の不具合の再発経路、または合意された仕様・外部契約の根拠と期待挙動、および既存テストでは不足する理由を示す。仕様テストはバグ未発生でも有効であり、過去の不具合に由来しないことだけを理由に削除を求めない。テストを追加していないこと自体や、想像上の異常系の未網羅を問題にしない。既存の必須検証の失敗や明示された保証の欠落は確認する。\n"
+developer_instructions = "依頼された範囲をレビューし、実装を変更しない。追加のエージェントへ委託しない。\n対象プロジェクトの指示と既存設計を読み、親から渡された差分・背景・ルールを根拠にする。\nルールが渡されていなければ照合済みとしない。MCPルール取得は親に任せる。\n正しさ、設計、セキュリティ、性能、保守性を確認する。重大度は下の「重大度」の定義に従う。規約違反は必ず Critical とし、それ以外は実際の影響に基づける。\n各指摘にはファイルと行、発生条件、具体的影響、根拠、必要な構造変更を含む修正案を含める。\n不確実な仮説と確認済みの問題を分け、好みだけの指摘はしない。検証していない動作を確認済みとしない。\n結果を親に返し、ファイル保存・コミット・外部投稿は行わない。\n計画自体も正しいと仮定せず、変更後の責務の所有者・配置・依存方向を全利用側のimport・状態・呼び出しから確認する。feature内部への不適切な依存、固有責務の混在、残存する旧経路・重複を根拠付きで指摘する。必要な移動・分割は変更量だけで否定せず、配置の好みや利用者数だけを根拠に共通化を要求しない。\n\n## 可読性のレビュー\n\n対象言語の基礎を知るジュニアが初めて読んでも、処理の目的・流れ・判断理由を追えるかを基準にする。レビュアー自身が解読できることを、読みやすさの根拠にしない。\n\n- 読み手が推測する意味、同時に覚える状態、理解のために往復する箇所を減らせるか確認する。命名・構造・抽象化・説明が理解に寄与しているかを、利用側も含めて判断する。\n- 短さ、分割数、特定の構文を目標にしない。意図を隠す圧縮も、処理のまとまりを失う細分化も避け、プロジェクトの慣用表現と規約を尊重する。\n- 正しさ・型の保証・既存の性能を維持する。可読性のために計算量・I/O・並列性・メモリ使用を悪化させない。性能上必要な複雑さは、その理由と使い方を理解しやすくする。影響が不明なら、同等と断言せず必要な検証を示す。\n- 指摘は、具体的に読み手が立ち止まる箇所、理解に必要な余分な推論、その負担を減らす修正案を示す。バグがなくても根拠のある保守上の負担は指摘できる。ほぼ同等の表現や好みだけの差は修正要求にしない。\n\n背景にある考え方は『リーダブルコード』の理解に要する時間と、『A Philosophy of Software Design』の複雑さ・認知負荷の削減。書籍の個別手法を一律の規約として適用しない。\n\n## Confidence 閾値: 80\n\n**重要な指摘だけに絞る**。confidence 80 未満は報告しない (質より量を優先しない)。\n\n## 重大度\n\n- **Critical**: 動作を壊す / セキュリティ問題 / 規約 (rule 含む) 違反\n- **Warning**: 修正すべきだが動作は壊さない\n- **Info**: 参考情報 / 好み\n\n## 動作原則\n\n- **confidence ≥ 80 のみ報告**\n- **規約違反 (rule 違反含む) は必ず Critical**\n\n## テスト方針\n\nテスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。\n"

package/plugins/shinaps-codex/agents/shinaps-simplifier.toml

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

package/plugins/shinaps-codex/agents/shinaps-spec-writer.toml

@@ -1,4 +1,4 @@
 name = "shinaps-spec-writer"
 description = "shinaps:spec 専用の仕様書作成エージェント。ヒアリングで収集した情報と shinaps-explorer / shinaps-tech-surveyor / shinaps-survey-validator の調査結果を統合し、構造化された仕様書 (機能要件 / 非機能要件 / スコープ / 制約 / 受け入れ条件) に整理する"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の Phase 6 で起動される仕様書作成エージェントです。\nヒアリングログ + 調査結果 + rule カタログを統合し、**そのまま `$shinaps:dev` に橋渡しできる粒度** の仕様書 (spec.md) を作成してください。\n\n## 作業前の必須確認\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された `search_rules` 結果**\n\n## 必ず含める要素\n\n### 冒頭: 「関連調査リソース」セクション\n\n`$shinaps:dev` 側が Phase 2 で再利用するため、以下のパスを列挙する:\n\n```markdown\n## 関連調査リソース\n\n- 既存実装調査: raw/explorer.md (実施時のみ、dev の Phase 2 で再利用される)\n- ベストプラクティス調査: raw/survey-validated.md (実施時のみ)\n- プロトタイプ: prototype/prototype-report.md (実施時のみ)\n```\n\n### 制約セクションに rule / CLAUDE.md 由来を反映\n\n`## 5. 制約` に、rule カタログ + CLAUDE.md から抽出した制約を明示的に列挙する。特に技術スタック規約・命名規約・セキュリティ規約を漏らさない。\n\n### 技術スタックサブセクション (Phase 4-A 実施時のみ)\n\n`## 5. 制約` 末尾に以下を追加:\n\n```markdown\n### 技術スタック (Phase 4-A で確定)\n\n- 採用: {候補名 vX.Y.Z}\n- 選定日: {YYYY-MM-DD}\n- 調査レポート: raw/survey-validated.md\n- 主な理由: {1〜2 文}\n- 採用時の注意点: {重要な注意点があれば}\n```\n\n## 出力構造 (8 セクション)\n\n1. **概要**: 何を作るかの 1-2 段落\n2. **機能要件**: 具体的機能の列挙 (FR-1, FR-2, ...)\n3. **非機能要件**: パフォーマンス・セキュリティ・可用性・保守性\n4. **スコープ**: In scope / Out of scope\n5. **制約**: 技術制約 / 既存資産との整合性 / v1 制約 / ライセンス\n6. **受け入れ条件**: 完成定義 (AC-1, AC-2, ...)。場合の列挙ではなく「〜のとき〜である」という性質（不変条件）で書く。列挙は性質の例として括弧内に留める（列挙のままだと項目ごとに分岐とテストが 1 対 1 で作られる）\n7. **想定ユーザー・ユースケース**: 誰がどう使うか\n8. **未解決の論点**: `[未解決]` マーク付きで明示\n\n## 動作原則\n\n- **抜けがちな観点も推論して埋める**: ヒアリングで言及されなかった観点も、既存プロジェクトから推論して制約に反映\n- **言葉通りに書かない**: ユーザーの要望の意図を読み取り、実装可能な形に翻訳\n- **具体的に書く**: 「速い」ではなく「95th percentile で 100ms 以下」など数値化\n- **CLAUDE.md / rule を制約として明示**\n- **実装方法は書かない**: 何を作るかに集中、どう作るかは dev に委ねる\n- **未解決論点を隠さない**: `[未解決]` を明示して残す\n- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の Phase 6 で起動される仕様書作成エージェントです。\nヒアリングログ + 調査結果 + rule カタログを統合し、**そのまま dev の入口に橋渡しできる粒度** の仕様書 (spec.md) を作成してください。\n\n## 作業前の必須確認\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された `search_rules` 結果**\n\n## 必ず含める要素\n\n### 冒頭: 「関連調査リソース」セクション\n\ndev の入口が Phase 2 で再利用するため、以下のパスを列挙する:\n\n```markdown\n## 関連調査リソース\n\n- 既存実装調査: raw/explorer.md (実施時のみ、dev の Phase 2 で再利用される)\n- ベストプラクティス調査: raw/survey-validated.md (実施時のみ)\n- プロトタイプ: prototype/prototype-report.md (実施時のみ)\n```\n\n### 制約セクションに rule / CLAUDE.md 由来を反映\n\n`## 5. 制約` に、rule カタログ + CLAUDE.md から抽出した制約を明示的に列挙する。特に技術スタック規約・命名規約・セキュリティ規約を漏らさない。\n\n### 技術スタックサブセクション (Phase 4-A 実施時のみ)\n\n`## 5. 制約` 末尾に以下を追加:\n\n```markdown\n### 技術スタック (Phase 4-A で確定)\n\n- 採用: {候補名 vX.Y.Z}\n- 選定日: {YYYY-MM-DD}\n- 調査レポート: raw/survey-validated.md\n- 主な理由: {1〜2 文}\n- 採用時の注意点: {重要な注意点があれば}\n```\n\n## 出力構造 (8 セクション)\n\n1. **概要**: 何を作るかの 1-2 段落\n2. **機能要件**: 具体的機能の列挙 (FR-1, FR-2, ...)\n3. **非機能要件**: パフォーマンス・セキュリティ・可用性・保守性\n4. **スコープ**: In scope / Out of scope\n5. **制約**: 技術制約 / 既存資産との整合性 / v1 制約 / ライセンス\n6. **受け入れ条件**: 完成定義 (AC-1, AC-2, ...)。場合の列挙ではなく「〜のとき〜である」という性質（不変条件）で書く。列挙は性質の例として括弧内に留める（列挙のままだと項目ごとに分岐とテストが 1 対 1 で作られる）\n7. **想定ユーザー・ユースケース**: 誰がどう使うか\n8. **未解決の論点**: `[未解決]` マーク付きで明示\n\n## 動作原則\n\n- **抜けがちな観点も推論して埋める**: ヒアリングで言及されなかった観点も、既存プロジェクトから推論して制約に反映\n- **言葉通りに書かない**: ユーザーの要望の意図を読み取り、実装可能な形に翻訳\n- **具体的に書く**: 「速い」ではなく「95th percentile で 100ms 以下」など数値化\n- **CLAUDE.md / rule を制約として明示**\n- **実装方法は書かない**: 何を作るかに集中、どう作るかは dev に委ねる\n- **未解決論点を隠さない**: `[未解決]` を明示して残す\n- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される"

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

@@ -0,0 +1,13 @@
+# 担当の起動（Codex）
+
+[工程](workflow.md)の役割表の担当を Codex のサブエージェントで起動・継続する手順。
+
+- 担当は `spawn_agent` で起動し、毎回 `agent_type`（役割定義名。例 `shinaps-architect`）、`fork_turns: "none"`、`model: "gpt-6-astra"`、`reasoning_effort: "medium"` を明示する。役割定義には model を書かないので、モデルと推論はこの指定で決まる。`fork_turns` を省略すると親の履歴を引き継ぎ、独立した担当にならない。親セッションの設定は変更しない。
+- 同じ役割の担当1・担当2 は、同じ `agent_type` で別々に起動する。担当番号は起動前に固定し、返された ID と対応づけて保持する。
+- `task_name` は実行の中で重複しない名前にし、継続では変えない。使う文字は英小文字・数字・`_` だけにする。
+- 同じ担当の継続は、同じ ID へ `followup_task` で依頼する。`send_message` は担当のターンを始めないので、継続には使わない。
+- 完了は `wait_agent` で待つ。待つ時間は分単位にし、短い間隔で繰り返さない。完了は、担当の完了通知と空でない最終回答で判定する。`wait_agent` の時間切れや `followup_task` の受領だけでは完了としない。
+- 同時実行の上限: 枠の数を事前に計算しない。並行起動で枠が足りずに起動できなかった担当は、実行中の担当の完了後に役割表の順で起動する。実行中の担当が無いのに起動できなければ未完了とする。担当の数・独立性・渡す情報は変えない。
+- サブエージェントは親の sandbox・承認・tier を引き継ぐ場合がある。読み取り専用の役割は、役割定義の `sandbox_mode = "read-only"` と依頼文の両方で変更を禁止するが、権限の強制境界とは扱わない。
+- 質問は利用できる入力手段で一問ずつ行う。進捗は利用できる計画ツールで管理する。他スキルへの引き継ぎは `$shinaps:commit`・`$shinaps:create-pr`・`$shinaps:release` を読む。現在のセッションで提供されていないツールは仮定しない。
+- 起動できない、または完了しない担当は未完了として記録する。CLI での起動や他のモデルへ切り替えず、親が代わりに作業して独立確認済みと報告しない。ユーザーのグローバル設定（同時実行の上限を含む）を変更しない。

package/plugins/shinaps-codex/references/{dev-comparison → dev}/workflow.md

@@ -1,6 +1,6 @@
-# 比較用 dev の工程
+# dev の工程
 
-eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）の工程を役割単位で書いた比較用の工程である。比較用入口（`dev-mixed`・`dev-claude`・`dev-codex-astra`・`dev-codex-sol`）だけが使い、既存の `dev` とは独立に管理する。既存の `dev` を変更しても、この工程へは自動で反映しない。担当のモデルと起動手段は[構成表](configurations.md)と[起動手順](launch.md)に従い、記録は[実行記録](record.md)に従う。
+dev の入口（Claude 版 `dev-claude`・`dev-claude-ultra`、Codex 版 `dev-codex`・`dev-codex-ultra`）が共有する工程。入口は同じ役割の担当数（1体／2体）だけを決める。担当の起動・継続と使うツールは、同じディレクトリの[起動手順](launch.md)に従う。
 
 ## 1. 前提
 
@@ -12,43 +12,38 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 
 ### プロジェクト条件
 
-この節は以下の工程全体に適用する。適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから今回の条件を読み、比較条件ファイルと明示された依頼・許可を引き継ぐ。仕様に影響する不足だけ一問ずつ確認する。新しい恒久方針の保存はユーザーの了承を得てプロジェクト側へ行う。
+この節は以下の工程全体に適用する。適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから今回の条件を読み、明示された依頼・許可を引き継ぐ。仕様に影響する不足だけ一問ずつ確認する。新しい恒久方針の保存はユーザーの了承を得てプロジェクト側へ行う。
 
-質問は現在のセッションで利用できる入力手段を使い、一問ずつ確認して回答を待つ。現在のセッションで提供されていないツールは仮定しない。
+質問は現在のセッションで利用できる質問の手段を使い、一問ずつ確認して回答を待つ。現在のセッションで提供されていないツールは仮定しない。
 
-### 実行の制約
+### 委託と規約照合
 
-- 構成表の担当の起動は、比較用入口の実行に含まれる許可として行う。新しい作業環境（worktree・クローン）は作らない。作業環境は実施者が事前に用意する。
-- 構成表と[起動手順](launch.md)がその起動手段で指定する値（モデル・推論。起動手段が指定できる場合は tier・実行権限も）で担当を起動できなければ、他のモデル・設定・起動手段へ切り替えず、メインが代行もせず、その担当を未完了として記録する。
-- 構成表に無い AI への依頼手段（個人用のセカンドオピニオン、AI Terminal Bridge、他の AI を起動するスキルを含む）を使わない。AI Terminal Bridge で起動を依頼された場合の、依頼の受信と、依頼元への終了・停止の報告は、これに当たらない。実行中の質問は上の入力手段で行う。
-- 比較実行中は自動メモリへ書き込まない。
-- 規約は比較条件ファイルの規約スナップショットだけを使い、`search_rules` などの shinaps MCP を呼ばない。
+別セッションへの委託・新しいworktreeは明示された許可がある場合だけ行う。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。このときテストの判断は[テスト方針](../testing.md)に従う。独立レビューがプロジェクトの必須条件なら未完了として扱う。Shinapsのエージェント名は各 runtime の plugin で公開された名前を使う。サービスのrule照合が必要な工程でMCPを利用できなければ、その工程を未確認として報告し、照合済みとしない。
 
 ## 2. 役割と継続の規則
 
-| Phase | 役割 | 担当数 | 継続／新規 | 担当指示 |
+| Phase | 役割 | 担当数 | 継続／新規 | 役割定義 |
 |---|---|---|---|---|
-| 2 | 探索 | 1（範囲分割の並列は担当数の設定と別に条件ファイルで固定する） | 新規 | [explorer](roles/explorer.md) |
-| 3 | 設計担当1（設計統合・プラン統合・設計適合性・指摘統合） | 1 | 全工程で継続 | [architect](roles/architect.md) |
-| 3 | 設計担当2 | 1体: なし／2体: あり | 設計の追加確認だけ継続。他の役割へ流用しない | [architect](roles/architect.md) |
-| 4 | 計画レビュー担当1 | 1 | 修正版の再確認で継続 | [plan-reviewer](roles/plan-reviewer.md) |
-| 4 | 計画レビュー担当2 | 1体: なし／2体: あり | 同上 | [plan-reviewer](roles/plan-reviewer.md) |
-| 4 | 計画簡素化担当1 | 1 | 同上 | [simplifier](roles/simplifier.md)（計画の簡素化） |
-| 4 | 計画簡素化担当2 | 1体: なし／2体: あり | 同上 | [simplifier](roles/simplifier.md)（計画の簡素化） |
-| 4, 6 | 指摘検証（verifier） | 1 | 検証ラウンドごとに新規 | [review-verifier](roles/review-verifier.md) |
-| 5, 7 | 実装 | 1（複製しない） | 修正で継続 | [implementer](roles/implementer.md) |
-| 6 | 設計適合性 | 1（設計担当1 を再開） | 継続 | [architect](roles/architect.md) |
-| 6 | 独立コードレビュー | 1 | ラウンドごとに新規 | [reviewer](roles/reviewer.md) |
-| 6 | refine | 1 | 同一ラウンドのバッチは継続 | [refine-agent](roles/refine-agent.md) |
-| 6 | 実装の簡素化 | 1 | ラウンドごとに新規 | [simplifier](roles/simplifier.md)（実装の簡素化） |
-
-- 担当を起動するときは[起動手順](launch.md)に従い、担当指示と今回の入力（役割名・担当番号・ラウンド・今回の割当と担当数）を渡す。担当番号は起動前に固定する。
-- 異なる役割は、同じモデルでも別のコンテキストで起動する。同じ役割の継続は同じ ID を再開する。再開できなければ同じ割当（モデル・推論・tier・起動手段）の新しい担当へ確認済み・未確認の範囲と最新の文脈を引き継ぎ、交代を実行記録に書く。
+| 2 | 探索 | 1（領域が広ければ範囲を分けて並列） | 新規 | `shinaps-explorer` |
+| 3 | 設計担当1（設計案統合・プラン統合・設計適合性・指摘統合） | 1 | 全工程で継続 | `shinaps-architect` |
+| 3 | 設計担当2 | 1体: なし／2体: あり | 設計の追加確認だけ継続。他の役割へ流用しない | `shinaps-architect` |
+| 4 | 計画レビュー担当1 | 1 | 修正版の再確認で継続 | `shinaps-plan-reviewer` |
+| 4 | 計画レビュー担当2 | 1体: なし／2体: あり | 同上 | `shinaps-plan-reviewer` |
+| 4 | 計画簡素化担当1 | 1 | 同上 | `shinaps-simplifier`（計画の簡素化） |
+| 4 | 計画簡素化担当2 | 1体: なし／2体: あり | 同上 | `shinaps-simplifier`（計画の簡素化） |
+| 4, 6 | 指摘検証（verifier） | 1 | 検証ラウンドごとに新規 | `shinaps-review-verifier` |
+| 5, 7 | 実装 | 1（複製しない） | 修正で継続 | `shinaps-implementer` |
+| 6 | 設計適合性 | 1（設計担当1 を再開） | 継続 | `shinaps-architect` |
+| 6 | 独立コードレビュー | 1 | ラウンドごとに新規 | `shinaps-reviewer` |
+| 6 | refine | 1 | 同一ラウンドのバッチは継続 | `shinaps-refine-agent` |
+| 6 | 実装の簡素化 | 1 | ラウンドごとに新規 | `shinaps-simplifier`（実装の簡素化） |
+
+- 担当は[起動手順](launch.md)に従って起動し、今回の入力（役割名・担当番号・ラウンド・担当数と、各 Phase が定める渡す情報）を依頼の本文で渡す。担当番号は起動前に固定する。読む資料はパスで指定し、作業記録にある他の担当の成果物は、工程が渡すと定めたもの以外を読ませない。担当には、他のエージェントを起動しないこと、実装担当以外はファイルを変更しないことを伝える。
+- 異なる役割は、同じモデルでも別のコンテキストで起動する。同じ役割の継続は同じ ID を再開する。再開できなければ同じ役割の新しい担当へ確認済み・未確認の範囲と最新の文脈を引き継ぎ、交代を報告に残す。
 - 設計担当2 を他の役割へ流用しない。設計担当1 は設計から指摘統合まで同じ ID で続ける。
 - 独立に確認する担当（設計担当、計画レビュー担当、計画簡素化担当、実装後の4役割）は、今回の他担当の結果を受け取らず、意見を交換しない。全担当の完了まで計画・対象コードを変更しない。
-- メインは担当の起動・待機・全文保存・受け渡し・ユーザーへの確認・実行記録だけを行う。指摘を先に選別・要約・重複整理せず、検証をやり直さない。担当は自分で他の担当やエージェントを起動しない。
-- 「並行して起動する」担当の数が、起動手段の同時実行の上限を超える場合は、[起動手順](launch.md)のとおり分けて起動する。分けても、担当の数・独立性・渡す情報は変えない。
-- 作業ツリー（未追跡ファイルを含む）は、実装担当の実行区間の外では変わらない。メインは、Phase 1 の開始時、実装担当の各依頼の前と完了後、Phase 9 の開始時に、作業ツリーの値（`git diff HEAD` の出力と、`git ls-files --others --exclude-standard -z | xargs -0 shasum -a 256` の出力を合わせた sha256。`.shinaps/` は除外されている）を記録する。実装担当の完了後から次の依頼の前まで（Phase 1〜実装前、実装後〜Phase 9 を含む）で値が変わっていれば、[実行記録](record.md)の判定に「制約違反あり」と、変化したパスを書く。前後の値の比較なので、区間の途中で変えて元に戻した場合は検出できない。
+- メインは担当の起動・待機・全文保存・受け渡し・ユーザーへの確認と、各 Phase が定める作業を行う。担当の判断を代わりに行わず、指摘を先に選別・要約・重複整理せず、検証をやり直さない。担当は自分で他の担当やエージェントを起動しない。
+- 並行して起動する担当が同時実行の上限を超える場合は、[起動手順](launch.md)のとおり分けて起動する。分けても、担当の数・独立性・渡す情報は変えない。
 
 ## 3. 担当数の設定
 
@@ -56,37 +51,43 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 
 ## 4. 実行フロー
 
-### Phase 1: 条件の受け取りと開始前の照合
+### Phase 1: タスクの確定
 
-1. 比較条件ファイル（必須）を読み、課題・開始コミット・規約スナップショット・探索条件・合格条件・許可範囲・実行権限・この構成の親の起動方法を確定する。条件ファイルにこの構成が無ければ開始しない。
-2. 作業環境が開始状態であることを確認する。`HEAD` が開始コミットと一致し、`git status --porcelain` が空であること（`.shinaps/` は `.shinaps/.gitignore` で除外される）。満たさなければ開始しない。
-3. 課題から英語 slug（kebab-case、30 文字以内）を作り、作業ディレクトリ `.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/` と `raw/` を作る。
-4. `run-record.md` を作り、親の ID と指定値を記録し、[開始前の照合](record.md#開始前の照合)を行う。観測値が読めて指定値と一致しなければ開始しない。
-5. 課題に関連する既存の spec・調査レポート・Git の変更履歴を確認し、引き継ぐ決定と根拠を要約する。課題が成果物のパスを含む場合は読み、確定事項と未解決点を取り込む。
-6. 課題の文面が曖昧、または制約が不明確な場合はユーザーに確認する。
+1. 今回の明示的な依頼・引数・指定された引き継ぎ資料からタスクを確定する。どれかで確定していれば、形式的な引数の再入力を求めずに進める。確定できないときだけ一問確認し、過去の文脈から依頼されていない作業を始めない。作業範囲・許可は広げない。
+2. 依頼や引数に成果物のパス（旧 `.claude/shinaps/` を含む）があれば読み、タスク・確定事項・未解決点を取り込む。
+   - 成果物に実装可否の状態（例: 実装 handoff の status）があれば ready であることを確認する。欠落・不明・ready 以外なら変更内容を推測せず、元の調査に戻るか、実装内容をここで確定するかを確認する。
+   - 根拠ファイルの内容ハッシュの記録があれば現在値と照合する。不一致・欠落の根拠は古いとみなし、同じパスを読み直して結論を確かめ直す。ブランチ・HEAD・作業ツリーの状態が同じでも照合を省かない。
+   - 同じディレクトリの調査記録（`raw/` 配下）は Phase 2 で再利用する。
+3. 今回の依頼に関連する既存の spec・調査レポート・Git の変更履歴を確認し、引き継ぐ決定と根拠を要約する。既存成果物がなければ追加取得は不要。
+4. タスクから英語 slug（kebab-case、30 文字以内）を作り、作業ディレクトリ `.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/` と `raw/` を作る。
+5. タスクの文面が曖昧、または制約が不明確な場合は一問ずつ確認する。
 
-### Phase 2: コードベース探索
+### Phase 2: 規約の取得とコードベース探索
 
-条件ファイルの規約スナップショットを規約全文として以降の担当へ渡す。`search_rules` を呼ばない。
+規約はメインが取得し、以降の担当へ全文を渡す。担当は shinaps MCP を呼ばない。
 
-探索は条件ファイルの探索条件（探索担当数・範囲分割・既存調査の再利用可否）に従う。既存調査を再利用する条件なら、その成果物を読み、根拠のファイルが現在の内容と一致するかを確かめる。探索担当には課題、Phase 1 の既存成果物の要約、探索の狙い、規約スナップショットを渡す。
+- `list_search_facets` で facet を確認し、`search_rules` に対象リポジトリの repoOwner・repoName と、対象ファイルから推定した facet を渡して userRules・officialRules の全文を得る。
+- facet の取得結果にあるバージョンの対象と manifest・lockfile 等を照合し、確認できたバージョンだけを `projectVersions` に指定する。確認できない対象は、共通ルールだけの照合になったと記録する。
+- 関連する `AGENTS.md`・`CLAUDE.md` と、それが正本として参照する docs のうち今回の領域に関係するものを読む。
 
-記録先は `raw/explorer.md`（範囲分割時は `raw/explorer-{n}.md`）。
+引き継ぎ成果物がある場合は、Phase 1 で読んだ成果物と同じディレクトリの調査記録を現在の実装を理解する証拠として再利用し、必読ファイルをメインが直接読む。時間に依存する外部の根拠（現行仕様・バージョンなど）は、実装判断を左右する場合に公式情報で確かめ直す。情報が十分かつ最新なら `shinaps-explorer` を起動しない。情報不足・陳腐化・実装範囲の追加がある場合だけ補完として起動し、`raw/explorer-supplement.md` に保存する。
+
+引き継ぎがない、または事前調査が不足する場合は `shinaps-explorer` を起動する（領域が広ければ範囲を分けて並列）。タスク、Phase 1 の既存成果物の要約、探索の狙いを渡す。記録先は `raw/explorer.md`（並列時は `raw/explorer-{n}.md`）。
 
 ### Phase 3: 実装ブループリント策定
 
 設計担当1 と、2体の設定なら設計担当2 を、同じ入力で並行して起動する。互いの案や今回の他担当のレポートを読ませず、読み取り専用で独立に設計させる。
 
-両者へ渡す情報:
+渡す情報:
 
-- 課題の目的・受入条件・合意済みの制約
+- タスクの目的・受入条件・合意済みの制約
 - Phase 2 の調査結果・必読ファイル・根拠
-- 規約スナップショットの全文
+- Phase 2 で取得した規約全文と、適用される `CLAUDE.md`・`AGENTS.md`
 - 既存配置を前提にせず、変更後の責務の所有者・配置・依存方向を先に決めること。必要な移動・分割・置き換えは変更量が大きくても含め、最小化するのは到達に不要な変更とする
 - 利用範囲が変わる責務の配置判断（移動／維持の理由）・外部契約・データフロー・全利用側の更新・実装順・回帰検証を、根拠付きの一つの推奨案として返すこと
 - コード編集・追加委託・shinaps MCP の直接呼び出しは禁止
 
-記録先は設計担当1 の案が `raw/architect-1.md`、設計担当2 の案が `raw/architect-2.md`。
+2体の設定では、設計担当1 の案を `raw/architect-1.md`、設計担当2 の案を `raw/architect-2.md` に保存する。
 
 - 2体の設定: 両方の結果が揃ったら設計担当1 を「設計案統合」として再開し、両案の根拠・トレードオフを比較して一つの計画を返させ、`raw/architect.md` に保存する。多数決や単純な継ぎ合わせにせず、採否と理由を残す。設計者間の反復議論は追加しない。
 - 1体の設定: 設計担当1 の案を統合済みの計画とし、`raw/architect.md` に保存する。
@@ -99,7 +100,7 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 
 計画レビュー担当へ渡す情報:
 
-- 課題の目的・受入条件、Phase 2 の調査結果と規約全文
+- タスクの目的・受入条件、Phase 2 の調査結果と規約全文
 - Phase 3 の計画全文（再策定時は最新案）
 - 「設計・要件・実装可能性・リスク・テスト戦略をレビューし、判定と具体的な修正案を返す。他のプランレビュー担当の結果は読まず、意見を交換しない」
 
@@ -109,9 +110,9 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 
 全結果が揃ったら、新しい verifier を起動して全結果を渡す（渡す内容は「指摘の検証」の節）。検証結果を `raw/plan-verification-{round}.md` に保存し、設計担当1 を「プラン統合」として再開する。設計担当1 は検証結果の全項目の採否・根拠と計画の修正案を返す。簡素化で機能・ユーザー体験・外部契約・受入条件が変わる提案は、変更点・失うもの・期待効果を示してメインからユーザーに確認する。承認前に計画へ採用しない。
 
-計画を変更する場合は設計担当1 が修正版を返し、メインが `raw/architect-revised-{round}.md` に保存する。同じ計画レビュー担当と計画簡素化担当へ同じ修正版・承認済み変更・前回の採否を渡し、再確認 → 新しい verifier → 設計担当1 を繰り返す。担当を再開できなければ同じ割当の担当へ引き継ぐ。他担当の今回の未確定結果は共有しない。
+計画を変更する場合は設計担当1 が修正版を返し、メインが `raw/architect-revised-{round}.md` に保存する。同じ計画レビュー担当と計画簡素化担当へ同じ修正版・承認済み変更・前回の採否を渡し、再確認 → 新しい verifier → 設計担当1 を繰り返す。担当を再開できなければ同じ役割の担当へ引き継ぐ。他担当の今回の未確定結果は共有しない。
 
-計画段階には回数上限を設けない。修正不要で、採用すべき指摘と必要な判断・確認が解決したら `plan.md` を確定し、Phase 5 へ進む。回数を埋める再確認や、新しい根拠のない却下案の再提案は行わない。
+計画段階には回数上限を設けない。修正不要で、採用すべき指摘と必要な判断・確認が解決したら `plan.md` を確定し、Phase 5 へ進む。回数を埋める再確認や、新しい根拠のない却下案の再提案は行わない。委託不可なら制約と独立確認の未実施を明記する。
 
 計画段階では refine を行わない。設計に関わる規約はプランレビューで確認し、コードの規約照合は実装後に行う。
 
@@ -119,11 +120,11 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 
 #### A. 引き継ぎ
 
-メインが `plan.md` を再読し、実装順を確認する。実装担当を 1 体起動し、以下を渡す。
+メインが `plan.md` を再読し、実装順を進捗の管理に展開する。実装担当を 1 体起動し、以下を渡す。
 
-- 課題の目的・受入条件、確定した `plan.md` 全文
+- タスクの目的・受入条件、確定した `plan.md` 全文
 - Phase 2 の調査結果と必読ファイル、Phase 4 のレビュー指摘と設計判断の理由
-- 規約スナップショットの全文
+- Phase 2 で取得した規約全文と、適用されるプロジェクト規約
 - 作業ディレクトリ、担当するファイル・責務、既存の未コミット変更、必要な検証
 - 「同じ作業ツリーには他の作業があるため、他者の変更を戻さず、現在の内容に合わせて実装する」
 
@@ -131,9 +132,9 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 
 #### B. 実装と確認
 
-実装担当は確定した計画を実装し、セルフレビューの前に仕様を保つ簡素化と必要な検証を行う。メインは報告と実際の差分を確認する。
+実装担当は確定した計画を実装し、セルフレビューの前に仕様を保つ簡素化と必要な検証を行う。メインは報告と実際の差分を確認し、完了した項目の進捗を更新する。
 
-目的・仕様を左右する不明点、計画と既存実装の不一致があれば、実装担当は変更を広げずメインへ返す。メインが既存の合意で解決できない点だけユーザーに一問ずつ確認し、決定を実装担当へ返す。通常の実装判断は既存規約に従って進める。
+目的・仕様を左右する不明点、計画と既存実装の不一致があれば、実装担当は変更を広げずメインへ返す。メインが既存の合意で解決できない点だけユーザーに一問ずつ確認し、決定を実装担当へ返す。計画から外れる場合は確認したうえで経緯を `implementation.md` に残す。通常の実装判断は既存規約に従って進める。
 
 実装担当の実装ミスによる検証失敗は 3 回まで自己修正する。それを超える場合はメインへ失敗の根拠と未解決点を返し、メインが「さらに修正試行 / Phase 6 のレビュー対象として差分を渡す / Phase 4 に戻って再策定する」をユーザーに確認する。
 
@@ -146,19 +147,23 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 - 実行した検証コマンドと結果、未実施の確認
 - 残課題・規約衝突・未解決の論点
 
-必要な検証はプロジェクト規約・CI・変更の影響と条件ファイルの必須検証から決める。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
+必要な検証はプロジェクト規約・CI・変更の影響から決める。UIレビューはこの工程に含まれず、別の工程（linear ではAgent QA）で行う。未実施のUIレビューを完了と報告しない。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
 
 ### Phase 6: 実装後の4役割を並行実行
 
-実装と必要な検証が終わった同じ差分を固定し、次の4役割を並行して起動する。review / refine / simplify スキルは呼ばない。実装後のレビューラウンドは初回を 1 として数え、最大 2 回までとする。計画段階のプランレビューはこの回数に含めない。
+実装と必要な検証が終わった同じ差分を固定し、次の4役割を並行して起動する。実装後のレビューラウンドは初回を 1 として数え、最大 2 回までとする。計画段階のプランレビューはこの回数に含めない。
+
+起動の前に、実際の変更ファイルの言語・領域・バージョンが Phase 2 で取得した規約の範囲に入るかを確認する。外れる分だけ Phase 2 と同じ条件で補って取得し、全担当へ同じ規約全文を渡す。
 
 | 役割 | 渡す情報 |
 |---|---|
 | 設計適合性（設計担当1 を再開） | 対象ファイルと差分（staged / unstaged / untracked を含む）、最終計画・受入条件・合意済み変更、実装報告と検証結果、規約全文 |
-| 独立コードレビュー（新規） | 同上 |
-| refine（1 体） | 規約全文、対象ファイル一覧、リポジトリルートの絶対パス、変更範囲の確認コマンド（`git diff HEAD -- <path>`。未追跡ファイルは全行を変更扱い）、バッチID |
+| 独立コードレビュー（新規） | 同上と、下の「独立コードレビューの前提」 |
+| refine（1 体） | 規約全文と関連する `AGENTS.md`・`CLAUDE.md`・docs の該当節、対象ファイル一覧、リポジトリルートの絶対パス、変更範囲の確認コマンド（`git diff HEAD -- <path>`。未追跡ファイルは全行を変更扱い）、バッチID |
 | 実装の簡素化（新規） | 目的・受入条件・最終計画・維持する契約・対象ファイルと差分・規約全文 |
 
+独立コードレビューの前提: 計画を正しいと仮定せず、実コード・利用箇所・契約から不具合を確認する。計画と形式的に異なるだけでは不具合にしない。重要度・file:line・影響・根拠・修正案、確認済みと未確認の範囲を返す。設計適合性は設計担当1 の担当なので、ここでは計画との照合ではなくコードの正しさ・安全性・性能・保守性・規約を確認する。
+
 設計担当1 は自身の設計適合性レビューを確定するまで他担当の今回の結果を読まない。先に起動した担当の完了を待ってから次を起動するのではなく、4役割を起動してから結果を待つ。同じ担当を重複起動しない。対象が大きい場合は同じ担当を再開して続きのバッチを渡し、担当数や確認範囲を黙って減らさない。
 
 全担当は読み取り専用で、今回の他担当の結果を読まず、意見を交換しない。メインと実装担当も全結果が揃うまで対象を編集しない。途中で外部の変更が入った場合は、その影響範囲を最新の同じ差分で確認し直してから統合する。
@@ -179,9 +184,9 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 
 設計担当1 が verifier の報告から全項目の採否を決め、対立・不確実性・設計上の重要点に必要な根拠を確認する。全件の事実確認を最初から繰り返さない。全指摘の採否と理由、採用した修正の対象・責務・具体的な変更・維持する契約・必要な検証を、一つの修正指示として返す。メインはそのまま記録し、仕様・受入条件の変更や未許可の範囲拡大が必要な点だけユーザーに確認する。通常の設計・修正判断をメインでやり直さない。
 
-修正不要なら Phase 9 へ進む。修正があれば、メインが同じ実装担当を再開し、設計担当1 の修正指示・確定した計画・現在の差分・規約・検証条件を渡す。再開できなければ実装履歴と採否を同じ割当の新しい担当へ引き継ぐ。設計担当1 は次のレビューに備えて継続し、コードを編集したり、実装担当を追加で起動したりしない。
+修正不要なら Phase 9 へ進む。修正があれば、メインが同じ実装担当を再開し、設計担当1 の修正指示・確定した計画・現在の差分・規約・検証条件を渡す。再開できなければ実装履歴と採否を同じ役割の新しい担当へ引き継ぐ。設計担当1 は次のレビューに備えて継続し、コードを編集したり、実装担当を追加で起動したりしない。
 
-実装担当が修正と必要な検証を行い、変更・検証結果・未解決点を返す。メインは設計担当1 の採否と修正結果を `fix-log.md` に記録する。
+実装担当が修正と必要な検証を行い、変更・検証結果・未解決点を返す。メインは設計担当1 の採否と修正結果を `fix-log.md` に記録する。委託不可の場合はメインが同じ観点で対応し、独立した確認とは報告しない。
 
 ### Phase 8: 最大2ラウンドで終了する
 
@@ -191,23 +196,20 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 
 最大2回は実装後の全体レビューに対する上限であり、担当の再開・交代や計画の変更でリセットしない。検証失敗・重大な未解決事項・未完了の担当が残る場合も追加ラウンドで無期限に続けず、その状態を明記してユーザーへ返す。未完了の確認を完了済みのラウンドと偽らない。
 
-### Phase 9: 完了報告と実行記録の確定
+### Phase 9: 完了と必要な引き継ぎ
 
 実施したレビュー回数、設計担当1 の判断と修正内容、検証結果、未解決事項を報告する。2回目の後に修正した場合は、その最終差分が再レビューされていないことを明記する。必須検証の失敗や重大な未解決事項があれば作業終了と品質上の完了を区別し、完了済みとは報告しない。
 
-[実行記録](record.md)の手順で観測値と使用量を読み、割当外の依頼の確認を行い、判定・2体目の発見の分類・修正回数・人の介入を `run-record.md` に確定する。
-
-比較実行ではコミット・PR・リリースを行わない。差分は未コミットのまま残し、回収は実施者が[比較手順](comparison.md)に従って行う。
+コミットが明示されていれば、その許可範囲と通常／自律モードを `commit` へ引き継ぐ。コミット依頼がなければ未コミットのまま完了し、毎回コミット許可を要求しない。PRやリリースは明示された場合だけ、それぞれ `create-pr`・`release` へ進む。
 
 ## 5. 成果物
 
 ```text
 .shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/
-├── run-record.md              ← 実行記録（record.md の様式）
 ├── plan.md                    ← Phase 4 の全結果を検証・統合した最終 plan
 ├── raw/
-│   ├── explorer.md            ← または explorer-1.md, explorer-2.md ...
-│   ├── architect-1.md         ← 設計担当1 の独立設計案
+│   ├── explorer.md            ← または explorer-1.md, explorer-2.md ...（引き継ぎ時の補完は explorer-supplement.md）
+│   ├── architect-1.md         ← 設計担当1 の独立設計案（2体の設定のみ）
 │   ├── architect-2.md         ← 設計担当2 の独立設計案（2体の設定のみ）
 │   ├── architect.md           ← 統合した計画（1体の設定では設計担当1 の案）
 │   ├── plan-review-{round}-{n}.md   ← 計画レビュー担当 n の結果
@@ -216,25 +218,17 @@ eafbbc5 の Claude 版 `dev`（`plugins/shinaps-claude/skills/dev/SKILL.md`）
 │   ├── implementation-verification-{round}.md ← 実装指摘の検証結果
 │   ├── refine.md              ← Phase 6 の規約照合の生レポート（2 回目は refine-2.md）
 │   ├── simplify.md            ← Phase 6 の実装の簡素化の生レポート（2 回目は simplify-2.md）
-│   ├── architect-revised-{n}.md  ← 計画の修正版（n は 1 始まり）
-│   ├── settings/              ← 観測値の抜粋
-│   ├── cli/                   ← codex exec のプロンプト・イベントログ（P1）
-│   └── agents/                ← サブエージェントへ渡した依頼の全文（P4〜P7）
+│   └── architect-revised-{round}.md  ← 計画の修正版（round は 1 始まり）
 ├── implementation.md          ← 実装ログ・変更ファイル一覧・動作確認結果
 ├── architecture-review.md     ← 設計担当1 の設計適合性レビュー
-├── architecture-review-{n}.md ← 修正後の設計適合性レビュー
+├── architecture-review-{n}.md ← 修正後の設計適合性レビュー（n は 2 始まり）
 ├── review.md                  ← 独立コードレビューの生レポート
 ├── review-{n}.md              ← 修正後の再レビュー（n は 2 始まり）
 └── fix-log.md                 ← 修正ループの履歴（修正があった場合のみ）
 ```
 
-全担当の応答は全文を参照できる状態で保存する。担当は結果を文字列で返し、進行管理の成果物はメインが保存する。
-
-## 6. 終了条件
-
-Phase 8・9 の条件で終了する。設定の不一致・未検証の項目・未完了の担当があれば `run-record.md` の判定に書き、比較データとして扱える完了として報告しない（判定は[実行記録](record.md)の定義に従う）。
+全担当の応答は全文を参照できる状態で保存する。担当は結果を文字列で返し、進行管理の成果物はメインが保存する。実装担当は担当範囲のコード・テスト・必要なドキュメントだけを編集する。
 
-## 7. テスト追加の判断
+## 6. 他スキルからの呼び出し
 
-テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、不具合の再発防止、または合意された仕様・外部契約の明示と保証を目的にする。仕様を表す既存テストは、過去のバグに由来しなくても残す。追加・更新する場合は、防ぐ不具合または保証する仕様の根拠と期待挙動を示す。実装方法を変えても守るべき挙動を検証し、テストの現状だけから未合意の仕様を作らない。既存テストで保証できるなら重複を増やさない。新機能という理由だけの網羅、根拠のない仮想的な異常系、ライブラリ単体の挙動や実装手順をなぞるだけのテストは追加しない。既存テストの実行とプロジェクトが明示する必須保証は維持し、失敗する期待値を弱めたり既存テストを一括削除したりしない。
-設計・実装・レビューへこの判断基準を渡す。バグ修正の回帰確認は修正前後の挙動で行い、自動化が困難なら理由と確認結果を残す。テストを追加しない場合も、変更に必要な既存検証や動作確認は行う。
+explore・spec・review・debug などは、生成した成果物のパスを入口の引数に直接渡す。専用の引き継ぎファイルは作らない。受け取った成果物は Phase 1・2 のとおりに扱う。どの成果物を渡すかと、既定で使う入口は、元のスキルの引き継ぎの記述に従う。

package/plugins/shinaps-codex/references/testing.md

@@ -0,0 +1,3 @@
+# テスト方針
+
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。

package/plugins/shinaps-codex/skills/commit/SKILL.md

@@ -19,14 +19,14 @@ description: 許可された差分を依存順のローカルコミットにし
 
 ## 範囲と進め方
 
-コミットは、ユーザーが明示した場合と、linear の開発進行でCodexからLocal Agent QAの合格後に対象を指定して依頼され、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり文書だけの変更として依頼された（条件の詳細はlinearの `references/configuration.md` の「許可」、文書だけの変更の判定は同じファイルの「項目」）。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。設定がない、または値がこの2つ以外なら、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
+コミットは、ユーザーが明示した場合と、linear の開発進行で、対象差分が特定され、実装とは別の工程の Local Agent QA に合格し、`human_code_review: required` なら人のレビューの完了を、`human_code_review: skip` または文書だけの変更の例外なら人のレビューを行わない条件が成り立つことを確認したうえで（省略の記録はコミット後に linear の手順で書く）、コミットの工程に進んだ場合（`implementation_skill` がClaudeの入口ならCodexからの依頼による。Codexの入口なら進行役のCodexが対象を特定して自分でこのスキルへ進む。実装担当の報告を、QAの合格や人の承認として扱わない）で、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり、Local Agent QAで対象差分が文書だけの変更と判定された（Claudeの入口ではその判定を添えて依頼された）（条件の詳細はlinearの `references/configuration.md` の「許可」、文書だけの変更の判定は同じファイルの「項目」）。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linearの開発進行では設定の不足・不正値を解消してから進む。linear以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
 
 - **通常（推奨）**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
 - **自律**: エージェントが検証できる単位を選び（許可された一連の変更をまとめてよい）、検証・レビューして個別の承認を求めずコミットする。
 
 質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。過去の別対象での自律選択は引き継がない。例外は `commit_mode` として明示的に保存されたプロジェクト設定だけで、同じプロジェクトでの依頼の選択として使う。その場の明示的な指定は設定に優先する。
 
-`commit_mode` は進め方の既定値であり、コミットの許可ではない。人のコードレビューの要否（`human_code_review`）や、ステージ・コミット・push・PR・公開の許可とは独立しており、どちらのモードもそれらを変えない。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
+`commit_mode` は進め方の設定であり、コミットの許可ではない。人のコードレビューの要否（`human_code_review`）や、ステージ・コミット・push・PR・公開の許可とは独立しており、どちらのモードもそれらを変えない。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
 
 どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。
 

package/plugins/shinaps-codex/skills/debug/SKILL.md

@@ -11,6 +11,6 @@ description: 再現手順、コード、ログと必要な外部情報から不
 
 委託が許可され登録されている場合はshinaps-debuggerで仮説を立て、shinaps-debug-validatorで実コードを検証する。外部調査にはshinaps-tech-surveyorとshinaps-survey-validatorを必要に応じて使う。取得済みのShinapsルールは親が担当へ渡す。MCP不可ならルール照合未確認とする。
 
-結論、証拠、再現状況、最小の修正方針と未確認を報告する。修正まで依頼されている場合は$shinaps:devへ引き継ぐ。調査だけなら変更しない。
+結論、証拠、再現状況、最小の修正方針と未確認を報告する。修正まで依頼されている場合は$shinaps:dev-codex-ultraへ引き継ぐ。1体での実行を指定された場合は$shinaps:dev-codexを使う。調査だけなら変更しない。
 
 必要な記録は.shinaps/work/debug/へ保存し、.shinaps/.gitignoreに`*`の除外を既存内容を保持して設定する。秘密情報・既存記録の削除・外部投稿は含めない。

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

@@ -0,0 +1,9 @@
+---
+name: dev-codex
+description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化をそれぞれ1体で確認する。実装依頼で1体での実行を指定されたときに使う。コミットは別途明示された場合だけ行う。
+---
+
+# 開発（同じ役割 1 体）
+
+同じ役割の担当数は 1 体。[工程](../../references/dev/workflow.md)と[起動手順](../../references/dev/launch.md)を読み、この担当数で進める。
+タスクの確定は[工程](../../references/dev/workflow.md)の Phase 1 に従う（引数が無いだけでは終了しない）。

package/plugins/shinaps-codex/skills/dev-codex-ultra/SKILL.md

@@ -0,0 +1,9 @@
+---
+name: dev-codex-ultra
+description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化を同じ役割の2体で独立に確認する。機能追加や修正の実装依頼の既定。コミットは別途明示された場合だけ行う。
+---
+
+# 開発（同じ役割 2 体）
+
+同じ役割の担当数は 2 体。[工程](../../references/dev/workflow.md)と[起動手順](../../references/dev/launch.md)を読み、この担当数で進める。
+タスクの確定は[工程](../../references/dev/workflow.md)の Phase 1 に従う（引数が無いだけでは終了しない）。

package/plugins/shinaps-codex/skills/explore/SKILL.md

@@ -9,6 +9,6 @@ description: 既存挙動の理由、実装方針、変更の影響を対話し
 
 委託を許可されている場合は登録済みのshinaps-investigatorに現在の質問と対象範囲を渡せる。許可がなければ現在のセッションで調べる。調査依頼を実装・設定変更・外部投稿の許可として扱わない。
 
-質問が曖昧なら結果を左右する点だけ一問確認する。回答後に新たな質問が来たら続け、仕様策定や修正へ自動で進まない。理解が揃い実装を依頼されたら、目的・合意事項・未確認事項・関連ファイルを引き継ぎ、$shinaps:devを読む。
+質問が曖昧なら結果を左右する点だけ一問確認する。回答後に新たな質問が来たら続け、仕様策定や修正へ自動で進まない。理解が揃い実装を依頼されたら、目的・合意事項・未確認事項・関連ファイルを引き継ぎ、$shinaps:dev-codex-ultraを読む。1体での実行を指定された場合は$shinaps:dev-codexを使う。
 
 継続用の記録が必要なら.shinaps/work/explorations/へ保存する。.shinaps/.gitignoreに`*`の除外を既存内容を保持して設定し、秘密情報や無関係な記録を持ち込まない。MCPが使えないときはルール照合未確認と明記する。

package/plugins/shinaps-codex/skills/linear/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: linear
-description: LinearのIssue・Cycleを起点に、作業先の規約か依頼が求める着手前のIssueへの紐づけ、Issue整理、開発の進行とAgent QA、AI Terminal Bridge経由のClaudeへの実装依頼、設定に従った人のレビューの確認または省略の記録、許可されたコミットの依頼と確認、設定した終了地点までの進行とCycle完了報告を行う。.shinaps/linear.yamlの初期設定・変更にも使う。
+description: LinearのIssue・Cycleを起点に、作業先の規約か依頼が求める着手前のIssueへの紐づけ、Issue整理、開発の進行とAgent QA、設定の implementation_skill に従ったAI Terminal Bridge経由のClaudeへの実装依頼またはCodex自身のdevの入口による実装、設定に従った人のレビューの確認または省略の記録、許可されたコミットの依頼または実施と確認、設定した終了地点までの進行とCycle完了報告を行う。.shinaps/linear.yamlの初期設定・変更にも使う。
 ---
 
 # Linearを起点に開発を進める
 
-Issueの責務・受入条件・ステータスを、実際の成果と一致させる。初版は利用者本人の環境向けで、Codexが進行・Agent QA・人への窓口を担当し、ClaudeがAI Terminal Bridge（以下Bridge）経由の依頼で実装する。Codexが実装を代わりに行う運用や、担当の入れ替えは扱わない。
+Issueの責務・受入条件・ステータスを、実際の成果と一致させる。初版は利用者本人の環境向けで、Codexが進行・Agent QA・人への窓口を担当する。実装担当は作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口ではClaudeがAI Terminal Bridge（以下Bridge）経由の依頼で実装し、Codexの入口（`dev-codex`・`dev-codex-ultra`）ではCodexが `$shinaps:<入口>` で実装・QA指摘の修正を行う（[references/workflow.md](references/workflow.md) の「担当と窓口」）。設定と異なる担当への入れ替えは扱わない。
 
 ## 再確認せず進める条件
 
@@ -22,7 +22,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 | Issueを読む・整理案を示す | なし | 整理案の提示 |
 | Issueを更新する | 設定の `issue_update`、またはその場の明示依頼 | 依頼された範囲 |
 | 初期設定・設定変更 | 利用者との合意 | 合意した設定の保存。チーム設定の変更は別に確認する |
-| Issue単位の開発進行 | 作業先リポジトリの設定（`issue_update`・`bridge_request` を含む）とBridge | 設定の `stop_after` |
+| Issue単位の開発進行 | 作業先リポジトリの設定（`issue_update` を含む。Claudeの入口では `bridge_request` とBridgeも必要） | 設定の `stop_after` |
 | Cycle単位の継続 | 上記に加えて、Cycle全体を任す明示依頼 | 対象Issueがすべて終了地点に達するか、進められる作業がなくなる |
 | Cycle完了報告 | 設定の `cycle_report` と、報告の明示依頼またはCycle全体の委任 | [references/cycle-report.md](references/cycle-report.md) の完了条件 |
 
@@ -45,4 +45,4 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 | QAの実施・記録・素材 | [references/qa.md](references/qa.md) |
 | Cycle完了QA・報告 | [references/cycle-report.md](references/cycle-report.md) |
 
-コミットは `shinaps:commit`（Claudeへ依頼する）、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには設定で許可された操作を継続的な許可として渡し、許可済みの操作を再確認しない。
+コミットは `shinaps:commit`（Claudeの入口ではClaudeへ依頼し、Codexの入口ではCodexが行う）、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには設定で許可された操作を継続的な許可として渡し、許可済みの操作を再確認しない。