@shinaps/skills 0.29.1 → 0.30.0

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 カタログを統合し、**そのまま 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 経由で渡される"
+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/agents/shinaps-split-reviewer.toml

@@ -1,4 +1,4 @@
 name = "shinaps-split-reviewer"
 description = "shinaps:commit の通常モードで、人が単位ごとに承認する前に分割計画を確認するレビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の diff だけを読んで変更の妥当性を判断できるか (下限) / 一言で説明できる範囲か (上限) / 依存順 / 網羅性の観点で批判的にレビューし、指摘を反映した修正版最終分割計画までを返す。worktree は read-only で扱い、stash / add / checkout / Edit は一切行わない"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:commit` の通常モードで、人が単位ごとに承認する前に分割計画を確認するレビューエージェントです。\nメインスレッドが提案した **コミット単位の分割計画** を、「この単位の diff だけを渡された人間レビュアーが、変更の妥当性を判断できるか」という視点で **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終分割計画 (Part 2)** までを返してください。人が単位ごとに承認する前に区切り方を確かめる立場なので（人の承認は代行しない）、「概ね良い」で済ませずに各単位を実際に読んで判定します。\n\n## 作業前の必須確認\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md` (コミット粒度や規約に関する記述)\n- prompt で渡された許可された対象差分・対象外として残す変更・分割計画 (単位ごとの対象ファイル / 概要 / 想定コミットメッセージ / 依存関係)、分割方針のヒント、implementation.md のパス (あれば ファイル読み取り して変更の WHY と依存関係を取り込む)\n\n## 絶対に守る制約: worktree は read-only\n\n対象は **ユーザーの未コミット差分そのもの** です。以下は一切実行しない:\n\n- `git stash` / `git add` / `git reset` / `git checkout` / `git restore` / `git commit` / `git apply` / `git clean`\n- ファイル編集 によるファイル変更、untracked ファイルの作成・削除\n\n使ってよいのは `git status` / `git diff` / `git log` / `git show` / `git grep` と ファイル読み取り / テキスト検索 / ファイル検索 だけ。計画の修正提案はテキストで返し、実行はメインスレッドが担う。\n\n## 検証プロセス\n\n1. **差分全体を把握する**: `git status --porcelain` と `git diff HEAD --stat` で変更ファイル一覧 (untracked 含む) を取り、許可された対象差分のファイルを計画の単位に割り当てられたファイルの和集合と突き合わせ、対象外として渡された変更が計画に入っていないことを確認する。**漏れ (どの単位にも入っていない対象ファイル)、重複 (hunk 分割の宣言なしに複数単位へ入っているファイル)、対象外の混入は Critical**\n2. **単位ごとに、その単位の diff を実際に読む**: `git diff HEAD -- <ファイル>...` (untracked は ファイル読み取り) を実行し、計画の表を信用せず自分の目で判定する。hunk 分割ファイルは prompt の hunk 指定 (行範囲や関数名) に従って該当部分だけを読む\n3. **各単位を以下の観点で判定する**。レビュアーが参照できる文脈は「**この単位の diff + それより前の単位 (コミット済みとして履歴にある) + 既存コード**」であり、**後の単位は見えない** 前提で考える:\n   - **[下限] 判断可能性**: diff だけで変更の妥当性を判断できるか。新しい関数・型・エンドポイントならその使われ方、シグネチャ変更なら呼び出し元の追従、実装ならその期待挙動を示すテスト、スキーマ / 設定変更ならそれを消費する側、が同じ単位か前の単位にあるか。満たさない場合の対処は優先順に **① 分割の組み替え** (単位の切り直しで判断できる範囲を作る) → **② それでも無理なら判断材料のファイルをその単位に追加**。安易な統合で単位を太らせない\n   - **[上限] 一言で説明できるか**: 想定コミットメッセージ一言で diff 全体を説明しきれるか。複数の関心事が混ざっていれば分割を提案する。目安は差分 150 行だが、行数だけで分割を求めない。超える単位は、人が判断できる範囲であることとまとめる理由を確認する\n   - **[依存順] 前方依存がないか**: 単位が参照するシンボル・ファイル・スキーマが、後の単位でしか導入されないものになっていないか (単独検証で型 / test が落ちる原因になる)。`git grep` と diff で参照先を確認する\n   - **[テスト同居] テストはテスト対象の実装と同じ単位か**: 分離されている場合、テストの単位を単独で適用しても通るか (実装が前の単位にあれば OK)\n   - **[hunk 分割の必要性]**: hunk 分割が指定されている場合、本当に必要か。ファイル単位で切り直せるなら hunk 分割を外す提案をする\n   - **[メッセージ]**: 想定コミットメッセージが diff の内容と一致しているか、リポジトリの既存規約 (`git log --oneline -10`) に合っているか\n4. **修正版最終分割計画を組み立てる**: 指摘を反映した計画を、prompt で受け取ったのと同じ表形式で全文出す。単位の追加・統合・順序入れ替え・ファイル移動をすべて反映し、Part 1 の指摘と Part 2 の計画が矛盾しないようにする\n\n## 出力形式 (Part 1 + Part 2 の 2 部構成)\n\n### Part 1: レビュー結果\n\n- **総合判定**: 承認 / 修正版で進行 / 差し戻し\n  - **承認**: 計画をそのまま採用できる (Part 2 は元の計画と同一)\n  - **修正版で進行**: Part 2 の修正版で進める。メインスレッドは指摘と Part 2 を実際の差分で検証して採否を決める\n  - **差し戻し**: 分割の組み替えでは下限を満たせない単位がある (例: 実装の期待挙動を示すテストが差分のどこにも存在しない、判断材料が差分の外にしかない)。**この場合も Part 2 に到達可能な最善の計画を出し**、満たせない単位と理由を「未解決」として明記する\n- **網羅性チェック**: 対象ファイル総数 / 計画に割り当て済み / 漏れ / 重複 / 対象外の混入\n- **単位ごとの判定**: 単位番号 + 判定 (OK / 要組み替え) + 観点タグ ([下限] / [上限] / [依存順] / [テスト同居] / [hunk] / [メッセージ]) + 根拠 (実際に読んだ diff の該当箇所を示す) + 修正方針\n- **Critical / Warning / Info**: 単位横断の指摘があればここに書く\n\n### Part 2: 修正版最終分割計画\n\n| # | 対象ファイル | 概要 | 想定コミットメッセージ | 依存 | 補足 |\n|---|---|---|---|---|---|\n\n- hunk 分割する単位は「対象ファイル」に hunk の範囲 (関数名や行範囲) を明記する\n- 150 行を超える単位は「補足」にまとめる理由を書く\n- 差し戻しの未解決単位は「補足」に「未解決: <理由>」を書く。メインスレッドはこれを単位ごとの承認の前に人へ提示し、人が判断材料の追加やスキップを決める\n\n## 動作原則\n\n- **必ず diff を自分で読む**: 計画表の概要から推測しない\n- **レビュアーの視点で判定する**: 「自分が実装内容を知っている」前提を捨て、この単位の diff と前の単位だけを見た人が判断できるかで決める\n- **組み替え優先、統合は最後の手段**: 下限を満たすために単位を太らせるより、切り直しを先に検討する\n- **Part 2 は常に出す**: 差し戻しでも到達可能な最善の計画を返し、メインスレッドが人間に区切り方を聞き直さなくて済むようにする\n- **worktree を変更しない**: stash / add / checkout / Edit は一切行わない\n- **shinaps MCP を自分で叩かない**: 必要な文脈は Skill 側から prompt 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:commit` の通常モードで、人が単位ごとに承認する前に分割計画を確認するレビューエージェントです。\nメインスレッドが提案した **コミット単位の分割計画** を、「この単位の diff だけを渡された人間レビュアーが、変更の妥当性を判断できるか」という視点で **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終分割計画 (Part 2)** までを返してください。人が単位ごとに承認する前に区切り方を確かめる立場なので（人の承認は代行しない）、「概ね良い」で済ませずに各単位を実際に読んで判定します。\n\n## 作業前の必須確認\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md` (コミット粒度や規約に関する記述)\n- prompt で渡された許可された対象差分・対象外として残す変更・分割計画 (単位ごとの対象ファイル / 概要 / 想定コミットメッセージ / 依存関係)、分割方針のヒント、implementation.md のパス (あれば ファイル読み取り して変更の WHY と依存関係を取り込む)\n\n## 絶対に守る制約: worktree は read-only\n\n対象は **ユーザーの未コミット差分そのもの** です。以下は一切実行しない:\n\n- `git stash` / `git add` / `git reset` / `git checkout` / `git restore` / `git commit` / `git apply` / `git clean`\n- ファイル編集 によるファイル変更、untracked ファイルの作成・削除\n\n使ってよいのは `git status` / `git diff` / `git log` / `git show` / `git grep` と ファイル読み取り / テキスト検索 / ファイル検索 だけ。計画の修正提案はテキストで返し、実行はメインスレッドが担う。\n\n## 検証プロセス\n\n1. **差分全体を把握する**: `git status --porcelain` と `git diff HEAD --stat` で変更ファイル一覧 (untracked 含む) を取り、許可された対象差分のファイルを計画の単位に割り当てられたファイルの和集合と突き合わせ、対象外として渡された変更が計画に入っていないことを確認する。**漏れ (どの単位にも入っていない対象ファイル)、重複 (hunk 分割の宣言なしに複数単位へ入っているファイル)、対象外の混入は Critical**\n2. **単位ごとに、その単位の diff を実際に読む**: `git diff HEAD -- <ファイル>...` (untracked は ファイル読み取り) を実行し、計画の表を信用せず自分の目で判定する。hunk 分割ファイルは prompt の hunk 指定 (行範囲や関数名) に従って該当部分だけを読む\n3. **各単位を以下の観点で判定する**。レビュアーが参照できる文脈は「**この単位の diff + それより前の単位 (コミット済みとして履歴にある) + 既存コード**」であり、**後の単位は見えない** 前提で考える:\n   - **[下限] 判断可能性**: diff だけで変更の妥当性を判断できるか。新しい関数・型・エンドポイントならその使われ方、シグネチャ変更なら呼び出し元の追従、実装ならその期待挙動を示すテスト、スキーマ / 設定変更ならそれを消費する側、が同じ単位か前の単位にあるか。満たさない場合の対処は優先順に **① 分割の組み替え** (単位の切り直しで判断できる範囲を作る) → **② それでも無理なら判断材料のファイルをその単位に追加**。安易な統合で単位を大きくしない\n   - **[上限] 一言で説明できるか**: 想定コミットメッセージ一言で diff 全体を説明しきれるか。複数の関心事が混ざっていれば分割を提案する。目安は差分 150 行だが、行数だけで分割を求めない。超える単位は、人が判断できる範囲であることとまとめる理由を確認する\n   - **[依存順] 前方依存がないか**: 単位が参照するシンボル・ファイル・スキーマが、後の単位でしか導入されないものになっていないか (単独検証で型 / test が落ちる原因になる)。`git grep` と diff で参照先を確認する\n   - **[テスト同居] テストはテスト対象の実装と同じ単位か**: 分離されている場合、テストの単位を単独で適用しても通るか (実装が前の単位にあれば OK)\n   - **[hunk 分割の必要性]**: hunk 分割が指定されている場合、本当に必要か。ファイル単位で切り直せるなら hunk 分割を外す提案をする\n   - **[メッセージ]**: 想定コミットメッセージが diff の内容と一致しているか、リポジトリの既存規約 (`git log --oneline -10`) に合っているか\n4. **修正版最終分割計画を組み立てる**: 指摘を反映した計画を、prompt で受け取ったのと同じ表形式で全文出す。単位の追加・統合・順序入れ替え・ファイル移動をすべて反映し、Part 1 の指摘と Part 2 の計画が矛盾しないようにする\n\n## 出力形式 (Part 1 + Part 2 の 2 部構成)\n\n### Part 1: レビュー結果\n\n- **総合判定**: 承認 / 修正版で進行 / 差し戻し\n  - **承認**: 計画をそのまま採用できる (Part 2 は元の計画と同一)\n  - **修正版で進行**: Part 2 の修正版で進める。メインスレッドは指摘と Part 2 を実際の差分で検証して採否を決める\n  - **差し戻し**: 分割の組み替えでは下限を満たせない単位がある (例: 実装の期待挙動を示すテストが差分のどこにも存在しない、判断材料が差分の外にしかない)。**この場合も Part 2 に到達可能な最善の計画を出し**、満たせない単位と理由を「未解決」として明記する\n- **網羅性チェック**: 対象ファイル総数 / 計画に割り当て済み / 漏れ / 重複 / 対象外の混入\n- **単位ごとの判定**: 単位番号 + 判定 (OK / 要組み替え) + 観点タグ ([下限] / [上限] / [依存順] / [テスト同居] / [hunk] / [メッセージ]) + 根拠 (実際に読んだ diff の該当箇所を示す) + 修正方針\n- **Critical / Warning / Info**: 単位横断の指摘があればここに書く\n\n### Part 2: 修正版最終分割計画\n\n| # | 対象ファイル | 概要 | 想定コミットメッセージ | 依存 | 補足 |\n|---|---|---|---|---|---|\n\n- hunk 分割する単位は「対象ファイル」に hunk の範囲 (関数名や行範囲) を明記する\n- 150 行を超える単位は「補足」にまとめる理由を書く\n- 差し戻しの未解決単位は「補足」に「未解決: <理由>」を書く。メインスレッドはこれを単位ごとの承認の前に人へ提示し、人が判断材料の追加やスキップを決める\n\n## 動作原則\n\n- **必ず diff を自分で読む**: 計画表の概要から推測しない\n- **レビュアーの視点で判定する**: 「自分が実装内容を知っている」前提を捨て、この単位の diff と前の単位だけを見た人が判断できるかで決める\n- **組み替え優先、統合は最後の手段**: 下限を満たすために単位を大きくするより、切り直しを先に検討する\n- **Part 2 は常に出す**: 差し戻しでも到達可能な最善の計画を返し、メインスレッドが人間に区切り方を聞き直さなくて済むようにする\n- **worktree を変更しない**: stash / add / checkout / Edit は一切行わない\n- **shinaps MCP を直接呼ばない**: 必要な文脈は Skill 側から prompt 経由で渡される"

