npm - @shinaps/skills - Versions diffs - 0.26.0 → 0.27.0 - Mend

@shinaps/skills 0.26.0 → 0.27.0

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

Files changed (28) hide show

package/README.md CHANGED Viewed

@@ -6,7 +6,7 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 共通スキルが持つのは判断手順。対象環境・必須検証・公開条件は、対象プロジェクトの `AGENTS.md` / `CLAUDE.md` と参照先、README、CI、既存スクリプトから読み取る。専用設定ファイルは必須にしない。
-例外として `linear-execute` の開発進行とチーム設定の変更には、対象リポジトリの `.shinaps/linear.yaml` を必須にする。操作の継続的な許可と終了地点を会話から推測せず、合意した範囲だけを続けて進めるためである。設定はGit対象外の個人用ローカルファイルで、`.shinaps/.gitignore` の除外に含まれる。設定がなくてもIssueの読み取り・整理はできる。
+例外として `linear-execute` の開発進行とチーム設定の変更には、対象リポジトリの `.shinaps/linear.yaml` を必須にする。操作の継続的な許可と終了地点を会話から推測せず、合意した範囲だけを続けて進めるためである。設定はGit対象外の個人用ローカルファイルで、`.shinaps/.gitignore` の除外に含まれる。設定がなくてもIssueの読み取り・整理はできる。設定が必要な実行でファイルがない場合は、同じセッションで `linear-plan` の初期設定ヒアリングへ進み、合意した設定の保存・確認後に元の依頼を再開する。
 例えばPCブラウザのみのプロジェクトには対応ブラウザと確認コマンドを書く。iOSプロジェクトにはSimulatorと実機の使い分けを記す。スキルは一律の端末数やOS数を追加しない。既存の情報で決まらず結果を左右する条件だけ確認し、保存を了承された方針をプロジェクト側に残す。
@@ -29,7 +29,7 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 | `linear-plan` | 相談・必要なspec/explore・Issue作成と整理・プロジェクト設定を行い、実装前で止める |
 | `linear-execute` | Issue単体・Cycle全体・バックログ消化を選び、設定に従って実装・QA・許可された公開を進める |
-コミット・PR・リリースは依頼された場合だけ進む。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
+コミット・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` は初版では利用者本人の環境向けで、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版へ同じ内容を複製し、テストで一致を確認する。

package/package.json CHANGED Viewed

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

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

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

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

@@ -200,7 +200,9 @@ dev の入口（Claude 版 `dev-claude`・`dev-claude-ultra`、Codex 版 `dev-co
 実施したレビュー回数、設計担当1 の判断と修正内容、検証結果、未解決事項を報告する。2回目の後に修正した場合は、その最終差分が再レビューされていないことを明記する。必須検証の失敗や重大な未解決事項があれば作業終了と品質上の完了を区別し、完了済みとは報告しない。
-コミットが明示されていれば、その許可範囲と通常／自律モードを `commit` へ引き継ぐ。コミット依頼がなければ未コミットのまま完了し、毎回コミット許可を要求しない。PRやリリースは明示された場合だけ、それぞれ `create-pr`・`release` へ進む。
+Linearの開発進行から受けた実装・修正では、未コミットの差分と結果を進行役へ返す。dev完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)の継続許可と[担当と工程](../linear/workflow.md)に従い、QA後のコミット依頼を受ける。
+単独のdev依頼では、コミットが許可されていれば、その範囲と通常／自律モードを `commit` へ引き継ぐ。許可がなければ未コミットで結果を返し、毎回コミット許可を要求しない。PR・リリースも許可された範囲で `create-pr`・`release` へ渡す。単独利用にLinear進行や新しいゴールを必須にしない。
 ## 5. 成果物

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

@@ -5,7 +5,7 @@
 ## 作成と再利用
 - 利用者の明示的な依頼または合意済みの `permissions: [codex_task, ...]` の範囲を確認する。ツールが利用者からの明示依頼を要求する場合はその条件も満たす必要があり、設定だけで迂回しない。必要な許可やツールがなければ開始前に止め、会話側での実装やCLIへの置き換えをしない。
