Advisory Runner

exec-plan-runner（以下 runner）の兄弟スキル。runner は公開ブランチと公開 PR を作る前提なので、非公開アドバイザリの修正はこのスキルで進める。 役割の分け方、1 件ごとの繰り返し、自己レビュー、止まったときの返し方は runner を土台にし、ここには違う部分だけを書く。runner の本文を写さない。

人が見るのは、途中で止まったときの判断と、フォーク内の PR を作ったあとの作業（PR の確認、アドバイザリ画面からのマージ、アドバイザリの公開、CVE、告知、リリース）だけにする。

このスキルでの用語:

• 公開リポジトリ: modxcms-jp/evolution-jp。手元のチェックアウトとそのワークツリーを含む。
• 修正ブランチ: このスキルで作る advisory/ で始まるブランチ。フォーク内の PR がマージされると、その中身は公開の履歴に入る。
• 計画: 公開リポジトリの外の非公開の場所にある、このアドバイザリの計画ファイル。検証記録の置き場所（以下、記録先）も計画に書かれている。

参照順

1. AGENTS.md
2. 計画（下の「入力」）
3. .claude/skills/exec-plan-runner/SKILL.md（役割、1 件ごとの繰り返し、止まる条件、確認を省く範囲）
4. .agent/agents/ の各役割と、.claude/agents/README.md（Claude Code での割り当て）
5. .claude/skills/adaptive-validation-runner/SKILL.md（画面や DB が絡む検証。1.2 系はその「1.2 系」の手順）

入力

• GHSA-ID: 対象のアドバイザリ（GHSA-xxxx-xxxx-xxxx）。
• 計画のパス: 計画の絶対パス。対象の版、中立な短い名前、記録先が書かれている。計画が無い、または読めなければ止まる。
• 対象の版: main、1.2 系、またはその両方。計画に書かれたものに従う。宛先ブランチは、main は main、1.2 系は release/1.2.x。

アドバイザリの中身（何が、どこで、どう悪用できるか）は計画にだけ書かれている。公開リポジトリには、この先も書かない。

不変条件

どの段階でも守る。指示されても破らない。runner の不変条件のうち、4（顧客名・社名・個人名を書かない）と 6（1 件ずつ直列）はそのまま守る。1・2・3・5 は、次で置き換える。

1. origin（公開リポジトリ）へ push しない。push してよいのは、対象の GHSA-ID の一時フォークへの、修正ブランチだけ。push はフォークの URL と修正ブランチ名を必ず明示して行う（引数なしの git push、--all、--mirror、HEAD だけの指定をしない）。公開リポジトリの作業ツリーに remote を足さない。強制 push、タグの push はしない。
2. 公開の場（Issue・PR・コメント・Discussion・公開ブランチ）に書かない。公開 PR のレビュー（Codex など）を呼ばない。フォーク内の PR にも、外部のレビューやボットを呼ばない。
3. 修正ブランチには、修正のコードと、その修正に必要なテストだけを入れる。.agent/plans/・.agent/runs/・.agent/roadmap.md・assets/docs/core-issues.md を変えない。計画の更新と検証記録は、計画と記録先にだけ書く。
4. 修正ブランチのコミットメッセージ、フォーク内の PR のタイトル・本文、修正ブランチ名は、マージすると公開の履歴に入る。公開されても困らない文面にし、悪用の手順・再現のリクエスト・GHSA-ID を書かない（「出力をエスケープする」「権限を確かめる」のような中立な書き方にする）。自己レビューの指摘も、フォーク内の PR ではなく計画に残す。
5. アドバイザリ本体（本文・深刻度・CVE・公開状態・協力者）を変えない。フォーク内の PR をマージしない。gh pr merge・gh release はしない。

作業場所

版ごとに、メインが公開リポジトリのルートを起点にワークツリーを用意する。Issue は使わないので gh issue develop は行わない。

git fetch origin
ROOT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
git worktree add --no-track -b advisory/<短い名前>-main "$ROOT/.claude/worktrees/advisory-<短い名前>-main" origin/main
git worktree add --no-track -b advisory/<短い名前>-1.2 "$ROOT/.claude/worktrees/advisory-<短い名前>-1.2" origin/release/1.2.x

