create-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create PR — pre-pull-request validation orchestration

创建PR — 拉取请求前的验证编排

Orchestrates every check a PR needs before it's opened. Does NOT open the PR — that's a separate action the user takes after this skill reports "ready."

协调PR打开前所需的所有检查。不会打开PR —— 此技能报告“就绪”后，由用户执行单独的打开PR操作。

Before You Start

开始之前

```
CLAUDE.md
```
— "Quick Reference" section lists the project's test, lint, and build commands.
```
.github/workflows/
```
— tells you what CI will run. The local gates should mirror these.

skills/workflow/merge-main/SKILL.md

skills/workflow/review-diff/SKILL.md

— this skill delegates to them.

```
CLAUDE.md
```
—— “快速参考”部分列出了项目的测试、Lint和构建命令。
```
.github/workflows/
```
—— 显示CI将运行的任务。本地检查应与这些任务保持一致。

skills/workflow/merge-main/SKILL.md

、

skills/workflow/review-diff/SKILL.md

—— 此技能会委托给这些技能。

Step 1: commit current work

步骤1：提交当前工作

Same discipline as

merge-main

step 1 — uncommitted changes block the rest.

bash

git status
git diff
git add <specific-files>
git commit -m "type(scope): concise message"

Follow the project's commit convention (check root

CLAUDE.md

.github/

). Common patterns:

type(scope): subject

with types from

fix | feat | test | doc | chore | refactor

Keep commits focused — one logical change per commit. Imperative mood ("Add X", not "Added X").

与

merge-main

技能的步骤1要求相同 —— 未提交的更改会阻碍后续操作。

bash

git status
git diff
git add <specific-files>
git commit -m "type(scope): concise message"

遵循项目的提交规范（查看根目录下的

CLAUDE.md

或

.github/

）。常见格式：

type(scope): subject

，其中type可选值包括

fix | feat | test | doc | chore | refactor

。

保持提交聚焦 —— 每次提交对应一个逻辑变更。使用祈使语气（如“Add X”而非“Added X”）。

Step 2: sync with main

步骤2：与主分支同步

Delegate to the

merge-main

skill. It commits any stragglers, fetches, merges, resolves conflicts, and validates post-merge. After it returns, the branch is up to date.

委托给

merge-main

技能。它会提交所有未提交的变更、拉取远程代码、合并分支、解决冲突并验证合并后的状态。返回后，当前分支将与主分支保持同步。

Step 3: format and lint

步骤3：格式化与Lint检查

Run the project's format + lint command (from root

CLAUDE.md

Quick Reference). Common patterns:

bash

undefined

运行项目的格式化+Lint命令（来自根目录

CLAUDE.md

的快速参考）。常见示例：

bash

undefined

pick the one your project uses; these are illustrative

选择项目使用的命令；以下仅为示例

make pr-ready pnpm lint:fix ruff format . && ruff check --fix . cargo fmt && cargo clippy --fix --allow-dirty


Fix any remaining errors until the command exits clean. Re-run after fixes — lint rules sometimes interact.

make pr-ready pnpm lint:fix ruff format . && ruff check --fix . cargo fmt && cargo clippy --fix --allow-dirty


修复所有剩余错误，直到命令执行成功。修复后重新运行 —— Lint规则有时会相互影响。

Step 4: run tests

步骤4：运行测试

Run the project's test command, scoped to the affected paths when the project supports it:

bash

undefined

运行项目的测试命令，若项目支持，可限定在受影响的路径范围内：

bash

undefined

pick the project's pattern

选择项目使用的格式

make test pnpm test pytest tests/ cargo test


**Every test must pass.** Never disable or skip a test to "get to green." Fix root causes.

make test pnpm test pytest tests/ cargo test


**所有测试必须通过**。绝不能为了“通过测试”而禁用或跳过测试。需修复根本原因。

Step 5: review changes

步骤5：审查变更

Delegate to

review-diff

for a senior-level review against the project's conventions. Fix every Critical and Important finding. Re-run step 3 (format + lint) and step 4 (tests) for any scopes touched while fixing.

委托给

review-diff

技能，按照项目规范进行资深级别的审查。修复所有**Critical（严重）和Important（重要）**问题。修复过程中涉及的代码范围，需重新运行步骤3（格式化+Lint）和步骤4（测试）。