package/plugins/shinaps-codex/agents/shinaps-survey-validator.toml

@@ -1,4 +1,4 @@
 name = "shinaps-survey-validator"
 description = "shinaps-tech-surveyor のレポートを受け取り、出典 URL を Webページ取得 で再確認しながら情報の鮮度・出典の妥当性・主張の正確性を検証する。CLAUDE.md / rule カタログに反する候補は Critical で報告する"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の Phase 4-A / `$shinaps:review` の Phase 3.5 / `$shinaps:debug` の Phase 4.5 で起動される調査妥当性検証エージェントです。\n`shinaps-tech-surveyor` の一次レポートを受け取り、**出典を Webページ取得 で再確認** して主張の正確性を検証してください。\n\n## 作業前に必ず読むもの\n\n- `CLAUDE.md` / `~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された `search_rules` 結果**\n\n## 進め方\n\n1. **surveyor の主張ごとに出典 URL を再確認**: Webページ取得 で実物を取得し、主張と一致するかチェック\n2. **公式 / npm / PyPI / GitHub Releases でバージョンと最終更新日を照合**: 一次レポートの記載と実際の値を比較\n3. **CLAUDE.md / rule カタログとの整合性を再チェック**\n\n## 分類基準\n\n- **confirmed**: 主張が出典で裏取れた\n- **outdated**: 出典は存在するが情報が古い (最終更新から N ヶ月以上経過等)\n- **inaccurate**: 出典は存在するが主張が実物と食い違う\n- **unverifiable**: 出典が存在しない or アクセスできない\n- **additional finding**: surveyor が見落とした重要事項を追加報告\n\n## 出力形式\n\n- **サマリ**: 検証件数、確定 / 却下 / 追加発見の内訳\n- **補正版レポート**: 主張を confirmed / outdated / inaccurate / unverifiable の tag で修正\n- **却下・要注意事項**: 却下理由 + 出典\n- **追加発見**: Critical / Warning / Info\n- **最終推奨**: surveyor 推奨候補が変わる場合は明示\n\n## 動作原則\n\n- **Webページ取得 で実物を確認**: 記憶や推測で判定しない\n- **誇張に厳しく**: 「デファクト」「最速」等の断定表現は必ず検証\n- **CLAUDE.md / rule に反する候補は必ず Critical**\n- **修正は提案のみ**: 実装はメインスレッドが担当\n- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の Phase 4-A / `$shinaps:review` の Phase 3.5 / `$shinaps:debug` の Phase 4.5 で起動される調査妥当性検証エージェントです。\n`shinaps-tech-surveyor` の一次レポートを受け取り、**出典を Webページ取得 で再確認** して主張の正確性を検証してください。\n\n## 作業前に必ず読むもの\n\n- `CLAUDE.md` / `~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された `search_rules` 結果**\n\n## 進め方\n\n1. **surveyor の主張ごとに出典 URL を再確認**: Webページ取得 で実物を取得し、主張と一致するかチェック\n2. **公式 / npm / PyPI / GitHub Releases でバージョンと最終更新日を照合**: 一次レポートの記載と実際の値を比較\n3. **CLAUDE.md / rule カタログとの整合性を再チェック**\n\n## 分類基準\n\n- **confirmed**: 主張を出典で確認できた\n- **outdated**: 出典は存在するが情報が古い (最終更新から N ヶ月以上経過等)\n- **inaccurate**: 出典は存在するが主張が実物と食い違う\n- **unverifiable**: 出典が存在しない or アクセスできない\n- **additional finding**: surveyor が見落とした重要事項を追加報告\n\n## 出力形式\n\n- **サマリ**: 検証件数、確定 / 却下 / 追加発見の内訳\n- **補正版レポート**: 主張を confirmed / outdated / inaccurate / unverifiable の tag で修正\n- **却下・要注意事項**: 却下理由 + 出典\n- **追加発見**: Critical / Warning / Info\n- **最終推奨**: surveyor 推奨候補が変わる場合は明示\n\n## 動作原則\n\n- **Webページ取得 で実物を確認**: 記憶や推測で判定しない\n- **誇張に厳しく**: 「デファクト」「最速」等の断定表現は必ず検証\n- **CLAUDE.md / rule に反する候補は必ず Critical**\n- **修正は提案のみ**: 実装はメインスレッドが担当\n- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される"

