Pull Request

# Get current branch
current_branch=$(git branch --show-current)

# Check if on main branch
if [ "$current_branch" = "main" ]; then
    need_new_branch=true
else
    # Check if current branch has a PR and if it's merged
    pr_status=$(gh pr view --json state,mergedAt 2>/dev/null)
    if [ $? -eq 0 ]; then
        is_merged=$(echo "$pr_status" | jq -r '.mergedAt')
        pr_state=$(echo "$pr_status" | jq -r '.state')

        if [ "$is_merged" != "null" ] || [ "$pr_state" = "MERGED" ]; then
            need_new_branch=true
        else
            need_new_branch=false
        fi
    else
        need_new_branch=false
    fi
fi

Step 2: Create Feature Branch (if needed)

Branch Naming Convention: <type>/<short-description>

• Examples: fix/typescript-errors, feat/add-cli-command, docs/update-readme

if [ "$need_new_branch" = "true" ]; then
    git checkout main
    git pull origin main
    git checkout -b <branch-name>
fi

Step 3: Analyze Changes

1. Run git status to see all changes
2. Run git diff to understand the nature of changes
3. Review recent commits with git log --oneline -5 for style consistency
4. Determine the appropriate commit type and message

Step 4: Stage, Commit, and Push

git add -A
git commit -m "<type>: <description>"
git push -u origin <branch-name>  # -u for new branches

Step 5: Create Pull Request

gh pr create --title "<type>: <description>" --body "<brief description>" --assignee @me
gh pr view --json url -q .url

Commit Message Rules

Format:

<type>[optional scope]: <description>

Valid Types:

• feat: New feature (triggers minor release)
• fix: Bug fix (triggers patch release)
• docs: Documentation changes
• style: Code style changes
• refactor: Code refactoring
• test: Test additions/changes
• chore: Build/auxiliary tool changes
• ci: CI configuration changes
• perf: Performance improvements
• build: Build system changes
• revert: Revert previous commit

Requirements:

• Type must be lowercase
• Description must start with lowercase
• No period at the end
• Keep under 100 characters
• Use imperative mood (add, not added)

Examples:

• feat: add user authentication system
• fix: resolve database connection timeout
• docs(api): update endpoint documentation

Operation 2: Merge PR

Workflow

Step 1: Check PR Status and CI Checks

gh pr view --json number,title,state
gh pr checks

Check Status:

• pass: Completed successfully
• fail: Must be fixed before merge
• pending: Still running, need to wait
• skipping: Skipped (acceptable)

Retry Logic:

• Wait 30 seconds between retries
• Retry up to 3 times (90 seconds max)
• Only proceed when all non-skipped checks pass

Step 2: Fetch Latest and Resolve Conflicts

git fetch origin
git diff origin/main...HEAD --stat
gh pr view --json title -q '.title'

Check for merge conflicts with main:

# Check if branch can be cleanly merged
git merge-tree $(git merge-base HEAD origin/main) HEAD origin/main

If conflicts exist, resolve them automatically:

1. Merge main into the current branch: git merge origin/main
2. Analyze each conflict and resolve it intelligently based on the intent of both changes
3. Stage resolved files: git add <resolved-files>
4. Complete the merge: git commit --no-edit
5. Push the updated branch: git push
6. Wait for CI checks to re-run before proceeding to Step 3

If a conflict cannot be resolved automatically (e.g., both sides make incompatible structural changes), stop and ask the user for guidance on that specific conflict.

Step 3: Merge the PR

Strategy: Squash and merge

gh pr merge --squash --delete-branch
sleep 3
gh pr view --json state,mergedAt

Why squash merge:

• Keeps main branch history clean and linear
• Combines all commits into single commit
• Automatically deletes feature branch

Step 4: Switch to Main and Pull Latest

git checkout main
git pull origin main
git log --oneline -1

Error Handling

No PR Found:

Error: No PR found for current branch

CI Checks Failing:

CI Checks Failed

The following checks are failing:
- <check-name>: fail - <url>

Action required: Fix failing checks before merging
Retrying in 30 seconds... (Attempt N/3)

Merge Conflicts:

Conflicts are resolved automatically in Step 2. If auto-resolution fails for any file:

Merge Conflict: Cannot auto-resolve

The following files have conflicts that require manual input:
- <file-path>: <brief description of the conflict>

Asking user for guidance...

Output Formats

Create PR Output:

PR Creation Workflow

Current Status:
   Branch: <branch-name>
   Status: <new/existing>

Actions Completed:
   1. [Branch created/Using existing branch]
   2. Changes staged: <file count> files
   3. Committed: <commit message>
   4. Pushed to remote
   5. PR created

Pull Request: <PR URL>

Merge Output:

PR Merge Workflow

PR Information:
   Number: #<number>
   Title: <title>

CI Checks: All passed

Changes Summary:
   Files changed: <count>
   Insertions: +<count>
   Deletions: -<count>

Actions Completed:
   1. CI checks validated
   2. PR squash merged
   3. Feature branch deleted
   4. Switched to main
   5. Pulled latest changes

Latest commit: <hash> <message>

Operation 3: List PRs

List all open pull requests in the current repository.

Workflow

gh pr list --state open

Display the list of open PRs with their numbers, titles, and branch names.

Operation 4: Comment

Summarize conversation discussion and post as PR comment for follow-up.

Arguments

• comment [pr-id] - Post conversation summary to specific PR

Workflow

Step 1: Detect PR Number

If PR ID not provided, detect from conversation context or current branch.

Step 2: Analyze Conversation

Review recent conversation to identify:

• Key discussion points and decisions
• Technical findings or analysis results
• Action items or follow-up tasks
• Recommendations or suggestions
• Open questions requiring input

Step 3: Structure Comment

Organize based on content type (technical memo, follow-up tasks, etc.):

## [Topic from Discussion]

[Summary of key points]

### Action Items
- [ ] Task 1
- [ ] Task 2

### Technical Notes
[If applicable]

Step 4: Post Comment

gh pr comment "$PR_NUMBER" --body "$COMMENT_CONTENT"

Best Practices

1. Always check branch status first - Don't assume the current state
2. Never merge with failing checks - Code quality is non-negotiable
3. Use squash merge - Keeps main history clean
4. Confirm merge completion - Verify PR state is MERGED
5. Keep user informed - Clear status at each step

Related Skills

• pr-check - CI monitoring and auto-fixing
• pr-review - Code review and feedback

Prerequisites

• GitHub CLI (gh) installed and authenticated
• Not on main branch (for create/merge)
• All dependencies installed
• Proper repository permissions

Your goal is to make the PR lifecycle smooth, consistent, and compliant with project standards.