npm - @shinaps/skills - Versions diffs - 0.32.0 → 0.33.0 - Mend

@shinaps/skills 0.32.0 → 0.33.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (45) hide show

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

@@ -22,11 +22,11 @@ description: 許可された差分を依存順のローカルコミットにし
 ## 範囲と進め方
-コミットは利用者の明示依頼、または[Linear共通設定](../../references/linear/configuration.md)の合意済みの許可に従う。Linear進行では[担当と工程](../../references/linear/workflow.md)の `code_review` に従い、Local Agent QA後に進行役から対象を指定した依頼を受けて行う。単独の依頼にはLinear進行や新しいゴールを必須にしない。
+コミットは利用者の明示依頼、または[Linear共通設定](../../references/linear/configuration.md)の合意済みの許可に従う。Linear進行では[担当と工程](../../references/linear/workflow.md)の差分確定に従い、Local Agent QA後に進行役から対象を指定した依頼を受けて行う。単独の依頼にはLinear進行や新しいゴールを必須にしない。
 どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。
-AIが担当するGit準備・修正は現在のセッションで行い、manualのレビュー・修正・commitは人が行う。autoは独立レビューを必須とする。必要な担当・許可が利用できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
+Git準備・修正・commitはAIが現在のセッションで行い、manualのレビュー・承認は人が行う。autoは独立レビューを必須とする。必要な担当・許可が利用できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
 ## 回復できる状態を作る
