create-pr

現在のブランチをプッシュし、GitHub プルリクエストを作成します。ブランチ名に JIRA ID が含まれ、チケットを取得できる場合、PR のタイトルと説明はチケットに沿ったものにします。JIRA ID がない場合、またはチケットを取得できない場合も、ブランチはプッシュします。その後、開発者が選べるように複数の PR タイトル案（またはカスタムタイトル）を提示し、PR を作成します。PR の説明には、この PR で実際に修正するすべての課題（JIRA チケット、GitHub イシューなど）のみを必ず記載します。関連はあっても対応しない項目は記載しません。

使い方：

• /create-pr — プッシュしてドラフト PR を作成
• /create-pr --no-draft — プッシュしてレビュー可能な PR を作成

手順：

1. 前提条件を確認します（GitHub — 常に実施）：

   • GitHub CLI（gh）： gh --version を実行します。見つからない場合は、次のメッセージを表示して停止します。

     ## 不足している前提条件：GitHub CLI
     
     `gh` コマンドがインストールされていません。このスキルでは、リポジトリ操作に GitHub CLI が必要です。
     
     インストール先：https://cli.github.com/
     

   • GitHub CLI の認証： gh auth status を実行します。認証されていない場合は、次のメッセージを表示して停止します。

     ## 不足している前提条件：GitHub CLI の認証
     
     GitHub CLI が認証されていません。このスキルを使用する前に、`gh auth login` を実行して認証してください。
     

2. オプションを解析します：

   • $1 が --no-draft の場合、PR はレビュー可能な状態で作成されます
   • それ以外の場合（デフォルト、引数なし）、PR はドラフトとして作成されます

3. 現在のブランチを取得し、JIRA ID を抽出します：

   • git branch --show-current を実行して、現在のブランチ名を取得します
   • パターン [A-Z][A-Z0-9]+-[0-9]+ に一致する文字列から JIRA ID を抽出します（例：PROJ-123、AB-1、MYAPP-4567）
   • JIRA ID はブランチ名のどこにあってもかまいません（例：fix/proj-123、feat/PROJ-123、PROJ-123-some-description）
   • 大文字と小文字を区別せずに一致させます。JIRA API で検索するため、抽出した ID は大文字に正規化します
   • JIRA ID が見つからなくても停止せずに続行します。プッシュ後、手順 8 のJIRA チケットなしのパスを使用します

4. JIRA チケットの詳細を取得します（手順 3 で JIRA ID が見つかった場合のみ）：

   • Atlassian CLI（acli）： acli auth status を実行して、CLI がインストール済みで認証されているか確認します。
     • コマンドが見つからない場合は、次のメッセージを表示して停止します。

       ## 不足している前提条件：Atlassian CLI
       
       ブランチ名に JIRA ID が見つかりましたが、`acli` コマンドがインストールされていません。チケットを読み込むには CLI をインストールしてください。JIRA なしで PR を作成する場合は、ブランチ名から JIRA ID を削除してください。
       
       次のコマンドでインストールします：brew tap atlassian/acli && brew install acli
       

     • 認証エラーでコマンドが失敗した場合は、次のメッセージを表示して停止します。

       ## 不足している前提条件：Atlassian CLI の認証
       
       Atlassian CLI が認証されていません。続行する前に、`acli auth login` を実行して認証するか、ブランチまたはチケットへのアクセス権を修正してください。
       

   • Atlassian CLI を使用して、JIRA ID で課題を取得します。

     acli jira workitem view <JIRA-ID> --fields summary,description,issuetype --json
     

   • コマンドが成功した場合は、summary、description、issue type（Bug、Story、Task など）を抽出します。これが手順 8 で使用するJIRA のコンテキストです
   • コマンドが失敗した場合（チケットがない、権限がない、ネットワークエラーなど）、開発者に簡潔に伝え、手順 8 のJIRA チケットなしのパスで続行します（停止しないでください）。正しい参照 URL を作成できる場合は、説明に任意で生の JIRA-ID 文字列を含めてもかまいません。作成できない場合は省略します

5. ベースブランチを特定します：

   • 現在のディレクトリに .agent ファイルがあるか確認します
   • ファイルがある場合は内容を読み、baseBranch=<value> の行を探してベースブランチを抽出します
   • AskUserQuestion を使って、開発者がベースブランチを選べるようにします：
     • .agent からベースブランチが見つかった場合：1つ目の選択肢はそのブランチに「(from .agent)」を付けたもの、2つ目の選択肢は main（異なる場合）
     • .agent ファイルがない、または baseBranch キーがない場合：1つ目の選択肢は main
     • PR のマージ先が別のベースブランチの場合、開発者は「Other」オプションから別のブランチ名を入力できます

