openclaw-pr-maintainer
starsforks
How to install openclaw-pr-maintainer?
safeai-lab-x/clawkeeper/openclaw-pr-maintainer
$npx -y skills add SafeAI-Lab-X/ClawKeeper --skill openclaw-pr-maintainerMaintainer workflow for reviewing, triaging, preparing, closing, or landing OpenClaw pull requests and related issues. Use when Codex needs to validate bug-fix claims, search for related issues or PRs, apply or recommend close/reason labels, prepare GitHub comments safely, check
SKILL.md
| 1 | # OpenClaw PR Maintainer |
| 2 | |
| 3 | Use this skill for maintainer-facing GitHub workflow, not for ordinary code changes. |
| 4 | |
| 5 | ## Apply close and triage labels correctly |
| 6 | |
| 7 | - If an issue or PR matches an auto-close reason, apply the label and let `.github/workflows/auto-response.yml` handle the comment/close/lock flow. |
| 8 | - Do not manually close plus manually comment for these reasons. |
| 9 | - `r:*` labels can be used on both issues and PRs. |
| 10 | - Current reasons: |
| 11 | - `r: skill` |
| 12 | - `r: support` |
| 13 | - `r: no-ci-pr` |
| 14 | - `r: too-many-prs` |
| 15 | - `r: testflight` |
| 16 | - `r: third-party-extension` |
| 17 | - `r: moltbook` |
| 18 | - `r: spam` |
| 19 | - `invalid` |
| 20 | - `dirty` for PRs only |
| 21 | |
| 22 | ## Enforce the bug-fix evidence bar |
| 23 | |
| 24 | - Never merge a bug-fix PR based only on issue text, PR text, or AI rationale. |
| 25 | - Before landing, require: |
| 26 | 1. symptom evidence such as a repro, logs, or a failing test |
| 27 | 2. a verified root cause in code with file/line |
| 28 | 3. a fix that touches the implicated code path |
| 29 | 4. a regression test when feasible, or explicit manual verification plus a reason no test was added |
| 30 | - If the claim is unsubstantiated or likely wrong, request evidence or changes instead of merging. |
| 31 | - If the linked issue appears outdated or incorrect, correct triage first. Do not merge a speculative fix. |
| 32 | |
| 33 | ## Handle GitHub text safely |
| 34 | |
| 35 | - For issue comments and PR comments, use literal multiline strings or `-F - <<'EOF'` for real newlines. Never embed `\n`. |
| 36 | - Do not use `gh issue/pr comment -b "..."` when the body contains backticks or shell characters. Prefer a single-quoted heredoc. |
| 37 | - Do not wrap issue or PR refs like `#24643` in backticks when you want auto-linking. |
| 38 | - PR landing comments should include clickable full commit links for landed and source SHAs when present. |
| 39 | |
| 40 | ## Search broadly before deciding |
| 41 | |
| 42 | - Prefer targeted keyword search before proposing new work or closing something as duplicate. |
| 43 | - Use `--repo openclaw/openclaw` with `--match title,body` first. |
| 44 | - Add `--match comments` when triaging follow-up discussion. |
| 45 | - Do not stop at the first 500 results when the task requires a full search. |
| 46 | |
| 47 | Examples: |
| 48 | |
| 49 | ```bash |
| 50 | gh search prs --repo openclaw/openclaw --match title,body --limit 50 -- "auto-update" |
| 51 | gh search issues --repo openclaw/openclaw --match title,body --limit 50 -- "auto-update" |
| 52 | gh search issues --repo openclaw/openclaw --match title,body --limit 50 \ |
| 53 | --json number,title,state,url,updatedAt -- "auto update" \ |
| 54 | --jq '.[] | "\(.number) | \(.state) | \(.title) | \(.url)"' |
| 55 | ``` |
| 56 | |
| 57 | ## Follow PR review and landing hygiene |
| 58 | |
| 59 | - If bot review conversations exist on your PR, address them and resolve them yourself once fixed. |
| 60 | - Leave a review conversation unresolved only when reviewer or maintainer judgment is still needed. |
| 61 | - When landing or merging any PR, follow the global `/landpr` process. |
| 62 | - Use `scripts/committer "<msg>" <file...>` for scoped commits instead of manual `git add` and `git commit`. |
| 63 | - Keep commit messages concise and action-oriented. |
| 64 | - Group related changes; avoid bundling unrelated refactors. |
| 65 | - Use `.github/pull_request_template.md` for PR submissions and `.github/ISSUE_TEMPLATE/` for issues. |
| 66 | |
| 67 | ## Extra safety |
| 68 | |
| 69 | - If a close or reopen action would affect more than 5 PRs, ask for explicit confirmation with the exact count and target query first. |
| 70 | - `sync` means: if the tree is dirty, commit all changes with a sensible Conventional Commit message, then `git pull --rebase`, then `git push`. Stop if rebase conflicts cannot be resolved safely. |
People who liked this also viewed
6 picksType
- find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 2026
- grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026
- vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026
- setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026
- triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026
