PR Advocacy

Monitor PR status every 4 hours, promptly address feedback and CI issues, communicate clearly within 24 hours, and drive reviews to timely merge.

PR Advocacy Skill

Purpose

Actively monitor, respond to, and drive Pull Request reviews to completion. This skill ensures PRs don't get stuck in review limbo and addresses maintainer feedback promptly.

Core Responsibilities

1. PR Status Monitoring

• Check PR status every heartbeat cycle (1 hour)
• Monitor CI/CD check results
• Track reviewer comments and requested changes
• Identify blocking vs non-blocking feedback

2. Professional Response Protocol

• Acknowledge all reviewer feedback within 24 hours
• Provide clear, technical responses to questions
• Implement requested changes promptly when valid
• Politely justify decisions when disagreeing with feedback

3. Proactive Issue Resolution

• Fix CI/CD failures immediately
• Address merge conflicts proactively
• Update documentation when code changes
• Add tests for edge cases identified by reviewers

4. PR Health Assessment

• Green Status: All checks pass, no pending reviews → Wait for merge
• Yellow Status: Minor feedback, passing checks → Respond and wait
• Red Status: Failing checks or major feedback → Immediate action required
• Stale Status: No activity for 48+ hours → Gentle ping to reviewers

PR Status Processing Rules

OPEN State Handling

When a PR is in OPEN state:

• Check for maintainer/reviewer comments pointing out issues
• If feedback requires changes:
  • Analyze the specific feedback content
  • Create fixes according to maintainer suggestions
  • Automatically commit changes to the PR branch
  • Update PR description if needed
  • Record fix details for learning
• If no issues found:
  • Continue monitoring CI/CD status
  • Wait for merge approval

CLOSED/REJECTED State Handling

When a PR is CLOSED or REJECTED:

• Immediately remove from active tracking list
• Stop all monitoring activities for this PR
• Record closure reason for future learning and improvement
• Do not attempt to resubmit unless explicitly instructed

MERGED State Handling

When a PR is successfully MERGED:

• Remove from active tracking list
• Add to merged records for success tracking
• Celebrate the contribution!
• Update skills and workflows based on successful patterns

Real-time Tracking List Synchronization

Automatic Updates

• After any PR status change, immediately update the tracking list file
• When PRs are added/removed, synchronize the tracking list in real-time
• Prevent information loss by ensuring all changes are persisted to disk
• Maintain accurate state by writing updates immediately after processing

Tracking List File Management

• Location: /Users/hope/.openclaw/agents/coding/workspace/memory/pr-tracking-list.md
• Format: Markdown with clear sections for active, closed, and merged PRs
• Updates: Atomic writes to prevent corruption during concurrent access
• Backup: Maintain version history through git commits for rollback capability

Synchronization Workflow

1. Detect PR status change (OPEN/CLOSED/MERGED)
2. Process the change according to status rules
3. Update tracking list file immediately with new state
4. Verify file integrity to ensure no data loss
5. Log the update for audit trail and debugging

Error Handling

• File write failures: Retry with exponential backoff
• Concurrent access: Use atomic file operations to prevent race conditions
• Data corruption: Validate file format before and after updates
• Recovery: Maintain backup copies for emergency restoration

Implementation Guidelines

Check Status Analysis

bash

# Check PR status and checks
gh pr view <PR_NUMBER> --json statusCheckRollup,reviewDecision

# Common check statuses:
# - SUCCESS: All good
# - FAILURE: Needs immediate fixing  
# - PENDING: Still running
# - NEUTRAL: Non-blocking (like coverage)

Reviewer Feedback Response Template

text

Thanks for the review! 

For [specific comment]:
- [Action taken or explanation]
- [Technical justification if disagreeing]

I've [implemented the change / pushed an update / clarified the approach] in [commit reference].

Let me know if you need any additional changes!

Common PR Issues & Solutions

CI/CD Failures

• Lint errors: Run npm run lint -- --fix locally first
• Test failures: Reproduce locally, add missing test cases
• Build errors: Verify dependencies, check Node.js version compatibility

Code Review Feedback

• Style issues: Follow project's .editorconfig and style guide
• Architecture concerns: Reference existing patterns in codebase
• Security concerns: Prioritize security fixes, add validation layers

Documentation Gaps

• Missing docs: Add/update relevant documentation files
• Inconsistent formatting: Use project's markdown template
• Outdated examples: Update code examples to match new implementation

Automation Integration

Heartbeat Integration

• Integrate with existing heartbeat monitoring system (every hour)
• Add PR status to daily summary reports
• Escalate stale PRs after 48 hours of inactivity

Memory Tracking

• Maintain PR tracking list in workspace memory
• Automatically clean up closed/rejected PRs from tracking list
• Real-time synchronization of tracking list file after any PR status change
• Record resolution outcomes for learning
• Update core memory with successful advocacy patterns

Automatic Response Workflow

1. Detect feedback on OPEN PRs
2. Analyze requirements and create appropriate fixes
3. Commit changes to existing PR branch
4. Update tracking status and notify maintainers
5. Handle closure by removing from active monitoring
6. Synchronize tracking list file immediately after any change

Success Metrics

• Response time: < 24 hours to reviewer feedback
• Resolution rate: > 90% of PRs merged within 7 days
• Rework rate: < 10% of PRs require major revisions after initial review
• Maintainer satisfaction: Positive feedback from maintainers on communication quality
• Data integrity: 100% tracking list accuracy with zero information loss

Best Practices

Communication

• Be concise but thorough in responses
• Use code blocks for technical explanations
• Reference specific line numbers when discussing changes
• Thank reviewers for their time and expertise

Technical Excellence

• Ensure changes are minimal and focused
• Maintain backward compatibility when possible
• Follow project conventions exactly
• Test changes thoroughly before pushing

Professionalism

• Never argue with reviewers; seek to understand their perspective
• Admit mistakes quickly and fix them
• Offer to help with related issues when appropriate
• Celebrate successful merges and thank maintainers