open-pr

ブランチをプッシュし、AI マーク付きの PR を作成して、変更をレビューし、結果を報告します。マージ、CI の事前チェック、クリーンアップは /merge-pr で行います。ブランチが GitHub スタックに属する場合、base は下位ブランチを指し、この階層をスタックに追加します。

1. ブランチと base の確認

1. ブランチには引数の最初の項目を使用します。引数がない場合は git rev-parse --abbrev-ref HEAD を実行します。
2. デフォルトブランチを特定します。git remote show origin で HEAD ブランチを取得します。問い合わせに失敗した場合は、リポジトリに存在する main / master を使用します。
3. base を決定します（このブランチがスタックの階層である場合は下位ブランチ、それ以外はデフォルトブランチです）。
   • 引数に下位ブランチが指定されている場合は、それを base にします。
   • それ以外の場合、現在のブランチに既存の PR があるか確認します：gh pr list --head <branch> --json baseRefName --jq '.[0].baseRefName'。値があり、デフォルトブランチでない場合は、それを base にします。
   • それ以外の場合は、デフォルトブランチを base にします。
4. 現在のブランチがデフォルトブランチの場合、GitHub remote がない場合、または git log <base>..<branch> --oneline が空の場合は、停止して理由を説明します。
5. base がデフォルトブランチでない場合（このブランチがスタックの階層である場合）：
   • 下位ブランチに open PR が必要です（gh pr list --head <base> --json number,state --jq '.[0]'）。ない場合は停止し、先に下位ブランチで /open-pr を実行するようユーザーに伝えます。gh stack link は PR のない下位ブランチに自動で draft PR を作成しますが、この目的には使用しません。
   • gh stack --version が失敗した場合は停止し、gh extension install github/gh-stack を実行するようユーザーに依頼します。チェーン PR をスタックに追加しないと、上位 PR の CI とブランチルールがスタックの最下層ブランチに基づいて適用されません。
   • gh stack view から base を逆算しないでください。piw の worktree からは .git/gh-stack を読み取れません（追跡ファイルはメインリポジトリの git ディレクトリにあります）。そのため、必ずスタックの一部ではないというエラーになります。

2. プッシュして PR を作成

1. git push origin <branch> を実行します。
2. 既存の PR を確認します：

gh pr list --head <branch> --json url,number --jq '.[0]'

3. 既存の PR がある場合は、その URL と番号を再利用し、タイトルは変更しません。ない場合：
   • git log <base>..<branch> --pretty=%s から関連する #N を探します。タイトルは [AI Generated][<タイプ>] <説明> とします。タイプには大文字のラベル（[FIX]、[DOCS] など）を使用し、説明には最初の commit message から type(scope): のプレフィックスを取り除いた部分を使用します。
   • 本文を作成します。関連 issue、変更概要、テストコマンドとその結果を記載します。ブランチに複数の commit がある場合、変更概要にはすべての commit を含めます。関連 issue がない場合は、関連 issue がないことを明記します。
   • gh pr create --base <base> --head <branch> --title "<タイトル>" --body "<本文>" を使用して作成します。
4. base がデフォルトブランチでない場合、この階層をスタックに追加します（新しい PR と既存の PR の再利用のどちらでも実行します）。gh stack link は自動でブランチをプッシュし、チェーン全体を指定する必要があります。
   1. 下位 PR がすでにスタックにある場合は、<owner>/<repo>（gh repo view --json nameWithOwner --jq .nameWithOwner）を使用してスタックを読み取ります：

gh api /repos/<owner>/<repo>/pulls/<下层PR号> --jq '.stack.number // empty'
gh api /repos/<owner>/<repo>/stacks/<栈号> --jq '.base.ref, ([.pull_requests[].head.ref] | join(" "))'

1 行目にスタック番号が表示されます（空の場合、下位ブランチはまだスタックに追加されていません）。2 行目には trunk と、最下層から上位へ並んだブランチのチェーンが表示されます。現在のブランチがチェーンにない場合は、末尾に追加します。 2. 2 階層だけの場合、チェーンは <下位ブランチ> <ブランチ> となり、trunk には下位 PR の baseRefName を使用します。 3. gh stack link --base <trunk> <チェーン…> を実行します。階層が不足していると Cannot update stack: this would remove #N from the stack というエラーになるため、エラーが出たら停止し、自分でチェーンを組み立てないでください。 4. 再確認します：gh api /repos/<owner>/<repo>/pulls/<PR番号> --jq '.stack' で number、position、size が表示される必要があります。 5. PR 自体を Project に追加し、Status を In review に設定します。github-project skill の references/sync-discipline.md に従って実行し、失敗時の対応も同ファイルの表に従います。その後、PR URL を報告します。

gh にログインしていない場合は、ユーザーに gh auth login の実行を促します。認証方法を推測したり、別の方法で代用したりしないでください。

3. レビュー

今回のセッションで同じブランチをレビュー済みで、その後に新しい commit がない場合は、既存のレビュー結果を再利用します。それ以外の場合は、git merge-base <base> <branch> を固定点として code-review skill を呼び出します。base が下位ブランチの場合、この固定点は下位ブランチの tip となり、レビュー対象はこの階層の diff になります。

セキュリティ脆弱性、データ損失やクラッシュのリスク、タスク要件の欠落、スコープの拡大、誤った実装をブロッカーとして扱います。スタイルや保守性に関する提案はブロッカーではありません。

• ブロッカーがある場合：ブロッカーと、ブロッカーではない提案をそれぞれ出典別に列挙し、修正を待つため停止します。
• レビューの実行に失敗した場合：エラーを報告し、レビューをスキップするかユーザーに確認します。明確な同意があった場合のみ続行します。
• ブロッカーがない場合：レビュー結果を報告します。

4. 報告

ブランチのプッシュ完了、PR URL、レビュー結果、PR の Project ステータスを報告します。スタックに追加した場合は、スタック番号と階層（stack #<number> 第 <position>/<size> 層）も報告します。CI とマージ可能性は、マージ前に /merge-pr で事前チェックします。次の手順として、ユーザーに /merge-pr の実行を促します。

境界

状況	対応
ユーザーが PR の作成だけを求めている	PR を作成して URL を報告したら停止し、レビューは行いません
レビューでブロッカーが見つかった	修正を待つため停止します。修正後、この skill を再実行して再提出・プッシュ・レビューを行います
gh pr create が失敗した	エラーと原因を報告し、代替操作は行いません
gh stack 拡張がインストールされていない	停止し、ユーザーに gh extension install github/gh-stack を依頼します
下位ブランチに open PR がない	停止し、先に下位ブランチで /open-pr を実行するよう促します
gh stack link が失敗した	エラーと原因を報告します。自分でチェーンを組み立てたり、gh stack submit（独自のタイトルを付けて新しい draft PR を作成します）に切り替えたりしません
worktree で gh stack view がスタックの一部ではないというエラーになる	想定どおりの動作です（追跡ファイルを読み取れません）。base は引数または既存 PR の baseRefName で判定します