create-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

<EXTREMELY-IMPORTANT> Before creating ANY pull request, you **ABSOLUTELY MUST**:

Verify you're NOT on main/master/develop
Check for uncommitted changes (invoke commit skill first if any)
Read the FULL diff against base branch (not just commit messages)
Scan for breaking changes and document them
Push the branch before creating the PR

Creating PRs without verification = broken builds, missing context, failed reviews

This is not optional. Every PR requires disciplined preparation. </EXTREMELY-IMPORTANT>

<EXTREMELY-IMPORTANT> 在创建任何pull request之前，你**绝对必须**：

确认你不在main/master/develop分支上
检查是否有未提交的变更（如果有，先调用commit技能）
查看与基准分支的完整差异（不只是提交信息）
扫描破坏性变更并记录
创建PR前先推送分支

未验证就创建PR会导致构建失败、上下文缺失、审核不通过

这不是可选步骤。每个PR都需要严谨的准备工作。 </EXTREMELY-IMPORTANT>

Create Pull Request

创建Pull Request

MANDATORY FIRST RESPONSE PROTOCOL

必须遵循的首次响应协议

Before creating ANY PR, you MUST complete this checklist:

☐ Run
```
git branch --show-current
```
— verify NOT on protected branch
☐ Run
```
git status --short
```
— invoke commit skill if uncommitted changes
☐ Run
```
git log main..HEAD
```
— verify commits exist
☐ Run
```
git diff main...HEAD
```
— read FULL diff (not just commit messages)
☐ Check for conflict markers in changed files
☐ Identify breaking changes (removed exports, schema changes, API changes)
☐ Determine PR type, scope, size, and risk
☐ Announce: "Creating PR: type: [title]"

Creating PRs WITHOUT completing this checklist = incomplete reviews and rework.

在创建任何PR之前，你必须完成以下检查清单：

☐ 运行
```
git branch --show-current
```
— 确认不在受保护分支上
☐ 运行
```
git status --short
```
— 如果有未提交变更，调用commit技能
☐ 运行
```
git log main..HEAD
```
— 确认存在提交
☐ 运行
```
git diff main...HEAD
```
— 查看完整差异（不只是提交信息）
☐ 检查变更文件中是否有冲突标记
☐ 识别破坏性变更（移除的导出、 schema 变更、API变更）
☐ 确定PR的类型、范围、大小和风险
☐ 通知："正在创建PR: 类型: [标题]"

未完成此检查清单就创建PR会导致审核不完整和返工。

Overview

概述

Validate branch readiness, analyze all commits since divergence from base, generate a structured PR with meaningful title and body, push to remote, and create via

gh pr create

. If uncommitted changes exist, invoke the

commit

skill first.

验证分支是否就绪，分析与基准分支分叉后的所有提交，生成包含有意义标题和正文的结构化PR，推送到远程仓库，并通过

gh pr create

命令创建PR。如果存在未提交的变更，先调用

commit

技能。

When to Use

使用场景

User says "create PR", "open PR", "submit PR", "/pr", "make a PR"
User says "push and create PR" or "send this for review"
After completing work and user wants to submit for review
$ARGUMENTS provided as PR guidance (e.g.,
```
/pr add auth feature
```
)

Never create a PR proactively. Only when explicitly requested.

用户说"create PR"、"open PR"、"submit PR"、"/pr"、"make a PR"
用户说"push and create PR"或"send this for review"
完成工作后用户希望提交审核
提供$ARGUMENTS作为PR指导（例如：
```
/pr add auth feature
```
）

绝不要主动创建PR。仅在明确请求时执行。

Step 1: Gather Branch Context

步骤1：收集分支上下文

Gate: Full context collected before proceeding to Step 2.

Run these commands to understand the full picture:

bash

undefined

** Gate：收集完完整上下文后再进入步骤2 **

运行以下命令以全面了解情况：

bash

undefined

Current branch name

当前分支名称

git branch --show-current

Check if branch tracks a remote

检查分支是否跟踪远程仓库

git status -sb

Uncommitted changes (never use -uall)

未提交的变更（绝不使用-uall）

git status --short

Find the base branch (main or master)

查找基准分支（main或master）

git log --oneline --decorate -1 origin/main 2>/dev/null || git log --oneline --decorate -1 origin/master 2>/dev/null

All commits on this branch since diverging from base

该分支与基准分支分叉后的所有提交

