create-pull-request

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create Pull Request

创建Pull Request

This skill guides you through creating a well-structured GitHub pull request that follows project conventions and best practices.

本技能将引导你创建结构规范、符合项目惯例与最佳实践的GitHub Pull Request。

Prerequisites Check

前置条件检查

Before proceeding, verify the following:

开始操作前，请验证以下内容：

1. Check if

gh

CLI is installed

1. 检查是否已安装

gh

CLI

bash

gh --version

If not installed, inform the user:

The GitHub CLI (
gh
) is required but not installed. Please install it:
macOS:
brew install gh
Other: https://cli.github.com/

bash

gh --version

如果未安装，请告知用户：

GitHub CLI（
gh
）是必需工具但尚未安装，请进行安装：
macOS：
brew install gh
其他系统：https://cli.github.com/

2. Check if authenticated with GitHub

2. 检查是否已通过GitHub认证

bash

gh auth status

If not authenticated, guide the user to run

gh auth login

bash

gh auth status

如果未认证，引导用户运行

gh auth login

。

3. Check for related skills

3. 检查相关技能

Before creating a PR, check if any skills are available that relate to code review, CI, or testing. These should be invoked first as prerequisites.

Look for skills with descriptions containing:

"review" (e.g., code review, PR review, web-design-guidelines)
"CI" or "ci-fix" (e.g., fixing CI failures)
"testing" or "test" (e.g., running tests, webapp-testing)

If such skills exist, invoke them before proceeding with PR creation. For example:

If a
```
ci-fix
```
skill exists and CI is failing, use it to diagnose and fix issues
If a
```
web-design-guidelines
```
skill exists for UI changes, use it to review the changes
If a testing skill exists, use it to ensure tests pass

Only proceed with PR creation after these prerequisite skills have been satisfied.

在创建PR之前，请检查是否存在与代码审核、CI或测试相关的技能。这些技能应作为前置条件优先调用。

寻找描述中包含以下关键词的技能：

"review"（例如：代码审核、PR审核、web-design-guidelines）
"CI"或"ci-fix"（例如：修复CI失败问题）
"testing"或"test"（例如：运行测试、webapp-testing）

如果存在此类技能，请在创建PR之前调用它们。例如：

如果存在
```
ci-fix
```
技能且CI运行失败，使用该技能诊断并修复问题
如果针对UI更改存在
```
web-design-guidelines
```
技能，使用该技能审核更改
如果存在测试技能，使用该技能确保测试通过

只有在满足这些前置技能的要求后，才能继续创建PR。

4. Verify clean working directory

4. 验证工作目录是否干净

bash

git status

If there are uncommitted changes, ask the user whether to:

Commit them as part of this PR
Stash them temporarily
Discard them (with caution)

bash

git status

如果存在未提交的更改，请询问用户选择以下操作：

将这些更改作为本次PR的一部分提交
暂时暂存这些更改
丢弃这些更改（请谨慎操作）

Check for Existing PR

检查是否存在现有PR

Before gathering context, check if a PR already exists for the current branch:

bash

gh pr list --head $(git branch --show-current) --json number,title,url

If a PR already exists:

Display the existing PR details (number, title, URL)
Ask the user if they want to:
- View the existing PR:
```
gh pr view
```
- Update the existing PR (push more commits and the PR will update automatically)
- Close the existing PR and create a new one

Only proceed with creating a new PR if no PR exists for this branch.

在收集上下文信息之前，检查当前分支是否已存在对应的PR：

bash

gh pr list --head $(git branch --show-current) --json number,title,url

如果已存在PR：

显示现有PR的详细信息（编号、标题、URL）
询问用户是否需要：
- 查看现有PR：
```
gh pr view
```
- 更新现有PR（推送更多提交后PR会自动更新）
- 关闭现有PR并创建新的PR

只有当当前分支不存在PR时，才能继续创建新的PR。

Gather Context

收集上下文信息

1. Identify the current branch

1. 确定当前分支

bash

git branch --show-current

Ensure you're not on

main

master

. If so, ask the user to create or switch to a feature branch.

bash

git branch --show-current

确保当前分支不是

main

或

master

。如果是，请询问用户创建或切换到功能分支。

2. Find the base branch

2. 找到基准分支

bash

git remote show origin | grep "HEAD branch"

This is typically

main

master

bash

git remote show origin | grep "HEAD branch"

基准分支通常为

main

或

master

。

3. Analyze recent commits relevant to this PR

3. 分析与本次PR相关的近期提交

bash

git log origin/main..HEAD --oneline --no-decorate

Review these commits to understand:

What changes are being introduced
The scope of the PR (single feature/fix or multiple changes)
Whether commits should be squashed or reorganized

bash

git log origin/main..HEAD --oneline --no-decorate

查看这些提交以了解：

