jackin-refresh-pr

jackin-refresh-pr

オープン中の PR のタイトルと本文を最新の差分に合わせます。本文には、ブランチを作成した時点での内容ではなく、ブランチが現在実際に提供する内容を記載します。本文にずれが生じた場合に実行してください。たとえば、コミットが追加された、スコープが拡大または変更された、PR が現在は機能を提供しているのにタイトルが docs: のままになっている場合です。

jackin-create-pr と cargo xtask pr body を共有します。Verify-locally ブロックの選択はバイナリが行い、説明文はエージェントが作成します。これは、jackin-merge-pr がステップ 5 で行う整合処理を、意図的に必要なときに実行するものです。

使用する場合

• オペレーターから PR の本文やタイトルの更新を求められた場合（「本文が古い」「PR を更新して」など）。
• 現時点で PR を確認するレビュー担当者に誤解を与える内容になっている場合。

使用しない場合

• 新しい PR を作成する場合 → jackin-create-pr。
• マージ可能な状態か確認する段階の場合 → jackin-merge-pr のステップ 5 で最終確認として整合処理が行われるため、二重に更新しないでください。
• イテレーションのコミットごとに更新する場合 — 更新はオペレーターの指示で実行するものであり、コミットを契機に実行するものではありません（.github/AGENTS.md の PR 本文更新ポリシー）。自動更新すると本文が頻繁に変わり、注意が無駄に消費されます。

引数

• PR — PR 番号（現在のブランチに対応する PR がデフォルトです）。

プロセス

1. PR を特定します。 gh pr view <PR> --json number,title,body,headRefName,baseRefName を実行します。現在のタイトルと本文を保持します。

2. 最新の状態を取得します。 git fetch origin <baseRefName> を実行してから、cargo xtask pr body --base origin/<baseRefName> > /tmp/pr-body.fresh.md を実行します。標準エラー出力にある 変更ダイジェスト（rust/docs/capsule/schema のカテゴリとファイル一覧）を読みます。これが現在の変更内容です。標準出力にある 最新のスケルトン を読みます。## Verify locally の下にある ### ブロックのセットが、現在の差分で必要な選択内容です。

3. Verify-locally ブロックを調整します。 最新のスケルトンのブロックセットと現在の本文を比較します。

   • 最新の選択に含まれているものの、本文にない場合 → 追加します（テンプレートの構造を使い、この PR 向けに記入します）。
   • 本文にあるものの、最新の選択から外れている場合 → 削除します。
   • 両方にある場合 → オペレーターが記入した内容をそのまま保持します。Checkout ブロックには実際の PR 番号が入り、Rust テストには対象を絞るフィルターが入り、User smoke には PR 固有の手順が入ります。保持するブロックをプレースホルダーで上書きしてはいけません。

   完了条件：## Verify locally の下にあるすべての ### ブロックが、現在の差分に対するバイナリの選択と一致し、保持するブロックには作成者が記入した内容がすべて残っています。

4. 説明文を調整します。 gh pr diff <PR> と git log origin/<baseRefName>..HEAD --oneline を読みます。本文に含まれる説明文の各セクション（Summary、What ships、Behavior changes、What this addresses、Hard rule、Not included、Migration notes）について、次のように対応します。

   • 現在の変更内容と一致している場合 → そのままにします。不要な変更を避け、正しい内容を書き直さないでください。
   • 内容にずれがある場合 → 現在の差分に合うように書き直します。そのセクションの根拠となる変更がなくなった場合 → 削除します。新しい成果があり、それを記載するセクションがない場合 → 追加します。

   完了条件：すべての説明文のセクションが現在の差分を反映し、ファイルごとに差分を繰り返して説明するセクションがありません。

5. タイトルを調整します。 Conventional Commits のタイトルが、現在の変更範囲を引き続き表しているか確認します。PR の範囲が広がった場合（たとえば、fix(typo) が現在は機能を追加している場合や、docs: の変更に現在はコードが含まれている場合）は、gh pr edit <PR> --title を使ってタイプとスコープを更新します。オペレーターが気付いていない可能性があるほど範囲の変更が大きい場合に限り、確認を求めるため作業を一時停止します（.github/AGENTS.md のタイトル／説明のルール）。

6. 本文を書き込みます。 保持した説明文、書き直した説明文、調整済みのブロックを組み合わせ、本文を一時ファイルに作成してから、gh pr edit <PR> --body-file /tmp/pr-body.md を実行します。コードフェンスや $ が正しく扱われるように、--body "..." は使わないでください。.github/AGENTS.md の本文作成ルールで --body-file が必須とされています。

7. 表示を確認します。 gh pr view <PR> --json body -q .body を実行し、手作業による編集で余計な \` や \$ が入っていないことを確認します。問題があれば、--body-file を使って修正します。

8. 報告します。 追加／削除したブロック、書き直した説明文のセクション、変更したタイトル（旧 → 新）とその理由を伝えます。更新の許可を求めてはいけません。オペレーターから更新を依頼されています。範囲が変わるタイトル変更にオペレーターが異議を唱える可能性がある場合は、確定する前にその点を伝えてください。

よくある間違い

• スケルトンから本文を再生成して、オペレーターが書いた説明文を失うこと。スケルトンにはプレースホルダーが含まれています。更新では作成者が記入した内容を保持し、ずれた部分だけを書き直します。
• すでに正確な説明文を書き直すこと。差分が不必要に増え、注意を無駄にします。
• cargo xtask pr body ではなく、Verify-locally ブロックを手作業で選ぶこと。バイナリが選択の基準です。
• --body-file ではなく gh pr edit --body "..." を使うこと。コードフェンスや $ が正しく扱われません。
• 表示確認を忘れること。壊れた \` や \$ が気付かれないまま反映されます。
• コミットのたびに更新すること。オペレーター起点のポリシーに反します。

ツール

cargo xtask pr body --base origin/<base>（jackin❯ repo）は、変更ダイジェストを標準エラー出力に、Verify-locally ブロックで絞り込んだスケルトンを標準出力に出力します。jackin-create-pr と共有されています。ブロックの選択はバイナリが担当し、説明文の調整はエージェントが担当します。PR を更新する xtask サブコマンドはありません。このスキルは pr body（選択）と gh pr edit（書き込み）を連携させます。