Marketingclaw Pr Maintainer

MarketingClaw 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 MarketingClaw 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 promisingcoder/marketingclaw --numbers <issue-or-pr-number> --include-closed --json
gitcrawl neighbors promisingcoder/marketingclaw --number <issue-or-pr-number> --limit 12 --json
gitcrawl search promisingcoder/marketingclaw --query "<scope or title keywords>" --mode hybrid --json
gitcrawl cluster-detail promisingcoder/marketingclaw --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 MarketingClaw 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/promisingcoder/marketingclaw/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/promisingcoder/marketingclaw/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) | MarketingClaw: 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: MarketingClaw-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/marketingclaw-pr-maintainer/scripts/github-activity.sh <login> [other-login...]
.agents/skills/marketingclaw-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) | MarketingClaw: 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.

Suppress recent wide-access maintainer PRs in triage

In generic issue/PR triage, hot queues, landable shortlists, or "what is still open", exclude PRs authored by maintainers with broad repository access until 14 days after created_at. Prefer external contributors' PRs. An ordinary request for landing candidates does not override the age gate. Continue suppressing maintainer-authored issues by default.

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:

• Once a maintainer-authored PR is at least 14 days old, triage it normally.
• A specific PR/issue number or an explicit request for maintainer-owned work overrides suppression.
• When a recent maintainer PR is the canonical fix for an external hot issue, mention it only as the fix path; do not count it as a triage or landing candidate.
• Do not close, label, or deprioritize solely because an item is maintainer-authored; this section only controls what appears in triage shortlists.

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.
• If an issue/PR is already fixed on current main or solved by a new release, comment with proof plus the canonical commit/PR/release, then close it.
• 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

Select small high-confidence triage candidates

When asked for X issues or PRs to triage, X means qualified candidates, not sampled threads.

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 release-note context in the PR body or commit message 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.md is not a PR review finding or merge blocker. If landing/fixing a user-visible change, make sure the PR body or commit message captures the release-note context; never ask or block solely on it.

Only list candidates that pass all gates:

• small owner/surface, with a likely narrow fix and focused regression test
• symptom is reproducible or provable with logs, failing test, live command, dependency contract, or current-main behavior
• root cause is traceable to code with file/line and the proposed fix touches that path
• no strong smell that a broader refactor, ownership rethink, migration, or product decision is the better fix
• dependency-backed behavior checked against upstream docs/source/types; live or web proof used when local proof is insufficient

Loop:

1. Use gitcrawl / gh to gather candidate clusters.
2. Read issue/PR body, comments, current code, adjacent tests, and dependency contracts.
3. Try focused repro or proof.
4. Reject unclear, stale, speculative, broad-refactor, or owner-ambiguous items.
5. Continue until X qualified candidates or the bounded search is exhausted.

Output only qualifying candidates, with: ref, surface, proof, cause, fix sketch, why small, expected test/gate. If none qualify, say so; do not pad.

Structure PR review output

• 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.
• Show size near the top as LOC: +<additions>/-<deletions> (<changedFiles> files), using live PR stats or local diff stats.
• Always answer: bug/behavior being fixed, PR/issue URL and affected surface, provenance for regressions when traceable, and best-fix verdict.
• For bug/regression fixes, include a compact Provenance: line after cause/root-cause when a bounded history pass can identify it. Use git log -S/-G, git blame, linked PRs/issues, and tests.
• Provenance must separate roles when they differ: blamed code author username, blamed PR author username, blamed PR merger/committer username, automerge trigger when known, current PR author username, PR number, and date. Do not collapse them into one "introduced by" actor.
• If the blamed PR was merged by clawsweeper[bot] or another automation, identify the human trigger when practical. Check live PR timeline/comments first; if rate-limited, use gitcrawl/cache or public PR HTML. Look for maintainer command comments such as @clawsweeper automerge, /landpr, labels/events that armed automerge, and ClawSweeper status comments. Report automerge triggered by @login; if not found, say trigger unknown rather than naming the bot as the human decision-maker.
• For any confirmed bug, run git blame on the implicated line(s) after identifying the root cause. Report who broke it as the blamed PR merger/committer, and also name the blamed code author. Include the PR number. If no PR is traceable, use the blamed commit as the provenance: commit SHA, date, and author username. Do not guess a merger or frame missing PR metadata as a separate finding.
• Phrase provenance as introduced by, made visible by, or carried forward by, with confidence (clear, likely, unknown). If unclear, say what evidence is missing instead of guessing. For features, docs, and refactors, use Provenance: N/A or omit it when no broken behavior is being fixed.
• Keep summaries compact, but include enough proof that the verdict is auditable without rereading the PR.

LOC proof:

gh pr view <number> --json additions,deletions,changedFiles \
  --jq '"LOC: +\(.additions)/-\(.deletions) (\(.changedFiles) files)"'

Read beyond the diff

• Review the surrounding code path, not just changed lines. Open the caller, callee, data contracts, adjacent tests, and owner module.
• Before any verdict, read enough code to fill this map: changed surface, runtime entry point, owner boundary, one caller, one callee, sibling implementations sharing the invariant, adjacent tests, current main behavior, and shipped/dependency/Codex contracts when relevant.
• 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.
• If the user challenges the verdict or asks whether the idea is really good, resume code reading first. Do not defend, soften, or reverse the verdict until the missing caller/callee/sibling/dependency path is checked.

Best-fix review loop

