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.

Security Scan

The skill's instructions expect filesystem writes, git/gh operations, and automatic commits but the metadata doesn't declare required binaries, credentials, or config paths — this mismatch is risky and unexplained.

Purpose & Capability

The name/description (PR monitoring and advocacy) matches the instructions, but the skill metadata declares no required binaries, env vars, or config paths while the SKILL.md expects tools like gh, git, npm and write access to a user workspace. Declaring no dependencies/configs is inconsistent with the stated capabilities.

Instruction Scope

Instructions direct the agent to run gh and local commands, automatically create and commit fixes to PR branches, and persist a tracking file to a concrete path (/Users/hope/.openclaw/agents/coding/workspace/memory/pr-tracking-list.md). Those behaviors require repository write/push access and filesystem writes and go beyond simple monitoring — the skill can modify code and commit changes autonomously.

Install Mechanism

No install spec (instruction-only), which reduces installation risk. However, SKILL.md implicitly requires command-line tools (gh, git, npm) to be present and authenticated; those requirements are not declared in the registry metadata.

Credentials

The skill metadata lists no required credentials, yet runtime behavior requires authenticated GitHub/GH CLI access and permission to push commits. The SKILL.md also uses a hard-coded absolute path under /Users/hope which may not match the installer's environment and indicates implicit access to the user's workspace without being declared.

Persistence & Privilege

always:false (ok) but autonomous invocation is allowed (platform default). Combined with instructions to auto-commit changes, write persistent tracking files, and run hourly heartbeat flows, this creates a high-impact capability if the agent is allowed to run without explicit user confirmation.

Scan Findings in Context

[no_regex_findings] expected: The scanner found no code to analyze because this is an instruction-only skill. That explains the lack of findings but does not mitigate the instruction-specified risks (filesystem writes, git pushes, CLI usage).

What to consider before installing

This skill will (per its instructions) run gh/git/npm commands, modify repository branches, and write a tracking file to a hard-coded home path — yet the registry metadata does not declare the required binaries, credentials, or config path. Before installing: 1) Verify you want an automated agent that can commit and push changes; prefer a bot account with limited repo scopes rather than your personal credentials. 2) Confirm GH CLI/git/npm availability and how authentication will be provided (GH_TOKEN or gh auth), and require the skill to declare those env vars. 3) Fix the hard-coded path: update it to a configurable, relative path or prompt for the correct location. 4) Consider disabling autonomous invocation or require explicit approval before any commit/push. 5) Test in a sandbox repository first. If the author cannot justify the undeclared dependencies and the hard-coded filesystem access, treat the skill as untrusted.

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