Agent skill

pr

Create or update a GitHub pull request. Use when asked to create a PR, submit for review, or push changes as a PR. Not for code review comments — use conventional-comments for that.

Stars 0
Forks 0

Install this agent skill to your Project

npx add-skill https://github.com/hairihou/dotfiles/tree/main/src/.config/claude/skills/pr

SKILL.md

Pull Request

Context

  • Current branch: !git rev-parse --abbrev-ref HEAD
  • Default branch: !gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' 2>/dev/null || echo 'unknown'
  • Diff summary: !git diff HEAD --stat
  • Git status: !git status -b --porcelain
  • Remote: !git remote -v | head -1

Conventions

Branch Naming

  • <type>/<description> — standard format
  • #<issue>_<type>/<description> — with auto issue linking

Commit Format

  1. Check CONTRIBUTING.md, .gitmessage first (respect project conventions)
  2. Fallback to Conventional Commits

Conventional Commits Types

chore, docs, feat, fix, perf, refactor, style, test

PR Body Templates

Standard:

markdown
## Summary

<description>

With issue linking (#<number>_ branch):

markdown
closes #<number>

---

## Summary

<description>

Rules

  • PR body ends with a trailing newline (prevents gh pr create HEREDOC from corrupting the last line)
  • Base branch: argument if provided, otherwise default branch
  • Infer issue number from base branch name if possible (e.g., feature-7509-...#7509)

Steps

  1. Validate: If no staged/unstaged changes AND no untracked files in git status, inform user and exit

  2. Branch: If current branch is main/master OR equals the base branch, create new branch first

    sh
    git switch -c <branch-name>
    
  3. Commit (use types and format from Conventions above):

    sh
    # if more context needed
    git diff HEAD
    
    git add <specific-files>  # prefer specific files over `git add .`
    git commit -m "<type>(scope): <description>"
    
  4. Push:

    sh
    git push -u origin <branch-name>
    
  5. Create PR (or update if exists):

    sh
    # PR title: same as commit message subject (without scope prefix if redundant)
    # Base branch: $ARGUMENTS if provided, otherwise Default branch from Context
    # New PR (if branch starts with #<number>_, prepend "closes #<number>" to body)
    gh pr create --title "<title>" --body "<body>" --base <base-branch> --assignee @me --draft
    
    # Existing PR
    gh pr edit --title "<title>" --body "<body>"
    gh pr view --web
    

Error Handling

  • gh not installed or not authenticated → stop, instruct user to run gh auth login
  • Current branch already has an open PR → update existing PR instead of creating new
  • Push rejected → check if remote branch exists, suggest git pull --rebase
  • No changes to commit (clean working tree) → inform user, skip workflow

Expand your agent's capabilities with these related and highly-rated skills.

hairihou/dotfiles

retrospect

Guided personal reflection that separates fact, interpretation, and emotion through structured inquiry. Use when "something feels off", "need to process this", "had a conflict", or decisions feel unclear. Not for technical decision analysis — use devils-advocate for that.

0 0
Explore
hairihou/dotfiles

1on1-prep

Prepare for 1on1 meetings using a Psychological Safety x Responsibility framework. Use when preparing for a 1on1, noticing behavioral changes, or planning a difficult conversation with a report.

0 0
Explore
hairihou/dotfiles

bonsai

Maintain and groom config files in the current repository. Use when "bonsai", "tidy up", "prune configs", "clean up", "spring cleaning", or reviewing config health. Not for code quality review — use code-critic for that.

0 0
Explore
hairihou/dotfiles

npm-update-report

Dependency update workflow with vulnerability assessment and verification. Use when asked to check outdated packages, bump dependencies, run audit, do periodic dependency maintenance, or when security vulnerabilities are reported.

0 0
Explore
hairihou/dotfiles

session-insights

Analyze the current conversation for inefficiencies and improvement opportunities. Use when "how did this session go", "what went wrong", "what could I have done better", or reviewing session quality. Not for personal reflection — use retrospect. Not for logging work — use diary.

0 0
Explore
hairihou/dotfiles

conventional-comments

Format code review comments using Conventional Comments labels and decorations. Use when writing inline review comments on a PR diff. Not for creating PRs — use pr for that. Not for complexity analysis — use code-critic for that.

0 0
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results