PR クリエーター

ベストプラクティスに従い、レビュアーフレンドリーでよく構成されたプルリクエストを作成します。

重要: このスキルは常に PR の作成をもたらさなければなりません。途中で停止しないでください。別のコマンドを実行するようユーザーに指示しないでください。前提条件（コミット、ブランチ作成、プッシュ）をすべてインラインで処理し、gh pr create に進めてください。

---

ワークフロー

ステップ 1: プリフライトチェック

その他すべての前に、これらのチェックを実行します:

1. GitHub CLI 認証を確認 — gh api user --jq '.login' を実行して CLI が認証されていることを確認します。これが失敗する場合、ユーザーに gh auth login を実行するよう指示して停止します。
2. ベースブランチを確認 — デフォルトは main です。ユーザーが異なるベースを指定する場合はそれを使用します。$BASE_BRANCH としてキャプチャします。

ステップ 2: コミットされていない変更をコミット

git status を実行してコミットされていない変更がないか確認します。コミットされていない変更がある場合は、別のスキルに委譲せず、ユーザーに先にコミットするよう指示せず、直接 コミットします。

1. 変更をステージング — 関連する変更/未追跡ファイルに対して git add <files> を実行します。.env または gitignore ファイルをステージングしないでください。
2. リント とフォーマット — Python ファイルがステージングされている場合は、以下を実行します:

   ruff check --fix <files> && ruff format <files>
   

   変更されたファイルを再度ステージングします。
3. コミット — ステージングされた diff に基づいて従来のコミットメッセージを作成します:

   git commit -m "<type>: <description>"
   

   プリコミットフックが ファイルを変更した場合は、git add -u で再度ステージングして再試行します（最大 3 回まで）。

ステップ 3: フィーチャーブランチの確認

1. 現在のブランチを確認 — git branch --show-current を実行します。
2. $BASE_BRANCH にある場合、フィーチャーブランチを作成します:
   • コミット/変更を分析して、わかりやすい名前を選択します（例: feat/add-auth、fix/login-bug）
   • git checkout -b <branch-name> を実行します
3. 異なるブランチにある場合、ブランチに $BASE_BRANCH と比較して PR に値するコミットがあるか確認します:
   • git log $BASE_BRANCH..HEAD --oneline を実行します
   • コミットがある場合は、現在のブランチをそのまま使用します
   • コミットがない場合（ブランチがベースと同じポイントにある）、何か問題が発生しています — 調査して修正します

ステップ 4: ベースブランチと同期

1. 最新情報を取得 — git fetch origin $BASE_BRANCH を実行します
2. 分岐を確認 — git log HEAD..origin/$BASE_BRANCH --oneline を実行します
3. 必要に応じてリベース — ベースブランチに新しいコミットがある場合: a. git rebase origin/$BASE_BRANCH を実行します b. コンフリクトが発生した場合は、ユーザーに表示します — 両側を表示して、どちらを保持するか尋ねます。サイレントに解決しないでください。 c. 解決後、git add <file> と git rebase --continue を実行します

ステップ 5: プッシュ

ブランチをリモートにプッシュします:

git push -u origin HEAD

プッシュが拒否された場合（例: リベース後の分岐した履歴）、git push --force-with-lease -u origin HEAD を使用します。

ステップ 6: 変更を分析し PR ドラフトを作成

1. 分析 — これらを並列に実行します:
   • git log $BASE_BRANCH..HEAD --oneline — すべてのコミット
   • git diff $BASE_BRANCH...HEAD --stat — ファイル変更の概要
   • git diff $BASE_BRANCH...HEAD — 完全な diff
2. PR サイズを確認 — 500 行以上変更されている場合は、ユーザーに警告しますが続行します。
3. タイトルのドラフト — 70 文字以下、従来のプリフィックス（feat:、fix:、refactor:、docs:、chore:）。
4. このテンプレートを使用してボディのドラフトを作成します:

## Summary
<何が変更され、なぜ変更されたかを説明する 1 ～ 5 個の箇条書き>

## Changes
<何が変更されたかのカテゴリー化されたリスト — 領域/関心事でグループ化>

## Diagrams
<オプション — ワークフロー またはアーキテクチャ変更を視覚的に明確にする場合は Mermaid ダイアグラムを含めます>

## Test Plan
<変更がどのように検証されたか — 手動テストステップ、実行された自動テスト、curl コマンドなど>

ガイドライン:

• 「何」だけでなく「なぜ」を説明します
• WIP PR の場合は、[WIP] プリフィックスの代わりに --draft フラグを使用します
• ワークフロー またはアーキテクチャを明確にする場合は Mermaid ダイアグラムを含めます
• 「Generated with Claude Code」フッターやボット属性を含めないでください
• Co-Authored-By 行を含めないでください

ステップ 7: PR を作成

ボディを一時ファイルに書き込んで PR を作成します:

cat > /tmp/pr_body.md <<'EOF'
## Summary
...

## Changes
...

## Test Plan
...
EOF
gh pr create --title "the pr title" --base $BASE_BRANCH --body-file /tmp/pr_body.md

オプションフラグ:

• WIP/ドラフト: --draft を追加します
• レビュアー: --reviewer <handle> を追加します
• アサイニー: --assignee <handle> を追加します

追加しないでください:

• --author フラグ（gh は認証されたユーザーを自動的に使用します）
• Co-Authored-By トレーラー
• 「Generated with Claude Code」フッター

ステップ 8: レポート

• PR URL を返すので、ユーザーがレビューできます
• gh pr create が失敗した場合は、エラーを診断し、修正を加えて再試行します

---

ベストプラクティス

コミット履歴: コミット履歴がまとまりがない場合は、PR 作成前にリベースしてクリーンアップすることを提案します。

フィードバックリクエスト: ユーザーが特定のフィードバックを望むことを言及した場合は、ボディに「Feedback Requested」セクションを追加します。

スクリーンショット: フロントエンドの変更の場合は、ユーザーに作成後 PR にスクリーンショットまたは録画を追加するよう指示します。