create-pr
create a pull request with standardized description template
Install via CLI (Recommended)
clawhub install openclaw/skills/skills/anderskev/create-pr-skipCreate Pull Request
Create a pull request with a well-structured description based on the branch changes.
Instructions
Gates (run in order)
Do not draft or run gh pr create until each step passes.
- Branch gate:
git branch --show-currentis not the default branch (main,master, or the repo’s documented default). Pass: branch name is printed and satisfies this. - Evidence gate: You have run the commands in Gather Context for the same
main..HEAD(ororigin/main..HEADif localmainis missing) range you will summarize. Pass: you can name at least one commit subject and one area of files changed without inventing details. - Template gate: The final PR title and body contain no unreplaced placeholders (
<...>,TODO,TBD). Optional sections with no content are removed, not left as stubs. Pass: a quick scan finds no angle-bracket placeholders or filler tokens. - Create gate:
gh pr createexits successfully and prints a PR URL (or the PR number/URL fromghoutput). Pass: URL (or id) is recorded; if the command fails, do not claim the PR was created.
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
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-anderskev-create-pr-skip": {
"enabled": true,
"auto_update": true
}
}
}Related Skills
explanation-docs
Explanation documentation patterns for understanding-oriented content - conceptual guides that explain why things work the way they do
tutorial-docs
Tutorial patterns for documentation - learning-oriented guides that teach through guided doing
pytest-code-review
Reviews pytest test code for async patterns, fixtures, parametrize, and mocking. Use when reviewing test_*.py files, checking async test functions, fixture usage, or mock patterns.
reference-docs
Reference documentation patterns for API and symbol documentation. Use when writing reference docs, API docs, parameter tables, or technical specifications. Triggers on reference docs, API reference, function reference, parameters table, symbol documentation.
serde-code-review
Reviews serde serialization code for derive patterns, enum representations, custom implementations, and common serialization bugs. Use when reviewing Rust code that uses serde, serde_json, toml, or any serde-based serialization format. Covers attribute macros, field renaming, and format-specific pitfalls.