gh-pr-description

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

GitHub PR description

GitHub PR 描述

See review notes for the maintainer patterns behind this workflow; they describe what to cover, not how much to write.

Read

CONTRIBUTING.md

and

.github/pull_request_template.md

, then inspect the branch diff, commits, related issue, tests, docs, and changesets. If updating a PR, read its current body too.

Fill in the repository template. Write for a reviewer:

explain the concrete problem and solution near the top
summarize meaningful behavior and decisions, not files or commits
mention breaking changes, preserved behavior, scope boundaries, or stacked PRs only when relevant
link the prior issue with
```
Closes #N
```
,
```
Related to #N
```
, or equivalent
scale length with risk, not diff size

Default to the shortest body that answers the four questions below. Keep the Summary under 5 sentences for most PRs; exceed 10 lines only for breaking or cross-cutting changes. Prefer plain language. Include implementation detail or jargon only when the reviewer cannot assess behavior or risk without it. Do not restate the issue, template guidance, or checklist. Use bullets only when they improve clarity.

A typical small PR body:

markdown

undefined

查看review notes了解此工作流背后的维护者模式；这些说明涵盖了需要包含的内容，而非撰写篇幅要求。

阅读

CONTRIBUTING.md

和

.github/pull_request_template.md

，然后检查分支差异、提交记录、相关问题、测试、文档和变更集。如果是更新PR，还需阅读其当前的正文内容。

填写仓库模板。撰写时需面向审核者：

在靠近顶部的位置说明具体问题和解决方案
总结有意义的行为和决策，而非文件或提交记录
仅在相关时提及破坏性变更、保留的行为、范围边界或堆叠PR
使用
```
Closes #N
```
、
```
Related to #N
```
或类似格式关联相关问题
根据风险调整篇幅，而非差异大小

默认使用能回答以下四个问题的最短正文。大多数PR的“摘要”部分控制在5句话以内；仅在涉及破坏性变更或跨模块变更时，篇幅才超过10行。优先使用平实语言。仅当审核者无法评估行为或风险时，才包含实现细节或术语。不要重复问题内容、模板指南或检查清单。仅在能提升清晰度时使用项目符号。

一个典型的小型PR正文示例：

markdown

undefined

Summary

Closes #412.

eve dev

crashed when an agent had no

connections/

directory; the compiler now treats missing optional directories as empty.

Closes #412.

eve dev

crashed when an agent had no

connections/

directory; the compiler now treats missing optional directories as empty.

Validation

Reproduced the crash with the weather fixture, then confirmed a clean boot
```
pnpm test:unit
```
,
```
pnpm typecheck
```

Reproduced the crash with the weather fixture, then confirmed a clean boot
```
pnpm test:unit
```
,
```
pnpm typecheck
```

Checklist

(preserved from the template; only verified items checked)


Under validation, list exact checks actually run and useful manual coverage. State
limitations honestly. Do not infer results or claim checks that only CI will
run.

Preserve the checklist and check only verified items. If tests, docs, or a
changeset are not applicable, say so in one short line at most.

Before returning or publishing the description, confirm that it answers:

1. What problem does this solve?
2. What meaningfully changes?
3. How was it validated?
4. What should the reviewer pay special attention to?

Then prune: delete any sentence that restates the diff, the issue, or the
template, and any detail the reviewer does not need. If the answer to question
4 is "nothing," leave it out.

When asked only to draft, return the body for review. When asked to create or
update the PR, pass a body file to `gh pr create` or `gh pr edit`.

(preserved from the template; only verified items checked)


在“验证”部分，列出实际运行的具体检查以及有用的手动测试覆盖范围。如实说明局限性。不要推断结果或声称仅由CI运行的检查。

保留检查清单，仅勾选已验证的项。如果测试、文档或变更集不适用，最多用一句话说明。

在返回或发布描述之前，确认它回答了以下问题：

1. 这解决了什么问题？
2. 哪些内容发生了有意义的变化？
3. 如何验证的？
4. 审核者需要特别注意什么？

然后精简内容：删除任何重复差异、问题或模板的句子，以及审核者不需要的细节。如果问题4的答案是“无”，则省略该部分。

当仅要求撰写草稿时，返回待审核的正文。当要求创建或更新PR时，将正文文件传递给`gh pr create`或`gh pr edit`。