git log --oneline main..HEAD 2>/dev/null || git log --oneline master..HEAD 2>/dev/null

Full diff against base branch (what the PR will contain)

与基准分支的完整差异（PR将包含的内容）

git diff main...HEAD 2>/dev/null || git diff master...HEAD 2>/dev/null


**Read the actual diff output.** You need the full diff to write an accurate PR summary — not just commit messages.

git diff main...HEAD 2>/dev/null || git diff master...HEAD 2>/dev/null


**务必阅读实际的差异输出。你需要完整差异来编写准确的PR摘要 — 而不只是提交信息。**

Determine Base Branch

确定基准分支

Use this priority:

If user specifies a base branch in $ARGUMENTS, use it

Check for

main

branch:

git rev-parse --verify origin/main 2>/dev/null

Check for

master

branch:

git rev-parse --verify origin/master 2>/dev/null

Check for

develop

branch:

git rev-parse --verify origin/develop 2>/dev/null

If none found, ask the user

Store as

$BASE_BRANCH

for all subsequent steps.

按以下优先级选择：

如果用户在$ARGUMENTS中指定了基准分支，使用该分支

检查是否存在

main

分支：

git rev-parse --verify origin/main 2>/dev/null

检查是否存在

master

分支：

git rev-parse --verify origin/master 2>/dev/null

检查是否存在

develop

分支：

git rev-parse --verify origin/develop 2>/dev/null

如果以上都未找到，询问用户

将其存储为

$BASE_BRANCH

，供后续所有步骤使用。

Step 2: Pre-PR Validation

步骤2：PR创建前验证

Gate: Branch ready (commits exist, no uncommitted changes) before proceeding to Step 3.

** Gate：分支就绪（存在提交、无未提交变更）后再进入步骤3 **

Uncommitted Changes

未提交的变更

git status --short

shows changes:

Invoke the
commit
skill using the Skill tool:

Use the Skill tool with skill="commit"

The commit skill handles staging, quality checks, and committing
After commit completes, re-run Step 1 to pick up the new commit(s)
Continue with the updated branch state

如果

git status --short

显示有变更：

调用
commit
技能：使用Skill工具，命令为

Use the Skill tool with skill="commit"

commit技能会处理暂存、质量检查和提交操作
commit完成后，重新运行步骤1以获取新的提交
使用更新后的分支状态继续操作

Empty Branch

空分支

git log $BASE_BRANCH..HEAD

shows no commits:

Stop. "No commits found on this branch relative to $BASE_BRANCH. Nothing to create a PR for."

如果

git log $BASE_BRANCH..HEAD

显示没有提交：

停止操作。"相对于$BASE_BRANCH，该分支上没有找到提交。没有内容可创建PR。"

Branch Naming

分支命名验证

Validate branch name is not

main

master

, or

develop

If on a protected branch, stop: "You're on $BRANCH. Create a feature branch first."

确认分支名称不是

main

、

master

或

develop

：

如果在受保护分支上，停止操作："你当前在$BRANCH分支上。请先创建功能分支。"

Step 3: Analyze All Commits

步骤3：分析所有提交

Gate: PR classified (type, scope, size, risk) before proceeding to Step 4.

Read every commit in the branch — not just the latest:

bash

undefined

** Gate：PR已分类（类型、范围、大小、风险）后再进入步骤4 **

阅读分支中的每个提交 — 不只是最新的提交：

bash

undefined

All commits with full messages

包含完整信息的所有提交

git log --format="%h %s%n%b%n---" $BASE_BRANCH..HEAD

File change summary across all commits

所有提交的文件变更摘要

git diff --stat $BASE_BRANCH...HEAD

Full diff for understanding scope

用于了解范围的完整差异

git diff $BASE_BRANCH...HEAD

undefined

git diff $BASE_BRANCH...HEAD

undefined

Classify the PR

对PR进行分类

Based on ALL commits and the full diff, determine:

Aspect	How to Determine
Type	Feature ( `feat` ), bugfix ( `fix` ), refactor, docs, chore — from commit types and actual changes
Scope	Primary area affected — from file paths and branch name
Size	S (1-3 files), M (4-10 files), L (11-25 files), XL (26+ files)
Risk	Low (docs, tests), Medium (new feature), High (breaking changes, core logic, DB migrations)
Breaking	Any API changes, removed endpoints, schema changes, renamed exports

基于所有提交和完整差异，确定：