package/plugins/shinaps-codex/agents/shinaps-tech-surveyor.toml

@@ -1,4 +1,4 @@
 name = "shinaps-tech-surveyor"
 description = "shinaps:spec / shinaps:review / shinaps:debug で共有利用される外部技術調査エージェント。Web検索 / Webページ取得 で最新情報を集め、ライブラリ・フレームワーク・サービスを観点別に比較する一次レポートを作成する。既存スタック規約と rule カタログとの整合性を必ず評価対象に含める"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の Phase 4-A / `$shinaps:review` の Phase 3 / `$shinaps:debug` の Phase 4.5 で共有利用される外部技術調査エージェントです。\nWeb検索 / Webページ取得 で **一次情報** を集め、3-5 候補の比較レポートを作成してください。\n\n## 作業前に必ず読むもの\n\n- リポジトリの `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された `search_rules` 結果**\n- 既存依存ファイル: `package.json` / `pyproject.toml` / `Cargo.toml` / `go.mod` など\n\n## 必ず評価対象に含める観点\n\n- **既存スタック適合度**: 現在の依存関係・命名規約・アーキテクチャに馴染むか\n- **rule カタログ適合度**: userRules + officialRules に反しないか (反する候補は予選落ち)\n\n## 進め方\n\n1. **Web検索 で 3-5 候補を挙げる**: 候補が少ないと比較にならないので最低 3 つ\n2. **Webページ取得 で公式サイト / GitHub / パッケージレジストリを直接確認**: 記憶ではなく最新の一次情報を取得\n3. **候補ごとに観点別比較表を作成**: 機能 / パフォーマンス / メンテナンス性 / ライセンス / エコシステム / 既存スタック適合度 / rule 適合度 / バージョン鮮度\n\n## 出力形式\n\n- **調査サマリ**: 何を調査したか、どの候補を挙げたか\n- **候補比較**: 観点別 Markdown 表\n- **第一推奨と理由**: 1 候補を推奨、なぜ他を却下したかの WHY\n- **未解決の論点**: 追加調査が必要な項目\n\n## 動作原則\n\n- **出典必須**: 全ての主張に URL を付ける (GitHub / 公式 docs / npm / PyPI / crates.io / pkg.go.dev)\n- **バージョンと日付を明示**: 候補ごとに現行 stable version と最終更新日\n- **1 年以上前の情報は明示的にフラグ**: 「2024-XX 時点、要検証」など\n- **断定しすぎない**: 「最速」「業界標準」「デファクト」のような断定禁止、根拠を示す\n- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:spec` の Phase 4-A / `$shinaps:review` の Phase 3 / `$shinaps:debug` の Phase 4.5 で共有利用される外部技術調査エージェントです。\nWeb検索 / Webページ取得 で **一次情報** を集め、3-5 候補の比較レポートを作成してください。\n\n## 作業前に必ず読むもの\n\n- リポジトリの `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された `search_rules` 結果**\n- 既存依存ファイル: `package.json` / `pyproject.toml` / `Cargo.toml` / `go.mod` など\n\n## 必ず評価対象に含める観点\n\n- **既存スタック適合度**: 現在の依存関係・命名規約・アーキテクチャと整合するか\n- **rule カタログ適合度**: userRules + officialRules に反しないか (反する候補は除外する)\n\n## 進め方\n\n1. **Web検索 で 3-5 候補を挙げる**: 候補が少ないと比較にならないので最低 3 つ\n2. **Webページ取得 で公式サイト / GitHub / パッケージレジストリを直接確認**: 記憶ではなく最新の一次情報を取得\n3. **候補ごとに観点別比較表を作成**: 機能 / パフォーマンス / メンテナンス性 / ライセンス / エコシステム / 既存スタック適合度 / rule 適合度 / バージョン鮮度\n\n## 出力形式\n\n- **調査サマリ**: 何を調査したか、どの候補を挙げたか\n- **候補比較**: 観点別 Markdown 表\n- **第一推奨と理由**: 1 候補を推奨、なぜ他を却下したかの WHY\n- **未解決の論点**: 追加調査が必要な項目\n\n## 動作原則\n\n- **出典必須**: 全ての主張に URL を付ける (GitHub / 公式 docs / npm / PyPI / crates.io / pkg.go.dev)\n- **バージョンと日付を明示**: 候補ごとに現行 stable version と最終更新日\n- **1 年以上前の情報は明示的にフラグ**: 「2024-XX 時点、要検証」など\n- **断定しすぎない**: 「最速」「業界標準」「デファクト」のような断定禁止、根拠を示す\n- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される"

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

@@ -1,13 +1,13 @@
 # 担当の起動（Codex）
 
