create-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create React Router PR

创建 React Router PR

Create the pull request handoff for completed React Router work. Default to a draft PR targeting

main

unless the user explicitly asks for a ready PR or a different base branch.

为已完成的 React Router 工作创建拉取请求交接。默认创建指向

main

分支的草稿 PR，除非用户明确要求创建就绪状态的 PR 或指定不同的基础分支。

Preconditions

前置条件

Inspect

git status --short --branch

and

git branch --show-current

Do not include unrelated dirty files. If unrelated changes are present, leave them unstaged and mention them.
If the worktree is detached, create a branch from the current
```
HEAD
```
before committing. Use the branch name requested by the user, an existing repository convention, or
```
<author>/<semantic-name>
```
when no stronger convention is available.
If already on a suitable named branch, use it.
Confirm appropriate automated coverage exists or was added. Do not list routine CI-covered checks in the PR body.
If user-facing functionality is being updated, check that the appropriate package has a change file under
```
packages/<package>/.changes/
```
. This is not necessary for docs-only, GitHub Actions/workflow-only, or dependency-maintenance PRs unless the dependency change itself has user-facing impact.

检查

git status --short --branch

和

git branch --show-current

的输出。

不要包含无关的未提交文件。如果存在无关更改，请不要暂存它们并予以说明。
如果工作区处于分离头指针状态，请在提交前从当前
```
HEAD
```
创建一个分支。使用用户要求的分支名、仓库现有的命名规范，如果没有更明确的规范，则使用
```
<author>/<semantic-name>
```
格式。
如果已经在合适命名的分支上，直接使用该分支。
确认存在或已添加适当的自动化测试覆盖。不要在 PR 正文中列出常规的 CI 覆盖检查项。
如果更新了面向用户的功能，请检查对应的包在
```
packages/<package>/.changes/
```
目录下是否有变更文件。对于仅文档修改、仅 GitHub Actions/工作流修改或依赖维护类的 PR 则不需要，除非依赖变更本身会影响用户。

Context

上下文

Capture what changed, why it changed, and who it affects.
Find related issues, discussions, or PRs and include links when relevant.
Prefer
```
git diff --stat
```
plus focused
```
git diff
```
over broad repo archaeology when the change is small.
If the user supplies a report, issue, discussion, or related PR, treat that as the primary context source.
For new feature work, include a concise usage snippet. If the feature replaces or improves an older approach, include before/after examples when they help reviewers.

记录变更内容、变更原因以及影响范围。
查找相关的 issue、讨论或 PR，并在相关时附上链接。
当变更较小时，优先使用
```
git diff --stat
```
加上针对性的
```
git diff
```
，而不是大范围翻查仓库历史。
如果用户提供了报告、issue、讨论或相关 PR，将其作为主要的上下文来源。
对于新功能开发，附上简洁的使用代码片段。如果该功能替代或改进了旧有实现方式，在有助于评审者理解的情况下，附上改造前后的示例。

Commit and Push

提交与推送

Review the diff with
```
git diff --stat
```
and focused
```
git diff
```
as needed.
Stage only the intended files.
Commit with a concise imperative subject.
Push the branch before creating the PR.

使用
```
git diff --stat
```
查看变更统计，并根据需要使用针对性的
```
git diff
```
检查详细变更。
仅暂存目标文件。
使用简洁的祈使句作为提交信息标题。
在创建 PR 之前推送分支。

PR Creation

PR 创建

Save the PR body to a temporary file, then use

gh pr create

with:

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

Omit
```
--draft
```
only when the user explicitly asks for a ready PR.
Change
```
--base
```
only when the user explicitly requests a different base branch.
Keep shell quoting simple. Prefer a body file if the body contains backticks, quotes, or multiple paragraphs.
Include issue/discussion links when known. Use
```
Closes #NNNN
```
for bug fixes the PR should close; use
```
Implements #NNNN
```
or a plain link for RFCs/discussions when closing semantics are not appropriate.
Include testing notes only for manual checks, unusual verification, skipped non-CI checks, or failures that reviewers should know about.
If
```
gh pr create
```
fails, leave the branch pushed when possible and give the user a ready-to-open compare URL plus the prepared title and body.

Recommended PR body shape:

markdown

This change ...

- Optional extra detail when useful.

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

tsx

// Optional before/after example

Testing

Optional manual or non-CI verification notes only.


- 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.

将 PR 正文保存到临时文件，然后使用以下

gh pr create

命令：

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

仅当用户明确要求创建就绪 PR 时，才省略
```
--draft
```
参数。
仅当用户明确要求使用不同的基础分支时，才修改
```
--base
```
参数。
保持 shell 引号简洁。如果 PR 正文包含反引号、引号或多个段落，优先使用正文文件。
如果已知相关 issue/讨论，附上链接。对于该 PR 应关闭的 bug 修复，使用
```
Closes #NNNN
```
；对于 RFC/讨论，如果关闭语义不合适，则使用
```
Implements #NNNN
```
或普通链接。
仅针对手动检查、非常规验证、跳过的非 CI 检查，或评审者需要了解的失败情况，才添加测试说明。
如果
```
gh pr create
```
执行失败，尽可能保留已推送的分支，并向用户提供可直接打开的比较 URL，以及准备好的标题和正文。

