Skills create-pr
create a pull request with standardized description template
install
source · Clone the upstream repo
git clone https://github.com/openclaw/skills
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/openclaw/skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/anderskev/create-pr-skip" ~/.claude/skills/openclaw-skills-create-pr && rm -rf "$T"
OpenClaw · Install into ~/.openclaw/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/openclaw/skills "$T" && mkdir -p ~/.openclaw/skills && cp -r "$T/skills/anderskev/create-pr-skip" ~/.openclaw/skills/openclaw-skills-create-pr && rm -rf "$T"
manifest:
skills/anderskev/create-pr-skip/SKILL.mdsource content
Create Pull Request
Create a pull request with a well-structured description based on the branch changes.
Instructions
1. Gather Context
First, collect information about the changes:
# Get current branch and verify it's not main git branch --show-current # Get commit history for this branch git log --oneline main..HEAD # Get detailed commit messages for context git log --format="### %s%n%n%b" main..HEAD # Get file change statistics git diff --stat main..HEAD # Get the actual diff for understanding changes git diff main..HEAD
2. Analyze the Changes
Based on the gathered information, determine:
- What changed: Categorize changes (features, fixes, refactors, docs, tests)
- Why it changed: Infer motivation from commit messages and code changes
- Impact: Breaking changes, new dependencies, migrations needed
- Testing: What tests were added/modified, how to verify manually
3. Check for Related Issues
Look for issue references:
- In commit messages (e.g., "fixes #123", "closes #456")
- In branch name (e.g.,
)fix/issue-123-description - In code comments or TODOs addressed
4. Generate PR Description
Create the PR using this template structure:
gh pr create --title "<type>(<scope>): <description>" --body "$(cat <<'EOF' ## Summary <1-3 sentence overview of what this PR does and why> ## Changes <Categorized bullet list of changes> ### Added - <new features or capabilities> ### Changed - <modifications to existing functionality> ### Fixed - <bug fixes> ### Removed - <deprecated or removed functionality> ## Motivation <Why were these changes needed? What problem does this solve?> ## Testing <How was this tested?> - [ ] Unit tests added/updated - [ ] Integration tests added/updated - [ ] Manual testing performed ### Manual Testing Steps <If applicable, steps to manually verify the changes> ## Breaking Changes <If any, describe what breaks and migration path. Remove section if none.> ## Related Issues <Link to related issues. Remove section if none.> - Closes #<issue_number> - Related to #<issue_number> ## Checklist - [ ] Code follows project style guidelines - [ ] Self-review completed - [ ] Tests pass locally - [ ] Linting passes - [ ] Documentation updated (if needed) --- Generated with [Claude Code](https://claude.com/claude-code) EOF )"
5. Title Format
Use conventional commit format for the PR title:
feat(scope): add new featurefix(scope): correct bug behaviorrefactor(scope): restructure without behavior changedocs(scope): update documentationtest(scope): add or modify testschore(scope): maintenance tasks
6. Apply Labels
After creating the PR, apply appropriate labels based on the changes. Use
gh pr edit <number> --add-label <label>.
Check the repository's available labels first:
gh label list
Common Type Labels
| Label | When to Use |
|---|---|
| New features, capabilities, or improvements |
| Bug fixes |
| Documentation-only changes |
| User-facing breaking changes requiring migration |
Breaking Change Criteria
Only apply
breaking-change for user-facing changes that require users to modify their:
- Configuration files
- CLI invocations
- API integrations
Do NOT apply for internal refactors unless they affect external consumers.
7. After Creation
After creating the PR:
- Display the PR URL with applied labels
- Suggest adding reviewers if appropriate
- Note if any CI checks need to pass
Guidelines
DO:
- Be specific about what changed and why
- Include testing evidence
- Link related issues
- Note breaking changes prominently
- Remove empty optional sections
DON'T:
- Include irrelevant commits (keep PR focused)
- Leave placeholder text in the description
- Skip the testing section
- Create PRs without running local checks first