6. ブランチをプッシュします：

   プッシュの方法は、PR がドラフトかレビュー可能な状態かによって異なります。

   ドラフト PR を作成する場合（--no-draft オプションなし）：

   • git push -u origin <branch-name> --no-verify を実行します
   • ドラフト PR のため、プッシュ前チェックはスキップできます。CI でチェックが実行され、開発者は PR をレビュー可能な状態にする前に問題に対処します
   • プッシュに失敗した場合は、エラーを表示して停止します

   レビュー可能な PR を作成する場合（--no-draft が渡された場合）：

   • git push -u origin <branch-name> を実行します

   • リモート上のブランチがすでに最新の場合は問題ありません。次のステップに進みます

   • プッシュ前フックが原因でプッシュに失敗した場合（エラー出力に husky、pre-push、フックスクリプトの出力、または対話型プロンプトなどの兆候がないか確認します）：

     a) --no-verify で回避するか確認します：

     • AskUserQuestion を使って、開発者に次のように尋ねます：

       プッシュ前フックによってプッシュがブロックされました。--no-verify で回避しますか？

     • 選択肢：はい — --no-verify でプッシュする、いいえ — プッシュ前フックを解決する

     b) 開発者が --no-verify を選択した場合：

     • git push -u origin <branch-name> --no-verify を実行します
     • 重要： --no-draft にかかわらず、PR は必ずドラフトとして作成してください。プッシュ前チェックがスキップされたため、PR をレビュー可能な状態にしてはいけません
     • このプッシュも失敗した場合は、エラーを表示して停止します

     c) 開発者がフックの解決を選択した場合：

     • 開発者が要求内容や失敗箇所を確認できるよう、プッシュ前フックの出力全体を表示します
     • フックの出力にプロンプトや質問（例：「続行しますか？ [y/n]」）が含まれている場合は、AskUserQuestion を使って開発者に選択肢を提示し、その回答を使ってフックに応答します
     • 解決後に git push -u origin <branch-name> を再実行します
     • プッシュに再度失敗した場合は、エラーを表示して停止します

   • プッシュ前フック以外の理由でプッシュに失敗した場合は、エラーを表示して停止します

