pr-creator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PR Creator

PR 创建工具

Create well-structured draft pull requests by analyzing the diff, generating a conventional-commit title and structured description, suggesting reviewers from CODEOWNERS, and executing

gh pr create

— all with a confirmation step before anything is submitted.

通过分析diff创建结构清晰的草稿拉取请求，生成符合约定式提交规范的标题和结构化描述，根据CODEOWNERS建议评审人，执行

gh pr create

命令——所有提交操作前都会有确认步骤。

Prerequisites

前置条件

Git repository with a remote origin
GitHub CLI (
```
gh
```
) installed and authenticated
For GitLab:
```
glab
```
CLI; for Bitbucket:
```
bb
```
CLI (see Platform Adaptation section at the end)

配置了remote origin的Git仓库
已安装并完成身份验证的GitHub CLI (
```
gh
```
)
若使用GitLab需安装
```
glab
```
CLI；若使用Bitbucket需安装
```
bb
```
CLI（参考文末的平台适配章节）

Workflow

工作流程

Follow these steps in order. Do not skip the preview step.

请按顺序执行以下步骤，不可跳过预览步骤。

Step 1: Gather context

步骤1：收集上下文

Run these commands to understand the current state:

bash

undefined

运行以下命令了解当前状态：

bash

undefined

Confirm repo and ownership

git config --get remote.origin.url

Detect current branch

git rev-parse --abbrev-ref HEAD


Then ask the user: **"What branch should this PR target?"**

Do not assume `dev`, `main`, or any default. Wait for the user's answer before proceeding.

git rev-parse --abbrev-ref HEAD


然后询问用户：**"What branch should this PR target?"**

不要默认假设是`dev`、`main`或任何默认分支，等待用户答复后再继续操作。

Step 2: Analyze the diff

步骤2：分析diff

First, verify the current branch has been pushed to the remote:

bash

git ls-remote --heads origin <current_branch>

If the branch doesn't exist on the remote, push it first:

bash

git push -u origin <current_branch>

Then run the diff:

bash

git diff origin/<target_branch>...origin/<current_branch> | cat

If the diff exceeds roughly 1000 lines, warn the user:

"This PR touches over 1000 lines of changes. Large PRs are harder to review effectively. Would you like to proceed anyway, or would you prefer to split this into smaller PRs?"

Wait for confirmation before continuing. If the user wants to split, help them plan the split — but that's outside this skill's scope.

首先验证当前分支已推送到远程仓库：

bash

git ls-remote --heads origin <current_branch>

如果远程仓库不存在该分支，先执行推送：

bash

git push -u origin <current_branch>

然后运行diff命令：

bash

git diff origin/<target_branch>...origin/<current_branch> | cat

如果diff行数超过约1000行，向用户发出警告：

"This PR touches over 1000 lines of changes. Large PRs are harder to review effectively. Would you like to proceed anyway, or would you prefer to split this into smaller PRs?"

等待用户确认后再继续。如果用户希望拆分，可协助其规划拆分方案——不过这不属于本技能的覆盖范围。

Step 3: Generate the PR title

步骤3：生成PR标题

Analyze the diff to determine:

Type — Pick the most appropriate conventional commit type based on what the diff actually does:
- ```
feat
```
  — new functionality
- ```
fix
```
  — bug fix
- ```
chore
```
  — maintenance, dependency updates
- ```
docs
```
  — documentation only
- ```
style
```
  — formatting, whitespace, no logic change
- ```
refactor
```
  — restructuring without behavior change
- ```
test
```
  — adding or updating tests
- ```
perf
```
  — performance improvement
- ```
ci
```
  — CI/CD config changes
- ```
build
```
  — build system or external dependency changes
Scope (optional) — If the changes clearly belong to a single module, component, or domain (e.g.,
```
pricing
```
,
```
auth
```
,
```
api
```
), include it in parentheses. If the changes span multiple areas or no clear scope emerges, omit it.
Description — A concise lowercase summary of what changed. Wrap code identifiers, function names, file names, and technical keywords in backticks.

Format:

type(scope): description

type: description

Examples:

feat(pricing): adjust formula to include volume discounts

