gh-andrzejsliwa-claude-code-marketplace-plugins-github/commands/open-pr.md

Open Pull Request

You are executing the /open-pr command. Follow these steps precisely:

Parameters

• draft (optional): Create PR as draft if specified (e.g., /open-pr draft)

Step 0: Branch Check

CRITICAL: Run this check FIRST before any other steps.

Check current branch with git branch --show-current.

If on main or master branch:

1. Ask user for new branch name using AskUserQuestion:
   • "You're on the main/master branch. What should the new branch be called?"
   • Options:
     • "Auto-generate from changes" - Claude creates descriptive branch name based on changes
     • "Custom name" - User will provide branch name
2. Create and checkout new branch:
   • If auto-generate: analyze changes briefly to create branch name (format: feature/descriptive-name or fix/descriptive-name)
   • If custom: wait for user input, then git checkout -b <branch-name>

If on any other branch: Proceed to Step 1.

Step 1: Analyze Changes

Run git status and git diff to analyze all changes:

• Identify files modified/created by Claude in current session
• Identify unstaged/untracked files NOT modified by Claude
• Review conversation context to detect if session involved multiple distinct tasks (separate features, fixes, or refactorings discussed/implemented)

Step 2: Commit Strategy Questions

If you detect multiple distinct tasks from conversation context, ask user using AskUserQuestion tool (both questions in same group):

Question 1 (always ask if multiple tasks detected):

• "How should I commit these changes?"
  • "Single commit" - Commit all changes together
  • "Multiple logical commits" - Create separate commits for each distinct task/feature

Question 2 (ask ONLY if unstaged/untracked files exist that Claude didn't modify):

• "There are uncommitted changes not made in this session. Include them?"
  • "Yes, include all changes" - Stage and commit everything
  • "No, only Claude's changes" - Commit only files Claude modified
  • "Let me review first" - Show list of files and stop

Step 3: Create Commits

Commit Message Rules:

• Style: Concise, factual, savant-like. State what was done, not why (unless discussed during implementation)

• Simple changes: Title only (no description)

• Complex changes: Title + description

  • Description adds context about what was changed
  • Use facts, avoid self-praise adjectives ("improved", "optimized", "enhanced")
  • Only state intents if explicitly discussed during implementation

• Hard limit: 80 words total

• Format: Always use heredoc for commit message

• Footer: Always append:

  
  🤖 Generated with [Claude Code](https://claude.com/claude-code)
  
  Co-Authored-By: Claude <noreply@anthropic.com>
  

Examples:

# Simple change
git commit -m "$(cat <<'EOF'
Add user authentication middleware

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"

# Complex change
git commit -m "$(cat <<'EOF'
Refactor database connection pooling

Extracted connection logic into separate module. Added retry mechanism
for failed connections. Configured pool size based on environment variables.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"

If creating multiple logical commits:

• Create commits in chronological order of implementation
• Each commit should be self-contained and logical
• Follow same message rules for each commit

Step 4: Push Branch

Check if force-push is needed (git status shows diverged branch).

If force-push required: Ask user for confirmation before proceeding.

Otherwise: Auto-push with git push -u origin <branch-name>

On push failure: Explain error and ask if you should retry with alternative approach.

Step 5: Create Pull Request

PR Title: Use title from commit message (if single commit) or summarize all commits (if multiple)

PR Description Rules:

• Always include description (even for simple changes)

• Same style as commit messages: factual, concise, savant-like

• For single commit: Expand on commit message with more context

• For multiple commits: List key changes made across commits

• Avoid self-praise language, state facts only

• Hard limit: 150 words

• Footer: Always append:

  
  🤖 Generated with [Claude Code](https://claude.com/claude-code)
  

PR Metadata:

• Auto-detect default branch (main/master) as base
• If draft parameter passed: add --draft flag
• No labels/reviewers unless user specifies

Create PR:

gh pr create --title "PR title" --body "$(cat <<'EOF'
PR description content here.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)" [--draft]

On PR creation failure: Explain error and ask if you should retry with alternative approach.

Step 6: Open PR Page

After successful PR creation, extract PR URL from gh output and open it:

xdg-open <PR_URL>

Error Handling

If any step fails:

1. Explain what went wrong clearly
2. Provide the specific error message
3. Ask user if you should retry with an alternative approach
4. If user confirms, attempt automatic fix or provide manual commands

Final Output

After successful completion, output:

• Commit SHA(s)
• Branch name
• PR URL
• Confirmation that PR page was opened