docs(plugin): Apify plugin docs

.agent/workflows/update_clawdbot.md

@@ -1,8 +1,8 @@
 ---
-description: Update Clawdbot from upstream when branch has diverged (ahead/behind)
+description: Update OpenClaw from upstream when branch has diverged (ahead/behind)
 ---
 
-# Clawdbot Upstream Sync Workflow
+# OpenClaw Upstream Sync Workflow
 
 Use this workflow when your fork has diverged from upstream (e.g., "18 commits ahead, 29 commits behind").
 
@@ -132,16 +132,16 @@ pnpm mac:package
 
 ```bash
 # Kill running app
-pkill -x "Clawdbot" || true
+pkill -x "OpenClaw" || true
 
 # Move old version
-mv /Applications/Clawdbot.app /tmp/Clawdbot-backup.app
+mv /Applications/OpenClaw.app /tmp/OpenClaw-backup.app
 
 # Install new build
-cp -R dist/Clawdbot.app /Applications/
+cp -R dist/OpenClaw.app /Applications/
 
 # Launch
-open /Applications/Clawdbot.app
+open /Applications/OpenClaw.app
 ```
 
 ---
@@ -235,7 +235,7 @@ If upstream introduced new model configurations:
 # Check for OpenRouter API key requirements
 grep -r "openrouter\|OPENROUTER" src/ --include="*.ts" --include="*.js"
 
