antfu-create-pr

プルリクエストの作成

本文だけでレビュアーが内容を理解できるプルリクエストを作成します。変更したファイルの一覧ではなく、動作がどう変わるのか、その理由を説明します。変更の規模に見合った本文にしてください。1 行の修正なら数文、複数モジュールにまたがる機能なら表や図を使います。

ワークフロー

1. リポジトリを確認します。git status、現在のブランチ、リモート、デフォルトブランチ、.github/PULL_REQUEST_TEMPLATE*、およびプルリクエストのルールが記載された AGENTS.md / CONTRIBUTING.md を調べます。
2. ターゲットブランチとのマージベースを算出し、プルリクエストに含める正確な base...head の範囲を記録します。ブランチが未マージの別ブランチに積み重なっている場合は、そのブランチをターゲットにし、このプルリクエスト独自の変更だけを説明します。
3. 差分全体を読みます。実行時のコードと、生成ファイル、ロックファイル、スナップショットを分けて確認します。変更されたコードのエントリーポイント、呼び出し元、外部との境界をたどり、アーキテクチャに関する説明をファイルパスやシンボルで裏付けます。
4. プルリクエストを分類します（feature、fix、refactor、chore、docs）。任意の本文セクションのうち、追加する価値があるものを判断します。pr-body を参照してください。
5. 変更箇所に応じたチェック（対象を絞ったテスト、型チェック、Lint）を実行します。正確なコマンドと結果を記録します。
6. 差分にユーザーが目にする UI の変更が含まれる場合は、変更前と変更後の証拠を記録します。visual-evidence を参照してください。
7. コミット履歴を確認し、原子的な Conventional Commits になるよう整えます。Commits を参照してください。
8. 本文を一時ファイルに書き込みます。ブランチをプッシュし、gh pr create --title ... --body-file ... でプルリクエストを作成します（スクリーンショットごとに --attach を追加します）。チェックの実行中、またはレビュー可能な状態に達していない場合は --draft を使います。
9. 作成したプルリクエストを開き、タイトル、ベース、ヘッド、レンダリングされた表、図、画像を確認します。
10. レビューコメントに対応します。確認済みの問題をそれぞれ修正し、対象を絞ったチェックを実行してプッシュし、根拠を添えて返信したうえで、スレッドを解決します。

タイトル

リポジトリでのコミットメッセージの書き方に合わせて、Conventional Commits を使用します。

feat(scope): add retry to upload client
fix(scope): avoid double submit on enter
refactor: extract diff parsing from cli
chore(deps): update vite to v8
docs: clarify worktree setup

• 小文字で始め、命令形にし、末尾にピリオドを付けず、約 70 文字以内にします。
• スコープには、リポジトリで既に使われているパッケージ、モジュール、機能の名前を使います。リポジトリ全体に関わる変更の場合は省略します。
• スカッシュマージを使うリポジトリでは、タイトルがコミットメッセージになります。履歴に残したいコミットメッセージとして記述します。

コミット

各コミットでは論理的な変更を 1 つだけ行い、Conventional Commits のメッセージを使います。レビュアーが git log --oneline を読めば変更の経緯が分かり、コミットごとにレビューできる状態にします。

# Good: each commit is self-contained
feat(api): add task creation endpoint with validation
feat(ui): add task creation form component
feat(ui): connect form to api and add loading state
test(tasks): cover task creation (unit + integration)

# Bad: everything mixed together
feat: add task feature, fix sidebar, update deps, refactor utils

• 無関係な修正、依存関係の更新、ついでのリファクタリングはブランチに含めず、別のプルリクエストを作成します。
• プッシュする前に履歴を確認し、各コミットが単独で成立してビルドできるよう、ローカルのコミットを分割またはスカッシュします（git rebase -i <base>）。
• すでにプッシュされてレビュー中のコミットは書き換えず、新しいコミットを追加します。

本文

すべてのプルリクエストで必須です。

• ## Summary：まず問題または実現する機能を説明し、次に変更内容とそのアプローチを選んだ理由を記述します。積み重ねたプルリクエストの場合は、その旨と対象ブランチを明記します。
• 関連するイシューへのリンク：GitHub のリンクと自動クローズのため、closes #123 / fixes #123 / refs #123 を記載します。
• ## Verification：実行したコマンドとその結果を正確に記載し、未検証の項目があれば明記します。

任意。レビュアーの役に立つ場合に限ります。

• ## Change map：モジュール、変更前、変更後、理由の表。複数のモジュールや所有範囲にまたがる変更で使います。単なるファイル一覧は避けます。
• ## Architecture and behavior：処理順序、非同期処理、状態遷移に変更がある場合は、Mermaid のフロー図、シーケンス図、または状態図を使います。修正の場合は、同じ抽象度で変更前と変更後の図を並べます。
• ## Boundaries and risks：不変条件、障害モード、保護策、根拠の表。実際の障害モード、移行、外部への影響がある場合に使います。
• ## Visual changes：UI の変更がある場合は、変更前と変更後の画像を表にまとめます。
• ## Rollout and follow-up：移行、機能フラグ、既知の不足点を記載します。不足点がマージを妨げるかどうかも明記します。

リポジトリにプルリクエストテンプレートがある場合は、その見出しを維持して内容を記入します。テンプレートに余地がある場合に限り、上記のセクションを追加します。

ルール

• 検証済みの内容、仮定している内容、未検証の内容を明記してください。根拠を示さずに「安全」「修正済み」「後方互換性がある」と書かないでください。
• CI が成功しても、CI で実行されるチェックの範囲しか証明されません。対象を絞ったテストで証明できるのは、そのテストがカバーする動作だけです。
• 親ブランチから引き継いだ変更を、この PR の変更として説明しないでください。
• 通常のハイフンを使ってください。em ダッシュ（U+2014）や en ダッシュ（U+2013）は使わないでください。
• 内容のない文言（「この PR は〜を目指します」「包括的」「堅牢」など）は使わないでください。事実から書き始めてください。
• トークン、シークレット、ユーザーレコード、完全なペイロードを本文に貼り付けないでください。
• スクリーンショットなど、PR 専用の成果物をリポジトリにコミットしないでください。gh --attach で添付してください。
• PR の作成にエージェントの支援を受けた場合は、本文の末尾にその旨を 1 行で記載してください。