chore: add maintainer setup baseline

[vincentkoc]

Summary

• add maintainer setup baseline files for this repository\n- add Crabbox/autoreview skills, Crabbox hydrate CI, stale automation, and CODEOWNERS coverage for new setup surfaces

Verification

• git diff --check
• ruby YAML.load_file for added/changed YAML files
• actionlint for added/changed workflow files
• private-data scan for added/changed non-skill setup files
• verified Crabbox skill SHA-256 matches openclaw/openclaw: ed512c0b0385fae7f6c5c14a7e9e6236ab68936506687a99ca976873492bdc43

Runtime tests were not run; this is setup, policy, and workflow metadata only.

[clawsweeper]

Codex review: needs maintainer review before merge.

Latest ClawSweeper review: 2026-05-22 15:05 UTC / May 22, 2026, 11:05 AM ET.

Workflow note: Future ClawSweeper reviews update this same comment in place.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Summary
This PR adds repository-local autoreview and Crabbox skills, a Crabbox config and hydrate workflow, stale automation, actionlint runner labels, and CODEOWNERS coverage for the new setup files.

Reproducibility: not applicable. this is a repository setup/admin PR, not a product bug. Source inspection covered the workflow and setup files rather than a runtime reproduction path.

PR rating
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
Patch quality: 🐚 platinum hermit
Summary: The patch looks mechanically coherent from source inspection, with merge readiness limited by maintainer policy acceptance rather than an actionable code defect.

Rank-up moves:

• Record the maintainer decision on stale automation windows and the copied-versus-shared skill strategy before merge.

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Real behavior proof
Not applicable: The PR is member-authored setup/policy metadata, so the external-contributor real behavior proof gate does not apply.

Risk before merge

• The stale workflow can automatically label and close existing issues and pull requests on the configured windows, so merging it changes repository operations immediately.
• The PR adds scheduled and workflow_dispatch automation with write permissions for stale handling and self-hosted Crabbox hydrate behavior, which needs explicit maintainer acceptance rather than cleanup automation.
• A maintainer already raised a product/process concern about copying shared agent scripts into each repository versus using a shared checkout, symlink, or shared OpenClaw location.

Maintainer options:

1. Require explicit setup-policy approval (recommended)
   Merge only after maintainers confirm the stale windows, copied skill strategy, write-scoped stale workflow, and Crabbox hydrate adoption are intended for this repository.
2. Split policy from mechanical baseline
   If maintainers want lower review risk, split CODEOWNERS/actionlint/Crabbox config from stale automation and shared-skill distribution into separate PRs.
3. Close and recreate from a policy decision
   If the copied local skill baseline is not the desired direction, close this draft and replace it with the shared-agent-scripts or shared OpenClaw setup path once chosen.

Next step before merge
This is a draft member PR with an explicit maintainer policy disagreement, so the next step is human maintainer decision rather than automated repair.

Security
Cleared: No concrete secret exposure or unsafe supply-chain behavior was found in the diff; the write-scoped stale workflow and unpinned action refs remain maintainer automation policy choices.

Review details

Best possible solution:

Keep the PR open only as a draft policy discussion until maintainers explicitly decide whether this repository should adopt local copied skills, stale automation, and the Crabbox hydrate workflow.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a repository setup/admin PR, not a product bug. Source inspection covered the workflow and setup files rather than a runtime reproduction path.

Is this the best way to solve the issue?

Unclear: the setup files are coherent after the fixups, but the maintainer discussion shows the unresolved question is whether copied per-repo skills and stale automation are the desired policy path.

Label changes:

• add P2: This is repository automation setup with limited product-runtime blast radius but meaningful maintainer workflow impact.
• add merge-risk: 🚨 automation: The PR adds scheduled stale automation and workflow_dispatch Crabbox hydration that can change issue/PR state or validation behavior after merge.

Label justifications:

• P2: This is repository automation setup with limited product-runtime blast radius but meaningful maintainer workflow impact.
• merge-risk: 🚨 automation: The PR adds scheduled stale automation and workflow_dispatch Crabbox hydration that can change issue/PR state or validation behavior after merge.
• rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🌊 off-meta tidepool, patch quality is 🐚 platinum hermit, and The patch looks mechanically coherent from source inspection, with merge readiness limited by maintainer policy acceptance rather than an actionable code defect.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The PR is member-authored setup/policy metadata, so the external-contributor real behavior proof gate does not apply.

