write-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Write a Pull Request

编写 Pull Request

Fill

PULL_REQUEST_TEMPLATE.md

. Write in Simple English. Keep the body short.

填写

PULL_REQUEST_TEMPLATE.md

。使用 Simple English 写作。保持正文简短。

When this skill applies

此 skill 的适用场景

When you create, open, submit, or update a pull request, use this skill. Use it for

gh pr create

, GitHub MCP

create_pull_request

, and body edits. Do not use a different heading set. Do not add a Summary or a Test Plan.

创建、打开、提交或更新 Pull Request 时使用此 skill。用于

gh pr create

、GitHub MCP

create_pull_request

以及正文编辑。不要使用其他标题集合。不要添加 Summary 或 Test Plan。

Before you write

编写前

Read the full diff against the base branch.
Read the commit subjects on this branch.
If linked issues or design docs add facts the diff does not show, read them.

阅读相对于 base branch 的完整 diff。
阅读此 branch 上的 commit subject。
如果 linked issue 或 design doc 补充了 diff 未显示的信息，请阅读它们。

Hard limits

硬性限制

Use only these headings, in this order:

Background
Design Decisions
Changes
Verification Performed
Post-Merge Operations

Keep the whole body under 250 words. If a heading has no content, write

None.

under it. Do not add a sixth heading. Do not leave HTML comments in the submitted body. Do not add a "Made with" or "Generated with" footer.

仅使用以下标题，并保持此顺序：

Background
Design Decisions
Changes
Verification Performed
Post-Merge Operations

整个正文保持在 250 个单词以内。如果某个标题下没有内容，请在其下写入

None.

。不要添加第六个标题。不要在提交的正文中保留 HTML comments。不要添加“Made with”或“Generated with”页脚。

Simple English

Apply the

simple-english

skill in pragmatic mode. If that skill is not in context, apply these rules:

Descriptive text uses simple present or simple past.
Descriptive sentences stay under 25 words.
```
Post-Merge Operations
```
is a procedure. Use the imperative.
Procedural sentences stay under 20 words.
One instruction per sentence.
Put
```
If
```
and
```
When
```
at the start of the sentence.
Use only the modals
```
can
```
,
```
will
```
, and
```
must
```
.
Do not use
```
should
```
,
```
would
```
,
```
may
```
,
```
might
```
, or
```
could
```
.
Do not use contractions or semicolons.
Do not use
```
e.g.
```
,
```
i.e.
```
, or
```
etc.
```
Pick one name per thing and keep it.
Delete filler that adds no fact.

Then run the simple-english self-check on the draft.

以务实模式应用

simple-english

skill。如果上下文中没有该 skill，请应用以下规则：

描述性文本使用一般现在时或一般过去时。
描述性句子保持在 25 个单词以内。
```
Post-Merge Operations
```
是一个操作流程。使用祈使句。
操作性句子保持在 20 个单词以内。
每个句子只包含一条指令。
将
```
If
```
和
```
When
```
放在句首。
仅使用
```
can
```
、
```
will
```
和
```
must
```
这三个情态动词。
不要使用
```
should
```
、
```
would
```
、
```
may
```
、
```
might
```
或
```
could
```
。
不要使用缩写形式或分号。
不要使用
```
e.g.
```
、
```
i.e.
```
或
```
etc.
```
。
每件事只使用一个名称，并保持一致。
删除不提供任何事实的冗余内容。

然后对草稿运行 simple-english 自检。

Section rules

各部分规则

Background (descriptive)

Background（描述性）

State why the change exists. Name the problem, the constraint, or the linked issue. Use two to four sentences. Put GitHub close keywords on their own line, for example

Closes #123

. Do not restate the diff.

说明进行此变更的原因。指出问题、限制条件或 linked issue。使用两到四个句子。将 GitHub close keywords 单独放在一行，例如

Closes #123

。不要重复 diff 中的内容。

Design Decisions (descriptive)

Design Decisions（描述性）

State only the choices a reviewer cannot infer from the diff. Use a short bullet list. If you made no such choice, write

None.

Do not narrate the design history.

仅说明 reviewer 无法从 diff 中推断出的选择。使用简短的项目符号列表。如果未做出此类选择，请写入

None.

。不要叙述设计的历史。

Changes (descriptive)

Changes（描述性）

State what landed, at component level. Bold the component. Then write one short clause. Do not list files. Do not paste commit messages. Three to seven bullets is enough.