维度	判定方式
类型	功能（ `feat` ）、 bug修复（ `fix` ）、重构、文档、杂项 — 来自提交类型和实际变更
范围	主要受影响的区域 — 来自文件路径和分支名称
大小	S（1-3个文件）、M（4-10个文件）、L（11-25个文件）、XL（26个以上文件）
风险	低（文档、测试）、中（新功能）、高（破坏性变更、核心逻辑、数据库迁移）
破坏性	任何API变更、移除的端点、schema变更、重命名的导出

Detect Breaking Changes

检测破坏性变更

Scan the diff for:

Removed or renamed public exports
Changed function signatures
Database migration files (schema changes)
API endpoint changes (routes added/removed/changed)
Environment variable changes
Package dependency major version bumps

If breaking changes detected, they MUST appear in the PR body.

扫描差异以查找：

移除或重命名的公共导出
更改的函数签名
数据库迁移文件（schema变更）
API端点变更（添加/移除/更改的路由）
环境变量变更
依赖包主版本升级

如果检测到破坏性变更，必须在PR正文中列出。

Step 4: Pre-PR Quality Checks

步骤4：PR创建前质量检查

Gate: No blocking issues before proceeding to Step 5.

Run quality gates across the entire branch diff:

bash

undefined

** Gate：无阻塞问题后再进入步骤5 **

对整个分支差异运行质量检查：

bash

undefined

TypeScript type check

TypeScript类型检查

npx tsc --noEmit

ESLint (if configured)

ESLint（如果已配置）

ls .eslintrc* eslint.config.* 2>/dev/null && git diff --name-only $BASE_BRANCH...HEAD -- '*.ts' | xargs npx eslint

Conflict markers in any changed file

变更文件中的冲突标记

git diff --name-only $BASE_BRANCH...HEAD | xargs grep -n '<<<<<<<|=======|>>>>>>>' 2>/dev/null

undefined

git diff --name-only $BASE_BRANCH...HEAD | xargs grep -n '<<<<<<<|=======|>>>>>>>' 2>/dev/null

undefined

If Checks Fail

如果检查失败

Conflict markers: Block. Must resolve before creating PR.
Type errors: Warn user. Recommend fixing. Ask whether to proceed.
Lint errors: Show errors. Offer auto-fix. Recommend fixing.

Quality issues are warnings for PRs (reviewer can catch them) — except conflict markers which always block.

冲突标记：阻塞。必须解决后才能创建PR。
类型错误：警告用户。建议修复。询问是否继续。
Lint错误：显示错误。提供自动修复选项。建议修复。

质量问题是PR的警告（审核人员会发现） — 但冲突标记始终会阻塞操作。

Step 5: Generate PR Title

步骤5：生成PR标题

Gate: Title follows conventions before proceeding to Step 6.

** Gate：标题遵循规范后再进入步骤6 **

Format

格式

<type>(<scope>): <concise description>

<类型>(<范围>): <简洁描述>

Rules

规则

Under 72 characters
Imperative mood: "add feature" not "added feature"
No period at the end
If breaking change, add
```
!
```
:
```
feat(api)!: remove legacy endpoint
```
Scope from branch name or primary file path area
Must reflect ALL changes, not just the last commit

长度不超过72个字符
使用祈使语气："add feature"而非"added feature"
结尾不加句号
如果是破坏性变更，添加
```
!
```
：
```
feat(api)!: remove legacy endpoint
```
范围来自分支名称或主要文件路径区域
必须反映所有变更，不只是最后一次提交

Title from Branch Name

从分支名称生成标题

Use branch name as a hint, verify against actual changes:

Branch Likely Title

Branch	Likely Title
`feat/add-auth-system`	`feat(auth): add JWT authentication system`
`fix/cart-total-calculation`	`fix(cart): correct total calculation with discounts`
`refactor/search-service`	`refactor(search): restructure search service architecture`

feat/add-auth-system

feat(auth): add JWT authentication system

fix/cart-total-calculation

fix(cart): correct total calculation with discounts

refactor/search-service

refactor(search): restructure search service architecture

If $ARGUMENTS contains a clear title, use it (respecting format rules).

将分支名称作为参考，结合实际变更验证：

分支名称可能的标题

分支名称	可能的标题
`feat/add-auth-system`	`feat(auth): add JWT authentication system`
`fix/cart-total-calculation`	`fix(cart): correct total calculation with discounts`
`refactor/search-service`	`refactor(search): restructure search service architecture`