推荐的 PR 正文结构：

markdown

This change ...

- Optional extra detail when useful.

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

tsx

// Optional before/after example

测试

仅包含手动或非 CI 验证说明。


- 不要使用 `## Summary` 标题。用一到两个短句开头，说明变更的作用。
- 仅在需要更多细节时，才在开头后添加项目符号列表。
- 对于新功能附上使用示例，对于替代或改进类变更附上前后对比示例，帮助评审者理解变更。
- 仅当存在手动检查、非常规验证步骤、跳过的非 CI 检查，或评审者需要了解的失败情况时，才在描述下方添加 `**Testing**` 及项目符号列表。常规自动化覆盖的内容无需添加。

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.

不要在 PR 正文中列出代码检查、类型检查、单元测试或集成测试命令，即使你在本地运行过。CI 会自动执行这些检查。
不要说明 CI 会运行常规的代码检查、类型检查、单元测试或集成测试。这是每个 PR 的默认操作。
默认情况下不要添加手动测试说明。
仅在必要时添加手动测试说明，例如需要人工评审的视觉/UI 行为、CI 未覆盖的特定环境行为、发布/发布预演步骤、外部服务集成，或无法在自动化测试中可靠复现的问题。
当需要手动测试时，保持说明简洁，并直接对应未覆盖的风险点。

Labels

Touched path	Label
`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`

If a package path is unclear, inspect its

package.json

name

and use

pkg:<name>

when that label exists. If a change touches generated artifacts or integration tests only, infer the package label from the runtime/tooling area being tested. For example, Vite plugin or prerender integration coverage usually maps to

pkg:@react-router/dev

根据修改的包路径，添加所有适用的

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

。

Feature Labels

功能标签

Add applicable

feat:*

labels for the behavior area being changed. Common labels include:

Behavior area	Label
Core navigation, loaders/actions, fetchers, redirects, matching, and router state	`feat:router`
Route config APIs and `routes.ts`	`feat:routes.ts`
Vite plugin and build pipeline behavior	`feat:vite`
SPA mode	`feat:spa-mode`
Prerendering	`feat:prerender`
Lazy route discovery	`feat:lazy-route-discovery`
Hydration and hydration fallback behavior	`feat:hydration`
View transition APIs	`feat:view-transitions`
Middleware behavior	`feat:middleware`
Split route module behavior	`feat:split-route-modules`
Streaming behavior	`feat:streaming`
CSS handling	`feat:css`
Windows-specific fixes	`feat:windows`
RSC Data or RSC Framework behavior	`feat:rsc`
Path matching semantics	`feat:path-matching`
Single fetch behavior	`feat:single-fetch`
Types, typegen, and TypeScript behavior	`feat:typescript`

Multiple feature labels are fine when the diff truly spans multiple areas. Prefer the most specific label that exists.

为变更的行为领域添加适用的

feat:*

标签。常见标签包括：

行为领域	标签
核心导航、loaders/actions、fetchers、重定向、路由匹配和 router 状态	`feat:router`
路由配置 API 和 `routes.ts`	`feat:routes.ts`
Vite 插件和构建流水线行为	`feat:vite`
SPA 模式	`feat:spa-mode`
预渲染	`feat:prerender`
懒路由发现	`feat:lazy-route-discovery`
Hydration 和 hydration 回退行为	`feat:hydration`
视图过渡 API	`feat:view-transitions`
中间件行为	`feat:middleware`
拆分路由模块行为	`feat:split-route-modules`
流式处理行为	`feat:streaming`
CSS 处理	`feat:css`
Windows 特定修复	`feat:windows`
RSC Data 或 RSC 框架行为	`feat:rsc`
路径匹配语义	`feat:path-matching`
单次获取行为	`feat:single-fetch`
类型、类型生成和 TypeScript 行为	`feat:typescript`

当变更确实涉及多个领域时，可以添加多个功能标签。优先选择最具体的现有标签。

Non-Package Labels

非包标签

Some PRs do not need package or feature labels:

Add
```
docs
```
for documentation-only changes.
Add
```
github-actions
```
for
```
.github/workflows/
```
or Actions infrastructure changes.
Add
```
dependencies
```
for dependency or lockfile-only maintenance.
Add version labels such as
```
v6
```
,
```
v7
```
, or
```
v8
```
only when the PR is intentionally scoped to that release line or the user asks for it.

有些 PR 不需要包标签或功能标签：

仅文档类变更添加
```
docs
```
标签。
```
.github/workflows/
```
或 Actions 基础设施变更添加
```
github-actions
```
标签。
仅依赖或锁文件维护类变更添加
```
dependencies
```
标签。
仅当 PR 明确针对某个发布线，或用户要求时，才添加版本标签如
```
v6
```
、
```
v7
```
或
```
v8
```
。

Final Report

最终报告

Report:

Branch name.
Commit hash.
PR URL and whether it is draft or ready.
Base branch.
Labels applied.
Verification performed or skipped.

报告内容包括：

分支名称。
提交哈希。
PR URL 以及是草稿还是就绪状态。
基础分支。
已应用的标签。
已执行或跳过的验证。