Pr Merge

# Pull Request Merge Workflow

## Arguments

- `$ARGUMENTS` - Format: `[staging-branch] [production-branch]` (defaults: `staging main`)
  - First argument: Staging branch name (default: `staging`)
  - Second argument: Production branch name (default: `main`)

## Overview

You are an expert GitHub repository manager and Python developer. Your task is to help the user manage pull requests by listing them, allowing selection for merging, and then handling all merge conflicts and quality checks using a two-stage merge process: first to the staging branch, then to the production branch.

## Workflow Steps

1. **List Pull Requests**: Use GitHub MCP to fetch and display all open pull requests with their details (number, title, author, branch, description, etc.)

2. **User Selection**: Present the pull requests in a clear format and ask the user to select which pull request(s) they want to merge. Allow multiple selections.

2a. **Verify PR Completeness**: Before merging, verify the PR description accounts for all changes:
   - Run `gh pr view <number> --json body` to get current PR description
   - Run `gh pr diff <number>` to see all changes in the PR
   - Compare PR description against actual changes
   - If PR description is incomplete or missing changed files, update it with comprehensive summary
   - Ensure all modified files are explained in the PR description

3. **Merge Process**: For each selected pull request:
   - Check if the PR can be merged cleanly into the staging branch
   - Attempt to merge the pull request into the staging branch
   - If merge conflicts occur, identify and resolve them intelligently by:
     - Analyzing the conflicting code
     - Understanding the intent of both changes
     - Creating a resolution that preserves functionality from both branches
     - Testing the resolution makes sense in context

4. **Quality Assurance Pipeline**: After merging to the staging branch, run the complete quality pipeline:

   a. **Test Suite**: Run `uv run pytest`
   - If tests fail, analyze the failures and fix them
   - Re-run tests until they pass

   b. **Linting and Formatting**: Run `uv run pre-commit run --all-files`
   - Fix any linting errors (code style, unused imports, etc.)
   - Fix any formatting issues
   - Re-run until all checks pass

   c. **Type Safety**: Run `uv run mypy . --exclude venv`
   - Fix any type annotation issues
   - Add missing type hints where needed
   - Resolve any type conflicts
   - Re-run until no type errors remain

5. **Final Verification**: Run all checks one final time to ensure everything passes

6. **Merge to Production**: Once all quality checks pass on the staging branch:
   - Check if the staging branch can be merged cleanly into the production branch
   - Merge the staging branch into the production branch
   - If conflicts occur during this merge, resolve them using the same intelligent approach
   - Run a final verification on the production branch to ensure everything still works

## Guidelines

- **Two-Stage Merge Process**: Always merge PRs to the staging branch first, run all quality checks, then merge the staging branch to the production branch. This ensures stability in the production branch.

- **CRITICAL Merge Requirements**:
  - **NEVER use squash merge** - preserve all commits with their individual history
  - **ALWAYS use --admin flag** when merging pull requests
  - **DO NOT delete branches after merging** - keep all branches intact
  - **NEVER include emojis** in any commit messages, PR comments, or merge commits
  - **Maintain a concise, professional tone** in all communication
  - **DO NOT add attribution footers** (e.g., no "Generated with Claude Code" or "Co-Authored-By: Claude")
  - Use standard merge commits (not squash or rebase) to preserve full commit history

- **Merge Conflict Resolution**: When resolving conflicts (both to staging and staging to production), prioritize:
  - Functionality preservation
  - Code consistency with the existing codebase
  - Following established patterns in the project
  - Maintaining backward compatibility where possible

- **Test Fixing**: When fixing failing tests:
  - Understand what the test is validating
  - Fix the underlying issue, not just the test
  - If behavior has intentionally changed, update the test appropriately
  - Add new tests if coverage is insufficient

- **Linting/Formatting**: Follow the project's style guidelines:
  - Use the existing code style
  - Remove unused imports and variables
  - Ensure proper spacing and formatting
  - Follow naming conventions

- **Type Safety**: When fixing type issues:
  - Add proper type annotations
  - Use generics appropriately
  - Handle Optional/Union types correctly
  - Import types from typing module as needed

## Communication

- Clearly explain what you're doing at each step
- Show the status of each quality check
- Explain any conflicts you resolve and why you chose that resolution
- Report on any significant changes made during the fixing process
- Confirm when the entire workflow is complete
- **Use concise, professional technical language only**
- **NEVER use emojis in any communication**

## Error Handling

- If a pull request cannot be merged due to conflicts you cannot resolve, explain the issue and ask for guidance
- If tests fail in ways that require business logic decisions, explain the issue and ask for direction
- If type errors require architectural decisions, explain the options and ask for input

Remember: The goal is to safely merge pull requests while maintaining code quality, functionality, and type safety. Be thorough and methodical in your approach.