feat/add-auth-system

feat(auth): add JWT authentication system

fix/cart-total-calculation

fix(cart): correct total calculation with discounts

refactor/search-service

refactor(search): restructure search service architecture

如果$ARGUMENTS中包含明确的标题，使用该标题（需符合格式规则）。

Step 6: Generate PR Body

步骤6：生成PR正文

Gate: Body has all required sections before proceeding to Step 7.

Use this template with HEREDOC:

markdown

undefined

** Gate：正文包含所有必填部分后再进入步骤7 **

使用HEREDOC模板：

markdown

undefined

Summary

摘要

<3-5 bullet points describing WHAT changed and WHY>

<3-5个要点描述变更内容和原因>

Changes

变更内容

<按区域分组 — 列出主要变更的文件/模块>

<Area 1>

<区域1>

description of change

变更描述

<Area 2>

<区域2>

description of change

变更描述

Breaking Changes

破坏性变更

What broke
Migration steps

<仅当步骤3中检测到破坏性变更时添加。否则完全省略。>

受影响的内容
迁移步骤

Test Plan

测试计划

Notes

备注

<Optional: deployment notes, config changes, dependencies added>

undefined

<可选：部署说明、配置变更、添加的依赖>

undefined

Body Writing Rules

正文编写规则

Summary bullets: Focus on "why" and business impact, not just "what"
Changes section: Group by module/area, not by commit
Test Plan: Specific, actionable items a reviewer can verify — not generic "run tests"
Breaking Changes: Include migration steps if applicable
Notes: Mention new env vars, DB migrations, service dependencies
Omit any section with no content (except Summary and Test Plan — always required)

摘要要点：聚焦于“原因”和业务影响，而非仅“内容”
变更内容部分：按模块/区域分组，而非按提交
测试计划：具体、可操作的审核人员可验证的项 — 而非通用的“运行测试”
破坏性变更：如有适用，包含迁移步骤
备注：提及新的环境变量、数据库迁移、服务依赖
省略任何无内容的部分（摘要和测试计划除外 — 这两个始终必填）

Step 7: Push Branch

步骤7：推送分支

Gate: Branch pushed to remote before proceeding to Step 8.

bash

undefined

** Gate：分支已推送到远程仓库后再进入步骤8 **

bash

undefined

Push with upstream tracking

推送并设置上游跟踪

git push -u origin $(git branch --show-current)


If push fails:

- **Rejected (non-fast-forward):** "Remote has changes not in your branch. Pull or rebase first."
- **Permission denied:** "Push access denied. Check your repository permissions."
- **Branch protection:** "Branch is protected. Create a PR from a different branch."

git push -u origin $(git branch --show-current)


如果推送失败：

- **被拒绝（非快进）**："远程仓库有你的分支中没有的变更。请先拉取或变基。"
- **权限被拒绝**："推送权限被拒绝。请检查你的仓库权限。"
- **分支受保护**："该分支受保护。请从其他分支创建PR。"

Step 8: Create PR via GitHub CLI

步骤8：通过GitHub CLI创建PR

Gate: PR created successfully before proceeding to Step 9.

** Gate：PR创建成功后再进入步骤9 **

Standard PR

标准PR

bash

gh pr create --base "$BASE_BRANCH" --title "<title>" --body "$(cat <<'EOF'
<generated body from Step 6>
EOF
)"

bash

gh pr create --base "$BASE_BRANCH" --title "<title>" --body "$(cat <<'EOF'
<步骤6生成的正文>
EOF
)"

With Options from $ARGUMENTS

从$ARGUMENTS中解析选项

Parse $ARGUMENTS for additional options:

User Says	Flag
"draft PR", "WIP"	`--draft`
"assign @user"	`--assignee user`
"add reviewer @user"	`--reviewer user`
"label bug"	`--label bug`
"milestone v2"	`--milestone "v2"`

Example with options:

bash

gh pr create --base main --draft --reviewer "tech-lead" --label "feature" \
  --title "feat(auth): add JWT authentication" \
  --body "$(cat <<'EOF'
...body...
EOF
)"

从$ARGUMENTS中解析额外选项：

用户输入	标志
"draft PR", "WIP"	`--draft`
"assign @user"	`--assignee user`
"add reviewer @user"	`--reviewer user`
"label bug"	`--label bug`
"milestone v2"	`--milestone "v2"`

带选项的示例：

