@shinaps/skills 0.25.0 → 0.26.0

package/README.md

@@ -6,7 +6,7 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 
 共通スキルが持つのは判断手順。対象環境・必須検証・公開条件は、対象プロジェクトの `AGENTS.md` / `CLAUDE.md` と参照先、README、CI、既存スクリプトから読み取る。専用設定ファイルは必須にしない。
 
-例外として `linear` の開発進行とチーム設定の変更には、対象リポジトリの `.shinaps/linear.yaml` を必須にする。操作の継続的な許可と終了地点を会話から推測せず、合意した範囲だけを続けて進めるためである。設定はGit対象外の個人用ローカルファイルで、`.shinaps/.gitignore` の除外に含まれる。設定がなくてもIssueの読み取り・整理はできる。
+例外として `linear-execute` の開発進行とチーム設定の変更には、対象リポジトリの `.shinaps/linear.yaml` を必須にする。操作の継続的な許可と終了地点を会話から推測せず、合意した範囲だけを続けて進めるためである。設定はGit対象外の個人用ローカルファイルで、`.shinaps/.gitignore` の除外に含まれる。設定がなくてもIssueの読み取り・整理はできる。
 
 例えばPCブラウザのみのプロジェクトには対応ブラウザと確認コマンドを書く。iOSプロジェクトにはSimulatorと実機の使い分けを記す。スキルは一律の端末数やOS数を追加しない。既存の情報で決まらず結果を左右する条件だけ確認し、保存を了承された方針をプロジェクト側に残す。
 
@@ -26,11 +26,16 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 | `commit` | 進め方（通常・自律）を `.shinaps/linear.yaml` の `commit_mode` か開始時の確認で決め、検証できる単位でコミットする |
 | `create-pr` | リポジトリの規約に合わせてPRを作成する |
 | `release` | 公開条件を確定し、対象バージョンの利用可能性を確認する |
-| `linear` | LinearのIssue整理から、Codexの進行・設定で選んだ担当（Bridge経由のClaude、またはCodex）の実装・QA・Cycle報告までを進める |
+| `linear-plan` | 相談・必要なspec/explore・Issue作成と整理・プロジェクト設定を行い、実装前で止める |
+| `linear-execute` | Issue単体・Cycle全体・バックログ消化を選び、設定に従って実装・QA・許可された公開を進める |
 
 コミット・PR・リリースは依頼された場合だけ進む。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
 
-`linear` は初版では利用者本人の環境向けで、Codexが進行とAgent QAを担当する。運用項目はすべて明示必須で、未記載を既定値で補わない。実装の担当は作業先の `.shinaps/linear.yaml` の `implementation_skill` で選ぶ。`dev-claude`・`dev-claude-ultra` を選ぶと、ClaudeがAI Terminal Bridge経由の依頼で実装する。`dev-codex`・`dev-codex-ultra` を選ぶと、Codexが自分で実装・QA指摘の修正・許可されたコミットを行う。どちらでも既存の許可は増えない。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/` に置く。`references/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
+`linear-execute` は初版では利用者本人の環境向けで、Codexが進行とAgent QAを担当する。運用項目はすべて明示必須で、未記載を既定値で補わない。実装の担当は作業先の `.shinaps/linear.yaml` の `implementation_skill` で選ぶ。`dev-claude`・`dev-claude-ultra` を選ぶと、ClaudeがAI Terminal Bridge経由の依頼で実装する。`dev-codex`・`dev-codex-ultra` を選ぶと、会話側はゴール・進行・Agent QAを担当し、Issueごとの別Codexタスクが実装・QA指摘の修正・許可されたコミットを行う。タスク作成・連絡には `codex_task` とツールが要求する明示依頼が必要。どちらでも既存の許可は増えない。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/linear/` に置く。`references/linear/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
+
+`permissions` の `development_operations` を明示すると、既存アカウントのログイン・環境準備・依存導入・起動・テスト・QAを継続的に許可できる。コミット・公開・破壊的操作の許可や人レビューは別に扱う。
+
+旧 `linear` の入口は廃止した。相談・Issue整理・設定変更は `linear-plan`、実行は `linear-execute` を使う。YAMLの名前・運用項目は変わらない。実行範囲は毎回の依頼で確定し、バックログではブロッカー到達と報告を終了条件にできる。人レビュー・Human QA待ちは予定工程として待機する。
 
 ### dev の入口
 
@@ -60,7 +65,7 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 
 ## Codex
 
-Node.js 22以上と、`plugin marketplace add` / `plugin add` に対応したCodex CLIを使う。Claude Codeのインストールは不要。ただし `linear` の開発進行をClaudeの入口で行う場合は、Claude CodeとAI Terminal Bridgeが必要になる。
+Node.js 22以上と、`plugin marketplace add` / `plugin add` に対応したCodex CLIを使う。Claude Codeのインストールは不要。ただし `linear-execute` の開発進行をClaudeの入口で行う場合は、Claude CodeとAI Terminal Bridgeが必要になる。
 
 導入・更新・削除:
 
@@ -162,7 +167,7 @@ codex mcp add shinaps-ai --url https://app.shinaps.ai/mcp
 codex mcp login shinaps-ai
 ```
 
-未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`commit`・`create-pr`・`release`・`linear` の基本手順はMCP接続を必須としない。
+未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`commit`・`create-pr`・`release`・`linear-plan`・`linear-execute` の基本手順はMCP接続を必須としない。
 
 ## Subagents (Claude: 16 / Codex: 16)
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.25.0",
+  "version": "0.26.0",
   "description": "Install Shinaps AI workflows and custom agents for Codex",
   "type": "module",
   "bin": {

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

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

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

@@ -147,7 +147,7 @@ dev の入口（Claude 版 `dev-claude`・`dev-claude-ultra`、Codex 版 `dev-co
 - 実行した検証コマンドと結果、未実施の確認
 - 残課題・規約衝突・未解決の論点
 
-必要な検証はプロジェクト規約・CI・変更の影響から決める。UIレビューはこの工程に含まれず、別の工程（linear ではAgent QA）で行う。未実施のUIレビューを完了と報告しない。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
+必要な検証はプロジェクト規約・CI・変更の影響から決める。UIレビューはこの工程に含まれず、別の工程（linear-execute ではAgent QA）で行う。未実施のUIレビューを完了と報告しない。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
 
 ### Phase 6: 実装後の4役割を並行実行
 

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

@@ -0,0 +1,26 @@
+# Codexの実装タスク
+
+`implementation_skill` が `dev-codex` または `dev-codex-ultra` の場合に使う。会話側のCodexがゴール・Linear・人への窓口・Agent QA・公開の進行を所有し、Issueごとの別のCodexタスクに実装を任せる。実装タスクは指定されたdevの入口でサブエージェントを使う。別タスクとdev内部のサブエージェントは別の役割である。
+
+## 作成と再利用
+
+- 利用者の明示的な依頼または合意済みの `permissions: [codex_task, ...]` の範囲を確認する。ツールが利用者からの明示依頼を要求する場合はその条件も満たす必要があり、設定だけで迂回しない。必要な許可やツールがなければ開始前に止め、会話側での実装やCLIへの置き換えをしない。
+- 既存の同じIssueの実装タスクがあれば状態を読み直して再利用する。なければ `list_projects` で作業先を特定し、`create_thread` で新しいローカルCodexタスクを一つ作る。会話全体をforkせず、実装に必要な情報だけを渡す。新しいworktreeは作らず、明示的に別途許可された場合だけ使う。ツールが対象checkoutを選べない場合は別のcheckoutで代用せず、必要な準備を案内する。
+- 返された確定済みthreadId・hostIdとIssue・checkout・branchをローカルの作業記録で対応づける。準備中のclientThreadIdを送信先にしない。作成結果が不明なときは一覧と状態を確認してから再試行する。
+- 同じIssueの質問回答・修正・許可されたコミット依頼は `send_message_to_thread` で同じタスクへ送る。モデルを利用者の指定なしに変更しない。dev内のモデル・役割構成は指定した入口に従う。
+
+## 実装依頼に渡すもの
+
+Issueリンク・範囲・受入条件・仕様や調査成果物、指定devスキル、Gitの絶対作業ディレクトリ・ブランチ・現在の差分、ローカル設定と補足の所在、合意済みの操作許可とユーザーの委託許可、必要な検証、会話側のタスクIDを渡す。秘密値をプロンプトへ転記しない。
+
+実装担当には次を明記する。
+
+> あなたはこのIssueの実装担当。指定されたdevスキルで実装・検証し、結果をこのタスクの最終回答へ返す。linear-executeを再起動せず、別の実装タスクや開発ゴールを作らない。dev内部のサブエージェントはdev_delegationの許可範囲で使う。仕様・権限の未決事項は質問として返し、人へ直接着手確認をしない。実装完了だけでコミット・push・公開・IssueのDone更新をしない。コミットは会話側からQA結果と必要な人レビューの証拠または省略根拠を伴う依頼を受け、設定の許可を確認してから行う。他の人・AIの差分を戻さない。
+
+## 待機・QA・修正
+
+会話側は `wait_threads` / `read_thread` で完了・質問・失敗を読み取り、実装結果を確認する。送信成功やタスクの終了だけで実装・QAの合格と扱わない。完了報告には変更範囲、検証結果、dev内レビュー結果、起動方法、未解決事項を含める。コミット依頼後はSHAも照合する。
+
+実装中は会話側で同じファイルを編集しない。Agent QAの開始前に実装タスクの編集が止まったことを確認し、差分と対象版を固定してQAする。不具合は再現手順・期待と実際・証拠とともに同じタスクへ返し、修正終了後に再検証する。実装担当が返したテスト結果を独立したAgent QAの代わりにしない。
+
+質問は会話側が既存の合意で答え、仕様・権限を変える判断だけ人へ確認する。実装タスクの失敗・利用不能時は未完了として報告し、独断で別タスクを重ねない。利用者の停止・範囲変更は実装タスクにも伝え、停止を確認する。次のIssueへは今回の実行範囲と終了条件に従って進む。

package/plugins/shinaps-claude/{skills/linear/references → references/linear}/configuration.md

@@ -41,7 +41,7 @@
 | `permissions` | 継続的に許可した操作の一覧（下の「許可」）。許可なしは `[]` |
 | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
 | `cycle_report` | Cycle報告の設定（下の「Cycle報告」）。報告を使わない場合は `null` |
