@shinaps/skills 0.50.3 → 0.51.1

package/README.md

@@ -66,6 +66,7 @@ Claude Code では `/shinaps:<スキル名>`（例 `/shinaps:review`）で呼び
 | `dev-claude` の体制と工程 | [実装体制の判断](plugins/shinaps-claude/references/dev/staffing.md)・[dev の工程](plugins/shinaps-claude/references/dev/workflow.md) |
 | レビューの担当の構成と指摘の採否・単独起動の手順 | [レビューの共通契約](plugins/shinaps-claude/references/review.md)・[単独レビューの手順](plugins/shinaps-claude/references/review-standalone.md) |
 | Linear での開発進行（`.shinaps/linear.json` の書き方・終了地点と制約・auto と manual） | [プロジェクト設定](plugins/shinaps-claude/references/linear/configuration.md)・[担当と工程](plugins/shinaps-claude/references/linear/workflow.md) |
+| develop → main の release PR へ開発 Issue の確認を集めて配布する方式（引継ぎの書き方・リリース Issue の進め方） | [リリース QA の引継ぎと進行](plugins/shinaps-claude/references/linear/release-qa.md) |
 | Claude Managed Agents（必要なもの・導入・依頼） | [設定とアカウント](plugins/shinaps-claude/references/managed/configuration.md)・[導入と更新](plugins/shinaps-claude/references/managed/setup.md)・[依頼と観測](plugins/shinaps-claude/references/managed/execute.md) |
 | スキルが使う担当（サブエージェント）の一覧 | [サブエージェント](docs/agents.md) |
 | 作業記録の保存先 | [作業記録](plugins/shinaps-claude/references/work-records.md) |