bash

gh pr create --base main --draft --reviewer "tech-lead" --label "feature" \
  --title "feat(auth): add JWT authentication" \
  --body "$(cat <<'EOF'
...正文...
EOF
)"

gh

is Not Available

如果

gh

不可用

gh pr create

fails with "command not found":

Show the PR title and body to the user

Provide the GitHub URL:

https://github.com/<org>/<repo>/compare/$BASE_BRANCH...<branch>

Instruct: "GitHub CLI not found. Create the PR manually using the URL above."

如果

gh pr create

执行失败并提示"command not found"：

向用户展示PR标题和正文

提供GitHub URL：

https://github.com/<org>/<repo>/compare/$BASE_BRANCH...<branch>

指导用户："未找到GitHub CLI。请使用上述URL手动创建PR。"

Step 9: Verify and Report

步骤9：验证并报告

Gate: PR verified and URL reported before proceeding to Step 10.

After creating the PR:

bash

undefined

** Gate：PR已验证并报告URL后再进入步骤10 **

创建PR后：

bash

undefined

Get PR details

获取PR详情

gh pr view --json number,url,title,state,isDraft


Report to the user:

PR #<number> created: <title> URL: <url> Base: <base> <- <branch> State: <open/draft> Size: <S/M/L/XL> (<N> files changed, +<additions> -<deletions>)


If there are remaining uncommitted changes, mention them.

gh pr view --json number,url,title,state,isDraft


向用户报告：

PR #<编号>已创建: <标题> URL: <链接> 基准分支: <base> <- <branch> 状态: <open/draft> 大小: <S/M/L/XL>（<N>个文件变更，+<新增行数> -<删除行数>）


如果仍有未提交的变更，需提及此情况。

Safety Rules

安全规则

Rule	Reason
Never create PRs proactively	Only when explicitly asked
Never force push before PR	Rewrites history others may depend on
Never create PR from main/master/develop	These are protected base branches
Never create PR with conflict markers	Unresolved conflicts break the build
Never fabricate test results in PR body	Test plan must reflect actual state
Never omit breaking changes from body	Reviewers must know about breaking changes
Never include secrets in PR body	No tokens, passwords, or keys in description
Always use `gh` CLI over manual API calls	Handles auth, org context, templates properly
Always push before creating PR	Remote must have the branch
Always read full diff, not just commits	Commit messages can be misleading

规则	原因
绝不要主动创建PR	仅在明确请求时执行
PR创建前绝不强制推送	会重写他人可能依赖的历史
绝不要从main/master/develop创建PR	这些是受保护的基准分支
绝不要创建带有冲突标记的PR	未解决的冲突会导致构建失败
绝不要在PR正文中伪造测试结果	测试计划必须反映实际状态
绝不要在正文中省略破坏性变更	审核人员必须了解破坏性变更
绝不要在PR正文中包含机密信息	描述中不得包含令牌、密码或密钥
始终使用 `gh` CLI而非手动API调用	能正确处理认证、组织上下文和模板
始终先推送分支再创建PR	远程仓库必须存在该分支
始终阅读完整差异，而非仅提交信息	提交信息可能存在误导

Quick Reference: PR Readiness Checklist

快速参考：PR就绪检查清单

1.  On a feature branch?            → BLOCK if on main/master/develop
2.  Uncommitted changes?            → Invoke commit skill first
3.  Has commits vs base?            → BLOCK if no commits
4.  Conflict markers?               → BLOCK until resolved
5.  Type errors?                    → WARN, recommend fixing
6.  Lint errors?                    → WARN, offer auto-fix
7.  Breaking changes documented?    → Ensure in PR body
8.  Branch pushed to remote?        → Push if not
9.  gh CLI available?               → Fallback to manual if not
10. All clear → create PR

1. 是否在功能分支上？ → 如果在main/master/develop分支上则阻塞
2. 是否有未提交的变更？ → 先调用commit技能
3. 相对于基准分支是否有提交？ → 如果没有则阻塞
4. 是否有冲突标记？ → 解决后才能继续
5. 是否有类型错误？ → 警告用户，建议修复
6. 是否有Lint错误？ → 警告用户，提供自动修复选项
7. 破坏性变更是否已记录？ → 确保包含在PR正文中
8. 分支是否已推送到远程？ → 如果没有则推送
9. GitHub CLI是否可用？ → 如果不可用则提供手动创建方式
10. 所有检查通过 → 创建PR

