@shinaps/skills 0.29.1 → 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,31 +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以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で対象単位を示して「このコミットはどちらで進めますか？」と一問だけ聞く。
+合意済みの実効 `review_flow` と今回の明示指示から進め方を確定する。両方とも対象のstageを許可し、`auto` ではAI、`manual` では人がcommitする。設定の存在だけを合意と扱わない。旧キー・不備・競合は共通設定に従って止める。
 
-- **通常（推奨）**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
-- **自律**: その単位を検証・レビューして個別の承認を求めずコミットする。
+設定がない単独依頼でも「各単位をAIがレビューして自動コミット」「人がレビューして自分でコミット」など明確な意図を引き継ぐ。「コミットして」「進めて」だけからautoを推測しない。flowが未解決のときだけ対象を示し「auto（AIがレビュー・コミット）とmanual（人がレビュー・修正・コミット）のどちらで進めますか？」と一問聞き、回答まで依存操作を待つ。未回答を承認と扱わない。同じ依頼内でもパス例外により異なるflowの単位があってよい。
 
-質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。別単位の選択は流用しない。同じ依頼内で通常・自律が混在してよい。合意して保存された通常設定またはパス別ルールの `commit_mode` は、その単位への適用結果を使う。その場の明示的な指定は設定に優先する。
-
-設定項目の独立性と併せて読む条件は[Linear共通設定](../../references/linear/configuration.md)に従う。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
-
-モード決定後にレビュー可能性や依存関係のため単位を分割・統合する場合は、[変更時の扱い](../../references/linear/configuration.md#判定記録と変更時の扱い)に従って変更した単位を再判定し、必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。「自律だからまとめる」「通常だから分ける」を先に適用して単位決定と判定を循環させない。
+モード決定後にレビュー可能性や依存関係のため単位を分割・統合する場合は、[変更時の扱い](../../references/linear/configuration.md#判定記録と変更時の扱い)に従って変更した単位を再判定し、必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。「autoだからまとめる」「manualだから分ける」を先に適用して単位決定と判定を循環させない。
 
 ## 単位ごとの検証・レビュー・コミット
 
+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

@@ -1,9 +1,14 @@
 ---
 name: debug
-description: バグ報告・不具合の根本原因を多角的に調査し、対症療法ではなく根本解決を導くスキル。コードトレース + WebSearch + GitHub Issue 検索で仮説を立て、実コード検証で確定させ、必要に応じて shinaps-tech-surveyor + shinaps-survey-validator で外部情報を深掘りし、/shinaps:dev-claude-ultra に橋渡しする。既存の調査・実装成果物と rule カタログを仮説候補の予選材料に使う
+description: バグ報告・不具合の根本原因を多角的に調査し、対症療法ではなく根本解決を導くスキル。コードトレース + WebSearch + GitHub Issue 検索で仮説を立て、実コード検証で確定させ、必要に応じて shinaps-tech-surveyor + shinaps-survey-validator で外部情報を深掘りし、/shinaps:dev-claude に引き継ぐ。既存の調査・実装成果物と rule カタログを仮説候補の優先順位付けに使う
 argument-hint: <なし | エラーメッセージ / 症状の説明 | ファイルパス>
 ---
 
+## 質問の実行経路（全工程に優先）
+
+対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
+
+
 ## 作業記録の保存先
 
 作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
@@ -80,7 +85,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 - プロジェクト `CLAUDE.md` 全文
 - **Phase 1 で作成した既存成果物の要約**
 - **前準備の `search_rules` 結果 (userRules + officialRules 全文)**
-- 「対症療法ではなく根本原因を特定せよ。既存成果物 と rule カタログを仮説予選材料に使う」
+- 「対症療法ではなく根本原因を特定せよ。既存成果物 と rule カタログを仮説の優先順位付けに使う」
 - trace モードの場合: 起点ファイル指定
 
 **記録先**: メインが Write で `debug-report.md`
@@ -103,10 +108,10 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 - 症状が特定 library / framework 依存
 - 環境依存 (OS / runtime version) の疑い
 
-実施する場合、`shinaps-tech-surveyor` → `shinaps-survey-validator` の 2 段パイプ。
+実施する場合、`shinaps-tech-surveyor` → `shinaps-survey-validator` の順に 2 段階で実行する。
 
 - **shinaps-tech-surveyor プロンプト**: `input.md` + `debug-validated.md` + `search_rules` 結果 + 「関連 library / API の既知バグ / breaking change / 挙動仕様を WebSearch + GitHub Issue で調査」
-- **shinaps-survey-validator プロンプト**: `raw/survey.md` 全文 + `search_rules` 結果 + 「出典 URL を再確認、CLAUDE.md / rule 逆行する候補は Critical」
+- **shinaps-survey-validator プロンプト**: `raw/survey.md` 全文 + `search_rules` 結果 + 「出典 URL を再確認、CLAUDE.md / rule に反する候補は Critical」
 
 **記録先**: メインが Write で `raw/survey.md` / `raw/survey-validated.md`
 
@@ -115,18 +120,18 @@ Phase 4.5 実施後、`debug-validated.md` を更新して「## 関連する外
 ### Phase 5: 次アクション選択
 
 root-cause または contributing-factor が 1 件以上あれば `AskUserQuestion` で:
-- **修正実装に進む** (`/shinaps:dev-claude-ultra` へ橋渡し) (推奨)
+- **修正実装に進む** (`/shinaps:dev-claude` へ引き継ぐ) (推奨)
 - **追加調査を依頼する** (Phase 7 へ)
 - **保存のみで終了**
 
 **根本原因確定時に ローカル成果物（implementation.md / 調査・レビューレポート）** で「症状 → 根本原因 → 修正方針」を記録。
 
-### Phase 6: /shinaps:dev-claude-ultra への橋渡し (修正実装選択時)
+### Phase 6: /shinaps:dev-claude への引き継ぎ (修正実装選択時)
 
-`debug-validated.md` のパスを渡す。dev の入口は Phase 1 でこのファイルを読み、root-cause / contributing-factor を修正タスクとして扱う。利用者が1体での実行を指定した場合は `shinaps:dev-claude` を使う。
+`debug-validated.md` のパスを渡す。dev の入口は Phase 1 でこのファイルを読み、root-cause / contributing-factor を修正タスクとして扱う。担当と人数はdevのメインが作業に応じて判断する。
 
 ```
-Skill(skill="shinaps:dev-claude-ultra", args="以下のデバッグ結果に基づき根本原因を修正する。詳細は .shinaps/work/debug/{ts}-{slug}/debug-validated.md を参照: {根本原因の 1 行サマリ}")
+Skill(skill="shinaps:dev-claude", args="以下のデバッグ結果に基づき根本原因を修正する。詳細は .shinaps/work/debug/{ts}-{slug}/debug-validated.md を参照: {根本原因の 1 行サマリ}")
 ```
 
 ### Phase 7: 追加調査 (選択時)
@@ -138,7 +143,9 @@ Skill(skill="shinaps:dev-claude-ultra", args="以下のデバッグ結果に基
 - **根本原因志向**: 対症療法を推奨しない、根本解決を導く
 - **多角的調査**: コード + docs + WebSearch + GitHub Issue を組み合わせる
 - **二段検証**: debugger の仮説を debug-validator が必ず実コードで検証
-- **rule と既存成果物を仮説予選に活用**: `search_rules` の結果と、今回の依頼に関連する Git・spec・raw report の根拠を debugger prompt に埋め込む
+- **rule と既存成果物を仮説の優先順位付けに活用**: `search_rules` の結果と、今回の依頼に関連する Git・spec・raw report の根拠を debugger prompt に埋め込む
 - **subagent は文字列応答のみ**: ファイル書き込みは必ずメインが担当
 - **生レポート保存厳守**: すべての subagent 応答を全文保存
-- **根本原因確定時に ローカル成果物（implementation.md / 調査・レビューレポート）**: 未来の自分と別 AI agent が辿れるように
+- **根本原因確定時に ローカル成果物（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/dev-claude/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: dev-claude
-description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化をそれぞれ1体で確認する。実装依頼で1体での実行を指定されたときに使う。コミットは許可と工程の条件に従い、Linear進行ではQAへ結果を返す。
-argument-hint: <実装したい機能・解決したい課題>
+description: 実装の不確実性・影響範囲・失敗時の影響から必要な担当と人数を決め、計画・実装・検証・独立レビューを進める。途中の新しい根拠で体制を追加する。コミットは許可に従い、Linear進行ではQAへ結果を返す。
 ---
 
-# 開発（同じ役割 1 体）
+# 作業に応じた体制で開発する
 
-同じ役割の担当数は 1 体。[工程](../../references/dev/workflow.md)と[起動手順](../../references/dev/launch.md)を読み、この担当数で進める。
-タスクの確定は[工程](../../references/dev/workflow.md)の Phase 1 に従う（引数が無いだけでは終了しない）。
+[体制の判断](../../references/dev/staffing.md)・[工程](../../references/dev/workflow.md)・[起動手順](../../references/dev/launch.md)を読む。人数を入口名で固定しない。linear-executeから渡された初期体制を引き継ぎ、なければメインが関連コードを確認して設計前に決める。途中でも必要な役割・人数を追加する。
+
+依頼や成果物からタスクが確定していれば、形式的な引数の再入力を求めずPhase 1から進める。

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

@@ -1,9 +1,14 @@
 ---
 name: explore
-description: バグか確定していない違和感、既存挙動の「なぜ」、実装方針や変更影響について、人間が理解・納得できるまで質問を重ねる対話型 read-only 調査スキル。質問ごとにコード、テスト、設定、git history、必要な公式情報を調べ、confirmed / inference / unknown を分けて根拠付きで回答する。debug のように根本原因確定を急がず、spec のように仕様策定を目的にせず、実装は行わない。理解が揃い実装内容に合意したら exploration.md を /shinaps:dev-claude-ultra に直接橋渡しする。「今の実装はどうなっている？」「なぜこうなる？」「この変更はどこに効く？」「実装前に一緒に調べたい」「質問しながら理解したい」で使う
+description: バグか確定していない違和感、既存挙動の「なぜ」、実装方針や変更影響について、人間が理解・納得できるまで質問を重ねる対話型 read-only 調査スキル。質問ごとにコード、テスト、設定、git history、必要な公式情報を調べ、confirmed / inference / unknown を分けて根拠付きで回答する。debug のように根本原因確定を急がず、spec のように仕様策定を目的にせず、実装は行わない。理解が揃い実装内容に合意したら exploration.md を /shinaps:dev-claude に直接渡す。「今の実装はどうなっている？」「なぜこうなる？」「この変更はどこに効く？」「実装前に一緒に調べたい」「質問しながら理解したい」で使う
 argument-hint: <調べたいバグ・挙動・実装上の疑問（省略可）>
 ---
 
+## 質問の実行経路（全工程に優先）
+
+対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
+
+
 ## 作業記録の保存先
 
 作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
@@ -25,7 +30,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 | `shinaps:explore` | 現状・因果・選択肢を対話で理解する | `exploration.md` |
 | `shinaps:debug` | 具体的な不具合の根本原因を仮説検証で確定する | `debug-validated.md` |
 | `shinaps:spec` | 要望と受け入れ条件を確定する | `spec.md` |
-| `shinaps:dev-claude-ultra`（1体は `shinaps:dev-claude`） | 計画し、実装・検証・セルフレビューする | コード + `implementation.md` |
+| `shinaps:dev-claude` | 計画し、実装・検証・セルフレビューする | コード + `implementation.md` |
 
 `explore` では最初から「バグ」「採用案」「修正対象」を決めつけない。調査中に不具合らしさが高まっても、自動で `debug` や dev の入口へ移らず、人間の質問に答え続ける。
 
@@ -55,7 +60,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 ```
 .shinaps/work/explorations/{YYYYMMDD-HHMMSS}-{slug}/
-├── exploration.md                 ← 現在の理解と dev handoff 契約を保つ living document
+├── exploration.md                 ← 現在の理解と dev handoff 契約を保つ、随時更新する文書
 ├── question-log.md                ← 質問と回答の要約。会話の逐語録にはしない
 └── raw/
     ├── investigation-001.md       ← 各ラウンドの investigator 生レポート
@@ -115,7 +120,7 @@ investigator の回答をそのまま転送しない。結論を支える主要
 - production deploy、外部データ変更、依存追加など調査を越える操作は行わない
 - 確認できない主張は `inference` または `unknown` に下げ、解消に必要な証拠を示す
 
-### Phase 4: 回答と living document 更新
+### Phase 4: 回答と exploration.md 更新
 
 各ラウンドの回答は次の順で短く提示する。
 
@@ -123,7 +128,7 @@ investigator の回答をそのまま転送しない。結論を支える主要
 2. **確認できたこと (`confirmed`)** — file:line / test / docs URL を添える
 3. **推測 (`inference`)** — 推測である理由と確信度を添える
 4. **まだ分からないこと (`unknown`)** — 何を見れば確定できるかを添える
-5. **次に掘る価値が高い論点** — 最大 3 件
+5. **次に調べる価値が高い論点** — 最大 3 件
 
 回答後、`question-log.md` には質問と回答の要約だけを追記し、`exploration.md` を現在の理解へ更新する。confirmed finding を支えるローカルファイルは、現在内容の hash (`git hash-object` など、object を書き込まない read-only 計算) を関連リソースへ記録する。過去の誤った仮説を残す必要がある場合は「却下済み」と明記し、現在の結論と混ぜない。
 
@@ -180,7 +185,7 @@ investigator の回答をそのまま転送しない。結論を支える主要
 
 実装内容がまだ曖昧な状態で「実装へ進む」が選ばれたら、望む変更を 1 問ずつ確認する。未解決点が残る場合は、残したまま実装するか調査を続けるかを選んでもらう。
 
-### Phase 6: `/shinaps:dev-claude-ultra` への橋渡し
+### Phase 6: `/shinaps:dev-claude` への引き継ぎ
 
 実装へ進む前に `exploration.md` の「実装 handoff」セクションを確定する。
 
@@ -195,10 +200,10 @@ handoff 直前に confirmed 根拠の content hash を再計算し、`evidenceSn
 
 安定した設計判断や再利用価値のある発見だけをローカル成果物（implementation.md / 調査・レビューレポート）へ短く記録する。質問ログや長いコード引用は記録しない。
 
-中間 handoff ファイルは作らず、`exploration.md` のパスを直接渡す。利用者が1体での実行を指定した場合は `shinaps:dev-claude` を使う。
+中間 handoff ファイルは作らず、`exploration.md` のパスを直接渡す。担当と人数はdevのメインが作業に応じて判断する。
 
 ```
-Skill(skill="shinaps:dev-claude-ultra", args="以下の対話調査で合意した変更を実装する。詳細は .shinaps/work/explorations/{ts}-{slug}/exploration.md を参照: {実装目的の 1 行サマリ}")
+Skill(skill="shinaps:dev-claude", args="以下の対話調査で合意した変更を実装する。詳細は .shinaps/work/explorations/{ts}-{slug}/exploration.md を参照: {実装目的の 1 行サマリ}")
 ```
 
 dev の入口は「実装 handoff」の `status: ready` と `evidenceSnapshot` の内容ハッシュを確認してから合意済み変更・confirmed findings・未解決点を取り込む。`exploration.md` と同ディレクトリの `raw/investigation-*.md` を既存実装調査として再利用し、情報が不足・陳腐化している場合だけ `shinaps-explorer` で補完する。
@@ -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/extract-rules/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: extract-rules
-description: 過去 PR のレビューコメントから shinaps-ai の rules を bulk 生成する skill。新規リポジトリ着手時、または search_rules の userRules が空 / 少ない (5 件未満) ときに提案・起動。owner / repo / since を確認し、bot 除外 + gh api pulls で 100 PR ブロック単位に fetch → LLM で規約抽出 → record_rules で投入 → 続行確認 → 完了 report まで完走。shinaps-ai server 未登録時は search_rules 呼び出しが自動で失敗して abort する。
+description: 過去 PR のレビューコメントから shinaps-ai の rules を bulk 生成する skill。新規リポジトリ着手時、または search_rules の userRules が空 / 少ない (5 件未満) ときに提案・起動。owner / repo / since を確認し、bot 除外 + gh api pulls で 100 PR ブロック単位に fetch → LLM で規約抽出 → record_rules で投入 → 続行確認 → 完了 report まで実行する。shinaps-ai server 未登録時は search_rules 呼び出しが自動で失敗して abort する。
 argument-hint: (引数なし、対話で owner-repo / since を確認)
 ---
 
@@ -18,7 +18,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 # shinaps:extract-rules — 過去 PR review から rules を bulk 生成
 
-新規リポジトリ着手時、または既存 userRules が薄いときに、過去 PR のレビューコメントから規約を bulk import する skill。shinaps-ai サーバは GitHub API も LLM も呼ばず、すべて Claude Code 側のあなた (= AI) が `gh` / 既存 MCP tools 経由で実行する (token / repo 内容をサーバ境界に置かない)。
+新規リポジトリ着手時、または既存 userRules が少ないときに、過去 PR のレビューコメントから規約を bulk import する skill。shinaps-ai サーバは GitHub API も LLM も呼ばず、すべて Claude Code 側のあなた (= AI) が `gh` / 既存 MCP tools 経由で実行する (token / repo 内容をサーバ境界に置かない)。
 
 ## Step 0. 対象 repo を環境から決定する (MUST)
 
@@ -63,7 +63,7 @@ PR description (本文) は対象外。あくまで「レビュー観点」を
 
 ## Step 6. 既存 rules 把握
 
-100 PR を 1 ブロックとして処理する。ブロックの開始時に必ず shinaps-ai MCP server の `search_rules({ repoOwner, repoName })` を呼んで、既存 userRules を取得する (facet を渡さないので officialRules は空、userRules は継承マージで scope=user / repo_owner / repo の全件、最大 200)。これを「新規 (= `record_rules` の投入対象に含める) か、既存に被せる `update_rule` か」を判断する material にする。
+100 PR を 1 ブロックとして処理する。ブロックの開始時に必ず shinaps-ai MCP server の `search_rules({ repoOwner, repoName })` を呼んで、既存 userRules を取得する (facet を渡さないので officialRules は空、userRules は継承マージで scope=user / repo_owner / repo の全件、最大 200)。これを「新規 (= `record_rules` の投入対象に含める) か、既存 rule を更新する `update_rule` か」を判断する材料にする。
 
 ## Step 7. rules 生成と投入
 
@@ -86,7 +86,7 @@ Good/Bad サンプルコード (examples) の付け方:
 
 投入手順:
 
-- 候補を既存 rules と照合し、**新規** (該当 rule 不在) だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, rules: [{ title, why, recommend?, avoid?, kind?, labels?, examples?, sourceUrls? }, ...] })` で **1 call bulk 投入** する。`labels` は language / platform / framework / topic の slug 配列 (`list_search_facets` の master 登録済みのみ、language/platform/framework は 1 rule に各 1 つまで) (1 call 最大 100 件、超えたら分割。同一 title の重複は入力段階で INPUT_INVALID)。extract-rules は対象 repo の PR レビューから抽出する性質上 scope=repo (当該 repo 限定) がデフォルト。横断ルールとして残したい場合だけユーザー判断で `scope: 'user'` に格上げ。**格上げするときは why / recommend / avoid / examples を当該 repo の固有文脈 (内部 API 名・モジュール構成・ドメイン固有の識別子) から切り離し、他プロジェクトでも適用イメージが湧く汎用的な表現・汎用サンプルに解釈し直してから登録する** (scope=repo のままなら repo 固有の具体的な記述・コード片で良い)。title は 200 字以内、規約本文は why (必須、なぜこの規約か、2000 字以内) / recommend (推奨行動、任意、1000 字以内) / avoid (避けるべきこと、任意、1000 字以内) の 3 フィールドに構造化する
+- 候補を既存 rules と照合し、**新規** (該当 rule 不在) だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, rules: [{ title, why, recommend?, avoid?, kind?, labels?, examples?, sourceUrls? }, ...] })` で **1 call bulk 投入** する。`labels` は language / platform / framework / topic の slug 配列 (`list_search_facets` の master 登録済みのみ、language/platform/framework は 1 rule に各 1 つまで) (1 call 最大 100 件、超えたら分割。同一 title の重複は入力段階で INPUT_INVALID)。extract-rules は対象 repo の PR レビューから抽出する性質上 scope=repo (当該 repo 限定) がデフォルト。横断ルールとして残したい場合だけユーザー判断で `scope: 'user'` に格上げ。**格上げするときは why / recommend / avoid / examples を当該 repo の固有文脈 (内部 API 名・モジュール構成・ドメイン固有の識別子) から切り離し、他プロジェクトでも適用場面を想定できる汎用的な表現・汎用サンプルに解釈し直してから登録する** (scope=repo のままなら repo 固有の具体的な記述・コード片で良い)。title は 200 字以内、規約本文は why (必須、なぜこの規約か、2000 字以内) / recommend (推奨行動、任意、1000 字以内) / avoid (避けるべきこと、任意、1000 字以内) の 3 フィールドに構造化する
 - 戻り値の `skipped: { title, existingRuleId, existingWhy, existingRecommend, existingAvoid, existingLabels, existingExamples, existingSourceUrls }[]` は「既存と title 重複して投入されなかった候補」。新しい why/recommend/avoid と existing* が異なるなら **ユーザーに diff を提示して同意を取る** (examples / sourceUrls の差分も同様):
 
 > 既存 rule "no-unused-vars" が見つかりました。why/recommend/avoid の差分:

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

@@ -1,15 +1,23 @@
 ---
 name: linear-execute
-description: Linearの実行でCodexから受けた実装・修正・コミット依頼を実行し結果を報告する。直接の開発進行依頼は設定と許可を確認してCodexへ引き渡す。相談・Issue整理はlinear-planを使う。
+description: Linearの開発で、Codexから受けた実装・修正・コミット依頼を実行する。作業先の設定の実装担当がManagedの入口なら、Claudeが進行役として実装からQA・許可された公開まで進める。それ以外の開発進行依頼はCodexへ引き渡す。相談・Issue整理はlinear-planを使う。
 ---
 
 # Linearの開発でClaudeが行うこと
 
-初版では、Codexが進行・Agent QA・人への窓口を担当する。作業先リポジトリの設定の `implementation_skill` がClaudeの入口のとき、ClaudeはAI Terminal Bridge（以下Bridge）経由の依頼で、技術調査と実装・修正を担当する。担当を入れ替えない。
+開発進行を依頼されたら、まず[設定の読み方](../../references/linear/configuration.md#設定の読み方)で作業先の設定を読み、`implementation_skill` で役割を決める。設定が真に未設定なら、下の「Codexの依頼なしで起動された場合」の初期設定へ進む。
+
+- 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の状態を照合し、一致すれば既存の許可の範囲で人へ再確認せず次の工程へ進む。
 
@@ -25,22 +33,45 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 
 - 依頼の範囲・受入条件・Gitの作業ディレクトリ・ブランチ・既存差分・許可範囲を確認する。
 - Codexから依頼された実装・修正は、依頼の対象Issueに紐づく。Claudeは別のIssueを作らない。
-- 実装・修正には、依頼で指定された入口（`shinaps:dev-claude` または `shinaps:dev-claude-ultra`）を使う。指定と設定を照合し、欠落・不一致ならCodexへ確認してから進め、受信側で入口を変えない。devの入口は内部で簡素化・規約照合・レビューを行うので、これらを別に起動しない。入口を使えない場合は、独自の手順で代わりに実装せずCodexへ報告する。
+- 実装・修正には、依頼で指定された入口（`shinaps:dev-claude`）を使う。指定と設定を照合し、欠落・不一致ならCodexへ確認してから進め、受信側で入口を変えない。devの入口は内部で簡素化・規約照合・レビューを行うので、これらを別に起動しない。入口を使えない場合は、独自の手順で代わりに実装せずCodexへ報告する。
 - devの入口の委託（サブエージェント）は、依頼の許可範囲に `dev_delegation` が書かれている場合だけ使う。許可範囲に `dev_delegation` がない依頼では委託しない。worktreeの作成は含まない。
 - 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の入口で進行する
+
+実行範囲、開始時に固定するもの、継続とゴールは [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)まで続ける。
+
 ## Codexの依頼なしで起動された場合
 
 相談・Issue整理・設定変更は `shinaps:linear-plan` を使う。実行範囲は [execution.md](../../references/linear/execution.md) に従って引き渡す。
 
 - 利用者から直接依頼された実作業（開発進行の依頼を除く）は、着手前に [references/issue.md](../../references/linear/issue.md) の「着手前に作業をIssueへ紐づける」に従う。Issueの作成は利用者がその場で依頼した場合だけ行い、設定の `issue_update` を根拠にしない。
 - 利用者から明示的にIssueの整理を依頼された場合は、[references/issue.md](../../references/linear/issue.md) に従って整理する。Issueの更新は、依頼で指定された範囲だけにする（設定の有無にかかわらない）。
-- 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、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の導入）を利用者へ案内する。
+
+## 初期体制と途中の増員
+
+[Issue開始時の実装体制](../../references/linear/execution.md#issue開始時の実装体制)と[体制の判断](../../references/dev/staffing.md)に従う。進行役は各Issueの初期体制を設計前に決めて渡し、実装側のメインは現物と照合して必要な担当を追加できる。Claudeが実装の受け手の場合も同じ基準を使い、変更理由と体制を進行役へ返す。Managedの進行役も初期体制をleadへ渡す。人数の固定された入口へ戻さず、必須検証と独立性を保つ。

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

@@ -20,11 +20,11 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 
 呼び出し時に「照合のみ」と指定された場合は、以下の修正工程を実行せず、findings と修正案を呼び出し元へ返す。並行レビューが同じ差分を確認できるよう、対象ファイルとルールを変更せず、修正の質問も呼び出し元に集約する。
 
-このスキルは「commit / report 直前の self-review」を確実にやるためのバッチ照合手順書。CLAUDE.md に「セルフレビュー直前 → search_rules で規約照合」と書かれていても AI (あなた) が頻繁にスキップする現実への対症療法として、ユーザーが手動で発火するためにある。
+このスキルは「commit / report 直前の self-review」を確実に行うためのバッチ照合手順書。CLAUDE.md に「セルフレビュー直前 → search_rules で規約照合」と書かれていても AI (あなた) が頻繁にスキップするので、その対策としてユーザーが手動で起動するためにある。
 
-照合対象は **ファイルの現状全文** であって diff ではない。diff の hunk だけでは「この関数全体の責務が正しいか」「この命名は周囲と揃っているか」「規約が要求する構造がファイル内に揃っているか」を判断できず、追加行だけ見て規約準拠に見えても、ファイル全体としては規約から外れているケースを取り逃すため。git は **どのファイルを見るか** を決める用途と、finding が **今回の変更に含まれる箇所か** を判定する用途に使う。
+照合対象は **ファイルの現状全文** であって diff ではない。diff の hunk だけでは「この関数全体の責務が正しいか」「この命名は周囲と揃っているか」「規約が要求する構造がファイル内に揃っているか」を判断できず、追加行だけ見て規約準拠に見えても、ファイル全体としては規約から外れているケースを見落とすため。git は **どのファイルを見るか** を決める用途と、finding が **今回の変更に含まれる箇所か** を判定する用途に使う。
 
-計画段階では発火しない。rule の大半はコメントの WHY / 命名 / import 経路といったコードレベルの規約で、自然言語の計画テキストからは検出できないため。計画段階で拾う価値がある設計レベルの規約違反は `shinaps-plan-reviewer` が担当する。
+計画段階では起動しない。rule の大半はコメントの WHY / 命名 / import 経路といったコードレベルの規約で、自然言語の計画テキストからは検出できないため。計画段階で指摘する価値がある設計レベルの規約違反は `shinaps-plan-reviewer` が担当する。
 
 shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて Claude Code 側のあなたが手元の `git` / `Read` / 既存 MCP tools で実行する (private repo の内容をサーバ境界に渡さない設計)。
 
@@ -45,11 +45,11 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
    - **ファイル / ディレクトリ path** (例: `apps/api/src/mcp/`) → その path 配下のファイルをそのまま対象集合にする (変更の有無を問わない)。ディレクトリなら `git ls-files <path>` で列挙する
    - **PR URL** (例: `https://github.com/owner/repo/pull/123`) → `gh pr diff 123 --repo owner/repo --name-only` で変更ファイル一覧を取得。カレント repo と同じなら `--repo` は省略可
    - **commit SHA / range** (例: `abc123` / `main..feature` / `HEAD~3..HEAD`) → `git diff --name-only <range>` で変更ファイル一覧を取得
-2. 明示指定がなければ `git diff --name-only HEAD` (= staged + unstaged の合計、ローカルで触ったファイル全部)
+2. 明示指定がなければ `git diff --name-only HEAD` (= staged + unstaged の合計、ローカルで変更したファイルすべて)
 3. それでも 0 件なら **ユーザーに確認**: 「変更がありません。直近の commit (`git diff --name-only HEAD~`) または特定のファイル / commit / PR を対象にしますか?」
 4. 削除されたファイルは対象集合から除く (現状が存在しない)
 
-対象が決まったらユーザーに「以下 N ファイルの現状を refine します」と 1 行で宣言してから先に進む。**Step 3 で各 agent に渡すファイル一覧と「変更範囲の確認コマンド」も、ここで決めた集合に必ず合わせること** (agent が独立に `git diff HEAD` を叩いて対象を取り違えないよう prompt に具体コマンドを埋め込む)。
+対象が決まったらユーザーに「以下 N ファイルの現状を refine します」と 1 行で宣言してから先に進む。**Step 3 で各 agent に渡すファイル一覧と「変更範囲の確認コマンド」も、ここで決めた集合に必ず合わせること** (agent が独立に `git diff HEAD` を実行して対象を取り違えないよう prompt に具体コマンドを埋め込む)。
 
 **ファイル数による一律の上限は設けない**。確定した対象集合を維持し、件数の多さだけを理由に対象の縮小やユーザーへの分割確認を求めない。対象の内容量が大きい場合は、ファイルの行数・内容量と関連性（ディレクトリ、機能、依存関係）を見て自動的にバッチへ分ける。小規模なら分割は不要。関連ファイルはできるだけ同じバッチにまとめ、バッチをまたぐ契約は集約時に照合する。
 
@@ -59,9 +59,9 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 
 - shinaps-ai MCP server の `list_search_facets()` で facet master (languages / platforms / frameworks / topics の登録済 slug 空間) を取得 → 対象ファイルの拡張子・パス・内容から関係する facet slug を推定して確定
 - `list_search_facets()` の `versionTargets` と manifest / lockfile / compiler config / deployment target を照合し、確認できたバージョンだけを `projectVersions: [{ targetKind, targetSlug, version }]` に指定する。facet取得後に検索する。targetやバージョンは推測しない。確認できない対象は条件付きルールが除外されるため、共通ルールのみの照合になったことを結果に明記する。
-- shinaps-ai MCP server の `search_rules({ repoOwner, repoName, languages?, platforms?, frameworks?, topics?, kind?, projectVersions? })` を呼ぶ → userRules + officialRules (両方を照合対象にする。userRules は facet に関係なく継承マージ全件、officialRules は admin が保存した rule のうち指定 facet とバージョン適用条件に一致するものへ絞られる（承認操作は不要）)。**repoOwner / repoName は現在の git workspace から必ず渡す** (`gh repo view` or `git remote get-url origin` から取得)。userRules は scope=user (横断) + scope=repo_owner (owner 一致) + scope=repo (owner+name 一致) の継承マージで返る。各 rule に乗る `scope` flag を見て「横断 / owner 限定 / repo 限定」を判別できる。facet を 1 つも指定せずに呼ぶと officialRules は空配列で返るので、必ず推定 facet を 1 つ以上指定すること。`kind` は通常指定しない (対象ファイル全体を rule 集合と広く照合する用途のため、絞り込むと見落としが増える)
+- shinaps-ai MCP server の `search_rules({ repoOwner, repoName, languages?, platforms?, frameworks?, topics?, kind?, projectVersions? })` を呼ぶ → userRules + officialRules (両方を照合対象にする。userRules は facet に関係なく継承マージ全件、officialRules は admin が保存した rule のうち指定 facet とバージョン適用条件に一致するものへ絞られる（承認操作は不要）)。**repoOwner / repoName は現在の git workspace から必ず渡す** (`gh repo view` or `git remote get-url origin` から取得)。userRules は scope=user (横断) + scope=repo_owner (owner 一致) + scope=repo (owner+name 一致) の継承マージで返る。各 rule に付く `scope` flag を見て「横断 / owner 限定 / repo 限定」を判別できる。facet を 1 つも指定せずに呼ぶと officialRules は空配列で返るので、必ず推定 facet を 1 つ以上指定すること。`kind` は通常指定しない (対象ファイル全体を rule 集合と広く照合する用途のため、絞り込むと見落としが増える)
 - repo root の `AGENTS.md` / `CLAUDE.md` を Read (プロジェクト規約)
-- AGENTS.md が `docs/` 等を「source of truth」として参照していたら **その docs も Read** (今回触った領域に関連するものに限定して良い)
+- AGENTS.md が `docs/` 等を「source of truth」として参照していたら **その docs も Read** (今回変更した領域に関連するものに限定して良い)
 - グローバル `~/.claude/CLAUDE.md` の `## コメントルール` `## 実装・設計に関して` 等の節 (一度読んだセッションなら conversation history で代替可)
 - 該当 repo の auto-memory `~/.claude/projects/<slug>/memory/MEMORY.md` がもしあれば Read
 
@@ -148,7 +148,7 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 集約後の finding を振り分ける。**`scope` が第一の分岐**:
 
 - **`changed`** (今回の変更に含まれる箇所) → 以下の「自明な修正」なら自動適用、それ以外は要確認
-- **`pre-existing`** (今回触っていない既存箇所) → severity を問わず **必ず要確認に回す**。自動修正しない
+- **`pre-existing`** (今回変更していない既存箇所) → severity を問わず **必ず要確認に回す**。自動修正しない
 
 `pre-existing` を自動修正しないのは、今回の作業と無関係な差分が commit に混入して、レビュアーが「この変更は何のためか」を追えなくなるため。既存箇所の指摘は「別 commit に分ける」「後回しにする」判断がユーザー側にある。
 
@@ -160,11 +160,11 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 - 既存パターンへの機械的な追従 (隣接コードと同じ流儀に揃えるだけ)
 - import 経路や命名の規約違反で、直し先が明白なもの
 
-自動修正を終えたら型 / lint / test を回して green を確認する。修正内容は Step 6 のサマリで「何をどう直したか」を file 単位で必ず一覧報告する (ユーザーが事後確認できるように)。
+自動修正を終えたら型 / lint / test を回して、すべて成功することを確認する。修正内容は Step 6 のサマリで「何をどう直したか」を file 単位で必ず一覧報告する (ユーザーが事後確認できるように)。
 
 ### 判断が必要なもの (要確認)
 
-以下に該当する finding は `AskUserQuestion` で確認する。**迷ったら確認側に倒す**:
+以下に該当する finding は `AskUserQuestion` で確認する。**迷ったら要確認にする**:
 
 - **`scope` が `pre-existing` のもの全般** (今回の変更と切り離して判断すべきなので、自明に見えても確認する)
 - 設計トレードオフがある (複数の修正方針があり得る / 影響範囲が広い / 構造変更を伴う)
@@ -174,9 +174,9 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 選択肢は 4 つ:
 
 1. **修正する** — どう直すかを 1-2 文で提案 (agent が返した `detail` を活用)。承認されたら `Edit` / `Write` で実行
-2. **このまま許容する** — 妥当な理由があるとき。理由を今回のローカル成果物（implementation.md / 調査・レビューレポート）に残す (将来の自分が「なぜ違反のままにしたか」を辿れるように)
+2. **このまま許容する** — 妥当な理由があるとき。理由を今回のローカル成果物（implementation.md / 調査・レビューレポート）に残す (後から「なぜ違反のままにしたか」を辿れるように)
 3. **ルールの方を修正する** — 規約自体が現実と乖離している場合。shinaps-ai MCP server の `record_rule` (新規) or `update_rule` (既存修正) を実行。新規 record_rule のときは scope (user / repo_owner / repo) も選ばせる (横断的なら user、この repo 限定なら repo)
-4. **後回し** — 別タスクとして扱う。`TaskCreate` で TODO 化し、後の作業セッションで拾えるようにする
+4. **後回し** — 別タスクとして扱う。`TaskCreate` で TODO 化し、後の作業セッションで着手できるようにする
 
 **提示順は `changed` を先、`pre-existing` を後**。それぞれの中では Violation → Improvement → Question の順。各 finding には `pre-existing` かどうかを明示して提示する (ユーザーが「今回の commit に混ぜるか」を判断する材料になるため)。件数が少なければ 1 回の `AskUserQuestion` に複数 question をまとめてよい (各 finding には前提説明を添える)。
 
@@ -189,17 +189,17 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 - 検出 / 処理した finding の総数と内訳 (自動修正 X 件 / 確認の上修正 Y 件 / 許容 Z 件 / rule 更新 W 件 / 後回し V 件)
 - **`changed` と `pre-existing` の内訳** (既存箇所の指摘が何件あり、そのうち何件を今回直したか。今回の変更に無関係な修正がどれだけ混ざったかをユーザーが把握できるように)
 - **自動修正した内容の一覧** (file + 1 行の何をどう直したか。ユーザーが事後確認する唯一の接点なので省略しない)
-- 新しく `record_rule` / `update_rule` した内容があれば「次セッション以降に効きます」と明示
+- 新しく `record_rule` / `update_rule` した内容があれば「次セッション以降に適用されます」と明示
 - まだ未処理の Question / 後回しの TaskCreate id を列挙
 
-この後 user は通常 `git add` / commit に進む想定なので、refine 自体は commit しない (ユーザー操作の自然な境界を奪わない)。
+この後 user は通常 `git add` / commit に進む想定なので、refine 自体は commit しない (commit はユーザーが行う操作として残す)。
 
 ## 注意点
 
 - テストに関わる指摘と修正の判断は [テスト方針](../../references/testing.md) に従う
-- **Info レベルは report しない**。Critical / Warning 相当だけを扱う。ノイズが多いと「規約照合は手間」というネガティブ印象が定着するため
+- **Info レベルは report しない**。Critical / Warning 相当だけを扱う。ノイズが多いと「規約照合は手間」という否定的な印象が定着するため
 - **1体で対象全体を確認する**。対象量が増えても担当数を増やさず、同じ担当へ続きのバッチを渡す
-- **Agent への rule 受け渡しは full text**。id + title だけを渡して agent 側に search_rules を再取得させると shinaps MCP を N 回叩くことになるため無駄。メインスレッドが 1 度取得したものを prompt に貼る
+- **Agent への rule 受け渡しは full text**。id + title だけを渡して agent 側に search_rules を再取得させると shinaps MCP を N 回呼ぶことになるため無駄。メインスレッドが 1 度取得したものを prompt に貼る
 - **根拠を確認する**: 担当は渡された規約と対象全体を照合し、規約や docs の根拠がある指摘だけを返す
 - finding 同士が重複していたら Step 4 の集約で統合する (「同じファイルで console.log 3 件、まとめて削除しますか?」等)
 - 規約が 0 件 (= `search_rules` の userRules / officialRules が空) のとき: 「rule が登録されていません。今日の作業で rule 化したい習慣はありますか?」と逆に質問して、`record_rule` を引き出すきっかけにする (この場合 Step 2-4 はスキップ)

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) に従う。
@@ -86,7 +91,7 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 - `input.md` 全文
 - **Phase 1 で作成した既存成果物の要約**
 - **前準備の `search_rules` 結果**
-- 「(a) 採用 API / library / 言語機能は現代的か、(b) より良い代替があるか、(c) 既知の落とし穴、(d) 採用バージョンの安全性、を WebSearch / WebFetch で調査せよ。既存スタック + rule カタログ整合性を予選条件に」
+- 「(a) 採用 API / library / 言語機能は現代的か、(b) より良い代替があるか、(c) 既知の落とし穴、(d) 採用バージョンの安全性、を WebSearch / WebFetch で調査せよ。既存スタック + rule カタログ整合性を絞り込み条件に」
 
 **記録先**: メインが Write で `review.md` / `tech-survey.md` に全文保存
 
@@ -115,18 +120,18 @@ tech-surveyor が「特筆事項なし」以外を返した場合のみ起動。
 ### Phase 5: 次アクション選択
 
 確定指摘が 1 件以上あれば `AskUserQuestion` で:
-- **修正実装に進む** (`/shinaps:dev-claude-ultra` へ橋渡し) (推奨)
+- **修正実装に進む** (`/shinaps:dev-claude` へ引き継ぐ) (推奨)
 - **PR にコメント投稿する** (PR モードのみ)
 - **ローカル保存のみで終了**
 
 **修正実装選択時 (Phase 6 前) に ローカル成果物（implementation.md / 調査・レビューレポート）** で修正方針決定の記録を残す。
 
-### Phase 6: /shinaps:dev-claude-ultra への橋渡し (修正実装選択時)
+### Phase 6: /shinaps:dev-claude への引き継ぎ (修正実装選択時)
 
-`review-validated.md` の確定指摘を修正タスクとして渡す。dev の入口は Phase 1 でこのファイルを読み、確定指摘を修正対象として扱う。利用者が1体での実行を指定した場合は `shinaps:dev-claude` を使う。
+`review-validated.md` の確定指摘を修正タスクとして渡す。dev の入口は Phase 1 でこのファイルを読み、確定指摘を修正対象として扱う。担当と人数はdevのメインが作業に応じて判断する。
 
 ```
-Skill(skill="shinaps:dev-claude-ultra", args="以下のレビュー指摘を修正する。詳細は .shinaps/work/reviews/{ts}-{mode}/review-validated.md を参照: {修正タスクの 1 行サマリ}")
+Skill(skill="shinaps:dev-claude", args="以下のレビュー指摘を修正する。詳細は .shinaps/work/reviews/{ts}-{mode}/review-validated.md を参照: {修正タスクの 1 行サマリ}")
 ```
 
 ### Phase 7: PR コメント投稿 (PR モードかつ選択時)
@@ -138,9 +143,11 @@ Skill(skill="shinaps:dev-claude-ultra", args="以下のレビュー指摘を修
 - **並列 + 検証パイプライン**: reviewer + tech-surveyor を並列、その結果を review-validator が統合
 - **tech-surveyor は毎回起動**: 現代的な代替や落とし穴を必ずチェック
 - **survey-validator は省略可**: tech-surveyor が「特筆事項なし」なら起動しない
-- **rule 照合を reviewer / review-validator に bake**: `search_rules` 結果を prompt に埋め込む
+- **rule 照合を reviewer / review-validator に組み込む**: `search_rules` 結果を prompt に埋め込む
 - **subagent は文字列応答のみ**: raw/*.md への Write / Edit は必ずメインが担当
 - **生レポート保存厳守**: すべての subagent 応答を全文保存
 - **PR コメント投稿は要承認**: 外部影響のある操作は必ず本文確認
 - **diff が空ならエラー終了**: 何もしない旨を明示
 - **テストの判断**: [テスト方針](../../references/testing.md) に従う
+
+Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto経路は [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し、manual経路はWebStormのClaudeとBridgeを使う。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。