在 component 层级说明已合入的内容。加粗 component，然后写一个简短子句。不要列出文件。不要粘贴 commit message。三到七个项目符号通常足够。

Verification Performed (descriptive, simple past)

Verification Performed（描述性，使用一般过去时）

State what you ran and the result. Name the command and the outcome. If you did not run the test suite, say that. Do not write an unchecked future checklist. Do not invent runs.

说明执行了什么以及结果如何。写出命令名称和结果。如果未运行 test suite，请明确说明。不要编写未勾选的未来检查清单。不要虚构执行记录。

Post-Merge Operations (procedural)

Post-Merge Operations（操作性）

State the steps a human must do after merge. Put a required condition before the command. If no step is required, write

None.

Do not tell the reader to merge the pull request.

说明 human 在 merge 后必须执行的步骤。将必要条件放在命令之前。如果不需要执行任何步骤，请写入

None.

。不要提示 reader 执行 Pull Request merge。

Title

标题

Write a conventional title of the form type-colon-what. Keep the title under 72 characters. Use the imperative:

Add

Fix

Pin

Remove

编写

type-colon-what

形式的 conventional title。标题保持在 72 个字符以内。使用祈使动词：

Add

、

Fix

、

Pin

、

Remove

。

How to submit

如何提交

Write the body to a file. Then pass that file to the create command. Do not rely on GitHub to fill the template. Your

--body

replaces it.

先将正文写入文件。然后将该文件传给 create 命令。不要依赖 GitHub 填充模板。

--body

会替换模板内容。

Example

示例

Before: extra headings, a future checklist, and a generator footer.

After:

markdown

undefined

**之前：**存在多余标题、未来检查清单和生成器页脚。

之后：

markdown

undefined

Background

codeql.yml

and

dependency-review.yml

did not take the

enabled:

input. The other PR-time gates already have that input. A docs-only pull request still ran a full CodeQL job.

This change unblocks lane targeting in

lvlup-sw/hierophant

. Tracking: lvlup-sw/.github#38.

codeql.yml

and

dependency-review.yml

did not take the

enabled:

input. The other PR-time gates already have that input. A docs-only pull request still ran a full CodeQL job.

This change unblocks lane targeting in

lvlup-sw/hierophant

. Tracking: lvlup-sw/.github#38.

Design Decisions

Add
```
enabled:
```
in the same shape as the other four gates.
Use
```
if: ${{ inputs.enabled != false }}
```
so a bad value still runs the job.
Leave
```
update-baseline
```
unchanged. Consumers call it only on the default branch.

Add
```
enabled:
```
in the same shape as the other four gates.
Use
```
if: ${{ inputs.enabled != false }}
```
so a bad value still runs the job.
Leave
```
update-baseline
```
unchanged. Consumers call it only on the default branch.

Changes

dependency-review.yml
and
codeql.yml
— accept

enabled:

(default

true

canary-enabled-input.yml
— cover both new callers.
Consumer guide — name which reusables accept the input.

dependency-review.yml
and
codeql.yml
— accept

enabled:

(default

true

canary-enabled-input.yml
— cover both new callers.
Consumer guide — name which reusables accept the input.

Verification Performed

```
actionlint
```
was clean on the three changed workflows.
```
pytest actions/ci-lanes/tests
```
— 39 passed, 164 subtests.
The canary asserts that a skipped inner job still reports the two-part check name.

```
actionlint
```
was clean on the three changed workflows.
```
pytest actions/ci-lanes/tests
```
— 39 passed, 164 subtests.
The canary asserts that a skipped inner job still reports the two-part check name.

Post-Merge Operations

None.

undefined

None.

undefined

Anti-patterns

反模式

Do not add extra headings such as Summary, Test Plan, Checklist, Docs, Proof, or Related Issues.
Do not add a bullet for every file.
Do not repeat the same fact in two sections.
Do not name classes and methods that the diff already shows.
Do not write unchecked boxes for work you plan to do later.
Do not add ritual
```
N/A
```
checklists.
Do not narrate the work phase by phase.

不要添加 Summary、Test Plan、Checklist、Docs、Proof 或 Related Issues 等额外标题。
不要为每个文件添加一个项目符号。
不要在两个部分中重复同一事实。
不要提及 diff 中已经展示的 class 和 method 名称。
不要为以后计划完成的工作添加未勾选的复选框。
不要添加仪式性的
```
N/A
```
检查清单。
不要按工作阶段逐一叙述过程。