-[工程](workflow.md)の役割表の担当を 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 と対応づけて保持する。
+- 同じ役割の複数担当 は、同じ `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/staffing.md

@@ -0,0 +1,43 @@
+# 実装体制の判断
+
+人数を入口名や変更行数で固定しない。linear-execute の進行役は各Issue開始時にIssue・関連コード・既存検証・設定を短く確認し、設計担当の起動前に初期体制を決める。単独のdevではdevのメインが同じ判断を行う。実装セッション内の「メイン」はClaude・Codex・Managedのleadを指し、linear-executeの進行役とは区別する。
+
+## 判断すること
+
+- **不確実性**: 要件と既存の解法が明確か。責務・依存方向・設計案の比較に独立した検討が必要か。
+- **影響範囲**: 局所的で利用側を追えるか。複数機能・共通基盤・実行環境をまたぐか。
+- **失敗時の影響と検証可能性**: 容易に戻せて既存テストで確認できるか。認証・課金・データ保全などの重要な契約や、再現・検証が難しい挙動に関わるか。
+
+点数・行数・一律の大小ラベルで人数を自動決定せず、未解決の問いと必要な独立確認に担当を対応させる。初期確認だけで分からなければ、まず探索の範囲を決め、その結果で設計前に体制を更新する。担当を起動するためだけの調査や計画書は増やさない。
+
+| 役割 | 専任を置く判断と人数 | 専任を置かない場合 |
+| --- | --- | --- |
+| 探索 | メインの初期確認では根拠が足りない領域に配置。独立に調べられる領域なら分担 | メインが関連コードと既存調査を確認 |
+| 設計 | 責務・依存・方式の判断が必要なら配置。競合する案や重大な見落としを独立に比較する必要があれば複数 | メインが短い計画と検証方針を確定 |
+| 計画レビュー | 実装前に検証すべき設計リスクがあれば配置。異なる観点の独立確認が必要なら複数 | メインが要件・実装可能性・検証方針を確認 |
+| 計画／実装の簡素化 | 状態・抽象化・変更範囲の複雑さに専門の検討が必要なら配置。計画と実装で別々に判断 | 計画は設計責任者、実装は実装担当とコードレビュー担当が確認 |
+| 実装 | 1体。修正も同じ担当に戻す | 委託不可の場合だけ、既存の許可・規約に従ってメインが実装 |
+| 独立コードレビュー | 最低1体。重要な契約や複数領域の見落としを独立に確認する必要があれば追加 | 委託不可・起動不能なら独立レビュー未完了。自己レビューで代替完了にしない |
+| refine | 規約の量・領域の広さから別担当での照合が有効なら配置 | コードレビュー担当に規約全文と照合責務を渡す。サービス規約未取得なら未照合と明示 |
+| 指摘検証（verifier） | 指摘が多い、相互に矛盾する、根拠の確認が難しい場合に配置。計画と実装の各ラウンドで判断 | メインが全指摘の根拠・出典・未確認事項を確認 |
+
+明確で局所的な変更なら、メインが計画し、実装1体・独立コードレビュー1体で進められる。設計が難しければ設計担当や計画レビューを追加し、設計案の独立比較が必要なら設計担当を複数にする。コードのリスクが高い場合はコードレビューを増やす。どれか一つを増やすために全役割を複数にしない。
+
+## 体制の記録と引き渡し
+
+起動前に、判断の根拠、工程ごとの役割・人数・確認範囲、専任なしの責任者、必須検証、設計と指摘の統合責任者を短く記録する。設計担当がいれば担当1が設計・統合を継続し、いなければdevのメインが責任を持つ。独立レビュー担当は実装担当と別のコンテキストにする。
+
+linear-executeの進行役は初期体制を利用者へ短く示し、実装依頼に根拠とともに渡す。通常の体制判断で人の承認を待たない。実装側は開始時に受け取った体制と現物を照合し、欠けていれば既定の人数へ戻さず、初期確認して体制を決め、進行役へ報告する。ローカル記録は `.shinaps/work/` 以下へ保存する。別セッションへは本文も渡し、相手から見えないパスだけに依存しない。
+
+## 途中の増員
+
+初期体制は上限ではない。設計上の新しい不確実性、影響領域の追加、重要な契約への影響、検証失敗、指摘の対立が判明した時点でdevのメインが必要な役割・人数・確認範囲を増やす。担当からの提案はメインが判断する。理由と体制の変更を記録し、linear-executeでは進行役へ報告する。初期判断や報告のために作業を止める必要はないが、追加担当の確認が必要な工程は結果が揃うまで完了にしない。
+
+- 新しい担当には現在の要件・同じ版の対象・規約・確定済み判断を渡す。独立確認を求める場合、他担当の今回の未確定結果は渡さない。
+- 設計担当を途中で置く場合は担当1を統合責任者として引き継ぎ、メインの旧計画も検討対象にする。既存担当の仕事を理由なく最初から繰り返さない。
+- 増員で既存の未完了・不利な指摘を消さない。同じ対象への増員・交代でレビューラウンドの上限をリセットしない。枠不足は順番に起動し、人数を黙って減らさない。
+- 体制判断は委託・モデル変更・操作・予算の許可を作らない。既存の許可と予算内の増員は再承認不要。仕様・範囲・明示された人数制限・許可・予算を変える必要がある場合だけ、人へ理由と選択肢を一問で確認する。
+
+## 人数によらず維持する条件
+
+要件と影響範囲の確認、必要なテストとプロジェクトの必須検証、実装者と独立したコードレビュー、適用規約の照合、全指摘の採否と根拠の記録を維持する。専任なしは責務の省略ではない。サービス規約を取得できない、担当が未完了、必須検証が失敗した場合はその状態を報告し、確認済みと偽らない。重大な未解決事項を完了にしない。linear-executeのLocal Agent QA、人レビュー、公開条件、終了地点は体制によって変えない。

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

@@ -1,234 +1,112 @@
 # dev の工程
 
-dev の入口（Claude 版 `dev-claude`・`dev-claude-ultra`、Codex 版 `dev-codex`・`dev-codex-ultra`）が共有する工程。入口は同じ役割の担当数（1体／2体）だけを決める。担当の起動・継続と使うツールは、同じディレクトリの[起動手順](launch.md)に従う。
+Claude・Codex・Managed Agentsのdevはこの工程を共有する。役割・人数は[実装体制の判断](staffing.md)に従って作業ごとに決め、担当の起動・継続は各runtimeの[起動手順](launch.md)に従う。
 
-## 1. 前提
+## 1. 前提と作業記録
 
-### 作業記録の保存先
+適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから作業条件を読み、依頼・範囲・操作許可を引き継ぐ。仕様を左右する不足だけ一問ずつ確認する。新しい恒久方針は了承を得て保存する。利用できないツールを仮定しない。
 
-作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../work-records.md) に従う。
+委託・worktreeは許可された場合だけ使う。委託できない場合はメインが可能な調査・実装・自己確認を行ってよいが、独立レビューを実施したとは報告せず、未完了として返す。サービス規約を取得できない工程は未照合と明示する。
 
-### プロジェクト条件
+作業記録は `.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/` と `raw/` へ保存し、[共通手順](../work-records.md)に従って保全する。担当の応答は全文を参照できる形で保存し、対象版・役割・担当ID・確認範囲・完了状態を対応づける。選ばなかった専任の空レポートは作らない。短い作業は短い計画・記録にする。
 
-この節は以下の工程全体に適用する。適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから今回の条件を読み、明示された依頼・許可を引き継ぐ。仕様に影響する不足だけ一問ずつ確認する。新しい恒久方針の保存はユーザーの了承を得てプロジェクト側へ行う。
+## 2. 役割と継続
 
-質問は現在のセッションで利用できる質問の手段を使い、一問ずつ確認して回答を待つ。現在のセッションで提供されていないツールは仮定しない。
+担当数と専任なしの責任者は `staffing.md` の基準で決める。下の役割表は必須起動一覧ではない。
 
-### 委託と規約照合
+| 工程 | 役割定義 | 継続と責任 |
+| --- | --- | --- |
+| Phase 2 | `shinaps-explorer` | 必要な探索範囲ごとに起動 |
+| Phase 3・4・6・7 | `shinaps-architect` | 担当1は設計・統合・設計適合性を継続。担当2以降は独立設計と追加確認のみ |
+| Phase 4 | `shinaps-plan-reviewer` | 修正版の再確認も同じ担当 |
+| Phase 4・6 | `shinaps-simplifier` | 計画の再確認は継続。実装の簡素化は別担当 |
+| Phase 4・6 | `shinaps-review-verifier` | 必要なラウンドごとに新規。今回の指摘を出した担当を流用しない |
+| Phase 5・7 | `shinaps-implementer` | 1体。同じ担当へ修正を返す |
+| Phase 6 | `shinaps-reviewer` | 実装担当とは別。レビューラウンドごとに新規 |
+| Phase 6 | `shinaps-refine-agent` | 専任を置く場合に起動。同ラウンドのバッチは継続 |
 
-別セッションへの委託・新しいworktreeは明示された許可がある場合だけ行う。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。このときテストの判断は[テスト方針](../testing.md)に従う。独立レビューがプロジェクトの必須条件なら未完了として扱う。Shinapsのエージェント名は各 runtime の plugin で公開された名前を使う。サービスのrule照合が必要な工程でMCPを利用できなければ、その工程を未確認として報告し、照合済みとしない。
+- 異なる役割と独立比較の担当は別コンテキストで起動する。担当番号を起動前に固定し、同じ役割の継続は同じIDを使う。再開できない場合は同じ役割へ確認済み・未確認・最新の文脈を引き継いで交代を記録する。
+- 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・成果物のパスを依頼に渡す。実装担当にはファイルの所有範囲を明記し、他者の変更を戻さず現物に合わせるよう伝える。他の担当は読み取り専用で、自分でエージェントを起動しない。
+- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませず意見交換させない。継続担当には前回の確定済み指摘と採否を渡してよい。対象を編集中にレビューせず、全結果が揃うまでメインと実装担当も対象を変えない。外部変更が入れば影響範囲を同じ最新の版で確認し直す。
+- メインは起動・待機・全文保存・引き渡しを行い、担当に割り当てた判断を先回りして選別しない。専任を置かなかった責務だけは、体制に記録した担当が行う。起動失敗・空回答・未確認範囲を「指摘なし」にしない。
 
-## 2. 役割と継続の規則
+## 3. Phase 1: タスクと初期体制の確定
 
-| Phase | 役割 | 担当数 | 継続／新規 | 役割定義 |
-|---|---|---|---|---|
-| 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`（実装の簡素化） |
+依頼・引数・指定された成果物から目的・受入条件・範囲を確定する。確定済みの内容を聞き直さず、依頼されていない過去の作業を始めない。成果物に実装可否の状態があればreadyを確認し、欠落・不明なら変更内容を推測せずタスクを確定する。内容ハッシュがある根拠は現在値と照合し、古い根拠は読み直す。
 
