← 返回
开发者工具 中文

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.
每4小时检查PR状态,及时处理反馈和CI问题,24小时内清晰沟通,推动审查及时合并。
linux2010 linux2010 来源
开发者工具 clawhub v1.0.3 1 版本 99873.6 Key: 无需
★ 0
Stars
📥 790
下载
💾 13
安装
1
版本
#automation#github#latest#pr#review#tracking

概述

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

# 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

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

版本历史

共 1 个版本

  • v1.0.3 当前
    2026-03-29 23:53 安全 安全

安全检测

腾讯云安全 (Keen)

安全,无风险
查看报告

腾讯云安全 (Sanbu)

安全,无风险
查看报告

🔗 相关推荐

dev-programming

Github

steipete
使用 `gh` CLI 与 GitHub 交互,通过 `gh issue`、`gh pr`、`gh run` 和 `gh api` 管理议题、PR、CI 运行及高级查询。
★ 676 📥 325,551
data-analysis

ECharts Master

linux2010
ECharts 图表大师。根据用户数据和业务上下文,自动设计并生成专业的 ECharts 可视化图表。使用场景:(1) 用户提供表格/JSON/CSV 数据需要可视化,(2) 用户说"帮我做个图"、"画个图表",(3) 需要将查询结果可视化
★ 0 📥 1,039
dev-programming

CodeConductor.ai

larsonreever
AI驱动平台,提供快速全栈开发、智能体、工作流自动化及低代码AI集成的可扩展产品创建。
★ 71 📥 181,355