-| `implementation_skill` | Issueの実装・修正に使うdevの入口。`dev-claude`・`dev-claude-ultra`（CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する）、または `dev-codex`・`dev-codex-ultra`（Codexが自分でその入口を実行する） |
+| `implementation_skill` | Issueの実装・修正に使うdevの入口。`dev-claude`・`dev-claude-ultra`（CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する）、または `dev-codex`・`dev-codex-ultra`（Issueごとの別Codexタスクがその入口を実行し、会話側は進行・Agent QAを担当する） |
 | `commit_mode` | `shinaps:commit` でコミットするときの進め方。`normal`（単位ごとに承認を得る）または `autonomous`（個別の承認なしで単位ごとに検証してコミットする） |
 | `human_code_review` | 人のコードレビューの要否。`required`（人がレビューする）または `skip`（人のレビューを行わない） |
 | `document_only_changes` | 文書だけの変更（下の説明）の扱い。`none` は例外なし。`ai_commit`: 対象差分が文書だけの変更のとき、人のコードレビューを行わず、Local Agent QAの合格後に実装担当が `shinaps:commit` でコミットする（Claudeの入口ではCodexの依頼でClaudeが行う） |
@@ -72,6 +72,8 @@
 | 値 | 許可する操作 |
 | --- | --- |
 | `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
+| `development_operations` | 任された対象の開発に必要な、既存アカウントへの通常のログイン、ローカル環境準備、プロジェクトの依存導入、開発サーバー・Simulatorの起動停止、ビルド・テスト・QA操作を継続的に許可する。下の範囲に従う |
+| `codex_task` | 対象IssueごとのCodex実装タスクの新規作成・状態確認・実装や修正や許可済みコミットの依頼。worktree作成、操作許可の追加、タスク側でのゴールや実装タスクの再作成は含めない。ツールの明示依頼要件も満たす（[codex-task.md](codex-task.md)） |
 | `bridge_request` | BridgeによるCodexからClaudeへの実装・修正の依頼と、ClaudeからCodexへの開発進行の引き渡し |
 | `stage` | レビュー・コミットの対象差分だけをステージする |
 | `commit` | 対象Issueの差分を、Local Agent QAの合格と `human_code_review` に従った工程の後に、`shinaps:commit` でローカルにコミットする。AIのコミットには `stage` の許可も併せて必要。push・PR・履歴の書き換え、人のレビューの省略を含めない。`document_only_changes: ai_commit` による文書だけの変更のコミットは、`commit` がなくても行える（`stage` は必要） |
@@ -83,7 +85,9 @@
 | `dev_delegation` | `implementation_skill` で選んだdevの入口の中で、サブエージェントへ委託する。許可がない場合は、入口のメインが同じ観点を自分で確認し、独立確認とは報告しない。worktreeの作成は含まない |
 | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
 
-- 開発進行には `issue_update` が必要である。`implementation_skill` がClaudeの入口のときは `bridge_request` も必要で、Codexの入口のときは不要である。初期設定では、`issue_update`・`bridge_request`・`stage`・`dev_delegation` を開発進行の標準の組として提案する（Codexの入口を選ぶ場合は `bridge_request` を除く）。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
+- 開発進行には `issue_update` が必要である。`implementation_skill` がClaudeの入口のときは `bridge_request` も必要で、Codexの入口のときは代わりに `codex_task` とCodexタスクの作成・読み取り・送信のツールが必要である。初期設定では、`issue_update`・`bridge_request`・`stage`・`dev_delegation` を開発進行の標準の組として提案する（Codexの入口を選ぶ場合は `bridge_request` を `codex_task` に置き換える）。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
+- `development_operations` は、既存の認証手段と利用者が許可した既存アカウントを使い、対象の開発・検証環境と専用の検証データで行う操作に限る。本人の二要素認証・セキュリティキー・CAPTCHA等が必要なら具体的に依頼し、回避しない。ログイン成功を新しい権限への同意と扱わず、新規アカウント・OAuth権限の拡大・課金・新規クラウド資源・共有環境への破壊的変更・実利用者データの操作は含めない。秘密値をIssueや証拠へ記載しない。
+- この包括許可は `stage`・`commit`・`push`・`pr_create`・`merge`・`deploy:*`・`publish:*`・外部への送信・履歴やデータの破壊的操作を含まない。テストや環境準備がこれらを伴うときも、それぞれの許可が必要。人レビュー・Human QA・ツール側の承認条件を省略しない。`permissions` に明示された場合だけ適用し、既存設定に自動で追加しない。
 - 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする（マージで本番へ自動配備される場合は `merge` と `deploy:production`）。
 - 次の操作は一覧に含めず、常にその場で確認する: force-push、履歴の書き換え、ブランチの削除、チーム設定の変更。
 - 設定の許可は、今回の依頼で任されたIssue・Cycleの範囲を広げない。
@@ -131,6 +135,7 @@ commit_mode: autonomous
 document_only_changes: none
 cycle_report: null
 permissions:
+  - development_operations # この範囲を利用者が合意した場合だけ記載
   - issue_update
   - bridge_request
   - stage
@@ -151,7 +156,7 @@ references:
 
 ## 初期設定
 
-Codexが行う。
+`linear-plan` を実行しているセッションが行う。Claudeも利用者から明示的に依頼された設定を作成・変更できる。開発の進行役を変更するものではない。
 
 1. アカウント、workspace、team、projectと、チームのステータス一覧・既存の運用をLinearから読む。
 2. 作業先リポジトリのAGENTS.md・CLAUDE.md・README・CI・検証や配備のスクリプトを読み、`references` の候補を決める。

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

@@ -0,0 +1,39 @@
+# 実行範囲とゴール
+
+実行範囲は今回の依頼で決める。YAMLは担当・QA・レビュー・操作許可・終了地点を決めるもので、実行範囲の既定値を持たない。
+
+| モード | 対象 | 終了条件 |
+| --- | --- | --- |
+| Issue単体 | 指定Issue | そのIssueの完了 |
+| Cycle全体 | 指定Cycleの開始時点の対象Issue | 全件完了と合意された全体QA・成果報告 |
+| バックログ消化 | 指定プロジェクト・チーム・フィルター等で限定した開始時点のIssue集合 | 全件消化、または最初のブロッカーに到達し状況を報告 |
+
+## 開始時に固定するもの
+
+依頼からモードと対象を特定できれば聞き直さない。不明な場合だけ上の3つから一問で確認する。「全部」をworkspace全体と推測しない。
+
+対象一覧は最後のページまで読み、作業先・依存・状態・優先順位を確認する。対象IDの一覧、依存順の実行順、開始時点、終了条件を既存の親Issue・依頼元Issueのコメントまたはローカル作業記録へ残す。記録のためだけに親Issueを新設しない。後から追加されたIssue、別Cycle、対象外の依存Issueを自動で取り込まない。順序を変える必要がある場合は理由を記録し、範囲の変更は利用者と合意する。
+
+各Issueの作業先の設定・補足を読み、担当と許可を引き継ぐ。設定がない・不足する対象を他のリポジトリの設定で実行しない。バックログで開始時から進められない場合も、その理由を報告し、独断で対象を除外して消化済みにしない。
+
+`stop_after` がIssue完了より手前の場合は、開始前に今回の依頼との相違を解消する。途中の終了地点までを明示的に任された場合は、その到達点を実行ゴールとして記録し、Issue全体の完了とは報告しない。Cycle完了報告を含む依頼で `cycle_report: null` の場合も、設定変更か報告なしの範囲を利用者と合意してから進む。操作許可を暗黙に増やさない。
+
+## 継続と待機
+
+原則、確定した順序で一つずつ実行する。Issue単体の依頼では完了後に別Issueへ進まない。複数対象では、現在のIssueのQA・必要な人の対応・コミットを残して次へ切り替えない。
+
+- 人レビュー・Human QA・本人認証・予定された手動コミット待ちは必要な工程として依頼し、作業中のまま待機する。回答がないことや待ち時間をブロッカー到達・承認・完了と扱わない。
+- 許可範囲で自分が解消できる実装・QAの不具合は修正して再検証する。テストの失敗だけでバックログ実行を打ち切らない。
+- 未決の仕様判断、許可不足、対象外の依存、外部障害など、現在の許可と対象内では解消できない進行不能をブロッカーとする。
+- バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
+- Issue単体・Cycle全体では、ブロッカー報告だけで完了にしない。必要な判断や準備を求め、再開条件を記録する。
+
+## ゴール機能
+
+実行開始の必須条件として、上の対象と終了条件を持つゴールが設定済みであることを確認する。ゴールの作成成功、または同じ対象の既存ゴールの状態をツールで確認してから実装・QA・公開の進行を始める。文章で目標を書くだけでは設定済みとしない。ツールが利用者の明示依頼を要求する場合、スキルの選択だけで迂回せず、既存の明示依頼を使い、なければ開始時に一度確認し、回答と設定成功を待つ。同じ対象のゴールは再利用し、別の未完了ゴールを上書きしない。予算は明示された場合だけ設定する。
+
+ゴール機能が利用できない、作成に失敗した、または別の未完了ゴールと競合する場合は、理由と必要な準備を報告して実行開始前で止まる。ゴールなしで代替実行しない。
+
+通常の人の対応待ちで自発的にゴールを一時停止・完了にしない。ツール側のblocked等の状態条件、予算・実行制限と利用者の停止指示を優先する。Issueのステータスとゴールの状態を混同しない。バックログでは、事前に終了条件として合意した「ブロッカー到達と報告」を満たした場合に限り実行ゴールを完了にできる。
+
+再開時は記録した対象・到達点を読み直し、変更されたIssueや設定を照合する。対象の追加や、停止済みバックログの再開を独断で行わない。予約実行や定期監視は別の依頼が必要。

package/plugins/{shinaps-codex/skills/linear/references → shinaps-claude/references/linear}/issue.md

@@ -10,7 +10,7 @@
 
 1. 作業先リポジトリと、紐づけ先のworkspace・team・projectを決める。紐づけ先は、[configuration.md](configuration.md) の「設定の読み方」に従って読んだ作業先リポジトリの設定の `target`、または利用者がその場で指定した先にする。
 2. 決めた先で、目的と作業先に合う既存Issue（依頼で示されたIssue、未完了のIssue、作業を含む親・関連Issue）を探し、あれば再利用する。作業が既存Issueの範囲に入る場合は、そのIssueの中の手順として扱う。
-3. 該当がなければ、利用者から任された目的について、下の「共通Issueテンプレート」に従って作成する。作成は、各版のSKILL.mdと [configuration.md](configuration.md) の「許可」で認められた範囲だけで行う。新しいIssueをCycleへ入れるのは、既存の合意か明示依頼がある場合だけにする（「Cycle・期限・見積もり」）。作成の後は読み戻し、結果が不明なら現状を確かめてから再試行し（「要件を整理する手順」）、同じ目的のIssueを重ねて作らない。
+3. 該当がなければ、利用者から任された目的について、下の「共通Issueテンプレート」に従って作成する。作成は、呼び出し元の `linear-plan` / `linear-execute` と [configuration.md](configuration.md) の「許可」で認められた範囲だけで行う。新しいIssueをCycleへ入れるのは、既存の合意か明示依頼がある場合だけにする（「Cycle・期限・見積もり」）。作成の後は読み戻し、結果が不明なら現状を確かめてから再試行し（「要件を整理する手順」）、同じ目的のIssueを重ねて作らない。
 4. 使うIssueのリンクを、会話またはBridgeの依頼・報告に示してから実作業に入る。
 
 紐づけ先が決まらない、接続できない、または新しいIssueの作成が必要だがその許可がない場合は、別のworkspace・team・projectや別のリポジトリの設定で代わりに作成・更新しない。紐づけを必要とする実作業の前で止まり、理由と必要な判断・準備（作成の許可がない場合はIssue案）を利用者に伝え、回答を得てから再開する。

package/plugins/shinaps-claude/{skills/linear/references → references/linear}/workflow.md

@@ -8,11 +8,11 @@
 | 実装担当 | 技術調査、`implementation_skill` で選んだdevの入口による実装・自動テスト・簡素化・セルフレビュー、QA指摘の修正、成果と人の対応結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
 | 人 | 未合意の仕様・権限の判断、設定で必要なコードレビュー・必要な修正、AIに許可していないコミット、本人の操作が必要な認証等、必要なHuman QA |
 
-実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口（`dev-claude`・`dev-claude-ultra`）では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口（`dev-codex`・`dev-codex-ultra`）では、この文書でClaudeが行うとした実装・修正・コミット・完了報告をCodexが自分で行い、そのためのBridgeの依頼・報告を使わない。どちらでもLocal Agent QAは実装とは別の工程として行い、実装担当の報告を合格の根拠にしない。
+実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口（`dev-claude`・`dev-claude-ultra`）では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口（`dev-codex`・`dev-codex-ultra`）では、この文書でClaudeが行うとした実装・修正・コミット・完了報告を会話側とは別のCodex実装タスクが行い、[Codex実装タスク](codex-task.md)の手順で依頼・結果を扱う。Bridgeは使わない。どちらでもLocal Agent QAは実装とは別の工程として行い、実装担当の報告を合格の根拠にしない。
 
-人への質問と依頼はCodexが窓口になる。Claudeは人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
+人への質問と依頼は会話側のCodexが窓口になる。実装担当は人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
 
-CodexはQAで見つけた不具合をQAの工程の中で修正せず、再現条件と証拠を実装担当へ返す。Codexの入口では、Codexが実装担当として同じ入口で修正し、改めてQAを行う。同じ作業ツリーを同時に編集せず、人や他のAIの変更を保持する。
+CodexはQAで見つけた不具合をQAの工程の中で修正せず、再現条件と証拠を実装担当へ返す。Codexの入口でも会話側は修正せず、同じ実装タスクへ戻してから改めてQAを行う。同じ作業ツリーを同時に編集せず、人や他のAIの変更を保持する。
 
 Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐付けなど）は、Codexが利用可能なブラウザで行う。MCPが対応していないという理由だけで人へ回さない。人の認証や権限が必要な場合だけ人へ依頼する。
 
@@ -20,12 +20,12 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 | 状況 | 必要な行動 |
 | --- | --- |
-| Codexから許可範囲と受入条件を伴う実装・修正の依頼を受けた | Claudeは人へ着手を再確認せず、指定されたスキルで実行する |
-| devの入口の中で計画上の判断が必要になった | Claudeの入口ではClaudeがCodexへ相談する。Codexは既存の合意で判断できれば回答し、人へ再承認を求めない |
-| QAで受入条件の範囲内の不具合が見つかった | CodexがClaudeへ修正を依頼し（Codexの入口では自分で修正し）、実装担当は人の着手許可を改めて取らずに修正する。Codexが再検証する |
+| Codexから許可範囲と受入条件を伴う実装・修正の依頼を受けた | 実装担当は人へ着手を再確認せず、指定されたスキルで実行する |
+| devの入口の中で計画上の判断が必要になった | 実装担当が会話側のCodexへ相談する。Codexは既存の合意で判断できれば回答し、人へ再承認を求めない |
+| QAで受入条件の範囲内の不具合が見つかった | CodexがClaudeへ修正を依頼し（Codexの入口では同じCodex実装タスクへ依頼し）、実装担当は人の着手許可を改めて取らずに修正する。Codexが再検証する |
 | Claudeが人のレビュー・コミット完了をBridgeで報告した | Codexは人に同じ事実を聞き直さず、報告の対象とGitの状態を照合して次の工程へ進む |
 | 次の操作の継続的な許可があり、必要な工程の結果が揃った | Codexは「進めてもよいか」を再質問せずに実行する |
-| Cycle全体を任され、対象Issueが設定された終了地点に達した | CodexはCycleを読み直し、依存・優先順位から次の実行可能なIssueを選んで続ける |
+| Cycle全体を任され、対象Issueが設定された終了地点に達した | Codexは開始時に確定した対象と順序を照合し、その範囲の次のIssueへ進む |
 
 「自律的に進める」とだけ書かず、この表と具体的な許可範囲を各Bridge依頼に書く。
 
@@ -42,7 +42,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` では人のレビュー完了の確認後）に、`commit` と `stage` の許可があれば実装担当が行い（Claudeの入口ではCodexの依頼による）、なければ人が行う。対象コミットと、人の完了通知または省略の記録を照合する。`document_only_changes: ai_commit` があり、対象差分が文書だけの変更に当たる場合は、下の箇条に従う |
+| `code_review` | Code Review（人のレビューまたは省略の記録・コミット） | `human_code_review: required` では人がレビュー・修正する。`skip` では人へのレビュー依頼も待ちも作らず、省略を記録する。コミットは、Local Agent QAの合格後（`required` では人のレビュー完了の確認後）に、`commit` と `stage` の許可があれば実装担当が行い（どちらの入口でも会話側のCodexの依頼による）、なければ人が行う。対象コミットと、人の完了通知または省略の記録を照合する。`document_only_changes: ai_commit` があり、対象差分が文書だけの変更に当たる場合は、下の箇条に従う |
 | `post_commit` | コミット後の検証・PR準備 | 設定に従って、push前の最終Agent QA、必須検証、許可されたpush・PR作成を行う |
 | `staging_agent_qa` | Staging Agent QA | 配備されたPR候補版をCodexが検証する |
 | `staging_human_qa` | Staging Human QA | そのPRで必要な人の確認。不要なら理由を記録して省略する |