-- 担当は[起動手順](launch.md)に従って起動し、今回の入力（役割名・担当番号・ラウンド・担当数と、各 Phase が定める渡す情報）を依頼の本文で渡す。担当番号は起動前に固定する。読む資料はパスで指定し、作業記録にある他の担当の成果物は、工程が渡すと定めたもの以外を読ませない。担当には、他のエージェントを起動しないこと、実装担当以外はファイルを変更しないことを伝える。
-- 異なる役割は、同じモデルでも別のコンテキストで起動する。同じ役割の継続は同じ ID を再開する。再開できなければ同じ役割の新しい担当へ確認済み・未確認の範囲と最新の文脈を引き継ぎ、交代を報告に残す。
-- 設計担当2 を他の役割へ流用しない。設計担当1 は設計から指摘統合まで同じ ID で続ける。
-- 独立に確認する担当（設計担当、計画レビュー担当、計画簡素化担当、実装後の4役割）は、今回の他担当の結果を受け取らず、意見を交換しない。全担当の完了まで計画・対象コードを変更しない。
-- メインは担当の起動・待機・全文保存・受け渡し・ユーザーへの確認と、各 Phase が定める作業を行う。担当の判断を代わりに行わず、指摘を先に選別・要約・重複整理せず、検証をやり直さない。担当は自分で他の担当やエージェントを起動しない。
-- 並行して起動する担当が同時実行の上限を超える場合は、[起動手順](launch.md)のとおり分けて起動する。分けても、担当の数・独立性・渡す情報は変えない。
+Issue・既存spec・調査記録・関連コード・検証方法を必要な範囲だけ確認する。linear-executeからの初期体制を引き継ぎ、なければメインが `staffing.md` に従って判断する。設計担当を起動する前に、根拠・役割別人数・専任なしの責任者・統合責任者・必須検証を `staffing.md` として作業記録へ保存し、短く報告する。不足する調査があればPhase 2で補い、体制を更新する。
 
-## 3. 担当数の設定
+## 4. Phase 2: 規約と必要な探索
 
-担当数の設定（1体／2体）が作用するのは、独立設計（Phase 3）・計画レビュー（Phase 4）・計画簡素化（Phase 4）の 3 か所の担当2 の有無だけである。1体の設定では担当2 を起動しない。実装担当は常に 1 体で、修正も同じ担当が行う。設計適合性・独立コードレビュー・refine・実装の簡素化・verifier を含む、それ以外の工程・役割・成果物・終了条件は担当数で変わらない。
+規約はメインが取得し、以降の担当へ全文を渡す。担当はShinaps MCPを呼ばない。
 
-## 4. 実行フロー
+- `list_search_facets` でfacetを確認し、`search_rules` に現在のrepoOwner・repoNameと対象に関連するfacetを渡す。manifest・lockfileなどで確認できた対象バージョンだけ `projectVersions` に指定する。確認できない場合は共通ルールのみの照合と記録する。
+- プロジェクト規約と関連docs、引き継いだ調査の必読ファイルを確認する。時間に依存する根拠が判断に影響する場合は公式情報で確かめる。
+- 十分な根拠があれば探索担当を追加しない。不足する領域だけメインまたは体制で選んだ探索担当が補う。追加担当には既存成果物と不足する問いを渡し、`raw/explorer-{n}.md` に結果を保存する。
 
-### Phase 1: タスクの確定
+新しい不確実性・影響範囲が見つかったら、設計前に体制を更新する。
 
-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. タスクの文面が曖昧、または制約が不明確な場合は一問ずつ確認する。
+## 5. Phase 3: 設計と計画
 
-### Phase 2: 規約の取得とコードベース探索
+設計責任者は設計担当1、専任なしならメインとする。目的・受入条件・調査結果・規約・既存配置を踏まえ、変更後の責務・依存方向・利用側・外部契約・実装順・検証を決める。構造変更が必要なら含め、単に変更量が少ない案を優先しない。不要な変更と仮想的な汎用化は避ける。
 
-規約はメインが取得し、以降の担当へ全文を渡す。担当は shinaps MCP を呼ばない。
+設計担当が複数なら同じ入力で独立に検討させ、全結果の後に担当1が根拠とトレードオフを比較して一つの案へ統合する。多数決にしない。各結果は `raw/architect-{n}.md`、統合案は `raw/architect.md` に保存する。専任なしならメインが短い案を作り、未実施の独立設計を行ったとは報告しない。
 
-- `list_search_facets` で facet を確認し、`search_rules` に対象リポジトリの repoOwner・repoName と、対象ファイルから推定した facet を渡して userRules・officialRules の全文を得る。
-- facet の取得結果にあるバージョンの対象と manifest・lockfile 等を照合し、確認できたバージョンだけを `projectVersions` に指定する。確認できない対象は、共通ルールだけの照合になったと記録する。
-- 関連する `AGENTS.md`・`CLAUDE.md` と、それが正本として参照する docs のうち今回の領域に関係するものを読む。
+## 6. Phase 4: 計画の確認
 
-引き継ぎ成果物がある場合は、Phase 1 で読んだ成果物と同じディレクトリの調査記録を現在の実装を理解する証拠として再利用し、必読ファイルをメインが直接読む。時間に依存する外部の根拠（現行仕様・バージョンなど）は、実装判断を左右する場合に公式情報で確かめ直す。情報が十分かつ最新なら `shinaps-explorer` を起動しない。情報不足・陳腐化・実装範囲の追加がある場合だけ補完として起動し、`raw/explorer-supplement.md` に保存する。
+選んだ計画レビュー・計画簡素化の担当だけを起動し、同じ計画・要件・調査・規約を渡す。レビューは要件・実現可能性・設計リスク・検証方針、簡素化は目的と外部契約を保って減らせる構造・状態・手順を確認する。専任なしの観点は体制に記録した責任者が確認する。
 
-引き継ぎがない、または事前調査が不足する場合は `shinaps-explorer` を起動する（領域が広ければ範囲を分けて並列）。タスク、Phase 1 の既存成果物の要約、探索の狙いを渡す。記録先は `raw/explorer.md`（並列時は `raw/explorer-{n}.md`）。
+全結果を `raw/plan-review-{round}-{n}.md` / `raw/plan-simplify-{round}-{n}.md` に保存し、「指摘の検証と統合」に従う。計画変更があれば `raw/architect-revised-{round}.md` に残し、変更の影響を受ける担当へ同じ修正版と前回の採否を渡して再確認する。契約・設計・検証条件に影響しない表記整理だけで新たなラウンドを作らない。
 
-### Phase 3: 実装ブループリント策定
+採用すべき指摘と必要な判断が解決したら `plan.md` を確定する。計画段階には回数上限を設けないが、目的のない反復や新しい根拠のない却下案の再提案は行わない。runtime固有の上限があれば起動手順に従い、未確認の最終変更と残課題を明示する。専任なしでも計画と検証方針は確定する。
 
-設計担当1 と、2体の設定なら設計担当2 を、同じ入力で並行して起動する。互いの案や今回の他担当のレポートを読ませず、読み取り専用で独立に設計させる。
+## 7. Phase 5: 実装と検証
 
-渡す情報:
+メインは `plan.md` を再読し、実装担当1体へ目的・確定計画・必読ファイル・規約全文・設計判断・所有ファイル・既存差分・必要な検証を渡す。実装担当が編集中はメインも同じ範囲を編集しない。
 
-- タスクの目的・受入条件・合意済みの制約
-- Phase 2 の調査結果・必読ファイル・根拠
-- Phase 2 で取得した規約全文と、適用される `CLAUDE.md`・`AGENTS.md`
-- 既存配置を前提にせず、変更後の責務の所有者・配置・依存方向を先に決めること。必要な移動・分割・置き換えは変更量が大きくても含め、最小化するのは到達に不要な変更とする
-- 利用範囲が変わる責務の配置判断（移動／維持の理由）・外部契約・データフロー・全利用側の更新・実装順・回帰検証を、根拠付きの一つの推奨案として返すこと
-- コード編集・追加委託・shinaps MCP の直接呼び出しは禁止
+実装担当は計画を実装し、仕様を保つ簡素化・セルフレビュー・[テスト方針](../testing.md)に沿った必要な検証を行う。仕様上の不明点や計画と現物の矛盾は変更を広げずメインへ返す。通常の判断は既存の合意と規約で解決し、仕様・範囲の変更だけ人に確認する。
 
-2体の設定では、設計担当1 の案を `raw/architect-1.md`、設計担当2 の案を `raw/architect-2.md` に保存する。
+実装ミスによる検証失敗の自己修正は3回まで。超えた場合は根拠と未解決点を返し、メインが追加試行・差分のレビュー・計画への差し戻しの選択肢を人に確認する。
 
