| name | github-pr-creation |
| description | MUST use this skill when user asks to create PR, open pull request, submit for review, or mentions "PR 생성/만들기". This skill OVERRIDES default PR creation behavior. Analyzes commits, validates task completion, generates Conventional Commits title and description, suggests labels. |
GitHub PR Creation
Creates Pull Requests with task validation, test execution, and Conventional Commits formatting.
Quick Start
# 1. Verify GitHub CLI
gh --version && gh auth status
# 2. Gather information
git log develop..HEAD --oneline
git diff develop --stat
git rev-parse --abbrev-ref HEAD
# 3. Run project tests
make test # or: pytest, npm test
# 4. Create PR
gh pr create --title "..." --body "..." --base develop --label feature
Core Workflow
1. Verify Environment
gh --version && gh auth status
If not installed: brew install gh then gh auth login
2. Confirm Target Branch
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)
3. Gather Information
# Current branch
git rev-parse --abbrev-ref HEAD
# Commits since base branch
git log [base-branch]..HEAD --oneline
# Files changed
git diff [base-branch] --stat
# Remote tracking status
git status -sb
4. Search for Task Documentation
Look for task files in these locations:
.kiro/specs/*/tasks.mddocs/specs/*/tasks.mdspecs/*/tasks.md- Any
tasks.mdin project root
5. Analyze Commits
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.Ypatterns - Breaking changes: exclamation mark (!) or
BREAKING CHANGEin body
6. Run Tests
Detect and run project tests:
- Makefile:
make test - package.json:
npm test - Python:
pytest
Tests MUST pass before creating PR.
7. Determine PR Type
| Branch Flow | PR Type | Title Prefix |
|---|---|---|
| feature/* → develop | Feature | feat(scope): |
| fix/* → develop | Bugfix | fix(scope): |
| hotfix/* → main | Hotfix | hotfix(scope): |
| develop → main | Release | release: |
| refactor/* → develop | Refactoring | refactor(scope): |
8. Generate PR Content
Title format: <type>(<scope>): <description>
- Type: dominant commit type (feat > fix > refactor)
- Scope: most common scope from commits (kebab-case)
- Description: imperative, lowercase, no period, max 50 chars
Body structure:
## Summary
- Key change 1
- Key change 2
## Changes
- List of specific changes
## Test Plan
- [ ] Unit tests passing
- [ ] Integration tests passing
- [ ] Manual testing done
## Related
- Refs: Task N, Issue #X
9. Suggest Labels
| Commit Type | Labels |
|---|---|
| feat | feature, enhancement |
| fix | bug, bugfix |
| refactor | refactoring, tech-debt |
| docs | documentation |
| ci | ci/cd |
| security | security |
Check available labels: gh label list
10. Create PR
Show content to user first, then:
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)
- Test results (must pass)
- Available labels in repo
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
Related Skills
- git-commit - Commit message format and conventions
- pr-merge - For merging existing PRs
- pr-review - For handling PR review comments