@shinaps/skills 0.32.0 → 0.33.0

package/README.md

@@ -1,6 +1,6 @@
 # shinaps-skills
 
-Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexにはそれぞれに適したplugin・カスタムエージェントとして配布し、Claude Managed Agentsには `ant apply` で作るエージェント・skill・環境の定義として提供する。スキルのダウンロードと導入にShinaps AIのアカウントは不要。サービスのrule検索・登録を使うときにアカウント作成と認証を行う。
+Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexにはそれぞれに適したplugin・カスタムエージェントとして配布する。実装はClaude Codeが行い、Codexは進行・QA・レビュー等を担当する。スキルのダウンロードと導入にShinaps AIのアカウントは不要。サービスのrule検索・登録を使うときにアカウント作成と認証を行う。
 
 ## プロジェクトごとの条件
 
@@ -14,12 +14,12 @@ sharedで採用する `instructions.md` は共有JSONの `references.specificati
 
 ## JSON設定の検証
 
-0.32.0から `.shinaps/linear.json`（`config_version: 1`）を使います。旧YAML・scalar review_flow・旧キーの共存は移行未完了として止め、[移行手順](plugins/shinaps-claude/references/linear/configuration.md#旧設定の移行)に従います。コメントの運用条件も補足へ移します。
+0.33.0から `.shinaps/linear.json`（`config_version: 2`）を使います。`config_version: 1`・`implementation_skill`・`review_flow.tool`・許可の `codex_task`/`managed_session:*`、旧YAML・scalar review_flowは受け付けず、[移行手順](plugins/shinaps-claude/references/linear/configuration.md#config_version-1-からの移行)に従います。
 
-CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.32.0` を導入し、`shinaps-skills --version` で確認します。`shinaps-skills validate-linear-config <明示ファイル>` は同梱schemaだけで検証し、ネットワーク取得・正本探索・Git操作・入力変更は行いません。`$schema` は固定URLによるエディタ補助で、契約の正本は[同梱schema](plugins/shinaps-claude/references/linear/configuration.schema.json)です。
+CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.33.0` を導入し、`shinaps-skills --version` で確認します。`shinaps-skills validate-linear-config <明示ファイル>` は同梱schemaだけで検証し、ネットワーク取得・正本探索・Git操作・入力変更は行いません。`$schema` は固定URLによるエディタ補助で、契約の正本は[同梱schema](plugins/shinaps-claude/references/linear/configuration.schema.json)です。
 
 ```sh
