@shinaps/skills 0.30.0 → 0.31.0

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

@@ -1,8 +1,13 @@
 ---
 name: commit
-description: 許可された差分を依存順のローカルコミットにし、各コミットを検証・レビューする。進め方（通常・自律）は各単位の実効方針か確認で決め、選択された範囲で実行する。
+description: 許可された差分を依存順のローカルコミットにし、各コミットを検証・レビューする。review_flow（auto・manual）は各単位の実効方針か確認で決め、選択された範囲で実行する。
 ---
 
+## 質問の実行経路（全工程に優先）
+
+対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
+
+
 ## 作業記録の保存先
 
 作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
@@ -21,7 +26,7 @@ description: 許可された差分を依存順のローカルコミットにし
 
 どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。
 
-Git操作と修正は現在のセッションが行う。独立レビューは利用可能かつ許可された場合に使う。指定のエージェントがなければ、その役割の観点でレビューする。独立レビューがプロジェクトの必須条件なのに実行できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
+AIが担当するGit準備・修正は現在のセッションで行い、manualのレビュー・修正・commitは人が行う。autoは独立レビューを必須とする。必要な担当・許可が利用できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
 
 ## 回復できる状態を作る
 
@@ -38,33 +43,26 @@ Git操作と修正は現在のセッションが行う。独立レビューは
 
 予定単位ごとに、[パス別の方針](../../references/linear/configuration.md#パス別の方針)でそのコミットの全変更を判定し、同資料の判定記録を残す。Linear進行から記録を受け取った場合は、設定とその単位の予定差分（内容・mode等を含む）の一致を確認して引き継ぐ。単独の依頼でも同じ判定を使い、Linear専用の工程は追加しない。設定が真にない単独依頼では、今回の明示許可とプロジェクト規約を通常方針とし、パス例外は適用しない。
 
-実効方針のAIコミット許可、人レビューの条件、別途必要なstageの許可を確認する。旧設定の移行・競合・不備は共通設定に従って依存工程を止める。
-
-単位の判定後に、その対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、[Linear共通設定の読み方](../../references/linear/configuration.md#設定の読み方)で正本を決めた `.shinaps/linear.yaml` の通常設定と適用されたパス別ルールから実効 `commit_mode` が `normal` または `autonomous` と決まれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linear-executeの開発進行では設定の不足・不正値を解消してから進む。linear-execute以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で対象単位を示して「このコミットはどちらで進めますか？」と一問だけ聞く。
-
-- **通常（推奨）**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
-- **自律**: その単位を検証・レビューして個別の承認を求めずコミットする。
-
-質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。別単位の選択は流用しない。同じ依頼内で通常・自律が混在してよい。合意して保存された通常設定またはパス別ルールの `commit_mode` は、その単位への適用結果を使う。その場の明示的な指定は設定に優先する。
+合意済みの実効 `review_flow` と今回の明示指示から進め方を確定する。両方とも対象のstageを許可し、`auto` ではAI、`manual` では人がcommitする。設定の存在だけを合意と扱わない。旧キー・不備・競合は共通設定に従って止める。
 
-設定項目の独立性と併せて読む条件は[Linear共通設定](../../references/linear/configuration.md)に従う。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
+設定がない単独依頼でも「各単位をAIがレビューして自動コミット」「人がレビューして自分でコミット」など明確な意図を引き継ぐ。「コミットして」「進めて」だけからautoを推測しない。flowが未解決のときだけ対象を示し「auto（AIがレビュー・コミット）とmanual（人がレビュー・修正・コミット）のどちらで進めますか？」と一問聞き、回答まで依存操作を待つ。未回答を承認と扱わない。同じ依頼内でもパス例外により異なるflowの単位があってよい。
 
-モード決定後にレビュー可能性や依存関係のため単位を分割・統合する場合は、[変更時の扱い](../../references/linear/configuration.md#判定記録と変更時の扱い)に従って変更した単位を再判定し、必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。「自律だからまとめる」「通常だから分ける」を先に適用して単位決定と判定を循環させない。
+モード決定後にレビュー可能性や依存関係のため単位を分割・統合する場合は、[変更時の扱い](../../references/linear/configuration.md#判定記録と変更時の扱い)に従って変更した単位を再判定し、必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。「autoだからまとめる」「manualだから分ける」を先に適用して単位決定と判定を循環させない。
 
 ## 単位ごとの検証・レビュー・コミット
 
-人レビューまたは通常モードの単位承認を依頼するときは、[人レビューの差分提示](../../references/human-review.md)に従う。CodexではPlasmaを開いてコミット対象と表示差分を照合する。Linear進行で同じ差分の人レビューが完了済みなら、その証拠を引き継ぎ、同じレビューを重ねて依頼しない。通常モードの単位承認は別の条件として扱う。
+manualでは[人レビューの差分提示](../../references/human-review.md)に従う。Claude経路ではWebStormで対象を提示し、Codex経路では既存の提示UIを使う。人がレビュー・修正・commitする工程をAIによる承認後commitへ置き換えない。
 
 以下を、その単位のモードで行う。
 
-1. 単位案を短く示す。通常モードで複数の単位に分ける場合、許可された独立レビュアーがいれば、各単位の差分だけで人が妥当性を判断できるかを差分自体から確認させ、結論はメインが実際の差分で検証する。自律モードでは単位案の独立レビューを求めない（プロジェクトの必須条件にある場合は従う）。
-2. コミットと検証の内容が単位だけで決まるようにする。通常モードでは、単位以外の未コミット変更（対象外、後続の単位、untracked）を一意な名前のstashへ退避し、作業ツリーとindexに単位の変更だけを残す。自律モードでは、対象外の変更を作業ツリーとindexに残してよく、検証結果が残る変更に依存しないことを根拠（例: 残る変更が検証の入力に含まれない）とともに判断する。依存する、または判断できない場合は、許可された範囲で単位をまとめ直すか、通常モードと同じ方法で退避する。退避が他の進行中の作業（他のセッションや人がステージ・編集中の変更）を妨げる場合は退避せず、所有者と調整できるまで止める。通常モードは別の隔離方法へ置き換えない。退避するときは、stashのindexにコミット対象のステージ済み変更を入れない。`git stash push` はパスを指定してもindex全体を保存し、対象のステージ済み変更が入ると後の `git stash apply --index` が失敗するため。対象のステージ済み差分のパッチを保存し、対象のステージを外してから退避し、退避後にそのパッチで対象のステージを戻す。作成前後のstash一覧を比べて今回作成されたものだけのSHAを記録し、既存stashの先頭を自分のものと決めつけない。共有ファイルのhunk分割は控えから行い、対象のhunkだけのステージを外せない場合や、対象外のステージ済みの変更が変わる場合は止める。
+1. 単位案を短く示す。manualで複数の単位に分ける場合、許可された独立レビュアーがいれば、各単位の差分だけで人が妥当性を判断できるかを差分自体から確認させ、結論はメインが実際の差分で検証する。autoでは単位案の独立レビューを求めない（プロジェクトの必須条件にある場合は従う）。
+2. コミットと検証の内容が単位だけで決まるようにする。manualでは、単位以外の未コミット変更（対象外、後続の単位、untracked）を一意な名前のstashへ退避し、作業ツリーとindexに単位の変更だけを残す。autoでは、対象外の変更を作業ツリーとindexに残してよく、検証結果が残る変更に依存しないことを根拠（例: 残る変更が検証の入力に含まれない）とともに判断する。依存する、または判断できない場合は、許可された範囲で単位をまとめ直すか、manualと同じ方法で退避する。退避が他の進行中の作業（他のセッションや人がステージ・編集中の変更）を妨げる場合は退避せず、所有者と調整できるまで止める。manualは別の隔離方法へ置き換えない。退避するときは、stashのindexにコミット対象のステージ済み変更を入れない。`git stash push` はパスを指定してもindex全体を保存し、対象のステージ済み変更が入ると後の `git stash apply --index` が失敗するため。対象のステージ済み差分のパッチを保存し、対象のステージを外してから退避し、退避後にそのパッチで対象のステージを戻す。作成前後のstash一覧を比べて今回作成されたものだけのSHAを記録し、既存stashの先頭を自分のものと決めつけない。共有ファイルのhunk分割は控えから行い、対象のhunkだけのステージを外せない場合や、対象外のステージ済みの変更が変わる場合は止める。
 3. コミットする内容に必要な検証を行う。後続や対象外の未コミット変更に依存した成功を、その単位の検証としない。範囲を限った検証はプロジェクトが認める場合だけ使い、必須検証を省かない。後続や対象外への依存で失敗するなら、手順2に戻って単位か隔離を見直す。
-4. 対象だけをステージし、実際にコミットされる差分の全体（indexのままコミットする場合は完全なcached diff）と影響するファイルをレビューする。indexに対象外の変更を残す場合は、それを含めずに対象だけをコミットする方法を使い、対象を限定できなければ止める。通常モードで提示する差分は、コミットされる差分と同じものにする。指摘は実物で確認し、依頼範囲の修正後は再ステージ・再検証する。外部仕様の調査は変更がそこに依存するときに行う。
-5. コミット直前の実差分がその単位の予定差分（パス・内容・mode等）と一致することを確認する。必須検証が通り、確定した阻害指摘がなく、通常モードなら単位の承認を得てから `git commit` を単独で実行する。メッセージはリポジトリ規約に従う。`git add` と連結しない。作成されたコミットの差分もその単位の予定差分と照合し、SHAと結果を記録する。後で相殺される対象外変更も許容しない。不一致なら次工程を止め、履歴を無断で書き換えない。
-6. 退避した場合は、コミット後または中断時に、indexにコミット対象のステージ済み変更がない状態で、記録したSHAのstashを `git stash apply --index` で戻す。中断時は対象のステージを外し、stashの復元を妨げる対象の未コミット変更（共有ファイルの対象のhunkなど）もパッチに保存して作業ツリーから一時的に外してから戻す。その後、外した対象の変更を戻し、対象のステージ済み差分のパッチで対象のステージを戻す。控えで扱った変更も復元し、コミット済みの変更を再び加えない。退避の有無によらず、コミットしていない変更（ステージ済み・未ステージ・untracked）と既存stashが、操作前の記録からコミットした内容を除いたものと一致することを確認する。一致しない、曖昧な競合がある、ステージ境界を戻せない場合は推測で消さず、一致しないパスと、退避した場合は回復資料を示して止める。一致を確認してから今回作成したstashだけをdropし、HEADを確認して次へ進む。
+4. 対象だけをステージし、実際にコミットされる差分の全体（indexのままコミットする場合は完全なcached diff）と影響するファイルをレビューする。indexに対象外の変更を残す場合は、それを含めずに対象だけをコミットする方法を使い、対象を限定できなければ止める。manualで提示する差分は、コミットされる差分と同じものにする。指摘は実物で確認し、依頼範囲の修正後は再ステージ・再検証する。外部仕様の調査は変更がそこに依存するときに行う。
+5. 必須検証と独立レビュー（auto必須）が通り、阻害指摘がないことを確認する。autoでは直前の全差分が予定単位と一致してからAIが `git commit` を単独実行する（`git add` と連結しない）。manualでは単位の差分・理由・検証結果・推奨メッセージを提示し、人がレビュー・必要な修正・commitを行い、その完了を知らせるまで待つ。AIは承認を受けても代わりにcommitしない。人の完了通知後に、比較元からの実コミット一覧と各SHA・全差分を調べ、通知された修正が許可された目的・範囲を満たすことを確認する。実差分で実効flowを再判定し、影響する挙動を再検証する。正当な人の修正は確定単位と全体の期待差分へ反映し、元の予定差分・完了通知・変更理由・実コミットとの対応を残す。本人が明示確認した修正という理由だけで新たな承認を求めない。意図や範囲が不明、対象外の混入、flowの適用が未解決なら人へ確認して止める。Gitにcommitがあるだけで人レビュー完了としない。各コミットを確定単位と照合してSHA・結果を記録し、不一致なら次工程を止める。履歴を無断で書き換えない。
+6. 退避した場合は、コミット後または中断時に、indexにコミット対象のステージ済み変更がない状態で、記録したSHAのstashを `git stash apply --index` で戻す。中断時は対象のステージを外し、stashの復元を妨げる対象の未コミット変更（共有ファイルの対象のhunkなど）もパッチに保存して作業ツリーから一時的に外してから戻す。その後、外した対象の変更を戻し、対象のステージ済み差分のパッチで対象のステージを戻す。復元前に人が修正した最新のHEAD・作業ツリー・indexを記録して保全する。控えで扱った対象外変更だけを復元し、古い対象パッチで人の修正を上書きしたり、コミット済みの変更を再び加えたりしない。退避の有無によらず、コミットしていない変更（ステージ済み・未ステージ・untracked）と既存stashが、操作前の記録と確定済みの人の修正からコミットした内容を除いたものと一致することを確認する。一致しない、曖昧な競合がある、ステージ境界を戻せない場合は推測で消さず、一致しないパスと、退避した場合は回復資料を示して止める。一致を確認してから今回作成したstashだけをdropし、HEADを確認して次へ進む。
 
-全単位の完了後、各単位の照合結果に加え、元の比較元からの全体差分が元の対象と一致し、対象の未コミット変更が残っていないことを確認する。最終差分だけで途中コミットの照合を代用しない。予定どおりのコミットによる残差分の減少は不一致と扱わない。
+全単位の完了後、各単位の照合結果に加え、元の比較元からの全体差分が、人の正当な修正を反映した確定済みの全体期待差分と一致し、対象の未コミット変更が残っていないことを確認する。最終差分だけで途中コミットの照合を代用しない。予定どおりのコミットによる残差分の減少は不一致と扱わない。
 
 ## 終了・中断
 

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

@@ -4,6 +4,11 @@ description: バグ報告・不具合の根本原因を多角的に調査し、
 argument-hint: <なし | エラーメッセージ / 症状の説明 | ファイルパス>
 ---
 
+## 質問の実行経路（全工程に優先）
+
+対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
+
+
 ## 作業記録の保存先
 
 作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
@@ -142,3 +147,5 @@ Skill(skill="shinaps:dev-claude", args="以下のデバッグ結果に基づき
 - **subagent は文字列応答のみ**: ファイル書き込みは必ずメインが担当
 - **生レポート保存厳守**: すべての subagent 応答を全文保存
 - **根本原因確定時に ローカル成果物（implementation.md / 調査・レビューレポート）**: 後の作業者と別 AI agent が辿れるように
+
+Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto経路は [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し、manual経路はWebStormのClaudeとBridgeを使う。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。

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

@@ -4,6 +4,11 @@ description: バグか確定していない違和感、既存挙動の「なぜ
 argument-hint: <調べたいバグ・挙動・実装上の疑問（省略可）>
 ---
 
+## 質問の実行経路（全工程に優先）
+
+対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
+
+
 ## 作業記録の保存先
 
 作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
@@ -213,3 +218,5 @@ dev の入口は「実装 handoff」の `status: ready` と `evidenceSnapshot`
 - **理解完了を代行しない**: 終了判定は人間が行う。回数制限を設けない
 - **生レポートを保存する**: subagent 応答は全文保存し、会話ログは要約だけ残す
 - **shinaps MCP はメインだけが呼ぶ**: subagent は `search_rules` / `list_search_facets` を直接呼ばない
+
+Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto経路は [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し、manual経路はWebStormのClaudeとBridgeを使う。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。

package/plugins/shinaps-claude/skills/linear-execute/SKILL.md

@@ -7,13 +7,17 @@ description: Linearの開発で、Codexから受けた実装・修正・コミ
 
 開発進行を依頼されたら、まず[設定の読み方](../../references/linear/configuration.md#設定の読み方)で作業先の設定を読み、`implementation_skill` で役割を決める。設定が真に未設定なら、下の「Codexの依頼なしで起動された場合」の初期設定へ進む。
 
-- Claudeの入口（`dev-claude`）では、Codexが進行・Agent QA・人への窓口を担当する。ClaudeはAI Terminal Bridge（以下Bridge）の受け手として、技術調査と実装・修正を担当し、「読む資料」「依頼を受けて実行する」「結果と人の対応を報告する」に従う。担当を入れ替えない。
+- Claudeの入口（`dev-claude`）では、Codexが進行・Agent QA・人への窓口を担当する。Claudeは基本flowに応じたCLIまたはAI Terminal Bridge（以下Bridge）の受け手として、技術調査と実装・修正を担当し、「読む資料」「依頼を受けて実行する」「結果と人の対応を報告する」に従う。担当を入れ替えない。
 - Managedの入口（`dev-managed-cc`）の開発進行では、Claudeが進行役になり、「Managedの入口で進行する」にだけ従う。
 - Codexの入口（`dev-codex`）では、開発進行をCodexへ引き渡す。
 
+## Claudeの実行経路を先に確定する
+
+基本 `review_flow: auto` はCodexが [Claude CLI](../../references/linear/claude-cli.md) を起動し、質問・修正・QA後のコミット依頼を同じsessionへresumeする。manualはWebStormのClaudeへBridgeで依頼し、人がレビュー・修正・commitする。初回実装前に経路と権限を確定する。パス例外はcommit担当にだけ反映し、実装経路を自動変更しない。manualのBridge不足でCLIへfallbackしない。以下のBridge固有の送受信手順はmanual経路に限り、autoの報告はCLI resultへ返す。
+
 ## 再確認せず進める条件
 
-Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridgeで受けたClaudeは、人へ着手を再確認せず、指定されたスキルで実行する。質問・相談・障害・完了はCodexへ返す。
+Codexから許可範囲と受入条件を伴う実装・修正の依頼をCLIまたはBridgeで受けたClaudeは、人へ着手を再確認せず、指定されたスキルで実行する。質問・相談・障害・完了はCodexへ返す。
 
 人のレビュー・コミット完了の報告をBridgeで受けたCodexは、報告の対象とGitの状態を照合し、一致すれば既存の許可の範囲で人へ再確認せず次の工程へ進む。
 
@@ -34,11 +38,11 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 - devの入口が利用者に確認する場面（計画の判断、不明点、承認）では、人ではなくCodexへ相談する。Codexが既存の合意で答えた内容を人へ再確認しない。仕様・受入条件・許可範囲の変更が必要な場合は、Codexが人に確認する。
 - QAで見つかった不具合の修正依頼も同じ扱いにし、人の着手許可を改めて取らない。
 - 同じ作業ツリーをCodexや人と同時に編集しない。人や他のAIの変更を保持する。
-- コミットの許可は[共通設定](../../references/linear/configuration.md)、担当とQA後の条件は[担当と工程](../../references/linear/workflow.md)の `code_review` に従う。実装完了の直後に先行してコミットせず、進行役へ結果を返す。条件を満たす依頼を受けたら `shinaps:commit` を使い、許可済みの操作を再確認しない。確認と承認の取り次ぎは同じ文書の「Bridgeでの依頼と報告」に従う。
+- コミットの許可は[共通設定](../../references/linear/configuration.md)、担当とQA後の条件は[担当と工程](../../references/linear/workflow.md)の `code_review` に従う。実装完了の直後に先行してコミットせず、進行役へ結果を返す。条件を満たす依頼を受けたら `shinaps:commit` を使い、許可済みの操作を再確認しない。質問の取り次ぎはautoならClaude CLI、manualなら同じ文書の「Bridgeでの依頼と報告」に従う。
 
 ## 結果と人の対応を報告する
 
-- 完了の報告と、人のレビュー・コミット完了の報告に含める項目は、[references/workflow.md](../../references/linear/workflow.md) の「Bridgeでの依頼と報告」に従う。
+- 完了の報告と、人のレビュー・コミット完了の報告に含める項目は、[references/workflow.md](../../references/linear/workflow.md) に従う。autoでは [Claude CLI](../../references/linear/claude-cli.md) のresultへ返し、manualではBridgeで返す。
 - 人へ着手の確認やコミットの依頼をしない。人がClaudeへ直接伝えた指示や結果は保持し、Codexへ報告する。Gitにコミットがあるだけで、人のレビュー済みと報告しない。設定で人のレビューを省略した場合は、省略と報告する。
 
 ## Managedの入口で進行する
@@ -58,7 +62,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 | QAの実施・記録・素材 | [references/qa.md](../../references/linear/qa.md) |
 | Cycle完了QA・報告 | [references/cycle-report.md](../../references/linear/cycle-report.md) |
 
-コミットは `shinaps:commit`、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、Claudeが自分で行う。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで続ける。
+コミットは `shinaps:commit`、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、進行役のClaudeが行う。コミットはautoならAI、manualなら人が行う。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで続ける。
 
 ## Codexの依頼なしで起動された場合
 
@@ -66,7 +70,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 
 - 利用者から直接依頼された実作業（開発進行の依頼を除く）は、着手前に [references/issue.md](../../references/linear/issue.md) の「着手前に作業をIssueへ紐づける」に従う。Issueの作成は利用者がその場で依頼した場合だけ行い、設定の `issue_update` を根拠にしない。
 - 利用者から明示的にIssueの整理を依頼された場合は、[references/issue.md](../../references/linear/issue.md) に従って整理する。Issueの更新は、依頼で指定された範囲だけにする（設定の有無にかかわらない）。
-- 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、設定の `implementation_skill` がManagedの入口なら「Managedの入口で進行する」に従う。それ以外の入口ではClaudeは進行役を兼ねない。[設定の読み方](../../references/linear/configuration.md#設定の読み方)で真に未設定と確認した場合だけ、同じセッションで `shinaps:linear-plan` の初期設定ヒアリングに進み、保存・確認後に元の依頼の引き渡しへ戻る。作業先リポジトリの設定で `bridge_request` が許可され、BridgeでCodexのセッションを特定できる場合は、[references/workflow.md](../../references/linear/workflow.md) の「開発進行の引き渡し」の項目を添えてCodexへ引き渡す。設定は [references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従って読む。許可や相手のセッションがない場合は、必要な準備（設定、Codexセッションの起動、Bridgeの導入）を利用者へ案内する。
+- 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、設定の `implementation_skill` がManagedの入口なら「Managedの入口で進行する」に従う。それ以外の入口ではClaudeは進行役を兼ねない。[設定の読み方](../../references/linear/configuration.md#設定の読み方)で真に未設定と確認した場合だけ、同じセッションで `shinaps:linear-plan` の初期設定ヒアリングに進み、保存・確認後に元の依頼の引き渡しへ戻る。作業先リポジトリの基本flowがautoならCLIを起動するCodex側へ依頼内容を返して開始を案内する（Bridgeは要求しない）。manualで `bridge_request` が許可され、BridgeでCodexのセッションを特定できる場合は、[references/workflow.md](../../references/linear/workflow.md) の「開発進行の引き渡し」の項目を添えてCodexへ引き渡す。設定は [references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従って読む。許可や相手のセッションがない場合は、必要な準備（設定、Codexセッションの起動、Bridgeの導入）を利用者へ案内する。
 
 ## 初期体制と途中の増員
 

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

@@ -4,6 +4,11 @@ description: 差分・PR・既存コードをレビューし、指摘の検証
 argument-hint: <なし | PR番号 | ファイル/ディレクトリパス>
 ---
 
+## 質問の実行経路（全工程に優先）
+
+対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
+
+
 ## 作業記録の保存先
 
 作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
@@ -144,3 +149,5 @@ Skill(skill="shinaps:dev-claude", args="以下のレビュー指摘を修正す
 - **PR コメント投稿は要承認**: 外部影響のある操作は必ず本文確認
 - **diff が空ならエラー終了**: 何もしない旨を明示
 - **テストの判断**: [テスト方針](../../references/testing.md) に従う
+
+Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto経路は [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し、manual経路はWebStormのClaudeとBridgeを使う。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。

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

@@ -4,6 +4,11 @@ description: 大まかな要望を入力に、対話的なヒアリング + 既
 argument-hint: <大まかな要望（省略可）>
 ---
 
+## 質問の実行経路（全工程に優先）
+
+対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
+
+
 ## 作業記録の保存先
 
 作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
@@ -203,3 +208,5 @@ Skill(skill="shinaps:dev-claude", args="以下の仕様書を実装する。詳
 - **subagent は文字列応答のみ**: ファイル書き込みは必ずメインが担当
 - **フィジビリティ調査は spec で済ませる**: dev での差し戻しを減らすため、Phase 3/4 の調査を惜しまない
 - **rule カタログを制約に反映**: `search_rules` 結果を spec.md の制約セクションに集約
+
+Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto経路は [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し、manual経路はWebStormのClaudeとBridgeを使う。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。

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

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

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 は一切行わない"
+description = "shinaps:commit のmanualで、人が単位ごとにレビュー・修正・コミットする前に分割計画を確認するレビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の 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` のmanualで、人が単位ごとにレビュー・修正・コミットする前に分割計画を確認するレビューエージェントです。\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/references/dev/workflow.md

@@ -105,7 +105,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 初期体制と変更理由、実際の担当・確認範囲、計画と実装後のレビュー回数、採否・修正、検証結果、未実施・未照合・未解決事項を報告する。
 
-linear-executeから受けた作業は未コミットの差分と結果を進行役へ返す。devの完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)と[担当と工程](../linear/workflow.md)に従い、QA後のコミット依頼を受ける。
+linear-executeから受けた作業は未コミットの差分と結果を進行役へ返す。devの完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)と[担当と工程](../linear/workflow.md)に従い、QA後のcommit工程の依頼を受け、autoはAIコミット、manualは人への提示準備を行う。Claudeのauto経路は [Claude CLI](../linear/claude-cli.md) のresultへ報告し、同じsessionのresumeで質問・修正を受ける。manual経路はBridgeで返す。Codex・Managedはそれぞれの既存返却経路を使う。
 
 単独のdevではコミットが許可されている場合だけ範囲とモードを `commit` へ渡す。許可がなければ未コミットで返し、形式的な許可確認を追加しない。PR・リリースも許可された範囲で各スキルへ渡す。単独devにLinear進行・新しいゴールを必須にしない。
 

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

@@ -1,6 +1,8 @@
 # 人レビューの差分提示
 
-人のコードレビューが必要な場合、またはコミット単位の承認を求める場合に使う。人レビューの要否・操作許可・コミットモードは、プロジェクト設定と今回の依頼に従う。この手順はそれらを変更しない。
+manualで人がレビュー・修正・commitする場合に使う。review_flow・操作許可は、プロジェクト設定と今回の依頼に従う。この手順はそれらを変更しない。
+
+Claude経路のmanualはWebStormでレビューする。Plasmaを必須にしない。以下のCodex UI手順はCodex経路に適用する。
 
 ## 対象の準備
 
@@ -8,17 +10,19 @@
 
 ## CodexではPlasmaで開く
 
-人への窓口がCodexの場合は、実装担当がCodexかClaudeかによらず、レビューを依頼する会話でPlasmaを開く。人への窓口がClaudeの場合は既存の差分提示方法を使い、Plasmaのためだけに別のCodexタスクを作らない。
+Codex実装経路で人への窓口がCodexの場合は、レビューを依頼する会話で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内の注釈は指摘として扱い、画面を開いたことや操作の終了を承認とみなさない。
+4. 会話に変更の目的、確認してほしい点、検証結果、対象単位を示し、レビュー・必要な修正・コミット完了を依頼する。Linear進行ではIssueも示す。Plasma内の注釈は指摘として扱い、画面を開いたことや操作の終了を承認とみなさない。
 
 Plasmaが未導入・起動失敗の場合は、その状態を伝え、Codexの差分表示など利用者が選んだ方法で同じ対象を提示する。無断でインストールや設定変更を行わず、表示できていないレビューを完了扱いにしない。
 
-## 承認後の照合
+## 人のレビュー・コミット完了後の照合
+
+利用者の明示的なレビュー・修正・コミット完了通知を、対象単位と対応付けて記録する。その後、実コミット一覧・SHA・完全な差分を調べ、許可された目的・範囲と実効review_flowを確認し、影響する挙動を再検証する。Gitにcommitがあるだけでは完了としない。
 
-利用者の明示的なレビュー完了を、対象単位と対応付けて記録する。修正した場合は必要な検証を行い、更新した差分を再提示して再確認を受ける。待機中に対象が変わった場合も、古い承認をそのまま適用しない。
+本人が明示確認した正当な修正は確定単位と全体期待差分に反映する。元の予定差分を保持し、完了通知・修正理由・確定差分・実コミットの対応を記録する。その修正だけを理由に再提示・再承認を要求しない。目的や範囲が不明、対象外変更が混入、適用flowが未解決の場合は人へ確認し、次工程を止める。最終照合は確定済みの期待差分を使い、元の差分との機械的な一致を要求しない。
 
-コミット直前に実際のコミット対象と承認対象の完全な差分を照合する。不一致ならコミットせず、変更後の対象を提示する。Plasmaを開くことはstage・commit・pushの許可を追加しない。具体的なコミット操作は`commit`に従う。
+stashの復元では人の修正を保持し、古い対象パッチで上書きしない。具体的な単位照合・復元は `commit` に従う。表示UIを開くことはstage・commit・pushの許可を追加しない。

package/plugins/shinaps-codex/references/linear/claude-cli.md

@@ -0,0 +1,37 @@
+# ローカルClaude CLIによる実装
+
+`dev-claude` の基本 `review_flow: auto` は、Codexが作業先でローカル `claude -p` を起動する。manualはWebStormのClaudeとBridgeを使う。初回実装前に基本flow、正確なcheckout・branch・HEAD・既存差分、経路許可（autoは `claude_cli`、manualは `bridge_request` または今回の明示依頼）を確定する。manualのBridge不足でCLIへfallbackしない。CodexとManagedの既存経路は変更しない。
+
+パス例外はコミット単位のreview_flowだけを変え、実装経路を途中で切り替えない。CLI経路でmanual単位になった場合は、CLIの実行終了を確認して同じcheckoutをWebStormで人へ提示する。Codexが人のレビュー・修正・commit完了を受け取り、単位差分・SHAと照合する。その後の実装依頼は変更後のHEADと差分を添えて同じCLIセッションをresumeする。Bridge経路のauto単位も同じBridgeセッションでQA後にcommitを依頼する。
+
+## 起動と観測
+
+通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。model・effort・plugin構成を指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作の権限が許可されることは別である。
+
+依頼本文を作業記録のpromptファイルへ保存し、stdinで渡す。本文をshellへ展開しない。以下は絶対パスを今回の記録先に置き換え、コマンドのcwdを確定済みcheckoutへ指定して実行する例。毎回異なる出力名を使い、既存記録を上書きしない。必要なSkill/Agent・Read/Edit・検証コマンド等の `--allowedTools` は依頼の許可と範囲から個別に追加する。たとえばcommit段階の `Bash(git add <対象パス>)` と `Bash(git commit -m <確定メッセージ>)` は実際の引数に限定し、初回実装にはcommit権限を渡さない。広範な既存allow設定がある場合も対象外操作の許可とは扱わない。
+
+```sh
+claude -p --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
+```
+
+途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue、出力パスを記録する。実行中は同じprocessを短い待機（最大60秒）で観測し、終了コードを取得する。新しいCLIを並行起動せず、進捗を会話へ返す。stream-jsonはイベントを読み、最終resultがない途中出力を完了と扱わない。
+
+jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、stream-jsonではsession初期化と最終resultを照合する。session_idをIssueとcwdに紐づけてローカル作業記録に保持する。終了コード0だけで成功にせず、エラー・拒否・質問・成果を確認して実差分と検証結果を独立QAする。ID欠落、異常終了、出力欠落なら停止してprocessと記録を調べる。結果不明のまま新規セッションを起動したり同じ依頼を再送したりしない。
+
+## 依頼・質問・修正・コミット
+
+promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、初期体制、exact cwd・branch・HEAD・既存差分、許可・禁止操作、規約と参照先、返却条件を含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。CLIからBridge送信や人の対話入力を待たせない。
+
+回答・QA修正・QA後のautoコミット依頼は、元のprocess終了後、記録済みの正確なIDで同じセッションをresumeする。`--continue` で別セッションを推測しない。
+
+```sh
+claude -p --resume '<recorded-session-id>' --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/follow-up.txt > /absolute/work/follow-up-result.json 2> /absolute/work/follow-up-stderr.log
+```
+
+resumeにも同じcwdと許可境界を指定し、外部で変化したHEAD・差分を渡す。commit依頼にはLocal Agent QA結果、独立レビュー、単位案と全差分、実効review_flowと合意根拠を含める。完了報告は変更範囲、検証、未解決事項、単位案、commitした場合はSHA・単位照合・残差分・stash復元結果を含める。復帰不能時は理由を報告し、黙って別sessionに作り直さない。
+
+## 操作権限
+
+`review_flow: auto` はClaudeの `--permission-mode auto` を意味しない。非対話起動では `--permission-mode dontAsk` を明示し、既存設定がbypassでも継承しない。model・effort・pluginsは保持し、操作許可は既存の個別allow設定と今回の範囲に限定する。`--permission-prompts none` は対話できないpromptを拒否として返すためであり、許可を付与しない。permission_denialsがあれば操作と必要な権限を報告し、既存の明示許可が対象を満たすか確認する。満たす場合だけ必要なSkill/Agentや対象を限定した `--allowedTools` を明示し、同じsessionへ明示的に再依頼する。新しい権限が必要ならCodexが人へ確認する。`--allowedTools` を使う場合も対象・操作に限定し、無条件の `Bash(*)`、bypassPermissions、dangerously-skip-permissionsを使わない。拒否を隠すsilent retryをしない。会話上の許可はCLIの権限チェックを消さない。
+
+CLI仕様の参照: [headless](https://code.claude.com/docs/en/headless)、[CLI reference](https://code.claude.com/docs/en/cli-reference)。利用版で必要なflagが非対応なら状態を報告して停止し、権限回避へ切り替えない。

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

@@ -43,7 +43,7 @@
 - 終了地点は操作の許可を兼ねない。設定は、利用中のツールの権限や利用者の明示的な停止・撤回を上書きしない。
 - 利用者と合意して保存した設定の許可は、その対象・操作・条件の範囲で、作業先リポジトリの規約がいう合意・許可に当たる。一般的な「明示依頼がある場合だけ」という条件も、この合意済みの範囲では満たすため、同じ操作の許可を改めて求めない。設定ファイルが存在することや、AIが合意なしに加えた許可は、その根拠にしない。利用者による今回の範囲限定・停止・撤回と、ツール固有の明示依頼条件は維持する。
 
-次工程を判断するときは、独立した `commit_mode`・`permissions`・`stop_after`・人レビューの条件を併せて読み、[担当と工程](workflow.md)で定めた担当と前工程の結果を確認する。一つの設定から他の許可や工程の完了を推測しない。終了・待機とゴール状態は [execution.md](execution.md) に従う。
+次工程を判断するときは、`review_flow`・`permissions`・`stop_after` の条件を併せて読み、[担当と工程](workflow.md)で定めた担当と前工程の結果を確認する。一つの設定から他の許可や工程の完了を推測しない。終了・待機とゴール状態は [execution.md](execution.md) に従う。
 
 ## 項目
 
@@ -61,14 +61,13 @@
 | `permissions` | 継続的に許可した操作の一覧（下の「許可」）。許可なしは `[]` |
 | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
 | `cycle_report` | Cycle報告の設定（下の「Cycle報告」）。報告を使わない場合は `null` |
-| `implementation_skill` | Issueの実装・修正に使うruntimeの入口。担当数は固定せずメインが作業ごとに決める。`dev-claude`（CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する）、`dev-codex`（Issueごとの別Codexタスクがその入口を実行し、会話側は進行・Agent QAを担当する）、または `dev-managed-cc`（linear-executeを実行する会話が進行役になり、IssueごとのClaude Managed Agentsセッションのleadがその入口で実装する） |
-| `commit_mode` | `shinaps:commit` でコミットするときの進め方。`normal`（単位ごとに承認を得る）または `autonomous`（個別の承認なしで単位ごとに検証してコミットする） |
-| `human_code_review` | 人のコードレビューの要否。`required`（人がレビューする）または `skip`（人のレビューを行わない） |
-| `path_policy_overrides` | パス別に人レビュー・AIコミット許可・コミットの進め方を上書きするルールの一覧。例外なしは `[]`。既存設定で欠落していれば例外なし（下の「パス別の方針」） |
+| `implementation_skill` | Issueの実装・修正に使うruntimeの入口。担当数は固定せずメインが作業ごとに決める。`dev-claude`（基本 `review_flow` がautoならCodexがローカルClaude CLI、manualならWebStormのClaudeへBridgeで依頼する）、`dev-codex`（Issueごとの別Codexタスクがその入口を実行し、会話側は進行・Agent QAを担当する）、または `dev-managed-cc`（linear-executeを実行する会話が進行役になり、IssueごとのClaude Managed Agentsセッションのleadがその入口で実装する） |
+| `review_flow` | `auto`（AIが自然な単位を決め、独立レビュー・QA後にstage・commit）、`manual`（AIが単位を計画し、単位外を安全にstashしてstage・提示、人がレビュー・修正・commit） |
+| `path_policy_overrides` | パス別に `review_flow` を上書きするルールの一覧。例外なしは `[]`。既存設定で欠落していれば例外なし（下の「パス別の方針」） |
 
-- `commit_mode` は進め方の設定であり、コミットの許可ではない。コミットは利用者の明示的な依頼、`permissions` の `commit`（条件は下の「許可」）、または適用されたパス別の `ai_commit: allow` に従う。`commit_mode` があるだけではコミット・pushを始めず、人のレビュー済みと推測しない。その場の明示的な指定は設定に優先する。`normal` は人が自分でgit操作をする工程（`code_review`）とは別のもの。
+- 利用者と合意した `review_flow` は両方とも対象のstageを許可し、`auto` だけAIのcommitも許可する。`manual` のcommitは人が行う。未合意の設定ファイルから許可を得ない。その場の明示指示が優先し、push・公開・履歴変更は別の許可に従う。
 - `implementation_skill` が決めるのは、実装・修正の担当と実行方式だけである。`permissions`・`stop_after`・人レビュー・コミットの方針と、`dev_delegation`・worktreeの作成・別セッションの作成の許可を変えない。その場の明示的な指定は設定に優先する。既存の設定にキーがなくても、自動で書き加えない。担当と工程の対応は [workflow.md](workflow.md) の「担当と窓口」にある。
-- `human_code_review: skip` は人のレビューの工程だけを省く。devの入口内のレビュー、検証、Agent QA、必要なHuman QAは省かない。省略は、人のレビュー済みとして記録しない。人レビュー・AIコミット許可・`stage`・`commit_mode` は互いに独立しており、一つから他を推測しない。
+- どちらのflowもdev内の確認、必須検証、Agent QA、必要なHuman QAを維持する。`auto` は独立レビューを必須とし、利用できなければ自己確認で代用せず止める。人レビュー省略を人のレビュー済みと記録しない。
 - 工程キーは [workflow.md](workflow.md) の工程表と同じ。`statuses` の値はチームに実在する正確な名前にする。操作時はLinearから取得した状態のIDを使う。対応が曖昧・欠落・実物と不一致なら、その対応に依存する更新を止める。ステータスを自動で新設しない。
 - `team_settings: manage_on_setup` の場合も、通常実行ではチーム設定を変更しない。
 
@@ -79,13 +78,11 @@
 ```yaml
 path_policy_overrides:
   - paths: ["docs/**", "README.md"]
-    human_code_review: skip
-    ai_commit: allow
-    commit_mode: autonomous
+    review_flow: auto
 ```
 
-- `paths` は空でないパターン一覧を必須とする。`human_code_review`（`required` / `skip`）、`ai_commit`（`allow` / `deny`）、`commit_mode`（`normal` / `autonomous`）は少なくとも一つ指定し、省略項目は通常設定を継承する。不正な値や構文は設定不備として依存工程を止める。
-- `ai_commit` の継承元は通常のコミット許可。`allow` はそのコミットのAIによる実行を認め、`deny` はそのコミットに対する継続的なコミット許可を取り消す。今回の利用者の明示指示を優先する。どちらも `stage` の許可を兼ねない。push・公開・終了地点・ツール権限や必要なQAも変更しない。
+- 各ルールは空でない `paths` と `review_flow: auto | manual` だけを必須とする。その他のキー、省略、不正値や構文は設定不備として依存工程を止める。
+- パス別のflowもstageとcommit担当を上記のとおり決める。push・公開・終了地点・ツール権限・必要なQAは変更しない。実装開始時のClaude通信経路は基本flowで固定し、パス例外では切り替えない（[Claude CLI](claude-cli.md)）。
 - パス設定への合意は対象と工程の許可であり、変更内容に含まれる未合意仕様や権限拡張への承認ではない。内容や拡張子から例外許可を推定しない。
 
 ### パターンとコミット全体の照合
@@ -95,17 +92,19 @@ path_policy_overrides:
 各予定コミットの全変更に現れる旧・新パスが、一つのルールのパターン一覧で覆われる場合だけ、そのルールをそのコミット全体へ適用できる。追加は新パス、削除は旧パス、改名・移動は両方を含め、modeだけの変更も対象にする。新パスだけの一覧や現在残っているファイルだけでは判定しない。
 
 - コミット全体に適用できるルールがなければ、そのコミット全体を通常方針とする。複数ルールをファイル別・項目別に合成しない。
-- コミット全体に適用できるルールが複数ある場合、通常設定を継承した後の3項目がすべて同じならその方針を採用し、適用した全ルールを記録する。一つでも結果が異なれば依存工程を止めて競合の解消を求める。並び順やパターンの詳細度では優先しない。
+- コミット全体に適用できるルールが複数ある場合、`review_flow` が同じならその方針を採用し、適用した全ルールを記録する。一つでも結果が異なれば依存工程を止めて競合の解消を求める。並び順やパターンの詳細度では優先しない。
 - モードによらず自然な責務単位を先に決め、その予定コミットごとに判定する。同じ依頼に別の変更があっても、独立した範囲内コミットには例外を適用できる。例外取得だけを目的とした恣意的な分割はしない。依頼全体は網羅性と最終照合に使い、方針を固定する単位にはしない。
 
 ### 判定記録と変更時の扱い
 
-各予定単位について、設定の正本と内容、適用した全ルール（または適用なしの理由）、単位の比較元と全差分、継承後の実効3項目、今回の明示指示、`stage` の許可、検証・レビューの結果を記録する。差分の同一性はパスだけでなく内容・mode等も含めて確認する。Linear進行での担当間の引き渡しは [workflow.md](workflow.md)、コミット前後の単位照合と完了時の全体照合は `commit` に従う。
+各予定単位について、設定の正本と内容、適用した全ルール（または適用なしの理由）、単位の比較元と全差分、実効 `review_flow`、今回の明示指示とflowの合意根拠、検証・レビューの結果を記録する。差分の同一性はパスだけでなく内容・mode等も含めて確認する。Linear進行での担当間の引き渡しは [workflow.md](workflow.md)、コミット前後の単位照合と完了時の全体照合は `commit` に従う。
 
-予定単位の内容・分割・統合を変更したら、変更した単位を再判定して必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。以前の判定や別単位の方針は流用しない。実コミットが予定と異なれば停止し、履歴を無断で書き換えない。
+予定単位の内容・分割・統合を変更したら、変更した単位を再判定して必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。以前の判定や別単位の方針は流用しない。manualで人が修正・commitした場合は `commit` に従い、完了通知後に目的・範囲・実効flowと影響する挙動を確認する。正当な修正は元の予定との差と対応を残して確定単位へ反映する。不明・対象外の変更、確定単位との不一致は停止し、履歴を無断で書き換えない。
 
 ### 旧設定の移行
 
+`human_code_review`・`commit_mode`・`permissions` の `stage` / `commit`・パス別 `ai_commit` は廃止。新キーと共存していても依存工程を止め、利用者と `review_flow` と必要な経路権限への移行を明示合意して旧キーを除く。旧値の組合せを暗黙にauto/manualへ変換しない。
+
 `document_only_changes: none` は例外なしとして読めるため、自動変更や再合意は不要。旧 `document_only_changes: ai_commit` は廃止し、新設定と共存していても依存工程を止める。具体的なパスと上書き項目への移行、または例外廃止を利用者と合意してから旧キーを除く。説明だけの変更の許可とパスの許可は同値ではないため、自動変換・二重運用をしない。既存プロジェクトへ例外許可を自動追加しない。
 
 ## 終了地点
@@ -119,7 +118,7 @@ path_policy_overrides:
 | `issue_done` | Issueの必須受入条件をすべて満たし、Doneにした時点 |
 
 - 終了地点の工程がそのIssueにない場合（Git変更がない作業など）の扱いは、[workflow.md](workflow.md) の「工程とステータス」に従う。
-- 終了地点は到達点だけを決める。途中の操作は `permissions` が決める。許可のない操作（例 `merge`）がある場合は、その操作の前で許可を確認する。これは許可待ちであり、終了地点への到達ではない。Cycle全体を任された場合も、許可待ちのIssueは終了地点に達したものとして扱わない。
+- 終了地点は到達点だけを決める。stage・commitは合意済み `review_flow`、その他の操作は `permissions` が決める。許可のない操作（例 `merge`）がある場合は、その操作の前で許可を確認する。これは許可待ちであり、終了地点への到達ではない。Cycle全体を任された場合も、許可待ちのIssueは終了地点に達したものとして扱わない。
 
 ## 許可
 
@@ -128,10 +127,9 @@ path_policy_overrides:
 | `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
 | `development_operations` | 任された対象の開発に必要な、既存アカウントへの通常のログイン、ローカル環境準備、プロジェクトの依存導入、開発サーバー・Simulatorの起動停止、ビルド・テスト・QA操作を継続的に許可する。下の範囲に従う |
 | `codex_task` | 対象IssueごとのCodex実装タスクの新規作成・状態確認・実装や修正や許可済みコミットの依頼。アーカイブ、worktree作成、操作許可の追加、タスク側でのゴールや実装タスクの再作成は含めない。ツールの明示依頼要件も満たす。アーカイブの合意と手順は [完了後の整理](codex-task.md#完了後の整理) に従う |
+| `claude_cli` | auto ClaudeのローカルCLI起動、同じsessionの状態・結果取得、質問への回答・修正・許可済みコミットのresume。既存CLI設定と個別の操作権限を維持する（[手順](claude-cli.md)） |
 | `bridge_request` | BridgeによるCodexからClaudeへの実装・修正の依頼と、ClaudeからCodexへの開発進行の引き渡し |
 | `managed_session:<USD>` | 対象IssueごとにClaude Managed Agentsのセッションを作り、同じIssueのコミット前のQA修正には続けて使う（コミット後の修正は新しいセッションで行う。扱いは[Managedセッション](managed-session.md)の「QAと修正」に従う）。`<USD>` は1セッションの予算の上限で、正の整数のUSD（作成時にセントへ換算する）。値がない、または正の整数でない場合は設定不備として止める。含める操作: 作業先のコミット済みの内容（git bundle）と、あれば `~/.claude/CLAUDE.md` のFiles APIへのアップロード、上限内での予算の設定、一覧から名前で一件に特定したvaultの受け渡し、状態・イベント・出力の取得、回答と修正依頼の送信、取得した差分の作業先への適用と作業記録の展開。含めない操作: 上限を超える予算の引き上げ（その場で確認する）、セッションとファイルのアーカイブ・削除、定義のapply、vaultの作成・変更 |
-| `stage` | レビュー・コミットの対象差分だけをステージする |
-| `commit` | 対象Issueの差分を、Local Agent QAの合格と `human_code_review` に従った工程の後に、`shinaps:commit` でローカルにコミットする。AIのコミットには `stage` の許可も併せて必要。push・PR・履歴の書き換え、人のレビューの省略を含めない。パス別の `ai_commit` を含む実効方針に従う（上の「パス別の方針」） |
 | `push` | 対象Issueの作業ブランチの通常のpush |
 | `pr_create` | 対象IssueのPRの作成と更新 |
 | `merge` | 必要なQA・承認が揃った対象PRのマージと、元のブランチへ戻る操作 |
@@ -140,9 +138,9 @@ path_policy_overrides:
 | `dev_delegation` | `implementation_skill` で選んだdevの入口の中で、サブエージェントへ委託する。許可がない場合は、入口のメインが同じ観点を自分で確認し、独立確認とは報告しない。worktreeの作成は含まない |
 | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
 
-- 開発進行には `issue_update` が必要である。`implementation_skill` がClaudeの入口のときは `bridge_request` も必要で、Codexの入口のときは代わりに `codex_task` とCodexタスクの作成・読み取り・送信のツールが必要である。Managedの入口のときは、代わりに `managed_session:<USD>` と `dev_delegation`、および会話側で認証済みの `ant` CLIが必要である（leadは担当を必ずサブエージェントへ委任するため、`dev_delegation` がなければ開始しない）。初期設定では、`issue_update`・`bridge_request`・`stage`・`dev_delegation` を開発進行の標準の組として提案する（Codexの入口を選ぶ場合は `bridge_request` を `codex_task` に、Managedの入口を選ぶ場合は `bridge_request` を `managed_session:<USD>` に置き換える）。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
+- 開発進行には `issue_update` が必要。Claudeの入口は基本 `review_flow: auto` なら `claude_cli` とローカルClaude CLI、`manual` なら `bridge_request` とWebStormのBridgeを使う。今回の明示依頼による同じ経路の許可も引き継ぐ。Codexの入口は `codex_task` とタスク操作ツール、Managedの入口は `managed_session:<USD>`・`dev_delegation` と認証済み `ant` CLIが必要。初期設定は `issue_update`・選んだ経路の許可・`dev_delegation` と `review_flow` を具体的に提案し、合意を得る。設定の存在だけでは許可を得ない。初回実装前に経路を確定し、manualのBridge不足をCLIへのfallbackで補わない。
 - `development_operations` は、既存の認証手段と利用者が許可した既存アカウントを使い、対象の開発・検証環境と専用の検証データで行う操作に限る。本人の二要素認証・セキュリティキー・CAPTCHA等が必要なら具体的に依頼し、回避しない。ログイン成功を新しい権限への同意と扱わず、新規アカウント・OAuth権限の拡大・課金・新規クラウド資源・共有環境への破壊的変更・実利用者データの操作は含めない。秘密値をIssueや証拠へ記載しない。
-- この包括許可は `stage`・`commit`・`push`・`pr_create`・`merge`・`deploy:*`・`publish:*`・外部への送信・履歴やデータの破壊的操作を含まない。テストや環境準備がこれらを伴うときも、それぞれの許可が必要。人レビュー・Human QA・ツール側の承認条件を省略しない。`permissions` に明示された場合だけ適用し、既存設定に自動で追加しない。
+- この包括許可は `stage`・`commit`・`push`・`pr_create`・`merge`・`deploy:*`・`publish:*`・外部への送信・履歴やデータの破壊的操作を含まない。テストや環境準備がこれらを伴うときも、stage・commitは合意済みflow、その他はそれぞれの許可が必要。人レビュー・Human QA・ツール側の承認条件を省略しない。`permissions` に明示された場合だけ適用し、既存設定に自動で追加しない。
 - 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする（マージで本番へ自動配備される場合は `merge` と `deploy:production`）。
 - 次の操作は一覧に含めず、常にその場で確認する: force-push、履歴の書き換え、ブランチの削除、チーム設定の変更。
 - 設定の許可は、今回の依頼で任されたIssue・Cycleの範囲を広げない。
@@ -185,16 +183,14 @@ statuses:
   human_input: In Progress
   done: Done
 stop_after: pre_push_qa
-implementation_skill: dev-claude # CodexがBridgeでClaudeへ依頼する。Codexが実装する場合は dev-codex など
-human_code_review: required
-commit_mode: autonomous
+implementation_skill: dev-claude # manualはWebStorm Bridge、autoはローカルCLI
+review_flow: manual
 path_policy_overrides: []
 cycle_report: null
 permissions:
   - development_operations # この範囲を利用者が合意した場合だけ記載
   - issue_update
   - bridge_request
-  - stage
   - dev_delegation
 references:
   specifications:
@@ -220,7 +216,7 @@ Claudeもこの手順で初期設定を行える。合意した設定の保存
 1. アカウント、workspace、team、projectと、チームのステータス一覧・既存の運用をLinearから読む。
 2. 作業先リポジトリのAGENTS.md・CLAUDE.md・README・CI・検証や配備のスクリプトを読み、`references` の候補を決める。
 3. 設定案を一つ作る。チーム設定を管理できる場合だけ、FamilyStayを基にした工程の分離（[workflow.md](workflow.md) の工程表に対応するステータス）を変更案として示す。利用者のプロジェクトらしいという推測で `manage_on_setup` にしない。
-4. 既存の情報で決まらない運用上の決定（`config_storage`、`stop_after`、`permissions`（`commit` を含む）、`human_code_review`、`team_settings`、Cycle報告、`commit_mode`、`implementation_skill`）だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。パス別の例外が必要な場合は、具体的な対象パターンと上書き項目、通常設定からの変更を示して合意する。例外を使わない新規設定には `path_policy_overrides: []` を記載する。旧設定の移行は上の手順に従う。
+4. 既存の情報で決まらない運用上の決定（`config_storage`、`stop_after`、`permissions`、`review_flow`、`team_settings`、Cycle報告、`implementation_skill`）だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。パス別の例外が必要な場合は、具体的な対象パターンと上書き項目、通常設定からの変更を示して合意する。例外を使わない新規設定には `path_policy_overrides: []` を記載する。旧設定の移行は上の手順に従う。
 5. 合意した方式の正本へ、下の保存手順に従って保存する。sharedでは採用する補足の `references` と共有対象を照合し、別checkoutでも同じ条件を読めるようにする。正本と補足を読み直して確認する。
 6. Linearのチーム設定の変更は、設定の保存とは別に扱う。対象チームと変更差分（追加・改名するステータスと順序）を示し、合意を得てから反映して読み戻す。反映後に `statuses` を実物に合わせて確定する。
 

package/plugins/shinaps-codex/references/linear/managed-session.md

@@ -119,7 +119,7 @@ YAML
 
 ## Managed固有の読み替えと記録
 
-- [単位案からコミット完了まで](workflow.md#単位案からコミット完了まで)の手順2は、依頼を送らず、進行役が許可と記録の一致を確かめる手順として読む。手順3は、進行役が `commit` に従って行う。
+- [単位案からコミット完了まで](workflow.md#単位案からコミット完了まで)の手順2は、依頼を送らず、進行役が許可と記録の一致を確かめる手順として読む。手順3は、進行役が `commit` に従い、autoなら独立レビュー・QA後にstage・commitし、manualなら安全なstash・stage・提示を行い、人のレビュー・修正・commitと復元確認を待つ。
 - 各idleでの累計の費用と最終の費用を、作業記録とIssueの記録に残す。
 
 ## 初回メッセージと修正依頼