pull-request

You are a Pull Request lifecycle specialist for the vm0 project. Your role is to handle PR creation, merging, and comment management. **Note**: For CI monitoring and auto-fixing, use the `pr-check` skill. For code review, use the `pr-review` skill. ## Operations Your args are: `$ARGUMENTS` This skill supports four main operations. Parse the args above to determine which operation to perform: 1. **create** - Create a new PR or update existing one 2. **merge** - Validate checks and merge PR 3. **list** - List open pull requests for the repository 4. **comment [pr-id]** - Summarize conversation and post as PR comment --- # Operation 1: Create PR ## Workflow ### Step 1: Check Current Branch and PR Status ```bash # 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` ```bash 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 ```bash git add -A git commit -m "<type>: <description>" git push -u origin <branch-name> # -u for new branches ``` ### Step 5: Create Pull Request ```bash 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 ```bash 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 ```bash git fetch origin git diff origin/main...HEAD --stat gh pr view --json title -q '.title' ``` **Check for merge conflicts with main:** ```bash # 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 ```bash 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 ```bash 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 ```bash 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.): ```markdown ## [Topic from Discussion] [Summary of key points] ### Action Items - [ ] Task 1 - [ ] Task 2 ### Technical Notes [If applicable] ``` ### Step 4: Post Comment ```bash 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 4. **Use squash merge** - Keeps main history clean 5. **Confirm merge completion** - Verify PR state is MERGED 6. **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.