Every PR review must explicitly answer: "Is this the best fix, or only a plausible fix?"

Before verdict:

1. Reconstruct the bug, feature need, or behavior claim from issue/PR/proof.
2. Trace current behavior from entry point to failure or decision point.
3. Read touched files, callers, callees, owner modules, adjacent tests, and relevant docs.
4. Read sibling surfaces that should share the invariant or could be broken by a one-sided fix.
5. Compare against current origin/main and shipped behavior when regression/compat matters.
6. Inspect upstream dependency/Codex source or docs for dependency-backed behavior.
7. Identify at least one alternative fix location or shape, then reject it with evidence.
8. If any required path above is uninspected, keep reading or mark Remaining uncertainty; do not call the PR best, blocked, proof-sufficient, or merge-ready.

Review output must include:

• Best-fix verdict: best / acceptable mitigation / wrong layer / too narrow / too broad.
• Alternatives considered: 1-3 concrete alternatives and why rejected.
• Code read: compact list of main files/contracts checked.
• Remaining uncertainty: what was not proven.

If the best-fix answer is only "maybe", keep reading or state the missing evidence. Do not call proof sufficient until the best-fix judgment is explicit.

Enforce the bug-fix evidence bar

• Never merge a bug-fix PR based only on issue text, PR text, or AI rationale.
• 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.
• 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. blame-backed provenance for regressions when traceable, including blamed PR merger and automerge trigger when known, or commit SHA/date when no PR is traceable
  4. a fix that touches the implicated code path
  5. 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.
• 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.

Close low-signal manual PRs carefully

• Do not close for red CI alone. Require a clear low-signal category plus stale or failed validation.
• Good manual-close categories:
  • blank or mostly untouched PR template with no concrete MarketingClaw problem/fix
  • random docs-only churn such as root README translations, generic wording tweaks, or community-plugin discoverability docs that should go through ClawHub
  • test-only coverage without a linked bug, owner request, or behavior change
  • refactor-only cleanup, variable renames, formatting, or generated/baseline churn without maintainer request
  • third-party channel/provider/tool/skill/plugin work that belongs on ClawHub instead of core
  • risky ops/infra drive-bys such as new external CI services, release workflows, host upgrade scripts, Docker base migrations, or apt retry/fix-missing tweaks without owner request and green validation
  • dirty branches where a narrow stated change includes unrelated docs/generated/runtime/extension files
  • repeated bot-review spam or copied bot output without author-owned fixes
• Keep or escalate plausible focused bug fixes, green PRs, active maintainer discussions, assigned work, recent author follow-up, and unique reproduction details.
• For third-party capabilities, prefer the r: third-party-extension auto-response label when it applies; it points contributors to publish on ClawHub.

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 gitcrawl first. Then use targeted GitHub keyword search to verify gaps, live status, comments, and candidates not present in the local store.
• Use --repo promisingcoder/marketingclaw with --match title,body first when using gh search.
• Add --match comments when triaging follow-up discussion or closed-as-duplicate chains.
• Do not stop at the first 500 results when the task requires a full search.

Examples:

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

Follow PR review and landing hygiene

• At the start of code-changing or landing work that will need tests or heavy proof, classify source trust and pre-warm the safe backend through $crabbox in the background. Trusted maintainer code defaults to Blacksmith Testbox; contributor/fork code stays untrusted unless a maintainer explicitly approves credentialed execution after review; it uses secretless fork CI or sanitized direct AWS Crabbox with CRABBOX_ENV_ALLOW=CI, --no-hydrate, and a fresh temporary remote HOME, never the credential-hydrated Testbox workflow or a previously hydrated lease. Launch an installed trusted Crabbox binary from clean trusted main, fetch the PR with --fresh-pr, unset and reject any resolved AWS instance profile, verify trusted IMDS reports no IAM credentials, bind the lease to the reviewed head SHA, and never execute its local wrapper or config. Upload trusted scripts/crabbox-untrusted-bootstrap.sh from clean main alongside --fresh-pr; it installs the pinned Node/pnpm runtime before executing PR code. Force public networking, disable and unset inherited Tailscale/exit-node settings, and fail closed unless crabbox inspect reports no Tailscale state before any script. Rewarm after any head change. Continue review/editing while it hydrates, sync every run, reuse the lease, then stop it before handoff. Skip warmup for read-only triage and docs-only work.
• Never mention release-note bookkeeping in review-only output. It is landing or release-generation mechanics, not a correctness finding.
• 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.
• Before landing any PR with non-trivial code changes, run $autoreview until no accepted/actionable findings remain, unless equivalent manual review already covered it, the change is trivial/docs-only, or the user opts out.
• When an agent is landing or merging a PR targeting main, use only the repo-native scripts/pr wrapper: run scripts/pr review-init <PR>, follow its emitted checkout/guard guidance, initialize and complete review artifacts with scripts/pr review-artifacts-init <PR>, validate them with scripts/pr review-validate-artifacts <PR>, then run MARKETINGCLAW_TESTBOX=1 scripts/pr prepare-run <PR> and scripts/pr merge-run <PR>. The Testbox flag is mandatory for agents: it verifies exact-head hosted CI/Testbox instead of running full pnpm gates locally.
• 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.
• Do not commit PR-only artifacts such as screenshots under .github/pr-assets; attach them to the PR/comment or use an external artifact store instead.

Extra safety

• If a close or reopen action would affect more than 20 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.