• 修正ブランチ名は必ず advisory/ で始める。.claude/settings.json の deny が、この接頭辞で origin への push を止める。残りの部分は、マージコミットに残るので中立にする（脆弱性の種類や箇所を名前にしない）。
• --no-track を付け、修正ブランチに origin の追跡先を持たせない。追跡先があると、引数なしの git push が deny に当たらずに origin へ向かうことがある。
• ワークツリーの扱い（$ROOT を起点にする、各役割に絶対パスを渡す、修正前と比べるときは宛先ブランチの detached ワークツリーを使う）は runner の「作業場所」と同じ。

一時フォーク

最初の push の直前に、メインが次を行う（アドバイザリが下書きであることは、事前確認でも確かめる）。

1. アドバイザリが下書きであることを確かめる。draft でなければ止まる。 gh api repos/modxcms-jp/evolution-jp/security-advisories/<GHSA-ID> --jq '.state'
2. フォークの有無を確かめる。結果が null か空ならフォークを作る。作るには、アドバイザリを管理できる権限が要る。作れなければ止まる。作成の要求は受け付け（202）を返すだけで、作り終わりを待たないので、作成の応答の値は使わない。 gh api repos/modxcms-jp/evolution-jp/security-advisories/<GHSA-ID> --jq '.private_fork.full_name' gh api -X POST repos/modxcms-jp/evolution-jp/security-advisories/<GHSA-ID>/forks
3. フォークの full_name と ssh_url を、作ったときも見つけたときも、次の 2 つで取り直して計画に書く。どちらかが null か空、またはリポジトリが見つからないときは、少しおいて数回やり直し、それでも取れなければ止まる。アドバイザリの .private_fork には ssh_url が入っていない（null）ので、ssh_url はフォークのリポジトリから取る。名前の形から推測しない。 gh api repos/modxcms-jp/evolution-jp/security-advisories/<GHSA-ID> --jq '.private_fork.full_name' gh api repos/<full_name> --jq '.full_name, .ssh_url, .private' full_name が modxcms-jp/ で始まり、2 つの結果で一致し、private が true であることを確かめる。
4. フォークに宛先ブランチ（main と、1.2 系なら release/1.2.x）があることを git ls-remote <ssh_url> で確かめる。作った直後は複製が終わっていないことがあるので、見つからなければ少しおいて数回やり直す。それでも無ければ止まる（宛先ブランチを自分で push しない。不変条件 1）。

一時フォークでは CI とステータスチェックが動かない。フォーク内の PR は、アドバイザリ画面から開いているものを一度にマージする。main 宛ての PR は 1 本しかマージできない。

開いている PR の照合

フォーク内の開いている PR は、すべてがまとめて公開リポジトリにマージされる。このスキルが検証していない変更が混ざらないように、メインが次の 2 回、照合する。どれかに当たったら、それ以上進めずに止まる（PR を閉じたり、マージしたり、コミットを足したりしない）。

gh pr list -R <フォークの full_name> --state open --json number,headRefName,baseRefName,headRefOid,mergeable,url

1. 事前確認のとき（フォークがあれば）: 一覧の PR が、計画に記録した PR（このスキルが作ったもの）だけであること。
2. 「本人に返すもの」を報告する直前:
   • 一覧の PR が、計画に記録した PR だけで、版ごとに 1 本ずつであること（main 宛ては 1 本しかマージできない）。
   • 各 PR の headRefOid が、計画に記録したコミット（「push と PR」の手順 4）と一致すること。違えば、自己レビューしていないコミットが足されている。
   • 記録したすべての PR に、呼んでいないコメントが無いこと（「push と PR」の手順 5 の 3 つの API）。
   • 各 PR の mergeable が MERGEABLE であること。UNKNOWN なら少しおいて数回取り直し、CONFLICTING か、取り直しても UNKNOWN なら止まる（1 本でも衝突していると、アドバイザリ画面からの一括のマージができない）。