-npm install -g @shinaps/skills@0.32.0
+npm install -g @shinaps/skills@0.33.0
 shinaps-skills --version
 shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 ```
@@ -30,13 +30,13 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 |---|---|
 | `explore` | 対話しながら既存挙動と変更影響を調べる |
 | `spec` | 目的・仕様・実現方法を詰める |
-| `dev-claude` (Claudeのみ) / `dev-codex` (Codexのみ) / `dev-managed-cc` (Managed Agentsのみ) | メインが作業に応じて担当・人数を判断し、計画・実装・検証・独立レビューを進める |
+| `dev-claude` (Claudeのみ) | メインが作業に応じて担当・人数を判断し、計画・実装・検証・独立レビューを進める |
 | `debug` | 不具合の原因を検証する |
 | `review` | 差分や既存コードをレビューする |
 | `refine` | Shinaps AIのruleと実ファイルを照合する |
 | `extract-rules` | PRレビューからruleを抽出する |
 | `simplify` | 目的から見直して不要な構造や手順を削る |
-| `commit` | 各単位のreview_flowに従い、autoはAIがレビュー・コミット、manualはAIがstash・stage・提示し、人がレビュー・修正・コミットする |
+| `commit` | 各単位のreview_flowに従い、autoはAIがレビュー・コミット、manualはAIが退避・stage・提示し、人と修正を相談して、人の単位承認後にAIがコミットする |
 | `create-pr` | リポジトリの規約に合わせてPRを作成する |
 | `release` | 公開条件を確定し、対象バージョンの利用可能性を確認する |
 | `linear-plan` | 相談・必要なspec/explore・Issue作成と整理・プロジェクト設定を行い、実装前で止める |
@@ -44,9 +44,9 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 コミット・PR・リリースは、利用者の依頼またはLinear進行で合意済みの継続許可に従う。[共通設定](plugins/shinaps-claude/references/linear/configuration.md)・[担当と工程](plugins/shinaps-claude/references/linear/workflow.md)・[終了と待機](plugins/shinaps-claude/references/linear/execution.md)を参照し、必要な前工程が揃えば再確認せずに進む。単独スキル利用にはLinear進行や新しいゴールを必須にしない。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
 
-`linear-execute` は初版では利用者本人の環境向けで、進行とAgent QAは会話側が担当する（Claude・Codexの入口ではCodex、Managedの入口では linear-execute を実行する Claude Code または Codex）。運用項目は明示必須で、未記載を既定値で補わない。実装の担当は作業先の `.shinaps/linear.json` の `implementation_skill` で選ぶ。`dev-claude` はauto/manualともCodexがローカル `claude -p` を起動し、同じsessionをresumeする。manualのレビューUIは `review_flow.tool` で選ぶ。[CLI手順](plugins/shinaps-claude/references/linear/claude-cli.md)に従い、CLIの既存権限・model・effort・pluginsを保持する。`dev-codex` を選ぶと、会話側はゴール・進行・Agent QAを担当し、Issueごとの別Codexタスクが実装・QA指摘の修正・許可されたコミットを行う。タスク作成・連絡には `codex_task` とツールが要求する明示依頼が必要。`dev-managed-cc` を選ぶと、Issueごとの Managed Agents セッションが実装し、進行役が差分を適用してQAとreview_flowに従ったコミット工程を行う。`managed_session:<USD>` と `dev_delegation` が必要で、Bridge は不要。どの入口でも `implementation_skill` は許可を増やさない。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/linear/` に置く。`references/linear/` はClaude版を編集元としてCodex版とManaged Agents版へ同じ内容を複製し、テストで一致を確認する。
+`linear-execute` は初版では利用者本人の環境向けで、Codexが進行役として進行・Agent QA・Issueの記録・人への窓口を担当し、Claude Codeが実装・修正・コミットを行う。主フローは着手・実装・差分確定・公開確認・結果報告の5工程。運用項目は明示必須で、未記載を既定値で補わない。経路は着手時に通常の `review_flow.mode` で決まる。autoはCodexがローカル `claude -p` を起動して同じsessionをresumeし（許可 `claude_cli`、[CLI手順](plugins/shinaps-claude/references/linear/claude-cli.md)）、CLIの既存権限・model・effort・pluginsを保持する。manualはWebStorm内の対話Claude CodeセッションへBridgeで依頼する（許可 `bridge_request`、[Bridge](plugins/shinaps-claude/references/linear/bridge.md)）。初期体制はClaudeのメインが決めて報告し、Codexは判断の材料を渡す。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/linear/` に置く。`references/linear/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
 
