OpenClaw PR Maintainer

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

Start issue and PR triage with gitcrawl

• Use $gitcrawl first anytime you inspect OpenClaw issues or PRs.
• Check local gitcrawl data first for related threads, duplicate attempts, and already-landed fixes.
• Use gitcrawl for candidate discovery and clustering; use gh, gh api, and the current checkout to verify live state before commenting, labeling, closing, or landing.
• If gitcrawl is missing, stale, lacks the target thread, or has no embeddings for neighbor/search commands, fall back to the GitHub search workflow below.
• Do not run expensive/update commands such as gitcrawl sync --include-comments, future enrichment commands, or broad reclustering unless the user asked to update the local store or stale data is blocking the decision.

Common read-only path:

gitcrawl threads openclaw/openclaw --numbers <issue-or-pr-number> --include-closed --json
gitcrawl neighbors openclaw/openclaw --number <issue-or-pr-number> --limit 12 --json
gitcrawl search openclaw/openclaw --query "<scope or title keywords>" --mode hybrid --json
gitcrawl cluster-detail openclaw/openclaw --id <cluster-id> --member-limit 20 --body-chars 280 --json

Claim specific review targets

When a maintainer asks Codex to review, triage, fix, or land a specific OpenClaw issue/PR, check assignment before deep work.

• Identify the requesting maintainer's GitHub login. In this environment, default Peter to steipete; if another maintainer is clearly the requester, use that maintainer's bare login.
• Read current assignees with live gh issue view / gh pr view; gitcrawl is not enough for assignment state.
• If unassigned, assign the requester before deep review. This is allowed for specific requested targets; do not auto-assign broad discovery candidates or shortlists.
• If assigned to someone else, say so clearly before analysis and include assignment age:
  • fresh: assigned within 6h; treat as actively owned unless user explicitly asks to continue or reassign
  • stale: assigned 6h+ ago; treat as ownership hint, not a hard block; continue only with that caveat
• If assigned to requester plus others, mention co-assignees and continue.
• If assignment event time is unavailable, say assigned, time unknown; treat as assigned, not stale.
• Never remove or replace assignees unless explicitly asked.

Assignment time proof:

gh api "repos/openclaw/openclaw/issues/<number>/timeline" --paginate \
  -H "Accept: application/vnd.github+json" \
  --jq '[.[] | select(.event=="assigned") | {assignee:.assignee.login, assigner:.assigner.login, actor:.actor.login, created_at}]'

Use the newest assigned event for each current assignee. Issue timeline events expose created_at; GitHub GraphQL AssignedEvent.createdAt is also valid when REST pagination is awkward.

Claim command for issues or PRs:

gh api -X POST "repos/openclaw/openclaw/issues/<number>/assignees" -f 'assignees[]=<login>' >/dev/null

Surface opener identity

• For every reviewed, triaged, closed, or landed issue/PR, show the opener's human name when available, GitHub login, and account age.
• Get the login from gh issue view / gh pr view (author.login), then fetch profile metadata once with gh api users/<login> --jq '{login,name,created_at,type}'.
• Report opener identity as one compact line: By: Jane Doe (@jane, acct 2021-04-03) | OpenClaw: 4 PRs, 2 issues, 11 commits/12mo | GitHub: 9 repos, 86 commits, 9 PRs, 3 issues, 12 reviews
• Always show recent activity in two lanes: OpenClaw-local PRs, issues, and commits in the last 12 months; and general public GitHub activity over the same window. For linked issue-fixing PRs, include both the PR author and issue opener when they differ.
• Prefer the bundled helper for activity lookups:

…