What I checked:

• PR metadata requires human handling: The provided GitHub context shows the PR author association is MEMBER, the PR is draft, and a maintainer comment on 2026-05-22 closed the draft for policy reasons before it was reopened the same day. (d2f10ee0129d)
• Current main lacks the proposed setup files: Current main only has existing .github automation/CODEOWNERS surfaces; .agents skills, .crabbox.yaml, actionlint config, crabbox-hydrate.yml, and stale.yml are not present on main. (a0080cf775ad)
• PR diff surface: The PR branch adds 1,824 lines across eight setup files: autoreview skill/script, crabbox skill/config, actionlint config, crabbox hydrate workflow, stale workflow, and CODEOWNERS updates. (d2f10ee0129d)
• Stale automation policy surface: The added stale workflow grants issues and pull-requests write permissions and configures automatic stale labeling and closure windows for issues and PRs. (.github/workflows/stale.yml:12, d2f10ee0129d)
• Crabbox hydrate workflow surface: The added hydrate workflow is manually dispatched, targets self-hosted Crabbox labels, installs dependencies, writes ready-marker state under the runner home, and keeps the job alive for the requested window. (.github/workflows/crabbox-hydrate.yml:35, d2f10ee0129d)
• Current CODEOWNERS baseline: Main already protects workflows, package integrity, provider execution, mapper, and security docs through @openclaw/openclaw-secops; the PR extends that coverage to the new hidden setup surfaces. (.github/CODEOWNERS:1, a0080cf775ad)

Likely related people:

• Peter Steinberger: Authored four of the five PR branch commits after the initial baseline, including Crabbox hydration hardening, maintainer validation flag handling, and stale label bootstrap; also appears in current-main history for repository automation and CODEOWNERS surfaces. (role: recent setup and automation contributor; confidence: high; commits: 7e468257601c, 1b0b0026a22d, c32faf49596d; files: .agents/skills/autoreview/SKILL.md, .agents/skills/autoreview/scripts/autoreview, .github/workflows/crabbox-hydrate.yml)
• Vincent Koc: Authored the first PR branch commit and has recent merged history in this repository, including operating-loop and PR workflow work; the GitHub context also marks the author as MEMBER. (role: initial setup baseline author and current-main contributor; confidence: medium; commits: f861f64beeb7, 398b752ad25b, 4eb9a55d8f70; files: .agents/skills/autoreview/SKILL.md, .agents/skills/crabbox/SKILL.md, .crabbox.yaml)

Codex review notes: model gpt-5.5, reasoning high; reviewed against a0080cf775ad.

[clawsweeper]

ClawSweeper PR egg

✨ Hatched: 🌱 uncommon Tiny Clawlet

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

• Merged PRs are hatchable.
• Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
• Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

Rarity: 🌱 uncommon.
Trait: guards the happy path.
Image traits: location CI tidepool; accessory tiny test log scroll; palette coral, mint, and warm cream; mood determined; pose waving from a small platform; shell frosted glass shell; lighting cool dashboard glow; background little resolved-comment flags.
Share on X: post this hatch
Copy: My PR egg hatched a 🌱 uncommon Tiny Clawlet in ClawSweeper.

What is this egg doing here?

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.

[steipete]

I don't really wanna copy that into each repo - better people check out my agent-scripts repo and symlink that. OR we create a shared one in openclaw?

[steipete]

Closing this draft for now.

The setup baseline is technically clean after the fixups, but it adds maintainer policy and automation surfaces that should not land by inertia: stale automation, write-scoped workflow behavior, and Crabbox hydrate workflow adoption.

We can reopen or recreate this when the repository policy decision is explicit.

[steipete]

Closing this in favor of the shared public skill source at https://github.com/openclaw/agent-skills.

We do not want to vendor the same maintainer skills into every repo. Repos that need zero-setup guidance should add a small pointer to openclaw/agent-skills; shared skill content should be updated there first and synced only where a vendored snapshot is intentionally required.