clawhub-pr-maintainer

name	clawhub-pr-maintainer
description	Use when reviewing, triaging, validating, or discussing ClawHub GitHub issues or pull requests, including author context, CI, UI proof, evidence, labels, close decisions, and maintainer handoff.

ClawHub PR Maintainer

Use this skill for maintainer-facing ClawHub GitHub workflow, not for ordinary implementation work.

Start With Live GitHub State

• Use gh pr view or gh issue view against openclaw/clawhub; verify live state before commenting, labeling, closing, or recommending merge.
• For PRs, read title, body, author, labels, comments, files, commits, status checks, review state, and linked issues.
• Surface author identity briefly: GitHub name/login and account age when useful. Treat identity as triage signal, never as proof by itself.

Common read-only commands:

gh pr view <number> --repo openclaw/clawhub --json title,body,author,labels,comments,files,commits,statusCheckRollup,reviewDecision,url
gh issue view <number> --repo openclaw/clawhub --json title,body,author,labels,comments,state,url
gh api users/<login> --jq '{login,name,created_at,type}'

Review Evidence Bar

• For bug fixes, require symptom evidence, a plausible root cause in the touched code path, and either a regression test or focused manual proof.
• For UI changes, require screenshots or video when the behavior is meaningfully visual. Use tests as supplemental evidence, not a substitute for visible proof.
• Do not merge or recommend merge based only on PR prose, AI rationale, or green CI when the changed behavior has not been exercised.
• For contributor-provided screenshots/videos/logs, inspect the artifact directly and state what it proves. Do not rerun proof:ui just to inspect existing evidence.

Decide UI Proof Mode

Use the clawhub-ui-proof skill when the maintainer/agent should generate new visual evidence.

• before-after: bug fixes, regressions, changed copy, changed layout, or any PR where main-vs-candidate comparison clarifies the change.
• feature: new page, new flow, new UI state, or behavior that cannot exist on origin/main.
• No generated proof: docs-only, backend-only, tests-only, metadata-only, or already-sufficient contributor evidence.

Write a temporary Playwright scenario under .artifacts/proof-scenarios/; do not infer manual clicks. Keep screenshots and videos in .artifacts/ until publishing. Never commit proof artifacts.

Final Review Comment With Proof

If this review generated proof:ui artifacts, publish them before the final PR review comment. Do not leave only local .artifacts/... paths in a PR comment; they are useful to the maintainer locally but invisible to GitHub readers.

Use:

bun run proof:publish -- --proof-dir .artifacts/clawhub-ui-proof/<timestamp> --target-pr <number>

proof:publish copies the selected files to the qa-artifacts branch and upserts a marker-backed PR comment with a ClawHub UI Proof section.

That comment includes:

• the proof mode (before-after or feature)
• the report.md result summary
• the most relevant per-step screenshots
• inline video previews when GIF previews are present
• links to full-run MP4s
• links to raw proof files on the artifact branch

Use --dry-run before publishing if you need to inspect the generated comment. If publishing fails because credentials are missing, report the local proof directory and the failed command instead of posting a comment that claims evidence is attached.

ClawSweeper

ClawSweeper is the bot control plane for automated PR/issue review once ClawHub dispatch is configured. Until then, use this skill for manual maintainer review. If ClawSweeper has posted a review, read it as evidence but verify live PR state before acting.

Commenting And Labels

• Use literal multiline comment bodies or --body-file; never pass escaped \n strings.
• Keep maintainer comments short: finding, evidence, requested action, and verification path.
• When no proof artifacts were generated, gh pr comment --body-file is fine. When proof artifacts were generated, use proof:publish so screenshots/videos are published before posting.
• Do not close more than five issues/PRs in one action without explicit confirmation and the exact target list.