```
fix: resolve null pointer in 
```
getUserProfile
```
 response
```
```
chore: upgrade 
```
axios
```
 to v1.7.2
```

refactor(auth): extract token validation into middleware

分析diff确定以下信息：

类型 — 根据diff的实际变更内容选择最合适的约定式提交类型：
- ```
feat
```
  — 新增功能
- ```
fix
```
  — 修复Bug
- ```
chore
```
  — 维护性变更、依赖更新
- ```
docs
```
  — 仅文档变更
- ```
style
```
  — 格式调整、空格修改，无逻辑变更
- ```
refactor
```
  — 代码重构，无行为变更
- ```
test
```
  — 新增或更新测试
- ```
perf
```
  — 性能优化
- ```
ci
```
  — CI/CD配置变更
- ```
build
```
  — 构建系统或外部依赖变更
范围（可选） — 如果变更明确属于单个模块、组件或领域（例如
```
pricing
```
、
```
auth
```
、
```
api
```
），将其放在括号中。如果变更覆盖多个领域或没有明确范围，则省略。
描述 — 对变更内容的简洁小写摘要。将代码标识符、函数名、文件名和技术关键词用反引号包裹。

格式：

type(scope): description

或

type: description

示例：

feat(pricing): adjust formula to include volume discounts

```
fix: resolve null pointer in 
```
getUserProfile
```
 response
```
```
chore: upgrade 
```
axios
```
 to v1.7.2
```

refactor(auth): extract token validation into middleware

Step 4: Generate the PR description

步骤4：生成PR描述

Structure the description with these three sections:

markdown

undefined

按照以下三个部分组织描述内容：

markdown

undefined

Summary

A 2-3 sentence high-level overview of what this PR does and why.

Key Changes

Specific change 1 with relevant detail
Specific change 2 with relevant detail
(list as many as needed to cover the meaningful changes)

Specific change 1 with relevant detail
Specific change 2 with relevant detail
(list as many as needed to cover the meaningful changes)

Impact

Who or what is affected by these changes
Any migration steps, breaking changes, or deployment considerations
Testing notes if relevant


Write the description based on what the diff actually shows. Be specific — reference file names, functions, and behaviors rather than being vague.

Who or what is affected by these changes
Any migration steps, breaking changes, or deployment considerations
Testing notes if relevant


描述内容要基于diff的实际内容，要具体——参考文件名、函数和行为，不要模糊表述。

Step 5: Suggest reviewers

步骤5：建议评审人

Check if a CODEOWNERS file exists:

bash

cat .github/CODEOWNERS 2>/dev/null || cat CODEOWNERS 2>/dev/null || echo "No CODEOWNERS file found"

If CODEOWNERS exists: Match changed file paths against CODEOWNERS patterns to identify suggested reviewers. Present them to the user and ask: "Based on CODEOWNERS, I'd suggest these reviewers:
```
@user1
```
,
```
@user2
```
. Would you like to add or change any?"
If no CODEOWNERS: Ask the user directly: "Please provide at least one reviewer for this PR (GitHub usernames)."

At least one reviewer is required. Do not proceed without one.

检查是否存在CODEOWNERS文件：

bash

cat .github/CODEOWNERS 2>/dev/null || cat CODEOWNERS 2>/dev/null || echo "No CODEOWNERS file found"

如果存在CODEOWNERS：将变更的文件路径与CODEOWNERS的规则匹配，确定建议的评审人。向用户展示并询问："Based on CODEOWNERS, I'd suggest these reviewers:
```
@user1
```
,
```
@user2
```
. Would you like to add or change any?"
如果没有CODEOWNERS：直接询问用户："Please provide at least one reviewer for this PR (GitHub usernames)."

至少需要一位评审人，未获取前不可继续操作。

Step 6: Detect labels

步骤6：检测标签

Check if the repo uses labels:

bash

gh label list --limit 50

If labels exist, suggest relevant ones based on the PR type and diff content. For example:

```
feat
```
type → look for
```
enhancement
```
or
```
feature
```
label
```
fix
```
type → look for
```
bug
```
or
```
bugfix
```
label
Breaking changes in the diff → look for
```
breaking-change
```
label