Quick Reference: Body Section Guide

快速参考：正文部分指南

Summary       → ALWAYS (3-5 bullets, why + what)
Changes       → ALWAYS for M/L/XL PRs, optional for S
Breaking      → ONLY if breaking changes detected
Test Plan     → ALWAYS (specific scenarios, checkboxes)
Notes         → ONLY if deployment/config/dependency changes

摘要 → 始终必填（3-5个要点，原因+内容）
变更内容 → M/L/XL型PR始终必填，S型可选
破坏性变更 → 仅当检测到破坏性变更时添加
测试计划 → 始终必填（具体场景，带复选框）
备注 → 仅当有部署/配置/依赖变更时添加

Resources

参考资源

See

references/pr-body-examples.md

for full PR body examples across different PR types (feature, bugfix, refactor, breaking change).

查看

references/pr-body-examples.md

获取不同类型PR（功能、bug修复、重构、破坏性变更）的完整PR正文示例。

Step 10: Verification (MANDATORY)

步骤10：验证（必须执行）

After creating PR, verify complete workflow:

创建PR后，验证完整工作流：

Check 1: PR Exists

检查1：PR是否存在

```
gh pr view
```
shows the PR details
PR URL is accessible

```
gh pr view
```
显示PR详情
PR URL可访问

Check 2: Content Quality

检查2：内容质量

Title follows conventional format
Summary section has 3-5 bullets
Test plan has specific scenarios

标题遵循规范格式
摘要部分包含3-5个要点
测试计划包含具体场景

Check 3: Breaking Changes Documented

检查3：破坏性变更是否已记录

If breaking changes detected, they appear in PR body
Migration steps included if applicable

如果检测到破坏性变更，已包含在PR正文中
如有适用，包含迁移步骤

Check 4: Branch State

检查4：分支状态

Local and remote branches are in sync
No remaining uncommitted changes

本地和远程分支同步
无剩余未提交变更

Check 5: PR State

检查5：PR状态

PR is in correct state (open/draft as intended)
Base branch is correct
Labels/reviewers assigned (if requested)

Gate: Do NOT mark PR creation complete until all 5 checks pass.

PR处于正确状态（按预期为open/draft）
基准分支正确
已按要求分配标签/审核人

** Gate：所有5项检查通过后，才能标记PR创建完成。**

Quality Checklist (Must Score 8/10)

质量检查清单（必须得8/10分）

Score yourself honestly before marking PR creation complete:

在标记PR创建完成前，诚实地为自己评分：

Context Gathering (0-2 points)

上下文收集（0-2分）

0 points: Created PR without reading diff
1 point: Read commit messages only
2 points: Read full diff against base branch

0分：未阅读差异就创建PR
1分：仅阅读了提交信息
2分：阅读了与基准分支的完整差异

Validation (0-2 points)

验证（0-2分）

0 points: Created PR with uncommitted changes or from protected branch
1 point: Validated some checks
2 points: All pre-PR validations pass

0分：在有未提交变更或受保护分支上创建PR
1分：验证了部分检查项
2分：所有PR创建前验证项通过

Title Quality (0-2 points)

标题质量（0-2分）

0 points: Generic title ("Update code", "Fix bug")
1 point: Has type but vague description
2 points: Proper format: type(scope): clear description <72 chars

0分：通用标题（"Update code", "Fix bug"）
1分：包含类型但描述模糊
2分：格式正确：type(scope): 清晰描述，长度<72字符

Body Quality (0-2 points)

正文质量（0-2分）

0 points: Empty or minimal body
1 point: Has summary but missing test plan
2 points: Complete: summary, changes (if M+), breaking changes (if any), test plan

0分：正文为空或内容极少
1分：包含摘要但缺少测试计划
2分：内容完整：摘要、变更内容（M+型PR）、破坏性变更（如有）、测试计划

Breaking Changes (0-2 points)

破坏性变更（0-2分）

0 points: Breaking changes exist but not documented
1 point: Breaking changes mentioned but no migration steps
2 points: No breaking changes, OR fully documented with migration steps

Minimum passing score: 8/10

0分：存在破坏性变更但未记录
1分：提及了破坏性变更但未包含迁移步骤
2分：无破坏性变更，或已完整记录并包含迁移步骤

最低及格分：8/10

Common Rationalizations (All Wrong)

常见错误理由（全错）

These are excuses. Don't fall for them:

