openclaw-pr-maintainer

Reviews, triages, and lands OpenClaw pull requests using GitHub CLI workflows.

Updated Mar 30, 2026
One-click install
npx skills add https://github.com/srgaba/open-claw --skill openclaw-pr-maintainer-srgaba
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: openclaw-pr-maintainer
Source: https://github.com/srgaba/open-claw/tree/main/project/.agents/skills/openclaw-pr-maintainer
Command: npx skills add https://github.com/srgaba/open-claw --skill openclaw-pr-maintainer-srgaba

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Maintaining a busy open-source repository requires consistent triage, evidence-based bug-fix review, and safe GitHub comment handling, which is error-prone when done ad hoc. This Skill encodes the maintainer decision workflow so PRs and issues are labeled, verified, and landed correctly. ## Core Features & Use Cases - Label-driven triage: Apply r:* close-reason labels (e.g., r: spam, r: support, invalid, dirty) and let the auto-response workflow handle comment, close, and lock actions. - Bug-fix evidence bar: Require symptom evidence, a verified root cause with file/line, a fix touching the implicated code path, and a regression test or documented manual verification before merging. - Safe GitHub commenting and search: Use single-quoted heredocs for multiline comments, avoid backtick-wrapping issue refs, and run broad gh search queries with --match title,body before closing as duplicate. - Use Case: A maintainer receives a bug-fix PR claiming to resolve an issue. Use this Skill to verify the repro evidence and root cause, search for duplicate issues, request changes if unsubstantiated, and land the PR following the /landpr process. ## Quick Start Review pull request 1234 in the openclaw/openclaw repository, verify its bug-fix evidence, and either request changes or prepare it for landing.

Frequently Asked Questions about openclaw-pr-maintainer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a bug-fix pull request before merging?

Verify four things before merging: symptom evidence such as a repro or failing test, a confirmed root cause with file and line, a fix touching the implicated code path, and a regression test or documented manual verification. If any are missing, request changes instead of merging.

How do I search GitHub issues and PRs with the gh CLI?

Use gh search issues or gh search prs with --repo, --match title,body, and a --limit flag. Add --match comments when triaging follow-up discussion, and use --json with --jq to format number, state, title, and URL output.

How do I post multiline GitHub comments safely with gh?

Use a single-quoted heredoc such as gh issue comment -F - <<'EOF' so real newlines and backticks are preserved. Avoid -b with embedded \n or shell-special characters, and do not wrap issue refs like #123 in backticks if you want auto-linking.

When should I apply close-reason labels instead of closing manually?

Apply labels like r: spam, r: support, invalid, or dirty when an issue or PR matches an auto-close reason, and let the auto-response workflow handle commenting, closing, and locking. Manual close plus manual comment duplicates that automation.

What precautions apply when closing or reopening many PRs at once?

If a close or reopen action would affect more than 5 PRs, ask for explicit confirmation first, stating the exact count and the target query. This prevents accidental bulk state changes across the repository.