@@ -77,7 +77,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 ## 待ち状態
 
-その場の質問と、本人が対応できるレビュー・作業の待ちは、元の工程を維持する。外部の資料提供・権限付与・審査など、自分たちでは解消できない対応の待ちだけを `human_input` で表す。別Issueの待ちは依存関係、Claudeの作業待ちはAI間の待機として扱う。
+その場の質問と、本人が対応できるレビュー・作業の待ちは、元の工程を維持する。外部の資料提供・権限付与・審査など、自分たちでは解消できない対応の待ちだけを `human_input` で表す。別Issueの待ちは依存関係、実装担当の作業待ちはAI間の待機として扱う。
 
 待つときは、必要な対応・担当・再開条件・戻る工程をIssueのコメントへ記録する。人の回答や対応完了を確認したら続け、同じ依頼を繰り返さない。
 
@@ -95,14 +95,14 @@ AI Terminal Bridge（以下Bridge）の本体は同梱しない。導入済み
 | コミットの依頼（CodexからClaude） | Issueリンク、対象差分・Gitの作業ディレクトリ・ブランチ、Local Agent QAの結果、人のレビューの状態（完了通知の内容、または設定による省略）、返信先のCodexの `session_id` |
 | 完了の報告（ClaudeからCodex） | 対象差分、自動検証の結果、起動方法、確認観点、既知の制限、未解決の事項、devの入口内のレビュー結果の要約と未解決の指摘。コミットした場合は、コミットSHAと `shinaps:commit` の検証・レビューの結果 |
 | 人のレビュー・コミット完了の報告（ClaudeからCodex） | 下の「人のレビュー・コミット完了の報告」の項目 |
-| 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先リポジトリの設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
+| 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle・バックログの範囲と順序、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先リポジトリの設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
 
 コミットの依頼では、`commit_mode` がない場合の開始時の確認と、通常モードの単位ごとの承認を、Codexが人へ取り次ぐ。Codexは自分で選択・承認しない。
 
 実装・修正の依頼には次の文を含める。
 
 ```text
-ユーザー承認済みの範囲でCodexが進行する。shinaps:linearを読み込み、この依頼の範囲と受入条件の中では人へ着手を再確認せず、指定した入口で実行する。計画の相談・質問・障害・完了はBridgeで依頼元のCodexへ返す。人のレビュー・コミット完了を受けた場合も同じ返信先へ報告する。
+ユーザー承認済みの範囲でCodexが進行する。shinaps:linear-executeを読み込み、この依頼の範囲と受入条件の中では人へ着手を再確認せず、指定した入口で実行する。計画の相談・質問・障害・完了はBridgeで依頼元のCodexへ返す。人のレビュー・コミット完了を受けた場合も同じ返信先へ報告する。
 入口: shinaps:<dev-claude または dev-claude-ultra>
 許可範囲: <設定と会話で許可された操作。dev_delegationの有無を含む>
 ```
@@ -137,22 +137,6 @@ Code Reviewを依頼する前に対象差分を確認する。`stage` の許可
 
 ## Issue単位とCycle単位の継続
 
-Issue単位の依頼は、そのIssueの終了地点で止まる。Cycle全体を任された場合だけ、Cycleを読み直して、依存と優先順位から次のIssueを選ぶ。
+実行範囲・順序・ゴール・終了条件は [execution.md](execution.md) に従う。Issue単体では次のIssueへ進まず、Cycle全体・バックログ消化は開始時に確定した対象の範囲で継続する。
 