引入了哪些更改
PR的范围（单个功能/修复或多项更改）
是否需要合并或重新整理提交

4. Review the diff

4. 查看差异

bash

git diff origin/main..HEAD --stat

This shows which files changed and helps identify the type of change.

bash

git diff origin/main..HEAD --stat

该命令会显示哪些文件被修改，帮助确定更改类型。

Information Gathering

信息收集

Gather the following information from available context (commit messages, branch names, changed files):

从现有上下文（提交信息、分支名称、修改的文件）中收集以下信息：

Information to Extract

需要提取的信息

Related Issue Number: Look for patterns like
```
#123
```
,
```
fixes #123
```
, or
```
closes #123
```
in:
- Commit messages
- Branch name (e.g.,
```
fix/issue-123
```
  ,
```
feature/123-new-login
```
  )
- If found, include it in the PR title and/or description
- If not found, proceed without it
Description: What problem does this solve? Why were these changes made?
- Infer from commit messages and diff
- Describe the changes made
Type of Change: Bug fix, new feature, breaking change, refactor, cosmetic, documentation, or workflow
- Determine from commit messages and changed files
Test Procedure: How was this tested? What could break?
- Mention test files if they were modified
- Describe testing approach if evident from changes

相关问题编号：在以下位置查找类似
```
#123
```
、
```
fixes #123
```
或
```
closes #123
```
的格式：
- 提交信息
- 分支名称（例如：
```
fix/issue-123
```
  、
```
feature/123-new-login
```
  ）
- 如果找到，请将其包含在PR标题和/或描述中
- 如果未找到，可跳过
描述：本次更改解决了什么问题？为什么要进行这些更改？
- 从提交信息和差异中推断
- 描述所做的更改
更改类型：Bug修复、新功能、破坏性更改、重构、界面优化、文档更新或工作流调整
- 根据提交信息和修改的文件确定
测试流程：如何测试的？哪些部分可能受影响？
- 如果修改了测试文件，请提及
- 如果从更改中可以看出测试方法，请进行描述

Intelligent PR Title Generation

智能PR标题生成

The PR title should be descriptive and meaningful. Avoid generic titles like:

"initial commit"
"fix"
"update"
"changes"

Instead, create a title that clearly summarizes the changes. Consider these approaches:

PR标题应具有描述性且表意明确。避免使用通用标题，例如：

"initial commit"
"fix"
"update"
"changes"

相反，创建一个能清晰概括更改内容的标题。可以参考以下方法：

1. Conventional Commits Format

1. 约定式提交格式

Check if the project uses conventional commits by analyzing:

Commit messages for patterns like
```
feat:
```
,
```
fix:
```
,
```
docs:
```
,
```
refactor:
```
,
```
test:
```
,
```
chore:
```
Branch name prefixes like
```
feat/
```
,
```
fix/
```
,
```
docs/
```

If conventional commits are detected, use the appropriate prefix for the PR title:

feat: Add user authentication with OAuth

fix: Resolve memory leak in data processing

docs: Update API documentation for v2 endpoints

```
refactor: Simplify error handling logic
```

test: Add integration tests for payment flow

chore: Update dependencies to latest versions

Include issue number if found:

feat: Add user authentication with OAuth (#123)

fix(auth): Resolve memory leak in data processing (fixes #456)

通过分析以下内容检查项目是否使用约定式提交：

提交信息中的模式，如
```
feat:
```
、
```
fix:
```
、
```
docs:
```
、
```
refactor:
```
、
```
test:
```
、
```
chore:
```
分支名称前缀，如
```
feat/
```
、
```
fix/
```
、
```
docs/
```

如果检测到使用约定式提交，请为PR标题使用适当的前缀：

feat: Add user authentication with OAuth

fix: Resolve memory leak in data processing

docs: Update API documentation for v2 endpoints

```
refactor: Simplify error handling logic
```

test: Add integration tests for payment flow

chore: Update dependencies to latest versions

如果找到问题编号，请包含在内：

feat: Add user authentication with OAuth (#123)

fix(auth): Resolve memory leak in data processing (fixes #456)

2. Descriptive Summary

2. 描述性摘要

If not using conventional commits, create a clear, action-oriented title:

Good: "Add pagination to search results"
Bad: "initial commit"
Good: "Fix race condition in authentication flow"
Bad: "fix bug"

Include issue number if found:

"Add pagination to search results (#123)"
"Fix race condition in authentication flow (fixes #456)"

如果不使用约定式提交，请创建清晰、面向动作的标题：

推荐："Add pagination to search results"
不推荐："initial commit"
推荐："Fix race condition in authentication flow"
不推荐："fix bug"

如果找到问题编号，请包含在内：

"Add pagination to search results (#123)"
"Fix race condition in authentication flow (fixes #456)"

3. Title Generation Strategy

3. 标题生成策略

Look at the most significant commit message (often the first or last)
Identify the main change from the diff (new feature, bug fix, etc.)
Extract the issue title if linked
If none of these provide a good title, synthesize one from the changed files and their purpose
Append issue number to title if found in commits or branch name

查看最重要的提交信息（通常是第一个或最后一个）
从差异中确定主要更改（新功能、Bug修复等）
如果关联了问题，提取问题标题
如果以上都无法生成合适标题，根据修改的文件及其用途综合生成
如果在提交或分支名称中找到问题编号，将其附加到标题中

Git Best Practices

Git最佳实践

Before creating the PR, consider these best practices:

在创建PR之前，请遵循以下最佳实践：

Commit Hygiene

提交规范

Atomic commits: Each commit should represent a single logical change
Clear commit messages: Follow conventional commit format when possible
No merge commits: Prefer rebasing over merging to keep history clean

原子提交：每个提交应代表一个独立的逻辑更改
清晰的提交信息：尽可能遵循约定式提交格式
无合并提交：优先使用变基（rebase）而非合并，以保持提交历史整洁

Branch Management

分支管理

Rebase on latest main (if needed):
bash
```
git fetch origin
git rebase origin/main
```
Squash if appropriate: If there are many small "WIP" commits, consider interactive rebase:
bash
```
git rebase -i origin/main
```
Only suggest this if commits appear messy and the user is comfortable with rebasing.

基于最新的main分支变基（如有需要）：
bash
```
git fetch origin
git rebase origin/main
```
适当合并提交：如果存在许多小型的"WIP"（工作中）提交，可以考虑交互式变基：
bash
```
git rebase -i origin/main
```
仅当提交历史混乱且用户熟悉变基操作时，才建议使用此方法。

Push Changes

推送更改

Ensure all commits are pushed:

bash

git push origin HEAD

If the branch was rebased, you may need:

bash

git push origin HEAD --force-with-lease

确保所有提交都已推送：

bash

git push origin HEAD

如果分支已变基，可能需要执行：

bash

git push origin HEAD --force-with-lease

Create the Pull Request

创建Pull Request

IMPORTANT: Read and use the PR template at

.github/pull_request_template.md

if it exists. The PR body format should match the template structure.

When filling out the template:

Include issue number (e.g.,
```
Fixes #123
```
,
```
Closes #456
```
) if found in context
If no template exists, create a clear description with:
- Summary of changes
- Related issue (if found)
- Testing performed
- Any breaking changes or notable impacts
Fill in all sections with relevant information gathered from commits and context
Mark the appropriate "Type of Change" checkbox(es) if template has them
Complete any checklist items that apply

重要提示：如果项目中存在

.github/pull_request_template.md

PR模板，请阅读并使用该模板。PR正文格式应与模板结构一致。

填写模板时：

如果在上下文中找到问题编号，请包含（例如：
```
Fixes #123
```
、
```
Closes #456
```
）
如果没有模板，请创建清晰的描述，包含：
- 更改摘要
- 相关问题（如果找到）
- 执行的测试
- 任何破坏性更改或显著影响
用从提交和上下文中收集的相关信息填写所有部分
如果模板包含"更改类型"复选框，请勾选相应选项
完成所有适用的检查项

Draft PR Decision

草稿PR决策

Decide whether to create a draft PR or a regular PR based on the following:

Use
--draft
flag when:

Changes are incomplete or work-in-progress, but you want early feedback
Tests are currently failing and you need help debugging
You're blocked on an architectural decision and need guidance
Creating the PR as a bookmark for work you'll continue later
You want to trigger CI checks but aren't ready for full review

Use regular PR (no
--draft
) when:

All tests pass and code is ready for review
Changes are complete and you're confident in the approach
You want the PR to be reviewed and merged soon

根据以下情况决定创建草稿PR还是常规PR：

使用
--draft
标记的场景：

更改尚未完成或仍在进行中，但需要提前获取反馈
测试当前失败，需要帮助调试
在架构决策上受阻，需要指导
将PR作为后续工作的书签
想要触发CI检查但尚未准备好全面审核

使用常规PR（不添加
--draft
）的场景：

所有测试通过，代码已准备好审核
更改已完成，且对实现方式有信心
希望PR尽快被审核并合并

Create PR with gh CLI

通过gh CLI创建PR

For a regular PR:

bash

gh pr create --title "PR_TITLE" --body "PR_BODY" --base main

For a draft PR:

bash

gh pr create --title "PR_TITLE" --body "PR_BODY" --base main --draft

创建常规PR：

bash

gh pr create --title "PR_TITLE" --body "PR_BODY" --base main

创建草稿PR：

bash

gh pr create --title "PR_TITLE" --body "PR_BODY" --base main --draft

Post-Creation

创建后操作

After creating the PR:

创建PR后：

1. Open PR in browser for verification

1. 在浏览器中打开PR进行验证

Immediately open the PR in the browser to verify it was created correctly:

bash

gh pr view --web

This allows you to:

Verify the PR title and description render correctly
Check that all links work (issue references, etc.)
Ensure the diff looks as expected
See any immediate CI status

立即在浏览器中打开PR，验证其创建是否正确：

bash

gh pr view --web

通过此操作可以：

验证PR标题和描述是否正确显示
检查所有链接是否可用（问题引用等）
确保差异显示符合预期
查看即时的CI状态

2. Remind about CI checks

2. 提醒关注CI检查

Tests and linting will run automatically. Monitor the checks to ensure they pass.

测试和代码检查将自动运行。请监控检查结果以确保其通过。

3. Suggest next steps (if needed)

3. 建议后续步骤（如有需要）

Add reviewers if needed:
```
gh pr edit --add-reviewer USERNAME
```
Add labels if needed:
```
gh pr edit --add-label "bug"
```

添加审核者：
```
gh pr edit --add-reviewer USERNAME
```
添加标签：
```
gh pr edit --add-label "bug"
```

Error Handling

错误处理

Common Issues

常见问题

No commits ahead of main: The branch has no changes to submit
- Ask if the user meant to work on a different branch
Branch not pushed: Remote doesn't have the branch
- Push the branch first:
```
git push -u origin HEAD
```
PR already exists: A PR for this branch already exists
- Show the existing PR:
```
gh pr view
```
- Ask if they want to update it instead
Merge conflicts: Branch conflicts with base
- Guide user through resolving conflicts or rebasing

没有比main分支新的提交：当前分支没有可提交的更改
- 询问用户是否打算在其他分支上工作
分支未推送：远程仓库中不存在该分支
- 先推送分支：
```
git push -u origin HEAD
```
PR已存在：当前分支对应的PR已存在
- 显示现有PR：
```
gh pr view
```
- 询问用户是否要更新现有PR
合并冲突：当前分支与基准分支存在冲突
- 指导用户解决冲突或进行变基

Summary Checklist

总结检查清单

Before finalizing, ensure:

```
gh
```
CLI is installed and authenticated
Related review/CI/testing skills have been invoked
No existing PR exists for this branch
Working directory is clean
All commits are pushed
Branch is up-to-date with base branch
PR title is descriptive and meaningful (not generic)
PR title uses conventional commit format if project uses it
Issue number included in title/description if found in context
PR description follows template (if template exists)
Appropriate type of change is selected
Correct draft/regular status chosen
PR opened in browser for verification

最终确认前，请确保：

```
gh
```
CLI已安装并完成认证
已调用相关的审核/CI/测试技能
当前分支不存在现有PR
工作目录干净
所有提交已推送
分支已与基准分支同步
PR标题具有描述性且表意明确（非通用标题）
如果项目使用约定式提交，PR标题遵循该格式
如果在上下文中找到问题编号，已包含在标题/描述中
PR描述遵循模板（如果存在模板）
已选择正确的更改类型
已选择正确的草稿/常规状态
已在浏览器中打开PR进行验证

create-pull-request

Original

Translation

Create Pull Request

创建Pull Request

Prerequisites Check

前置条件检查

1. Check if gh CLI is installed

1. 检查是否已安装gh CLI

2. Check if authenticated with GitHub

2. 检查是否已通过GitHub认证

3. Check for related skills

3. 检查相关技能

4. Verify clean working directory

4. 验证工作目录是否干净

Check for Existing PR

检查是否存在现有PR

Gather Context

收集上下文信息

1. Identify the current branch

1. 确定当前分支

2. Find the base branch

2. 找到基准分支

3. Analyze recent commits relevant to this PR

3. 分析与本次PR相关的近期提交

4. Review the diff

4. 查看差异

Information Gathering

信息收集

Information to Extract

需要提取的信息

Intelligent PR Title Generation

智能PR标题生成

1. Conventional Commits Format

1. 约定式提交格式

2. Descriptive Summary

2. 描述性摘要

3. Title Generation Strategy

3. 标题生成策略

Git Best Practices

Git最佳实践

Commit Hygiene

提交规范

Branch Management

分支管理

Push Changes

推送更改

Create the Pull Request

创建Pull Request

Draft PR Decision

草稿PR决策

Create PR with gh CLI

通过gh CLI创建PR

Post-Creation

创建后操作

1. Open PR in browser for verification

1. 在浏览器中打开PR进行验证

2. Remind about CI checks

2. 提醒关注CI检查

3. Suggest next steps (if needed)

3. 建议后续步骤（如有需要）

Error Handling

错误处理

Common Issues

常见问题

Summary Checklist

总结检查清单

1. Check if
`gh`
CLI is installed

1. 检查是否已安装
`gh`
CLI