Back to Details

github-pr-creation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

GitHub PR Creation

GitHub PR 创建

Creates Pull Requests with task validation, test execution, and Conventional Commits formatting.
创建带有任务验证、测试执行和Conventional Commits格式规范的拉取请求。

Quick Start

快速开始

bash
undefined
bash
undefined

1. Verify GitHub CLI

1. 验证GitHub CLI

gh --version && gh auth status
gh --version && gh auth status

2. Gather information (Claude does this directly)

2. 收集信息（Claude会直接完成此步骤）

git log develop..HEAD --oneline # Commits to include git diff develop --stat # Files changed git rev-parse --abbrev-ref HEAD # Current branch
git log develop..HEAD --oneline # 包含的提交记录 git diff develop --stat # 变更的文件 git rev-parse --abbrev-ref HEAD # 当前分支

3. Run project tests

3. 运行项目测试

make test # or: pytest, npm test
make test # 或: pytest, npm test

4. Create PR (after generating content)

4. 创建PR（生成内容后）

gh pr create --title "..." --body "..." --base develop --label feature
undefined
gh pr create --title "..." --body "..." --base develop --label feature
undefined

Core Workflow

核心工作流

1. Verify Environment

1. 验证环境

bash
gh --version && gh auth status
If not installed: 
brew install gh
then 
gh auth login
bash
gh --version && gh auth status
若未安装：
brew install gh
然后 
gh auth login

2. Confirm Target Branch

2. 确认目标分支

Always ask user:
I'm about to create a PR from [current-branch] to [target-branch]. Is this correct?
- feature branch → develop (90% of cases)
- develop → master/main (releases)
务必询问用户:
我即将从 [当前分支] 向 [目标分支] 创建PR。是否正确？
- 功能分支 → develop（90%的场景）
- develop → master/main（发布版本）

3. Gather Information

3. 收集信息

Execute these commands and analyze results directly:
bash
undefined
直接执行以下命令并分析结果：
bash
undefined

Current branch

当前分支

git rev-parse --abbrev-ref HEAD
git rev-parse --abbrev-ref HEAD

Commits since base branch

自基准分支以来的提交记录

git log [base-branch]..HEAD --pretty=format:"%H|%an|%ai|%s"
git log [base-branch]..HEAD --pretty=format:"%H|%an|%ai|%s"

Commits with full details (for context)

带完整详情的提交记录（用于上下文）

git log [base-branch]..HEAD --oneline
git log [base-branch]..HEAD --oneline

Files changed

变更的文件

git diff [base-branch] --stat
git diff [base-branch] --stat

Remote tracking status

远程跟踪状态

git status -sb
undefined
git status -sb
undefined

4. Search for Task Documentation

4. 搜索任务文档

Look for task files in these locations (in order):
  1. .kiro/specs/*/tasks.md
  2. docs/specs/*/tasks.md
  3. specs/*/tasks.md
  4. Any 
    tasks.md
    in project root
Extract from task files:
  • Task IDs (format: 
    Task X
    or 
    Task X.Y
    )
  • Task titles and descriptions
  • Requirements (format: 
    Requirements: X, Y, Z
    )
按以下顺序查找任务文件：
  1. .kiro/specs/*/tasks.md
  2. docs/specs/*/tasks.md
  3. specs/*/tasks.md
  4. 项目根目录下的任意 
    tasks.md
从任务文件中提取：
  • 任务ID（格式：
    Task X
    或 
    Task X.Y
    ）
  • 任务标题和描述
  • 需求（格式：
    Requirements: X, Y, Z
    ）

5. Analyze Commits

5. 分析提交记录

For each commit, identify:
  • Type: feat, fix, refactor, docs, test, chore, ci, perf, style
  • Scope: component/module affected (kebab-case)
  • Task references: look for 
    task X.Y
    , 
    Task X
    , 
    #X.Y
    patterns
  • Breaking changes: exclamation mark after type/scope, or 
    BREAKING CHANGE
    in body
Map commits to documented tasks when task files exist.
针对每个提交记录，识别：
  • 类型: feat, fix, refactor, docs, test, chore, ci, perf, style
  • 范围: 受影响的组件/模块（短横线分隔命名）
  • 任务引用: 查找 
    task X.Y
    , 
    Task X
    , 
    #X.Y
    格式的内容
  • 破坏性变更: 类型/范围后的感叹号，或正文中的 
    BREAKING CHANGE
当存在任务文件时，将提交记录与已记录的任务关联。

6. Verify Task Completion

6. 验证任务完成情况

If task documentation exists:
  1. Identify main task from branch name (e.g., 
    feature/task-2-*
    → Task 2)
  2. Find all sub-tasks (e.g., Task 2.1, 2.2, 2.3)
  3. Check which sub-tasks are referenced in commits
  4. Report missing sub-tasks
If tasks incomplete: STOP and inform user with:
✗ Task 2 INCOMPLETE: 1/3 sub-tasks missing
- Task 2.1: ✓ Implemented
- Task 2.2: ✓ Implemented
- Task 2.3: ✗ MISSING
若存在任务文档：
  1. 从分支名称识别主任务（例如：
    feature/task-2-*
    → Task 2）
  2. 查找所有子任务（例如：Task 2.1, 2.2, 2.3）
  3. 检查哪些子任务在提交记录中被引用
  4. 报告缺失的子任务