-### 開発進行のゴール
-
-Codexは開発進行を始めるとき、利用者が指定した対象（IssueまたはCycle）が完了するまでを一つのゴールとして設定する。Issueなら、そのIssueの完了。Cycleなら、対象Issueの完了と、合意されたCycle全体のQA・成果報告まで。同じ対象の既存のゴールがあれば再利用し、別の未完了のゴールを上書きしない。予算は利用者が明示した場合だけ設定する。Issueの読み取りや整理だけの呼び出しでは、ゴールを設定しない。
-
-設定の `stop_after` が対象の完了より手前なら、ゴールに到達したと扱わず、開始前に完了までの依頼と設定の相違を利用者と解消する。この解消で許可範囲を暗黙に広げない。通常の人の対応待ちで自発的にゴールを一時停止・完了にしない（[待ち状態](#待ち状態)）。利用者の明示的な停止・一時停止の指示と、実行環境の上位の制約は尊重する。ゴール機能が利用者からの明示的な依頼を要求する環境では、スキルだけでその制約を迂回しない。利用者の明示的な依頼が既にあればそれを用い、ない場合だけ開始時に一度得る。
-
-| 状況 | 行動 |
-| --- | --- |
-| 継続中のIssue、人の対応が済んだIssueがある | それを優先する。レビュー対象を残して別のIssueへ切り替えない |
-| 次のIssueを選ぶ | Cycle内で依存が解消し、着手できるIssueを優先順位の順に選ぶ |
-| 人の対応が必要になった | Issueリンクと必要な作業を添えて依頼し、回答・対応を確認してから再開する。人の対応を代わりに行わず、対象を残して別のIssueへ切り替えない |
-| 別のAIが作業中 | 完了の報告を待ち、結果を検証して次の工程へ進む。利用者への再開依頼に置き換えない |
-| 進められる作業がない | 理由と再開条件を報告して止まる |
-
-複数のリポジトリを含むCycleでは、各Issueの作業先リポジトリの設定を使う。設定・担当・QAの証拠が足りない部分を、別のリポジトリの結果で代わりにしない。
-
-Cycle外の取り込みと次のCycleへの継続には、別の合意が必要。Cycleの移動や取消で見かけ上の完了を作らない。Cycle実行の終わりには、対象Issueの到達点・未完了の条件・次に必要な対応を要約する。途中の終了地点に達しただけでは、Cycle完了報告を行わない。
+複数リポジトリの作業では各Issueの作業先の設定を使う。Cycleの移動や取消で見かけ上の完了を作らない。Cycleの必須条件をすべて満たした場合だけ [cycle-report.md](cycle-report.md) に従って合意された全体QA・成果報告を行う。

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

@@ -19,7 +19,7 @@ description: 許可された差分を依存順のローカルコミットにし
 
 ## 範囲と進め方
 
-コミットは、ユーザーが明示した場合と、linear の開発進行でCodexからLocal Agent QAの合格後に対象を指定して依頼され、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり文書だけの変更として依頼された（条件の詳細はlinearの `references/configuration.md` の「許可」、文書だけの変更の判定は同じファイルの「項目」）。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linearの開発進行では設定の不足・不正値を解消してから進む。linear以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
+コミットは、ユーザーが明示した場合と、linear-execute の開発進行でCodexからLocal Agent QAの合格後に対象を指定して依頼され、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり文書だけの変更として依頼された（条件の詳細は[Linear共通設定](../../references/linear/configuration.md) の「許可」、文書だけの変更の判定は同じファイルの「項目」）。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linear-executeの開発進行では設定の不足・不正値を解消してから進む。linear-execute以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
 
 - **通常（推奨）**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
 - **自律**: エージェントが検証できる単位を選び（許可された一連の変更をまとめてよい）、検証・レビューして個別の承認を求めずコミットする。

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

@@ -1,6 +1,6 @@
 ---
-name: linear
-description: Codexが進行するLinearの開発で、AI Terminal Bridge経由の実装・修正依頼を受けて実行し、結果、許可されたコミット、人のレビュー・コミット完了をCodexへ報告する。利用者から明示的に依頼されたIssue整理と、作業先の規約か依頼が求める着手前のIssueへの紐づけも行う。
+name: linear-execute
+description: Linearの実行でCodexから受けた実装・修正・コミット依頼を実行し結果を報告する。直接の開発進行依頼は設定と許可を確認してCodexへ引き渡す。相談・Issue整理はlinear-planを使う。
 ---
 
 # Linearの開発でClaudeが行うこと
@@ -13,19 +13,19 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 
 人のレビュー・コミット完了の報告をBridgeで受けたCodexは、報告の対象とGitの状態を照合し、一致すれば既存の許可の範囲で人へ再確認せず次の工程へ進む。
 
-条件の一覧と報告の項目は `references/workflow.md` にある。
+条件の一覧と報告の項目は `../../references/linear/workflow.md` にある。
 
 ## 読む資料
 
-依頼を受けたら、[references/workflow.md](references/workflow.md) の「担当と窓口」「再確認せず進める条件」「Bridgeでの依頼と報告」を読む。依頼に添えられたプロジェクトの補足と参照先も読む。
+依頼を受けたら、[references/workflow.md](../../references/linear/workflow.md) の「担当と窓口」「再確認せず進める条件」「Bridgeでの依頼と報告」を読む。依頼に添えられたプロジェクトの補足と参照先も読む。
 
-他の資料は次の場合だけ読む: 依頼で指示された場合、Issue整理を依頼された場合（[references/issue.md](references/issue.md)）、Codexの依頼なしで実作業を依頼された場合（[references/issue.md](references/issue.md) の「着手前に作業をIssueへ紐づける」）、設定を読む必要がある場合（[references/configuration.md](references/configuration.md) の「設定の読み方」）。
+他の資料は次の場合だけ読む: 依頼で指示された場合、Issue整理を依頼された場合（[references/issue.md](../../references/linear/issue.md)）、Codexの依頼なしで実作業を依頼された場合（[references/issue.md](../../references/linear/issue.md) の「着手前に作業をIssueへ紐づける」）、設定を読む必要がある場合（[references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」）。
 
 ## 依頼を受けて実行する
 
 - 依頼の範囲・受入条件・Gitの作業ディレクトリ・ブランチ・既存差分・許可範囲を確認する。
 - Codexから依頼された実装・修正は、依頼の対象Issueに紐づく。Claudeは別のIssueを作らない。
-- 実装・修正には、依頼で指定された入口（`shinaps:dev-claude` または `shinaps:dev-claude-ultra`）を使う。指定がなければ `shinaps:dev-claude-ultra` を使い、受信側で入口を変えない。devの入口は内部で簡素化・規約照合・レビューを行うので、これらを別に起動しない。入口を使えない場合は、独自の手順で代わりに実装せずCodexへ報告する。
+- 実装・修正には、依頼で指定された入口（`shinaps:dev-claude` または `shinaps:dev-claude-ultra`）を使う。指定と設定を照合し、欠落・不一致ならCodexへ確認してから進め、受信側で入口を変えない。devの入口は内部で簡素化・規約照合・レビューを行うので、これらを別に起動しない。入口を使えない場合は、独自の手順で代わりに実装せずCodexへ報告する。
 - devの入口の委託（サブエージェント）は、依頼の許可範囲に `dev_delegation` が書かれている場合だけ使う。許可範囲に `dev_delegation` がない依頼では委託しない。worktreeの作成は含まない。
 - devの入口が利用者に確認する場面（計画の判断、不明点、承認）では、人ではなくCodexへ相談する。Codexが既存の合意で答えた内容を人へ再確認しない。仕様・受入条件・許可範囲の変更が必要な場合は、Codexが人に確認する。
 - QAで見つかった不具合の修正依頼も同じ扱いにし、人の着手許可を改めて取らない。
@@ -35,15 +35,17 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
   - 作業先リポジトリの設定の `permissions` に `commit` と `stage` があり、CodexがLocal Agent QAの合格後にコミットを依頼した場合。
   - 設定に `document_only_changes: ai_commit` と `stage` があり、CodexがLocal Agent QAの合格後に文書だけの変更としてコミットを依頼した場合。
 
-  後の2つでは、Claude自身が設定（[references/configuration.md](references/configuration.md) の「設定の読み方」）で必要なキーと許可を確認する。3つ目では、依頼された対象差分が、作業ツリー上の同じ対象（ファイルと内容）の差分と一致することも確認する（[references/workflow.md](references/workflow.md) の `code_review`）。実装完了の直後に先行してコミットしない。それ以外のCodexの依頼はコミットの許可にならない。コミットは `shinaps:commit` で行い、進め方は `commit_mode` か開始時の確認で決める。確認と承認の扱いは、[references/workflow.md](references/workflow.md) の「Bridgeでの依頼と報告」に従う。
+  後の2つでは、Claude自身が設定（[references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」）で必要なキーと許可を確認する。3つ目では、依頼された対象差分が、作業ツリー上の同じ対象（ファイルと内容）の差分と一致することも確認する（[references/workflow.md](../../references/linear/workflow.md) の `code_review`）。実装完了の直後に先行してコミットしない。それ以外のCodexの依頼はコミットの許可にならない。コミットは `shinaps:commit` で行い、進め方は `commit_mode` か開始時の確認で決める。確認と承認の扱いは、[references/workflow.md](../../references/linear/workflow.md) の「Bridgeでの依頼と報告」に従う。
 
 ## 結果と人の対応を報告する
 
-- 完了の報告と、人のレビュー・コミット完了の報告に含める項目は、[references/workflow.md](references/workflow.md) の「Bridgeでの依頼と報告」に従う。
+- 完了の報告と、人のレビュー・コミット完了の報告に含める項目は、[references/workflow.md](../../references/linear/workflow.md) の「Bridgeでの依頼と報告」に従う。
 - 人へ着手の確認やコミットの依頼をしない。人がClaudeへ直接伝えた指示や結果は保持し、Codexへ報告する。Gitにコミットがあるだけで、人のレビュー済みと報告しない。設定で人のレビューを省略した場合は、省略と報告する。
 
 ## Codexの依頼なしで起動された場合
 
-- 利用者から直接依頼された実作業（開発進行の依頼を除く）は、着手前に [references/issue.md](references/issue.md) の「着手前に作業をIssueへ紐づける」に従う。Issueの作成は利用者がその場で依頼した場合だけ行い、設定の `issue_update` を根拠にしない。
-- 利用者から明示的にIssueの整理を依頼された場合は、[references/issue.md](references/issue.md) に従って整理する。Issueの更新は、依頼で指定された範囲だけにする（設定の有無にかかわらない）。
-- 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、Claudeは進行役を兼ねない。作業先リポジトリの設定で `bridge_request` が許可され、BridgeでCodexのセッションを特定できる場合は、[references/workflow.md](references/workflow.md) の「開発進行の引き渡し」の項目を添えてCodexへ引き渡す。設定は [references/configuration.md](references/configuration.md) の「設定の読み方」に従って読む。許可や相手のセッションがない場合は、必要な準備（設定、Codexセッションの起動、Bridgeの導入）を利用者へ案内する。
+相談・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は進行役を兼ねない。作業先リポジトリの設定で `bridge_request` が許可され、BridgeでCodexのセッションを特定できる場合は、[references/workflow.md](../../references/linear/workflow.md) の「開発進行の引き渡し」の項目を添えてCodexへ引き渡す。設定は [references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従って読む。許可や相手のセッションがない場合は、必要な準備（設定、Codexセッションの起動、Bridgeの導入）を利用者へ案内する。

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

@@ -0,0 +1,24 @@
+---
+name: linear-plan
+description: アイデアの相談・調査・仕様整理を行い、LinearのIssueを作成・更新・分割する。必要に応じてspecやexploreを使い、Issue整理までで止める。プロジェクトのLinear設定の初期設定・変更も扱う。
+---
+
+# 相談を実行可能なIssueへまとめる
+
+相談の目的を確認し、既存の会話・仕様・Issue・コードから分かる内容は再質問しない。仕様が曖昧なら `shinaps:spec`、既存挙動や影響の調査なら `shinaps:explore` を使う。明確な小さな作業は直接整理し、毎回これらのスキルを必須にしない。委託やworktreeの作成は既存の許可に従う。
+
+## 整理と保存
+
+- [設定](../../references/linear/configuration.md)で作業先・Linearの対象・許可を確認する。設定がなくても相談・読み取り・整理案の提示と、利用者が明示的に依頼したIssue更新はできる。別プロジェクトの設定を借用しない。
+- [Issueの整理と記録](../../references/linear/issue.md)に従い既存Issueを検索して再利用する。目的・範囲・受入条件・依存・未決事項を整理し、必要ならレビューできる到達点で分割する。要件の正本やspec/exploreの成果物へ参照を付ける。
+- spec/exploreから実装へ進む案内があっても、この入口では実装を始めない。調査中の確認や読み取りを、製品コードの変更に広げない。
+- Issueの作成・更新は、利用者の明示依頼または設定の `issue_update` が許可する範囲で行う。Claudeは利用者の明示依頼の範囲だけで更新する。チーム設定変更は別の合意が必要。
+- 計画対象の調査自体をIssueで管理する規約がある場合も、同じ目的の既存Issueを使い、細かな手順ごとのIssueは増やさない。相談の結果、Issueを作らず保留・見送りにしてもよい。
+
+## 設定の初期作成・変更
+
+[configuration.md](../../references/linear/configuration.md)の手順で合意済みの内容を保存する。運用項目を暗黙に補完しない。設定変更は実装開始を意味せず、実行範囲の既定値をYAMLに追加しない。
+
+## 終了と引き渡し
+
+作成・更新したIssue、決定事項、未決事項と依存を示して終了する。相談だけなら結論を返す。開発用ゴールの設定、実装、コミット・公開には進まない。利用者が続けて実行を明示的に依頼したときだけ `shinaps:linear-execute` へIssueと成果物を渡し、実行範囲を確定する。

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

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

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

@@ -147,7 +147,7 @@ dev の入口（Claude 版 `dev-claude`・`dev-claude-ultra`、Codex 版 `dev-co
 - 実行した検証コマンドと結果、未実施の確認
 - 残課題・規約衝突・未解決の論点
 
-必要な検証はプロジェクト規約・CI・変更の影響から決める。UIレビューはこの工程に含まれず、別の工程（linear ではAgent QA）で行う。未実施のUIレビューを完了と報告しない。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
+必要な検証はプロジェクト規約・CI・変更の影響から決める。UIレビューはこの工程に含まれず、別の工程（linear-execute ではAgent QA）で行う。未実施のUIレビューを完了と報告しない。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
 
 ### Phase 6: 実装後の4役割を並行実行
 

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

@@ -0,0 +1,26 @@
+# Codexの実装タスク
+
+`implementation_skill` が `dev-codex` または `dev-codex-ultra` の場合に使う。会話側のCodexがゴール・Linear・人への窓口・Agent QA・公開の進行を所有し、Issueごとの別のCodexタスクに実装を任せる。実装タスクは指定されたdevの入口でサブエージェントを使う。別タスクとdev内部のサブエージェントは別の役割である。
+
+## 作成と再利用
+
+- 利用者の明示的な依頼または合意済みの `permissions: [codex_task, ...]` の範囲を確認する。ツールが利用者からの明示依頼を要求する場合はその条件も満たす必要があり、設定だけで迂回しない。必要な許可やツールがなければ開始前に止め、会話側での実装やCLIへの置き換えをしない。
+- 既存の同じIssueの実装タスクがあれば状態を読み直して再利用する。なければ `list_projects` で作業先を特定し、`create_thread` で新しいローカルCodexタスクを一つ作る。会話全体をforkせず、実装に必要な情報だけを渡す。新しいworktreeは作らず、明示的に別途許可された場合だけ使う。ツールが対象checkoutを選べない場合は別のcheckoutで代用せず、必要な準備を案内する。
+- 返された確定済みthreadId・hostIdとIssue・checkout・branchをローカルの作業記録で対応づける。準備中のclientThreadIdを送信先にしない。作成結果が不明なときは一覧と状態を確認してから再試行する。
+- 同じIssueの質問回答・修正・許可されたコミット依頼は `send_message_to_thread` で同じタスクへ送る。モデルを利用者の指定なしに変更しない。dev内のモデル・役割構成は指定した入口に従う。
+
+## 実装依頼に渡すもの
+
+Issueリンク・範囲・受入条件・仕様や調査成果物、指定devスキル、Gitの絶対作業ディレクトリ・ブランチ・現在の差分、ローカル設定と補足の所在、合意済みの操作許可とユーザーの委託許可、必要な検証、会話側のタスクIDを渡す。秘密値をプロンプトへ転記しない。
+
+実装担当には次を明記する。
+
+> あなたはこのIssueの実装担当。指定されたdevスキルで実装・検証し、結果をこのタスクの最終回答へ返す。linear-executeを再起動せず、別の実装タスクや開発ゴールを作らない。dev内部のサブエージェントはdev_delegationの許可範囲で使う。仕様・権限の未決事項は質問として返し、人へ直接着手確認をしない。実装完了だけでコミット・push・公開・IssueのDone更新をしない。コミットは会話側からQA結果と必要な人レビューの証拠または省略根拠を伴う依頼を受け、設定の許可を確認してから行う。他の人・AIの差分を戻さない。
+
+## 待機・QA・修正
+
+会話側は `wait_threads` / `read_thread` で完了・質問・失敗を読み取り、実装結果を確認する。送信成功やタスクの終了だけで実装・QAの合格と扱わない。完了報告には変更範囲、検証結果、dev内レビュー結果、起動方法、未解決事項を含める。コミット依頼後はSHAも照合する。
+
+実装中は会話側で同じファイルを編集しない。Agent QAの開始前に実装タスクの編集が止まったことを確認し、差分と対象版を固定してQAする。不具合は再現手順・期待と実際・証拠とともに同じタスクへ返し、修正終了後に再検証する。実装担当が返したテスト結果を独立したAgent QAの代わりにしない。
+
+質問は会話側が既存の合意で答え、仕様・権限を変える判断だけ人へ確認する。実装タスクの失敗・利用不能時は未完了として報告し、独断で別タスクを重ねない。利用者の停止・範囲変更は実装タスクにも伝え、停止を確認する。次のIssueへは今回の実行範囲と終了条件に従って進む。

package/plugins/shinaps-codex/{skills/linear/references → references/linear}/configuration.md

@@ -41,7 +41,7 @@
 | `permissions` | 継続的に許可した操作の一覧（下の「許可」）。許可なしは `[]` |
 | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
 | `cycle_report` | Cycle報告の設定（下の「Cycle報告」）。報告を使わない場合は `null` |
-| `implementation_skill` | Issueの実装・修正に使うdevの入口。`dev-claude`・`dev-claude-ultra`（CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する）、または `dev-codex`・`dev-codex-ultra`（Codexが自分でその入口を実行する） |
+| `implementation_skill` | Issueの実装・修正に使うdevの入口。`dev-claude`・`dev-claude-ultra`（CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する）、または `dev-codex`・`dev-codex-ultra`（Issueごとの別Codexタスクがその入口を実行し、会話側は進行・Agent QAを担当する） |
 | `commit_mode` | `shinaps:commit` でコミットするときの進め方。`normal`（単位ごとに承認を得る）または `autonomous`（個別の承認なしで単位ごとに検証してコミットする） |
 | `human_code_review` | 人のコードレビューの要否。`required`（人がレビューする）または `skip`（人のレビューを行わない） |
 | `document_only_changes` | 文書だけの変更（下の説明）の扱い。`none` は例外なし。`ai_commit`: 対象差分が文書だけの変更のとき、人のコードレビューを行わず、Local Agent QAの合格後に実装担当が `shinaps:commit` でコミットする（Claudeの入口ではCodexの依頼でClaudeが行う） |
@@ -72,6 +72,8 @@
 | 値 | 許可する操作 |
 | --- | --- |
 | `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
+| `development_operations` | 任された対象の開発に必要な、既存アカウントへの通常のログイン、ローカル環境準備、プロジェクトの依存導入、開発サーバー・Simulatorの起動停止、ビルド・テスト・QA操作を継続的に許可する。下の範囲に従う |
+| `codex_task` | 対象IssueごとのCodex実装タスクの新規作成・状態確認・実装や修正や許可済みコミットの依頼。worktree作成、操作許可の追加、タスク側でのゴールや実装タスクの再作成は含めない。ツールの明示依頼要件も満たす（[codex-task.md](codex-task.md)） |
 | `bridge_request` | BridgeによるCodexからClaudeへの実装・修正の依頼と、ClaudeからCodexへの開発進行の引き渡し |
 | `stage` | レビュー・コミットの対象差分だけをステージする |
 | `commit` | 対象Issueの差分を、Local Agent QAの合格と `human_code_review` に従った工程の後に、`shinaps:commit` でローカルにコミットする。AIのコミットには `stage` の許可も併せて必要。push・PR・履歴の書き換え、人のレビューの省略を含めない。`document_only_changes: ai_commit` による文書だけの変更のコミットは、`commit` がなくても行える（`stage` は必要） |
@@ -83,7 +85,9 @@
 | `dev_delegation` | `implementation_skill` で選んだdevの入口の中で、サブエージェントへ委託する。許可がない場合は、入口のメインが同じ観点を自分で確認し、独立確認とは報告しない。worktreeの作成は含まない |
 | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
 
-- 開発進行には `issue_update` が必要である。`implementation_skill` がClaudeの入口のときは `bridge_request` も必要で、Codexの入口のときは不要である。初期設定では、`issue_update`・`bridge_request`・`stage`・`dev_delegation` を開発進行の標準の組として提案する（Codexの入口を選ぶ場合は `bridge_request` を除く）。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
+- 開発進行には `issue_update` が必要である。`implementation_skill` がClaudeの入口のときは `bridge_request` も必要で、Codexの入口のときは代わりに `codex_task` とCodexタスクの作成・読み取り・送信のツールが必要である。初期設定では、`issue_update`・`bridge_request`・`stage`・`dev_delegation` を開発進行の標準の組として提案する（Codexの入口を選ぶ場合は `bridge_request` を `codex_task` に置き換える）。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
+- `development_operations` は、既存の認証手段と利用者が許可した既存アカウントを使い、対象の開発・検証環境と専用の検証データで行う操作に限る。本人の二要素認証・セキュリティキー・CAPTCHA等が必要なら具体的に依頼し、回避しない。ログイン成功を新しい権限への同意と扱わず、新規アカウント・OAuth権限の拡大・課金・新規クラウド資源・共有環境への破壊的変更・実利用者データの操作は含めない。秘密値をIssueや証拠へ記載しない。
+- この包括許可は `stage`・`commit`・`push`・`pr_create`・`merge`・`deploy:*`・`publish:*`・外部への送信・履歴やデータの破壊的操作を含まない。テストや環境準備がこれらを伴うときも、それぞれの許可が必要。人レビュー・Human QA・ツール側の承認条件を省略しない。`permissions` に明示された場合だけ適用し、既存設定に自動で追加しない。
 - 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする（マージで本番へ自動配備される場合は `merge` と `deploy:production`）。
 - 次の操作は一覧に含めず、常にその場で確認する: force-push、履歴の書き換え、ブランチの削除、チーム設定の変更。
 - 設定の許可は、今回の依頼で任されたIssue・Cycleの範囲を広げない。
@@ -131,6 +135,7 @@ commit_mode: autonomous
 document_only_changes: none
 cycle_report: null
 permissions:
+  - development_operations # この範囲を利用者が合意した場合だけ記載
   - issue_update
   - bridge_request
   - stage
@@ -151,7 +156,7 @@ references:
 
 ## 初期設定
 
-Codexが行う。
+`linear-plan` を実行しているセッションが行う。Claudeも利用者から明示的に依頼された設定を作成・変更できる。開発の進行役を変更するものではない。
 
 1. アカウント、workspace、team、projectと、チームのステータス一覧・既存の運用をLinearから読む。
 2. 作業先リポジトリのAGENTS.md・CLAUDE.md・README・CI・検証や配備のスクリプトを読み、`references` の候補を決める。

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

@@ -0,0 +1,39 @@
+# 実行範囲とゴール
+
+実行範囲は今回の依頼で決める。YAMLは担当・QA・レビュー・操作許可・終了地点を決めるもので、実行範囲の既定値を持たない。
+
+| モード | 対象 | 終了条件 |
+| --- | --- | --- |
+| Issue単体 | 指定Issue | そのIssueの完了 |
+| Cycle全体 | 指定Cycleの開始時点の対象Issue | 全件完了と合意された全体QA・成果報告 |
+| バックログ消化 | 指定プロジェクト・チーム・フィルター等で限定した開始時点のIssue集合 | 全件消化、または最初のブロッカーに到達し状況を報告 |
+
+## 開始時に固定するもの
+
+依頼からモードと対象を特定できれば聞き直さない。不明な場合だけ上の3つから一問で確認する。「全部」をworkspace全体と推測しない。
+
+対象一覧は最後のページまで読み、作業先・依存・状態・優先順位を確認する。対象IDの一覧、依存順の実行順、開始時点、終了条件を既存の親Issue・依頼元Issueのコメントまたはローカル作業記録へ残す。記録のためだけに親Issueを新設しない。後から追加されたIssue、別Cycle、対象外の依存Issueを自動で取り込まない。順序を変える必要がある場合は理由を記録し、範囲の変更は利用者と合意する。
+
+各Issueの作業先の設定・補足を読み、担当と許可を引き継ぐ。設定がない・不足する対象を他のリポジトリの設定で実行しない。バックログで開始時から進められない場合も、その理由を報告し、独断で対象を除外して消化済みにしない。
+
+`stop_after` がIssue完了より手前の場合は、開始前に今回の依頼との相違を解消する。途中の終了地点までを明示的に任された場合は、その到達点を実行ゴールとして記録し、Issue全体の完了とは報告しない。Cycle完了報告を含む依頼で `cycle_report: null` の場合も、設定変更か報告なしの範囲を利用者と合意してから進む。操作許可を暗黙に増やさない。
+
+## 継続と待機
+
+原則、確定した順序で一つずつ実行する。Issue単体の依頼では完了後に別Issueへ進まない。複数対象では、現在のIssueのQA・必要な人の対応・コミットを残して次へ切り替えない。
+
+- 人レビュー・Human QA・本人認証・予定された手動コミット待ちは必要な工程として依頼し、作業中のまま待機する。回答がないことや待ち時間をブロッカー到達・承認・完了と扱わない。
+- 許可範囲で自分が解消できる実装・QAの不具合は修正して再検証する。テストの失敗だけでバックログ実行を打ち切らない。
+- 未決の仕様判断、許可不足、対象外の依存、外部障害など、現在の許可と対象内では解消できない進行不能をブロッカーとする。
+- バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
+- Issue単体・Cycle全体では、ブロッカー報告だけで完了にしない。必要な判断や準備を求め、再開条件を記録する。
+
+## ゴール機能
+
+実行開始の必須条件として、上の対象と終了条件を持つゴールが設定済みであることを確認する。ゴールの作成成功、または同じ対象の既存ゴールの状態をツールで確認してから実装・QA・公開の進行を始める。文章で目標を書くだけでは設定済みとしない。ツールが利用者の明示依頼を要求する場合、スキルの選択だけで迂回せず、既存の明示依頼を使い、なければ開始時に一度確認し、回答と設定成功を待つ。同じ対象のゴールは再利用し、別の未完了ゴールを上書きしない。予算は明示された場合だけ設定する。
+
+ゴール機能が利用できない、作成に失敗した、または別の未完了ゴールと競合する場合は、理由と必要な準備を報告して実行開始前で止まる。ゴールなしで代替実行しない。
+
+通常の人の対応待ちで自発的にゴールを一時停止・完了にしない。ツール側のblocked等の状態条件、予算・実行制限と利用者の停止指示を優先する。Issueのステータスとゴールの状態を混同しない。バックログでは、事前に終了条件として合意した「ブロッカー到達と報告」を満たした場合に限り実行ゴールを完了にできる。
+
+再開時は記録した対象・到達点を読み直し、変更されたIssueや設定を照合する。対象の追加や、停止済みバックログの再開を独断で行わない。予約実行や定期監視は別の依頼が必要。

package/plugins/{shinaps-claude/skills/linear/references → shinaps-codex/references/linear}/issue.md

@@ -10,7 +10,7 @@
 
 1. 作業先リポジトリと、紐づけ先のworkspace・team・projectを決める。紐づけ先は、[configuration.md](configuration.md) の「設定の読み方」に従って読んだ作業先リポジトリの設定の `target`、または利用者がその場で指定した先にする。
 2. 決めた先で、目的と作業先に合う既存Issue（依頼で示されたIssue、未完了のIssue、作業を含む親・関連Issue）を探し、あれば再利用する。作業が既存Issueの範囲に入る場合は、そのIssueの中の手順として扱う。
-3. 該当がなければ、利用者から任された目的について、下の「共通Issueテンプレート」に従って作成する。作成は、各版のSKILL.mdと [configuration.md](configuration.md) の「許可」で認められた範囲だけで行う。新しいIssueをCycleへ入れるのは、既存の合意か明示依頼がある場合だけにする（「Cycle・期限・見積もり」）。作成の後は読み戻し、結果が不明なら現状を確かめてから再試行し（「要件を整理する手順」）、同じ目的のIssueを重ねて作らない。
+3. 該当がなければ、利用者から任された目的について、下の「共通Issueテンプレート」に従って作成する。作成は、呼び出し元の `linear-plan` / `linear-execute` と [configuration.md](configuration.md) の「許可」で認められた範囲だけで行う。新しいIssueをCycleへ入れるのは、既存の合意か明示依頼がある場合だけにする（「Cycle・期限・見積もり」）。作成の後は読み戻し、結果が不明なら現状を確かめてから再試行し（「要件を整理する手順」）、同じ目的のIssueを重ねて作らない。
 4. 使うIssueのリンクを、会話またはBridgeの依頼・報告に示してから実作業に入る。
 
 紐づけ先が決まらない、接続できない、または新しいIssueの作成が必要だがその許可がない場合は、別のworkspace・team・projectや別のリポジトリの設定で代わりに作成・更新しない。紐づけを必要とする実作業の前で止まり、理由と必要な判断・準備（作成の許可がない場合はIssue案）を利用者に伝え、回答を得てから再開する。

package/plugins/shinaps-codex/{skills/linear/references → references/linear}/workflow.md

@@ -8,11 +8,11 @@
 | 実装担当 | 技術調査、`implementation_skill` で選んだdevの入口による実装・自動テスト・簡素化・セルフレビュー、QA指摘の修正、成果と人の対応結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
 | 人 | 未合意の仕様・権限の判断、設定で必要なコードレビュー・必要な修正、AIに許可していないコミット、本人の操作が必要な認証等、必要なHuman QA |
 
-実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口（`dev-claude`・`dev-claude-ultra`）では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口（`dev-codex`・`dev-codex-ultra`）では、この文書でClaudeが行うとした実装・修正・コミット・完了報告をCodexが自分で行い、そのためのBridgeの依頼・報告を使わない。どちらでもLocal Agent QAは実装とは別の工程として行い、実装担当の報告を合格の根拠にしない。
+実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口（`dev-claude`・`dev-claude-ultra`）では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口（`dev-codex`・`dev-codex-ultra`）では、この文書でClaudeが行うとした実装・修正・コミット・完了報告を会話側とは別のCodex実装タスクが行い、[Codex実装タスク](codex-task.md)の手順で依頼・結果を扱う。Bridgeは使わない。どちらでもLocal Agent QAは実装とは別の工程として行い、実装担当の報告を合格の根拠にしない。
 
-人への質問と依頼はCodexが窓口になる。Claudeは人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
+人への質問と依頼は会話側のCodexが窓口になる。実装担当は人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
 
-CodexはQAで見つけた不具合をQAの工程の中で修正せず、再現条件と証拠を実装担当へ返す。Codexの入口では、Codexが実装担当として同じ入口で修正し、改めてQAを行う。同じ作業ツリーを同時に編集せず、人や他のAIの変更を保持する。
+CodexはQAで見つけた不具合をQAの工程の中で修正せず、再現条件と証拠を実装担当へ返す。Codexの入口でも会話側は修正せず、同じ実装タスクへ戻してから改めてQAを行う。同じ作業ツリーを同時に編集せず、人や他のAIの変更を保持する。
 
 Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐付けなど）は、Codexが利用可能なブラウザで行う。MCPが対応していないという理由だけで人へ回さない。人の認証や権限が必要な場合だけ人へ依頼する。
 
@@ -20,12 +20,12 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 | 状況 | 必要な行動 |
 | --- | --- |
-| Codexから許可範囲と受入条件を伴う実装・修正の依頼を受けた | Claudeは人へ着手を再確認せず、指定されたスキルで実行する |
-| devの入口の中で計画上の判断が必要になった | Claudeの入口ではClaudeがCodexへ相談する。Codexは既存の合意で判断できれば回答し、人へ再承認を求めない |
-| QAで受入条件の範囲内の不具合が見つかった | CodexがClaudeへ修正を依頼し（Codexの入口では自分で修正し）、実装担当は人の着手許可を改めて取らずに修正する。Codexが再検証する |
+| Codexから許可範囲と受入条件を伴う実装・修正の依頼を受けた | 実装担当は人へ着手を再確認せず、指定されたスキルで実行する |
+| devの入口の中で計画上の判断が必要になった | 実装担当が会話側のCodexへ相談する。Codexは既存の合意で判断できれば回答し、人へ再承認を求めない |
+| QAで受入条件の範囲内の不具合が見つかった | CodexがClaudeへ修正を依頼し（Codexの入口では同じCodex実装タスクへ依頼し）、実装担当は人の着手許可を改めて取らずに修正する。Codexが再検証する |
 | Claudeが人のレビュー・コミット完了をBridgeで報告した | Codexは人に同じ事実を聞き直さず、報告の対象とGitの状態を照合して次の工程へ進む |
 | 次の操作の継続的な許可があり、必要な工程の結果が揃った | Codexは「進めてもよいか」を再質問せずに実行する |
-| Cycle全体を任され、対象Issueが設定された終了地点に達した | CodexはCycleを読み直し、依存・優先順位から次の実行可能なIssueを選んで続ける |
+| Cycle全体を任され、対象Issueが設定された終了地点に達した | Codexは開始時に確定した対象と順序を照合し、その範囲の次のIssueへ進む |
 
 「自律的に進める」とだけ書かず、この表と具体的な許可範囲を各Bridge依頼に書く。
 
@@ -42,7 +42,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` では人のレビュー完了の確認後）に、`commit` と `stage` の許可があれば実装担当が行い（Claudeの入口ではCodexの依頼による）、なければ人が行う。対象コミットと、人の完了通知または省略の記録を照合する。`document_only_changes: ai_commit` があり、対象差分が文書だけの変更に当たる場合は、下の箇条に従う |
+| `code_review` | Code Review（人のレビューまたは省略の記録・コミット） | `human_code_review: required` では人がレビュー・修正する。`skip` では人へのレビュー依頼も待ちも作らず、省略を記録する。コミットは、Local Agent QAの合格後（`required` では人のレビュー完了の確認後）に、`commit` と `stage` の許可があれば実装担当が行い（どちらの入口でも会話側のCodexの依頼による）、なければ人が行う。対象コミットと、人の完了通知または省略の記録を照合する。`document_only_changes: ai_commit` があり、対象差分が文書だけの変更に当たる場合は、下の箇条に従う |
 | `post_commit` | コミット後の検証・PR準備 | 設定に従って、push前の最終Agent QA、必須検証、許可されたpush・PR作成を行う |
 | `staging_agent_qa` | Staging Agent QA | 配備されたPR候補版をCodexが検証する |
 | `staging_human_qa` | Staging Human QA | そのPRで必要な人の確認。不要なら理由を記録して省略する |
@@ -77,7 +77,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 ## 待ち状態
 
-その場の質問と、本人が対応できるレビュー・作業の待ちは、元の工程を維持する。外部の資料提供・権限付与・審査など、自分たちでは解消できない対応の待ちだけを `human_input` で表す。別Issueの待ちは依存関係、Claudeの作業待ちはAI間の待機として扱う。
+その場の質問と、本人が対応できるレビュー・作業の待ちは、元の工程を維持する。外部の資料提供・権限付与・審査など、自分たちでは解消できない対応の待ちだけを `human_input` で表す。別Issueの待ちは依存関係、実装担当の作業待ちはAI間の待機として扱う。
 
 待つときは、必要な対応・担当・再開条件・戻る工程をIssueのコメントへ記録する。人の回答や対応完了を確認したら続け、同じ依頼を繰り返さない。
 
@@ -95,14 +95,14 @@ AI Terminal Bridge（以下Bridge）の本体は同梱しない。導入済み
 | コミットの依頼（CodexからClaude） | Issueリンク、対象差分・Gitの作業ディレクトリ・ブランチ、Local Agent QAの結果、人のレビューの状態（完了通知の内容、または設定による省略）、返信先のCodexの `session_id` |
 | 完了の報告（ClaudeからCodex） | 対象差分、自動検証の結果、起動方法、確認観点、既知の制限、未解決の事項、devの入口内のレビュー結果の要約と未解決の指摘。コミットした場合は、コミットSHAと `shinaps:commit` の検証・レビューの結果 |
 | 人のレビュー・コミット完了の報告（ClaudeからCodex） | 下の「人のレビュー・コミット完了の報告」の項目 |
-| 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先リポジトリの設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
+| 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle・バックログの範囲と順序、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先リポジトリの設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
 
 コミットの依頼では、`commit_mode` がない場合の開始時の確認と、通常モードの単位ごとの承認を、Codexが人へ取り次ぐ。Codexは自分で選択・承認しない。
 
 実装・修正の依頼には次の文を含める。
 
 ```text
-ユーザー承認済みの範囲でCodexが進行する。shinaps:linearを読み込み、この依頼の範囲と受入条件の中では人へ着手を再確認せず、指定した入口で実行する。計画の相談・質問・障害・完了はBridgeで依頼元のCodexへ返す。人のレビュー・コミット完了を受けた場合も同じ返信先へ報告する。
+ユーザー承認済みの範囲でCodexが進行する。shinaps:linear-executeを読み込み、この依頼の範囲と受入条件の中では人へ着手を再確認せず、指定した入口で実行する。計画の相談・質問・障害・完了はBridgeで依頼元のCodexへ返す。人のレビュー・コミット完了を受けた場合も同じ返信先へ報告する。
 入口: shinaps:<dev-claude または dev-claude-ultra>
 許可範囲: <設定と会話で許可された操作。dev_delegationの有無を含む>
 ```
@@ -137,22 +137,6 @@ Code Reviewを依頼する前に対象差分を確認する。`stage` の許可
 
 ## Issue単位とCycle単位の継続
 
-Issue単位の依頼は、そのIssueの終了地点で止まる。Cycle全体を任された場合だけ、Cycleを読み直して、依存と優先順位から次のIssueを選ぶ。
+実行範囲・順序・ゴール・終了条件は [execution.md](execution.md) に従う。Issue単体では次のIssueへ進まず、Cycle全体・バックログ消化は開始時に確定した対象の範囲で継続する。
 
-### 開発進行のゴール
-
-Codexは開発進行を始めるとき、利用者が指定した対象（IssueまたはCycle）が完了するまでを一つのゴールとして設定する。Issueなら、そのIssueの完了。Cycleなら、対象Issueの完了と、合意されたCycle全体のQA・成果報告まで。同じ対象の既存のゴールがあれば再利用し、別の未完了のゴールを上書きしない。予算は利用者が明示した場合だけ設定する。Issueの読み取りや整理だけの呼び出しでは、ゴールを設定しない。
-
-設定の `stop_after` が対象の完了より手前なら、ゴールに到達したと扱わず、開始前に完了までの依頼と設定の相違を利用者と解消する。この解消で許可範囲を暗黙に広げない。通常の人の対応待ちで自発的にゴールを一時停止・完了にしない（[待ち状態](#待ち状態)）。利用者の明示的な停止・一時停止の指示と、実行環境の上位の制約は尊重する。ゴール機能が利用者からの明示的な依頼を要求する環境では、スキルだけでその制約を迂回しない。利用者の明示的な依頼が既にあればそれを用い、ない場合だけ開始時に一度得る。
-
-| 状況 | 行動 |
-| --- | --- |
-| 継続中のIssue、人の対応が済んだIssueがある | それを優先する。レビュー対象を残して別のIssueへ切り替えない |
-| 次のIssueを選ぶ | Cycle内で依存が解消し、着手できるIssueを優先順位の順に選ぶ |
-| 人の対応が必要になった | Issueリンクと必要な作業を添えて依頼し、回答・対応を確認してから再開する。人の対応を代わりに行わず、対象を残して別のIssueへ切り替えない |
-| 別のAIが作業中 | 完了の報告を待ち、結果を検証して次の工程へ進む。利用者への再開依頼に置き換えない |
-| 進められる作業がない | 理由と再開条件を報告して止まる |
-
-複数のリポジトリを含むCycleでは、各Issueの作業先リポジトリの設定を使う。設定・担当・QAの証拠が足りない部分を、別のリポジトリの結果で代わりにしない。
-
-Cycle外の取り込みと次のCycleへの継続には、別の合意が必要。Cycleの移動や取消で見かけ上の完了を作らない。Cycle実行の終わりには、対象Issueの到達点・未完了の条件・次に必要な対応を要約する。途中の終了地点に達しただけでは、Cycle完了報告を行わない。
+複数リポジトリの作業では各Issueの作業先の設定を使う。Cycleの移動や取消で見かけ上の完了を作らない。Cycleの必須条件をすべて満たした場合だけ [cycle-report.md](cycle-report.md) に従って合意された全体QA・成果報告を行う。

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

@@ -19,7 +19,7 @@ description: 許可された差分を依存順のローカルコミットにし
 
 ## 範囲と進め方
 
-コミットは、ユーザーが明示した場合と、linear の開発進行で、対象差分が特定され、実装とは別の工程の Local Agent QA に合格し、`human_code_review: required` なら人のレビューの完了を、`human_code_review: skip` または文書だけの変更の例外なら人のレビューを行わない条件が成り立つことを確認したうえで（省略の記録はコミット後に linear の手順で書く）、コミットの工程に進んだ場合（`implementation_skill` がClaudeの入口ならCodexからの依頼による。Codexの入口なら進行役のCodexが対象を特定して自分でこのスキルへ進む。実装担当の報告を、QAの合格や人の承認として扱わない）で、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり、Local Agent QAで対象差分が文書だけの変更と判定された（Claudeの入口ではその判定を添えて依頼された）（条件の詳細はlinearの `references/configuration.md` の「許可」、文書だけの変更の判定は同じファイルの「項目」）。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linearの開発進行では設定の不足・不正値を解消してから進む。linear以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
+コミットは、ユーザーが明示した場合と、linear-execute の開発進行で、対象差分が特定され、実装とは別の工程の Local Agent QA に合格し、`human_code_review: required` なら人のレビューの完了を、`human_code_review: skip` または文書だけの変更の例外なら人のレビューを行わない条件が成り立つことを確認したうえで（省略の記録はコミット後に linear-execute の手順で書く）、コミットの工程に進んだ場合（`implementation_skill` がClaudeの入口ならCodexからの依頼による。Codexの入口なら会話側のCodexがQA後に対象を特定して実装タスクへ依頼する。実装担当の報告を、QAの合格や人の承認として扱わない）で、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり、Local Agent QAで対象差分が文書だけの変更と判定された（Claudeの入口ではその判定を添えて依頼された）（条件の詳細は[Linear共通設定](../../references/linear/configuration.md) の「許可」、文書だけの変更の判定は同じファイルの「項目」）。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linear-executeの開発進行では設定の不足・不正値を解消してから進む。linear-execute以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
 
 - **通常（推奨）**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
 - **自律**: エージェントが検証できる単位を選び（許可された一連の変更をまとめてよい）、検証・レビューして個別の承認を求めずコミットする。

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

@@ -0,0 +1,44 @@
+---
+name: linear-execute
+description: 指定したIssue・Cycle・バックログの実装からQA・許可された公開まで進める。実行範囲と終了条件を依頼から確定し、プロジェクト設定に従って完了またはブロッカー到達まで継続する。相談やIssue整理だけの依頼はlinear-planを使う。
+---
+
+# Linearを起点に開発を進める
+
+Issueの責務・受入条件・ステータスを、実際の成果と一致させる。初版は利用者本人の環境向けで、Codexが進行・Agent QA・人への窓口を担当する。実装担当は作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口ではClaudeがAI Terminal Bridge（以下Bridge）経由の依頼で実装し、Codexの入口（`dev-codex`・`dev-codex-ultra`）ではIssueごとの別Codexタスクが `$shinaps:<入口>` で実装・QA指摘の修正を行う（[references/workflow.md](../../references/linear/workflow.md) の「担当と窓口」）。設定と異なる担当への入れ替えは扱わない。
+
+## 再確認せず進める条件
+
+Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridgeで受けたClaudeは、人へ着手を再確認せず、指定されたスキルで実行する。質問・相談・障害・完了はCodexへ返す。
+
+人のレビュー・コミット完了の報告をBridgeで受けたCodexは、報告の対象とGitの状態を照合し、一致すれば既存の許可の範囲で人へ再確認せず次の工程へ進む。
+
+条件の一覧と照合の項目は `../../references/linear/workflow.md` にある。
+
+## 実行範囲を確定する
+
+[実行範囲とゴール](../../references/linear/execution.md)を読み、Issue単体・Cycle全体・バックログ消化から依頼に合う範囲を確定する。依頼が明確なら聞き直さず、不明な場合だけ一問確認する。対象ID・順序・終了条件を記録してから実装を始める。
+
+開発進行には作業先の明示された設定と `issue_update` が必要。Claudeの入口では `bridge_request` とBridge、Codexの入口では `codex_task` と別タスクの作成・連絡手段も必要。設定の許可・`stop_after` を超えない。Issue未作成の明示的な実装依頼は共通の紐づけ手順でIssueを作って続けられるが、仕様が未決なら `shinaps:linear-plan` へ整理を戻す。
+
+実行には対象と終了条件を持つゴールの設定成功が必須。環境が明示許可を要求する場合は、既存の依頼で満たされるか確認し、なければ開始前に一度確認する。ゴール未設定のまま実装へ進まない。人レビュー・Human QA待ちは予定された工程として待機する。スキルの実行だけで予約実行・定期監視は開始しない。
+
+## 設定と補足を読む
+
+- 設定の所在・読み方・補足との関係・不足時の止め方は、[references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従う。
+- 作業先リポジトリは、Issue本文の「対象・範囲外」で特定する。Issueがまだない作業では、依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、`list_sessions` の `project_path`、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。
+- 操作の許可は作業先リポジトリの設定で決める。同じLinear projectに属するだけでは、別のリポジトリの作業を現在の設定に含めない。作業先を特定できないIssueや、作業先に設定がないIssueでは、開発進行を始めない。
+- 設定がない場合は、Issueの読み取り、整理案、明示依頼された更新だけを行い、初期設定を案内する。
+
+## 作業ごとに読む資料
+
+| 作業 | 読む資料 |
+| --- | --- |
+| 設定の確認（初期設定・変更は `shinaps:linear-plan`） | [references/configuration.md](../../references/linear/configuration.md) |
+| 着手前の紐づけ、Issueの作成・整理・本文の更新 | [references/issue.md](../../references/linear/issue.md) |
+| 担当、工程、待ち状態、Bridge、人への依頼、継続の範囲 | [references/workflow.md](../../references/linear/workflow.md) |
+| Codex実装タスクの作成・再利用・依頼とQAへの受け渡し | [codex-task.md](../../references/linear/codex-task.md) |
+| QAの実施・記録・素材 | [references/qa.md](../../references/linear/qa.md) |
+| Cycle完了QA・報告 | [references/cycle-report.md](../../references/linear/cycle-report.md) |
+
+コミットは `shinaps:commit`（Claudeの入口ではClaudeへ依頼し、Codexの入口では会話側がQA後に実装タスクへ依頼する）、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには設定で許可された操作を継続的な許可として渡し、許可済みの操作を再確認しない。

package/plugins/shinaps-codex/skills/linear-plan/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: linear-plan
+description: アイデアの相談・調査・仕様整理を行い、LinearのIssueを作成・更新・分割する。必要に応じてspecやexploreを使い、Issue整理までで止める。プロジェクトのLinear設定の初期設定・変更も扱う。
+---
+
+# 相談を実行可能なIssueへまとめる
+
+相談の目的を確認し、既存の会話・仕様・Issue・コードから分かる内容は再質問しない。仕様が曖昧なら `shinaps:spec`、既存挙動や影響の調査なら `shinaps:explore` を使う。明確な小さな作業は直接整理し、毎回これらのスキルを必須にしない。委託やworktreeの作成は既存の許可に従う。
+
+## 整理と保存
+
+- [設定](../../references/linear/configuration.md)で作業先・Linearの対象・許可を確認する。設定がなくても相談・読み取り・整理案の提示と、利用者が明示的に依頼したIssue更新はできる。別プロジェクトの設定を借用しない。
+- [Issueの整理と記録](../../references/linear/issue.md)に従い既存Issueを検索して再利用する。目的・範囲・受入条件・依存・未決事項を整理し、必要ならレビューできる到達点で分割する。要件の正本やspec/exploreの成果物へ参照を付ける。
+- spec/exploreから実装へ進む案内があっても、この入口では実装を始めない。調査中の確認や読み取りを、製品コードの変更に広げない。
+- Issueの作成・更新は、利用者の明示依頼または設定の `issue_update` が許可する範囲で行う。Claudeは利用者の明示依頼の範囲だけで更新する。チーム設定変更は別の合意が必要。
+- 計画対象の調査自体をIssueで管理する規約がある場合も、同じ目的の既存Issueを使い、細かな手順ごとのIssueは増やさない。相談の結果、Issueを作らず保留・見送りにしてもよい。
+
+## 設定の初期作成・変更
+
+[configuration.md](../../references/linear/configuration.md)の手順で合意済みの内容を保存する。運用項目を暗黙に補完しない。設定変更は実装開始を意味せず、実行範囲の既定値をYAMLに追加しない。
+
+## 終了と引き渡し
+
+作成・更新したIssue、決定事項、未決事項と依存を示して終了する。相談だけなら結論を返す。開発用ゴールの設定、実装、コミット・公開には進まない。利用者が続けて実行を明示的に依頼したときだけ `shinaps:linear-execute` へIssueと成果物を渡し、実行範囲を確定する。

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

@@ -1,48 +0,0 @@
----
-name: linear
-description: LinearのIssue・Cycleを起点に、作業先の規約か依頼が求める着手前のIssueへの紐づけ、Issue整理、開発の進行とAgent QA、設定の implementation_skill に従ったAI Terminal Bridge経由のClaudeへの実装依頼またはCodex自身のdevの入口による実装、設定に従った人のレビューの確認または省略の記録、許可されたコミットの依頼または実施と確認、設定した終了地点までの進行とCycle完了報告を行う。.shinaps/linear.yamlの初期設定・変更にも使う。
----
-
-# Linearを起点に開発を進める
-
-Issueの責務・受入条件・ステータスを、実際の成果と一致させる。初版は利用者本人の環境向けで、Codexが進行・Agent QA・人への窓口を担当する。実装担当は作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口ではClaudeがAI Terminal Bridge（以下Bridge）経由の依頼で実装し、Codexの入口（`dev-codex`・`dev-codex-ultra`）ではCodexが `$shinaps:<入口>` で実装・QA指摘の修正を行う（[references/workflow.md](references/workflow.md) の「担当と窓口」）。設定と異なる担当への入れ替えは扱わない。
-
-## 再確認せず進める条件
-
-Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridgeで受けたClaudeは、人へ着手を再確認せず、指定されたスキルで実行する。質問・相談・障害・完了はCodexへ返す。
-
-人のレビュー・コミット完了の報告をBridgeで受けたCodexは、報告の対象とGitの状態を照合し、一致すれば既存の許可の範囲で人へ再確認せず次の工程へ進む。
-
-条件の一覧と照合の項目は `references/workflow.md` にある。
-
-## 依頼の種類と必要な条件
-
-| 依頼 | 必要な条件 | 止まる地点 |
-| --- | --- | --- |
-| Issueを読む・整理案を示す | なし | 整理案の提示 |
-| Issueを更新する | 設定の `issue_update`、またはその場の明示依頼 | 依頼された範囲 |
-| 初期設定・設定変更 | 利用者との合意 | 合意した設定の保存。チーム設定の変更は別に確認する |
-| Issue単位の開発進行 | 作業先リポジトリの設定（`issue_update` を含む。Claudeの入口では `bridge_request` とBridgeも必要） | 設定の `stop_after` |
-| Cycle単位の継続 | 上記に加えて、Cycle全体を任す明示依頼 | 対象Issueがすべて終了地点に達するか、進められる作業がなくなる |
-| Cycle完了報告 | 設定の `cycle_report` と、報告の明示依頼またはCycle全体の委任 | [references/cycle-report.md](references/cycle-report.md) の完了条件 |
-
-開発進行を始めるときは、指定された対象（IssueまたはCycle）の完了までを一つのゴールとして設定し、通常の人の対応待ちで一時停止・完了にしない（[references/workflow.md](references/workflow.md) の「開発進行のゴール」「待ち状態」）。読み取り・整理だけの呼び出しではゴールを設定しない。スキルの実行だけでは、予約実行・定期監視を開始しない。
-
-## 設定と補足を読む
-
-- 設定の所在・読み方・補足との関係・不足時の止め方は、[references/configuration.md](references/configuration.md) の「設定の読み方」に従う。
-- 作業先リポジトリは、Issue本文の「対象・範囲外」で特定する。Issueがまだない作業では、依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、`list_sessions` の `project_path`、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。
-- 操作の許可は作業先リポジトリの設定で決める。同じLinear projectに属するだけでは、別のリポジトリの作業を現在の設定に含めない。作業先を特定できないIssueや、作業先に設定がないIssueでは、開発進行を始めない。
-- 設定がない場合は、Issueの読み取り、整理案、明示依頼された更新だけを行い、初期設定を案内する。
-
-## 作業ごとに読む資料
-
-| 作業 | 読む資料 |
-| --- | --- |
-| 初期設定・設定変更 | [references/configuration.md](references/configuration.md) |
-| 着手前の紐づけ、Issueの作成・整理・本文の更新 | [references/issue.md](references/issue.md) |
-| 担当、工程、待ち状態、Bridge、人への依頼、継続の範囲 | [references/workflow.md](references/workflow.md) |
-| QAの実施・記録・素材 | [references/qa.md](references/qa.md) |
-| Cycle完了QA・報告 | [references/cycle-report.md](references/cycle-report.md) |
-
-コミットは `shinaps:commit`（Claudeの入口ではClaudeへ依頼し、Codexの入口ではCodexが行う）、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには設定で許可された操作を継続的な許可として渡し、許可済みの操作を再確認しない。