create-pull-request
This skill contains shell command directives (!`command`) that may execute system commands. Review carefully before installing.
Create Pull Request
Mode: $ARGUMENTS
If --draft is passed, create as draft PR.
Pre-loaded context
- Branch status: !
git status && git branch -vv - Recent commits: !
git log --oneline -10
Workflow
- Run in parallel:
git fetch origin && git remote show origin | grep 'HEAD branch' | cut -d' ' -f5(get base branch)git rev-parse --abbrev-ref HEAD | grep -oE '[A-Z]+-[0-9]+'(extract ticket ID)- Search for PR template (see template-locations.md)
- Run in parallel:
git diff HEADgit diff [base-branch]...HEAD --unified=0
- Read template if found
- Review ALL commits (not just latest)
- Ask the user (use AskUserQuestion when available; otherwise ask directly). Ask all at once where possible:
- Effort (required): how long the task took in hours (planning, reading, testing, all included)
- Changes (required): general overview of what was done
- Testing (optional): testing done that isn't visible in the diff
- Tricky parts (optional): anything hard, requiring multiple attempts, or non-obvious
- If template found, also surface any template-specific fields that can't be inferred from the diff (e.g. "Does this include breaking changes?", "What type of change is this?")
- Draft title and body:
- Title must match:
/^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)(\(.*\))?: .+$/ - If template found: use the template verbatim as the body base — fill every section/placeholder using diff + user answers; check applicable checkboxes; do NOT add sections not in the template; do NOT omit any template sections
- If no template: use Summary + Test plan
- Reference ticket ID in body if found (e.g.
Resolves TICKET-123) - Incorporate user's answers into description — don't just repeat the diff
- Title must match:
- In parallel:
- Create branch if needed
- Push with
-uif needed - Create PR with
gh pr createusing HEREDOC (add--draftif requested)
See examples.md for output format and gh-flags.md for advanced options.
Rules
- If a PR template exists, the body MUST be the filled template — not a summary that references it
- Analyze ALL commits, not just the latest
- Return PR URL when done
- Use
ghCLI only - NEVER force push to main/master
- NEVER push without user confirmation if already on main/master
- NEVER create PR with uncommitted changes — commit first
Error Handling
- If
gh pr createfails with "already exists" → rungh pr viewand return existing PR URL - If branch is not pushed → run
git push -u origin HEADbefore creating PR - If
gh auth statusfails → ask user to rungh auth loginand retry
More from helderberto/skills
explain-code
Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?" Don't use for modifying code, fixing bugs, or generating new implementations.
45ship
Commit and push changes using atomic commits. Use when user asks to "ship", "commit and push", or requests committing and pushing changes. Don't use for creating pull requests or reviewing changes before committing.
45refactor-plan
Create structured refactoring plans. Use when user wants to plan a refactor, needs a refactoring strategy, or mentions breaking down large changes into small commits. Don't use for implementing code changes directly, small one-line fixes, or renaming a single variable.
44safe-repo
Check for sensitive data in repository. Use when user asks to "check for sensitive data", "/safe-repo", or wants to verify no company/credential data is in the repository. Don't use for general code review, adding .gitignore entries, or scanning non-git directories.
41lint
Run linting and formatting checks. Use when user asks to "run linter", "/lint", "check linting", "fix lint errors", or requests code linting/formatting. Don't use for running tests, type-checking only, or projects without a lint script in package.json.
40tdd
Guides test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants test-first development, or requests TDD workflow. Don't use for writing tests after implementation, adding tests to existing untested code, or one-off test fixes.
40