create-pr

React Router の PR を作成する

完了した React Router の作業について、プルリクエストの引き継ぎを作成します。ユーザーが明示的に ready な PR や別のベースブランチを要求しない限り、デフォルトでは main を対象としたドラフト PR にします。

前提条件

• git status --short --branch と git branch --show-current を確認します。
• 無関係なダーティファイルを含めないでください。無関係な変更が存在する場合は、それらをステージせずに残し、言及します。
• ワークツリーが detached 状態の場合は、コミットする前に現在の HEAD からブランチを作成します。ユーザーが要求したブランチ名、リポジトリの既存の慣習、またはより強い慣習がない場合は <author>/<semantic-name> を使用します。
• すでに適切な名前付きブランチにいる場合は、それを使用します。
• 適切な自動カバレッジが存在するか、追加されたことを確認します。PR 本文には、CI でカバーされる定型的なチェックを記載しないでください。
• ユーザー向けの機能を更新している場合は、適切なパッケージに packages/<package>/.changes/ 配下の変更ファイルがあるか確認します。これは、ドキュメントのみ、GitHub Actions/ワークフローのみ、または依存関係メンテナンスの PR では、依存関係の変更自体がユーザー向けの影響を持たない限り必要ありません。

コンテキスト

• 何が変更されたか、なぜ変更されたか、誰に影響するかを把握します。
• 関連する issue、discussion、PR を見つけ、関連する場合はリンクを含めます。
• 変更が小さい場合は、広範なリポジトリの調査よりも git diff --stat と焦点を絞った git diff を優先します。
• ユーザーがレポート、issue、discussion、または関連する PR を提供した場合は、それを主要なコンテキストソースとして扱います。
• 新機能の作業では、簡潔な使用例スニペットを含めます。その機能が古いアプローチを置き換えたり改善したりする場合は、レビュアーの役に立つときに before/after の例を含めます。

コミットとプッシュ

1. 必要に応じて git diff --stat と焦点を絞った git diff で差分を確認します。
2. 意図したファイルのみをステージします。
3. 簡潔な命令形の件名でコミットします。
4. PR を作成する前にブランチをプッシュします。

PR の作成

PR 本文を一時ファイルに保存し、次を指定して gh pr create を使用します:

gh pr create --draft --base main --head <branch> --title "<title>" --body-file <file>

• --draft は、ユーザーが明示的に ready な PR を要求した場合にのみ省略します。
• --base は、ユーザーが明示的に別のベースブランチを要求した場合にのみ変更します。
• シェルのクォートはシンプルに保ちます。本文にバッククォート、引用符、または複数の段落が含まれる場合は、本文ファイルを優先します。
• 既知の場合は issue/discussion のリンクを含めます。PR がクローズすべきバグ修正には Closes #NNNN を使用し、クローズの意味が適切でない RFC/discussion には Implements #NNNN または単純なリンクを使用します。
• テストに関する注記は、手動チェック、通常とは異なる検証、スキップされた非 CI チェック、またはレビュアーが知っておくべき失敗についてのみ含めます。
• gh pr create が失敗した場合は、可能であればブランチをプッシュしたままにし、ユーザーにすぐ開ける compare URL と準備済みのタイトルおよび本文を提供します。

推奨される PR 本文の形式:

This change ...

- Optional extra detail when useful.

```tsx
// Optional feature usage example
```

// Optional before/after example

Testing

• 任意の手動または非 CI の検証に関する注記のみ。

- Do not use a `## Summary` heading. Start with one or two short sentences explaining what the change accomplishes.
- Add bullets after the opening only when more detail is useful.
- Include usage examples for new features, and before/after examples for replacements or improvements, when they help reviewers understand the change.
- Add `**Testing**` with bullets below the description only when there are manual checks, unusual verification steps, skipped non-CI checks, or failures reviewers should know about. Omit it for routine automated coverage.

## Testing Notes