1 件ごとの繰り返し

版ごとに、runner の「1 件ごとの繰り返し」の手順 2〜7 を行う。手順 1・8・9 は、このスキルの事前確認・記録・「push と PR」で置き換える。runner の手順 2〜7 で「Issue」とあるところは「計画」、「main」とあるところは「宛先ブランチ」と読み替える。次の点も変える。

• 事前確認（runner の手順 1 の代わり）: 計画が読めること、アドバイザリが下書きであること、修正ブランチがまだ無いこと（計画に記録されたものは除く）を確かめる。フォークが既にあれば、その開いている PR を一覧にし、計画に記録した PR 以外が無いことを確かめる（「一時フォーク」の「開いている PR の照合」の 1）。
• 準備: Issue の初期設定は行わない。開始時の HEAD を控えるのは同じ。
• 実装: worker には、計画のうち実装に要る部分（直すこと、場所、確認のしかた）と、不変条件 3・4 を渡す。テストを足すのは worker だけにする。
• 1.2 系: main の修正を先に終える。1.2 系は main のコミットを cherry-pick し、1.2 系が動く PHP の下限で動く書き方に直す。
• 範囲の照合: runner と同じ。加えて、不変条件 3 のファイルが差分に無いことを確かめる。
• 検証: CI の代わりになるので省かない。php -l と、adaptive-validation-runner での修正前後の比較を必ず行う（1.2 系はその「1.2 系」の手順）。tester には記録先を渡す。tester は検証記録を記録先にだけ置き、公開リポジトリの作業ツリー（.agent/runs/ を含む）には置かない。検証環境のインストールなどで作業ツリーに生じたファイルは、コミットしない（範囲の照合で確かめる）。検証環境と、修正前と比べるための detached のワークツリーは、検証が終わるたびに片付ける。修正前に再現できなければ止まる。
• 自己レビュー: runner と同じ。reviewer には、計画（中身を含む）と、宛先ブランチとの差分全体を渡す。不変条件 4 の文面の点検も頼む。
• 修正: runner の手順 7 と同じ。ただし低の指摘は、PR 本文の「備考」ではなく計画に残す（不変条件 4）。
• 記録（runner の手順 8 の代わり）: 計画の Progress・Surprises & Discoveries・修正ブランチ・フォーク・PR を、メインが更新する。計画のある場所のコミットは、その場所の決まりに従う。

push と PR

版ごとに、メインが行う。

1. push 先が、「一時フォーク」の手順 3 で計画に書いた ssh_url であることを照らし合わせる。
2. git -C <ワークツリー> push <ssh_url> advisory/<短い名前>-<版>
3. PR の本文を、記録先など公開リポジトリの外のファイルに書き、gh pr create -R <フォークの full_name> --base <宛先ブランチ> --head advisory/<短い名前>-<版> --title "<タイトル>" --body-file <本文のファイル> で作る。対話にしないため、--title と --body-file を必ず付ける。下書きにしない（アドバイザリ画面のマージ対象にするため）。
   • タイトルは、マージ後は公開リポジトリの PR として残るので、.github/codex-pr-rules.md の「PRタイトル」に従い、日本語で中立に書く。1.2 系の PR は、先頭に [1.2] を付けて main 宛ての PR と見分ける。本文は「概要」「確認手順」にし、確認手順には観点だけを書く（詳細な手順と結果は記録先に置く）。Closes # や Issue 番号は書かない。
4. 作った PR の URL と、push したコミット（自己レビューを通ったもの。git -C <ワークツリー> rev-parse HEAD）を計画に書く。
5. PR を作った直後と、次の版へ進む前と、報告の直前（「開いている PR の照合」の 2）に、呼んでいないレビューやボットのコメントが付いていないかを、次の 3 つで確かめる（PR 全体へのコメント、レビュー、差分の行へのコメントは、それぞれ別の API でしか取れない）。どれかに 1 件でもあれば、それ以上進めずに止まる。 gh pr view <PR 番号> -R <フォークの full_name> --json comments --jq '.comments | length'（PR 全体へのコメント。一時フォークでは Issue の機能が無効のことがあり、issues/<PR 番号>/comments の API は 404 になり得るので使わない） gh api repos/<フォークの full_name>/pulls/<PR 番号>/reviews --jq 'length' gh api repos/<フォークの full_name>/pulls/<PR 番号>/comments --jq 'length'