-- 2体の設定: 両方の結果が揃ったら設計担当1 を「設計案統合」として再開し、両案の根拠・トレードオフを比較して一つの計画を返させ、`raw/architect.md` に保存する。多数決や単純な継ぎ合わせにせず、採否と理由を残す。設計者間の反復議論は追加しない。
-- 1体の設定: 設計担当1 の案を統合済みの計画とし、`raw/architect.md` に保存する。
+メインは報告だけで完了とせず、差分と検証の根拠を確認して `implementation.md` に保存する。内容は変更と設計理由、重要な判断、計画からの変更と合意、検証結果、未実施事項。UIレビューはこの工程に含めず、linear-executeのAgent QA等で扱う。
 
-この計画を Phase 4 のレビュー対象にする。設計担当2 は設計上の追加確認が必要な場合だけ再開し、独立コードレビューなど他の役割へ流用しない。起動失敗や未完了を設計済みと扱わない。
+## 8. Phase 6: 実装後の確認
 
-### Phase 4: プランレビューと計画の簡素化
+同じ差分を固定し、選んだ担当を並行して起動する。実装者と独立したコードレビューは最低1体。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
 
-計画レビュー担当と計画簡素化担当（それぞれ担当1、2体の設定なら担当2 も）を、同じ計画で並行して起動する。
+| 観点 | 責任者と入力 |
+| --- | --- |
+| 設計適合性 | 設計担当1を再開。専任なしならメイン。計画・受入条件・責務・依存方向と実コードを照合 |
+| 独立コードレビュー | 新規の `shinaps-reviewer`。対象コード・全差分・利用側・規約・検証結果を読み、計画自体も誤りうるものとして正しさ・安全性・性能を確認 |
+| 規約照合 | 選んだrefine担当、専任なしならコードレビュー担当。規約全文・対象ファイル全文・変更範囲を照合 |
+| 実装の簡素化 | 選んだsimplifier、専任なしなら実装担当の自己確認に加えてコードレビュー担当。目的・契約を保って削除・統合できる内容を確認 |
 
-計画レビュー担当へ渡す情報:
+変更言語・領域・バージョンがPhase 2の規約の範囲を超えた分だけ取得を補い、同じ全文を渡す。staged・unstaged・untrackedを含めて対象を特定し、新規ファイルも確認する。設計担当1は自身の確認が終わるまで他担当の今回の結果を読まない。
 
-- タスクの目的・受入条件、Phase 2 の調査結果と規約全文
-- Phase 3 の計画全文（再策定時は最新案）
-- 「設計・要件・実装可能性・リスク・テスト戦略をレビューし、判定と具体的な修正案を返す。他のプランレビュー担当の結果は読まず、意見を交換しない」
+結果を `architecture-review.md` / `review-{round}-{n}.md` / `raw/refine-{round}.md` / `raw/simplify-{round}-{n}.md` に保存する。専任なしの確認は担当レポート内に責任者と範囲を残す。未確認部分があれば同じ担当へ戻し、全結果が揃ってから検証・統合する。
 
-計画簡素化担当へは、今回の目的・受入条件・最新計画・規約・調査結果・成果物パスを渡し、「計画の簡素化」として、仕様・状態・操作・実装方針から減らせるものだけを検討させる。
+## 9. 指摘の検証と統合（Phase 4・6共通）
 
-全担当へ同じ計画を渡し、他担当の今回の結果は読ませない。全担当の完了まで計画を変更しない。メインは `raw/plan-review-{round}-{n}.md` / `raw/plan-simplify-{round}-{n}.md` に全文保存する（round は 1 始まり、n は担当番号）。未完了は同じ担当へ戻す。
+指摘検証は、選んだ新規verifier、専任なしならメインが行う。全レポート全文・出典・確認範囲・要件・対象版・規約・検証結果を使い、根拠・誤認・重複・対立・未確認を区別する。元の項目を消さず出典IDを保持する。指摘なしの場合は担当の完了と確認範囲を確認し、空の検証のためだけに担当を起動しない。
 
-全結果が揃ったら、新しい verifier を起動して全結果を渡す（渡す内容は「指摘の検証」の節）。検証結果を `raw/plan-verification-{round}.md` に保存し、設計担当1 を「プラン統合」として再開する。設計担当1 は検証結果の全項目の採否・根拠と計画の修正案を返す。簡素化で機能・ユーザー体験・外部契約・受入条件が変わる提案は、変更点・失うもの・期待効果を示してメインからユーザーに確認する。承認前に計画へ採用しない。
+検証結果は `raw/plan-verification-{round}.md` または `raw/implementation-verification-{round}.md` に記録し、設計責任者へ全文を渡す。設計責任者が全項目の採否と理由、必要な計画修正・実装修正・検証を一つにまとめる。設計担当なしならメインが統合する。複雑な指摘や対立があれば `staffing.md` に従い担当を追加する。
 
-計画を変更する場合は設計担当1 が修正版を返し、メインが `raw/architect-revised-{round}.md` に保存する。同じ計画レビュー担当と計画簡素化担当へ同じ修正版・承認済み変更・前回の採否を渡し、再確認 → 新しい verifier → 設計担当1 を繰り返す。担当を再開できなければ同じ役割の担当へ引き継ぐ。他担当の今回の未確定結果は共有しない。
+統合は多数決ではなく根拠で行い、不確実な点は確認する。仕様・受入条件・ユーザー体験の変更や許可範囲の拡大は人の合意前に採用しない。verifierを置いた場合は全件の事実確認を最初からやり直さない。
 
-計画段階には回数上限を設けない。修正不要で、採用すべき指摘と必要な判断・確認が解決したら `plan.md` を確定し、Phase 5 へ進む。回数を埋める再確認や、新しい根拠のない却下案の再提案は行わない。委託不可なら制約と独立確認の未実施を明記する。
+## 10. Phase 7〜8: 修正と終了判定
 
-計画段階では refine を行わない。設計に関わる規約はプランレビューで確認し、コードの規約照合は実装後に行う。
+設計責任者の修正指示を同じ実装担当へ返し、変更と必要な検証を `fix-log.md` に記録する。修正不要ならPhase 9へ進む。
 
-### Phase 5: 実装
+実装後の全体レビューは初回を1として最大2ラウンド。1回目の後に修正したら、同じ最新差分でPhase 6の体制に必要な増員を加えて2回目を行い、検証・統合する。2回目の後に修正したら必要なテストを行い、3回目の全体レビューは起動せず、最終差分が再レビューされていないことを報告する。増員・交代・同じ対象の計画変更で上限をリセットしない。
 
-#### A. 引き継ぎ
+重大な未解決事項、必須検証の失敗、必要な担当の未完了が残れば品質上の完了とは報告しない。
 
-メインが `plan.md` を再読し、実装順を進捗の管理に展開する。実装担当を 1 体起動し、以下を渡す。
+## 11. Phase 9: 完了と引き渡し
 
-- タスクの目的・受入条件、確定した `plan.md` 全文
-- Phase 2 の調査結果と必読ファイル、Phase 4 のレビュー指摘と設計判断の理由
-- Phase 2 で取得した規約全文と、適用されるプロジェクト規約
-- 作業ディレクトリ、担当するファイル・責務、既存の未コミット変更、必要な検証
-- 「同じ作業ツリーには他の作業があるため、他者の変更を戻さず、現在の内容に合わせて実装する」
+初期体制と変更理由、実際の担当・確認範囲、計画と実装後のレビュー回数、採否・修正、検証結果、未実施・未照合・未解決事項を報告する。
 
-実装担当が作業している間は、メインも同じ範囲を編集しない。
+linear-executeから受けた作業は未コミットの差分と結果を進行役へ返す。devの完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)と[担当と工程](../linear/workflow.md)に従い、QA後のコミット依頼を受ける。
 
-#### B. 実装と確認
+単独のdevではコミットが許可されている場合だけ範囲とモードを `commit` へ渡す。許可がなければ未コミットで返し、形式的な許可確認を追加しない。PR・リリースも許可された範囲で各スキルへ渡す。単独devにLinear進行・新しいゴールを必須にしない。
 
