agentleFS
Sign inStart free
AtomicBot-aiAtomicBot-ai/atomicbot/.agents/skills/openclaw-pr-maintainer/SKILL.md

openclaw-pr-maintainer

Skill325 starsChanged 7 months agoMITView on GitHub

Maintainer 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 review-thread follow-up, or perform maintainer-style PR decision making before merge or closure.

  • Commits and pushes

We split this skill into the rules it gives an agent

19 rules. 0 are common, 11 are distinctive, and 8 are very specific to this project.

  • 0

    Common

    Most of the 12 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Use this skill for maintainer-facing GitHub workflow, not for ordinary code changes.

    line 8
  2. Very specific:

    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 …

    line 12
  3. Distinctive:

    Do not manually close plus manually comment for these reasons.

    line 13
  4. Distinctive:

    Never merge a bug-fix PR based only on issue text, PR text, or AI rationale.

    line 29
  5. Distinctive:

    If the claim is unsubstantiated or likely wrong, request evidence or changes instead of merging.

    line 35
  6. Distinctive:

    If the linked issue appears outdated or incorrect, correct triage first.

    line 36
  7. Very specific:

    Do not use gh issue/pr comment -b "..." when the body contains backticks or shell characters.

    line 41
  8. Very specific:

    Do not wrap issue or PR refs like #24643 in backticks when you want auto-linking.

    line 42
  9. Distinctive:

    Prefer targeted keyword search before proposing new work or closing something as duplicate.

    line 47
  10. Very specific:

    Use --repo openclaw/openclaw with --match title,body first.

    line 48
  11. Very specific:

    Add --match comments when triaging follow-up discussion.

    line 49
  12. Distinctive:

    Do not stop at the first 500 results when the task requires a full search.

    line 50
  13. Distinctive:

    If bot review conversations exist on your PR, address them and resolve them yourself once fixed.

    line 64
  14. Distinctive:

    Leave a review conversation unresolved only when reviewer or maintainer judgment is still needed.

    line 65
  15. Very specific:

    When landing or merging any PR, follow the global /landpr process.

    line 66
  16. Very specific:

    Use scripts/committer "<msg>" <file...> for scoped commits instead of manual git add and git commit.

    line 67
  17. Distinctive:

    Keep commit messages concise and action-oriented.

    line 68
  18. Very specific:

    Use .github/pull_request_template.md for PR submissions and .github/ISSUE_TEMPLATE/ for issues.

    line 70
  19. Distinctive:

    If a close or reopen action would affect more than 5 PRs, ask for explicit confirmation with the exact count and target query first.

    line 74

“Common” is measured: kept by at least 6 in 10 of the 12 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

OpenClaw PR Maintainer

Use this skill for maintainer-facing GitHub workflow, not for ordinary code changes.

Apply close and triage labels correctly

  • 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.
  • Do not manually close plus manually comment for these reasons.
  • r:* labels can be used on both issues and PRs.
  • Current reasons:
    • r: skill
    • r: support
    • r: no-ci-pr
    • r: too-many-prs
    • r: testflight
    • r: third-party-extension
    • r: moltbook
    • r: spam
    • invalid
    • dirty for PRs only

Enforce the bug-fix evidence bar

  • Never merge a bug-fix PR based only on issue text, PR text, or AI rationale.
  • Before landing, require:
    1. symptom evidence such as a repro, logs, or a failing test
    2. a verified root cause in code with file/line
    3. a fix that touches the implicated code path
    4. a regression test when feasible, or explicit manual verification plus a reason no test was added
  • If the claim is unsubstantiated or likely wrong, request evidence or changes instead of merging.
  • If the linked issue appears outdated or incorrect, correct triage first. Do not merge a speculative fix.

Handle GitHub text safely

  • For issue comments and PR comments, use literal multiline strings or -F - <<'EOF' for real newlines. Never embed \n.
  • Do not use gh issue/pr comment -b "..." when the body contains backticks or shell characters. Prefer a single-quoted heredoc.
  • Do not wrap issue or PR refs like #24643 in backticks when you want auto-linking.
  • PR landing comments should include clickable full commit links for landed and source SHAs when present.

Search broadly before deciding

  • Prefer targeted keyword search before proposing new work or closing something as duplicate.
  • Use --repo openclaw/openclaw with --match title,body first.
  • Add --match comments when triaging follow-up discussion.
  • Do not stop at the first 500 results when the task requires a full search.

Examples:

gh search prs --repo openclaw/openclaw --match title,body --limit 50 -- "auto-update"
gh search issues --repo openclaw/openclaw --match title,body --limit 50 -- "auto-update"
gh search issues --repo openclaw/openclaw --match title,body --limit 50 \
  --json number,title,state,url,updatedAt -- "auto update" \
  --jq '.[] | "\(.number) | \(.state) | \(.title) | \(.url)"'

Follow PR review and landing hygiene

  • If bot review conversations exist on your PR, address them and resolve them yourself once fixed.
  • Leave a review conversation unresolved only when reviewer or maintainer judgment is still needed.
  • When landing or merging any PR, follow the global /landpr process.
  • Use scripts/committer "<msg>" <file...> for scoped commits instead of manual git add and git commit.
  • Keep commit messages concise and action-oriented.
  • Group related changes; avoid bundling unrelated refactors.
  • Use .github/pull_request_template.md for PR submissions and .github/ISSUE_TEMPLATE/ for issues.

Extra safety

  • If a close or reopen action would affect more than 5 PRs, ask for explicit confirmation with the exact count and target query first.
  • 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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free