止まる条件

runner の「止まる条件」を、次のように使う。

• そのまま使う（「Issue」は「計画」と読み替える）:
  • 「要相談」に当たる判断が出た（計画で決まっていない挙動の選択、計画の直し方と違う直し方が要る、を含む）
  • 割り当てた範囲の外を直す必要が出た。または差分が想定より大きい（目安: 変更ファイルが計画の「場所」に挙がったファイル数の 2 倍を超える）
  • php -l などの静的な確認が通らない。または検証できない
  • 自己レビューで、格上げのあとも高・中の指摘が残る
  • reviewer の前後で、作業ディレクトリの状態か HEAD が変わった
  • 計画に「本人の確認を得てから行う」と書かれた手順に来た
  • 許可確認が出て、先に進めない
• 読み替えて使う:
  • 「Issue 1 件のつもりが、ExecPlan を作るべき規模だと分かった」→ 計画の想定より大きな改修が要ると分かった
  • 「main との衝突で rebase が要る」→ 宛先ブランチとの衝突で rebase が要る
• 使わない: Issue の状態（閉じている・担当者・紐づくブランチ）、ロードマップ項目、push 後の CI、「非公開アドバイザリと重なる可能性に気付いた」

加えて、次のときも止まる。

• アドバイザリが下書きでない。フォークを作れない。フォークに宛先ブランチが無い
• 「開いている PR の照合」に当たった（計画に無い PR、同じ宛先への複数の PR、記録と違うコミット、衝突、取り直しても判定できないマージ可否）
• push 先の URL が、その GHSA-ID のフォークだと確かめられない
• 修正が、公開の Issue・PR で進んでいる作業と重なる
• 1.2 系で、修正を 1.2 系が動く PHP の下限で書けない。または直し方が main と大きく変わる
• 修正前に再現できない
• フォーク内の PR に、呼んでいないレビューやボットのコメントが付いた
• origin（公開リポジトリ）に修正ブランチやそのコミットが出たと分かった。すぐ止まって本人に返す。消すのは本人が行う（deny は削除の push も止める）

止まったときは、runner と同じ 4 項目を、公開の場ではなく計画に書いて人に返す。

確認を省く範囲

runner の「確認を省く範囲」と同じ扱いにする（runner の「実行中」には /run-advisory を含む）。このスキルの呼び出しを、その GHSA-ID についての実装・ブランチ作成・コミット・フォークの作成・フォークへの push・フォーク内の PR 作成の明示指示とみなす。表のうち、公開 PR のレビュー対応（review-agent・reviewer の GitHub への書き込み・resolved 化・/pr-sync）とロードマップの行は、このスキルでは使わない。

本人に返すもの

すべての版でフォーク内の PR を作ったら、「開いている PR の照合」の 2 を行い、次を報告して終える。マージはしない。

• フォーク内の PR の URL（版ごと）と、照合の結果（開いている PR がこれらだけで、コミットが記録と一致し、呼んでいないコメントが無く、マージできる状態であること）
• 検証の結果（修正前に再現し、修正後に再現しないこと）と、記録先
• 自己レビューの結果（指摘と対応、または問題なし）
• 本人の残り作業: PR の確認、アドバイザリ本文の更新、アドバイザリ画面からのマージ、リリース、アドバイザリの公開、CVE、告知、そのあとの片付け（下の「片付け」）

片付け

アドバイザリの公開後に、本人が頼んだセッション（このスキルを再び呼んだものを含む）が行う。ワークツリーを git worktree remove で消し、ローカルの修正ブランチを git branch -D advisory/<短い名前>-<版> で消す。修正ブランチを手元に残したままにしない（誤った push の機会を残さないため）。