-`review_flow: { "mode": "auto" }` はAIが自然な単位を決め、独立レビュー・QA後にstage・commitする。`review_flow: { "mode": "manual", "tool": "plasma" }`（toolは `webstorm` も可） はAIが単位を計画し、単位外を安全にstashしてstage・提示し、人がレビュー・修正・commitする。両方のstage権限とautoのAI commit権限は利用者との明示合意に含まれ、未合意ファイルからは得ない。`path_policy_overrides` は `paths` と `review_flow` だけを持つ。全変更が一つのルールで覆われる単位だけ適用し、改名は旧新両パスを判定する。競合時は止める。旧 `human_code_review`・`commit_mode`・permissionsのstage/commit・パス別ai_commitは明示移行が必要。[共通設定](plugins/shinaps-claude/references/linear/configuration.md#パス別の方針)を参照する。
+`review_flow: { "mode": "auto" }` はAIが自然な単位を決め、独立レビュー・QA後にstage・commitする。`review_flow: { "mode": "manual" }` はAIが単位外を安全に退避して単位をstage・提示し、人と修正を相談し、人がその単位を承認した後にAIがcommitする。両方のstage・AI commit権限は利用者との明示合意に含まれ、未合意ファイルからは得ない。`path_policy_overrides` は `paths` と `review_flow` だけを持つ。全変更が一つのルールで覆われる単位だけ適用し、改名は旧新両パスを判定する。競合時は止める。旧 `human_code_review`・`commit_mode`・permissionsのstage/commit・パス別ai_commitは明示移行が必要。[共通設定](plugins/shinaps-claude/references/linear/configuration.md#パス別の方針)を参照する。
 
 0.29.0では旧 `document_only_changes: ai_commit` を廃止した。利用先では依存工程を止め、具体的なパス例外への移行または例外廃止を合意する。説明だけの変更の許可とは同値でないため自動変換しない。旧 `none` もJSONへ明示移行し、新規設定は `path_policy_overrides: []` にする。
 
@@ -56,21 +56,15 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 ### dev の入口と体制
 
-| 入口 | 実行環境 | 担当のモデル |
-| --- | --- | --- |
-| `dev-claude` | Claude Code | Opus / medium（登録エージェントの定義） |
-| `dev-codex` | Codex | `gpt-6-astra` / medium（起動時に指定） |
-| `dev-managed-cc` | Managed Agents | leadはFable 5.1 / medium、担当はOpus / medium・fast |
+実装の入口は Claude Code の `dev-claude` だけで、Codexに実装の入口はない。メインは利用者のClaude CLI・セッションの設定（model・effort）を保持し、起動引数で上書きしない。担当は登録エージェントの定義（Opus / medium）で動く。
 
-人数による通常／ultraの区別は廃止した。`implementation_skill` は実行環境だけを選ぶ。旧名は対応する通常名へ設定・呼び出しを移行し、互換の入口は残さない。
-
-[実装体制の判断](plugins/shinaps-claude/references/dev/staffing.md)に従い、executeの進行役が各Issue開始時に関連コードを確認し、設計前に役割別の人数・理由・専任なしの責任者・必須検証を決めて渡す。単独devではメインが判断する。不確実性・影響範囲・失敗時の影響を基準に、途中でも必要な担当を追加する。人数を増やすだけで許可・予算・品質条件は変えない。
+[実装体制の判断](plugins/shinaps-claude/references/dev/staffing.md)に従い、devのメインが設計前に役割別の人数・理由・専任なしの責任者・必須検証を決める。linear-executeでは進行役のCodexが判断の材料を渡し、メインが決めて報告する。不確実性・影響範囲・失敗時の影響を基準に、途中でも必要な担当を追加する。人数を増やすだけで許可・予算・品質条件は変えない。
 
 小さく明確な変更はメインが計画し、実装1体と独立コードレビュー1体で進められる。設計の比較や重要な契約の独立確認が必要なら該当する役割だけ増やす。規約照合・簡素化・指摘検証は専任なしでも責任者を決めて行う。
 
-- 工程と体制基準はClaude版を編集元としてCodex・Managedへ複製する。起動手順だけはruntimeごとに異なる。
-- Claudeは登録エージェント、Codexは名前付きサブエージェント、Managedは定義済みエージェントを使う。モデル・推論の設定は今回の人数判断で変更しない。
-- explore・spec・review・debugからは同じruntimeのdevへ引き継ぐ。ClaudeのdevはSkillツールからの起動も許可する。
+- 工程と体制基準はClaude版を編集元としてCodexへ複製する。起動手順だけはruntimeごとに異なる。
+- Claudeは登録エージェント、Codexは名前付きサブエージェントを使う。モデル・推論の設定は今回の人数判断で変更しない。
+- Claudeのexplore・spec・review・debugからは `dev-claude` へ引き継ぐ。ClaudeのdevはSkillツールからの起動も許可する。Codexのスキルは実装へ引き継がず、Linear進行では `linear-execute` でClaudeへ依頼する。
 - テスト方針は各版の `references/testing.md` を正本とし、役割定義に同じ段落を複製して検証する。
 
 ## Claude Code
@@ -84,7 +78,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 ## Codex
 
-Node.js 22以上と、`plugin marketplace add` / `plugin add` に対応したCodex CLIを使う。Claude Codeのインストールは不要。ただし `linear-execute` の開発進行をClaudeの入口で行う場合は、両modeともローカルClaude Codeが必要になる。Managedの入口で進める場合は `ant` CLI が必要になる。
+Node.js 22以上と、`plugin marketplace add` / `plugin add` に対応したCodex CLIを使う。Codexのスキルだけを使う場合、Claude Codeのインストールは不要。`linear-execute` の開発進行には、autoではローカルClaude Code CLI、manualではWebStorm内のClaude CodeとBridgeが必要になる。
 
 導入・更新・削除:
 
@@ -99,7 +93,7 @@ npx @shinaps/skills@latest recover codex
 
 ローカル開発では、このcheckoutから `node bin/skills.ts install codex` のように同じ操作を実行できる。Node.js 22.18以上なら型除去でTypeScriptをそのまま実行する (ビルド不要)。
 
-CLIはスキルをCodex pluginとして登録し、16個のカスタムエージェントを`${CODEX_HOME:-~/.codex}/agents/`へ配置する。新しいセッションで`shinaps:dev-codex`、`shinaps:review`等が読み込まれる。dev の入口から起動した担当は入口が指定するモデルと推論（`gpt-6-astra` / medium）で動き、それ以外のスキルからの利用ではモデルと推論設定を親セッションから継承する。実装担当以外の調査・レビュー担当は読み取り専用を既定にする。0.23.0 まで配置していた比較専用の役割は、更新時に管理済みエージェントとして削除される。親セッションの実行時設定が優先される場合もあるため、権限の強制境界とは扱わない。
+CLIはスキルをCodex pluginとして登録し、16個のカスタムエージェントを`${CODEX_HOME:-~/.codex}/agents/`へ配置する。新しいセッションで`shinaps:review`、`shinaps:linear-execute`等が読み込まれる。Codexに実装の入口はなく、review・debug・spec等のスキルが担当を使う。担当のモデルと推論設定は親セッションから継承する。実装担当以外の調査・レビュー担当は読み取り専用を既定にする。0.23.0 まで配置していた比較専用の役割は、更新時に管理済みエージェントとして削除される。親セッションの実行時設定が優先される場合もあるため、権限の強制境界とは扱わない。
 
 配布物は`~/.local/share/shinaps-ai/skills/codex/`へ保持し、一時的なnpxキャッシュに依存しない。同じ親ディレクトリの`state.json`に配置したエージェントと内容のハッシュを記録する。管理対象外の同名ファイルや、導入後に編集されたエージェントは上書き・削除せず停止する。必要な変更を退避・整理してから再実行する。`CODEX_HOME`を変更する場合は元の配置先で先にuninstallする。
 
@@ -134,122 +128,15 @@ macOS以外では予定実行の登録に対応していないため手動更新
 
 Claude Codeは標準のmarketplace自動更新機能を使う。`/plugin` のMarketplacesから対象marketplaceのauto-updateを有効にする。GitHubから自動取得するにはリモートmarketplaceを登録する必要があり、ローカルcheckout登録ではソースのgit pullまで自動実行しない。
 
-## Claude Managed Agents
-
-`managed-agents/` に、lead `shinaps-dev-managed-cc`、devの8役割、skill `dev-managed-cc`、環境 `shinaps-dev` の定義を置く。leadが体制を引き継いで必要な担当へ委任する。
-
-lead は Fable 5.1（`claude-fable-5-1` / medium）、役割は Opus 5.5 の fast（`speed: fast`）で動く。人数と再確認によって費用は変わるため、固定体制時の費用を現在の見積りに使わない。セッションの合意済み予算内で体制を決め、増員のために予算を自動で増やさない。計画の再確認はManagedの起動手順に従い最大2ラウンドとする。QA修正も同じセッションの予算に含める。
-
-前提は `ant` CLI 1.42.0 以上と `ant auth login` 済みであること。定義の作成・更新は次の npm script だけで行う。
-
-```sh
-npm run managed:plan          # 送信内容の確認。全項目は npm run managed:plan -- -v
-npm run managed:apply         # 作成・更新。確認に対話で答えられない実行では、先に managed:plan の出力を確認してから -- --yes を付ける
-```
-
-`ant apply` を直接実行しない。`ant apply` は指定したディレクトリを再帰的に走査し、`agents/` の下のファイルと `SKILL.md` を持つディレクトリを送信対象にするので、リポジトリ直下を対象にすると `plugins/` の下にある Claude 版・Codex 版の定義も送信対象に含まれる。また lockfile は実行した場所から上へ探し、キーは lockfile のディレクトリからの相対パスになる。別の場所から実行すると、既存の lockfile と対応づかずに同じリソースが重複して作られる。npm script は `managed-agents/` に移動してから実行するので、対象と lockfile の位置が常に同じになる。
-
-`managed-agents/claude-lock.json` は apply が書き出す。リソースの ID を記録しているので commit する。lockfile は shinaps 組織のリソースの記録である。別の組織で使う場合は、lockfile を消してから実行するか、`npm run managed:apply -- --lock-file claude-lock.<組織名>.json` のように別の lockfile を指定する。パスは `managed-agents/` から見た位置で、lockfile は `managed-agents/` の中に置く（外に置くとキーの形が変わり、下の jq の例と合わなくなる）。ID は次のように引ける。
-
-```sh
-jq -r '.resources["./agents/shinaps-dev-managed-cc.md"].id' managed-agents/claude-lock.json
-jq -r '.resources["./environments/shinaps-dev.yaml"].id' managed-agents/claude-lock.json
-```
-
-旧ultraのクラウドリソースとlockの対応は過去セッションの参照用に保持する。新規実行には使わず、通常の更新で `--prune` による削除を行わない。
-
-定義を変えたら `npm run managed:apply` を実行する。lead が参照する役割と skill の版も同じ実行で更新される。
-
-### セッション
-
-linear-execute の Managed の入口では、セッションの作成・観測・取り出し・差分の適用を、進行役が [Managedセッション](plugins/shinaps-claude/references/linear/managed-session.md) の手順で行う。以下は手動で作る場合の例である。
-
-lead は shinaps-ai MCP の `list_search_facets`・`search_rules` を使う。規約を取得するには、shinaps-ai の API トークンが使えるようになってから、利用者が vault を作って資格情報を登録する。vault はセッションの作成時にしか渡せない。vault を渡さないセッションでも作業は進むが、規約照合は未確認になる。
-
-```sh
-ant beta:vaults create --display-name shinaps-ai --transform id --raw-output   # 返された ID を VAULT_ID にする
-read -rs SHINAPS_AI_TOKEN                                                     # 画面に表示せずに入力する
-ant beta:vaults:credentials create --vault-id "$VAULT_ID" --display-name shinaps-ai <<YAML
-auth:
-  type: static_bearer
-  mcp_server_url: https://app.shinaps.ai/mcp
-  token: "$SHINAPS_AI_TOKEN"
-YAML
-unset SHINAPS_AI_TOKEN
-```
-
-token は stdin の YAML で渡す。`--auth.token` の引数で渡すと、シェルの履歴とプロセスの一覧に見える（`ant` 自身も、引数で資格情報を渡すことを非推奨にしている）。YAML の値を二重引用符で囲むので、token に `"` や `\` が含まれる場合は、その文字の前に `\` を付けてから入力する。
-
-作業先を git bundle にして添付する。利用者共通方針（`~/.claude/CLAUDE.md`）も同じようにアップロードして添付する。どちらもリポジトリには入れない。
-
-```sh
-git bundle create /tmp/<repo>.bundle <branch>
-BUNDLE_ID=$(ant files upload --file /tmp/<repo>.bundle --expires-in-seconds 604800 --transform id --raw-output)
-CLAUDE_MD_ID=$(ant files upload --file ~/.claude/CLAUDE.md --expires-in-seconds 604800 --transform id --raw-output)
-ant beta:sessions create \
-  --agent "$LEAD_ID" \
-  --environment-id "$ENV_ID" \
-  --vault-id "$VAULT_ID" \
-  --budget '{type: limit, max_list_cost: {amount: "4000", currency: USD}}' <<YAML
-resources:
-  - {type: file, file_id: $BUNDLE_ID, mount_path: /<repo>.bundle}
-  - {type: file, file_id: $CLAUDE_MD_ID, mount_path: /CLAUDE.md}
-YAML
-ant beta:sessions connect --web "$SESSION_ID"
-```
-
-- 最初のメッセージで、作業先の bundle（`/mnt/session/uploads/<repo>.bundle`）、ブランチ、比較元の SHA を伝える。lead は起動手順に従って `/workspace/<repo>` に clone してから工程を始める。
-- bundle の代わりに GitHub のリポジトリをマウントすることもできる。その場合は resources の bundle を次に置き換える。token は Contents: Read だけを許可した fine-grained token にする。
-
-  ```yaml
-  - type: github_repository
-    url: https://github.com/<owner>/<repo>
-    authorization_token: <Contents: Read だけを許可した fine-grained token>
-    checkout: {type: branch, name: <branch>}
-  ```
-
-- 予算はセッション作成時にしか付けられない（後から変更・削除はできる）。金額はセント単位の文字列で、`"4000"` は 40 USD である。
-- lead の model を上書きするときは、`--agent` を外し、stdin の YAML に次を加える。上書きすると定義の effort は引き継がれないので、effort も指定する。
-
-  ```yaml
-  agent:
-    type: agent_with_overrides
-    id: <LEAD_ID>
-    model: {id: <model>, effort: <effort>}
-  ```
-
-- `ant beta:sessions connect --web` は全スレッドを見られるビューアを開く。lead の質問には、次のメッセージで答える。
-
-作業記録は、lead が終了時に `/mnt/session/outputs/` へ tar.gz でまとめる。正本はサンドボックス内の `.shinaps/work/` である。あわせて、比較元からの差分の全体を `changes.patch` として同じ場所に置く。
-
-```sh
-ant beta:files list --scope-id "$SESSION_ID" --beta managed-agents-2026-04-01
-ant files download --file-id <file ID> -o <保存先>
-```
-
-ファイルはセッションが待機状態になってから数秒遅れて一覧に現れることがある。予算に達して止まったセッションでは、予算を引き上げて lead が終了処理を行うまで tar は作られない。
-
-担当の委任・継続の方法と、Claude Code 固有の手段の置き換え・未対応のものは、[起動手順](managed-agents/skills/dev-managed-cc/references/dev/launch.md)にある。
-
-### ネットワークと危険
-
-環境 `shinaps-dev` のネットワークは制限しない（`unrestricted`）。
-
-- bash の実行は承認なし（`always_allow`）なので、サンドボックスにあるもの（マウントしたコード、添付した CLAUDE.md）は外へ送ることができる。
-- 取得した Web ページやリポジトリの内容に書かれた指示に従ってしまう危険（プロンプトインジェクション）がある。
-- bash を `always_ask` か `auto` にすれば軽減できるが、担当ごとの承認待ちで工程が止まるので採らない。
-- 秘密情報はサンドボックスに置かない。マウントするリポジトリの token は読み取りだけに限る。
-- bundle で送るのはコミット済みの内容だけで、ignore 済みのファイルや作業記録は送らない。
-
 ## 開発と配布
 
 - Claude版: `plugins/shinaps-claude/`、marketplaceは`.claude-plugin/marketplace.json`
 - Codex版: `plugins/shinaps-codex/`、marketplaceは`.agents/plugins/marketplace.json`
 - Codexカスタムエージェント: `plugins/shinaps-codex/agents/`
-- Managed Agents版: `managed-agents/`。npmパッケージには含めない
+- `managed-agents/claude-lock.json` は既存クラウドリソースの記録として保持する。`managed-agents/` で `ant` を実行しない（apply・prune・削除をしない）
 - 配布CLI: ソースは `bin/skills.ts` と `lib/*.ts`。`npm run build` (`tsc`) で `dist/` にJSを出力し、npmにはそれを配布する。Node.jsは`node_modules`配下の`.ts`に型除去を適用しないため、ソースのままは配布できない。checkoutでは型除去で直接実行するので、`enum`など型除去で消せない構文は使わない (`tsconfig.json` の `erasableSyntaxOnly`)
 
-品質基準とプロジェクト設定の方針は揃えつつ、クライアント固有の実行手順・エージェント形式は別々に管理する。Managed Agents版は、役割の本文・`name`・`description` と工程の資料（`references/` の、`dev/launch.md` を除くもの）をClaude版と一致させ、テストで確認する。版ごとに内容を変えるのは役割の frontmatter（model・tools）と `references/dev/launch.md` で、Managed Agents版はこのほかに lead の定義、skill の `SKILL.md`、環境の定義を持つ。Codex版は役割の本文とスキルを書き分け、Claude向けのエージェント呼び出しをCodexに読み替えさせる方式は使わない。スキルを追加・変更した場合は各版への適用可否を判断する。
+品質基準とプロジェクト設定の方針は揃えつつ、クライアント固有の実行手順・エージェント形式は別々に管理する。Codex版の工程の資料（`references/` の、`dev/launch.md` を除くもの）はClaude版と一致させ、テストで確認する。Codex版は役割の本文とスキルを書き分け、Claude向けのエージェント呼び出しをCodexに読み替えさせる方式は使わない。スキルを追加・変更した場合は各版への適用可否を判断する。
 
 ```sh
 npm test
@@ -259,9 +146,9 @@ npm pack --dry-run
 
 公開前にはnpmスコープ`@shinaps`の利用権限とtarball内容を確認する。CLIのバージョンと両pluginのバージョンを揃える。開発中の同一バージョンも`update codex`で再配置できる。
 
-### Codexでの人レビュー
+### manualの提示と承認
 
-manualでは対象checkoutと単位の差分を提示し、人のレビュー・修正・コミット完了を待ちます。実装runtimeによらず、実効 `review_flow.tool` でPlasmaまたはWebStormを選びます。Plasmaは別途導入するツールで、未導入時も人レビューを省略しません。変更の目的と確認点は会話に示し、人の完了通知後の実コミット照合と修正の検証は[共通手順](plugins/shinaps-codex/references/human-review.md)に従います。autoには人レビュー待ちを追加しません。
+manualではWebStorm内の対話Claude Codeセッションで、Claudeが単位外を退避して単位の差分をstage・提示します。人はWebStormの差分表示で確認し、Claudeと修正を相談します。人がその単位を承認したら、Claudeが承認したtreeと一致することを確かめてコミットします。承認後に単位の差分が変われば再提示・再承認が必要です。手順は[共通手順](plugins/shinaps-claude/references/human-review.md)に従います。autoには人レビュー待ちを追加しません。
 
 ### CIとnpm自動公開
 
@@ -300,7 +187,7 @@ codex mcp login shinaps-ai
 
 未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`commit`・`create-pr`・`release`・`linear-plan`・`linear-execute` の基本手順はMCP接続を必須としない。
 
-## Subagents (Claude: 16 / Codex: 16 / Managed: 8)
+## Subagents (Claude: 16 / Codex: 16)
 
 | Subagent | 役割 |
 |---|---|
@@ -321,16 +208,16 @@ codex mcp login shinaps-ai
 | `shinaps-debug-validator` | 仮説の実コード検証 (root-cause / contributing-factor / red-herring / needs-reproduction 分類) |
 | `shinaps-split-reviewer` | `shinaps:commit` のmanualの分割案を「単位の diff だけで妥当性を判断できるか」で批判 + 修正版最終分割計画 (worktree は read-only) |
 
-Claude版はMarkdown、Codex版はTOMLで役割を定義する。Managed Agents版は dev で使う8役割だけを、Claude版の本文に `ant apply` 用の frontmatter を付けたMarkdownで定義する。
+Claude版はMarkdown、Codex版はTOMLで役割を定義する。
 
-Claude版は全16エージェントが `opus / medium`。Codex版の役割定義はモデルを書かず、dev の入口が起動時にモデルと推論を指定する。dev での担当の割り当ては[dev の工程](plugins/shinaps-claude/references/dev/workflow.md)にある。
+Claude版は全16エージェントが `opus / medium`。Codex版の役割定義はモデルを書かず、モデルと推論は親セッションから継承する。dev での担当の割り当ては[dev の工程](plugins/shinaps-claude/references/dev/workflow.md)にある。
 
 **subagent 内では shinaps MCP を直接呼び出さず、rule 全文は Skill 側から prompt 経由で渡す** 原則を全 system prompt に明記する。MCP呼び出しの利用量が重複しないようにするため。
 
 
 ## 作業成果物
 
-作業記録は現在の作業先の `.shinaps/work/` に保存する。[作業記録の共通手順](plugins/shinaps-claude/references/work-records.md)に従い、既存の共有例外を保持し、workの除外が不足する場合だけ `/work/` を追加する。設定の共有方式は記録作成では変更しない。共通手順はClaude版を編集元としてCodex版とManaged Agents版へ複製し、テストで一致を確認する。
+作業記録は現在の作業先の `.shinaps/work/` に保存する。[作業記録の共通手順](plugins/shinaps-claude/references/work-records.md)に従い、既存の共有例外を保持し、workの除外が不足する場合だけ `/work/` を追加する。設定の共有方式は記録作成では変更しない。共通手順はClaude版を編集元としてCodex版へ複製し、テストで一致を確認する。
 
 ```text
 .shinaps/

package/dist/bin/skills.js

@@ -15,7 +15,7 @@ try {
         if (rest.length !== 1)
             throw new Error('Usage: shinaps-skills validate-linear-config <file>');
         await validateLinearConfig(rest[0]);
-        console.log('Linear configuration is valid (config_version: 1).');
+        console.log('Linear configuration is valid (config_version: 2).');
     }
     else if (command === 'auto-update')
         await autoUpdate(rest);

package/dist/lib/linear-config.js

@@ -8,10 +8,10 @@ export async function validateLinearConfig(path) {
     // 版の不一致は設定修正とskill更新で対処が異なるため、schema検証より先に案内する。
     if (typeof input === 'object' && input !== null && !Array.isArray(input)) {
         const version = 'config_version' in input ? input.config_version : undefined;
-        if (version === undefined || (Number.isInteger(version) && Number(version) < 1)) {
-            throw new Error('config_version is missing or old. Migrate with linear-plan to config_version: 1.');
+        if (version === undefined || (Number.isInteger(version) && Number(version) < 2)) {
+            throw new Error('config_version is missing or old. Migrate with linear-plan to config_version: 2.');
         }
-        if (Number.isInteger(version) && Number(version) > 1) {
+        if (Number.isInteger(version) && Number(version) > 2) {
             throw new Error('Future config_version. Update the skill and matching CLI before continuing.');
         }
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.32.0",
+  "version": "0.33.0",
   "description": "Install Shinaps AI workflows and custom agents for Codex",
   "type": "module",
   "bin": {
@@ -22,8 +22,6 @@
     "test": "node --test \"test/*.test.ts\"",
     "check": "npm run format:check && tsc --noEmit",
     "verify:package": "node scripts/verify-package.ts",
-    "managed:plan": "cd managed-agents && ant apply --dry-run .",
-    "managed:apply": "cd managed-agents && ant apply .",
     "format": "biome format --write .",
     "format:check": "biome format ."
   },

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

@@ -1,7 +1,7 @@
 {
   "name": "shinaps",
   "description": "Shinaps AIの開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・レビュー・コミット・PR・リリースとLinearでの開発進行を支援する。",
-  "version": "0.32.0",
+  "version": "0.33.0",
   "author": {
     "name": "shinaps",
     "email": "ryuta@shinaps.jp"

package/plugins/shinaps-claude/agents/shinaps-split-reviewer.md

@@ -1,13 +1,13 @@
 ---
 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 は一切行わない
 model: opus
 effort: medium
 color: blue
 ---
 
-あなたは `/shinaps:commit` のmanualで、人が単位ごとにレビュー・修正・コミットする前に分割計画を確認するレビューエージェントです。
-メインスレッドが提案した **コミット単位の分割計画** を、「この単位の diff だけを渡された人間レビュアーが、変更の妥当性を判断できるか」という視点で **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終分割計画 (Part 2)** までを返してください。人が単位ごとにレビュー・修正・コミットする前に区切り方を確かめる立場なので（人のレビュー・コミットは代行しない）、「概ね良い」で済ませずに各単位を実際に読んで判定します。
+あなたは `/shinaps:commit` のmanualで、人が単位ごとにレビュー・承認する前に分割計画を確認するレビューエージェントです。
+メインスレッドが提案した **コミット単位の分割計画** を、「この単位の diff だけを渡された人間レビュアーが、変更の妥当性を判断できるか」という視点で **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終分割計画 (Part 2)** までを返してください。人が単位ごとにレビュー・承認する前に区切り方を確かめる立場なので（人のレビュー・承認は代行しない）、「概ね良い」で済ませずに各単位を実際に読んで判定します。
 
 ## 作業前の必須確認
 

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

@@ -6,6 +6,6 @@
 - 同じ役割の複数担当 は、同じ登録エージェントを別々に起動する。呼び出しごとに別のコンテキストになるので、互いの結果は共有されない。担当番号は起動前に固定し、返された ID と対応づけて保持する。
 - 並行する担当はバックグラウンドで起動し、全担当の完了を待つ。同時に起動できなかった担当は、実行中の担当の完了後に起動する。
 - 同じ担当の継続は、同じ ID へ SendMessage で依頼する。
-- 対話セッションの質問は `AskUserQuestion` で一問ずつ行う。CodexからローカルCLIで受けた依頼では質問・障害・再開点を最終resultへ返してターンを終了し（CLI内で `AskUserQuestion` や入力待ちを行わない）、同じsessionのresumeで回答を受ける（[CLI手順](../linear/claude-cli.md)）。Bridge経路は依頼元Codexへ返す。進捗は `TaskCreate`・`TaskUpdate` で管理する。他スキル（`commit`・`create-pr`・`release`）への引き継ぎは `Skill` を使う。現在のセッションで提供されていないツールは仮定しない。
+- 対話セッションの質問は `AskUserQuestion` で一問ずつ行う。CodexからローカルCLIで受けた依頼（auto経路）では質問・障害・再開点を最終resultへ返してターンを終了し（CLI内で `AskUserQuestion` や入力待ちを行わない）、同じsessionのresumeで回答を受ける（[CLI手順](../linear/claude-cli.md)）。Bridgeで受けた依頼（manual経路の対話セッション）では人へ `AskUserQuestion` で確認し、決定を依頼元Codexへの報告に含める（[Bridge](../linear/bridge.md)）。進捗は `TaskCreate`・`TaskUpdate` で管理する。他スキル（`commit`・`create-pr`・`release`）への引き継ぎは `Skill` を使う。現在のセッションで提供されていないツールは仮定しない。
 - `EnterPlanMode` は使わない。bypassPermissions モード（リモート実行など）と両立させるため。
 - 起動できない、または完了しない担当は未完了として記録する。他のモデルや Fable へ切り替えず、メインが代わりに作業して独立確認済みと報告しない。

package/plugins/shinaps-claude/references/dev/staffing.md

@@ -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-claude/references/dev/workflow.md

@@ -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-claude/references/human-review.md

@@ -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-claude/references/linear/bridge.md

@@ -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-claude/references/linear/claude-cli.md

@@ -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に作り直さない。
 
 ## 操作権限