- Do not list linting, typechecking, unit test, or integration test commands in the PR body, even if they were run locally. CI runs these automatically.
- Do not say that CI will run routine linting, typechecking, unit tests, or integration tests. That is assumed for every PR.
- Do not add manual testing instructions by default.
- Add manual testing instructions only when necessary, such as visual/UI behavior that needs human review, environment-specific behavior not covered by CI, release/publish dry-run steps, external service integration, or a reproduction that cannot be expressed reliably in automated tests.
- When manual testing is necessary, keep the instructions minimal and directly tied to the uncovered risk.

## Labels

Apply labels after the PR exists. Rely on the stable labels listed in this skill for normal PRs.

Apply labels with:

```sh
gh pr edit <number-or-url> --add-label "<label>"

指定したラベルが無効または存在しないために gh pr edit --add-label が失敗した場合は、次を実行します:

gh label list --limit 200

その後、ライブリストから正しいラベルを選択し、このスキルをその場で更新して、安定したラベルのガイダンスが最新の状態に保たれるようにします。実際のラベルのみを使用してください。適切なラベルが存在しない場合は、でっち上げずに、不足しているラベルについて言及します。

パッケージラベル

変更されたパッケージパスに基づいて、該当するすべての pkg:* ラベルを追加します:

変更されたパス	ラベル
packages/react-router/	pkg:react-router
packages/react-router-dev/	pkg:@react-router/dev
packages/create-react-router/	pkg:create-react-router
packages/react-router-architect/	pkg:@react-router/architect
packages/react-router-cloudflare/	pkg:@react-router/cloudflare
packages/react-router-node/	pkg:@react-router/node
packages/react-router-serve/	pkg:@react-router/serve
packages/react-router-express/	pkg:@react-router/express
packages/react-router-fs-routes/	pkg:@react-router/fs-routes
packages/react-router-remix-routes-option-adapter/	pkg:@react-router/remix-routes-option-adapter

パッケージパスが不明な場合は、その package.json の name を確認し、そのラベルが存在する場合は pkg:<name> を使用してください。変更が生成された成果物や統合テストのみに影響する場合は、テスト対象のランタイム/ツール領域からパッケージラベルを推測してください。たとえば、Vite プラグインやプリレンダーの統合テストのカバレッジは、通常 pkg:@react-router/dev に対応します。

機能ラベル

変更される動作領域に該当する feat:* ラベルを追加します。一般的なラベルには次のものがあります。

動作領域	ラベル
コアナビゲーション、ローダー/アクション、フェッチャー、リダイレクト、マッチング、ルーター状態	feat:router
ルート設定 API と routes.ts	feat:routes.ts
Vite プラグインとビルドパイプラインの動作	feat:vite
SPA モード	feat:spa-mode
プリレンダリング	feat:prerender
遅延ルート検出	feat:lazy-route-discovery
ハイドレーションとハイドレーションフォールバックの動作	feat:hydration
ビュー遷移 API	feat:view-transitions
ミドルウェアの動作	feat:middleware
分割ルートモジュールの動作	feat:split-route-modules
ストリーミングの動作	feat:streaming
CSS の処理	feat:css
Windows 固有の修正	feat:windows
RSC データまたは RSC フレームワークの動作	feat:rsc
パスマッチングのセマンティクス	feat:path-matching
シングルフェッチの動作	feat:single-fetch
型、型生成、TypeScript の動作	feat:typescript

diff が本当に複数の領域にまたがる場合は、複数の機能ラベルを付けて問題ありません。存在する中で最も具体的なラベルを優先してください。

パッケージ以外のラベル

パッケージラベルや機能ラベルを必要としない PR もあります。

• ドキュメントのみの変更には docs を追加します。
• .github/workflows/ または Actions インフラストラクチャの変更には github-actions を追加します。
• 依存関係またはロックファイルのみのメンテナンスには dependencies を追加します。
• v6、v7、v8 などのバージョンラベルは、PR が意図的にそのリリースラインを対象としている場合、またはユーザーが要求した場合にのみ追加します。

最終レポート

報告内容:

• ブランチ名。
• コミットハッシュ。
• PR の URL と、それがドラフトか準備完了か。
• ベースブランチ。
• 適用されたラベル。
• 実施またはスキップされた検証。