@shinaps/skills 0.30.0 → 0.32.0

package/plugins/shinaps-codex/references/linear/configuration.schema.json

@@ -0,0 +1,305 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "$id": "https://raw.githubusercontent.com/sh1n4ps/shinaps-skills/v0.32.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
+  "title": "Shinaps Linear configuration v1",
+  "type": "object",
+  "properties": {
+    "$schema": {
+      "type": "string"
+    },
+    "config_version": {
+      "type": "integer",
+      "const": 1
+    },
+    "config_storage": {
+      "enum": ["shared", "local"]
+    },
+    "target": {
+      "type": "object",
+      "properties": {
+        "workspace": {
+          "type": "string",
+          "minLength": 1
+        },
+        "team": {
+          "type": "string",
+          "minLength": 1
+        },
+        "project": {
+          "anyOf": [
+            {
+              "type": "string",
+              "minLength": 1
+            },
+            {
+              "type": "null"
+            }
+          ]
+        }
+      },
+      "required": ["workspace", "team", "project"],
+      "additionalProperties": false
+    },
+    "team_settings": {
+      "enum": ["existing_only", "manage_on_setup"]
+    },
+    "statuses": {
+      "type": "object",
+      "properties": {
+        "todo": {
+          "type": "string",
+          "minLength": 1
+        },
+        "refinement": {
+          "type": "string",
+          "minLength": 1
+        },
+        "ready": {
+          "type": "string",
+          "minLength": 1
+        },
+        "coding": {
+          "type": "string",
+          "minLength": 1
+        },
+        "local_agent_qa": {
+          "type": "string",
+          "minLength": 1
+        },
+        "code_review": {
+          "type": "string",
+          "minLength": 1
+        },
+        "post_commit": {
+          "type": "string",
+          "minLength": 1
+        },
+        "staging_agent_qa": {
+          "type": "string",
+          "minLength": 1
+        },
+        "staging_human_qa": {
+          "type": "string",
+          "minLength": 1
+        },
+        "release": {
+          "type": "string",
+          "minLength": 1
+        },
+        "production_agent_qa": {
+          "type": "string",
+          "minLength": 1
+        },
+        "production_human_qa": {
+          "type": "string",
+          "minLength": 1
+        },
+        "human_input": {
+          "type": "string",
+          "minLength": 1
+        },
+        "done": {
+          "type": "string",
+          "minLength": 1
+        }
+      },
+      "required": [],
+      "additionalProperties": false
+    },
+    "stop_after": {
+      "enum": ["pre_push_qa", "pr_created", "issue_done"]
+    },
+    "implementation_skill": {
+      "enum": ["dev-claude", "dev-codex", "dev-managed-cc"]
+    },
+    "review_flow": {
+      "$ref": "#/definitions/reviewFlow"
+    },
+    "path_policy_overrides": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "properties": {
+          "paths": {
+            "type": "array",
+            "minItems": 1,
+            "items": {
+              "type": "string",
+              "minLength": 1
+            }
+          },
+          "review_flow": {
+            "$ref": "#/definitions/reviewFlow"
+          }
+        },
+        "required": ["paths", "review_flow"],
+        "additionalProperties": false
+      }
+    },
+    "permissions": {
+      "type": "array",
+      "items": {
+        "anyOf": [
+          {
+            "enum": [
+              "issue_update",
+              "development_operations",
+              "codex_task",
+              "claude_cli",
+              "bridge_request",
+              "push",
+              "pr_create",
+              "merge",
+              "dev_delegation"
+            ]
+          },
+          {
+            "type": "string",
+            "pattern": "^managed_session:[1-9][0-9]*$"
+          },
+          {
+            "type": "string",
+            "pattern": "^(deploy|publish|evidence):[^\\s]+$"
+          }
+        ]
+      }
+    },
+    "references": {
+      "type": "object",
+      "properties": {
+        "specifications": {
+          "type": "array",
+          "items": {
+            "type": "string",
+            "minLength": 1
+          }
+        },
+        "validation": {
+          "type": "array",
+          "items": {
+            "type": "string",
+            "minLength": 1
+          }
+        },
+        "environments": {
+          "type": "array",
+          "items": {
+            "type": "string",
+            "minLength": 1
+          }
+        },
+        "deployment": {
+          "type": "array",
+          "items": {
+            "type": "string",
+            "minLength": 1
+          }
+        },
+        "publication": {
+          "type": "array",
+          "items": {
+            "type": "string",
+            "minLength": 1
+          }
+        }
+      },
+      "required": ["specifications", "validation", "environments", "deployment", "publication"],
+      "additionalProperties": false
+    },
+    "cycle_report": {
+      "anyOf": [
+        {
+          "type": "null"
+        },
+        {
+          "type": "object",
+          "properties": {
+            "qa_scope": {
+              "type": "array",
+              "items": {
+                "type": "string",
+                "minLength": 1
+              }
+            },
+            "destination": {
+              "type": "string",
+              "minLength": 1
+            },
+            "index": {
+              "anyOf": [
+                {
+                  "type": "string",
+                  "minLength": 1
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "audience": {
+              "type": "string",
+              "minLength": 1
+            },
+            "format": {
+              "anyOf": [
+                {
+                  "type": "string",
+                  "minLength": 1
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            }
+          },
+          "required": ["qa_scope", "destination", "index", "audience", "format"],
+          "additionalProperties": false
+        }
+      ]
+    }
+  },
+  "required": [
+    "config_version",
+    "config_storage",
+    "target",
+    "team_settings",
+    "statuses",
+    "stop_after",
+    "implementation_skill",
+    "review_flow",
+    "path_policy_overrides",
+    "permissions",
+    "references",
+    "cycle_report"
+  ],
+  "additionalProperties": false,
+  "definitions": {
+    "reviewFlow": {
+      "oneOf": [
+        {
+          "type": "object",
+          "properties": {
+            "mode": {
+              "const": "auto"
+            }
+          },
+          "required": ["mode"],
+          "additionalProperties": false
+        },
+        {
+          "type": "object",
+          "properties": {
+            "mode": {
+              "const": "manual"
+            },
+            "tool": {
+              "enum": ["plasma", "webstorm"]
+            }
+          },
+          "required": ["mode", "tool"],
+          "additionalProperties": false
+        }
+      ]
+    }
+  }
+}

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

@@ -1,6 +1,6 @@
 # 実行範囲とゴール
 
-実行範囲は今回の依頼で決める。YAMLは担当・QA・レビュー・操作許可・終了地点を決めるもので、実行範囲の既定値を持たない。
+実行範囲は今回の依頼で決める。JSON設定は担当・QA・レビュー・操作許可・終了地点を決めるもので、実行範囲の既定値を持たない。
 
 | モード | 対象 | 終了条件 |
 | --- | --- | --- |

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

@@ -119,7 +119,7 @@ YAML
 
 ## Managed固有の読み替えと記録
 
-- [単位案からコミット完了まで](workflow.md#単位案からコミット完了まで)の手順2は、依頼を送らず、進行役が許可と記録の一致を確かめる手順として読む。手順3は、進行役が `commit` に従って行う。
+- [単位案からコミット完了まで](workflow.md#単位案からコミット完了まで)の手順2は、依頼を送らず、進行役が許可と記録の一致を確かめる手順として読む。手順3は、進行役が `commit` に従い、autoなら独立レビュー・QA後にstage・commitし、manualなら安全なstash・stage・提示を行い、人のレビュー・修正・commitと復元確認を待つ。
 - 各idleでの累計の費用と最終の費用を、作業記録とIssueの記録に残す。
 
 ## 初回メッセージと修正依頼
@@ -131,7 +131,7 @@ YAML
 Linear進行の実装依頼として、skill dev-managed-cc の工程と起動手順に従ってください。
 作業先: /mnt/session/uploads/<repo>.bundle をブランチ <branch> で /workspace/<repo> に用意する。比較元 <SHA>。
 タスク: <Issueの識別子とリンク>。<範囲・受入条件・範囲外・仕様や調査成果物の本文。leadはLinearを読めない>。必要な検証: <references.validation に従うコマンド>。
-設定: 保存方式 <shared|local>。正本 <作業先の .shinaps/linear.yaml。bundleに含まれるか>。読む補足 <references のうち工程に必要なもの>。正本や補足がbundleに含まれない場合（`local` など）は、その本文をこの欄に写す。
+設定: 保存方式 <shared|local>。正本 <作業先の .shinaps/linear.json。bundleに含まれるか>。読む補足 <references のうち工程に必要なもの>。正本や補足がbundleに含まれない場合（`local` など）は、その本文をこの欄に写す。
 前提: <CLAUDE.mdを添付した場合だけ: 利用者共通方針は /mnt/session/uploads/CLAUDE.md>。規約照合: <vaultあり | vaultなし。取得できなければ未確認として進める>。許可範囲: devの入口の中の委託（dev_delegation）。コミット・push・PR作成・Issueの更新・ant apply はしない。仕様・権限の不明点は一問ずつ質問してターンを終える。通常の実装判断は任せる。
 報告: 最終報告に、変更範囲、検証結果、dev内レビューの結果と未解決の指摘、起動方法、未解決事項、コミット単位案と単位ごとの予定差分（references/linear/workflow.md「単位案からコミット完了まで」の1）を含める。
 ```

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

@@ -4,13 +4,13 @@
 
 | 担当 | 責務 |
 | --- | --- |
-| Codex | Issueの作成・整理、仕様相談、Ready判定、依存・Cycle管理、進行判断、Claudeの入口のときのBridgeでの依頼、Local・Staging・ProductionのAgent QA、許可されたPR・配備等の運用、結果の記録、人への依頼 |
+| Codex | Issueの作成・整理、仕様相談、Ready判定、依存・Cycle管理、進行判断、Claudeの入口のときのCLIでの依頼、Local・Staging・ProductionのAgent QA、許可されたPR・配備等の運用、結果の記録、人への依頼 |
 | 実装担当 | 技術調査、`implementation_skill` で選んだdevの入口による実装・自動テスト・簡素化・セルフレビュー、QA指摘の修正、成果と人の対応結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
-| 人 | 未合意の仕様・権限の判断、設定で必要なコードレビュー・必要な修正、AIに許可していないコミット、本人の操作が必要な認証等、必要なHuman QA |
+| 人 | 未合意の仕様・権限の判断、manualのコードレビュー・必要な修正・コミット、本人の操作が必要な認証等、必要なHuman QA |
 
-実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口（`dev-claude`）では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口（`dev-codex`）では、この文書でClaudeが行うとした実装・修正・コミット・完了報告を会話側とは別のCodex実装タスクが行い、[Codex実装タスク](codex-task.md)の手順で依頼・結果を扱う。Bridgeは使わない。どちらでも実装担当はdev内レビューと検証を終えて進行役へ結果を返し、進行役がLocal Agent QAを行う。実装担当の報告をQA合格の根拠にせず、この引き渡しを進行全体の終了と扱わない。
+実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口（`dev-claude`）では、auto/manualともCodexが[ローカルClaude CLI](claude-cli.md)を起動し、同じsessionをresumeする。パス例外はreview_flow全体に反映し、実装経路は変えない。manualのUIは実効 `review_flow.tool` で決める。Codexの入口（`dev-codex`）では、この文書でClaudeが行うとした実装・修正・コミット・完了報告を会話側とは別のCodex実装タスクが行い、[Codex実装タスク](codex-task.md)の手順で依頼・結果を扱う。Bridgeは使わない。どちらでも実装担当はdev内レビューと検証を終えて進行役へ結果を返し、進行役がLocal Agent QAを行う。実装担当の報告をQA合格の根拠にせず、この引き渡しを進行全体の終了と扱わない。
 
-Managedの入口（`dev-managed-cc`）では、linear-executeを実行している会話（ClaudeまたはCodex）が進行役になり、`linear/` の各文書でCodexが行うとした進行・Agent QA・記録・人への窓口を行う。実装・修正はIssueごとのClaude Managed Agentsセッションのleadがその入口のskillで行い、[Managedセッション](managed-session.md)の手順で依頼・結果を扱う。この文書でClaudeまたは実装担当が行うとした実装・修正・完了報告はleadが行う。leadはローカルの作業先へ書けないため、差分の適用・コミットと、人の対応結果の受け取りは進行役が行う。BridgeとCodex実装タスクは使わない。
+Managedの入口（`dev-managed-cc`）では、linear-executeを実行している会話（ClaudeまたはCodex）が進行役になり、`linear/` の各文書でCodexが行うとした進行・Agent QA・記録・人への窓口を行う。実装・修正はIssueごとのClaude Managed Agentsセッションのleadがその入口のskillで行い、[Managedセッション](managed-session.md)の手順で依頼・結果を扱う。この文書でClaudeまたは実装担当が行うとした実装・修正・完了報告はleadが行う。leadはローカルの作業先へ書けないため、差分の適用と、人の対応結果の受け取りは進行役が行う。コミット工程は進行役が `commit` に従い、autoなら自身がcommit、manualなら安全なstash・stage・提示まで行い人のcommitを待つ。BridgeとCodex実装タスクは使わない。
 
 人への質問と依頼は会話側のCodexが窓口になる。実装担当は人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
 
@@ -29,7 +29,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 | 次の操作の継続的な許可があり、必要な工程の結果が揃った | Codexは「進めてもよいか」を再質問せずに実行する |
 | Cycle全体を任され、対象Issueが設定された終了地点に達した | Codexは開始時に確定した対象と順序を照合し、その範囲の次のIssueへ進む |
 
-「自律的に進める」とだけ書かず、この表と具体的な許可範囲を各Bridge依頼に書く。
+「自律的に進める」とだけ書かず、この表と具体的な許可範囲を各CLI・Bridge依頼に書く。
 
 ## 人に確認する条件
 
@@ -44,7 +44,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 | `ready` | Ready | 自分たちの作業を依存順に進めれば着手できる。開始時に、必要な前工程の成果を再確認する |
 | `coding` | Coding | 実装担当が実装・自動検証・簡素化・セルフレビューを完了し、差分と結果を渡す |
 | `local_agent_qa` | Local Agent QA | Codexが受入条件を検証する。不合格なら `coding` へ戻す |
-| `code_review` | Code Review（人のレビューまたは省略の記録・コミット） | 各予定単位の実効方針が `human_code_review: required` なら人がレビュー・修正し、`skip` なら依頼も待ちも作らず省略を記録する。Local Agent QAの合格後（`required` なら人のレビュー完了の確認後）、実効方針でAIコミットが許可され、`stage` の許可もあれば、会話側のCodexの依頼で実装担当がコミットする。許可がなければ人が行う。対象コミットと人の完了通知または省略の記録を照合する |
+| `code_review` | Code Review・コミット | Local Agent QA合格後、実効 `review_flow.mode: auto` は独立レビュー・検証後にAIが単位ごとにstage・commitする。manualはAIが単位外を安全にstashしてstage・提示し、人がレビュー・修正・commitする。単位照合、人の完了通知（manual）、stash/index復元を確認して次へ進む |
 | `post_commit` | コミット後の検証・PR準備 | 設定に従って、push前の最終Agent QA、必須検証、許可されたpush・PR作成を行う |
 | `staging_agent_qa` | Staging Agent QA | 配備されたPR候補版をCodexが検証する |
 | `staging_human_qa` | Staging Human QA | そのPRで必要な人の確認。不要なら理由を記録して省略する |
@@ -61,7 +61,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 - 人がレビュー中に修正した場合は `code_review` を続ける。AIへ追加実装を依頼する場合は、範囲と受入条件をIssueで更新してから `coding` へ戻す。
 - Human QAが新たに必要になった場合は、理由と具体的な残項目をIssueに記録して利用者に相談する。
 - プロジェクトの規約や補足の記述だけでは、AIコミットの許可として扱わない。[共通設定のパス別の方針](configuration.md#パス別の方針)に従って、通常設定・適用ルール・今回の明示指示から実効方針を決める。
-- 実効方針が `human_code_review: skip` なら、Codexは `code_review` で対象単位を明示し、省略と実施した確認への参照をIssueへ記録する。人のレビュー済みとは記録しない。
+- 実効方針が `review_flow.mode: auto` なら、Codexは `code_review` で対象単位を明示し、省略と実施した確認への参照をIssueへ記録する。人のレビュー済みとは記録しない。
 
   ```text
   人のコードレビュー: <対象単位>は省略（根拠: <通常設定または適用したパス別ルール>、判定: <Local Agent QAの記録へのリンク>）
@@ -74,10 +74,10 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 以下はすべての実装方式に共通する（Managedの入口での手順2・3の読み方は、[Managedセッション](managed-session.md)の「Managed固有の読み替えと記録」にある）。単位計画の作成・確認にはコミット許可を要求しない。
 
 1. 実装担当は成果引き渡しに、モードによらず自然な責務で決めたコミット単位案と予定差分を含める。進行役のCodexはLocal Agent QAで対象を検証し、単位案が依頼全体を漏れなく覆い対象外変更を含まないことと、各単位の[判定記録](configuration.md#判定記録と変更時の扱い)を確認する。依頼の比較元と全体差分も最終照合用に記録する。
-2. 人レビューを待つかAIコミットを依頼するかは、各単位の実効方針で決める。QA合格とその単位に必要な人レビュー・AIコミット・stageの許可が揃ったら、CodexはQA結果、単位の判定記録、人レビュー完了の証拠または省略根拠を添えて実装担当へ依頼する。担当は設定・予定差分と記録の一致、許可を確認し、不一致なら実行せず進行役へ返す。
-3. 実装担当は `commit` に従い、各単位のモードに応じた承認・隔離・検証・レビューを行う。同じ依頼内に通常・自律の単位が混在してよい。各コミット直前・作成後の実差分をその単位の予定差分と照合し、予定単位・SHA・照合結果・検証とレビュー結果を進行役へ返す。
-4. 全単位完了後、Codexは各コミットの単位照合結果を実差分で独立確認したうえで、依頼の比較元からの全体差分が対象と一致し、対象の未コミット変更が残っていないことを照合する。最終差分だけでは途中で混入し後で相殺された対象外変更を検出できないため、単位照合を省かない。人レビューを省略した単位は、上の省略記録を完成させる。
-5. 単位の組み替え・内容・設定の変更は[変更時の扱い](configuration.md#判定記録と変更時の扱い)に従って再判定し、必要なレビュー・許可確認・検証へ戻す。実コミットに不一致があれば次工程を止め、SHA・予定差分・実差分の違いを記録して人に確認する。履歴を無断で書き換えない。
+2. QA合格後、Codexは実効flow・単位の判定記録・QA結果を実装担当へ渡す。Claudeは両modeとも同じCLI sessionをresumeする。manualは準備したprocessの終了後に進行役が指定toolで提示する。担当は設定・予定差分・合意根拠を照合する。manualの依頼は人への提示準備でありAIコミットの依頼ではない。
+3. 担当は `commit` に従い、autoでは独立レビュー後にAIがstage・commitし、manualでは単位外を安全にstashしてstage・提示、人がレビュー・修正・commitする。各コミット直前・作成後の実差分と確定した予定単位を照合し、予定単位・SHA・検証・レビュー・復元結果を進行役へ返す。
+4. 全単位完了後、Codexは各コミットの単位照合結果を実差分で独立確認したうえで、依頼の比較元からの全体差分が、`commit` の手順で正当な人の修正を反映した確定済みの全体期待差分と一致し、対象の未コミット変更が残っていないことを照合する。最終差分だけでは途中で混入し後で相殺された対象外変更を検出できないため、単位照合を省かない。人レビューを省略した単位は、上の省略記録を完成させる。
+5. 単位の組み替え・内容・設定の変更は[変更時の扱い](configuration.md#判定記録と変更時の扱い)に従って再判定し、必要なレビュー・許可確認・検証へ戻す。人の完了通知後は `commit` に従って正当な修正と元の予定差分の対応を記録し、確定単位に更新する。確定単位と実コミットに不一致があれば次工程を止め、SHA・予定差分・実差分の違いを記録して人に確認する。履歴を無断で書き換えない。
 
 ## 待ち状態
 
@@ -87,40 +87,17 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 Linearの工程のステータスと、Codexのゴールの状態は別に扱う。会話側のゴールの維持・終了・状態変更は [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。通知を受けたら対象と結果を照合し、次工程の許可と前提が揃っていれば再確認せずに続ける。
 
-## Bridgeでの依頼と報告
+## Bridgeでの任意の引き渡し・報告
 
-AI Terminal Bridge（以下Bridge）の本体は同梱しない。導入済みのMCPとWebStormプラグインを使う。Claudeの入口で開発進行するときは必須で、Codexの入口やIssue整理だけなら不要。
+Claudeの実装依頼は両modeともCLIを使い、Bridgeを必須にしない。既存の `bridge_request` または今回の明示許可で別会話から進行の引き渡し・人の完了報告を受ける場合だけ、この節を使う。報告は照合材料であり、CLIの実装経路やレビューUI、操作許可を変更しない。
 
-送信前に `list_sessions` で、相手の `project_path`、完全な `session_id`、受信の可否を確認する。`session_id` は保存せず、依頼のたびに一覧から取得する。`project_path` はIDEのプロジェクトのルートで、作業ディレクトリと一致するとは限らない。依頼と報告には、Gitの作業ディレクトリを別に書く。次の表のCodexとClaudeの間の依頼・報告は、Claudeの入口のときに使う。
+### 開発進行の引き渡し
 
-| 依頼・報告 | 含めるもの |
-| --- | --- |
-| 実装・修正の依頼（CodexからClaude） | Issueリンク、使う入口（`implementation_skill` の値、またはその場の明示的な指定）、範囲・受入条件、初期体制（役割別人数・根拠・専任なしの責任者・必須検証）、Gitの作業ディレクトリ・ブランチ・既存差分、許可範囲（`dev_delegation` の有無を含む）、返信先のCodexの `session_id`、関係する補足と参照先、下の定型文。修正依頼では、再現手順・期待と実際・対象差分・証拠の場所を加える |
-| コミットの依頼（CodexからClaude） | Issueリンク、Gitの作業ディレクトリ・ブランチ、返信先のCodexの `session_id` と、上の「単位案からコミット完了まで」で定める依頼情報 |
-| 完了の報告（ClaudeからCodex） | 対象差分、自動検証の結果、起動方法、確認観点、既知の制限、未解決の事項、初期体制からの変更と理由、実際の担当と確認範囲、devの入口内のレビュー結果の要約と未解決の指摘。コミットした場合の返却情報は上の「単位案からコミット完了まで」に従う |
-| 人のレビュー・コミット完了の報告（ClaudeからCodex） | 下の「人のレビュー・コミット完了の報告」の項目 |
-| 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle・バックログの範囲と順序、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先リポジトリの設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
-
-コミットの依頼では、単位の判定後もモードが決まらない場合の確認と、通常モードの単位ごとの承認を、Codexが人へ取り次ぐ。Codexは自分で選択・承認しない。
-
-実装・修正の依頼には次の文を含める。
-
-```text
-ユーザー承認済みの範囲でCodexが進行する。shinaps:linear-executeを読み込み、この依頼の範囲と受入条件の中では人へ着手を再確認せず、指定した入口で実行する。計画の相談・質問・障害・完了はBridgeで依頼元のCodexへ返す。人のレビュー・コミット完了を受けた場合も同じ返信先へ報告する。
-入口: shinaps:dev-claude
-初期体制: <役割別人数・根拠・専任なしの責任者・必須検証。途中の増員はdevのメインが判断して進行役へ報告する>
-許可範囲: <設定と会話で許可された操作。dev_delegationの有無を含む>
-```
-
-受信は `read_messages` で全文を読み、受け取ったIDを `ack_messages` で確認する。ackは受領の確認であり、作業の完了ではない。完了は、相手の報告と実際の差分・検証結果で確認する。
-
-再接続後は、宛先を一覧から取得し直す。結果が不明な依頼を重複して送らない。重要な判断と結果はIssueへ記録し、Bridgeを唯一の記録先にしない。Bridgeの依頼は、利用者の明示的な停止や操作の許可範囲を上書きしない。
-
-Bridgeが必要な工程で使えない場合は、未実施の引き渡しを完了扱いにしない。担当を入れ替えず、状態と必要な準備を利用者へ伝える。
+利用可能なBridgeツールでプロジェクト名・絶対パス・正確なsession IDを確認し、Issue・受入条件・現在の状態・正本と補足・許可範囲・返信先を渡す。宛先を推測しない。受信は全文を読み、ackは受領だけを表す。結果不明の依頼を重複送信せず、重要な判断と結果はIssueへ残す。Bridgeがなければ進行役のCodex側へ開始を案内する。
 
 ### 人のレビュー・コミット完了の報告
 
-Claudeは、対象Issue、Gitの作業ディレクトリとブランチ、コミットSHA、人から受けた完了通知の内容、残作業を報告する。Gitにコミットがあるだけで、人のレビュー済みと推測しない。人がレビューだけを行い、コミットを `code_review` の工程の条件によりAIが行う場合は、レビューの完了通知の内容を報告し、コミットは後の工程で扱う。
+Claudeは、対象Issue、Gitの作業ディレクトリとブランチ、コミットSHA、人から受けたレビュー・コミット完了通知、残作業を報告する。Gitにコミットがあるだけで、人のレビュー済みと推測しない。manualでは人がcommitする。
 
 Codexは、対象Issue・差分・コミットと、対象作業の未コミット変更の有無を照合する。報告と実体が一致し、許可済みの工程へ進む場合は、人へ再確認しない。これは人のレビューをAIのレビューで代わりにする扱いではなく、人の完了通知を別のセッション経由で受け取る扱いである。
 
@@ -128,7 +105,7 @@ Bridgeの報告は、新しい公開や破壊的な操作の許可を作らな
 
 ## 人への依頼
 
-Code Reviewを依頼する前に対象差分を確認する。`stage` の許可がある場合だけ、対象だけをステージする。`git diff --cached` と `git status --short` で、新規ファイルの漏れと無関係な差分の混入を確認する。ステージにコミットは含めない。許可がなければ、ステージを人への依頼に含める。
+manualでは合意済みflowを根拠に、`commit` のstash安全手順で単位外を退避し、対象だけstageして提示する。`git diff --cached` と `git status --short` で漏れと混入を確認する。stage後は人のレビュー・修正・commitを待つ。
 
 人レビューの差分提示は[共通手順](../human-review.md)に従う。
 
@@ -136,7 +113,7 @@ Code Reviewを依頼する前に対象差分を確認する。`stage` の許可
 
 | 依頼 | 文例 |
 | --- | --- |
-| Code Review | できるようになったことと重点確認点を添えて「[Issueリンク]の<依頼する作業>をお願いします。」依頼する作業は、設定で必要なコードレビューと、AIに許可していないコミットだけにする |
+| Code Review | できるようになったことと重点確認点を添えて「[Issueリンク]の<依頼する作業>をお願いします。」依頼する作業は、manualのコードレビュー・必要な修正・コミットにする |
 | Human QA | 「[Issueリンク]のHuman QAをお願いします。」 |
 | 外部対応 | 「[Issueリンク]の〇〇をお願いします。」 |
 

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

@@ -1,8 +1,13 @@
 ---
 name: commit
-description: 許可された差分を依存順のローカルコミットにし、各コミットを検証・レビューする。進め方（通常・自律）は各単位の実効方針か確認で決め、選択された範囲で実行する。
+description: 許可された差分を依存順のローカルコミットにし、各コミットを検証・レビューする。review_flow（auto・manual）は各単位の実効方針か確認で決め、選択された範囲で実行する。
 ---
 
+## 質問の実行経路（全工程に優先）
+
+対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
+
+
 ## 作業記録の保存先
 
 作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
@@ -21,7 +26,7 @@ description: 許可された差分を依存順のローカルコミットにし
 
 どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。
 
-Git操作と修正は現在のセッションが行う。独立レビューは利用可能かつ許可された場合に使う。指定のエージェントがなければ、その役割の観点でレビューする。独立レビューがプロジェクトの必須条件なのに実行できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
+AIが担当するGit準備・修正は現在のセッションで行い、manualのレビュー・修正・commitは人が行う。autoは独立レビューを必須とする。必要な担当・許可が利用できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
 
 ## 回復できる状態を作る
 
@@ -38,33 +43,28 @@ 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だから分ける」を先に適用して単位決定と判定を循環させない。
 
 ## 単位ごとの検証・レビュー・コミット
 
-人レビューまたは通常モードの単位承認を依頼するときは、[人レビューの差分提示](../../references/human-review.md)に従う。CodexではPlasmaを開いてコミット対象と表示差分を照合する。Linear進行で同じ差分の人レビューが完了済みなら、その証拠を引き継ぎ、同じレビューを重ねて依頼しない。通常モードの単位承認は別の条件として扱う。
+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情報を受け、以下の照合と復元を続ける。
 
 以下を、その単位のモードで行う。
 
-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-codex/skills/debug/SKILL.md

@@ -3,6 +3,11 @@ name: debug
 description: 再現手順、コード、ログと必要な外部情報から不具合の根本原因を調べ、仮説を実際の証拠で検証する。
 ---
 
+## 質問の実行経路（全工程に優先）
+
+対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
+
+
 # 原因調査
 
 症状・期待する挙動・発生条件を依頼と既存情報から確定する。不足は一問ずつ確認する。プロジェクトの指示と過去の調査を読み、関係するコードとログを追う。再現が必要なら許可された環境を使い、本番データを変更しない。
@@ -14,3 +19,5 @@ description: 再現手順、コード、ログと必要な外部情報から不
 結論、証拠、再現状況、最小の修正方針と未確認を報告する。修正まで依頼されている場合は$shinaps:dev-codexへ引き継ぐ。担当と人数はdevのメインが作業に応じて判断する。調査だけなら変更しない。
 
 必要な記録は.shinaps/work/debug/へ保存し、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。秘密情報・既存記録の削除・外部投稿は含めない。
+
+Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto/manual両modeは [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。

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

@@ -3,6 +3,11 @@ name: explore
 description: 既存挙動の理由、実装方針、変更の影響を対話しながら読み取り専用で調べる。ユーザーが理解してから実装を決めたい場合に使う。
 ---
 
+## 質問の実行経路（全工程に優先）
+
+対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
+
+
 # 対話的な調査
 
 現在の質問を一つに絞り、プロジェクトの指示と関連コード・テスト・設定・履歴を読む。既存の調査記録と利用可能なShinapsルールを使い、確認済みの事実・推測・未確認を分けて説明する。ファイルと行、再現結果、必要な公式資料を根拠にする。
@@ -12,3 +17,5 @@ description: 既存挙動の理由、実装方針、変更の影響を対話し
 質問が曖昧なら結果を左右する点だけ一問確認する。回答後に新たな質問が来たら続け、仕様策定や修正へ自動で進まない。理解が揃い実装を依頼されたら、目的・合意事項・未確認事項・関連ファイルを引き継ぎ、$shinaps:dev-codexを読む。担当と人数はdevのメインが作業に応じて判断する。
 
 継続用の記録が必要なら.shinaps/work/explorations/へ保存する。[作業記録の共通手順](../../references/work-records.md)に従い、秘密情報や無関係な記録を持ち込まない。MCPが使えないときはルール照合未確認と明記する。
+
+Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto/manual両modeは [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。