7. この PR が修正または対処する課題を特定します：

   目標は、この PR が実際に修正または対処する項目だけを一覧にすることです。関連項目、依存関係、または単に言及されているだけの項目は含めません。

   a) 利用可能なすべての情報源から候補となる参照を集めます：

   • ブランチ名： ステップ 3 の JIRA ID、および GitHub issue 番号を示すヒント。例：issue-123、gh-123、123-some-description のような先頭の数字セグメント、または #123。
   • このブランチのコミットメッセージ： git log <base-branch>..HEAD --pretty=%B を実行し、出力から次を探します：
     • GitHub issue 参照：#NNN、GH-NNN、または別リポジトリへの参照 owner/repo#NNN
     • クローズキーワードを含む参照：Fixes #NNN、Closes #NNN、Resolves #NNN（大文字・小文字は問いません）
     • [A-Z][A-Z0-9]+-[0-9]+ に一致する追加の JIRA キー
   • PR タイトル（JIRA に基づく場合）： JIRA キーはすでに候補に含まれています。 b) この PR で実際に修正・対応する項目に絞り込みます：
   • PR の変更で解決または実装される項目のみを参照に含めます。以下の基準を使用します。
     • ブランチ名の主な JIRA ID（手順 3 で取得）と、ブランチ名に含まれる GitHub issue 番号 → ほぼ常にこの PR で対応するため、含めます。
     • このブランチのコミットで、クローズキーワード（Fixes、Closes、Resolves）とともに記載された参照 → 含めます。
     • コミットメッセージ内の単独の #NNN への言及 → コミット本文に、その issue を PR で解決することが明確に示されている場合のみ含めます。それ以外は関連事項として扱い、除外します。
     • コミット内で言及されているものの、明示的に「修正／対応する」意図が示されていない追加の JIRA キー → 関連情報として除外します。
   • 候補が修正対象なのか、単なる関連事項なのか判断できない場合は、AskUserQuestion を使って開発者に確認します。曖昧な候補をそれぞれ列挙し、選択肢として 「この PR で修正する — 含める」 と 「単なる関連事項 — 除外する」 を提示します。曖昧な候補がなければ、確認は行いません。
   • 最終リストから重複を除きます。

   c) PR 本文用に参照を整形します：

   • JIRA チケット： [PROJ-123](https://<site>.atlassian.net/browse/PROJ-123) の後に、分かっている場合はチケットの要約を続けます（例： — 一括エクスポートを追加）。acli での検索時に確認したものと同じ <site> ホストを使用します。
   • GitHub issue（同一リポジトリ）： GitHub がマージ時に自動クローズできるよう、クローズキーワードを使います — Fixes #123（バグには Fixes、それ以外には Closes を推奨します。どちらも自動クローズに使用できます）。
   • GitHub issue（別リポジトリ）： Fixes owner/repo#123。

   手順 8 で使うため、結果を保持します。絞り込み後のリストが空の場合、## Fixes セクションは作成しません。

8. プルリクエストを作成します：

   手順 4 で JIRA の情報を取得できている場合：

   • issue の種類に応じたコミットプレフィックスの規則に従い、JIRA チケットの要約をもとに簡潔なタイトルを作成します。
     • バグ → fix: <summary>（例：fix: resolve null pointer in user lookup）
     • それ以外の種類 → feat: <summary>（例：feat: add bulk export for reports）
     • 要約部分は、小文字で、命令形かつ簡潔にします。
   • PR の説明を作成します。
     • ## Summary — JIRA チケットの説明に基づく簡潔な説明。
     • ## Fixes — 手順 7 で確認した参照をすべて、1 行に 1 つずつ箇条書きで記載します。ブランチの JIRA チケットは必ず最初の箇条書きに含めます。手順 7 の結果が空の場合に限り、このセクション全体を省略します（JIRA の情報がある場合はまれです）。
   • そのタイトルと本文を指定して gh pr create を実行します（共通のフラグについては以下を参照）。 JIRA のコンテキストがない場合（ブランチに JIRA ID がない、または手順 4 で取得に失敗した場合）：
   • 手がかりを集めます。ブランチ名（リモートプレフィックスを除く）と、最新のコミットの件名（例：git log -1 --pretty=%s）。必要に応じて、コミット本文の 1 行目も確認します
   • gh pr create を実行する前に、開発者がPR タイトルを選択できるように AskUserQuestion を使用します。次のような、異なる選択肢を少なくとも 3 つ提示します。
     • ブランチのスラッグから作成した一般的な形式のタイトル（feat:、fix:、chore: の後に続く小文字のフレーズを命令形で記述します。ブランチがバグ修正を示している場合は fix: を選び、そうでなければ feat: を優先します。ただし、変更内容が明らかに雑務やドキュメントのみの場合は chore: を選びます）
     • 最新のコミットの件名に基づくタイトル（必要に応じて一般的な形式に調整します）
     • より短い表現や別の言い回し
     • ツールが対応している場合は、開発者が自由記述でカスタムタイトルを入力するための選択肢も提示します
   • 開発者がタイトルを選んだら、PR の説明を作成します。
     • ## Summary — ブランチ名と最近のコミットメッセージから簡潔に説明します。JIRA ID が判明しているものの、チケットを読み込めなかった場合は、対象のチケットキーを記載する文を追加してもかまいません。
     • ## Fixes — 手順 7 で確認された参照をすべて、1 行につき 1 つずつ箇条書きで記載します。手順 7 で該当するものがなかった場合は、このセクション全体を省略します。
   • 選択されたタイトルと本文を指定して gh pr create を実行します

   gh pr create の共通動作：

   • --no-draft が指定されていない限り、--draft フラグを使用します。ただし、手順 6 の push で --no-verify を使用した場合は例外です。この場合は --no-draft オプションの有無にかかわらず、必ず --draft を使用し、開発者に次のメッセージを伝えます。

     ⚠️ プッシュ前チェックがスキップされたため、PR はドラフトとして作成されました（--no-verify）。
     すべてのチェックに合格したことを確認してから、レビュー可能な状態にしてください。
     

   • 手順 5 で特定したブランチを --base <base-branch> で指定します
   • HEREDOC を使用して本文を渡します
   • PR の作成に失敗した場合は、エラーを表示して停止します

9. 成功メッセージを表示します。

成功した内容を、関連情報をすべて含めて要約します。## Fixes セクションに記載した参照をすべて列挙するか、セクションを省略した場合は「なし」と記載します。

## PR Created

- Fixes: PROJ-123, #45 (or "none")
- Branch: my-branch → main
- PR: https://github.com/org/repo/pull/42 (draft)
- Title: <chosen title>