
pull-request
by vm0-ai
the easiest way to run natural language-described workflows automatically
SKILL.md
name: pull-request description: PR lifecycle management - create PRs with proper commits, merge with validation, and manage PR comments allowed-tools: Bash, Read, Grep context: fork
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
This skill supports four main operations. Parse the args parameter to determine which operation to perform:
- create - Create a new PR or update existing one
- merge - Validate checks and merge PR
- list - List open pull requests for the repository
- comment [pr-id] - Summarize conversation and post as PR comment
When invoked, check the args to determine the operation and execute accordingly.
Operation 1: Create PR
Workflow
Step 1: Check Current Branch and PR Status
# 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
- Run
git statusto see all changes - Run
git diffto understand the nature of changes - Review recent commits with
git log --oneline -5for style consistency - Determine the appropriate commit type and message
Step 4: Run Pre-Commit Checks
CRITICAL: All checks MUST pass before committing.
cd turbo
pnpm install
pnpm format # Auto-format code
pnpm lint # Check for linting issues
pnpm check-types # Verify TypeScript type safety
pnpm test # Run all tests
If checks fail:
- Auto-fix formatting/linting issues
- For type errors: review and fix manually
- For test failures: debug and fix
- Re-run checks until all pass
Step 5: Stage, Commit, and Push
git add -A
git commit -m "<type>: <description>"
git push -u origin <branch-name> # -u for new branches
Step 6: Create Pull Request
gh pr create --title "<type>: <description>" --body "<brief description>"
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 changesstyle: Code style changesrefactor: Code refactoringtest: Test additions/changeschore: Build/auxiliary tool changesci: CI configuration changesperf: Performance improvementsbuild: Build system changesrevert: 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 systemfix: resolve database connection timeoutdocs(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 successfullyfail: Must be fixed before mergepending: Still running, need to waitskipping: 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 Show Summary
git fetch origin
git diff origin/main...HEAD --stat
gh pr view --json title -q '.title'
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:
Merge failed: conflicts detected
Please resolve conflicts manually:
1. git fetch origin
2. git merge origin/main
3. Resolve conflicts
4. Push changes
5. Try merge again
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. Pre-commit checks: PASSED
3. Changes staged: <file count> files
4. Committed: <commit message>
5. Pushed to remote
6. 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
- Always check branch status first - Don't assume the current state
- Run pre-commit checks - Never skip quality checks
- Never merge with failing checks - Code quality is non-negotiable
- Use squash merge - Keeps main history clean
- Confirm merge completion - Verify PR state is MERGED
- 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.
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
1ヶ月以内に更新
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon


