Menu
create a pull request with standardized description template
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | create-pr |
| description | create a pull request with standardized description template |
| disable-model-invocation | true |
Create a pull request with a well-structured description based on the branch changes.
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
Based on the gathered information, determine:
Look for issue references:
fix/issue-123-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
)"
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 tasksAfter 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
| Label | When to Use |
|---|---|
enhancement | New features, capabilities, or improvements |
bug | Bug fixes |
documentation | Documentation-only changes |
breaking-change | User-facing breaking changes requiring migration |
Only apply breaking-change for user-facing changes that require users to modify their:
Do NOT apply for internal refactors unless they affect external consumers.
After creating the PR:
DO:
DON'T:
Create Claude Code skills with best practices, structure, validation, and testing. Use when designing or refining skills, prompts, references, or supporting files.
Use when the user wants a cited, structured read of local documents and project knowledge. Triggers on: "analyze these docs", "scan my project for context", "read the docs folder", "summarize what's in .beagle/concepts/", "extract context from docs/", "what's in this folder", "go read everything in X and tell me what's there". Also invoked programmatically by other beagle skills (prfaq-beagle Ignition, brainstorm-beagle reference points, strategy-interview context grounding) via the companion contract. Does NOT trigger on codebase lookups ("find this function", "search the repo"), web research (use web-research), LLM-as-judge evaluation (use llm-judge), or document editing (use humanize-beagle). Produces a written scan plan, parallel-subagent findings, and a cited synthesis report on disk — never inline prose, never unsourced claims.
Use when the user has a fuzzy idea and wants to shape it into a concrete project spec before planning or building. Triggers on: "brainstorm this", "I have an idea for...", "help me think through this project", "what should I build", "spec this out". Also catches vague feature descriptions needing structured questioning to clarify scope. Does NOT write code, plan implementation, review strategy docs, or run strategy interviews — produces a WHAT/WHY spec through dialogue, not a HOW plan.
Use when the user wants to pressure-test a product, internal-tool, or OSS concept against Amazon's Working Backwards PRFAQ gauntlet before committing to a spec. Triggers on: "work backwards", "write a PRFAQ", "press release first", "is this idea worth building", "pressure-test this concept", "filter this before brainstorm", "is this a real product". Also catches solution-first pitches ("I want to build X that does Y") and technology-first pitches ("use AI to...") that need customer-first filtering. Produces a binary pass/fail verdict, not a polished doc. Hardcore coaching — direct, skeptical, concrete. On pass, hands off to brainstorm-beagle with a concept brief. Does NOT write code, plan implementation, scaffold projects, or draft specs.
Use when the user wants web research: gathering cited, multi-angle evidence on a specific question. Triggers on: "research X for me", "do web research on", "look up sources for", "find citations for", "gather evidence on", "what does the web say about X". Also invoked programmatically by other beagle skills (prfaq-beagle Ignition, brainstorm-beagle reference points, strategy-interview context grounding) via the companion contract. Does NOT trigger on codebase lookups ("find this function", "search the repo"), local file search, LLM-as-judge evaluation, or paywalled/auth-gated scraping. Produces a written plan, parallel-subagent findings, and a cited synthesis report on disk — never inline prose, never unsourced claims.
generate release notes for changes since a given tag