description: Use immediately for any pasted OpenClaw GitHub issue or PR URL/number, and for OpenClaw issue/PR review, triage, duplicate search, opener identity/who wrote it, author account age/activity, comments, labels, close, land, or maintainer evidence checks.

- 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:

.agents/skills/openclaw-pr-maintainer/scripts/github-activity.sh <login> [other-login...]

.agents/skills/openclaw-pr-maintainer/scripts/github-activity.sh --global <login>

- The helper reports repo-local activity first and can fetch public GitHub contribution totals for the same window with `--global`; run the global form by default for review/triage identity summaries.

- If the global contribution graph reports zero or looks inconsistent with visible public activity, sanity-check with `gh api users/<login>`, `gh api 'users/<login>/events/public?per_page=100'`, and recent public repo commits before calling the account inactive.

- The helper is intentionally cache-friendly for gitcrawl-backed `gh`: it rounds repo-local windows to the UTC day, rounds global contribution windows to the UTC hour, and counts PRs/issues from one paginated issues response before fetching commits separately. Prefer reusing the helper instead of hand-rolling several `gh api` loops.

- If the contribution graph is misleading or zero but public events/repos show activity, keep it one line, for example:

`By: pickaxe (@ProspectOre, acct 2019-08-24) | OpenClaw: 5 PRs, 0 issues, 5 commits/12mo | GitHub: 5 repos, 29 recent events, 100 public own-repo commits; graph=0`

- If `name` is empty, use the login only. If profile lookup is rate-limited or unavailable, say `account age unknown` rather than omitting the opener.

- Use identity and activity as triage signal, not proof by itself: new, low-activity, or bot-like accounts can raise review caution, but code, repro, and CI evidence still decide.

When asked for issue triage, hot issues, pressing bugs, Discord-correlated issues, or "what is still open", do not surface issues or PRs authored by top maintainers by default. Prefer external/user-reported hot issues and external PRs, not maintainer-owned work queues.

Suppress by default when the opener/author is one of:

- `@vincentkoc`

- `@Takhoffman`

- `@gumadeiras`

- `@obviyus`

- `@shakkernerd`

- `@mbelinky`

- `@joshavant`

- `@ngutman`

- `@vignesh07`

- `@huntharo`

Also suppress lower-priority maintainer-owned noise from the broader keep/top-maintainer group unless it is directly relevant:

- `@thewilloftheshadow`

- `@onutc` / `@osolmaz`

- `@jacobtomlinson`

- `@tyler6204`

- `@velvet-shark`

- `@jalehman`

- `@frankekn`

- `@ImLukeF`

- `@mcaxtr`

Exceptions:

- Show maintainer-authored items when the requester explicitly asks for maintainer PRs/issues, PR landing candidates, release-blocking maintainer work, or a specific PR/issue number.

- Show a maintainer-authored item when it is the canonical fix for an external hot issue, but frame it as the fix path rather than as a user-facing issue candidate.

- Do not close, label, or deprioritize solely because an item is maintainer-authored; this section only controls what appears in triage shortlists.

Issue triage is review/prove/patch-local by default:

1. Review the issue body, comments, related threads, current code, and adjacent tests.

2. Fix only issues that are easy, high-confidence, and narrowly owned by the implicated path.

3. Add focused regression proof when practical.

4. Stop with the dirty diff, touched files, and test/gate output for maintainer review.

5. After maintainer approval to ship, make one commit per accepted fix, with its own changelog entry when user-facing.

6. Pull/rebase, push, then comment and close only the issues that were fixed or explicitly triaged closed.

Do not batch unrelated issue fixes into one commit. Do not publish, comment, close, or label during the review/prove phase.

Missing changelog is not a PR review finding or merge blocker. If landing/fixing a user-visible change, add/update changelog automatically when practical; never ask or block solely on it.

- Start every PR review with 1-3 plain sentences explaining what the change does and why it matters. Put this before `Findings`.

- Then list findings first. If none, say `No blocking findings` or `No findings`.

- Always answer: bug/behavior being fixed, PR/issue URL and affected surface, and best-fix verdict.

- Keep summaries compact, but include enough proof that the verdict is auditable without rereading the PR.

- Review the surrounding code path, not just changed lines. Open the caller, callee, data contracts, adjacent tests, and owner module.

- For large-codebase PRs, sample enough related files to understand the runtime boundary before deciding. Default to more code reading when the change touches agents, gateway, plugins, auth, sessions, process, config, or provider/runtime seams.

- Compare the PR against current `origin/main` behavior. Check whether recent main already changed the same surface.

- Dependency-backed behavior: MUST read upstream docs/source/types before judging API use, defaults, output shapes, errors, timeouts, memory behavior, or compatibility. Do not assume dependency contracts from memory or PR text.

- Judge solution quality, not only correctness. Ask whether the PR is the clean owner-boundary fix or a wart/workaround that should be replaced by a small refactor, moved seam, contract change, or deletion of duplicate logic.

- Mention the main files read when the verdict depends on code-path evidence.

- Whenever feasible, use Crabbox (`$crabbox`) for end-to-end verification before

commenting that a bug is unreproducible, closing an issue, or opening/landing

a fix PR. Prefer a real packaged/Docker/live lane that exercises the reported

user flow over unit-only proof.

- If Crabbox/E2E proof is blocked, say exactly why and use the closest available

local, Docker, mocked, or targeted proof. Do not present unit tests as real

behavior proof.

- Never mention merge conflicts that are relatively easy to resolve, such as

`CHANGELOG.md` entries, in review-only output. These are landing mechanics,

not correctness findings.