-- 既存の同じIssueの実装タスクがあれば状態を読み直して再利用する。なければ `list_projects` で作業先を特定し、`create_thread` で新しいローカルCodexタスクを一つ作る。会話全体をforkせず、実装に必要な情報だけを渡す。新しいworktreeは作らず、明示的に別途許可された場合だけ使う。ツールが対象checkoutを選べない場合は別のcheckoutで代用せず、必要な準備を案内する。
+- 既存の同じIssueの実装タスクがあれば状態を読み直して再利用する。なければ `list_projects` で所属先を確認し、`create_thread` で新しいローカルCodexタスクを一つ作る。所属プロジェクトと実際の作業ディレクトリは一致を必須にしない。作業先が登録一覧にない場合も、利用者が指定した所属先を使い、対象checkoutの絶対パスを依頼に明記できる。実装担当は変更前に、指定先のGitルート・ブランチ・差分と適用される規約を確認し、以後の操作をその作業先で行う。指定先にアクセスできない場合は、別checkoutで代用せず必要な準備を報告する。会話全体をforkせず、実装に必要な情報だけを渡す。新しいworktreeは作らず、明示的に別途許可された場合だけ使う。
 - 返された確定済みthreadId・hostIdとIssue・checkout・branchをローカルの作業記録で対応づける。準備中のclientThreadIdを送信先にしない。作成結果が不明なときは一覧と状態を確認してから再試行する。
 - 同じIssueの質問回答・修正・許可されたコミット依頼は `send_message_to_thread` で同じタスクへ送る。モデルを利用者の指定なしに変更しない。dev内のモデル・役割構成は指定した入口に従う。
@@ -19,7 +19,7 @@ Issueリンク・範囲・受入条件・仕様や調査成果物、指定devス
 ## 待機・QA・修正