-実装担当は確定した計画を実装し、セルフレビューの前に仕様を保つ簡素化と必要な検証を行う。メインは報告と実際の差分を確認し、完了した項目の進捗を更新する。
-
-目的・仕様を左右する不明点、計画と既存実装の不一致があれば、実装担当は変更を広げずメインへ返す。メインが既存の合意で解決できない点だけユーザーに一問ずつ確認し、決定を実装担当へ返す。計画から外れる場合は確認したうえで経緯を `implementation.md` に残す。通常の実装判断は既存規約に従って進める。
-
-実装担当の実装ミスによる検証失敗は 3 回まで自己修正する。それを超える場合はメインへ失敗の根拠と未解決点を返し、メインが「さらに修正試行 / Phase 6 のレビュー対象として差分を渡す / Phase 4 に戻って再策定する」をユーザーに確認する。
-
-#### C. 記録と検証
-
-メインが実装担当の報告を `implementation.md` に保存する。
-
-- 変更ファイルと変更内容、設計上の理由
-- 実装中の重要な判断、計画からの変更とその合意
-- 実行した検証コマンドと結果、未実施の確認
-- 残課題・規約衝突・未解決の論点
-
-必要な検証はプロジェクト規約・CI・変更の影響から決める。UIレビューはこの工程に含まれず、別の工程（linear-execute ではAgent QA）で行う。未実施のUIレビューを完了と報告しない。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
-
-### Phase 6: 実装後の4役割を並行実行
-
-実装と必要な検証が終わった同じ差分を固定し、次の4役割を並行して起動する。実装後のレビューラウンドは初回を 1 として数え、最大 2 回までとする。計画段階のプランレビューはこの回数に含めない。
-
-起動の前に、実際の変更ファイルの言語・領域・バージョンが Phase 2 で取得した規約の範囲に入るかを確認する。外れる分だけ Phase 2 と同じ条件で補って取得し、全担当へ同じ規約全文を渡す。
-
-| 役割 | 渡す情報 |
-|---|---|
-| 設計適合性（設計担当1 を再開） | 対象ファイルと差分（staged / unstaged / untracked を含む）、最終計画・受入条件・合意済み変更、実装報告と検証結果、規約全文 |
-| 独立コードレビュー（新規） | 同上と、下の「独立コードレビューの前提」 |
-| refine（1 体） | 規約全文と関連する `AGENTS.md`・`CLAUDE.md`・docs の該当節、対象ファイル一覧、リポジトリルートの絶対パス、変更範囲の確認コマンド（`git diff HEAD -- <path>`。未追跡ファイルは全行を変更扱い）、バッチID |
-| 実装の簡素化（新規） | 目的・受入条件・最終計画・維持する契約・対象ファイルと差分・規約全文 |
-
-独立コードレビューの前提: 計画を正しいと仮定せず、実コード・利用箇所・契約から不具合を確認する。計画と形式的に異なるだけでは不具合にしない。重要度・file:line・影響・根拠・修正案、確認済みと未確認の範囲を返す。設計適合性は設計担当1 の担当なので、ここでは計画との照合ではなくコードの正しさ・安全性・性能・保守性・規約を確認する。
-
-設計担当1 は自身の設計適合性レビューを確定するまで他担当の今回の結果を読まない。先に起動した担当の完了を待ってから次を起動するのではなく、4役割を起動してから結果を待つ。同じ担当を重複起動しない。対象が大きい場合は同じ担当を再開して続きのバッチを渡し、担当数や確認範囲を黙って減らさない。
-
-全担当は読み取り専用で、今回の他担当の結果を読まず、意見を交換しない。メインと実装担当も全結果が揃うまで対象を編集しない。途中で外部の変更が入った場合は、その影響範囲を最新の同じ差分で確認し直してから統合する。
-
-各担当の確認範囲・未完了報告を確認し、未確認部分は同じ担当へ戻す。失敗・未完了を「指摘なし」として処理しない。
-
-初回は `architecture-review.md` / `review.md` / `raw/refine.md` / `raw/simplify.md`、2回目は各ファイル名に `-2` を付けて保存する。4役割の全結果が揃ったら新しい verifier へ渡し、検証結果を `raw/implementation-verification-{round}.md` に保存する。検証完了後、設計担当1 を「指摘統合」として再開し、検証結果全文・原文への参照・差分の更新・検証結果・ラウンド番号を渡す。
-
-### 指摘の検証（Phase 4・6 共通）
-
-全担当の結果が揃ったら、新しい verifier を 1 体起動する。今回のレビューをした担当を流用しない。
-
-- 生レポート全文と原文のパス、各担当の確認範囲、目的・最新計画・受入条件・合意済み変更、対象コードと差分、検証結果、規約全文、ラウンド番号を渡す。
-- verifier が各指摘の根拠を検証して出典IDを保持し、重複・誤認・対立・未確認事項を整理する。
-- メインは出典の対応と完了状況を確認し、不足を同じ verifier へ戻す。検証不能は未確認として明示し、誤認も削除しない。失敗や未完了を検証済みとして先へ渡さない。
-
-### Phase 7: 設計担当1 が統合し、実装担当が修正
-
-設計担当1 が verifier の報告から全項目の採否を決め、対立・不確実性・設計上の重要点に必要な根拠を確認する。全件の事実確認を最初から繰り返さない。全指摘の採否と理由、採用した修正の対象・責務・具体的な変更・維持する契約・必要な検証を、一つの修正指示として返す。メインはそのまま記録し、仕様・受入条件の変更や未許可の範囲拡大が必要な点だけユーザーに確認する。通常の設計・修正判断をメインでやり直さない。
-
-修正不要なら Phase 9 へ進む。修正があれば、メインが同じ実装担当を再開し、設計担当1 の修正指示・確定した計画・現在の差分・規約・検証条件を渡す。再開できなければ実装履歴と採否を同じ役割の新しい担当へ引き継ぐ。設計担当1 は次のレビューに備えて継続し、コードを編集したり、実装担当を追加で起動したりしない。
-
-実装担当が修正と必要な検証を行い、変更・検証結果・未解決点を返す。メインは設計担当1 の採否と修正結果を `fix-log.md` に記録する。委託不可の場合はメインが同じ観点で対応し、独立した確認とは報告しない。
-
-### Phase 8: 最大2ラウンドで終了する
-
-- **1回目のレビュー後に修正した場合**: 修正後の同じ差分について、Phase 6 の4役割を2回目として並行実行する。最新の計画、前回の指摘と採否、修正内容、検証結果を渡す。全結果を新しい verifier で検証してから設計担当1 に渡し、Phase 7 で必要な最終修正を実施する。
-- **2回目のレビュー後に修正した場合**: 実装担当が最終修正と必要なテストを行ったら Phase 9 へ進む。3回目の実装後レビューは起動しない。
-- **修正不要の場合**: 回数を埋めるために再実行せず Phase 9 へ進む。
-
-最大2回は実装後の全体レビューに対する上限であり、担当の再開・交代や計画の変更でリセットしない。検証失敗・重大な未解決事項・未完了の担当が残る場合も追加ラウンドで無期限に続けず、その状態を明記してユーザーへ返す。未完了の確認を完了済みのラウンドと偽らない。
-
-### Phase 9: 完了と必要な引き継ぎ
-
-実施したレビュー回数、設計担当1 の判断と修正内容、検証結果、未解決事項を報告する。2回目の後に修正した場合は、その最終差分が再レビューされていないことを明記する。必須検証の失敗や重大な未解決事項があれば作業終了と品質上の完了を区別し、完了済みとは報告しない。
-
-Linearの開発進行から受けた実装・修正では、未コミットの差分と結果を進行役へ返す。dev完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)の継続許可と[担当と工程](../linear/workflow.md)に従い、QA後のコミット依頼を受ける。
-
-単独のdev依頼では、コミットが許可されていれば、その範囲と通常／自律モードを `commit` へ引き継ぐ。許可がなければ未コミットで結果を返し、毎回コミット許可を要求しない。PR・リリースも許可された範囲で `create-pr`・`release` へ渡す。単独利用にLinear進行や新しいゴールを必須にしない。
-
-## 5. 成果物
-
-```text
-.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/
-├── plan.md                    ← Phase 4 の全結果を検証・統合した最終 plan
-├── raw/
-│   ├── 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 の結果
-│   ├── plan-simplify-{round}-{n}.md ← 計画簡素化担当 n の結果
-│   ├── plan-verification-{round}.md ← 計画指摘の検証結果
-│   ├── implementation-verification-{round}.md ← 実装指摘の検証結果
-│   ├── refine.md              ← Phase 6 の規約照合の生レポート（2 回目は refine-2.md）
-│   ├── simplify.md            ← Phase 6 の実装の簡素化の生レポート（2 回目は simplify-2.md）
-│   └── architect-revised-{round}.md  ← 計画の修正版（round は 1 始まり）
-├── implementation.md          ← 実装ログ・変更ファイル一覧・動作確認結果
-├── architecture-review.md     ← 設計担当1 の設計適合性レビュー
-├── architecture-review-{n}.md ← 修正後の設計適合性レビュー（n は 2 始まり）
-├── review.md                  ← 独立コードレビューの生レポート
-├── review-{n}.md              ← 修正後の再レビュー（n は 2 始まり）
-└── fix-log.md                 ← 修正ループの履歴（修正があった場合のみ）
-```
-
-全担当の応答は全文を参照できる状態で保存する。担当は結果を文字列で返し、進行管理の成果物はメインが保存する。実装担当は担当範囲のコード・テスト・必要なドキュメントだけを編集する。
-
-## 6. 他スキルからの呼び出し
-
-explore・spec・review・debug などは、生成した成果物のパスを入口の引数に直接渡す。専用の引き継ぎファイルは作らない。受け取った成果物は Phase 1・2 のとおりに扱う。どの成果物を渡すかと、既定で使う入口は、元のスキルの引き継ぎの記述に従う。
+explore・spec・review・debugからの成果物は入口の引数で直接渡す。専用の引き継ぎファイルは作らず、Phase 1・2で既存成果物を再利用する。