@@ -43,17 +43,15 @@ AIが担当するGit準備・修正は現在のセッションで行い、manual
 予定単位ごとに、[パス別の方針](../../references/linear/configuration.md#パス別の方針)でそのコミットの全変更を判定し、同資料の判定記録を残す。Linear進行から記録を受け取った場合は、設定とその単位の予定差分（内容・mode等を含む）の一致を確認して引き継ぐ。単独の依頼でも同じ判定を使い、Linear専用の工程は追加しない。設定が真にない単独依頼では、今回の明示許可とプロジェクト規約を通常方針とし、パス例外は適用しない。
-合意済みの実効 `review_flow` と今回の明示指示から進め方を確定する。両方とも対象のstageを許可し、`auto` ではAI、`manual` では人がcommitする。設定の存在だけを合意と扱わない。旧キー・不備・競合は共通設定に従って止める。
+合意済みの実効 `review_flow` と今回の明示指示から進め方を確定する。両方とも対象のstageとAIのcommitを許可し、`auto` では独立レビュー後、`manual` では人の単位承認後にAIがcommitする。設定の存在だけを合意と扱わない。旧キー・不備・競合は共通設定に従って止める。
-設定がない単独依頼でも「各単位をAIがレビューして自動コミット」「人がレビューして自分でコミット」など明確な意図を引き継ぐ。「コミットして」「進めて」だけからautoを推測しない。flowが未解決のときだけ対象を示し「auto（AIがレビュー・コミット）とmanual（人がレビュー・修正・コミット）のどちらで進めますか？」と一問聞き、回答まで依存操作を待つ。未回答を承認と扱わない。同じ依頼内でもパス例外により異なるflowの単位があってよい。
+設定がない単独依頼でも「各単位をAIがレビューして自動コミット」「単位ごとに見せて承認後にコミット」など明確な意図を引き継ぐ。「コミットして」「進めて」だけからautoを推測しない。flowが未解決のときだけ対象を示し「auto（AIがレビュー・コミット）とmanual（人がレビュー・承認し、AIが修正・コミット）のどちらで進めますか？」と一問聞き、回答まで依存操作を待つ。未回答を承認と扱わない。同じ依頼内でもパス例外により異なるflowの単位があってよい。
 モード決定後にレビュー可能性や依存関係のため単位を分割・統合する場合は、[変更時の扱い](../../references/linear/configuration.md#判定記録と変更時の扱い)に従って変更した単位を再判定し、必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。「autoだからまとめる」「manualだから分ける」を先に適用して単位決定と判定を循環させない。
 ## 単位ごとの検証・レビュー・コミット
-manualでは[人レビューの差分提示](../../references/human-review.md)に従う。実装runtimeによらず、実効 `review_flow.tool`（`plasma` / `webstorm`）で対象を提示する。未指定や利用不能なら止め、無断で別UIに切り替えない。人がレビュー・修正・commitする工程をAIによる承認後commitへ置き換えない。
-Claude CLIの非対話実行でmanualを準備する場合は、stash・stage・検証と対象情報をresultへ返してprocessを終了する。人への提示と完了待ちは進行役が行い、CLI内で対話を待たない。完了後の同じsessionへのresumeでHEAD・人の修正・実コミット・stash情報を受け、以下の照合と復元を続ける。
+manualでは[manualの差分提示と単位承認](../../references/human-review.md)に従い、人と対話できるセッションで提示・相談・承認を受ける。ローカルClaude CLIの非対話実行でmanualの単位を検出した場合は、手順を進めず、判定を記録してresultへ返す（[経路](../../references/linear/configuration.md#経路)）。
 以下を、その単位のモードで行う。
@@ -61,7 +59,7 @@ Claude CLIの非対話実行でmanualを準備する場合は、stash・stage・
 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に対象外の変更を残す場合は、それを含めずに対象だけをコミットする方法を使い、対象を限定できなければ止める。manualで提示する差分は、コミットされる差分と同じものにする。指摘は実物で確認し、依頼範囲の修正後は再ステージ・再検証する。外部仕様の調査は変更がそこに依存するときに行う。
-5. 必須検証と独立レビュー（auto必須）が通り、阻害指摘がないことを確認する。autoでは直前の全差分が予定単位と一致してからAIが `git commit` を単独実行する（`git add` と連結しない）。manualでは単位の差分・理由・検証結果・推奨メッセージを提示し、人がレビュー・必要な修正・commitを行い、その完了を知らせるまで待つ。AIは承認を受けても代わりにcommitしない。人の完了通知後に、比較元からの実コミット一覧と各SHA・全差分を調べ、通知された修正が許可された目的・範囲を満たすことを確認する。実差分で実効flowを再判定し、影響する挙動を再検証する。正当な人の修正は確定単位と全体の期待差分へ反映し、元の予定差分・完了通知・変更理由・実コミットとの対応を残す。本人が明示確認した修正という理由だけで新たな承認を求めない。意図や範囲が不明、対象外の混入、flowの適用が未解決なら人へ確認して止める。Gitにcommitがあるだけで人レビュー完了としない。各コミットを確定単位と照合してSHA・結果を記録し、不一致なら次工程を止める。履歴を無断で書き換えない。
+5. 必須検証と独立レビュー（auto必須）が通り、阻害指摘がないことを確認する。autoでは直前の全差分が予定単位と一致してからAIが `git commit` を単独実行する（`git add` と連結しない）。manualでは単位の差分・理由・検証結果・推奨メッセージを提示し、提示時の `git write-tree` を記録する。人との相談で修正したら再stage・再検証・再提示する。人がその単位を明示的に承認したら、直前のindexのtreeが承認したtreeと一致することを確認してAIが `git commit` を単独実行し、作成したコミットのtreeも照合する。承認後に単位のパスで作業ツリーまたはindexが変わったら承認は失効し、再提示・再承認する。承認はその単位にだけ及ぶ。commit後に（人自身の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 CHANGED Viewed

@@ -148,4 +148,4 @@ Skill(skill="shinaps:dev-claude", args="以下のデバッグ結果に基づき
 - **生レポート保存厳守**: すべての subagent 応答を全文保存
 - **根本原因確定時に ローカル成果物（implementation.md / 調査・レビューレポート）**: 後の作業者と別 AI agent が辿れるように
-Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto/manual両modeは [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。
+Linear進行への成果引き渡しでは、確定済みの経路を維持する。autoは同じ[Claude CLI](../../references/linear/claude-cli.md)のsessionのresultへ返す。manualは同じ対話セッションで続け、[Bridge](../../references/linear/bridge.md)で依頼元のCodexへ報告する。調査スキルから経路を切り替えない。

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

@@ -219,4 +219,4 @@ dev の入口は「実装 handoff」の `status: ready` と `evidenceSnapshot`
 - **生レポートを保存する**: subagent 応答は全文保存し、会話ログは要約だけ残す
 - **shinaps MCP はメインだけが呼ぶ**: subagent は `search_rules` / `list_search_facets` を直接呼ばない
-Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto/manual両modeは [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。
+Linear進行への成果引き渡しでは、確定済みの経路を維持する。autoは同じ[Claude CLI](../../references/linear/claude-cli.md)のsessionのresultへ返す。manualは同じ対話セッションで続け、[Bridge](../../references/linear/bridge.md)で依頼元のCodexへ報告する。調査スキルから経路を切り替えない。

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

@@ -1,68 +1,40 @@
 ---
 name: linear-execute
-description: Linearの開発で、Codexから受けた実装・修正・コミット依頼を実行する。作業先の設定の実装担当がManagedの入口なら、Claudeが進行役として実装からQA・許可された公開まで進める。それ以外の開発進行依頼はCodexへ引き渡す。相談・Issue整理はlinear-planを使う。
+description: Linearの開発で、Codexから受けた実装・修正・コミット依頼をClaude Codeで実行する。autoはローカルClaude CLI、manualはWebStormの対話セッションでBridgeの依頼を受ける。開発進行の依頼はCodexへ引き渡す。相談・Issue整理はlinear-planを使う。
 ---
 # Linearの開発でClaudeが行うこと
-開発進行を依頼されたら、まず[設定の読み方](../../references/linear/configuration.md#設定の読み方)で作業先の設定を読み、`implementation_skill` で役割を決める。設定が真に未設定なら、下の「Codexの依頼なしで起動された場合」の初期設定へ進む。
+Claudeは実装担当で、Codexが進行・Agent QA・Issueの記録・人への窓口を担当する。担当を入れ替えない。依頼を受けたら[設定の読み方](../../references/linear/configuration.md#設定の読み方)で作業先の設定を読み、依頼の経路と照合する。設定が真に未設定なら、下の「Codexの依頼なしで起動された場合」の初期設定へ進む。
-- Claudeの入口（`dev-claude`）では、Codexが進行・Agent QA・人への窓口を担当する。ClaudeはローカルClaude CLIの受け手として、技術調査と実装・修正を担当し、「読む資料」「依頼を受けて実行する」「結果と人の対応を報告する」に従う。担当を入れ替えない。
-- Managedの入口（`dev-managed-cc`）の開発進行では、Claudeが進行役になり、「Managedの入口で進行する」にだけ従う。
-- Codexの入口（`dev-codex`）では、開発進行をCodexへ引き渡す。
+## 経路
-## Claudeの実行経路を先に確定する
+経路は着手時に通常設定の `review_flow.mode` で決まり、Issueの途中で切り替えない（[経路](../../references/linear/configuration.md#経路)）。
-auto/manualともCodexが [Claude CLI](../../references/linear/claude-cli.md) を起動し、質問・修正・QA後のコミット準備を同じsessionへresumeする。manualはprocess終了後に実効 `review_flow.tool` で提示し、人がレビュー・修正・commitする。初回実装前に経路と権限を確定する。パス例外はreview_flow全体だけを変更し、実装経路を変えない。報告はCLI resultへ返し、任意のBridge報告は照合入力として扱う。
-## 再確認せず進める条件
-Codexから許可範囲と受入条件を伴う実装・修正の依頼をCLIで受けたClaudeは、人へ着手を再確認せず、指定されたスキルで実行する。質問・相談・障害・完了はCodexへ返す。
-人のレビュー・コミット完了の報告をBridgeで受けたCodexは、報告の対象とGitの状態を照合し、一致すれば既存の許可の範囲で人へ再確認せず次の工程へ進む。
-条件の一覧と報告の項目は `../../references/linear/workflow.md` にある。
+- auto: Codexが起動する[ローカルClaude CLI](../../references/linear/claude-cli.md)で依頼を受け、質問・障害・完了はresultへ返す。回答・修正・コミットの依頼は同じsessionのresumeで受ける。
+- manual: WebStorm内の対話Claude Codeセッションで[Bridge](../../references/linear/bridge.md)の依頼を受ける。人と直接作業し、計画上の判断・仕様の不明点は人へ `AskUserQuestion` で一問ずつ確認する。完了・障害・人の承認とcommitの完了は、Bridgeで依頼元のCodexへ報告する。
 ## 読む資料
-依頼を受けたら、[references/workflow.md](../../references/linear/workflow.md) の「担当と窓口」「再確認せず進める条件」「Bridgeでの任意の引き渡し・報告」を読む。依頼に添えられたプロジェクトの補足と参照先も読む。
+依頼を受けたら、[担当と工程](../../references/linear/workflow.md)の「担当と窓口」「工程とステータス」「失敗・許可・停止の共通ルール」と、経路の資料（[Claude CLI](../../references/linear/claude-cli.md) または [Bridge](../../references/linear/bridge.md)）を読む。依頼に添えられたプロジェクトの補足と参照先も読む。
 他の資料は次の場合だけ読む: 依頼で指示された場合、Issue整理を依頼された場合（[references/issue.md](../../references/linear/issue.md)）、Codexの依頼なしで実作業を依頼された場合（[references/issue.md](../../references/linear/issue.md) の「着手前に作業をIssueへ紐づける」）、設定を読む必要がある場合（[references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」）。
 ## 依頼を受けて実行する
-- 依頼の範囲・受入条件・Gitの作業ディレクトリ・ブランチ・既存差分・許可範囲を確認する。
+- 依頼の範囲・受入条件・Gitの作業ディレクトリ・ブランチ・既存差分・許可範囲を確認する。Codexから許可範囲と受入条件を伴う依頼を受けたら、人へ着手を再確認せず実行する。
 - Codexから依頼された実装・修正は、依頼の対象Issueに紐づく。Claudeは別のIssueを作らない。
-- 実装・修正には、依頼で指定された入口（`shinaps:dev-claude`）を使う。指定と設定を照合し、欠落・不一致ならCodexへ確認してから進め、受信側で入口を変えない。devの入口は内部で簡素化・規約照合・レビューを行うので、これらを別に起動しない。入口を使えない場合は、独自の手順で代わりに実装せずCodexへ報告する。
-- devの入口の委託（サブエージェント）は、依頼の許可範囲に `dev_delegation` が書かれている場合だけ使う。許可範囲に `dev_delegation` がない依頼では委託しない。worktreeの作成は含まない。
-- devの入口が利用者に確認する場面（計画の判断、不明点、承認）では、人ではなくCodexへ相談する。Codexが既存の合意で答えた内容を人へ再確認しない。仕様・受入条件・許可範囲の変更が必要な場合は、Codexが人に確認する。
+- 実装・修正には `shinaps:dev-claude` を使う。devの入口は内部で簡素化・規約照合・レビューを行うので、これらを別に起動しない。入口を使えない場合は、独自の手順で代わりに実装せずCodexへ報告する。
+- 初期体制は、Codexが渡した材料と現物から、Claudeのメインが[体制の判断](../../references/dev/staffing.md)に従って決めて報告する。途中の新しい根拠で必要な担当を増やし、変更理由と体制を報告する。人数の固定された入口へ戻さず、必須検証と独立性を保つ。
+- devの入口の委託（サブエージェント）は、依頼の許可範囲に `dev_delegation` が書かれている場合だけ使う。worktreeの作成は含まない。
 - QAで見つかった不具合の修正依頼も同じ扱いにし、人の着手許可を改めて取らない。
 - 同じ作業ツリーをCodexや人と同時に編集しない。人や他のAIの変更を保持する。
-- コミットの許可は[共通設定](../../references/linear/configuration.md)、担当とQA後の条件は[担当と工程](../../references/linear/workflow.md)の `code_review` に従う。実装完了の直後に先行してコミットせず、進行役へ結果を返す。条件を満たす依頼を受けたら `shinaps:commit` を使い、許可済みの操作を再確認しない。質問の取り次ぎは両modeともClaude CLIのresultへ返す。
+- コミットの許可は[共通設定](../../references/linear/configuration.md)、担当とQA後の条件は[担当と工程](../../references/linear/workflow.md)の差分確定に従う。実装完了の直後に先行してコミットせず、Codexへ結果を返す。差分確定の依頼を受けたら `shinaps:commit` を使い、許可済みの操作を再確認しない。
 ## 結果と人の対応を報告する
-- 完了の報告と、人のレビュー・コミット完了の報告に含める項目は、[references/workflow.md](../../references/linear/workflow.md) に従う。両modeとも [Claude CLI](../../references/linear/claude-cli.md) のresultへ返す。
-- 人へ着手の確認やコミットの依頼をしない。人がClaudeへ直接伝えた指示や結果は保持し、Codexへ報告する。Gitにコミットがあるだけで、人のレビュー済みと報告しない。設定で人のレビューを省略した場合は、省略と報告する。
-## Managedの入口で進行する
-実行範囲、開始時に固定するもの、継続とゴールは [execution.md](../../references/linear/execution.md) に従う。必要な許可は [configuration.md](../../references/linear/configuration.md) の「許可」に従う。実装・修正は [managed-session.md](../../references/linear/managed-session.md) の手順でセッションへ依頼し、結果を受け取る。
-- ゴール: 対象と終了条件を、会話から到達を確かめられる `/goal` の文で示す（例「SHINAPS-xxx が終了地点 <到達点> に達し、PRのURLとIssueとの相互リンクを報告した」）。ProposeGoalツールが使えればそれで提案し、その結果を確認とする。使えなければ `AskUserQuestion` で `/goal` の設定を依頼し、設定済みという回答を受けてから始める。Claude Codeではモデルからゴールの状態を読めないため、この回答を確認とする。設定されなければ、execution.mdの「ゴール機能」に従って開始前で止まる。
-- 人への確認（人の判断が要る質問への回答、未完了の扱い、作業ツリーに差がある場合など）は、すべて `AskUserQuestion` でターンの中で受ける。確認のためにターンを終えて待たない。Claude Code では /goal が有効な間、ターンを終えると Stop hook がゴール未達と判定して作業が続き、利用者の回答を待てないため。
-- セッションの完了待ち: backgroundのBashで、managed-session.mdの「観測と判定」の待ちを終える条件が現れるまで60秒ごとに確かめるuntilループを回し、終了の通知で再開する。`/goal` によって作業が続いても、動いているループがあれば二重に起動しない。
-| 作業 | 読む資料 |
-| --- | --- |
-| 設定の確認 | [references/configuration.md](../../references/linear/configuration.md) |
-| 着手前の紐づけ、Issueの作成・整理・本文の更新 | [references/issue.md](../../references/linear/issue.md) |
-| 担当、工程、待ち状態、人への依頼、継続の範囲 | [references/workflow.md](../../references/linear/workflow.md) |
-| Managedセッションの作成・観測・取り出し・適用とQAへの受け渡し | [references/managed-session.md](../../references/linear/managed-session.md) |
-| 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が行う。コミットはautoならAI、manualなら人が行う。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで続ける。
+- 完了の報告と、人の承認・commit完了の報告に含める項目は、経路の資料に従う。
+- 人がClaudeへ直接伝えた指示・決定・承認は保持し、Codexへ報告する。Gitにコミットがあるだけで、人の承認済みと報告しない。設定で人のレビューを省略した単位は、省略と報告する。
 ## Codexの依頼なしで起動された場合
@@ -70,8 +42,4 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をCLIで
 - 利用者から直接依頼された実作業（開発進行の依頼を除く）は、着手前に [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` の初期設定ヒアリングに進み、保存・確認後に元の依頼の引き渡しへ戻る。両modeともCLIを起動するCodex側へ依頼内容を返して開始を案内する。任意の引き渡しとして `bridge_request` が許可され、BridgeでCodexのセッションを特定できる場合は、[references/workflow.md](../../references/linear/workflow.md) の「開発進行の引き渡し」の項目を添えてCodexへ引き渡す。設定は [references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従って読む。許可や相手のセッションがない場合は、必要な準備（設定、CodexセッションとClaude CLIの起動）を利用者へ案内する。
-## 初期体制と途中の増員
-[Issue開始時の実装体制](../../references/linear/execution.md#issue開始時の実装体制)と[体制の判断](../../references/dev/staffing.md)に従う。進行役は各Issueの初期体制を設計前に決めて渡し、実装側のメインは現物と照合して必要な担当を追加できる。Claudeが実装の受け手の場合も同じ基準を使い、変更理由と体制を進行役へ返す。Managedの進行役も初期体制をleadへ渡す。人数の固定された入口へ戻さず、必須検証と独立性を保つ。
+- 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、Claudeは進行役を兼ねない。設定は [references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従って読み、真に未設定と確認した場合だけ、同じセッションで `shinaps:linear-plan` の初期設定ヒアリングに進み、保存・確認後に元の依頼の引き渡しへ戻る。`bridge_request` が許可され、BridgeでCodexのセッションを特定できる場合は、[Bridge](../../references/linear/bridge.md) の「開発進行の引き渡し」の項目を添えてCodexへ引き渡す。許可や相手のセッションがない場合は、必要な準備（設定、Codexのセッション）を利用者へ案内する。

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

@@ -150,4 +150,4 @@ Skill(skill="shinaps:dev-claude", args="以下のレビュー指摘を修正す
 - **diff が空ならエラー終了**: 何もしない旨を明示
 - **テストの判断**: [テスト方針](../../references/testing.md) に従う
-Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto/manual両modeは [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。
+Linear進行への成果引き渡しでは、確定済みの経路を維持する。autoは同じ[Claude CLI](../../references/linear/claude-cli.md)のsessionのresultへ返す。manualは同じ対話セッションで続け、[Bridge](../../references/linear/bridge.md)で依頼元のCodexへ報告する。調査スキルから経路を切り替えない。

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

@@ -209,4 +209,4 @@ Skill(skill="shinaps:dev-claude", args="以下の仕様書を実装する。詳
 - **フィジビリティ調査は spec で済ませる**: dev での差し戻しを減らすため、Phase 3/4 の調査を惜しまない
 - **rule カタログを制約に反映**: `search_rules` 結果を spec.md の制約セクションに集約
-Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto/manual両modeは [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。
+Linear進行への成果引き渡しでは、確定済みの経路を維持する。autoは同じ[Claude CLI](../../references/linear/claude-cli.md)のsessionのresultへ返す。manualは同じ対話セッションで続け、[Bridge](../../references/linear/bridge.md)で依頼元のCodexへ報告する。調査スキルから経路を切り替えない。

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

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

package/plugins/shinaps-codex/agents/shinaps-split-reviewer.toml CHANGED Viewed

@@ -1,4 +1,4 @@
 name = "shinaps-split-reviewer"
-description = "shinaps:commit のmanualで、人が単位ごとにレビュー・修正・コミットする前に分割計画を確認するレビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の 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` の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 経由で渡される"
+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/launch.md CHANGED Viewed

@@ -1,13 +1,13 @@
 # 担当の起動（Codex）
-[工程](workflow.md)の体制で選んだ担当を Codex のサブエージェントで起動・継続する手順。
+review・debug・spec などのCodexスキルが、[工程](workflow.md)で定める役割の担当を Codex のサブエージェントで起動・継続する手順。
-- 担当は `spawn_agent` で起動し、毎回 `agent_type`（役割定義名。例 `shinaps-architect`）、`fork_turns: "none"`、`model: "gpt-6-astra"`、`reasoning_effort: "medium"` を明示する。役割定義には model を書かないので、モデルと推論はこの指定で決まる。`fork_turns` を省略すると親の履歴を引き継ぎ、独立した担当にならない。親セッションの設定は変更しない。
+- 担当は `spawn_agent` で起動し、毎回 `agent_type`（役割定義名。例 `shinaps-reviewer`）と `fork_turns: "none"` を明示する。`fork_turns` を省略すると親の履歴を引き継ぎ、独立した担当にならない。役割定義には model を書かないので、`model`・`reasoning_effort` はスキルが指定する場合だけ明示し、指定がなければ親セッションから継承する。親セッションの設定は変更しない。
 - 同じ役割の複数担当 は、同じ `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 CHANGED Viewed

@@ -1,6 +1,6 @@
 # 実装体制の判断
-人数を入口名や変更行数で固定しない。linear-execute の進行役は各Issue開始時にIssue・関連コード・既存検証・設定を短く確認し、設計担当の起動前に初期体制を決める。単独のdevではdevのメインが同じ判断を行う。実装セッション内の「メイン」はClaude・Codex・Managedのleadを指し、linear-executeの進行役とは区別する。
+人数を入口名や変更行数で固定しない。devのメインが設計担当の起動前に初期体制を決める。linear-execute の進行役は各Issue開始時に受入条件・関連範囲・既存検証・リスクを材料として渡し、体制は決めない。「メイン」はdevを実行するClaude Codeのセッション（CLIまたは対話）を指し、linear-executeの進行役とは区別する。
 ## 判断すること
@@ -27,7 +27,7 @@
 起動前に、判断の根拠、工程ごとの役割・人数・確認範囲、専任なしの責任者、必須検証、設計と指摘の統合責任者を短く記録する。設計担当がいれば担当1が設計・統合を継続し、いなければdevのメインが責任を持つ。独立レビュー担当は実装担当と別のコンテキストにする。
-linear-executeの進行役は初期体制を利用者へ短く示し、実装依頼に根拠とともに渡す。通常の体制判断で人の承認を待たない。実装側は開始時に受け取った体制と現物を照合し、欠けていれば既定の人数へ戻さず、初期確認して体制を決め、進行役へ報告する。ローカル記録は `.shinaps/work/` 以下へ保存する。別セッションへは本文も渡し、相手から見えないパスだけに依存しない。
+linear-executeから受けた作業では、メインが決めた初期体制と根拠を進行役へ報告する。通常の体制判断で人の承認を待たない。材料が欠けていれば既定の人数へ戻さず、初期確認して体制を決める。ローカル記録は `.shinaps/work/` 以下へ保存する。別セッションへは本文も渡し、相手から見えないパスだけに依存しない。
 ## 途中の増員

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

@@ -1,6 +1,6 @@
 # dev の工程
-Claude・Codex・Managed Agentsのdevはこの工程を共有する。役割・人数は[実装体制の判断](staffing.md)に従って作業ごとに決め、担当の起動・継続は各runtimeの[起動手順](launch.md)に従う。
+Claude Codeのdev（`dev-claude`）の工程。役割・人数は[実装体制の判断](staffing.md)に従って作業ごとに決め、担当の起動・継続は[起動手順](launch.md)に従う。Codexのreview・debug・spec等も、ここで定める役割を使う。
 ## 1. 前提と作業記録
@@ -34,7 +34,7 @@ Claude・Codex・Managed Agentsのdevはこの工程を共有する。役割・
 依頼・引数・指定された成果物から目的・受入条件・範囲を確定する。確定済みの内容を聞き直さず、依頼されていない過去の作業を始めない。成果物に実装可否の状態があればreadyを確認し、欠落・不明なら変更内容を推測せずタスクを確定する。内容ハッシュがある根拠は現在値と照合し、古い根拠は読み直す。
-Issue・既存spec・調査記録・関連コード・検証方法を必要な範囲だけ確認する。linear-executeからの初期体制を引き継ぎ、なければメインが `staffing.md` に従って判断する。設計担当を起動する前に、根拠・役割別人数・専任なしの責任者・統合責任者・必須検証を `staffing.md` として作業記録へ保存し、短く報告する。不足する調査があればPhase 2で補い、体制を更新する。
+Issue・既存spec・調査記録・関連コード・検証方法を必要な範囲だけ確認する。linear-executeからは体制判断の材料を受け取り、メインが `staffing.md` に従って初期体制を決める。設計担当を起動する前に、根拠・役割別人数・専任なしの責任者・統合責任者・必須検証を `staffing.md` として作業記録へ保存し、短く報告する。不足する調査があればPhase 2で補い、体制を更新する。
 ## 4. Phase 2: 規約と必要な探索
@@ -105,7 +105,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 初期体制と変更理由、実際の担当・確認範囲、計画と実装後のレビュー回数、採否・修正、検証結果、未実施・未照合・未解決事項を報告する。
-linear-executeから受けた作業は未コミットの差分と結果を進行役へ返す。devの完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)と[担当と工程](../linear/workflow.md)に従い、QA後のcommit工程の依頼を受け、autoはAIコミット、manualは人への提示準備を行う。Claudeのauto/manual両modeは [Claude CLI](../linear/claude-cli.md) のresultへ報告し、同じsessionのresumeで質問・修正を受ける。manualの提示はprocess終了後に実効 `review_flow.tool` で行う。Codex・Managedはそれぞれの既存返却経路を使う。
+linear-executeから受けた作業は未コミットの差分と結果を進行役へ返す。devの完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)と[担当と工程](../linear/workflow.md)に従い、QA後の差分確定の依頼を受けて `commit` を行う。auto経路は [Claude CLI](../linear/claude-cli.md) のresultへ報告し、同じsessionのresumeで質問・修正を受ける。manual経路は同じ対話セッションで人と作業し、[Bridge](../linear/bridge.md)で依頼元Codexへ報告する。
 単独のdevではコミットが許可されている場合だけ範囲とモードを `commit` へ渡す。許可がなければ未コミットで返し、形式的な許可確認を追加しない。PR・リリースも許可された範囲で各スキルへ渡す。単独devにLinear進行・新しいゴールを必須にしない。

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

@@ -1,32 +1,26 @@
-# 人レビューの差分提示
+# manualの差分提示と単位承認
-manualで人がレビュー・修正・commitする場合に使う。review_flow・操作許可は、プロジェクト設定と今回の依頼に従う。この手順はそれらを変更しない。
+実効 `review_flow.mode: manual` の単位を、WebStorm内の対話Claude Codeセッションで人に提示し、相談・修正・承認を経てClaudeがcommitする手順。review_flow・操作許可は、プロジェクト設定と今回の依頼に従う。この手順はそれらを変更しない。
-実装runtimeによらず、実効 `review_flow.tool` が `plasma` ならPlasma、`webstorm` ならWebStormを使う。UIの指定がない場合は提示前に一問で確認する。設定のmanualでtoolが欠落していれば設定を修正する。CLIのprocess終了を確認してから提示し、人の操作と実装処理を並行しない。
+## 提示
-## 対象の準備
+1. `commit` の安全手順で単位外の変更を退避し、単位の変更だけをstageする。必須検証を行う。
+2. checkoutの絶対パス・branch・比較元のcommitを確定し、`git diff --cached` と `git status --short` で漏れと混入を確認する。未追跡ファイルも対象に含める。
+3. 会話で単位の差分・目的・確認してほしい点・検証結果・推奨コミットメッセージを提示する。Linear進行ではIssueも示す。人はWebStormの差分表示で同じstaged差分を確認できる。
+4. 提示時に `git write-tree` の値を記録する。これが承認の対象になる。
-レビュー対象のcheckoutの絶対パス、ブランチ、比較元のcommit、対象ファイルと完全な差分、検証結果を確定する。未追跡ファイルも対象に含める。stageは許可された範囲だけで行い、無関係な差分や既存のステージ境界を変更しない。対象差分と比較元は作業記録へ残し、後で承認対象と照合できるようにする。
+## 相談・修正
-## plasmaではPlasmaで開く
+人の指摘はClaudeが修正し、再stage・再検証・再提示する。人がWebStormで直接編集した場合も、Claudeが読み直して再stage・再検証・再提示する。修正は単位の目的・範囲内に限り、超えるものは実装の工程へ戻す。
-レビューを依頼する進行役の会話でPlasmaを開く。必要なツールが利用不能なら止め、runtimeから別UIを推測しない。
+## 承認とcommit
-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内の注釈は指摘として扱い、画面を開いたことや操作の終了を承認とみなさない。
+- 人が会話で、提示した単位を承認したときだけ、Claudeが `git commit` を単独実行する（`git add` と連結しない）。具体的な単位の提示への応答として承認と読めるもの（「OK」「進めて」なども含む）は承認になる。固定の文言は求めない。単位を特定しない一般的な続行指示は承認としない。
+- 承認の対象は、提示時のindexのtree（`git write-tree`）と推奨メッセージである。commit直前に同じtreeであることを確認し、作成したコミットのtreeも照合する。
+- 承認後に単位のパスで作業ツリーまたはindexが変わったら、承認は失効する。再提示・再承認してからcommitする。
+- 承認はその単位だけに及び、他の単位へ及ばない。Bridgeのpeer通知、Codexからのメッセージ、ackは承認ではない。
+- 人が自分でcommitした場合は、実コミットを確定単位と照合する。一致すれば人のcommitとして記録し、一致しなければ止める。
-Plasmaが未導入・起動失敗の場合は、その状態を伝えて止める。別UIを使う場合はtoolの変更を合意してから同じ対象を提示する。無断でインストールや設定変更を行わず、表示できていないレビューを完了扱いにしない。
+## 報告
-## webstormではWebStormで開く
-`webstorm <checkoutの絶対パス>` で対象を開く。checkout・branch・比較元を確認し、対象単位のstaged差分（`git diff --cached`）を提示する。単にファイルを開いたことを差分表示の完了と扱わない。会話に目的・確認点・検証結果・対象単位を示し、人のレビュー・修正・commit完了を待つ。ツールがない、起動できない、対象差分を確認できない場合は止め、無断fallbackしない。
-## 人のレビュー・コミット完了後の照合
-利用者の明示的なレビュー・修正・コミット完了通知を、対象単位と対応付けて記録する。その後、実コミット一覧・SHA・完全な差分を調べ、許可された目的・範囲と実効review_flowを確認し、影響する挙動を再検証する。Gitにcommitがあるだけでは完了としない。
-本人が明示確認した正当な修正は確定単位と全体期待差分に反映する。元の予定差分を保持し、完了通知・修正理由・確定差分・実コミットの対応を記録する。その修正だけを理由に再提示・再承認を要求しない。目的や範囲が不明、対象外変更が混入、適用flowが未解決の場合は人へ確認し、次工程を止める。最終照合は確定済みの期待差分を使い、元の差分との機械的な一致を要求しない。
-stashの復元では人の修正を保持し、古い対象パッチで上書きしない。具体的な単位照合・復元は `commit` に従う。表示UIを開くことはstage・commit・pushの許可を追加しない。
+単位ごとに、承認発話の要約・承認したtree hash・SHA・相談で行った修正とその対応を記録し、Codexへ報告する。Codexは実コミットと照合する。stashの復元では人の修正を保持し、古い対象パッチで上書きしない。具体的な単位照合・復元は `commit` に従う。WebStormで差分を表示することはstage・commit・pushの許可を追加しない。

package/plugins/shinaps-codex/references/linear/bridge.md ADDED Viewed

@@ -0,0 +1,55 @@
+# Bridge
+通常設定が `review_flow.mode: manual` のIssue（[経路](configuration.md#経路)）で、CodexがWebStorm内の対話Claude CodeセッションへAI Terminal Bridge（以下Bridge）で依頼し、報告を受ける手順。`bridge_request` があれば、別会話との任意の進行の引き渡しにも使う。
+各項目の根拠を括弧で示す。「履歴」はこのリポジトリのコミット 6ebbfbf・c766eb6 時点の `plugins/shinaps-claude/skills/linear/references/workflow.md` の「Bridgeでの依頼と報告」に記録された運用、「現物確認」は2026-10-19に進行役がBridge MCPのツール一覧で確認した内容を指す。どちらにもない挙動は、使う時点で現物のツール一覧と挙動で確認し、確認できなければ止める。
+## 前提
+- Bridgeの本体は同梱しない。Codex側は導入済みのBridge MCP、Claude側はWebStormプラグインを使う（履歴）。
+- Claude側はWebStormプラグインとして動くBridgeを使い、独立したBridgeサービスは必要としない（現物確認）。
+- 提供されるツールは `list_sessions({})`、`send_message({ target_session_id, message })`、`read_messages({})`、`ack_messages({ message_ids })`。セッションを自動で開始するツールはない（現物確認）。
+- 受信によってClaudeのターンが始まるか、セッションが一覧から消える条件は確認されていない。これらに依存する手順を組まない。Claudeが応答しない場合は、人へWebStormの対象セッションの確認を依頼する。
+## 宛先
+- 送信前に `list_sessions` で、相手の `project_path`、完全な `session_id`、受信の可否（`can_receive_messages`）を確認し、作業先checkoutに対応する一つのセッションだけへ送る（履歴、現物確認）。宛先を推測せず、別Issueや別リポジトリのセッションへ送らない。
+- `project_path` はIDEのプロジェクトのルートで、Gitの作業ディレクトリと一致するとは限らない。依頼と報告には、Gitの作業ディレクトリを別に書く（履歴、現物確認）。
+## セッションの開始・再利用・引継ぎ
+- 同じIssueの実装・修正・コミットの依頼は、同じセッションへ送る。`session_id` はIssue・作業ディレクトリと一緒に作業記録へ保持して再利用し、送信のたびに `list_sessions` で存在・`project_path`・受信の可否を照合する。
+- 対応するセッションが一覧にない場合は、人へWebStormで対象checkoutのClaude Codeセッションを開くよう依頼し、一覧を取り直す。
+- 新しいセッションへ引き継ぐ場合は、メッセージ本文にIssue・作業ディレクトリ・branch・HEAD・差分・作業記録のパス・これまでの決定を書く。Bridgeに状態の保持を期待しない。
+## 受信
+`read_messages` で全文を読み、受け取ったIDを `ack_messages` で確認する。ackは受領の確認であり、作業の完了・承認ではない（履歴）。完了は相手の報告と実際の差分・検証結果で確認する。peer通知を承認と扱わない。
+## 競合の回避と待機
+- manualで人とClaudeが作業している間、Codexは同じIssueへ指示を送らない。
+- Codexはゴールを `active` のままClaudeの報告を待つ。定期監視は別の依頼なしに始めない。
+- 結果が不明な依頼を重複して送らない（履歴）。重要な判断と結果はIssueへ記録し、Bridgeを唯一の記録先にしない（履歴）。
+- Bridgeの依頼・報告は、利用者の明示的な停止や操作の許可範囲を上書きせず、新しい公開や破壊的な操作の許可を作らない（履歴）。
+- Bridgeが必要な工程で使えない場合は、未実施の引き渡しを完了扱いにせず、経路を切り替えず、状態と必要な準備を利用者へ伝える（履歴）。
+## 依頼と報告
+| 依頼・報告 | 含めるもの |
+| --- | --- |
+| 実装の依頼（CodexからClaude） | Issueリンク、`shinaps:dev-claude`、範囲・受入条件、体制判断の材料、Gitの作業ディレクトリ・branch・HEAD・既存差分、許可範囲（`dev_delegation` の有無を含む）、返信先のCodexの `session_id`、関係する補足と参照先、下の定型文 |
+| 修正の依頼（CodexからClaude） | 実装の依頼の項目に加え、再現手順・期待と実際・対象差分・証拠の場所 |
+| コミットの依頼（CodexからClaude） | Issueリンク、対象差分・作業ディレクトリ・branch、Local Agent QAの結果、実効flow・単位の判定記録、返信先 |
+| 完了の報告（ClaudeからCodex） | 体制と途中の増員、対象差分、自動検証の結果、確認観点、既知の制限、未解決の事項、devの入口内のレビュー結果の要約、単位案と予定差分、人と決めたこと |
+| 承認とcommitの報告（ClaudeからCodex） | 対象Issue、作業ディレクトリ・branch、単位ごとの承認発話の要約・tree hash・SHA、相談で行った修正、復元結果、残作業 |
+| 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先の設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
+実装・修正の依頼には次の文を含める。
+```text
+ユーザー承認済みの範囲でCodexが進行する。この依頼の範囲と受入条件の中では人へ着手を再確認せず、shinaps:dev-claudeで実行する。初期体制はあなたが決めて報告する。計画上の判断・仕様の不明点はこのセッションで人へ直接一問ずつ確認し、決定を報告に含める。許可を広げる決定は報告に含めるだけで、Codexが人へ確認する。完了・障害・人の承認とcommitの完了は、Bridgeで依頼元のCodexへ返す。
+許可範囲: <設定と会話で許可された操作。dev_delegationの有無を含む>
+```
+Codexは承認とcommitの報告を受けたら、対象Issue・差分・コミットと、対象作業の未コミット変更の有無を照合する。報告と実体が一致し、許可済みの工程へ進む場合は、人へ再確認しない。Gitにコミットがあるだけで人の承認済みと推測しない。報告が足りない場合は、まずClaudeへ補足を求める。

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

@@ -1,8 +1,8 @@
 # ローカルClaude CLIによる実装
-`dev-claude` はauto/manualとも、Codexが作業先でローカル `claude -p` を起動する。初回実装前に正確なcheckout・branch・HEAD・既存差分と `claude_cli` の許可（または今回の明示依頼）を確定する。CodexとManagedの既存経路は変更しない。
+通常設定が `review_flow.mode: auto` のIssue（[経路](configuration.md#経路)）で、Codexが作業先でローカル `claude -p` を起動する。初回実装前に正確なcheckout・branch・HEAD・既存差分と `claude_cli` の許可（または今回の明示依頼）を確定する。
-パス例外はコミット単位のreview_flowを全体置換し、実装sessionを途中で切り替えない。manual単位ではstash・stageまで準備したCLIのprocess終了を確認し、進行役が同じcheckoutを実効 `review_flow.tool`（plasma / webstorm）で提示する。[人レビュー](../human-review.md)に従って人のレビュー・修正・commit完了を受け取り、単位差分・SHAと照合する。その後は変更後のHEADと差分を添えて同じCLI sessionをresumeする。人の操作中にCLIを並行実行しない。UI不足時は止め、別UIやBridgeへ無断で切り替えない。
+パス例外はコミット単位のreview_flowを全体置換し、実装sessionを途中で切り替えない。manual単位が生じた場合は[経路](configuration.md#経路)に従う。
 ## 起動と観測
@@ -20,7 +20,7 @@ jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、
 ## 依頼・質問・修正・コミット
-promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、初期体制、exact cwd・branch・HEAD・既存差分、許可・禁止操作、規約と参照先、返却条件を含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。CLIからBridge送信や人の対話入力を待たせない。
+promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、体制判断の材料（関連範囲・既存検証・リスク）、exact cwd・branch・HEAD・既存差分、許可・禁止操作、規約と参照先、返却条件を含める。初期体制はClaudeのメインが材料と現物から決め、体制と理由をresultに含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。CLIからBridge送信や人の対話入力を待たせない。
 回答・QA修正・QA後のautoコミット依頼は、元のprocess終了後、記録済みの正確なIDで同じセッションをresumeする。`--continue` で別セッションを推測しない。
@@ -28,7 +28,7 @@ promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、初期体
 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に作り直さない。
+resumeにも同じcwdと許可境界を指定し、外部で変化したHEAD・差分を渡す。commit依頼にはLocal Agent QA結果、独立レビュー、単位案と全差分、実効review_flowと合意根拠を含める。完了報告は体制と途中の増員、変更範囲、検証、未解決事項、単位案、commitした場合はSHA・単位照合・残差分・stash復元結果を含める。復帰不能時は理由を報告し、黙って別sessionに作り直さない。
 ## 操作権限