@shinaps/skills 0.51.0 → 0.51.2

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.51.0
+npm install -g @shinaps/skills@0.51.2
 shinaps-skills --version
 ```
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.51.0",
+  "version": "0.51.2",
   "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.51.0",
+  "version": "0.51.2",
   "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.51.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.51.0`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.51.2のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.51.2`）。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

@@ -4,7 +4,7 @@ Agent QAは、自動テスト・API・ブラウザ・管理画面・Simulatorな
 
 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

@@ -32,7 +32,9 @@ Linear進行では、Claudeは実装担当のままで、リリースIssueの進
 
 ## 開発Issue: リリースへ引き継ぐ確認
 
-開発IssueのDoneは、必要なQA・レビュー・developへの統合・引継ぎがそろった状態を表し、配布済みを意味しない。通常のPRのbaseはdevelopにし、PRのタイトルか本文に開発Issueのキーを書く（ブランチ名だけでは出所に辿れない）。
+開発IssueのDoneは、必要なQA・レビュー・developへの統合・引継ぎがそろった状態を表し、配布済みを意味しない。通常のPRのbaseはdevelopにし、PRの本文に `Relates to <開発Issueのキー>` を書いて開発Issueと関連づける（共通のCLIはこのキーから出所を辿り、ブランチ名だけでは辿らない）。タイトルのキーと、`Relates to` 以外の関連づけの語（`Fixes`・`Part of` など）は使わない。LinearのGitHub連携は、これらでつないだIssueのステータスをPRの作成やmergeに合わせて変えることがあり、`Relates to` は変えない（[Linearの資料](https://linear.app/docs/github)）。ブランチ名のキーも同じ変更を起こしうるが、ブランチ名の付け方はこの方式では決めず、食い違いは次の段落のとおり直す。
+
+開発Issueのステータスは、進行役が工程の証拠にもとづいて動かす（PRの作成やmergeはQA・レビューの証拠ではない）。PRの作成・mergeの後や次にIssueを読んだときに、連携が変えたステータスが証拠と食い違っていれば、証拠に合わせて直す。
 
 進行役は、Local Agent QAの合格後、終了地点で止まる前（遅くともdevelopへmergeする前。収集はdevelopへのpushのたびに引継ぎを読む）に、開発Issueのコメントとして引継ぎを書く。材料は受入条件、Local Agent QAの記録、ソースの差分、Claudeの完了報告（未解決の事項など）。
 
@@ -76,7 +78,7 @@ Linear進行では、Claudeは実装担当のままで、リリースIssueの進
 
 `status` の出力（以前のheadからの変更を含む）を読み、項目の重複・順序・まとめて確かめる方法を決め、`plan` に項目ごとの確かめる環境（staging・本番）と担当（agent・human）か、対象外の理由を記録する。本番で確かめる項目は、[QAと証拠](qa.md)の「本番でも環境差と主要導線を確認する」を材料に選ぶ。理由付きの「なし」は、計画が無くても対象外として扱われる。項目を対象外にするのは、資料から理由が決まる場合（他の項目と重複する、開発中に確かめ済みなど）だけにし、確かめられないことを理由にしない（受入条件の変更に当たるので[停止と人への確認](workflow.md#失敗確認停止の共通ルール)に従う）。
 
-未整理の項目は、ソースの差分と受入条件から補い、引継ぎを直して `sync` を起動するか、対象外の理由を記録する。開発Issueを特定できないPRによる未整理は、そのPRのタイトルか本文にIssueのキーを足して `sync` を起動する。利用者の判断が要る点だけを相談する。
+未整理の項目は、ソースの差分と受入条件から補い、引継ぎを直して `sync` を起動するか、対象外の理由を記録する。開発Issueを特定できないPRによる未整理は、そのPRの本文に `Relates to <開発Issueのキー>` を足して `sync` を起動する。利用者の判断が要る点だけを相談する。
 
 ### stagingの確認と記録
 

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-codex/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "shinaps",
-  "version": "0.51.0",
+  "version": "0.51.2",
   "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.51.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.51.0`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.51.2のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.51.2`）。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

@@ -4,7 +4,7 @@ Agent QAは、自動テスト・API・ブラウザ・管理画面・Simulatorな
 
 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

@@ -32,7 +32,9 @@ Linear進行では、Claudeは実装担当のままで、リリースIssueの進
 
 ## 開発Issue: リリースへ引き継ぐ確認
 
-開発IssueのDoneは、必要なQA・レビュー・developへの統合・引継ぎがそろった状態を表し、配布済みを意味しない。通常のPRのbaseはdevelopにし、PRのタイトルか本文に開発Issueのキーを書く（ブランチ名だけでは出所に辿れない）。
+開発IssueのDoneは、必要なQA・レビュー・developへの統合・引継ぎがそろった状態を表し、配布済みを意味しない。通常のPRのbaseはdevelopにし、PRの本文に `Relates to <開発Issueのキー>` を書いて開発Issueと関連づける（共通のCLIはこのキーから出所を辿り、ブランチ名だけでは辿らない）。タイトルのキーと、`Relates to` 以外の関連づけの語（`Fixes`・`Part of` など）は使わない。LinearのGitHub連携は、これらでつないだIssueのステータスをPRの作成やmergeに合わせて変えることがあり、`Relates to` は変えない（[Linearの資料](https://linear.app/docs/github)）。ブランチ名のキーも同じ変更を起こしうるが、ブランチ名の付け方はこの方式では決めず、食い違いは次の段落のとおり直す。
+
+開発Issueのステータスは、進行役が工程の証拠にもとづいて動かす（PRの作成やmergeはQA・レビューの証拠ではない）。PRの作成・mergeの後や次にIssueを読んだときに、連携が変えたステータスが証拠と食い違っていれば、証拠に合わせて直す。
 
 進行役は、Local Agent QAの合格後、終了地点で止まる前（遅くともdevelopへmergeする前。収集はdevelopへのpushのたびに引継ぎを読む）に、開発Issueのコメントとして引継ぎを書く。材料は受入条件、Local Agent QAの記録、ソースの差分、Claudeの完了報告（未解決の事項など）。
 
@@ -76,7 +78,7 @@ Linear進行では、Claudeは実装担当のままで、リリースIssueの進
 
 `status` の出力（以前のheadからの変更を含む）を読み、項目の重複・順序・まとめて確かめる方法を決め、`plan` に項目ごとの確かめる環境（staging・本番）と担当（agent・human）か、対象外の理由を記録する。本番で確かめる項目は、[QAと証拠](qa.md)の「本番でも環境差と主要導線を確認する」を材料に選ぶ。理由付きの「なし」は、計画が無くても対象外として扱われる。項目を対象外にするのは、資料から理由が決まる場合（他の項目と重複する、開発中に確かめ済みなど）だけにし、確かめられないことを理由にしない（受入条件の変更に当たるので[停止と人への確認](workflow.md#失敗確認停止の共通ルール)に従う）。
 
-未整理の項目は、ソースの差分と受入条件から補い、引継ぎを直して `sync` を起動するか、対象外の理由を記録する。開発Issueを特定できないPRによる未整理は、そのPRのタイトルか本文にIssueのキーを足して `sync` を起動する。利用者の判断が要る点だけを相談する。
+未整理の項目は、ソースの差分と受入条件から補い、引継ぎを直して `sync` を起動するか、対象外の理由を記録する。開発Issueを特定できないPRによる未整理は、そのPRの本文に `Relates to <開発Issueのキー>` を足して `sync` を起動する。利用者の判断が要る点だけを相談する。
 
 ### stagingの確認と記録
 

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,7 +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) |
+| リリースQAの方式を採用した作業先での通常のPRの書き方・引継ぎの記録と、リリース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)まで継続する。