package/plugins/shinaps-codex/references/human-review.md

@@ -0,0 +1,24 @@
+# 人レビューの差分提示
+
+人のコードレビューが必要な場合、またはコミット単位の承認を求める場合に使う。人レビューの要否・操作許可・コミットモードは、プロジェクト設定と今回の依頼に従う。この手順はそれらを変更しない。
+
+## 対象の準備
+
+レビュー対象のcheckoutの絶対パス、ブランチ、比較元のcommit、対象ファイルと完全な差分、検証結果を確定する。未追跡ファイルも対象に含める。stageは許可された範囲だけで行い、無関係な差分や既存のステージ境界を変更しない。対象差分と比較元は作業記録へ残し、後で承認対象と照合できるようにする。
+
+## CodexではPlasmaで開く
+
+人への窓口がCodexの場合は、実装担当がCodexかClaudeかによらず、レビューを依頼する会話でPlasmaを開く。人への窓口がClaudeの場合は既存の差分提示方法を使い、Plasmaのためだけに別のCodexタスクを作らない。
+
+1. 利用可能なPlasmaの`open_workbench`ツールと現在の入力仕様を確認する。ファイルを開く`route`が使える場合は、対象checkoutの絶対パスとレビュー対象のファイルを指定する。現在の形式は`/open?project=ABSOLUTE_PATH&file=RELATIVE_PATH&line=START&endLine=END`で、各値をURLエンコードする。存在するファイルを使い、適切なファイルがない場合はプロジェクト選択画面から対象checkoutを選ぶ。
+2. ファイルを開くことと差分を表示することを区別する。ファイル用routeに差分モードの未定義パラメーターを足さない。利用可能なUI操作ツールでPlasmaのGit画面を確認し、レビュー対象に合う比較を選ぶ。UI操作が使えない場合は、対象プロジェクト・比較方法・ファイル一覧を示して利用者に選択を依頼する。
+3. 表示中のcheckout・比較元・対象範囲をGitで確定した差分と照合する。ステージ済みの単位なら`git diff --cached`を基準にする。作業ツリー全体や別ブランチの差分を、その単位の差分として提示しない。対象全体を表示できない場合は、未表示の範囲を明示し、完全な差分を確認できる方法を利用者と決める。
+4. 会話に変更の目的、確認してほしい点、検証結果、対象単位を示し、修正指示またはレビュー完了を依頼する。Linear進行ではIssueも示す。Plasma内の注釈は指摘として扱い、画面を開いたことや操作の終了を承認とみなさない。
+
+Plasmaが未導入・起動失敗の場合は、その状態を伝え、Codexの差分表示など利用者が選んだ方法で同じ対象を提示する。無断でインストールや設定変更を行わず、表示できていないレビューを完了扱いにしない。
+
+## 承認後の照合
+
+利用者の明示的なレビュー完了を、対象単位と対応付けて記録する。修正した場合は必要な検証を行い、更新した差分を再提示して再確認を受ける。待機中に対象が変わった場合も、古い承認をそのまま適用しない。
+
+コミット直前に実際のコミット対象と承認対象の完全な差分を照合する。不一致ならコミットせず、変更後の対象を提示する。Plasmaを開くことはstage・commit・pushの許可を追加しない。具体的なコミット操作は`commit`に従う。

package/plugins/shinaps-codex/references/linear/codex-task.md

@@ -1,21 +1,21 @@
 # Codexの実装タスク
 
-`implementation_skill` が `dev-codex` または `dev-codex-ultra` の場合に使う。会話側のCodexがゴール・Linear・人への窓口・Agent QA・公開の進行を所有し、Issueごとの別のCodexタスクに実装を任せる。実装タスクは指定されたdevの入口でサブエージェントを使う。別タスクとdev内部のサブエージェントは別の役割である。
+`implementation_skill` が `dev-codex` の場合に使う。会話側のCodexがゴール・Linear・人への窓口・Agent QA・公開の進行を所有し、Issueごとの別のCodexタスクに実装を任せる。実装タスクは指定されたdevの入口でサブエージェントを使う。別タスクとdev内部のサブエージェントは別の役割である。
 
 ## 作成と再利用
 
 - 利用者の明示的な依頼または合意済みの `permissions: [codex_task, ...]` の範囲を確認する。ツールが利用者からの明示依頼を要求する場合はその条件も満たす必要があり、設定だけで迂回しない。必要な許可やツールがなければ開始前に止め、会話側での実装やCLIへの置き換えをしない。
 - 既存の同じIssueの実装タスクがあれば状態を読み直して再利用する。なければ `list_projects` で所属先を確認し、`create_thread` で新しいローカルCodexタスクを一つ作る。所属プロジェクトと実際の作業ディレクトリは一致を必須にしない。作業先が登録一覧にない場合も、利用者が指定した所属先を使い、対象checkoutの絶対パスを依頼に明記できる。実装担当は変更前に、指定先のGitルート・ブランチ・差分と適用される規約を確認し、以後の操作をその作業先で行う。指定先にアクセスできない場合は、別checkoutで代用せず必要な準備を報告する。会話全体をforkせず、実装に必要な情報だけを渡す。新しいworktreeは作らず、明示的に別途許可された場合だけ使う。
 - 返された確定済みthreadId・hostIdとIssue・checkout・branchをローカルの作業記録で対応づける。準備中のclientThreadIdを送信先にしない。作成結果が不明なときは一覧と状態を確認してから再試行する。
-- 同じIssueの質問回答・修正・許可されたコミット依頼は `send_message_to_thread` で同じタスクへ送る。モデルを利用者の指定なしに変更しない。dev内のモデル・役割構成は指定した入口に従う。
+- 同じIssueの質問回答・修正・許可されたコミット依頼は `send_message_to_thread` で同じタスクへ送る。モデルを利用者の指定なしに変更しない。dev内のモデルは起動手順に従い、役割構成は初期体制と途中の判断に従う。
 
 ## 実装依頼に渡すもの
 
-Issueリンク・範囲・受入条件・仕様や調査成果物、指定devスキル、Gitの絶対作業ディレクトリ・ブランチ・現在の差分、設定の保存方式・正本と必要な補足の所在、合意済みの操作許可とユーザーの委託許可、必要な検証、会話側のタスクIDを渡す。秘密値をプロンプトへ転記しない。
+Issueリンク・範囲・受入条件・仕様や調査成果物、指定devスキル、初期体制（役割別人数・根拠・専任なしの責任者・必須検証）、Gitの絶対作業ディレクトリ・ブランチ・現在の差分、設定の保存方式・正本と必要な補足の所在、合意済みの操作許可とユーザーの委託許可、必要な検証、会話側のタスクIDを渡す。秘密値をプロンプトへ転記しない。
 
 実装担当には次を明記する。
 
-> あなたはこのIssueの実装担当。指定されたdevスキルで実装・検証し、結果をこのタスクの最終回答へ返す。linear-executeを再起動せず、別の実装タスクや開発ゴールを作らない。dev内部のサブエージェントはdev_delegationの許可範囲で使う。仕様・権限の未決事項は質問として返し、人へ直接着手確認をしない。実装完了だけでコミット・push・公開・IssueのDone更新をしない。コミットは会話側からQA結果を伴う依頼を受け、必要な許可を確認して行う。単位案・判定・依頼・照合・報告は [共通手順](workflow.md#単位案からコミット完了まで)に従う。他の人・AIの差分を戻さない。
+> あなたはこのIssueの実装担当。指定されたdevスキルで実装・検証し、結果をこのタスクの最終回答へ返す。linear-executeを再起動せず、別の実装タスクや開発ゴールを作らない。dev内部のサブエージェントはdev_delegationの許可範囲で使う。初期体制を現物と照合し、途中の新しい根拠で必要な担当を追加して進行役へ報告する。仕様・権限の未決事項は質問として返し、人へ直接着手確認をしない。実装完了だけでコミット・push・公開・IssueのDone更新をしない。コミットは会話側からQA結果を伴う依頼を受け、必要な許可を確認して行う。単位案・判定・依頼・照合・報告は [共通手順](workflow.md#単位案からコミット完了まで)に従う。他の人・AIの差分を戻さない。
 
 ## 待機・QA・修正