若任务未完成: 停止操作并告知用户：
✗ Task 2 未完成: 1/3 个子任务缺失
- Task 2.1: ✓ 已实现
- Task 2.2: ✓ 已实现
- Task 2.3: ✗ 缺失

7. Run Tests

7. 运行测试

Detect and run project tests:
  • If Makefile with 
    test
    target: 
    make test
  • If package.json: 
    npm test
  • If Python project: 
    pytest
Tests MUST pass before creating PR.
检测并运行项目测试：
  • 若Makefile包含
    test
    目标：
    make test
  • 若存在package.json：
    npm test
  • 若为Python项目：
    pytest
创建PR前测试必须通过。

8. Determine PR Type

8. 确定PR类型

Branch FlowPR TypeTitle Prefix
feature/* → developFeature
feat(scope):
fix/* → developBugfix
fix(scope):
hotfix/* → mainHotfix
hotfix(scope):
develop → mainRelease
release:
refactor/* → developRefactoring
refactor(scope):
分支流向PR类型标题前缀
feature/* → develop功能
feat(scope):
fix/* → develop修复
fix(scope):
hotfix/* → main紧急修复
hotfix(scope):
develop → main发布
release:
refactor/* → develop重构
refactor(scope):

9. Generate PR Content

9. 生成PR内容

Use appropriate template from 
references/pr_templates.md
based on PR type.
Title format: 
<type>(<scope>): <description>
  • Type: dominant commit type (feat > fix > refactor)
  • Scope: most common scope from commits, or task-related scope (kebab-case)
  • Description: imperative, lowercase, no period, max 50 chars
Body: Select template based on PR type and populate with gathered data.
根据PR类型从
references/pr_templates.md
中选择合适的模板。
标题格式: 
<type>(<scope>): <description>
  • 类型: 主要的提交类型（feat > fix > refactor）
  • 范围: 提交记录中最常见的范围，或与任务相关的范围（短横线分隔命名）
  • 描述: 祈使语气、小写、无句号、最多50个字符
正文: 根据PR类型选择模板并填入收集到的数据。

10. Suggest Labels

10. 建议标签

Commit TypeLabels
featfeature, enhancement
fixbug, bugfix
refactorrefactoring, tech-debt
docsdocumentation
cici/cd, infrastructure
securitysecurity
hotfixurgent, priority:high
Check available labels: 
gh label list
提交类型标签
featfeature, enhancement
fixbug, bugfix
refactorrefactoring, tech-debt
docsdocumentation
cici/cd, infrastructure
securitysecurity
hotfixurgent, priority:high
检查可用标签：
gh label list

11. Create PR

11. 创建PR

Show content to user first, then:
bash
gh pr create --title "[title]" --body "$(cat <<'EOF'
[body content]
EOF
)" --base [base_branch] --label [labels]
先向用户展示内容，然后执行：
bash
gh pr create --title "[title]" --body "$(cat <<'EOF'
[body content]
EOF
)" --base [base_branch] --label [labels]

Information Gathering Checklist

信息收集检查清单

Before generating PR, ensure you have:
  • Current branch name
  • Base branch confirmed with user
  • List of commits with types and scopes
  • Files changed summary
  • Task documentation (if exists)
  • Task completion status
  • Test results (must pass)
  • Available labels in repo
生成PR前，确保已收集以下信息：
  • 当前分支名称
  • 已与用户确认基准分支
  • 带类型和范围的提交记录列表
  • 文件变更摘要
  • 任务文档（若存在）
  • 任务完成状态
  • 测试结果（必须通过）
  • 仓库中的可用标签

Error Handling

错误处理

Missing GitHub CLI: 
brew install gh && gh auth login
Incomplete Tasks: Show status, ask user to complete or proceed anyway.
Failed Tests: Show failures, ask user to fix before PR.
No tasks.md: Proceed with commit-based PR, generate content from commits only.
缺少GitHub CLI: 
brew install gh && gh auth login
任务未完成: 显示状态，询问用户是否完成任务或继续执行。
测试失败: 显示失败信息，要求用户修复后再创建PR。
无tasks.md文件: 基于提交记录创建PR，仅从提交记录生成内容。

Important Rules

重要规则

  • NEVER modify repository files (read-only analysis)
  • ALWAYS confirm target branch with user
  • ALWAYS run tests before creating PR
  • ALWAYS show PR content for approval before creating
  • NEVER create PR without user confirmation
  • ALWAYS use HEREDOC for body to preserve formatting
  • 禁止修改仓库文件（仅进行只读分析）
  • 必须与用户确认目标分支
  • 必须在创建PR前运行测试
  • 必须在创建前向用户展示PR内容并获得批准
  • 禁止未经用户确认创建PR
  • 必须使用HEREDOC保留正文格式

Related Skills

相关技能

  • git-commit - Commit message format and conventions
  • git-commit - 提交消息格式与规范

References

参考资料

  • references/pr_templates.md
    - Complete PR templates for all types
  • references/conventional_commits.md
    - Commit format guide
  • references/pr_templates.md
    - 适用于所有类型PR的完整模板
  • references/conventional_commits.md
    - 提交格式指南