create-draft-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create Draft PR

创建草稿PR

Commit all changes, push to remote, and create a draft pull request with a focused generated description.

提交所有更改，推送至远程仓库，并生成一份重点突出的描述来创建草稿拉取请求（PR）。

Steps

步骤

Run
```
git status
```
to see changes
Run
```
git diff
```
to understand what changed
Run
```
git log
```
to see commit message style
If on
```
main
```
, create a new branch in the format
```
<initials>/<feature>
```
or the project's branch naming convention, then switch to it
Stage and commit changes with a concise message
Push branch to remote with
```
-u
```
flag
Generate the PR description using the
```
pr-description
```
skill's description format.
If the change is user-facing, workflow-oriented, or architectural, include a concise UX flow section using the
```
ux-flow-plan
```
style.
Create draft PR using
```
gh pr create --draft
```
If you created the branch (were on
```
main
```
), switch back to
```
main
```
after the PR is created

运行
```
git status
```
查看更改内容
运行
```
git diff
```
了解具体变更
运行
```
git log
```
查看提交消息风格
如果当前在
```
main
```
分支，按照
```
<首字母缩写>/<功能>
```
格式或项目的分支命名规范创建新分支，然后切换到该分支
暂存并提交更改，使用简洁的提交消息
使用
```
-u
```
参数将分支推送至远程仓库
使用
```
pr-description
```
技能的描述格式生成PR描述
如果变更涉及用户界面、工作流程或架构，使用
```
ux-flow-plan
```
风格添加简洁的UX流程章节
使用
```
gh pr create --draft
```
创建草稿PR
如果是从
```
main
```
分支创建的新分支，PR创建完成后切换回
```
main
```
分支

PR Body Format

PR正文格式

Use the

pr-description

skill's format as the base:

markdown

undefined

以

pr-description

技能的格式为基础：

markdown

undefined

Summary

Additional note if needed
Another note if needed

<一句话描述整体变更>

如有需要可添加补充说明
如有需要可添加另一项补充说明

Problem

Describe the issue being addressed. What was broken, missing, or suboptimal? Be specific about the root cause.

描述要解决的问题。指出存在哪些故障、缺失或不够优化的地方？明确说明根本原因。

Solution

Explain the approach taken to fix the problem. Include code snippets only when they clarify the core approach.


When relevant, add this section between `Problem` and `Solution`:

````markdown

解释解决问题所采用的方法。仅在有助于阐明核心方法时才包含代码片段。


必要时，在`Problem`和`Solution`之间添加以下章节：

````markdown

UX Flow

text

Current flow
└─ ...

Desired flow
└─ ...


Only include `UX Flow` when it helps explain the product behavior, user journey, or architecture boundary. Keep it short and use the `ux-flow-plan` tree style.

text

当前流程
└─ ...

期望流程
└─ ...


仅当UX流程有助于解释产品行为、用户旅程或架构边界时才添加该部分。保持内容简短，使用`ux-flow-plan`的树形格式。

Rules

规则

PR title should be succinct (no "feat:" prefix, but "fix:" is ok for bug fixes)
Use
```
pr-description
```
as the source of truth for PR body structure.
Include
```
UX Flow
```
from
```
ux-flow-plan
```
only when relevant; omit it for mechanical, dependency, or tiny internal changes.
Do NOT include a file-by-file summary of code changes.
Do NOT include a test plan with checkboxes.
Do NOT include "Generated with Claude Code" or similar footers
Keep the PR description concise and focused on intent and approach
Use HEREDOC for the PR body to preserve formatting

PR标题应简洁（无需“feat:”前缀，但修复bug时可使用“fix:”）
以
```
pr-description
```
作为PR正文结构的权威标准
仅在必要时从
```
ux-flow-plan
```
中引入
```
UX Flow
```
；对于机械性变更、依赖更新或微小内部变更，可省略该部分
请勿包含逐文件的代码变更摘要
请勿包含带复选框的测试计划
请勿添加“Generated with Claude Code”或类似的页脚
PR描述应简洁，重点关注变更意图和实现方法
使用HEREDOC来保留PR正文的格式