-# Update clawdbot.json with fallback chains
+# Update openclaw.json with fallback chains
 # Add model fallback configurations as needed
 ```
 

.agents/skills/openclaw-ghsa-maintainer/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: openclaw-ghsa-maintainer
+description: Maintainer workflow for OpenClaw GitHub Security Advisories (GHSA). Use when Codex needs to inspect, patch, validate, or publish a repo advisory, verify private-fork state, prepare advisory Markdown or JSON payloads safely, handle GHSA API-specific publish constraints, or confirm advisory publish success.
+---
+
+# OpenClaw GHSA Maintainer
+
+Use this skill for repo security advisory workflow only. Keep general release work in `openclaw-release-maintainer`.
+
+## Respect advisory guardrails
+
+- Before reviewing or publishing a repo advisory, read `SECURITY.md`.
+- Ask permission before any publish action.
+- Treat this skill as GHSA-only. Do not use it for stable or beta release work.
+
+## Fetch and inspect advisory state
+
+Fetch the current advisory and the latest published npm version:
+
+```bash
+gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
+npm view openclaw version --userconfig "$(mktemp)"
+```
+
+Use the fetch output to confirm the advisory state, linked private fork, and vulnerability payload shape before patching.
+
+## Verify private fork PRs are closed
+
+Before publishing, verify that the advisory's private fork has no open PRs:
+
+```bash
+fork=$(gh api /repos/openclaw/openclaw/security-advisories/<GHSA> | jq -r .private_fork.full_name)
+gh pr list -R "$fork" --state open
+```
+
+The PR list must be empty before publish.
+
+## Prepare advisory Markdown and JSON safely
+
+- Write advisory Markdown via heredoc to a temp file. Do not use escaped `\n` strings.
+- Build PATCH payload JSON with `jq`, not hand-escaped shell JSON.
+
+Example pattern:
+
+```bash
+cat > /tmp/ghsa.desc.md <<'EOF'
+<markdown description>
+EOF
+
+jq -n --rawfile desc /tmp/ghsa.desc.md \
+  '{summary,severity,description:$desc,vulnerabilities:[...]}' \
+  > /tmp/ghsa.patch.json
+```
+
+## Apply PATCH calls in the correct sequence
+
+- Do not set `severity` and `cvss_vector_string` in the same PATCH call.
+- Use separate calls when the advisory requires both fields.
+- Publish by PATCHing the advisory and setting `"state":"published"`. There is no separate `/publish` endpoint.
+
+Example shape:
+
+```bash
+gh api -X PATCH /repos/openclaw/openclaw/security-advisories/<GHSA> \
+  --input /tmp/ghsa.patch.json
+```
+
+## Publish and verify success
+
+After publish, re-fetch the advisory and confirm:
+
+- `state=published`
+- `published_at` is set
+- the description does not contain literal escaped `\\n`
+
+Verification pattern:
+
+```bash
+gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
+jq -r .description < /tmp/ghsa.refetch.json | rg '\\\\n'
+```
+
+## Common GHSA footguns
+
+- Publishing fails with HTTP 422 if required fields are missing or the private fork still has open PRs.
+- A payload that looks correct in shell can still be wrong if Markdown was assembled with escaped newline strings.
+- Advisory PATCH sequencing matters; separate field updates when GHSA API constraints require it.

.agents/skills/openclaw-parallels-smoke/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: openclaw-parallels-smoke
+description: End-to-end Parallels smoke, upgrade, and rerun workflow for OpenClaw across macOS, Windows, and Linux guests. Use when Codex needs to run, rerun, debug, or interpret VM-based install, onboarding, gateway smoke tests, latest-release-to-main upgrade checks, fresh snapshot retests, or optional Discord roundtrip verification under Parallels.
+---
+
+# OpenClaw Parallels Smoke
+
+Use this skill for Parallels guest workflows and smoke interpretation. Do not load it for normal repo work.
+
+## Global rules
+
+- Use the snapshot most closely matching the requested fresh baseline.
+- Gateway verification in smoke runs should use `openclaw gateway status --deep --require-rpc` unless the stable version being checked does not support it yet.
+- Stable `2026.3.12` pre-upgrade diagnostics may require a plain `gateway status --deep` fallback.
+- Treat `precheck=latest-ref-fail` on that stable pre-upgrade lane as baseline, not automatically a regression.
+- Pass `--json` for machine-readable summaries.
+- Per-phase logs land under `/tmp/openclaw-parallels-*`.
+- Do not run local and gateway agent turns in parallel on the same fresh workspace or session.
+
+## macOS flow
+
+- Preferred entrypoint: `pnpm test:parallels:macos`
+- Target the snapshot closest to `macOS 26.3.1 fresh`.
+- `prlctl exec` is fine for deterministic repo commands, but use the guest Terminal or `prlctl enter` when installer parity or shell-sensitive behavior matters.
+- On the fresh Tahoe snapshot, `brew` exists but `node` may be missing from PATH in noninteractive exec. Use `/opt/homebrew/bin/node` when needed.
+- Fresh host-served tgz installs should install as guest root with `HOME=/var/root`, then run onboarding as the desktop user via `prlctl exec --current-user`.
+- Root-installed tgz smoke can log plugin blocks for world-writable `extensions/*`; do not treat that as an onboarding or gateway failure unless plugin loading is the task.
+
+## Windows flow
+
+- Preferred entrypoint: `pnpm test:parallels:windows`
+- Use the snapshot closest to `pre-openclaw-native-e2e-2026-03-12`.
+- Always use `prlctl exec --current-user`; plain `prlctl exec` lands in `NT AUTHORITY\\SYSTEM`.
+- Prefer explicit `npm.cmd` and `openclaw.cmd`.
+- Use PowerShell only as the transport with `-ExecutionPolicy Bypass`, then call the `.cmd` shims from inside it.
+- Keep onboarding and status output ASCII-clean in logs; fancy punctuation becomes mojibake in current capture paths.
+
+## Linux flow
+
+- Preferred entrypoint: `pnpm test:parallels:linux`
+- Use the snapshot closest to fresh `Ubuntu 24.04.3 ARM64`.
+- Use plain `prlctl exec`; `--current-user` is not the right transport on this snapshot.
+- Fresh snapshots may be missing `curl`, and `apt-get update` can fail on clock skew. Bootstrap with `apt-get -o Acquire::Check-Date=false update` and install `curl ca-certificates`.
+- Fresh `main` tgz smoke still needs the latest-release installer first because the snapshot has no Node or npm before bootstrap.
+- This snapshot does not have a usable `systemd --user` session; managed daemon install is unsupported.
+- `prlctl exec` reaps detached Linux child processes on this snapshot, so detached background gateway runs are not trustworthy smoke signals.
+
+## Discord roundtrip
+
+- Discord roundtrip is optional and should be enabled with:
+  - `--discord-token-env`
+  - `--discord-guild-id`
+  - `--discord-channel-id`
+- Keep the Discord token only in a host env var.
+- Use installed `openclaw message send/read`, not `node openclaw.mjs message ...`.
+- Set `channels.discord.guilds` as one JSON object, not dotted config paths with snowflakes.
+- Avoid long `prlctl enter` or expect-driven Discord config scripts; prefer `prlctl exec --current-user /bin/sh -lc ...` with short commands.
+- For a narrower macOS-only Discord proof run, the existing `parallels-discord-roundtrip` skill is the deep-dive companion.

.agents/skills/openclaw-pr-maintainer/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: openclaw-pr-maintainer
+description: Maintainer workflow for reviewing, triaging, preparing, closing, or landing OpenClaw pull requests and related issues. Use when Codex needs to validate bug-fix claims, search for related issues or PRs, apply or recommend close/reason labels, prepare GitHub comments safely, check review-thread follow-up, or perform maintainer-style PR decision making before merge or closure.
+---
+
+# OpenClaw PR Maintainer
+
+Use this skill for maintainer-facing GitHub workflow, not for ordinary code changes.
+
+## 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.
+- `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
+
+## Enforce the bug-fix evidence bar
+
+- Never merge a bug-fix PR based only on issue text, PR text, or AI rationale.
+- 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. a fix that touches the implicated code path
+  4. 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.
+
+## 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 targeted keyword search before proposing new work or closing something as duplicate.
+- Use `--repo openclaw/openclaw` with `--match title,body` first.
+- Add `--match comments` when triaging follow-up discussion.
+- Do not stop at the first 500 results when the task requires a full search.
+
+Examples:
+
+```bash
+gh search prs --repo openclaw/openclaw --match title,body --limit 50 -- "auto-update"
+gh search issues --repo openclaw/openclaw --match title,body --limit 50 -- "auto-update"
+gh search issues --repo openclaw/openclaw --match title,body --limit 50 \
+  --json number,title,state,url,updatedAt -- "auto update" \
+  --jq '.[] | "\(.number) | \(.state) | \(.title) | \(.url)"'
+```
+
+## Follow PR review and landing hygiene
+
+- 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.
+- When landing or merging any PR, follow the global `/landpr` process.
+- 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.
+
+## Extra safety
+
+- If a close or reopen action would affect more than 5 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.

.agents/skills/openclaw-release-maintainer/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: openclaw-release-maintainer
+description: Maintainer workflow for OpenClaw releases, prereleases, changelog release notes, and publish validation. Use when Codex needs to prepare or verify stable or beta release steps, align version naming, assemble release notes, check release auth requirements, or validate publish-time commands and artifacts.
+---
+
+# OpenClaw Release Maintainer
+
+Use this skill for release and publish-time workflow. Keep ordinary development changes and GHSA-specific advisory work outside this skill.
+
+## Respect release guardrails
+
+- Do not change version numbers without explicit operator approval.
+- Ask permission before any npm publish or release step.
+- Use the private maintainer release docs for the actual runbook and `docs/reference/RELEASING.md` for public policy.
+
+## Keep release channel naming aligned
+
+- `stable`: tagged releases only, with npm dist-tag `latest`
+- `beta`: prerelease tags like `vYYYY.M.D-beta.N`, with npm dist-tag `beta`
+- Prefer `-beta.N`; do not mint new `-1` or `-2` beta suffixes
+- `dev`: moving head on `main`
+- When using a beta Git tag, publish npm with the matching beta version suffix so the plain version is not consumed or blocked
+
+## Handle versions and release files consistently
+
+- Version locations include:
+  - `package.json`
+  - `apps/android/app/build.gradle.kts`
+  - `apps/ios/Sources/Info.plist`
+  - `apps/ios/Tests/Info.plist`
+  - `apps/macos/Sources/OpenClaw/Resources/Info.plist`
+  - `docs/install/updating.md`
+  - Peekaboo Xcode project and plist version fields
+- “Bump version everywhere” means all version locations above except `appcast.xml`.
+- Release signing and notary credentials live outside the repo in the private maintainer docs.
+
+## Build changelog-backed release notes
+
+- Changelog entries should be user-facing, not internal release-process notes.
+- When cutting a mac release with a beta GitHub prerelease:
+  - tag `vYYYY.M.D-beta.N` from the release commit
+  - create a prerelease titled `openclaw YYYY.M.D-beta.N`
+  - use release notes from the matching `CHANGELOG.md` version section
+  - attach at least the zip and dSYM zip, plus dmg if available
+- Keep the top version entries in `CHANGELOG.md` sorted by impact:
+  - `### Changes` first
+  - `### Fixes` deduped with user-facing fixes first
+
+## Run publish-time validation
+
+Before tagging or publishing, run:
+
+```bash
+node --import tsx scripts/release-check.ts
+pnpm release:check
+pnpm test:install:smoke
+```
+
+For a non-root smoke path:
+
+```bash
+OPENCLAW_INSTALL_SMOKE_SKIP_NONROOT=1 pnpm test:install:smoke
+```
+
+## Use the right auth flow
+
+- Core `openclaw` publish uses GitHub trusted publishing.
+- Do not use `NPM_TOKEN` or the plugin OTP flow for core releases.
+- `@openclaw/*` plugin publishes use a separate maintainer-only flow.
+- Only publish plugins that already exist on npm; bundled disk-tree-only plugins stay unpublished.
+
+## GHSA advisory work
+
+- Use `openclaw-ghsa-maintainer` for GHSA advisory inspection, patch/publish flow, private-fork validation, and GHSA API-specific publish checks.