<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
- ☐ Run — invoke commit skill if uncommitted changes
- ☐ Run — verify commits exist
- ☐ Run — 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
- ☐ 运行 — 如果有未提交变更，调用commit技能
- ☐ 运行 — 确认存在提交
- ☐ 运行 — 查看完整差异（不只是提交信息）
- ☐ 检查变更文件中是否有冲突标记
- ☐ 识别破坏性变更（移除的导出、 schema 变更、API变更）
- ☐ 确定PR的类型、范围、大小和风险
- ☐ 通知："正在创建PR: 类型: [标题]"
未完成此检查清单就创建PR会导致审核不完整和返工。
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
. If uncommitted changes exist, invoke the
skill first.
验证分支是否就绪，分析与基准分支分叉后的所有提交，生成包含有意义标题和正文的结构化PR，推送到远程仓库，并通过
命令创建PR。如果存在未提交的变更，先调用
技能。
- 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., )
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。仅在明确请求时执行。
Step 1: Gather Branch Context
步骤1：收集分支上下文
Gate: Full context collected before proceeding to Step 2.
Run these commands to understand the full picture:
** Gate：收集完完整上下文后再进入步骤2 **
运行以下命令以全面了解情况：
Current branch name
当前分支名称
git branch --show-current
git branch --show-current
Check if branch tracks a remote
检查分支是否跟踪远程仓库
Uncommitted changes (never use -uall)
未提交的变更（绝不使用-uall）
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
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
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 branch:
git rev-parse --verify origin/main 2>/dev/null
- Check for branch:
git rev-parse --verify origin/master 2>/dev/null
- Check for branch:
git rev-parse --verify origin/develop 2>/dev/null
- If none found, ask the user
Store as
for all subsequent steps.
按以下优先级选择：
- 如果用户在$ARGUMENTS中指定了基准分支，使用该分支
- 检查是否存在分支：
git rev-parse --verify origin/main 2>/dev/null
- 检查是否存在分支：
git rev-parse --verify origin/master 2>/dev/null
- 检查是否存在分支：
git rev-parse --verify origin/develop 2>/dev/null
- 如果以上都未找到，询问用户
Step 2: Pre-PR Validation
步骤2：PR创建前验证
Gate: Branch ready (commits exist, no uncommitted changes) before proceeding to Step 3.
** Gate：分支就绪（存在提交、无未提交变更）后再进入步骤3 **
Uncommitted Changes
未提交的变更
- Invoke the 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
- 调用技能：使用Skill工具，命令为
Use the Skill tool with skill="commit"
- commit技能会处理暂存、质量检查和提交操作
- commit完成后，重新运行步骤1以获取新的提交
- 使用更新后的分支状态继续操作
If
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。"
Validate branch name is not
,
, or
:
- If on a protected branch, stop: "You're on $BRANCH. Create a feature branch first."
- 如果在受保护分支上，停止操作："你当前在$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:
** Gate：PR已分类（类型、范围、大小、风险）后再进入步骤4 **
阅读分支中的每个提交 — 不只是最新的提交：
All commits with full messages
包含完整信息的所有提交
git log --format="%h %s%n%b%n---" $BASE_BRANCH..HEAD
git log --format="%h %s%n%b%n---" $BASE_BRANCH..HEAD
File change summary across all commits
所有提交的文件变更摘要
git diff --stat $BASE_BRANCH...HEAD
git diff --stat $BASE_BRANCH...HEAD
Full diff for understanding scope
用于了解范围的完整差异
git diff $BASE_BRANCH...HEAD
git diff $BASE_BRANCH...HEAD
Based on ALL commits and the full diff, determine:
| Aspect | How to Determine |
|---|
| Type | Feature (), bugfix (), 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 |
基于所有提交和完整差异，确定：
| 维度 | 判定方式 |
|---|
| 类型 | 功能（）、 bug修复（）、重构、文档、杂项 — 来自提交类型和实际变更 |
| 范围 | 主要受影响的区域 — 来自文件路径和分支名称 |
| 大小 | 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:
** Gate：无阻塞问题后再进入步骤5 **
对整个分支差异运行质量检查：
TypeScript type check
TypeScript类型检查
ESLint (if configured)
ESLint（如果已配置）
ls .eslintrc* eslint.config.* 2>/dev/null && git diff --name-only $BASE_BRANCH...HEAD -- '*.ts' | xargs npx 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
git diff --name-only $BASE_BRANCH...HEAD | xargs grep -n '<<<<<<<|=======|>>>>>>>' 2>/dev/null
- 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.
<type>(<scope>): <concise description>
- 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 |
|---|
| feat(auth): add JWT authentication system
|
fix/cart-total-calculation
| fix(cart): correct total calculation with discounts
|
| refactor(search): restructure search service architecture
|
If $ARGUMENTS contains a clear title, use it (respecting format rules).
将分支名称作为参考，结合实际变更验证：
| 分支名称 | 可能的标题 |
|---|
| feat(auth): add JWT authentication system
|
fix/cart-total-calculation
| fix(cart): correct total calculation with discounts
|
| 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:
** Gate：正文包含所有必填部分后再进入步骤7 **
使用HEREDOC模板：
<3-5 bullet points describing WHAT changed and WHY>
<Grouped by area — list key files/modules changed>
<Only if breaking changes detected in Step 3. Otherwise omit entirely.>
- What broke
- Migration steps
<仅当步骤3中检测到破坏性变更时添加。否则完全省略。>
<Optional: deployment notes, config changes, dependencies added>
- 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.
** Gate：分支已推送到远程仓库后再进入步骤8 **
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.
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" | |
| "assign @user" | |
| "add reviewer @user" | |
| "label bug" | |
| "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" | |
| "assign @user" | |
| "add reviewer @user" | |
| "label bug" | |
| "milestone v2" | |
带选项的示例：
bash
gh pr create --base main --draft --reviewer "tech-lead" --label "feature" \
--title "feat(auth): add JWT authentication" \
--body "$(cat <<'EOF'
...正文...
EOF
)"
If
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."
如果
执行失败并提示"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:
** Gate：PR已验证并报告URL后再进入步骤10 **
创建PR后：
gh pr view --json number,url,title,state,isDraft
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>个文件变更，+<新增行数> -<删除行数>）
| 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 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正文中包含机密信息 | 描述中不得包含令牌、密码或密钥 |
| 始终使用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型可选
破坏性变更 → 仅当检测到破坏性变更时添加
测试计划 → 始终必填（具体场景，带复选框）
备注 → 仅当有部署/配置/依赖变更时添加
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:
Check 1: PR Exists
检查1：PR是否存在
Check 2: Content Quality
检查2：内容质量
Check 3: Breaking Changes Documented
检查3：破坏性变更是否已记录
Check 4: Branch State
检查4：分支状态
Check 5: PR State
检查5：PR状态
Gate: Do NOT mark PR creation complete until all 5 checks pass.
** Gate：所有5项检查通过后，才能标记PR创建完成。**
Quality Checklist (Must Score 8/10)
质量检查清单（必须得8/10分）
Score yourself honestly before marking PR creation complete:
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 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: fails with "branch not found on remote"
Fix: Run
git push -u origin $(git branch --show-current)
first
症状： 失败，提示"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
skill integrates with:
- — Use to identify if PR creation is appropriate
- — Automatically invoked if uncommitted changes detected
git-merge-expert-worktree
Workflow Chain:
Work completed
│
▼
commit skill (if uncommitted changes)
│
▼
create-pr skill (this skill)
│
▼
Review cycle
Auto-Invoke Pattern:
When
detects uncommitted changes via
, it automatically invokes the
skill first. The user doesn't need to manually run commit before PR creation.
- — 使用技能判断是否适合创建PR
- — 当检测到未提交变更时自动调用
git-merge-expert-worktree
工作流链:
工作完成
│
▼
commit技能（如有未提交变更）
│
▼
create-pr技能（本技能）
│
▼
审核周期
自动调用模式:
当
通过
检测到未提交变更时，会自动先调用
技能。用户无需在创建PR前手动运行commit。