npx claudepluginhub bae-changhyun/cc-plugins-bch --plugin gitwfWant just this skill?
Add to a custom plugin, then install with one command.
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.
This skill uses the workspace's default tool permissions.
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