"The commit messages explain it" → STILL read the full diff
"It's a small PR" → STILL write summary and test plan
"I'll add the test plan later" → Write it NOW, reviewers need it
"There are no breaking changes" → STILL check for removed exports, API changes
"I can push after creating the PR" → PUSH FIRST, then create PR
"The title is obvious" → STILL use conventional format with type and scope
"gh isn't installed" → STILL provide manual URL and formatted body
"It's just a draft" → Draft PRs STILL need quality body and test plan

这些都是借口。不要被它们误导：

"提交信息已经说明了一切" → 仍然要阅读完整差异
"这是一个小PR" → 仍然要编写摘要和测试计划
"我稍后再添加测试计划" → 现在就写，审核人员需要它
"没有破坏性变更" → 仍然要检查是否有移除的导出、API变更
"我可以先创建PR再推送" → 先推送，再创建PR
"标题很明显" → 仍然要使用包含类型和范围的规范格式
"gh没有安装" → 仍然要提供手动URL和格式化的正文
"这只是草稿PR" → 草稿PR仍然需要高质量的正文和测试计划

Failure Modes

失败模式

Failure Mode 1: PR from Protected Branch

失败模式1：从受保护分支创建PR

Symptom: Trying to create PR from main/master/develop Fix: Create a feature branch first:

git checkout -b feature/name

症状： 尝试从main/master/develop分支创建PR 修复： 先创建功能分支：

git checkout -b feature/name

Failure Mode 2: Uncommitted Changes Included

失败模式2：包含未提交的变更

Symptom: PR diff doesn't match expected changes Fix: Invoke commit skill first, then re-run create-pr

症状： PR差异与预期变更不符 修复： 先调用commit技能，然后重新运行create-pr

Failure Mode 3: Missing Breaking Changes

失败模式3：遗漏破坏性变更

Symptom: Reviewer discovers undocumented breaking changes Fix: Edit PR body to add Breaking Changes section with migration steps

症状： 审核人员发现未记录的破坏性变更 修复： 编辑PR正文，添加破坏性变更部分及迁移步骤

Failure Mode 4: Branch Not Pushed

失败模式4：分支未推送

Symptom:

gh pr create

fails with "branch not found on remote" Fix: Run

git push -u origin $(git branch --show-current)

first

症状：

gh pr create

失败，提示"branch not found on remote" 修复： 先运行

git push -u origin $(git branch --show-current)

Failure Mode 5: Empty Test Plan

失败模式5：测试计划为空

Symptom: Reviewers ask "how do I test this?" Fix: Add specific, actionable test scenarios with checkboxes

症状： 审核人员询问"我该如何测试？" 修复： 添加具体、可操作的测试场景并带复选框

Quick Workflow Summary

快速工作流摘要

STEP 1: GATHER BRANCH CONTEXT
├── git branch --show-current
├── git status --short
├── git log main..HEAD
├── git diff main...HEAD
└── Gate: Context collected

STEP 2: PRE-PR VALIDATION
├── Not on protected branch?
├── Uncommitted changes? → invoke commit
├── Has commits vs base?
└── Gate: Branch ready

STEP 3: ANALYZE ALL COMMITS
├── Read all commit messages
├── Read full diff
├── Classify: type, scope, size, risk
├── Detect breaking changes
└── Gate: PR classified

STEP 4: PRE-PR QUALITY CHECKS
├── Conflict markers?
├── Type errors?
├── Lint errors?
└── Gate: No blocking issues

STEP 5: GENERATE PR TITLE
├── type(scope): description
├── Under 72 chars
├── Breaking? Add !
└── Gate: Title ready

STEP 6: GENERATE PR BODY
├── Summary (3-5 bullets)
├── Changes (if M/L/XL)
├── Breaking Changes (if any)
├── Test Plan (always)
├── Notes (if deployment/config)
└── Gate: Body complete

STEP 7: PUSH BRANCH
├── git push -u origin <branch>
└── Gate: Branch on remote

STEP 8: CREATE PR VIA GH CLI
├── gh pr create with heredoc
├── Add flags: --draft, --reviewer, etc.
└── Gate: PR created

STEP 9: VERIFY AND REPORT
├── gh pr view
├── Report URL and details
└── Gate: PR verified

STEP 10: VERIFICATION
├── Check 1: PR exists
├── Check 2: Content quality
├── Check 3: Breaking changes documented
├── Check 4: Branch state
├── Check 5: PR state
└── Gate: All 5 checks pass