-会話側は `wait_threads` / `read_thread` で完了・質問・失敗を読み取り、実装結果を確認する。送信成功やタスクの終了だけで実装・QAの合格と扱わない。完了報告には変更範囲、検証結果、dev内レビュー結果、起動方法、未解決事項を含める。コミット依頼後はSHAも照合する。
+会話側は同じタスクを `wait_threads` / `read_thread` で観測し、完了・質問・失敗と実装結果を確認する。待機中のゴールと観測結果が得られない場合の扱いは [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。送信成功やタスクの終了だけで実装・QAの合格と扱わない。完了報告には変更範囲、検証結果、dev内レビュー結果、起動方法、未解決事項を含める。コミット依頼後はSHAも照合する。
 実装中は会話側で同じファイルを編集しない。Agent QAの開始前に実装タスクの編集が止まったことを確認し、差分と対象版を固定してQAする。不具合は再現手順・期待と実際・証拠とともに同じタスクへ返し、修正終了後に再検証する。実装担当が返したテスト結果を独立したAgent QAの代わりにしない。

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

@@ -24,7 +24,9 @@
 - 補足ファイルは追加の条件と手順を表す。設定の決定（対象・許可・終了地点・工程の対応）と、人の完了・QAの証拠の要件は変えない。補足と設定が矛盾したら、設定に従って止め、どちらを直すか確認する。
 - 不足や矛盾があれば、影響する工程の開始前に止めて一問ずつ確認する。影響しない工程は続ける。許可の追加やステータスの新設を推測で補わない。
 - 終了地点は操作の許可を兼ねない。設定は、利用中のツールの権限や利用者の明示的な停止・撤回を上書きしない。
-- 利用者と合意して保存した設定の許可は、その対象・操作・条件の範囲で、作業先リポジトリの規約がいう合意・許可に当たる。設定ファイルが存在することや、AIが合意なしに加えた許可は、その根拠にしない。
+- 利用者と合意して保存した設定の許可は、その対象・操作・条件の範囲で、作業先リポジトリの規約がいう合意・許可に当たる。一般的な「明示依頼がある場合だけ」という条件も、この合意済みの範囲では満たすため、同じ操作の許可を改めて求めない。設定ファイルが存在することや、AIが合意なしに加えた許可は、その根拠にしない。利用者による今回の範囲限定・停止・撤回と、ツール固有の明示依頼条件は維持する。
+次工程を判断するときは、独立した `commit_mode`・`permissions`・`stop_after`・人レビューの条件を併せて読み、[担当と工程](workflow.md)で定めた担当と前工程の結果を確認する。一つの設定から他の許可や工程の完了を推測しない。終了・待機とゴール状態は [execution.md](execution.md) に従う。
 ## 項目
@@ -156,7 +158,9 @@ references:
 ## 初期設定
-`linear-plan` を実行しているセッションが行う。Claudeも利用者から明示的に依頼された設定を作成・変更できる。開発の進行役を変更するものではない。
+依頼の実行に設定が必要で、「設定の読み方」で定めた保存先に設定がなければ、同じセッションで `linear-plan` の以下の手順を開始する。別PCではローカル設定が引き継がれないため、初期設定の案内やスキルの再実行依頼だけで止めない。設定なしでできる相談・読み取り・明示依頼されたIssue整理には、初期設定を必須にしない。
+Claudeもこの手順で初期設定を行える。合意した設定の保存・確認後は元の依頼へ戻る。設定作成は元の依頼の実行範囲や担当、操作許可を増やさず、開発の進行役も変更しない。
 1. アカウント、workspace、team、projectと、チームのステータス一覧・既存の運用をLinearから読む。
 2. 作業先リポジトリのAGENTS.md・CLAUDE.md・README・CI・検証や配備のスクリプトを読み、`references` の候補を決める。

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

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

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

@@ -8,7 +8,7 @@
 | 実装担当 | 技術調査、`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実装タスクが行い、[Codex実装タスク](codex-task.md)の手順で依頼・結果を扱う。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は使わない。どちらでも実装担当はdev内レビューと検証を終えて進行役へ結果を返し、進行役がLocal Agent QAを行う。実装担当の報告をQA合格の根拠にせず、この引き渡しを進行全体の終了と扱わない。
 人への質問と依頼は会話側のCodexが窓口になる。実装担当は人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
@@ -81,7 +81,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 待つときは、必要な対応・担当・再開条件・戻る工程をIssueのコメントへ記録する。人の回答や対応完了を確認したら続け、同じ依頼を繰り返さない。
-Linearの工程のステータスと、Codexのゴールの状態は別に扱う。人のレビュー・コミット、Human QA、その場の回答を待つ間、Linearは進行中の工程を維持し、Codexはゴールを作業中のまま利用可能な待機手段で待つ。人の応答待ちという理由だけで、自発的にゴールをblocked・一時停止・完了へ切り替えない。人からの通知を受けたら、対象を照合してから再開する。実行環境の上位の指示やゴール機能の制約はこのスキルで上書きできないため、環境が許す範囲で作業中を維持し、環境が状態の変更を要求する場合はその理由を利用者に説明する。制約を迂回する操作や、代わりの新しいゴールの作成はしない。
+Linearの工程のステータスと、Codexのゴールの状態は別に扱う。会話側のゴールの維持・終了・状態変更は [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。通知を受けたら対象と結果を照合し、次工程の許可と前提が揃っていれば再確認せずに続ける。
 ## Bridgeでの依頼と報告

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

@@ -19,14 +19,16 @@ description: 許可された差分を依存順のローカルコミットにし
 ## 範囲と進め方
-コミットは、ユーザーが明示した場合と、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以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
+コミットは利用者の明示依頼、または[Linear共通設定](../../references/linear/configuration.md)の合意済みの許可に従う。Linear進行では[担当と工程](../../references/linear/workflow.md)の `code_review` に従い、Local Agent QA後に進行役から対象を指定した依頼を受けて行う。単独の依頼にはLinear進行や新しいゴールを必須にしない。
+開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linear-executeの開発進行では設定の不足・不正値を解消してから進む。linear-execute以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
 - **通常（推奨）**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
 - **自律**: エージェントが検証できる単位を選び（許可された一連の変更をまとめてよい）、検証・レビューして個別の承認を求めずコミットする。
 質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。過去の別対象での自律選択は引き継がない。例外は `commit_mode` として明示的に保存されたプロジェクト設定だけで、同じプロジェクトでの依頼の選択として使う。その場の明示的な指定は設定に優先する。
-`commit_mode` は進め方の設定であり、コミットの許可ではない。人のコードレビューの要否（`human_code_review`）や、ステージ・コミット・push・PR・公開の許可とは独立しており、どちらのモードもそれらを変えない。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
+設定項目の独立性と併せて読む条件は[Linear共通設定](../../references/linear/configuration.md)に従う。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
 どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。

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

@@ -1,6 +1,6 @@
 ---
 name: create-pr
-description: ブランチの変更意図と検証結果を整理し、リポジトリの規約に合ったGitHub PRを作成する。PR作成・公開を依頼されたときに使う。
+description: ブランチの変更意図と検証結果を整理し、リポジトリの規約に合ったGitHub PRを作成する。PR作成・公開の依頼または合意済みの継続許可があるときに使う。
 ---
 ## 作業記録の保存先
@@ -17,6 +17,8 @@ description: ブランチの変更意図と検証結果を整理し、リポジ
 既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
+Linearの開発進行から受けた依頼では、[共通設定](../../references/linear/configuration.md)の合意済みの許可と[担当・工程](../../references/linear/workflow.md)を引き継ぐ。操作後は進行役へ結果を返し、[終了条件](../../references/linear/execution.md)に従って次工程を判断する。単独の依頼にはLinear進行や新しいゴールを必須にしない。
 ## 差分と宛先
 プロジェクトルート、Git状態、remote、対象アカウント、base・headを確認する。ユーザーの指定を優先し、base未指定ならGitHubのdefault branchを取得する。比較には取得したリモートのbase refを使い、古いローカルブランチだけで判断しない。

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

@@ -1,6 +1,6 @@
 ---
 name: dev-claude
-description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化をそれぞれ1体で確認する。実装依頼で1体での実行を指定されたときに使う。コミットは別途明示された場合だけ行う。
+description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化をそれぞれ1体で確認する。実装依頼で1体での実行を指定されたときに使う。コミットは許可と工程の条件に従い、Linear進行ではQAへ結果を返す。
 argument-hint: <実装したい機能・解決したい課題>
 ---

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

@@ -1,6 +1,6 @@
 ---
 name: dev-claude-ultra
-description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化を同じ役割の2体で独立に確認する。機能追加や修正の実装依頼の既定。コミットは別途明示された場合だけ行う。
+description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化を同じ役割の2体で独立に確認する。機能追加や修正の実装依頼の既定。コミットは許可と工程の条件に従い、Linear進行ではQAへ結果を返す。
 argument-hint: <実装したい機能・解決したい課題>
 ---

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

@@ -30,12 +30,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 - devの入口が利用者に確認する場面（計画の判断、不明点、承認）では、人ではなくCodexへ相談する。Codexが既存の合意で答えた内容を人へ再確認しない。仕様・受入条件・許可範囲の変更が必要な場合は、Codexが人に確認する。
 - QAで見つかった不具合の修正依頼も同じ扱いにし、人の着手許可を改めて取らない。
 - 同じ作業ツリーをCodexや人と同時に編集しない。人や他のAIの変更を保持する。
-- Claudeは次のいずれかの場合だけコミットする。
-  - 利用者本人がその場で明示的に依頼した場合。
-  - 作業先リポジトリの設定の `permissions` に `commit` と `stage` があり、CodexがLocal Agent QAの合格後にコミットを依頼した場合。
-  - 設定に `document_only_changes: ai_commit` と `stage` があり、CodexがLocal Agent QAの合格後に文書だけの変更としてコミットを依頼した場合。
-  後の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/linear/configuration.md)、担当とQA後の条件は[担当と工程](../../references/linear/workflow.md)の `code_review` に従う。実装完了の直後に先行してコミットせず、進行役へ結果を返す。条件を満たす依頼を受けたら `shinaps:commit` を使い、許可済みの操作を再確認しない。確認と承認の取り次ぎは同じ文書の「Bridgeでの依頼と報告」に従う。
 ## 結果と人の対応を報告する
@@ -48,4 +43,4 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 - 利用者から直接依頼された実作業（開発進行の依頼を除く）は、着手前に [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の導入）を利用者へ案内する。
+- 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、Claudeは進行役を兼ねない。作業先の設定がない場合は、同じセッションで `shinaps:linear-plan` の初期設定ヒアリングに進み、保存・確認後に元の依頼の引き渡しへ戻る。作業先リポジトリの設定で `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 CHANGED Viewed

@@ -17,8 +17,8 @@ description: アイデアの相談・調査・仕様整理を行い、LinearのI
 ## 設定の初期作成・変更
-[configuration.md](../../references/linear/configuration.md)の手順で合意済みの内容を保存する。運用項目を暗黙に補完しない。設定変更は実装開始を意味せず、実行範囲の既定値をYAMLに追加しない。
+依頼の実行に設定が必要で、作業先の設定がない場合は、その場で [configuration.md](../../references/linear/configuration.md) の初期設定手順に進む。未決事項を一問ずつ確認し、合意済みの内容を保存する。運用項目を暗黙に補完しない。設定変更は実装開始を意味せず、実行範囲の既定値をYAMLに追加しない。
 ## 終了と引き渡し
-作成・更新したIssue、決定事項、未決事項と依存を示して終了する。相談だけなら結論を返す。開発用ゴールの設定、実装、コミット・公開には進まない。利用者が続けて実行を明示的に依頼したときだけ `shinaps:linear-execute` へIssueと成果物を渡し、実行範囲を確定する。
+作成・更新したIssue、決定事項、未決事項と依存を示して終了する。相談だけなら結論を返す。開発用ゴールの設定、実装、コミット・公開には進まない。設定のために `linear-execute` から移った場合は、保存・確認後に元の依頼へ戻り、設定と既存の許可の範囲で再開する。それ以外では、利用者が続けて実行を明示的に依頼したときだけ `shinaps:linear-execute` へIssueと成果物を渡し、実行範囲を確定する。

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

@@ -1,6 +1,6 @@
 ---
 name: release
-description: プロジェクトの公開手順と完了条件に従ってリリースし、対象バージョンが利用可能なことを検証する。公開・配布・本番デプロイを依頼されたときに使う。
+description: プロジェクトの公開手順と完了条件に従ってリリースし、対象バージョンが利用可能なことを検証する。公開・配布・本番デプロイの依頼または合意済みの継続許可があるときに使う。
 ---
 ## 作業記録の保存先
@@ -17,6 +17,8 @@ description: プロジェクトの公開手順と完了条件に従ってリリ
 既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
+Linearの開発進行から受けた依頼では、[共通設定](../../references/linear/configuration.md)の合意済みの許可と[担当・工程](../../references/linear/workflow.md)を引き継ぐ。操作後は進行役へ結果を返し、[終了条件](../../references/linear/execution.md)に従って次工程を判断する。単独の依頼にはLinear進行や新しいゴールを必須にしない。
 ## 公開前に条件を確定する
 対象環境・配布先・ソースrevision・成果物のバージョンと、成功を判断する操作・証拠を確定する。リポジトリのリリース手順を使い、既存CIや証拠形式があれば再利用する。専用のJSON形式や新しい検証基盤を導入すること自体を必須にしない。

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

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

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

@@ -200,7 +200,9 @@ dev の入口（Claude 版 `dev-claude`・`dev-claude-ultra`、Codex 版 `dev-co
 実施したレビュー回数、設計担当1 の判断と修正内容、検証結果、未解決事項を報告する。2回目の後に修正した場合は、その最終差分が再レビューされていないことを明記する。必須検証の失敗や重大な未解決事項があれば作業終了と品質上の完了を区別し、完了済みとは報告しない。
-コミットが明示されていれば、その許可範囲と通常／自律モードを `commit` へ引き継ぐ。コミット依頼がなければ未コミットのまま完了し、毎回コミット許可を要求しない。PRやリリースは明示された場合だけ、それぞれ `create-pr`・`release` へ進む。
+Linearの開発進行から受けた実装・修正では、未コミットの差分と結果を進行役へ返す。dev完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)の継続許可と[担当と工程](../linear/workflow.md)に従い、QA後のコミット依頼を受ける。
+単独のdev依頼では、コミットが許可されていれば、その範囲と通常／自律モードを `commit` へ引き継ぐ。許可がなければ未コミットで結果を返し、毎回コミット許可を要求しない。PR・リリースも許可された範囲で `create-pr`・`release` へ渡す。単独利用にLinear進行や新しいゴールを必須にしない。
 ## 5. 成果物

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

@@ -5,7 +5,7 @@
 ## 作成と再利用
 - 利用者の明示的な依頼または合意済みの `permissions: [codex_task, ...]` の範囲を確認する。ツールが利用者からの明示依頼を要求する場合はその条件も満たす必要があり、設定だけで迂回しない。必要な許可やツールがなければ開始前に止め、会話側での実装やCLIへの置き換えをしない。
-- 既存の同じIssueの実装タスクがあれば状態を読み直して再利用する。なければ `list_projects` で作業先を特定し、`create_thread` で新しいローカルCodexタスクを一つ作る。会話全体をforkせず、実装に必要な情報だけを渡す。新しいworktreeは作らず、明示的に別途許可された場合だけ使う。ツールが対象checkoutを選べない場合は別のcheckoutで代用せず、必要な準備を案内する。
+- 既存の同じIssueの実装タスクがあれば状態を読み直して再利用する。なければ `list_projects` で所属先を確認し、`create_thread` で新しいローカルCodexタスクを一つ作る。所属プロジェクトと実際の作業ディレクトリは一致を必須にしない。作業先が登録一覧にない場合も、利用者が指定した所属先を使い、対象checkoutの絶対パスを依頼に明記できる。実装担当は変更前に、指定先のGitルート・ブランチ・差分と適用される規約を確認し、以後の操作をその作業先で行う。指定先にアクセスできない場合は、別checkoutで代用せず必要な準備を報告する。会話全体をforkせず、実装に必要な情報だけを渡す。新しいworktreeは作らず、明示的に別途許可された場合だけ使う。
 - 返された確定済みthreadId・hostIdとIssue・checkout・branchをローカルの作業記録で対応づける。準備中のclientThreadIdを送信先にしない。作成結果が不明なときは一覧と状態を確認してから再試行する。
 - 同じIssueの質問回答・修正・許可されたコミット依頼は `send_message_to_thread` で同じタスクへ送る。モデルを利用者の指定なしに変更しない。dev内のモデル・役割構成は指定した入口に従う。
@@ -19,7 +19,7 @@ Issueリンク・範囲・受入条件・仕様や調査成果物、指定devス
 ## 待機・QA・修正
-会話側は `wait_threads` / `read_thread` で完了・質問・失敗を読み取り、実装結果を確認する。送信成功やタスクの終了だけで実装・QAの合格と扱わない。完了報告には変更範囲、検証結果、dev内レビュー結果、起動方法、未解決事項を含める。コミット依頼後はSHAも照合する。
+会話側は同じタスクを `wait_threads` / `read_thread` で観測し、完了・質問・失敗と実装結果を確認する。待機中のゴールと観測結果が得られない場合の扱いは [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。送信成功やタスクの終了だけで実装・QAの合格と扱わない。完了報告には変更範囲、検証結果、dev内レビュー結果、起動方法、未解決事項を含める。コミット依頼後はSHAも照合する。
 実装中は会話側で同じファイルを編集しない。Agent QAの開始前に実装タスクの編集が止まったことを確認し、差分と対象版を固定してQAする。不具合は再現手順・期待と実際・証拠とともに同じタスクへ返し、修正終了後に再検証する。実装担当が返したテスト結果を独立したAgent QAの代わりにしない。

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

@@ -24,7 +24,9 @@
 - 補足ファイルは追加の条件と手順を表す。設定の決定（対象・許可・終了地点・工程の対応）と、人の完了・QAの証拠の要件は変えない。補足と設定が矛盾したら、設定に従って止め、どちらを直すか確認する。
 - 不足や矛盾があれば、影響する工程の開始前に止めて一問ずつ確認する。影響しない工程は続ける。許可の追加やステータスの新設を推測で補わない。
 - 終了地点は操作の許可を兼ねない。設定は、利用中のツールの権限や利用者の明示的な停止・撤回を上書きしない。
-- 利用者と合意して保存した設定の許可は、その対象・操作・条件の範囲で、作業先リポジトリの規約がいう合意・許可に当たる。設定ファイルが存在することや、AIが合意なしに加えた許可は、その根拠にしない。
+- 利用者と合意して保存した設定の許可は、その対象・操作・条件の範囲で、作業先リポジトリの規約がいう合意・許可に当たる。一般的な「明示依頼がある場合だけ」という条件も、この合意済みの範囲では満たすため、同じ操作の許可を改めて求めない。設定ファイルが存在することや、AIが合意なしに加えた許可は、その根拠にしない。利用者による今回の範囲限定・停止・撤回と、ツール固有の明示依頼条件は維持する。
+次工程を判断するときは、独立した `commit_mode`・`permissions`・`stop_after`・人レビューの条件を併せて読み、[担当と工程](workflow.md)で定めた担当と前工程の結果を確認する。一つの設定から他の許可や工程の完了を推測しない。終了・待機とゴール状態は [execution.md](execution.md) に従う。
 ## 項目
@@ -156,7 +158,9 @@ references:
 ## 初期設定
-`linear-plan` を実行しているセッションが行う。Claudeも利用者から明示的に依頼された設定を作成・変更できる。開発の進行役を変更するものではない。
+依頼の実行に設定が必要で、「設定の読み方」で定めた保存先に設定がなければ、同じセッションで `linear-plan` の以下の手順を開始する。別PCではローカル設定が引き継がれないため、初期設定の案内やスキルの再実行依頼だけで止めない。設定なしでできる相談・読み取り・明示依頼されたIssue整理には、初期設定を必須にしない。
+Claudeもこの手順で初期設定を行える。合意した設定の保存・確認後は元の依頼へ戻る。設定作成は元の依頼の実行範囲や担当、操作許可を増やさず、開発の進行役も変更しない。
 1. アカウント、workspace、team、projectと、チームのステータス一覧・既存の運用をLinearから読む。
 2. 作業先リポジトリのAGENTS.md・CLAUDE.md・README・CI・検証や配備のスクリプトを読み、`references` の候補を決める。

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

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

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

@@ -8,7 +8,7 @@
 | 実装担当 | 技術調査、`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実装タスクが行い、[Codex実装タスク](codex-task.md)の手順で依頼・結果を扱う。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は使わない。どちらでも実装担当はdev内レビューと検証を終えて進行役へ結果を返し、進行役がLocal Agent QAを行う。実装担当の報告をQA合格の根拠にせず、この引き渡しを進行全体の終了と扱わない。
 人への質問と依頼は会話側のCodexが窓口になる。実装担当は人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
@@ -81,7 +81,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 待つときは、必要な対応・担当・再開条件・戻る工程をIssueのコメントへ記録する。人の回答や対応完了を確認したら続け、同じ依頼を繰り返さない。
-Linearの工程のステータスと、Codexのゴールの状態は別に扱う。人のレビュー・コミット、Human QA、その場の回答を待つ間、Linearは進行中の工程を維持し、Codexはゴールを作業中のまま利用可能な待機手段で待つ。人の応答待ちという理由だけで、自発的にゴールをblocked・一時停止・完了へ切り替えない。人からの通知を受けたら、対象を照合してから再開する。実行環境の上位の指示やゴール機能の制約はこのスキルで上書きできないため、環境が許す範囲で作業中を維持し、環境が状態の変更を要求する場合はその理由を利用者に説明する。制約を迂回する操作や、代わりの新しいゴールの作成はしない。
+Linearの工程のステータスと、Codexのゴールの状態は別に扱う。会話側のゴールの維持・終了・状態変更は [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。通知を受けたら対象と結果を照合し、次工程の許可と前提が揃っていれば再確認せずに続ける。
 ## Bridgeでの依頼と報告

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

@@ -19,14 +19,16 @@ description: 許可された差分を依存順のローカルコミットにし
 ## 範囲と進め方
-コミットは、ユーザーが明示した場合と、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以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
+コミットは利用者の明示依頼、または[Linear共通設定](../../references/linear/configuration.md)の合意済みの許可に従う。Linear進行では[担当と工程](../../references/linear/workflow.md)の `code_review` に従い、Local Agent QA後に進行役から対象を指定した依頼を受けて行う。単独の依頼にはLinear進行や新しいゴールを必須にしない。
+開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linear-executeの開発進行では設定の不足・不正値を解消してから進む。linear-execute以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
 - **通常（推奨）**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
 - **自律**: エージェントが検証できる単位を選び（許可された一連の変更をまとめてよい）、検証・レビューして個別の承認を求めずコミットする。
 質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。過去の別対象での自律選択は引き継がない。例外は `commit_mode` として明示的に保存されたプロジェクト設定だけで、同じプロジェクトでの依頼の選択として使う。その場の明示的な指定は設定に優先する。
-`commit_mode` は進め方の設定であり、コミットの許可ではない。人のコードレビューの要否（`human_code_review`）や、ステージ・コミット・push・PR・公開の許可とは独立しており、どちらのモードもそれらを変えない。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
+設定項目の独立性と併せて読む条件は[Linear共通設定](../../references/linear/configuration.md)に従う。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
 どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。

package/plugins/shinaps-codex/skills/create-pr/SKILL.md CHANGED Viewed

@@ -1,6 +1,6 @@
 ---
 name: create-pr
-description: ブランチの変更意図と検証結果を整理し、リポジトリの規約に合ったGitHub PRを作成する。PR作成・公開を依頼されたときに使う。
+description: ブランチの変更意図と検証結果を整理し、リポジトリの規約に合ったGitHub PRを作成する。PR作成・公開の依頼または合意済みの継続許可があるときに使う。
 ---
 ## 作業記録の保存先
@@ -17,6 +17,8 @@ description: ブランチの変更意図と検証結果を整理し、リポジ
 既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
+Linearの開発進行から受けた依頼では、[共通設定](../../references/linear/configuration.md)の合意済みの許可と[担当・工程](../../references/linear/workflow.md)を引き継ぐ。操作後は進行役へ結果を返し、[終了条件](../../references/linear/execution.md)に従って次工程を判断する。単独の依頼にはLinear進行や新しいゴールを必須にしない。
 ## 差分と宛先
 プロジェクトルート、Git状態、remote、対象アカウント、base・headを確認する。ユーザーの指定を優先し、base未指定ならGitHubのdefault branchを取得する。比較には取得したリモートのbase refを使い、古いローカルブランチだけで判断しない。

package/plugins/shinaps-codex/skills/dev-codex/SKILL.md CHANGED Viewed

@@ -1,6 +1,6 @@
 ---
 name: dev-codex
-description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化をそれぞれ1体で確認する。実装依頼で1体での実行を指定されたときに使う。コミットは別途明示された場合だけ行う。
+description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化をそれぞれ1体で確認する。実装依頼で1体での実行を指定されたときに使う。コミットは許可と工程の条件に従い、Linear進行ではQAへ結果を返す。
 ---
 # 開発（同じ役割 1 体）

package/plugins/shinaps-codex/skills/dev-codex-ultra/SKILL.md CHANGED Viewed

@@ -1,6 +1,6 @@
 ---
 name: dev-codex-ultra
-description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化を同じ役割の2体で独立に確認する。機能追加や修正の実装依頼の既定。コミットは別途明示された場合だけ行う。
+description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化を同じ役割の2体で独立に確認する。機能追加や修正の実装依頼の既定。コミットは許可と工程の条件に従い、Linear進行ではQAへ結果を返す。
 ---
 # 開発（同じ役割 2 体）

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

@@ -28,7 +28,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 - 設定の所在・読み方・補足との関係・不足時の止め方は、[references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従う。
 - 作業先リポジトリは、Issue本文の「対象・範囲外」で特定する。Issueがまだない作業では、依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、`list_sessions` の `project_path`、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。
 - 操作の許可は作業先リポジトリの設定で決める。同じLinear projectに属するだけでは、別のリポジトリの作業を現在の設定に含めない。作業先を特定できないIssueや、作業先に設定がないIssueでは、開発進行を始めない。
-- 設定がない場合は、Issueの読み取り、整理案、明示依頼された更新だけを行い、初期設定を案内する。
+- 依頼の実行に設定が必要で、作業先の設定がない場合は、同じセッションで `shinaps:linear-plan` の初期設定ヒアリングに進む。保存・確認後に元の依頼へ戻り、設定と既存の許可の範囲で再開する。設定不要のIssueの読み取り、整理案、明示依頼された更新はそのまま行う。
 ## 作業ごとに読む資料
@@ -41,4 +41,4 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 | 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` に従い、このスキルで手順を持たない。これらのスキルには設定で許可された操作を継続的な許可として渡し、許可済みの操作を再確認しない。
+コミットは `shinaps:commit`（Claudeの入口ではClaudeへ依頼し、Codexの入口では会話側がQA後に実装タスクへ依頼する）、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで継続する。

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

@@ -17,8 +17,8 @@ description: アイデアの相談・調査・仕様整理を行い、LinearのI
 ## 設定の初期作成・変更
-[configuration.md](../../references/linear/configuration.md)の手順で合意済みの内容を保存する。運用項目を暗黙に補完しない。設定変更は実装開始を意味せず、実行範囲の既定値をYAMLに追加しない。
+依頼の実行に設定が必要で、作業先の設定がない場合は、その場で [configuration.md](../../references/linear/configuration.md) の初期設定手順に進む。未決事項を一問ずつ確認し、合意済みの内容を保存する。運用項目を暗黙に補完しない。設定変更は実装開始を意味せず、実行範囲の既定値をYAMLに追加しない。
 ## 終了と引き渡し
-作成・更新したIssue、決定事項、未決事項と依存を示して終了する。相談だけなら結論を返す。開発用ゴールの設定、実装、コミット・公開には進まない。利用者が続けて実行を明示的に依頼したときだけ `shinaps:linear-execute` へIssueと成果物を渡し、実行範囲を確定する。
+作成・更新したIssue、決定事項、未決事項と依存を示して終了する。相談だけなら結論を返す。開発用ゴールの設定、実装、コミット・公開には進まない。設定のために `linear-execute` から移った場合は、保存・確認後に元の依頼へ戻り、設定と既存の許可の範囲で再開する。それ以外では、利用者が続けて実行を明示的に依頼したときだけ `shinaps:linear-execute` へIssueと成果物を渡し、実行範囲を確定する。

package/plugins/shinaps-codex/skills/release/SKILL.md CHANGED Viewed

@@ -1,6 +1,6 @@
 ---
 name: release
-description: プロジェクトの公開手順と完了条件に従ってリリースし、対象バージョンが利用可能なことを検証する。公開・配布・本番デプロイを依頼されたときに使う。
+description: プロジェクトの公開手順と完了条件に従ってリリースし、対象バージョンが利用可能なことを検証する。公開・配布・本番デプロイの依頼または合意済みの継続許可があるときに使う。
 ---
 ## 作業記録の保存先
@@ -17,6 +17,8 @@ description: プロジェクトの公開手順と完了条件に従ってリリ
 既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
+Linearの開発進行から受けた依頼では、[共通設定](../../references/linear/configuration.md)の合意済みの許可と[担当・工程](../../references/linear/workflow.md)を引き継ぐ。操作後は進行役へ結果を返し、[終了条件](../../references/linear/execution.md)に従って次工程を判断する。単独の依頼にはLinear進行や新しいゴールを必須にしない。
 ## 公開前に条件を確定する
 対象環境・配布先・ソースrevision・成果物のバージョンと、成功を判断する操作・証拠を確定する。リポジトリのリリース手順を使い、既存CIや証拠形式があれば再利用する。専用のJSON形式や新しい検証基盤を導入すること自体を必須にしない。