Only suggest labels that actually exist in the repo. If no labels exist or none are relevant, skip this step silently.

检查仓库是否使用标签：

bash

gh label list --limit 50

如果存在标签，根据PR类型和diff内容建议相关标签。例如：

```
feat
```
类型 → 查找
```
enhancement
```
或
```
feature
```
标签
```
fix
```
类型 → 查找
```
bug
```
或
```
bugfix
```
标签
diff中包含破坏性变更 → 查找
```
breaking-change
```
标签

仅建议仓库中实际存在的标签。如果没有标签或没有相关标签，直接跳过此步骤。

Step 7: Preview and confirm

步骤7：预览和确认

Present the complete PR to the user for review before executing anything:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 PR Preview
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Title:       <generated title>
Target:      <target_branch>
Source:      <current_branch>
Reviewers:   <reviewer list>
Labels:      <label list or "none">
Status:      Draft

Description:
<generated description>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ask: "Does this look good? I'll create the draft PR once you confirm. Let me know if you'd like to change anything."

If the user requests changes, apply them and show the preview again. Do not proceed until the user confirms.

在执行任何操作前，向用户展示完整的PR供其确认：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 PR 预览
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
标题:       <generated title>
目标分支:      <target_branch>
源分支:      <current_branch>
评审人:   <reviewer list>
标签:      <label list or "none">
状态:      草稿

描述:
<generated description>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

询问用户："Does this look good? I'll create the draft PR once you confirm. Let me know if you'd like to change anything."

如果用户要求修改，调整后再次展示预览。用户确认前不可继续操作。

Step 8: Create the PR

步骤8：创建PR

Once confirmed, execute:

bash

gh pr create \
  --base "<target_branch>" \
  --head "<current_branch>" \
  --title "<title>" \
  --body "<description>" \
  --draft \
  --reviewer "<reviewer1>,<reviewer2>" \
  --label "<label1>,<label2>"

Omit

--label

if no labels were selected. Use comma-separated usernames for

--reviewer

(e.g.,

--reviewer "alice,bob"

). For team reviewers, use a separate

--reviewer

flag (e.g.,

--reviewer myorg/team-name

After successful creation, share the PR URL with the user.

If the command fails, show the error and help the user troubleshoot (common issues:

gh

not authenticated, branch not pushed to remote, reviewer username doesn't exist).

确认后执行以下命令：

bash

gh pr create \
  --base "<target_branch>" \
  --head "<current_branch>" \
  --title "<title>" \
  --body "<description>" \
  --draft \
  --reviewer "<reviewer1>,<reviewer2>" \
  --label "<label1>,<label2>"

如果没有选择标签则省略

--label

参数。

--reviewer

使用逗号分隔的用户名（例如

--reviewer "alice,bob"

）。如果是团队评审人，使用单独的

--reviewer

参数（例如

--reviewer myorg/team-name

）。

创建成功后，将PR的URL分享给用户。

如果命令执行失败，展示错误信息并协助用户排查（常见问题：

gh

未完成身份验证、分支未推送到远程、评审人用户名不存在）。

Platform Adaptation

平台适配

This skill defaults to GitHub CLI (

gh

). If the remote URL indicates a different platform, mention the equivalent commands:

GitLab (
glab
):

bash

glab mr create \
  --target-branch "<target>" \
  --title "<title>" \
  --description "<description>" \
  --draft \
  --reviewer "<reviewers>"

Bitbucket: The

bb

CLI or Bitbucket API can be used, but workflows vary. Suggest the user consult their team's tooling.

The title format, description structure, and review workflow remain the same regardless of platform.

本技能默认使用GitHub CLI (

gh

)。如果远程URL显示为其他平台，告知用户对应的等价命令：

GitLab (
glab
):

bash

glab mr create \
  --target-branch "<target>" \
  --title "<title>" \
  --description "<description>" \
  --draft \
  --reviewer "<reviewers>"

Bitbucket：可使用

bb

CLI或Bitbucket API，但工作流程差异较大，建议用户参考团队的工具规范。

无论使用什么平台，标题格式、描述结构和评审工作流都保持不变。