@@ -73,6 +74,10 @@ Claude Code では `/shinaps:<スキル名>`（例 `/shinaps:review`）で呼び
 
 旧版の設定は自動では変換しません。Linear は [旧設定の移行](plugins/shinaps-claude/references/linear/configuration.md#旧設定の移行)（0.48.0 から `config_version: 3`。操作ごとの許可の一覧を廃止し `constraints` に置き換え）、Managed Agents は [version 1 からの移行](plugins/shinaps-claude/references/managed/configuration.md#version-1-からの移行)に従ってください。
 
+### 0.51.0 の変更
+
+develop → main の release PR ごとに開発 Issue の確認をリリース Issue へ集めて配布する方式の手順を追加しました（[リリース QA の引継ぎと進行](plugins/shinaps-claude/references/linear/release-qa.md)）。作業先の資料がこの方式を定めているときだけ使い、定めていない作業先の進め方は変わりません。設定ファイルの形式は変わりません。
+
 ### 0.50.0 の変更
 
 - 規約の照合は、plugin の hook が保存した応答から作る snapshot を担当と機械検査が読みます。Codex では hook の信頼が要り、plugin の更新のたびに `/hooks` で信頼し直します（[導入と更新](docs/install.md#規約の-hook)）。

package/docs/install.md

@@ -26,7 +26,7 @@ npx @shinaps/skills@latest recover codex
 設定の検証（`validate-linear-config`・`validate-managed-config`）、Managed Agents の操作（`managed`）、規約の機械検査と受け渡し（`lint`・`rule-snapshot`・`rule-coverage`、[規約の機械検査](lint.md)）には、配布 CLI `shinaps-skills` を使います。CLI は plugin に含まれないため、利用中のスキルと同じ版を導入します。
 
 ```sh
-npm install -g @shinaps/skills@0.50.3
+npm install -g @shinaps/skills@0.51.1
 shinaps-skills --version
 ```
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.50.3",
+  "version": "0.51.1",
   "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.50.3",
+  "version": "0.51.1",
   "author": {
     "name": "shinaps"
   },

package/plugins/shinaps-claude/managed-agents/agents/shinaps-dev-managed-cc.md

@@ -52,7 +52,7 @@ multiagent:
 - 初回メッセージにリポジトリ・base・head・範囲と受入条件・体制（LITE・BASIC・ULTRA）・許可・予算のいずれかが欠けていれば作業を始めない。欠落を列挙し、1行目を `状態: 質問` にしてターンを終える。
 - 許可は利用者のメッセージで明示された操作だけとする。この構成の導入、リポジトリの設定ファイル、過去の作業から許可を推定しない。
 - リポジトリ側で人の承認を要する方針（例: `review_flow: manual`、ブランチ保護、必須レビュー）は迂回せず、そこで止めて `状態: 未完了` で返す。
-- push は依頼の head ブランチにだけ行う。force push と base への push はしない。PR は draft で作る。
+- push は依頼の head ブランチにだけ、作業先が push 前に求める検証（pre-push hook など）をこのセッションで通してから行う。push の代わりに、その検証を通らない手段（GitHub MCP の `create_branch`・`push_files` など）を使わない。force push と base への push はしない。PR は draft で作る。
 - merge・deploy・release・Issue の更新・`ant apply`・予定実行の登録はしない。
 - Codex の QA をこのセッションで行ったとは報告しない。Shinaps AI の rule は取得せず、未照合と報告する。
 

package/plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/launch.md

@@ -58,7 +58,7 @@ PR: <draft PR の URL。無ければ なし>
 
 - push に使えるのはマウント時の `github_repository.authorization_token` だけで、GitHub MCP に使えるのはセッション作成時に渡された vault の資格情報だけとする。
 - token をサンドボックスのファイル・環境変数・git の設定に書かない。作業記録と報告にも値を残さない。
-- push や PR 作成が拒否されたら、別の資格情報や経路を試さず、patch を置いて `状態: 未完了` で返す。
+- 作業先が push 前に求める検証を通せない（検証が拒否した、またはこの環境で実行できない）とき、および push や PR 作成が拒否されたときは、`--no-verify`・別の資格情報・別の経路を試さず、patch を置いて `状態: 未完了` で返し、通せなかった検証または拒否の理由を報告する。
 - PR は `create_pull_request` に `draft: true` を付けて作り、`pull_request_read` で draft であることを確かめる。
 
 ## Claude Code 固有の手段の置き換え

package/plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/workflow.md

@@ -53,7 +53,7 @@ lead が確定計画を実装する。
 - 計画で決めた最終構造を実装する。必要な移動・分割を差分削減のために省略せず、全利用側の参照更新・旧経路や重複の解消・既存利用側の回帰確認まで行う。目的・仕様・受入条件の変更が必要と分かったら、該当作業を止めて `状態: 質問` で利用者に確認する。
 - 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
 - 実装後、目的を保ったまま削除・統合できる処理を確かめ、不要な分岐・重複・互換層を減らしてからセルフレビューする。
-- lead の定義のテスト方針に沿って、プロジェクトの規約・CI・変更の影響に応じた必須検証を行う。実装ミスによる検証失敗の自己修正は3回まで。超えたら根拠と未解決点を記録して未完了で返す。
+- lead の定義のテスト方針に沿って、プロジェクトの規約・CI・push 前に求める検証（pre-push hook など）・変更の影響に応じた必須検証を行う。実装ミスによる検証失敗の自己修正は3回まで。超えたら根拠と未解決点を記録して未完了で返す。
 
 ## Phase 6: 実装後の確認
 

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

@@ -79,7 +79,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 - 目的・仕様・受入条件の変更が必要と分かったら、該当作業を止めて人に確認する。計画の前提が成立しない技術的な矛盾は計画を直し、設計・契約・検証条件が変わればPhase 4の扱いで再確認する。通常の判断は既存の合意と規約で解決する。
 - 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
 - 実装後、目的を保ったまま削除・統合できる処理を確かめ、不要な分岐・重複・互換層を減らしてからセルフレビューする。
-- [テスト方針](../testing.md)に沿って、プロジェクトの規約・CI・変更の影響に応じた検証を行う。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
+- [テスト方針](../testing.md)に沿って、プロジェクトの規約・CI・push前に求める検証（pre-push hookなど）・変更の影響に応じた検証を行う。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
 - Claude CodeでiOSの不具合の再現や原因の調査に実際の画面・操作の観測が必要な場合は、Apple公式のXcodeプラグインの `device-interaction` スキルを使える。使うのはこの目的の場合だけとし、同スキルがUI変更後の毎回の確認を勧めていても実装後の一律確認には使わない（動作QAは[QAと証拠](../linear/qa.md)の工程が担う）。操作とセッションの手順は同スキルに従う。端末は上の「Simulatorの所有と再利用」に従ってUDIDで指定し、同スキルのツールは指定に近い端末を選ぶことがあるため、開始したセッションの端末がそのUDIDと一致することを確かめる。未導入・未承認・その端末を選べない・一致しないなど使えない場合は、導入や権限の変更を手順に加えず、観測していない内容を未確認として扱う。観測は対象版・端末と合わせて `implementation.md`（Phase 7と修正サイクルでは `fix-log.md`）に残し、検証やQAの合格に読み替えない。
 - 実装ミスによる検証失敗の自己修正は3回まで。超えた場合は根拠と未解決点を記録し、追加試行・差分のレビュー・計画への差し戻しの選択肢を人に確認する。
 

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.50.3のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.50.3`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.51.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.51.1`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
 
 0.48.0から `config_version: 3`（操作ごとの許可の一覧を廃止し `constraints` を必須にした契約）だけを受理する。0.47.x以前のCLIと `$schema` のURLはv3を拒否し、0.48.0以降はv2を拒否するため、skill・CLI・`$schema` の版を揃えてから下の[旧設定の移行](#旧設定の移行)を行う。
 

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

@@ -2,9 +2,9 @@
 
 Agent QAは、自動テスト・API・ブラウザ・管理画面・Simulatorなど、AIが操作と結果を確認できるもの。Human QAは、人の判断や実機でしか確認できない条件。普通の画面に一律のHuman QAを設けない。不要なら「不要」と記録する。
 
-QAはPRごとに完結させ、複数のPRをまとめるために人の確認を遅らせない。環境ごとに、Agent QAと必要なHuman QAを分ける。Staging QAが必要な公開変更は、本番でも環境差と主要導線を確認する。存在しない環境を合格扱いにしない。
+QAはPRごとに完結させ、複数のPRをまとめるために人の確認を遅らせない。環境ごとに、Agent QAと必要なHuman QAを分ける。Staging QAが必要な公開変更は、本番でも環境差と主要導線を確認する。存在しない環境を合格扱いにしない。ただし[リリースQAの方式](release-qa.md)を採用した作業先では、開発中に確かめられない確認をPRごとに完結させず、[引継ぎ](release-qa.md#開発issue-リリースへ引き継ぐ確認)の項目としてリリースIssueで確かめる。
 
-自動検証のコマンドと必須対象は、各プロジェクトの規約・CI・スクリプト（設定の `references.validation`）を正本にする。原因調査の絞り込み実行を、必須検証全体の合格に読み替えない。成否の判定とログの短縮は[テスト方針](../testing.md)に従う。
+自動検証のコマンドと必須対象は、各プロジェクトの規約・CI・スクリプト（設定の `references.validation`）と、そのプロジェクトがpush前に求める検証（pre-push hookなど）を正本にする。原因調査の絞り込み実行を、必須検証全体の合格に読み替えない。成否の判定とログの短縮は[テスト方針](../testing.md)に従う。
 
 ## 証拠の要件
 
@@ -18,7 +18,7 @@ QAはPRごとに完結させ、複数のPRをまとめるために人の確認
 Simulator等の仮想端末は、プロジェクトごとのQA専用端末を作成して再利用する。作業ごとの増設や毎回の削除を既定にしない。2ユーザーのE2Eなど複数台が必要な場合は、そのプロジェクトの専用端末として確保する。
 
 - 使う端末をUDIDで固定し、ビルド・インストール・起動・UI操作・終了などの各操作で対象を明示する。起動中の端末や表示中の端末を暗黙に選ばない。
-- 端末とプロジェクトの対応、使用状況（端末名・UDID・用途・使用中の作業と開始時刻）は、同じリポジトリの全作業ツリーで1つの記録を共有して調整するため、メインの作業ツリー（[Linear共通設定](configuration.md) の「設定の読み方」）の `.shinaps/work/simulators.md` に記録する。記録の初期化と保全は、メインの作業ツリーを対象に[作業記録](../work-records.md)の手順で行う。他プロジェクトや普段使いの端末を停止・初期化・削除しない。
+- 端末とプロジェクトの対応、使用状況（端末名・UDID・用途・使用中の作業と開始時刻）は、同じリポジトリの全作業ツリーで1つの記録を共有して調整するため、メインの作業ツリー（[Linear共通設定](configuration.md) の「設定の読み方」）の `.shinaps/work/simulators.md` に記録する。プロジェクトがpush前に求める検証がQA専用端末を使う場合は、pushもその端末の使用に含め、pushの前にこの記録で調整する。使い終えたら、成否によらず使用中の記録を外す。記録の初期化と保全は、メインの作業ツリーを対象に[作業記録](../work-records.md)の手順で行う。他プロジェクトや普段使いの端末を停止・初期化・削除しない。
 - 同じプロジェクトの別の作業が使用中なら、調整して順に使い、占有を奪わない。
 - 自動QAでは端末を不要に前面へ出さず、人の確認が必要なときに対象を表示する。表示やUI操作ツールの制約で他の作業と衝突する場合は、一方的に切り替えず調整する。
 

package/plugins/shinaps-claude/references/linear/release-qa.md

@@ -0,0 +1,122 @@
+# リリースQAの引継ぎと進行
+
+develop へ統合した開発Issueの確認を、develop → main の release PR ごとのリリースIssueへ集めてから配布する方式（以下「この方式」）の手順。開発Issueの引継ぎの書き方と、リリースIssueを進める担当の判断を定める。記録の追記と照合は共通のCLIが行い、どの項目をどう確かめるか、以前の合格を今の head へ持ち越してよいかは担当が決める。
+
+| 担当 | 責務 |
+| --- | --- |
+| 進行役（Linear進行ではCodex） | 開発Issueの引継ぎの記録、リリースIssueの開始時の決定・計画・確認・記録・ステータス・Done |
+| 共通のCLI | 引継ぎの収集、記録の追記、記録と release PR の head・環境の版の照合、`release-gate`、release PR の merge |
+| 作業先のリポジトリ | CLIを呼ぶwrapper、環境の版を読む観測コマンド、配備・配布の手順、CLIを実行するworkflow（GitHub Actions）、記録として認めるLinearの利用者の設定 |
+| 人 | 人が行う確認、許可の範囲の判断 |
+
+`release-gate` は、共通のCLIが release PR の head に付ける判定で、stagingの確認が記録の上でそろったかを表す。満たしていない条件は `status` が理由として示す。
+
+Linear進行では、Claudeは実装担当のままで、リリースIssueの進行を担当しない。リリースQAで見つかった不具合は、元の開発Issueに関連づけた修正Issueとして通常の工程でdevelopへ入れる。
+
+## 採用の判定
+
+作業先の設定が採用した資料（`instructions.md` と `references`。[設定の読み方](configuration.md#設定の読み方)）が、release PR とwrapperの呼び出し方を定めている場合だけこの方式を使う。ファイルやworkflowがあるだけで採用とは扱わない。定めていない作業先は[担当と工程](workflow.md#工程とステータス)の5工程で進め、この方式への移行を求めない。採用する前から進行中のリリースは途中で変換せず、その完了か、明示した切り替えの時点から使う。
+
+- 操作を行うかどうかは[依頼範囲と操作](../request-scope.md)で判断する。この方式は許可を増やさず、許可のための設定も持たない。
+- `status`・`plan`・`record`・`carry`・`record-deployment`・`merge` は作業先のwrapperで実行する。`sync`・`gate` は作業先のworkflowを起動して実行する。共通のCLIの配布元と版は作業先の資料に従い、本書では決めない。
+- 共通のCLI・wrapper・workflowの失敗や拒否は、成功を記録せずに止め、実際の状態を読んで成功した工程から再開する。記録だけが失敗したら記録だけをやり直し、配備・配布はやり直さない。起動したか分からない配備・配布は、環境と配布先の実際の状態を読んでから進める。記録として認められない利用者の記録など、作業先の設定が原因の拒否は回避せず、[停止と人への確認](workflow.md#失敗確認停止の共通ルール)に従う。
+
+## 保つ性質
+
+- developへ統合した変更の受入条件は、開発中に確かめた証拠、引継ぎの項目、理由付きの「なし」のどれかへ辿れる。空の一覧や未整理を、確認不要とは扱わない。
+- 一つの操作で複数の項目を確かめても、結果から各項目と出所の開発Issueへ辿れる。
+- 記録は追記だけにする。確かめ直した結果は新しい記録にし、変更の影響が無いと判断した項目は、理由を付けた `carry` で以前の合格を今の head へ持ち越す。以前の記録を書き換えない。
+- 人が確かめると決めた項目は、本人の報告にもとづく記録だけで満たす。開始時の許可、agentの合格、自動の承認では満たさない。
+- 配布の成功、環境で実際に動いている版、QAの合格は別の事実として扱う。
+- 共通のCLIの判定と表示（`release-gate`、項目の状態）はLinearの工程ではない。リリースIssueのステータスとDoneは、進行役が結果を読んで動かす。
+
+## 開発Issue: リリースへ引き継ぐ確認
+
+開発IssueのDoneは、必要なQA・レビュー・developへの統合・引継ぎがそろった状態を表し、配布済みを意味しない。通常のPRのbaseはdevelopにし、PRのタイトルか本文に開発Issueのキーを書く（ブランチ名だけでは出所に辿れない）。
+
+進行役は、Local Agent QAの合格後、終了地点で止まる前（遅くともdevelopへmergeする前。収集はdevelopへのpushのたびに引継ぎを読む）に、開発Issueのコメントとして引継ぎを書く。材料は受入条件、Local Agent QAの記録、ソースの差分、Claudeの完了報告（未解決の事項など）。
+
+- 開発中に確かめられる条件は開発Issueで確かめ、引継ぎで後へ回さない。配布物・staging・本番・人・実機でしか確かめられない条件と、配布した環境で確かめる価値のある利用者向けの挙動は引き継ぐ。どちらでも、環境が無いことを理由に条件を消さない。
+- 見出しは `リリースへ引き継ぐ確認`（階層は問わない）。最上位の箇条書き1つが1項目で、入れ子や続く段落は同じ項目に含まれる。各項目には、操作と期待結果、stagingか本番か、人や実機が要る条件、開発中に確かめたことと未確認のことを普通の文で書く。確かめる環境や担当（agent・人）が違う確認は、別の項目にする（計画は項目ごとに担当を一つ持つ）。
+- 全項目に共通する条件は、最初の箇条書きより前に書く。項目ごとに違う条件は、その項目の中に書く。
+- 追加の確認が要らなければ、節を `なし: <理由>` だけにする（他の項目や導入文と混ぜない）。理由の無い「なし」と空の節は未整理になる。
+- 人にJSON・内部のid・短縮したidを書かせない。項目のidは共通のCLIが内容から作る。
+
+```markdown
+### リリースへ引き継ぐ確認
+
+テスト用のアカウントでログインして確認する:
+
+- staging で一覧画面を開くと、新しい順に並ぶ
+- staging で通知を受け取ると未読の件数が増え、アプリをバックグラウンドから戻したときも増える（開発中は Simulator の通知で確認済み。実機は未確認）
+- 本番の配布後に、実機で初めて起動すると通知の許可を一度だけ求められる（人が確認する）
+```
+
+最新の節が全件を表すので、直すときは以前の項目も含めた節を新しいコメントで書く。項目や導入文の文言を変えると別の項目として扱われ、以前の合格は付かない（導入文の変更は全項目に及ぶ）。developへmergeした後に直したら、作業先の手順で `sync` を起動する。他のコメントではこの見出しを使わない（最新の引継ぎとして読まれる）。折りたたみの節は引継ぎの節より後に置く（節は、同じ階層以上の次の見出しか折りたたみの区切りで終わる）。
+
+## リリースIssueの進行
+
+リリースIssueは、developへのpushで共通のCLIが release PR とともに作る。開発Issueの着手から差分確定まで（Readyの判定、経路・体制の確認、Claudeへの依頼）は通らず、この節の工程で進める。[失敗・確認・停止の共通ルール](workflow.md#失敗確認停止の共通ルール)・[待ち状態](workflow.md#待ち状態)・[人への依頼](workflow.md#人への依頼)は使うが、不合格の戻し先は冒頭の修正Issueにする。リリースIssueは修正Issueへの依存として元の工程のまま待ち（[待ち状態](workflow.md#待ち状態)）、修正Issueは今回の実行範囲に含まれる場合か、利用者と合意した場合に進める。
+
+バックログ消化・Cycle全体の対象には、利用者が対象として明示した場合だけ含める。開始時の対象一覧にリリースIssueがあり明示されていなければ、対象外として理由とともに[開始時の記録](execution.md#開始時に固定するもの)に残し、Cycle報告では成果と区別する。
+
+### 到達点と開始
+
+到達点は、今回の明示の指定を優先する。一般的な進行の依頼では、設定の `stop_after` が `issue_done` ならDoneまで進む。他の値はリリースIssueに対応する工程が無いので、[工程とステータス](workflow.md#工程とステータス)の「適用される最後の必要工程まで」を当てはめず、開始時に一問で確認する。release PR のmergeで配備が始まる作業先では、その配備が到達点に含まれるかを[依頼範囲と操作](../request-scope.md#通常操作)で照らす。
+
+開始時に、リリースIssueの本文（共通のCLIが作る本文がここに書くよう案内している。共通のCLIは作成後の本文を書き換えない）へ次を書く。
+
+- 配布先（作業先の資料か受入条件にある先）と到達点。資料と受入条件から今回の配布先が一つに決まらないときは、開始時に一問で確認し（到達点の確認が要るときはそれと合わせる）、回答を残す。
+- 人の担当
+- 必須のQA: 項目の外で行う確認（共通の導線、本番での環境差と主要な導線など）とその環境。項目ごとの要否は共通のCLIの計画の記録（表示用コメントで確かめられる）にあると書き添える。
+
+項目ごとの要否は計画の記録を正本にし、本文へ写さない。途中で変えたら本文を直し、理由をコメントに残す。到達点までの通常操作は、本番の直前に許可を取り直さない。
+
+### 計画
+
+`status` の出力（以前のheadからの変更を含む）を読み、項目の重複・順序・まとめて確かめる方法を決め、`plan` に項目ごとの確かめる環境（staging・本番）と担当（agent・human）か、対象外の理由を記録する。本番で確かめる項目は、[QAと証拠](qa.md)の「本番でも環境差と主要導線を確認する」を材料に選ぶ。理由付きの「なし」は、計画が無くても対象外として扱われる。項目を対象外にするのは、資料から理由が決まる場合（他の項目と重複する、開発中に確かめ済みなど）だけにし、確かめられないことを理由にしない（受入条件の変更に当たるので[停止と人への確認](workflow.md#失敗確認停止の共通ルール)に従う）。
+
+未整理の項目は、ソースの差分と受入条件から補い、引継ぎを直して `sync` を起動するか、対象外の理由を記録する。開発Issueを特定できないPRによる未整理は、そのPRのタイトルか本文にIssueのキーを足して `sync` を起動する。利用者の判断が要る点だけを相談する。
+
+### stagingの確認と記録
+
+- 確認の前（特に人へ依頼する前）に、作業先の観測手段でstagingに今のheadが動いていることを確かめ、動いていなければ作業先の手順で配備する。同じソースの版でも配備し直すと観測される配備が変わり、`merge` は確かめた配備と違うとして拒否し、以前の記録とも配備がそろわなくなるので、確かめ直すか `carry` で今の配備へ持ち越す。記録の直前の照合は共通のCLIに任せる。
+- 一つの操作で複数の項目を確かめたら、`record` にそのすべての項目を含め、証拠に操作を書く。不合格・未確認もそのとおりに記録する。
+- 項目の結果は共通のCLIの記録をQAのコメントとし、証拠は[証拠の要件](qa.md#証拠の要件)に従う。項目の外で行う確認は[QAコメントの書式](qa.md#qaコメントの書式と更新)で書く。
+- 人が確かめる項目は[Human QAの引き渡し](qa.md#human-qaの引き渡し)に従って依頼し、本人の報告から `--by human` で記録する。回答を待つ間も `staging_human_qa`・`production_human_qa` のままにする。
+- 記録の後は `gate` を起動する。表示と記録が食い違っていたら、`sync` か `gate` を起動し直す。
+
+### 追加のmerge
+
+QAの途中でdevelopが進むと、`sync` が新しい出所の記録を追記する。`status` が示す以前のheadからの変更を読み、影響がある項目と影響を限定できない項目は確かめ直す。影響が無いと判断できる項目は、理由を付けて `carry` で持ち越す。毎回の全件の回帰や、製品の全テストは求めない。
+
+### merge・配布・本番の確認
+
+- `release-gate` が成功し、本文の必須のQAのうちstagingで行う確認が今のheadで合格したら、wrapperの `merge` を実行する。`merge` は判定とstagingで動いている配備を確かめ直し、そのheadを指定してmergeする。GitHubの画面や `gh pr merge` はstagingの配備を読み直さないので使わない。CIの必須の条件は作業先の資料とrulesetに従い、GitHubが拒否する条件を重ねて検査しない。
+- 作業先の手順で配備・配布し（`release` スキル）、`record-deployment` で配布の事実を記録する。
+- 本番の確認を `record --stage production` で記録し、`gate` を起動して表示を更新し、`status --stage production` で今の本番の版と照らす。
+
+### Done
+
+次がすべて成り立つときに、進行役がリリースIssueをDoneにする。
+
+- 合意した配布先へ配布した。
+- 本番で確かめると計画した項目が、今の本番の版で合格している。
+- 項目の外で行う確認が合格している。
+- 対象外の項目には理由がある。
+
+### 次のリリースとの関係
+
+mainへmergeした後のdevelopの変更は、次の release PR とリリースIssueへ集まる。進行中の本番の確認の対象を、黙って次の版へ変えない。未完了のまま次の版を配布するときは、両方のリリースIssueに未完了の項目・影響・移す先を記録する。不具合を修正版で直すときは、元のリリースの問題を修正版の確認へ結びつけ、元のリリースを未確認のままDoneにしない。
+
+## 状態キーとの対応
+
+| 工程 | 状態キー |
+| --- | --- |
+| 共通のCLIによる作成 | `todo` |
+| 開始時の決定と計画、merge・配布 | `release` |
+| stagingの確認 | `staging_agent_qa`・`staging_human_qa` |
+| 本番の確認 | `production_agent_qa`・`production_human_qa` |
+| 完了 | `done` |
+
+専用のステータスが無い工程は[工程とステータス](workflow.md#工程とステータス)の規則に従う。`human_input` は外部の対応を待つときだけに使う。結果の語（合格・不合格・未確認・対象外）は[QAと証拠](qa.md)と同じ意味で使う。

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

@@ -34,6 +34,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 - QAステータスへの移動とQAの合格を区別する。終了地点への到達とIssueのDoneを区別する。
 - 工程を行うかどうかは、Issueの受入条件と終了地点で決める。Issueに適用されない工程は通らない（配備しない変更の環境配備・環境QA、Git変更がない作業の差分確定・PRなど）。省略した工程は理由を記録する。工程の省略を理由に、必要なQAや未達の受入条件を省かない。
 - 終了地点の工程がそのIssueにない場合は、適用される最後の必要工程まで進めて止まる。そのとき必須受入条件をすべて満たしていればDoneにする。満たしていなければ、残る条件を記録してDoneにしない（push前QAで止める運用で、本番公開の受入条件が残るIssueなど）。
+- [リリースQAの方式](release-qa.md)を採用した作業先では、開発Issueの配布で確かめる条件は、引継ぎの項目としてリリースIssueの完了条件へ移る。開発IssueのDoneはその確認を待たず、配布済み・確認済みを意味しない。リリースIssueはこの5工程ではなく、同じ資料の工程で進める。
 - Human QAが新たに必要になった場合は、理由と具体的な残項目をIssueに記録して利用者に相談する。
 - プロジェクトの規約や補足の記述だけでは、AIコミットの進め方の根拠として扱わない。[共通設定のパス別の方針](configuration.md#パス別の方針)に従って、通常設定・適用ルール・今回の明示指示から実効方針を決める。
 - 実効方針が `review_flow.mode: auto` の単位は、Codexが差分確定で対象単位を明示し、人のレビューの省略と実施した確認への参照をIssueへ記録する。人のレビュー済みとは記録しない。

package/plugins/shinaps-claude/references/managed/execute.md

@@ -30,6 +30,7 @@ shinaps-skills managed run .shinaps/managed.json --account <name> \
 ```
 
 - 設定と引数を検証し、セッションを作る前に次で止まる: `draft_pr` を許可したのにそのアカウントの `vault_id` が `null`、`push` か `draft_pr` を許可したのに token が無い。どちらもセッションを作ってから lead が気づくと予算を消費した後になるため。
+- 作業先が push 前に求める検証（pre-push hook など）に、Managed の環境で実行できないもの（Xcode など）が要る場合は、`--allow` に `push` と `draft_pr` を含めない。許可しても lead は push できず、実装を終えても `未完了` で返すため。回収した差分の統合と push は、[5. 出力を回収して確かめる](#5-出力を回収して確かめる)の確認の後に利用者と決めた作業で、作業先の検証を通して行う。
 - セッションは lock の lead と環境、そのアカウントの vault、`max_list_cost` の予算、base の SHA をチェックアウトしたリポジトリで作る。head ブランチが無ければ lead が base から作る。初回メッセージにはリポジトリ・base と SHA・head・範囲と受入条件・体制・許可・予算・任意の入力を全て書く。
 - `--claude-md` は `ant beta:files upload` で上げ、`/mnt/session/uploads/CLAUDE.md` に置く。
 - 同じ入力（設定のリポジトリと vault、引数、範囲と CLAUDE.md の本文）の再実行は新しいセッションを作らず、記録したセッションの ID を返す。完了後に同じ範囲で新しく依頼するときは、題名など入力を変える。作成の途中で止まった記録が残っていれば作らずに止まる。表示された metadata `shinaps_request` のセッションがコンソールに無いことを確かめてから、表示された記録を消して再実行する。
@@ -75,7 +76,7 @@ shinaps-skills managed collect --account <name> --session <ID>
 
 - `managed setup`・`run`・`status`・`reply`・`collect` のコマンド・フラグ・stdin の本文・出力の形は ant 2.4.0 の公式ソースで照合し、偽の `ant` を使うテストで確かめた。実際の `ant` とクラウドではまだ実行していない。
 - API の側で決まり、ant のソースでは確かめられないこと: `mount_path: /CLAUDE.md` が `/mnt/session/uploads/CLAUDE.md` に置かれるか、Files の upload・一覧・取得に `files-api-2025-04-14` と `managed-agents-2026-04-01` の両方の beta を付ければよいか（ant の `--beta` は既定の beta を置き換えるので、全ての呼び出しで明示している）、Files の応答の `filename`・`size_bytes`・`created_at`、events の一覧に役割のスレッドの `agent.message` が混ざるか。lock が無い状態での skill の重複は、同じ setup で作る lead の同名確認で止まる。
-- マウントしたリポジトリの remote へ `git push` できるか（`authorization_token` が push に使われるか）。最初のセッションで最優先に確かめ、できなければ GitHub MCP の push 用ツール（`create_branch`・`push_files`）を有効にするかを利用者と相談する。
+- マウントしたリポジトリの remote へ `git push` できるか（`authorization_token` が push に使われるか）。最初のセッションで最優先に確かめ、できなければ GitHub MCP の push 用ツール（`create_branch`・`push_files`）を有効にするかを利用者と相談する。この手段は git の hook を通らないので、作業先が push 前に検証を求める場合は push の代わりにしない。
 - commit をチェックアウトしてマウントした作業先から、origin の head ブランチを取得できるか（clone の深さと fetch の資格情報）。
 - GitHub MCP で draft PR を作れるか。`draft: true` は lead への指示でしか担保されない。
 - vault に資格情報を登録できたことは、上の3点の確認にならない。

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

@@ -30,7 +30,7 @@ description: ブランチの変更意図と検証結果を整理し、リポジ
 ## 作成と確認
 
 - 完成したタイトルと本文を提示し、依頼範囲に含まれるpush・PRの公開を進める。ドラフトの指定と対象ブランチを守る。
-- 必要なpushは通常のpushを単独コマンドで行う。force-pushや履歴書き換えに広げない。
+- 必要なpushは、作業先がpush前に求める検証（pre-push hookなど）を通した通常のpushを単独コマンドで行う。検証がQA専用端末を使う場合は、[QAと証拠](../../references/linear/qa.md#simulatorの所有と再利用)に従ってpushの前に調整する。force-push・履歴書き換え・`--no-verify`・hookの無効化に広げない。pushが拒否されたら、同じ状態での再試行や別の手段でのpushをせず、拒否の理由（push前の検証で拒否されたなら、通らなかった検証）を報告して止める。
 - 本文は一時ファイルに保存し、`gh pr create --base <base> --head <head> --title <title> --body-file <file>` で渡す。本文をシェルのコマンド置換に埋め込まない。
 - 作成結果が不明な失敗は、再作成の前に同じheadのPRを読み戻す。URL、タイトル、base・head、draft状態を確認する。
 - タスクへのPR添付ツールがある環境では作成したPRを添付し、URLを報告する。作成をマージ・デプロイまで拡大しない。

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

@@ -17,6 +17,8 @@ description: プロジェクトの公開手順と完了条件に従ってリリ
 
 操作の判断は[依頼範囲と操作](../../references/request-scope.md)に従う。Linearの開発進行から受けた依頼では、実効到達点・`constraints` と[担当・工程](../../references/linear/workflow.md)を引き継ぐ。操作後は進行役へ結果を返し、[終了条件](../../references/linear/execution.md)に従って次工程を判断する。単独の依頼にはLinear進行や新しいゴールを必須にしない。
 
+作業先が[リリースQAの方式](../../references/linear/release-qa.md)を採用している場合、release PR のmergeと配布はその手順に従う（mergeはwrapperの `merge`、配布の事実は `record-deployment` で記録する）。リリースIssueの計画と完了の判断は進行役が行う。
+
 ## 公開前に条件を確定する
 
 対象環境・配布先・ソースrevision・成果物のバージョンと、成功を判断する操作・証拠を確定する。リポジトリのリリース手順を使い、既存CIや証拠形式があれば再利用する。専用のJSON形式や新しい検証基盤を導入すること自体を必須にしない。

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

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

package/plugins/shinaps-codex/managed-agents/agents/shinaps-dev-managed-cc.md

@@ -52,7 +52,7 @@ multiagent:
 - 初回メッセージにリポジトリ・base・head・範囲と受入条件・体制（LITE・BASIC・ULTRA）・許可・予算のいずれかが欠けていれば作業を始めない。欠落を列挙し、1行目を `状態: 質問` にしてターンを終える。
 - 許可は利用者のメッセージで明示された操作だけとする。この構成の導入、リポジトリの設定ファイル、過去の作業から許可を推定しない。
 - リポジトリ側で人の承認を要する方針（例: `review_flow: manual`、ブランチ保護、必須レビュー）は迂回せず、そこで止めて `状態: 未完了` で返す。
-- push は依頼の head ブランチにだけ行う。force push と base への push はしない。PR は draft で作る。
+- push は依頼の head ブランチにだけ、作業先が push 前に求める検証（pre-push hook など）をこのセッションで通してから行う。push の代わりに、その検証を通らない手段（GitHub MCP の `create_branch`・`push_files` など）を使わない。force push と base への push はしない。PR は draft で作る。
 - merge・deploy・release・Issue の更新・`ant apply`・予定実行の登録はしない。
 - Codex の QA をこのセッションで行ったとは報告しない。Shinaps AI の rule は取得せず、未照合と報告する。
 

package/plugins/shinaps-codex/managed-agents/skills/dev-managed-cc/references/launch.md

@@ -58,7 +58,7 @@ PR: <draft PR の URL。無ければ なし>
 
 - push に使えるのはマウント時の `github_repository.authorization_token` だけで、GitHub MCP に使えるのはセッション作成時に渡された vault の資格情報だけとする。
 - token をサンドボックスのファイル・環境変数・git の設定に書かない。作業記録と報告にも値を残さない。
-- push や PR 作成が拒否されたら、別の資格情報や経路を試さず、patch を置いて `状態: 未完了` で返す。
+- 作業先が push 前に求める検証を通せない（検証が拒否した、またはこの環境で実行できない）とき、および push や PR 作成が拒否されたときは、`--no-verify`・別の資格情報・別の経路を試さず、patch を置いて `状態: 未完了` で返し、通せなかった検証または拒否の理由を報告する。
 - PR は `create_pull_request` に `draft: true` を付けて作り、`pull_request_read` で draft であることを確かめる。
 
 ## Claude Code 固有の手段の置き換え

package/plugins/shinaps-codex/managed-agents/skills/dev-managed-cc/references/workflow.md

@@ -53,7 +53,7 @@ lead が確定計画を実装する。
 - 計画で決めた最終構造を実装する。必要な移動・分割を差分削減のために省略せず、全利用側の参照更新・旧経路や重複の解消・既存利用側の回帰確認まで行う。目的・仕様・受入条件の変更が必要と分かったら、該当作業を止めて `状態: 質問` で利用者に確認する。
 - 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
 - 実装後、目的を保ったまま削除・統合できる処理を確かめ、不要な分岐・重複・互換層を減らしてからセルフレビューする。
-- lead の定義のテスト方針に沿って、プロジェクトの規約・CI・変更の影響に応じた必須検証を行う。実装ミスによる検証失敗の自己修正は3回まで。超えたら根拠と未解決点を記録して未完了で返す。
+- lead の定義のテスト方針に沿って、プロジェクトの規約・CI・push 前に求める検証（pre-push hook など）・変更の影響に応じた必須検証を行う。実装ミスによる検証失敗の自己修正は3回まで。超えたら根拠と未解決点を記録して未完了で返す。
 
 ## Phase 6: 実装後の確認
 

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

@@ -79,7 +79,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 - 目的・仕様・受入条件の変更が必要と分かったら、該当作業を止めて人に確認する。計画の前提が成立しない技術的な矛盾は計画を直し、設計・契約・検証条件が変わればPhase 4の扱いで再確認する。通常の判断は既存の合意と規約で解決する。
 - 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
 - 実装後、目的を保ったまま削除・統合できる処理を確かめ、不要な分岐・重複・互換層を減らしてからセルフレビューする。
-- [テスト方針](../testing.md)に沿って、プロジェクトの規約・CI・変更の影響に応じた検証を行う。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
+- [テスト方針](../testing.md)に沿って、プロジェクトの規約・CI・push前に求める検証（pre-push hookなど）・変更の影響に応じた検証を行う。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
 - Claude CodeでiOSの不具合の再現や原因の調査に実際の画面・操作の観測が必要な場合は、Apple公式のXcodeプラグインの `device-interaction` スキルを使える。使うのはこの目的の場合だけとし、同スキルがUI変更後の毎回の確認を勧めていても実装後の一律確認には使わない（動作QAは[QAと証拠](../linear/qa.md)の工程が担う）。操作とセッションの手順は同スキルに従う。端末は上の「Simulatorの所有と再利用」に従ってUDIDで指定し、同スキルのツールは指定に近い端末を選ぶことがあるため、開始したセッションの端末がそのUDIDと一致することを確かめる。未導入・未承認・その端末を選べない・一致しないなど使えない場合は、導入や権限の変更を手順に加えず、観測していない内容を未確認として扱う。観測は対象版・端末と合わせて `implementation.md`（Phase 7と修正サイクルでは `fix-log.md`）に残し、検証やQAの合格に読み替えない。
 - 実装ミスによる検証失敗の自己修正は3回まで。超えた場合は根拠と未解決点を記録し、追加試行・差分のレビュー・計画への差し戻しの選択肢を人に確認する。
 

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.50.3のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.50.3`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.51.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.51.1`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
 
 0.48.0から `config_version: 3`（操作ごとの許可の一覧を廃止し `constraints` を必須にした契約）だけを受理する。0.47.x以前のCLIと `$schema` のURLはv3を拒否し、0.48.0以降はv2を拒否するため、skill・CLI・`$schema` の版を揃えてから下の[旧設定の移行](#旧設定の移行)を行う。
 

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

@@ -2,9 +2,9 @@
 
 Agent QAは、自動テスト・API・ブラウザ・管理画面・Simulatorなど、AIが操作と結果を確認できるもの。Human QAは、人の判断や実機でしか確認できない条件。普通の画面に一律のHuman QAを設けない。不要なら「不要」と記録する。
 
-QAはPRごとに完結させ、複数のPRをまとめるために人の確認を遅らせない。環境ごとに、Agent QAと必要なHuman QAを分ける。Staging QAが必要な公開変更は、本番でも環境差と主要導線を確認する。存在しない環境を合格扱いにしない。
+QAはPRごとに完結させ、複数のPRをまとめるために人の確認を遅らせない。環境ごとに、Agent QAと必要なHuman QAを分ける。Staging QAが必要な公開変更は、本番でも環境差と主要導線を確認する。存在しない環境を合格扱いにしない。ただし[リリースQAの方式](release-qa.md)を採用した作業先では、開発中に確かめられない確認をPRごとに完結させず、[引継ぎ](release-qa.md#開発issue-リリースへ引き継ぐ確認)の項目としてリリースIssueで確かめる。
 
-自動検証のコマンドと必須対象は、各プロジェクトの規約・CI・スクリプト（設定の `references.validation`）を正本にする。原因調査の絞り込み実行を、必須検証全体の合格に読み替えない。成否の判定とログの短縮は[テスト方針](../testing.md)に従う。
+自動検証のコマンドと必須対象は、各プロジェクトの規約・CI・スクリプト（設定の `references.validation`）と、そのプロジェクトがpush前に求める検証（pre-push hookなど）を正本にする。原因調査の絞り込み実行を、必須検証全体の合格に読み替えない。成否の判定とログの短縮は[テスト方針](../testing.md)に従う。
 
 ## 証拠の要件
 
@@ -18,7 +18,7 @@ QAはPRごとに完結させ、複数のPRをまとめるために人の確認
 Simulator等の仮想端末は、プロジェクトごとのQA専用端末を作成して再利用する。作業ごとの増設や毎回の削除を既定にしない。2ユーザーのE2Eなど複数台が必要な場合は、そのプロジェクトの専用端末として確保する。
 
 - 使う端末をUDIDで固定し、ビルド・インストール・起動・UI操作・終了などの各操作で対象を明示する。起動中の端末や表示中の端末を暗黙に選ばない。
-- 端末とプロジェクトの対応、使用状況（端末名・UDID・用途・使用中の作業と開始時刻）は、同じリポジトリの全作業ツリーで1つの記録を共有して調整するため、メインの作業ツリー（[Linear共通設定](configuration.md) の「設定の読み方」）の `.shinaps/work/simulators.md` に記録する。記録の初期化と保全は、メインの作業ツリーを対象に[作業記録](../work-records.md)の手順で行う。他プロジェクトや普段使いの端末を停止・初期化・削除しない。
+- 端末とプロジェクトの対応、使用状況（端末名・UDID・用途・使用中の作業と開始時刻）は、同じリポジトリの全作業ツリーで1つの記録を共有して調整するため、メインの作業ツリー（[Linear共通設定](configuration.md) の「設定の読み方」）の `.shinaps/work/simulators.md` に記録する。プロジェクトがpush前に求める検証がQA専用端末を使う場合は、pushもその端末の使用に含め、pushの前にこの記録で調整する。使い終えたら、成否によらず使用中の記録を外す。記録の初期化と保全は、メインの作業ツリーを対象に[作業記録](../work-records.md)の手順で行う。他プロジェクトや普段使いの端末を停止・初期化・削除しない。
 - 同じプロジェクトの別の作業が使用中なら、調整して順に使い、占有を奪わない。
 - 自動QAでは端末を不要に前面へ出さず、人の確認が必要なときに対象を表示する。表示やUI操作ツールの制約で他の作業と衝突する場合は、一方的に切り替えず調整する。
 

package/plugins/shinaps-codex/references/linear/release-qa.md

@@ -0,0 +1,122 @@
+# リリースQAの引継ぎと進行
+
+develop へ統合した開発Issueの確認を、develop → main の release PR ごとのリリースIssueへ集めてから配布する方式（以下「この方式」）の手順。開発Issueの引継ぎの書き方と、リリースIssueを進める担当の判断を定める。記録の追記と照合は共通のCLIが行い、どの項目をどう確かめるか、以前の合格を今の head へ持ち越してよいかは担当が決める。
+
+| 担当 | 責務 |
+| --- | --- |
+| 進行役（Linear進行ではCodex） | 開発Issueの引継ぎの記録、リリースIssueの開始時の決定・計画・確認・記録・ステータス・Done |
+| 共通のCLI | 引継ぎの収集、記録の追記、記録と release PR の head・環境の版の照合、`release-gate`、release PR の merge |
+| 作業先のリポジトリ | CLIを呼ぶwrapper、環境の版を読む観測コマンド、配備・配布の手順、CLIを実行するworkflow（GitHub Actions）、記録として認めるLinearの利用者の設定 |
+| 人 | 人が行う確認、許可の範囲の判断 |
+
+`release-gate` は、共通のCLIが release PR の head に付ける判定で、stagingの確認が記録の上でそろったかを表す。満たしていない条件は `status` が理由として示す。
+
+Linear進行では、Claudeは実装担当のままで、リリースIssueの進行を担当しない。リリースQAで見つかった不具合は、元の開発Issueに関連づけた修正Issueとして通常の工程でdevelopへ入れる。
+
+## 採用の判定
+
+作業先の設定が採用した資料（`instructions.md` と `references`。[設定の読み方](configuration.md#設定の読み方)）が、release PR とwrapperの呼び出し方を定めている場合だけこの方式を使う。ファイルやworkflowがあるだけで採用とは扱わない。定めていない作業先は[担当と工程](workflow.md#工程とステータス)の5工程で進め、この方式への移行を求めない。採用する前から進行中のリリースは途中で変換せず、その完了か、明示した切り替えの時点から使う。
+
+- 操作を行うかどうかは[依頼範囲と操作](../request-scope.md)で判断する。この方式は許可を増やさず、許可のための設定も持たない。
+- `status`・`plan`・`record`・`carry`・`record-deployment`・`merge` は作業先のwrapperで実行する。`sync`・`gate` は作業先のworkflowを起動して実行する。共通のCLIの配布元と版は作業先の資料に従い、本書では決めない。
+- 共通のCLI・wrapper・workflowの失敗や拒否は、成功を記録せずに止め、実際の状態を読んで成功した工程から再開する。記録だけが失敗したら記録だけをやり直し、配備・配布はやり直さない。起動したか分からない配備・配布は、環境と配布先の実際の状態を読んでから進める。記録として認められない利用者の記録など、作業先の設定が原因の拒否は回避せず、[停止と人への確認](workflow.md#失敗確認停止の共通ルール)に従う。
+
+## 保つ性質
+
+- developへ統合した変更の受入条件は、開発中に確かめた証拠、引継ぎの項目、理由付きの「なし」のどれかへ辿れる。空の一覧や未整理を、確認不要とは扱わない。
+- 一つの操作で複数の項目を確かめても、結果から各項目と出所の開発Issueへ辿れる。
+- 記録は追記だけにする。確かめ直した結果は新しい記録にし、変更の影響が無いと判断した項目は、理由を付けた `carry` で以前の合格を今の head へ持ち越す。以前の記録を書き換えない。
+- 人が確かめると決めた項目は、本人の報告にもとづく記録だけで満たす。開始時の許可、agentの合格、自動の承認では満たさない。
+- 配布の成功、環境で実際に動いている版、QAの合格は別の事実として扱う。
+- 共通のCLIの判定と表示（`release-gate`、項目の状態）はLinearの工程ではない。リリースIssueのステータスとDoneは、進行役が結果を読んで動かす。
+
+## 開発Issue: リリースへ引き継ぐ確認
+
+開発IssueのDoneは、必要なQA・レビュー・developへの統合・引継ぎがそろった状態を表し、配布済みを意味しない。通常のPRのbaseはdevelopにし、PRのタイトルか本文に開発Issueのキーを書く（ブランチ名だけでは出所に辿れない）。
+
+進行役は、Local Agent QAの合格後、終了地点で止まる前（遅くともdevelopへmergeする前。収集はdevelopへのpushのたびに引継ぎを読む）に、開発Issueのコメントとして引継ぎを書く。材料は受入条件、Local Agent QAの記録、ソースの差分、Claudeの完了報告（未解決の事項など）。
+
+- 開発中に確かめられる条件は開発Issueで確かめ、引継ぎで後へ回さない。配布物・staging・本番・人・実機でしか確かめられない条件と、配布した環境で確かめる価値のある利用者向けの挙動は引き継ぐ。どちらでも、環境が無いことを理由に条件を消さない。
+- 見出しは `リリースへ引き継ぐ確認`（階層は問わない）。最上位の箇条書き1つが1項目で、入れ子や続く段落は同じ項目に含まれる。各項目には、操作と期待結果、stagingか本番か、人や実機が要る条件、開発中に確かめたことと未確認のことを普通の文で書く。確かめる環境や担当（agent・人）が違う確認は、別の項目にする（計画は項目ごとに担当を一つ持つ）。
+- 全項目に共通する条件は、最初の箇条書きより前に書く。項目ごとに違う条件は、その項目の中に書く。
+- 追加の確認が要らなければ、節を `なし: <理由>` だけにする（他の項目や導入文と混ぜない）。理由の無い「なし」と空の節は未整理になる。
+- 人にJSON・内部のid・短縮したidを書かせない。項目のidは共通のCLIが内容から作る。
+
+```markdown
+### リリースへ引き継ぐ確認
+
+テスト用のアカウントでログインして確認する:
+
+- staging で一覧画面を開くと、新しい順に並ぶ
+- staging で通知を受け取ると未読の件数が増え、アプリをバックグラウンドから戻したときも増える（開発中は Simulator の通知で確認済み。実機は未確認）
+- 本番の配布後に、実機で初めて起動すると通知の許可を一度だけ求められる（人が確認する）
+```
+
+最新の節が全件を表すので、直すときは以前の項目も含めた節を新しいコメントで書く。項目や導入文の文言を変えると別の項目として扱われ、以前の合格は付かない（導入文の変更は全項目に及ぶ）。developへmergeした後に直したら、作業先の手順で `sync` を起動する。他のコメントではこの見出しを使わない（最新の引継ぎとして読まれる）。折りたたみの節は引継ぎの節より後に置く（節は、同じ階層以上の次の見出しか折りたたみの区切りで終わる）。
+
+## リリースIssueの進行
+
+リリースIssueは、developへのpushで共通のCLIが release PR とともに作る。開発Issueの着手から差分確定まで（Readyの判定、経路・体制の確認、Claudeへの依頼）は通らず、この節の工程で進める。[失敗・確認・停止の共通ルール](workflow.md#失敗確認停止の共通ルール)・[待ち状態](workflow.md#待ち状態)・[人への依頼](workflow.md#人への依頼)は使うが、不合格の戻し先は冒頭の修正Issueにする。リリースIssueは修正Issueへの依存として元の工程のまま待ち（[待ち状態](workflow.md#待ち状態)）、修正Issueは今回の実行範囲に含まれる場合か、利用者と合意した場合に進める。
+
+バックログ消化・Cycle全体の対象には、利用者が対象として明示した場合だけ含める。開始時の対象一覧にリリースIssueがあり明示されていなければ、対象外として理由とともに[開始時の記録](execution.md#開始時に固定するもの)に残し、Cycle報告では成果と区別する。
+
+### 到達点と開始
+
+到達点は、今回の明示の指定を優先する。一般的な進行の依頼では、設定の `stop_after` が `issue_done` ならDoneまで進む。他の値はリリースIssueに対応する工程が無いので、[工程とステータス](workflow.md#工程とステータス)の「適用される最後の必要工程まで」を当てはめず、開始時に一問で確認する。release PR のmergeで配備が始まる作業先では、その配備が到達点に含まれるかを[依頼範囲と操作](../request-scope.md#通常操作)で照らす。
+
+開始時に、リリースIssueの本文（共通のCLIが作る本文がここに書くよう案内している。共通のCLIは作成後の本文を書き換えない）へ次を書く。
+
+- 配布先（作業先の資料か受入条件にある先）と到達点。資料と受入条件から今回の配布先が一つに決まらないときは、開始時に一問で確認し（到達点の確認が要るときはそれと合わせる）、回答を残す。
+- 人の担当
+- 必須のQA: 項目の外で行う確認（共通の導線、本番での環境差と主要な導線など）とその環境。項目ごとの要否は共通のCLIの計画の記録（表示用コメントで確かめられる）にあると書き添える。
+
+項目ごとの要否は計画の記録を正本にし、本文へ写さない。途中で変えたら本文を直し、理由をコメントに残す。到達点までの通常操作は、本番の直前に許可を取り直さない。
+
+### 計画
+
+`status` の出力（以前のheadからの変更を含む）を読み、項目の重複・順序・まとめて確かめる方法を決め、`plan` に項目ごとの確かめる環境（staging・本番）と担当（agent・human）か、対象外の理由を記録する。本番で確かめる項目は、[QAと証拠](qa.md)の「本番でも環境差と主要導線を確認する」を材料に選ぶ。理由付きの「なし」は、計画が無くても対象外として扱われる。項目を対象外にするのは、資料から理由が決まる場合（他の項目と重複する、開発中に確かめ済みなど）だけにし、確かめられないことを理由にしない（受入条件の変更に当たるので[停止と人への確認](workflow.md#失敗確認停止の共通ルール)に従う）。
+
+未整理の項目は、ソースの差分と受入条件から補い、引継ぎを直して `sync` を起動するか、対象外の理由を記録する。開発Issueを特定できないPRによる未整理は、そのPRのタイトルか本文にIssueのキーを足して `sync` を起動する。利用者の判断が要る点だけを相談する。
+
+### stagingの確認と記録
+
+- 確認の前（特に人へ依頼する前）に、作業先の観測手段でstagingに今のheadが動いていることを確かめ、動いていなければ作業先の手順で配備する。同じソースの版でも配備し直すと観測される配備が変わり、`merge` は確かめた配備と違うとして拒否し、以前の記録とも配備がそろわなくなるので、確かめ直すか `carry` で今の配備へ持ち越す。記録の直前の照合は共通のCLIに任せる。
+- 一つの操作で複数の項目を確かめたら、`record` にそのすべての項目を含め、証拠に操作を書く。不合格・未確認もそのとおりに記録する。
+- 項目の結果は共通のCLIの記録をQAのコメントとし、証拠は[証拠の要件](qa.md#証拠の要件)に従う。項目の外で行う確認は[QAコメントの書式](qa.md#qaコメントの書式と更新)で書く。
+- 人が確かめる項目は[Human QAの引き渡し](qa.md#human-qaの引き渡し)に従って依頼し、本人の報告から `--by human` で記録する。回答を待つ間も `staging_human_qa`・`production_human_qa` のままにする。
+- 記録の後は `gate` を起動する。表示と記録が食い違っていたら、`sync` か `gate` を起動し直す。
+
+### 追加のmerge
+
+QAの途中でdevelopが進むと、`sync` が新しい出所の記録を追記する。`status` が示す以前のheadからの変更を読み、影響がある項目と影響を限定できない項目は確かめ直す。影響が無いと判断できる項目は、理由を付けて `carry` で持ち越す。毎回の全件の回帰や、製品の全テストは求めない。
+
+### merge・配布・本番の確認
+
+- `release-gate` が成功し、本文の必須のQAのうちstagingで行う確認が今のheadで合格したら、wrapperの `merge` を実行する。`merge` は判定とstagingで動いている配備を確かめ直し、そのheadを指定してmergeする。GitHubの画面や `gh pr merge` はstagingの配備を読み直さないので使わない。CIの必須の条件は作業先の資料とrulesetに従い、GitHubが拒否する条件を重ねて検査しない。
+- 作業先の手順で配備・配布し（`release` スキル）、`record-deployment` で配布の事実を記録する。
+- 本番の確認を `record --stage production` で記録し、`gate` を起動して表示を更新し、`status --stage production` で今の本番の版と照らす。
+
+### Done
+
+次がすべて成り立つときに、進行役がリリースIssueをDoneにする。
+
+- 合意した配布先へ配布した。
+- 本番で確かめると計画した項目が、今の本番の版で合格している。
+- 項目の外で行う確認が合格している。
+- 対象外の項目には理由がある。
+
+### 次のリリースとの関係
+
+mainへmergeした後のdevelopの変更は、次の release PR とリリースIssueへ集まる。進行中の本番の確認の対象を、黙って次の版へ変えない。未完了のまま次の版を配布するときは、両方のリリースIssueに未完了の項目・影響・移す先を記録する。不具合を修正版で直すときは、元のリリースの問題を修正版の確認へ結びつけ、元のリリースを未確認のままDoneにしない。
+
+## 状態キーとの対応
+
+| 工程 | 状態キー |
+| --- | --- |
+| 共通のCLIによる作成 | `todo` |
+| 開始時の決定と計画、merge・配布 | `release` |
+| stagingの確認 | `staging_agent_qa`・`staging_human_qa` |
+| 本番の確認 | `production_agent_qa`・`production_human_qa` |
+| 完了 | `done` |
+
+専用のステータスが無い工程は[工程とステータス](workflow.md#工程とステータス)の規則に従う。`human_input` は外部の対応を待つときだけに使う。結果の語（合格・不合格・未確認・対象外）は[QAと証拠](qa.md)と同じ意味で使う。

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

@@ -34,6 +34,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 - QAステータスへの移動とQAの合格を区別する。終了地点への到達とIssueのDoneを区別する。
 - 工程を行うかどうかは、Issueの受入条件と終了地点で決める。Issueに適用されない工程は通らない（配備しない変更の環境配備・環境QA、Git変更がない作業の差分確定・PRなど）。省略した工程は理由を記録する。工程の省略を理由に、必要なQAや未達の受入条件を省かない。
 - 終了地点の工程がそのIssueにない場合は、適用される最後の必要工程まで進めて止まる。そのとき必須受入条件をすべて満たしていればDoneにする。満たしていなければ、残る条件を記録してDoneにしない（push前QAで止める運用で、本番公開の受入条件が残るIssueなど）。
+- [リリースQAの方式](release-qa.md)を採用した作業先では、開発Issueの配布で確かめる条件は、引継ぎの項目としてリリースIssueの完了条件へ移る。開発IssueのDoneはその確認を待たず、配布済み・確認済みを意味しない。リリースIssueはこの5工程ではなく、同じ資料の工程で進める。
 - Human QAが新たに必要になった場合は、理由と具体的な残項目をIssueに記録して利用者に相談する。
 - プロジェクトの規約や補足の記述だけでは、AIコミットの進め方の根拠として扱わない。[共通設定のパス別の方針](configuration.md#パス別の方針)に従って、通常設定・適用ルール・今回の明示指示から実効方針を決める。
 - 実効方針が `review_flow.mode: auto` の単位は、Codexが差分確定で対象単位を明示し、人のレビューの省略と実施した確認への参照をIssueへ記録する。人のレビュー済みとは記録しない。

package/plugins/shinaps-codex/references/managed/execute.md

@@ -30,6 +30,7 @@ shinaps-skills managed run .shinaps/managed.json --account <name> \
 ```
 
 - 設定と引数を検証し、セッションを作る前に次で止まる: `draft_pr` を許可したのにそのアカウントの `vault_id` が `null`、`push` か `draft_pr` を許可したのに token が無い。どちらもセッションを作ってから lead が気づくと予算を消費した後になるため。
+- 作業先が push 前に求める検証（pre-push hook など）に、Managed の環境で実行できないもの（Xcode など）が要る場合は、`--allow` に `push` と `draft_pr` を含めない。許可しても lead は push できず、実装を終えても `未完了` で返すため。回収した差分の統合と push は、[5. 出力を回収して確かめる](#5-出力を回収して確かめる)の確認の後に利用者と決めた作業で、作業先の検証を通して行う。
 - セッションは lock の lead と環境、そのアカウントの vault、`max_list_cost` の予算、base の SHA をチェックアウトしたリポジトリで作る。head ブランチが無ければ lead が base から作る。初回メッセージにはリポジトリ・base と SHA・head・範囲と受入条件・体制・許可・予算・任意の入力を全て書く。
 - `--claude-md` は `ant beta:files upload` で上げ、`/mnt/session/uploads/CLAUDE.md` に置く。
 - 同じ入力（設定のリポジトリと vault、引数、範囲と CLAUDE.md の本文）の再実行は新しいセッションを作らず、記録したセッションの ID を返す。完了後に同じ範囲で新しく依頼するときは、題名など入力を変える。作成の途中で止まった記録が残っていれば作らずに止まる。表示された metadata `shinaps_request` のセッションがコンソールに無いことを確かめてから、表示された記録を消して再実行する。
@@ -75,7 +76,7 @@ shinaps-skills managed collect --account <name> --session <ID>
 
 - `managed setup`・`run`・`status`・`reply`・`collect` のコマンド・フラグ・stdin の本文・出力の形は ant 2.4.0 の公式ソースで照合し、偽の `ant` を使うテストで確かめた。実際の `ant` とクラウドではまだ実行していない。
 - API の側で決まり、ant のソースでは確かめられないこと: `mount_path: /CLAUDE.md` が `/mnt/session/uploads/CLAUDE.md` に置かれるか、Files の upload・一覧・取得に `files-api-2025-04-14` と `managed-agents-2026-04-01` の両方の beta を付ければよいか（ant の `--beta` は既定の beta を置き換えるので、全ての呼び出しで明示している）、Files の応答の `filename`・`size_bytes`・`created_at`、events の一覧に役割のスレッドの `agent.message` が混ざるか。lock が無い状態での skill の重複は、同じ setup で作る lead の同名確認で止まる。
-- マウントしたリポジトリの remote へ `git push` できるか（`authorization_token` が push に使われるか）。最初のセッションで最優先に確かめ、できなければ GitHub MCP の push 用ツール（`create_branch`・`push_files`）を有効にするかを利用者と相談する。
+- マウントしたリポジトリの remote へ `git push` できるか（`authorization_token` が push に使われるか）。最初のセッションで最優先に確かめ、できなければ GitHub MCP の push 用ツール（`create_branch`・`push_files`）を有効にするかを利用者と相談する。この手段は git の hook を通らないので、作業先が push 前に検証を求める場合は push の代わりにしない。
 - commit をチェックアウトしてマウントした作業先から、origin の head ブランチを取得できるか（clone の深さと fetch の資格情報）。
 - GitHub MCP で draft PR を作れるか。`draft: true` は lead への指示でしか担保されない。
 - vault に資格情報を登録できたことは、上の3点の確認にならない。

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

@@ -30,7 +30,7 @@ description: ブランチの変更意図と検証結果を整理し、リポジ
 ## 作成と確認
 
 - 完成したタイトルと本文を提示し、依頼範囲に含まれるpush・PRの公開を進める。ドラフトの指定と対象ブランチを守る。
-- 必要なpushは通常のpushを単独コマンドで行う。force-pushや履歴書き換えに広げない。
+- 必要なpushは、作業先がpush前に求める検証（pre-push hookなど）を通した通常のpushを単独コマンドで行う。検証がQA専用端末を使う場合は、[QAと証拠](../../references/linear/qa.md#simulatorの所有と再利用)に従ってpushの前に調整する。force-push・履歴書き換え・`--no-verify`・hookの無効化に広げない。pushが拒否されたら、同じ状態での再試行や別の手段でのpushをせず、拒否の理由（push前の検証で拒否されたなら、通らなかった検証）を報告して止める。
 - 本文は一時ファイルに保存し、`gh pr create --base <base> --head <head> --title <title> --body-file <file>` で渡す。本文をシェルのコマンド置換に埋め込まない。
 - 作成結果が不明な失敗は、再作成の前に同じheadのPRを読み戻す。URL、タイトル、base・head、draft状態を確認する。
 - タスクへのPR添付ツールがある環境では作成したPRを添付し、URLを報告する。作成をマージ・デプロイまで拡大しない。

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

@@ -41,6 +41,7 @@ Issueの責務・受入条件・ステータスを、実際の成果と一致さ
 | auto経路の起動・観測・resume | [references/claude-cli.md](../../references/linear/claude-cli.md) |
 | manual経路の宛先・依頼・報告 | [references/bridge.md](../../references/linear/bridge.md) |
 | QAの実施・記録・素材 | [references/qa.md](../../references/linear/qa.md) |
+| リリースQAの方式を採用した作業先での引継ぎの記録と、リリースIssueの進行（5工程とは別） | [references/release-qa.md](../../references/linear/release-qa.md) |
 | Cycle完了QA・報告 | [references/cycle-report.md](../../references/linear/cycle-report.md) |
 
 コミットはClaudeへ差分確定を依頼して `shinaps:commit` で行い（manualは上の経路の項に従う）、Codexは各コミットの単位照合と全体照合を行う。pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには実効到達点・`constraints` と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで継続する。

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

@@ -17,6 +17,8 @@ description: プロジェクトの公開手順と完了条件に従ってリリ
 
 操作の判断は[依頼範囲と操作](../../references/request-scope.md)に従う。Linearの開発進行から受けた依頼では、実効到達点・`constraints` と[担当・工程](../../references/linear/workflow.md)を引き継ぐ。操作後は進行役へ結果を返し、[終了条件](../../references/linear/execution.md)に従って次工程を判断する。単独の依頼にはLinear進行や新しいゴールを必須にしない。
 
+作業先が[リリースQAの方式](../../references/linear/release-qa.md)を採用している場合、release PR のmergeと配布はその手順に従う（mergeはwrapperの `merge`、配布の事実は `record-deployment` で記録する）。リリースIssueの計画と完了の判断は進行役が行う。
+
 ## 公開前に条件を確定する
 
 対象環境・配布先・ソースrevision・成果物のバージョンと、成功を判断する操作・証拠を確定する。リポジトリのリリース手順を使い、既存CIや証拠形式があれば再利用する。専用のJSON形式や新しい検証基盤を導入すること自体を必須にしない。