STEP 1: 收集分支上下文
├── git branch --show-current
├── git status --short
├── git log main..HEAD
├── git diff main...HEAD
└── Gate: 上下文已收集

STEP 2: PR创建前验证
├── 是否在受保护分支？
├── 是否有未提交变更？ → 调用commit
├── 相对于基准分支是否有提交？
└── Gate: 分支就绪

STEP 3: 分析所有提交
├── 阅读所有提交信息
├── 阅读完整差异
├── 分类：类型、范围、大小、风险
├── 检测破坏性变更
└── Gate: PR已分类

STEP 4: PR创建前质量检查
├── 是否有冲突标记？
├── 是否有类型错误？
├── 是否有Lint错误？
└── Gate: 无阻塞问题

STEP 5: 生成PR标题
├── type(scope): description
├── 长度<72字符
└── 破坏性变更？添加!
└── Gate: 标题就绪

STEP 6: 生成PR正文
├── 摘要（3-5个要点）
├── 变更内容（如果是M/L/XL）
├── 破坏性变更（如有）
├── 测试计划（始终）
├── 备注（如果有部署/配置）
└── Gate: 正文完成

STEP 7: 推送分支
├── git push -u origin <branch>
└── Gate: 分支已上传到远程

STEP 8: 通过GH CLI创建PR
├── 使用heredoc运行gh pr create
├── 添加标志：--draft、--reviewer等
└── Gate: PR已创建

STEP 9: 验证并报告
├── gh pr view
├── 报告URL和详情
└── Gate: PR已验证

STEP 10: 最终验证
├── 检查1: PR存在
├── 检查2: 内容质量
├── 检查3: 破坏性变更已记录
├── 检查4: 分支状态
├── 检查5: PR状态
└── Gate: 所有5项检查通过

Completion Announcement

完成通知

When PR is created, announce:

PR created.

**Quality Score: X/10**
- Context Gathering: X/2
- Validation: X/2
- Title Quality: X/2
- Body Quality: X/2
- Breaking Changes: X/2

**Pull Request:**
- PR #[number]: [title]
- URL: [url]
- Base: [base] <- [branch]
- State: [open/draft]
- Size: [S/M/L/XL] ([N] files, +[add] -[del])

**Verification:**
- PR exists: ✅
- Title format: ✅
- Test plan: ✅
- Breaking changes: [None/Documented]
- Branch synced: ✅

**Next steps:**
[Request reviewers, address CI, or wait for review]

PR创建完成后，通知用户：

PR已创建。

**质量评分: X/10**
- 上下文收集: X/2
- 验证: X/2
- 标题质量: X/2
- 正文质量: X/2
- 破坏性变更: X/2

**Pull Request详情:**
- PR #<编号>: <标题>
- URL: <链接>
- 基准分支: <base> <- <branch>
- 状态: <open/draft>
- 大小: <S/M/L/XL>（<N>个文件，+<新增> -<删除>）

**验证结果:**
- PR存在: ✅
- 标题格式: ✅
- 测试计划: ✅
- 破坏性变更: [无/已记录]
- 分支同步: ✅

**下一步:**
[请求审核人员、处理CI或等待审核]

Integration with Other Skills

与其他技能的集成

The

create-pr

skill integrates with:

start
— Use
```
start
```
to identify if PR creation is appropriate
commit
— Automatically invoked if uncommitted changes detected
git-merge-expert-worktree
— PRs can be created from worktree branches

Workflow Chain:

Work completed
       │
       ▼
commit skill (if uncommitted changes)
       │
       ▼
create-pr skill (this skill)
       │
       ▼
Review cycle

Auto-Invoke Pattern:

When

create-pr

detects uncommitted changes via

git status --short

, it automatically invokes the

commit

skill first. The user doesn't need to manually run commit before PR creation.

create-pr

技能与以下技能集成：

start
— 使用
```
start
```
技能判断是否适合创建PR
commit
— 当检测到未提交变更时自动调用
git-merge-expert-worktree
— 可从工作树分支创建PR

工作流链:

工作完成
       │
       ▼
commit技能（如有未提交变更）
       │
       ▼
create-pr技能（本技能）
       │
       ▼
审核周期

自动调用模式:

当

create-pr

通过

git status --short

检测到未提交变更时，会自动先调用

commit

技能。用户无需在创建PR前手动运行commit。