Step 6: update documentation

步骤6：更新文档

If the changes touched:

API contracts, schemas, or public behavior — update the relevant docs (
```
docs/
```
,
```
README.md
```
, OpenAPI specs, etc.). Delegate to
```
update-doc
```
if the project has multiple doc locations.
Architecture-level decisions — an ADR may be required. Delegate to
```
document-decision
```
.
CLAUDE.md
-level invariants — if you discovered a new gotcha while implementing, add it to
```
CLAUDE.md
```
under Things to Know.

若变更涉及以下内容：

API契约、Schema或公开行为 —— 更新相关文档（
```
docs/
```
、
```
README.md
```
、OpenAPI规范等）。若项目有多个文档位置，可委托给
```
update-doc
```
技能。
架构层面的决策 —— 可能需要编写ADR（架构决策记录）。委托给
```
document-decision
```
技能。
CLAUDE.md
中的核心规则 —— 若在实现过程中发现新的注意事项，将其添加到
```
CLAUDE.md
```
的“Things to Know”部分。

Step 7: declare ready

步骤7：声明就绪

Print a summary for the user:

markdown

undefined

为用户打印总结：

markdown

undefined

PR Readiness: {branch}

PR就绪状态：{branch}

Committed ({N} commits on this branch)
Synced with origin/main
Format + lint clean
Tests pass ({N} passed)
Reviewed — {critical resolved, important resolved, suggestions noted}
Docs updated: {list}
PR not yet opened — run
```
gh pr create
```
when ready

Summary of changes for the PR body: {2–4 bullet points}

undefined

已提交（此分支上共{N}次提交）
已与origin/main同步
格式化+Lint检查通过
测试通过（共{N}项测试通过）
已审查 —— {严重问题已解决，重要问题已解决，建议已记录}
文档已更新：{列表}
尚未打开PR —— 就绪后运行
```
gh pr create
```

PR正文的变更摘要： {2–4个要点}

undefined

Critical Rules

关键规则

Do NOT open the PR. This skill stops at "ready." The user runs
```
gh pr create
```
themselves.
Do NOT skip any failing test.
Fix the actual problem, not the symptom.
Commit fixes from the review as separate commits, not amended into feature commits.
Do NOT add backwards-compatibility shims unless the user explicitly asked.

请勿打开PR。此技能仅负责将代码准备至“就绪”状态。由用户自行运行
```
gh pr create
```
。
请勿跳过任何失败的测试。
修复实际问题，而非仅解决表面症状。
将审查后的修复作为单独提交，不要合并到功能提交中。
请勿添加向后兼容垫片，除非用户明确要求。

Verify

验证

bash

undefined

bash

undefined

On a feature branch (not main)

在功能分支上（而非主分支）

git branch --show-current

Expected: not "main" / "master"

预期结果：不是"main" / "master"

Branch is up to date with origin/main

分支已与origin/main同步

git fetch origin main && git log --oneline HEAD..origin/main | wc -l

Expected: 0

预期结果：0

Working tree clean

工作区干净

git status --short

Expected: empty output

预期结果：无输出

Project-specific final gate (pull from CLAUDE.md Quick Reference)

项目特定的最终检查（来自CLAUDE.md的快速参考）

undefined

undefined

Common Mistakes

常见错误

Mistake	Correction
Amending feature commits with review-fix commits	Keep review fixes as separate commits. The PR reviewer sees the progression; amending erases it.
Running tests against a stale branch	Sync with main first (step 2). Tests passing on an old base prove nothing.
Opening the PR before fixing Important findings	"Important" from `review-diff` means "should fix before merge." Address them, then open.
Updating docs in a separate later PR	Doc drift compounds. Keep code and docs in the same PR — easier to review and less likely to be forgotten.

错误	修正方法
将审查修复合并到功能提交中	将审查修复作为单独提交。PR审查者可以看到变更过程；合并会抹除这些记录。
在过时分支上运行测试	先与主分支同步（步骤2）。在旧分支上测试通过毫无意义。
未修复Important（重要）问题就打开PR	`review-diff` 中的“Important”意味着“合并前应修复”。解决这些问题后再打开PR。
在后续单独的PR中更新文档	文档偏差会不断累积。将代码和文档更新放在同一个PR中 —— 更易于审查，也更不容易被遗忘。