[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M698R0JRXT3GQK3N4HESBC9S":3,"skill-same:01M698R0JRXT3GQK3N4HESBC9S":61},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":43,"ownerHtmlUrl":44,"ownerBlogUrl":43,"ownerDescription":45,"updatedAt":46,"install":47,"resources":60},"01M698R0JRXT3GQK3N4HESBC9S","openclaw-parallels-smoke",null,"Prepare, snapshot, run, rerun, debug, or interpret OpenClaw Parallels guest install, onboarding, gateway smoke, and upgrade checks across macOS, Windows, and Linux.","openclaw\u002Fopenclaw","openclaw","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F252820863?v=4","01M698P3FSAZ6B4R928ZF19KPT","01M698PDMDRVH56MV30D253NFP",394302,"MIT","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenclaw-parallels-smoke\u002FSKILL.md",[],[9,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32],"openclaw parallels smoke","smoke","macos","linux","windows","prepare","debug","run","onboarding","gateway","install","snapshot","upgrade","across","rerun","2026-11-10 10:12:30",false,"---\nname: openclaw-parallels-smoke\ndescription: Prepare, snapshot, run, rerun, debug, or interpret OpenClaw Parallels guest install, onboarding, gateway smoke, and upgrade checks across macOS, Windows, and Linux.\n---\n\n# OpenClaw Parallels Smoke\n\nUse this skill for Parallels guest workflows and smoke interpretation. Do not load it for normal repo work.\n\n## Global rules\n\n- Parallels is postpublish-confidence coverage by default, not a prerequisite\n  for the bounded beta-publish phase. Run it against one exact published\n  package version and record the Validation SHA + Tooling SHA run tuple that\n  authorized that package. Validation SHA maps to its Code SHA or Release SHA;\n  it is not a third release identity.\n- A failed postpublish Parallels lane does not retroactively unpublish a beta.\n  Classify it as product, harness\u002Ftooling\u002Fprovenance, infrastructure\u002Fcredential,\n  or wrapper failure. Only a confirmed product defect enters the next beta.\n- Use one coordinator and one lane per independent guest family. Diagnose and\n  retry one failed family once, then reassess; do not restart the aggregate\n  matrix automatically.\n- Inventory existing VMs and snapshots before provisioning anything. When a preconfigured pristine\n  snapshot matches the requested baseline, switch to it and reuse its user, tools, and base setup.\n  Do not create a new VM, reinstall macOS, or rebuild the guest baseline for a \"fresh\" run.\n- \"Fresh\" means restoring the closest existing pristine snapshot, not creating another snapshot.\n  Do not create ad-hoc snapshots unless the user explicitly asks or no suitable baseline exists;\n  restore the original snapshot and leave the guest stopped after an ad-hoc run.\n- Inspect the snapshot state before restoring it. A pristine `poweron` snapshot can contain the\n  preconfigured logged-in session; switch to it normally so Parallels resumes that session. Do not\n  pass `--skip-resume` at test entry unless the run intentionally needs to discard the saved session\n  and boot from the login window. `--skip-resume` is acceptable for final cleanup that must leave the\n  restored source guest stopped.\n- Gateway verification in smoke runs should use `openclaw gateway status --deep --require-rpc` unless the stable version being checked does not support it yet.\n- Stable `2026.3.12` pre-upgrade diagnostics may require a plain `gateway status --deep` fallback.\n- Treat `precheck=latest-ref-fail` on that stable pre-upgrade lane as baseline, not automatically a regression.\n- Pass `--json` for machine-readable summaries.\n- Per-phase logs land under `.artifacts\u002Fparallels\u002Fopenclaw-parallels-*` by default. Override with `OPENCLAW_PARALLELS_ARTIFACT_ROOT` when a run needs another artifact volume.\n- Do not run local and gateway agent turns in parallel on the same fresh workspace or session.\n- Hard-cap every top-level Parallels lane with host `timeout --foreground` (or `gtimeout --foreground` if that is the available binary) so a stalled install, snapshot switch, or `prlctl exec` transport cannot consume the rest of the testing window. Defaults:\n  - macOS: `75m`\n  - Linux: `75m`\n  - Windows: `90m`\n  - aggregate npm-update wrapper: `150m`\n    If a lane hits the cap, stop there, inspect the newest `\u002Ftmp\u002Fopenclaw-parallels-*` run directory and phase log, then fix or rerun the smallest affected lane. Do not keep waiting on a capped lane.\n- Actual OpenClaw npm install\u002Fupdate phases are a stricter signal than whole-lane caps: install phases should normally finish within 7 minutes, and update phases should normally show meaningful progress within 5 minutes. If a phase named `install-main`, `install-latest`, `install-baseline`, or `install-baseline-package` exceeds 420s, or a phase named `update-dev` \u002F same-guest `openclaw update` exceeds 300s without new markers, start diagnosis from that phase log and guest process state. Current Windows update phases can still pass after roughly 10-15 minutes because `doctor --fix` may install bundled plugin runtime deps; keep the script hard cap near 20 minutes unless the log is truly stale.\n- For a full OS matrix, prefer running independent guest-family lanes in parallel when host capacity allows:\n  - `timeout --foreground 75m pnpm test:parallels:macos -- --json`\n  - `timeout --foreground 90m pnpm test:parallels:windows -- --json`\n  - `timeout --foreground 75m pnpm test:parallels:linux -- --json`\n    Keep each lane in its own shell\u002Fsession and track the run directory for each one. Before starting the matrix, run any required host build\u002Fpackage gate to completion. When current-main tgz packaging is needed, the smoke scripts hold a shared package lock through `pnpm build`, inventory\u002Fstaging, and `npm pack`; if that lock is missing or broken, serialize the matrix instead of accepting concurrent `dist` mutation.\n- Do not run multiple smoke lanes against the same guest family at once. Tahoe lanes share the host HTTP port, and Windows\u002FLinux lanes can collide on snapshot restore\u002Fstart state if two jobs touch the same VM concurrently.\n- Do not run the aggregate `pnpm test:parallels:npm-update` wrapper in parallel with individual macOS\u002FWindows\u002FLinux smoke lanes; it touches the same guest families and snapshots.\n- Do not start Parallels lanes while any unrelated host command may rebuild, clean, or restage `dist` (`pnpm build`, `pnpm ui:build`, `pnpm release:check`, `pnpm test:install:smoke`, npm pack\u002Finstall smoke, or Docker lanes that run package\u002Fbuild prep). Run unrelated build\u002Fpackage gates first, let them finish, then start the VM matrix. Concurrent `dist` mutation can make host `npm pack` fail with missing files and wastes a full VM cycle.\n- While running or optimizing the matrix, record wall-clock duration per lane and the slowest phase from `\u002Ftmp\u002Fopenclaw-parallels-*` logs. Use that timing before changing smoke order, timeouts, or helper behavior.\n- If a host build changes tracked generated files, stop before spending VM time. Commit the generated artifact separately or fix the generator drift, then rerun the smallest affected lane.\n- If `main` is moving under active multi-agent work, prefer a detached worktree pinned to one commit for long Parallels suites. The smoke scripts now verify the packed tgz commit instead of live `git rev-parse HEAD`, but a pinned worktree still avoids noisy rebuild\u002Fversion drift during reruns.\n- For `openclaw update --channel dev` lanes, remember the guest clones GitHub `main`, not your local worktree. If a local fix exists but the rerun still fails inside the cloned dev checkout, do not treat that as disproof of the fix until the branch has been pushed.\n- For `prlctl exec`, pass the VM name before `--current-user` (`prlctl exec \"$VM\" --current-user ...`), not the other way around.\n- If the workflow installs OpenClaw from a repo checkout instead of the site installer\u002Fnpm release, finish by installing a real guest CLI shim and verifying it in a fresh guest shell. `pnpm openclaw ...` inside the repo is not enough for handoff parity.\n- On macOS guests, prefer a user-global install plus a stable PATH-visible shim:\n  - install with `NPM_CONFIG_PREFIX=\"$HOME\u002F.npm-global\" npm install -g .`\n  - make sure `~\u002F.local\u002Fbin\u002Fopenclaw` exists or `~\u002F.npm-global\u002Fbin` is on PATH\n  - verify from a brand-new guest shell with `which openclaw` and `openclaw --version`\n\n## npm install then update\n\n- Preferred entrypoint: `pnpm test:parallels:npm-update`\n- For a macOS-only published release update check, use:\n  - `timeout --foreground 75m pnpm test:parallels:npm-update -- --platform macos --package-spec openclaw@\u003Cold-version> --update-target \u003Ctarget-version-or-tag> --json`\n    This keeps the same-guest `openclaw update --tag ...` coverage and uses the shared macOS current-user\u002Fsudo fallback without starting Windows\u002FLinux lanes.\n- Required coverage: every release\u002Fupdate regression run must include both lanes:\n  - fresh snapshot -> install requested package\u002Fbaseline -> smoke\n  - same guest baseline -> run the guest's installed `openclaw update ...` command -> smoke again\n- The update lane must exercise OpenClaw's internal updater. Do not count a direct `npm install -g \u003Ctgz-or-spec>` or harness-side package swap as update-flow coverage; those are install smokes only.\n- For published targets, install the old baseline package first (for example `openclaw@2026.4.9`), then run the installed guest CLI with the intended channel\u002Ftag (for example `openclaw update --channel beta --yes --json`) and verify `openclaw --version`, `openclaw update status --json`, gateway RPC, and an agent turn after the command.\n- For unpublished targets, pack the candidate on the host, serve the `.tgz` over the harness HTTP server, and point the guest updater at that served package. Prefer `openclaw update --tag http:\u002F\u002F\u003Chost-ip>:\u003Cport>\u002Fopenclaw-\u003Cversion>.tgz --yes --json`; when channel persistence also matters, pass `--channel \u003Cstable|beta>` and set `OPENCLAW_UPDATE_PACKAGE_SPEC` to the same served URL in the guest update environment. The command under test must still be `openclaw update`, not direct npm.\n- For unpublished local-fix validation, remember the old baseline updater code still controls the first hop. A fix that lives only in the new updater code cannot change that already-running old process; the served candidate must either keep package\u002Fplugin metadata compatible with the baseline host or the baseline itself must include the updater fix.\n- For beta\u002Fstable verification, resolve the tag immediately before the run (`npm view openclaw@beta version dist.tarball` or `npm view openclaw@latest ...`). Tags can move while a long VM matrix is already running; restart the matrix when the intended prerelease appears after an earlier registry 404\u002Ftag-lag check.\n- Use the configured secret workflow to inject only the provider keys needed by OpenAI\u002FAnthropic lanes. Do not print secrets or env dumps; pass provider secrets through the guest exec environment.\n- Same-guest update verification should set the default model explicitly to `openai\u002Fgpt-5.4` before the agent turn and use a fresh explicit `--session-id` so old session model state does not leak into the check.\n- The aggregate npm-update wrapper must resolve the Linux VM with the same Ubuntu fallback policy as `parallels-linux-smoke.sh` before both fresh and update lanes. Treat any Ubuntu guest with major version `>= 24` as acceptable when the exact default VM is missing, preferring the newest versioned Ubuntu guest with a fresh poweroff snapshot. On Peter's current host today, use `Ubuntu 26.04`.\n- On macOS same-guest update checks, restart the gateway after the npm upgrade before `gateway status` \u002F `agent`; launchd can otherwise report a loaded service while the old process has exited and the fresh process is not RPC-ready yet.\n- The npm-update aggregate's macOS update leg writes the guest update script as root, then runs it as the desktop user. If `prlctl exec \"$MACOS_VM\" --current-user ...` cannot authenticate, retry through plain root `prlctl exec` plus `sudo -u \u003Cdesktop-user> \u002Fusr\u002Fbin\u002Fenv HOME=\u002FUsers\u002F\u003Cdesktop-user> USER=\u003Cdesktop-user> LOGNAME=\u003Cdesktop-user> PATH=\u002Fopt\u002Fhomebrew\u002Fbin:\u002Fopt\u002Fhomebrew\u002Fopt\u002Fnode\u002Fbin:\u002Fusr\u002Fbin:\u002Fbin:\u002Fusr\u002Fsbin:\u002Fsbin ...`. That is a Parallels transport fallback; still verify `openclaw --version`, gateway RPC, and an agent turn after the update.\n- On Windows same-guest update checks, restart the gateway after the npm upgrade before `gateway status` \u002F `agent`; in-place global npm updates can otherwise leave stale hashed `dist\u002F*` module imports alive in the running service.\n- In those Windows same-guest update checks, do not treat one nonzero `openclaw gateway restart` as definitive failure. Current login-item restarts can report failure before the background service becomes observable again; follow with a longer RPC-ready wait and use `gateway start` only as a recovery step if readiness still never returns.\n- After that Windows restart, do not trust one `gateway status --deep --require-rpc` call after a fixed sleep. Retry the RPC-ready probe for roughly 30 seconds and log each attempt; current guests can keep port `18789` bound while the fresh RPC endpoint is still coming up.\n- For Windows same-guest update checks, prefer the done-file\u002Flog-drain PowerShell runner pattern over one long-lived `prlctl exec ... powershell -EncodedCommand ...` transport. The guest can finish successfully while the outer `prlctl exec` still hangs.\n- The Windows same-guest update helper should write stage markers to its log before long steps like tgz download and `npm install -g` so the outer progress monitor does not sit on `waiting for first log line` during healthy but quiet installs.\n- Linux same-guest update verification should also export `HOME=\u002Froot`, pass `OPENAI_API_KEY` via `prlctl exec ... \u002Fusr\u002Fbin\u002Fenv`, and use `openclaw agent --local`; the fresh Linux baseline does not rely on persisted gateway credentials.\n- The npm-update wrapper now prints per-lane progress from the nested log files. If a lane still looks stuck, inspect the nested logs in `runDir` first (`macos-fresh.log`, `windows-fresh.log`, `linux-fresh.log`, `macos-update.log`, `windows-update.log`, `linux-update.log`) instead of assuming the outer wrapper hung.\n- Each run writes both `summary.json` and `summary.md`; read the markdown first for quick human triage, then the JSON\u002Ftimings for automation.\n- For full beta validation after a tag is published, prefer one command:\n  - `timeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta3 --json`\n    This resolves `beta3` to the latest `*-beta.3` version, runs latest->that-version same-guest update coverage, and then runs fresh install smoke for that exact published target on the same selected OS matrix. Use `--platform macos|windows|linux` to narrow reruns.\n- For beta 4 npm validation with agent turns, the known-good shape is:\n  - `gtimeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta4 --model openai\u002Fgpt-5.4 --json`\n    Prefer the explicit `beta4` alias over `openclaw@beta` when validating a specific prerelease number; npm tags can move.\n- If the wrapper fails a lane, read the auto-dumped tail first, then the full nested lane log under `.artifacts\u002Fparallels\u002Fopenclaw-parallels-npm-update.*`.\n- Current known macOS update-lane transport signature when the fallback is missing or bypassed: `Unable to authenticate the user. Make sure that the specified credentials are correct and try again.` Treat that as Parallels current-user authentication before blaming npm or OpenClaw.\n- A macOS packaged fresh install with global package directories or bundled files mode `0777` usually means the harness used the root `prlctl exec` fallback under a permissive umask. The POSIX guest transports should prepend `umask 022`; verify the phase preflight line before blaming npm.\n\n## CLI invocation footgun\n\n- The Parallels smoke shell scripts should tolerate a literal bare `--` arg so `pnpm test:parallels:* -- --json` and similar forwarded invocations work without needing to call `bash scripts\u002Fe2e\u002F...` directly.\n\n## macOS and Windows guest-command transport\n\nThe macOS and Windows smoke and same-guest update lanes route guest commands through\n`scripts\u002Fe2e\u002Fparallels\u002Fparallels-exec.py`; macOS hosts need `python3` with its standard\nlibrary. On verified Parallels 27.0.0 (58628) and 27.0.2 (58673) Apple-silicon installations for macOS guests,\nand 27.1.0 (58756) for Windows guests, the\nclient retains SDK login-job handles through result extraction, avoiding the\nhost CLI's intermittent `PrlJob_GetRetCode: Invalid argument` failure. This error\nis not proof that the guest needs reinstallation or another Tools update.\n\nSelection checks the actual `prlctl` on PATH and the installed CLI digest before\nexecution. Other binaries retain ordinary `prlctl`; an SDK failure never retries\nthrough another transport. Root\u002Fcurrent-user choice, raw shell-argument joining,\nstdin, stdout\u002Fstderr, and guest exit status are preserved. Windows calls pass `--windows`\nto keep the program separate from its raw arguments; POSIX calls retain shell joining.\nCallers still own shell quoting. Bare UUIDs use the CLI's braced lookup form; when that UUID is absent,\nthe client checks the original literal VM name once before any guest execution.\nOther lookup failures are terminal. Snapshot\u002Fstart\u002Fstop\u002Finput\u002Fcapture and\nLinux execution are unchanged.\n\nFor an already-owned, running macOS guest, the same transport can be checked directly:\n\n```bash\npython3 -B scripts\u002Fe2e\u002Fparallels\u002Fparallels-exec.py --timeout-ms 30000 -- exec \"\u003Cowned-macos-vm>\" --current-user \u002Fbin\u002Fecho ready\n```\n\nKeep the outer host timeout for complete lanes; the SDK wait deadline is not proof\nof guest-process termination. This is a bounded workaround, not a supported public\nSDK integration. Revalidate ABI and live command\u002Fstdio\u002Fcleanup behavior before\nadding an installed-binary digest; remove the workaround after a vendor-fixed CLI\nis verified. Restore the original snapshot and stop the guest after ad-hoc proof.\n\n## macOS flow\n\n- Preferred entrypoint: `pnpm test:parallels:macos`\n- `parallels-macos-smoke.sh --mode fresh --target-package-spec openclaw@\u003Cversion>` is an install smoke only. For published old-version -> new-version update coverage on macOS, prefer the npm-update wrapper with `--platform macos`; `parallels-macos-smoke.sh --mode upgrade --target-package-spec ...` installs the target package and does not exercise the baseline CLI's updater.\n- Default upgrade coverage on macOS should now include: fresh snapshot -> site installer pinned to the latest stable tag -> `openclaw update --channel dev` on the guest. Treat this as part of the default Tahoe regression plan, not an optional side quest.\n- `parallels-macos-smoke.sh --mode upgrade` should run that release-to-dev lane by default. Keep the older host-tgz upgrade path only when the caller explicitly passes `--target-package-spec`.\n- Because the default upgrade lane no longer needs a host tgz, skip `npm pack` + host HTTP server startup for `--mode upgrade` unless `--target-package-spec` is set. Keep the pack\u002Fserver path for `fresh` and `both`.\n- If that release-to-dev lane fails with `reason=preflight-no-good-commit` and repeated `sh: pnpm: command not found` tails from `preflight build`, treat it as an updater regression first. The fix belongs in the git\u002Fdev updater bootstrap path, not in Parallels retry logic.\n- Until the public stable train includes that updater bootstrap fix, the macOS release-to-dev lane may seed a temporary guest-local `pnpm` shim immediately before `openclaw update --channel dev`. Keep that workaround scoped to the smoke harness and remove it once the latest stable no longer needs it.\n- In Tahoe `prlctl exec --current-user` runs, prefer explicit `node ...\u002Fopenclaw.mjs ...` invocations for the release->dev handoff itself and for post-update verification. The shebanged global `openclaw` wrapper can fail with `env: node: No such file or directory`, and self-updating through the wrapper is a weaker lane than invoking the entrypoint under a fixed `node`.\n- Default to the snapshot closest to `macOS 26.5 latest`.\n- On Peter's Tahoe VM, `fresh-latest-march-2026` can hang in `prlctl snapshot-switch`; if restore times out there, rerun with `--snapshot-hint 'macOS 26.5 latest'` before blaming auth or the harness.\n- `parallels-macos-smoke.sh` now retries `snapshot-switch` once after force-stopping a stuck running\u002Fsuspended guest. If Tahoe still times out after that recovery path, then treat it as a real Parallels\u002Fhost issue and rerun manually.\n- The macOS smoke should include a dashboard load phase after gateway health: resolve the tokenized URL with `openclaw dashboard --no-open`, verify the served HTML contains the Control UI title\u002Froot shell, then open Safari and require an established localhost TCP connection from Safari to the gateway port.\n- For Tahoe `fresh.gateway-status`, prefer non-TTY `prlctl exec --current-user ... openclaw gateway status ...` plus a few short retries. `prlctl enter` can spam TTY control bytes and hang the phase log even when the CLI itself is healthy.\n- If a Tahoe lane times out in `fresh.first-agent-turn` and the phase log stops right after `__OPENCLAW_RC__:0` from `models set`, suspect the `prlctl enter` \u002F `expect` wrapper before blaming auth or the model lane. That pattern means the first guest command finished but the transport never released for the next `guest_current_user_cli` call.\n- If a packaged install regresses with `500` on `\u002F`, `\u002Fhealthz`, or `__openclaw\u002Fcontrol-ui-config.json` after `fresh.install-main` or `upgrade.install-main`, suspect bundled plugin runtime deps resolving from the package root `node_modules` rather than `dist\u002Fextensions\u002F*\u002Fnode_modules`. Repro quickly with a real `npm pack`\u002Fglobal install lane before blaming dashboard auth or Safari.\n- `prlctl exec` is fine for deterministic repo commands, but use the guest Terminal or `prlctl enter` when installer parity or shell-sensitive behavior matters.\n- Multi-word `openclaw agent --message ...` checks should go through a guest shell wrapper (`guest_current_user_sh` \u002F `guest_current_user_cli` or `\u002Fbin\u002Fsh -lc ...`), not raw `prlctl exec ... node openclaw.mjs ...`, or the message can be split into extra argv tokens and Commander reports `too many arguments for 'agent'`.\n- The same wrapper rule applies when bypassing `--current-user`: write a tiny `\u002Ftmp\u002F*.sh` on the guest and execute `\u002Fbin\u002Fbash \u002Ftmp\u002F*.sh` through the sudo desktop-user environment. Do not pass `openclaw agent --message '...'` directly as one raw `prlctl exec` command.\n- When ref-mode onboarding stores `OPENAI_API_KEY` as an env secret ref, the post-onboard agent verification should also export `OPENAI_API_KEY` for the guest command. The gateway can still reject with pairing-required and fall back to embedded execution, and that fallback needs the env-backed credential available in the shell.\n- On the fresh Tahoe snapshot, `brew` exists but `node` may be missing from PATH in noninteractive exec. Use `\u002Fopt\u002Fhomebrew\u002Fbin\u002Fnode` when needed.\n- Fresh host-served tgz installs should install as guest root with `HOME=\u002Fvar\u002Froot`, then run onboarding as the desktop user via `prlctl exec --current-user`.\n- Root-installed tgz smoke can log plugin blocks for world-writable `extensions\u002F*`; do not treat that as an onboarding or gateway failure unless plugin loading is the task.\n\n## Windows flow\n\n- This repo owns the general Windows VM lifecycle: remote `prlctl` management, clean-state checks, WSL 2, Git\u002FNode, snapshot creation\u002Frestoration, and OpenClaw smoke. Assume Parallels Desktop is installed\u002Factivated and a Windows 11 VM has been downloaded, then run:\n\n  ```bash\n  pnpm test:parallels:windows:prepare -- inventory\n  pnpm test:parallels:windows:prepare -- prepare\n  pnpm test:parallels:windows:prepare -- verify\n  ```\n\n- `prepare` inventories before mutation, requires Parallels Tools and a logged-in desktop session, rejects OpenClaw CLI\u002Fapp\u002Ftray\u002Fprocess state and WSL distros, creates a dated power-off clean-OS snapshot only on an unprepared guest, enables WSL\u002FVirtual Machine Platform, installs the signed Microsoft WSL package, sets WSL 2 as default, installs Git, Node\u002Fnpm, and the native addons' Visual C++ runtime, verifies the Windows hypervisor is active and no reboot is pending, and creates a power-off `pre-openclaw-native-e2e-\u003Cdate>` snapshot. Existing baselines without `vcruntime140.dll` fail verification; prepare a new baseline name to upgrade them.\n- When today's E2E snapshot already exists, `prepare` restores and verifies that snapshot instead of trusting its name. Treat `prepare` as destructive to post-snapshot guest changes, just like an explicit restore.\n- Package elevation resolves the exact version and SHA-256 from Microsoft's official WinGet manifests, validates the expected Authenticode publisher, and copies into a freshly ACL-restricted SYSTEM directory before execution. Keep this generic mechanism here; companion-specific package choices stay in the Windows app repo.\n- Restore `clean`, `e2e`, an exact name, or an id:\n\n  ```bash\n  pnpm test:parallels:windows:prepare -- restore --snapshot e2e\n  ```\n\n- Restoring discards all post-snapshot changes. Inventory first and do not restore while another developer or lane owns the VM. `e2e` selects the newest `pre-openclaw-native-e2e-*`; use an exact snapshot for historical reproduction.\n- For native companion work, read `..\u002F..\u002F..\u002F..\u002Fopenclaw-windows-node\u002F.agents\u002Fskills\u002Fopenclaw-proof-validation\u002FPARALLELS.md`. That optional macOS sidecar reuses this controller and adds only .NET, Windows SDK, WebView2, the app checkout, app-layer snapshots, build\u002Ftests, and native proof.\n- Preferred entrypoint: `pnpm test:parallels:windows`\n- Use the newest verified `pre-openclaw-native-e2e-*` snapshot and pass its exact name with `--snapshot-hint`.\n- Default upgrade coverage on Windows should now include: fresh snapshot -> site installer pinned to the requested stable tag -> `openclaw update --channel dev` on the guest. Keep the older host-tgz upgrade path only when the caller explicitly passes `--target-package-spec`.\n- Optional exact npm-tag baseline on Windows: `bash scripts\u002Fe2e\u002Fparallels-windows-smoke.sh --mode upgrade --target-package-spec openclaw@\u003Ctag> --json`. That lane installs the published npm tarball as baseline, then runs `openclaw update --channel dev`.\n- Optional forward-fix Windows validation: `bash scripts\u002Fe2e\u002Fparallels-windows-smoke.sh --mode upgrade --upgrade-from-packed-main --json`. That lane installs the packed current-main npm tgz as baseline, then runs `openclaw update --channel dev`.\n- Always use `prlctl exec --current-user`; plain `prlctl exec` lands in `NT AUTHORITY\\\\SYSTEM`.\n- Prefer explicit `npm.cmd` and `openclaw.cmd`.\n- Use PowerShell only as the transport with `-ExecutionPolicy Bypass`, then call the `.cmd` shims from inside it.\n- Current Windows Node installs expose `corepack` as a `.cmd` shim. If a release-to-dev lane sees `corepack` on PATH but `openclaw update --channel dev` still behaves as if corepack is missing, treat that as an exec-shim regression first.\n- If an exact published-tag Windows lane fails during preflight with `npm run build` and `'pnpm' is not recognized`, remember that the guest is still executing the old published updater. Validate the fix with `--upgrade-from-packed-main`, then wait for the next tagged npm release before expecting the historical tag lane to pass.\n- Multi-word `openclaw agent --message ...` checks should call `& $openclaw ...` inside PowerShell, not `Start-Process ... -ArgumentList` against `openclaw.cmd`, or Commander can see split argv and throw `too many arguments for 'agent'`.\n- Windows installer\u002Ftgz phases now retry once after guest-ready recheck; keep new Windows smoke steps idempotent so a transport-flake retry is safe.\n- If a Windows retry sees the VM become `suspended` or `stopped`, resume\u002Fstart it before the next `prlctl exec`; otherwise the second attempt just repeats the same `rc=255`.\n- Windows global `npm install -g` phases can stay quiet for a minute or more even when healthy; inspect the phase log before calling it hung, and only treat it as a regression once the retry wrapper or timeout trips.\n- When those Windows global installs stay quiet, the useful progress often lives in the guest npm debug log, not the helper phase log. The smoke script now streams incremental `npm-cache\u002F_logs\u002F*-debug-0.log` deltas into the phase log during long baseline\u002Fpackage installs; read those lines before assuming the lane is stalled.\n- The Windows baseline-package helpers now auto-dump the latest guest `npm-cache\u002F_logs\u002F*-debug-0.log` tail on timeout or nonzero completion. Read that tail in the phase log before opening a second guest shell.\n- The same incremental npm-debug streaming also applies to `--upgrade-from-packed-main` \u002F packaged-install baseline phases. A phase log that still says only `install.start`, `install.download-tgz`, `install.install-tgz` can still be healthy if the streamed npm-debug section shows registry fetches or bundled-plugin postinstall work.\n- Fresh Windows tgz install phases should also use the background PowerShell runner plus done-file\u002Flog-drain pattern; do not rely on one long-lived `prlctl exec ... powershell ... npm install -g` transport for package installs.\n- Windows release-to-dev helpers may log `where pnpm` diagnostically. The updater deliberately bootstraps a temporary pinned pnpm and cleans it up; permanent pnpm availability is not a post-update requirement. Require the installed OpenClaw CLI to resolve in a fresh shell using persisted Machine + User PATH.\n- Keep the CLI update deadline inside the Windows phase envelope, with separate setup\u002Freporting and cleanup allowances. If setup consumes the command's reserved budget, refuse before launching the updater. Verify version, status, and fresh-shell CLI in the subsequent verification phase; retain the top-level host hard cap.\n- Fresh Windows ref-mode onboard should use the same background PowerShell runner plus done-file\u002Flog-drain pattern as the npm-update helper, including startup materialization checks, host-side timeouts on short poll `prlctl exec` calls, and retry-on-poll-failure behavior for transient transport flakes.\n- Fresh Windows daemon-health reachability should use `openclaw gateway probe --json` with a longer timeout and treat `ok: true` as success; full `gateway status --require-rpc` checks are too eager during initial startup on current main.\n- Fresh Windows ref-mode agent verification should set `OPENAI_API_KEY` in the PowerShell environment before invoking `openclaw.cmd agent`, for the same pairing-required fallback reason as macOS.\n- The standalone Windows upgrade smoke lane should stop the managed gateway after `upgrade.install-main` and before `upgrade.onboard-ref`. Restarting before onboard can leave the old process alive on the pre-onboard token while onboard rewrites `~\u002F.openclaw\u002Fopenclaw.json`, which then fails `gateway-health` with `unauthorized: gateway token mismatch`.\n- If standalone Windows upgrade fails with a gateway token mismatch but `pnpm test:parallels:npm-update` passes, trust the mismatch as a standalone ref-onboard ordering bug first; the npm-update helper does not re-run ref-mode onboard on the same guest.\n- Keep onboarding and status output ASCII-clean in logs; fancy punctuation becomes mojibake in current capture paths.\n- If you hit an older run with `rc=255` plus an empty `fresh.install-main.log` or `upgrade.install-main.log`, treat it as a likely `prlctl exec` transport drop after guest start-up, not immediate proof of an npm\u002Fpackage failure.\n- If WSL features are enabled but `wsl.exe --version` fails, rerun `prepare`; the inbox features and the signed WSL package are separate prerequisites. If the default reverts to 1, set `wsl.exe --set-default-version 2` and rerun `verify`.\n- If `winget` detaches or prints nothing over `prlctl`, call it through `cmd.exe \u002Fd \u002Fs \u002Fc`. Avoid remote UAC: download as the desktop user, then let the controller verify the trusted manifest hash\u002Fpublisher and install from its protected SYSTEM staging directory.\n- If snapshot restore reports incompatible saved CPU state, make a power-off replacement snapshot from the known-good disk state and use its exact name. Never bypass snapshot restore for a two-lane fresh+upgrade claim.\n- If baseline verification reports OpenClaw state, restore `clean` or remove the product state deliberately; never bless a dirty guest. Check `%APPDATA%` and `%LOCALAPPDATA%` for both stable and dev companion identities plus Inno uninstall registration.\n- Long Windows installers can remain quiet while healthy. Inspect `tasklist` and installer\u002FMSI logs before declaring a hang; keep long operations behind a background runner with short host-bounded polling calls.\n\n## Linux flow\n\n- Preferred entrypoint: `pnpm test:parallels:linux`\n- Use the newest versioned Ubuntu guest with a fresh poweroff snapshot. On Peter's host today, that is `Ubuntu 26.04`.\n- If an exact requested Ubuntu VM is missing on the host, any Ubuntu guest with major version `>= 24` is acceptable; prefer the newest versioned Ubuntu guest over older fallback snapshots.\n- Use plain `prlctl exec`; `--current-user` is not the right transport on this snapshot.\n- 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`.\n- Fresh `main` tgz smoke still needs the latest-release installer first because the snapshot has no Node or npm before bootstrap.\n- This snapshot does not have a usable `systemd --user` session; managed daemon install is unsupported.\n- The Linux smoke now falls back to a manual `setsid openclaw gateway run --bind loopback --port 18789 --force` launch with `HOME=\u002Froot` and the provider secret exported, then verifies `gateway status --deep --require-rpc` when available.\n- The Linux manual gateway launch should wait for `gateway status --deep --require-rpc` inside the `gateway-start` phase; otherwise the first status probe can race the background bind and fail a healthy lane.\n- If Linux gateway bring-up fails, inspect `\u002Ftmp\u002Fopenclaw-parallels-linux-gateway.log` in the guest phase logs first; the common failure mode is a missing provider secret in the launched gateway environment.\n\n## Discord roundtrip\n\n- Discord roundtrip is optional and should be enabled with:\n  - `--discord-token-env`\n  - `--discord-guild-id`\n  - `--discord-channel-id`\n- After a successful Discord smoke\u002Froundtrip, shut down the guest VM before handoff (`prlctl stop \"$VM_NAME\"` or the concrete VM name). The macOS smoke harness should do this automatically after successful Discord proof; still stop the VM manually after ad-hoc Discord checks. Do not leave the Discord-configured guest running; it can keep reading\u002Fposting in `#maintainer` and spam Discord after the proof is complete.\n- Keep the Discord token only in a host env var.\n- Use installed `openclaw message send\u002Fread`, not `node openclaw.mjs message ...`.\n- Set `channels.discord.guilds` as one JSON object, not dotted config paths with snowflakes.\n- Avoid long `prlctl enter` or expect-driven Discord config scripts; prefer `prlctl exec --current-user \u002Fbin\u002Fsh -lc ...` with short commands.\n- For a narrower macOS-only Discord proof run, the existing `parallels-discord-roundtrip` skill is the deep-dive companion.\n","# OpenClaw Parallels Smoke\n\nUse this skill for Parallels guest workflows and smoke interpretation. Do not load it for normal repo work.\n\n## Global rules\n\n- Parallels is postpublish-confidence coverage by default, not a prerequisite\n  for the bounded beta-publish phase. Run it against one exact published\n  package version and record the Validation SHA + Tooling SHA run tuple that\n  authorized that package. Validation SHA maps to its Code SHA or Release SHA;\n  it is not a third release identity.\n- A failed postpublish Parallels lane does not retroactively unpublish a beta.\n  Classify it as product, harness\u002Ftooling\u002Fprovenance, infrastructure\u002Fcredential,\n  or wrapper failure. Only a confirmed product defect enters the next beta.\n- Use one coordinator and one lane per independent guest family. Diagnose and\n  retry one failed family once, then reassess; do not restart the aggregate\n  matrix automatically.\n- Inventory existing VMs and snapshots before provisioning anything. When a preconfigured pristine\n  snapshot matches the requested baseline, switch to it and reuse its user, tools, and base setup.\n  Do not create a new VM, reinstall macOS, or rebuild the guest baseline for a \"fresh\" run.\n- \"Fresh\" means restoring the closest existing pristine snapshot, not creating another snapshot.\n  Do not create ad-hoc snapshots unless the user explicitly asks or no suitable baseline exists;\n  restore the original snapshot and leave the guest stopped after an ad-hoc run.\n- Inspect the snapshot state before restoring it. A pristine `poweron` snapshot can contain the\n  preconfigured logged-in session; switch to it normally so Parallels resumes that session. Do not\n  pass `--skip-resume` at test entry unless the run intentionally needs to discard the saved session\n  and boot from the login window. `--skip-resume` is acceptable for final cleanup that must leave the\n  restored source guest stopped.\n- Gateway verification in smoke runs should use `openclaw gateway status --deep --require-rpc` unless the stable version being checked does not support it yet.\n- Stable `2026.3.12` pre-upgrade diagnostics may require a plain `gateway status --deep` fallback.\n- Treat `precheck=latest-ref-fail` on that stable pre-upgrade lane as baseline, not automatically a regression.\n- Pass `--json` for machine-readable summaries.\n- Per-phase logs land under `.artifacts\u002Fparallels\u002Fopenclaw-parallels-*` by default. Override with `OPENCLAW_PARALLELS_ARTIFACT_ROOT` when a run needs another artifact volume.\n- Do not run local and gateway agent turns in parallel on the same fresh workspace or session.\n- Hard-cap every top-level Parallels lane with host `timeout --foreground` (or `gtimeout --foreground` if that is the available binary) so a stalled install, snapshot switch, or `prlctl exec` transport cannot consume the rest of the testing window. Defaults:\n  - macOS: `75m`\n  - Linux: `75m`\n  - Windows: `90m`\n  - aggregate npm-update wrapper: `150m`\n    If a lane hits the cap, stop there, inspect the newest `\u002Ftmp\u002Fopenclaw-parallels-*` run directory and phase log, then fix or rerun the smallest affected lane. Do not keep waiting on a capped lane.\n- Actual OpenClaw npm install\u002Fupdate phases are a stricter signal than whole-lane caps: install phases should normally finish within 7 minutes, and update phases should normally show meaningful progress within 5 minutes. If a phase named `install-main`, `install-latest`, `install-baseline`, or `install-baseline-package` exceeds 420s, or a phase named `update-dev` \u002F same-guest `openclaw update` exceeds 300s without new markers, start diagnosis from that phase log and guest process state. Current Windows update phases can still pass after roughly 10-15 minutes because `doctor --fix` may install bundled plugin runtime deps; keep the script hard cap near 20 minutes unless the log is truly stale.\n- For a full OS matrix, prefer running independent guest-family lanes in parallel when host capacity allows:\n  - `timeout --foreground 75m pnpm test:parallels:macos -- --json`\n  - `timeout --foreground 90m pnpm test:parallels:windows -- --json`\n  - `timeout --foreground 75m pnpm test:parallels:linux -- --json`\n    Keep each lane in its own shell\u002Fsession and track the run directory for each one. Before starting the matrix, run any required host build\u002Fpackage gate to completion. When current-main tgz packaging is needed, the smoke scripts hold a shared package lock through `pnpm build`, inventory\u002Fstaging, and `npm pack`; if that lock is missing or broken, serialize the matrix instead of accepting concurrent `dist` mutation.\n- Do not run multiple smoke lanes against the same guest family at once. Tahoe lanes share the host HTTP port, and Windows\u002FLinux lanes can collide on snapshot restore\u002Fstart state if two jobs touch the same VM concurrently.\n- Do not run the aggregate `pnpm test:parallels:npm-update` wrapper in parallel with individual macOS\u002FWindows\u002FLinux smoke lanes; it touches the same guest families and snapshots.\n- Do not start Parallels lanes while any unrelated host command may rebuild, clean, or restage `dist` (`pnpm build`, `pnpm ui:build`, `pnpm release:check`, `pnpm test:install:smoke`, npm pack\u002Finstall smoke, or Docker lanes that run package\u002Fbuild prep). Run unrelated build\u002Fpackage gates first, let them finish, then start the VM matrix. Concurrent `dist` mutation can make host `npm pack` fail with missing files and wastes a full VM cycle.\n- While running or optimizing the matrix, record wall-clock duration per lane and the slowest phase from `\u002Ftmp\u002Fopenclaw-parallels-*` logs. Use that timing before changing smoke order, timeouts, or helper behavior.\n- If a host build changes tracked generated files, stop before spending VM time. Commit the generated artifact separately or fix the generator drift, then rerun the smallest affected lane.\n- If `main` is moving under active multi-agent work, prefer a detached worktree pinned to one commit for long Parallels suites. The smoke scripts now verify the packed tgz commit instead of live `git rev-parse HEAD`, but a pinned worktree still avoids noisy rebuild\u002Fversion drift during reruns.\n- For `openclaw update --channel dev` lanes, remember the guest clones GitHub `main`, not your local worktree. If a local fix exists but the rerun still fails inside the cloned dev checkout, do not treat that as disproof of the fix until the branch has been pushed.\n- For `prlctl exec`, pass the VM name before `--current-user` (`prlctl exec \"$VM\" --current-user ...`), not the other way around.\n- If the workflow installs OpenClaw from a repo checkout instead of the site installer\u002Fnpm release, finish by installing a real guest CLI shim and verifying it in a fresh guest shell. `pnpm openclaw ...` inside the repo is not enough for handoff parity.\n- On macOS guests, prefer a user-global install plus a stable PATH-visible shim:\n  - install with `NPM_CONFIG_PREFIX=\"$HOME\u002F.npm-global\" npm install -g .`\n  - make sure `~\u002F.local\u002Fbin\u002Fopenclaw` exists or `~\u002F.npm-global\u002Fbin` is on PATH\n  - verify from a brand-new guest shell with `which openclaw` and `openclaw --version`\n\n## npm install then update\n\n- Preferred entrypoint: `pnpm test:parallels:npm-update`\n- For a macOS-only published release update check, use:\n  - `timeout --foreground 75m pnpm test:parallels:npm-update -- --platform macos --package-spec openclaw@\u003Cold-version> --update-target \u003Ctarget-version-or-tag> --json`\n    This keeps the same-guest `openclaw update --tag ...` coverage and uses the shared macOS current-user\u002Fsudo fallback without starting Windows\u002FLinux lanes.\n- Required coverage: every release\u002Fupdate regression run must include both lanes:\n  - fresh snapshot -> install requested package\u002Fbaseline -> smoke\n  - same guest baseline -> run the guest's installed `openclaw update ...` command -> smoke again\n- The update lane must exercise OpenClaw's internal updater. Do not count a direct `npm install -g \u003Ctgz-or-spec>` or harness-side package swap as update-flow coverage; those are install smokes only.\n- For published targets, install the old baseline package first (for example `openclaw@2026.4.9`), then run the installed guest CLI with the intended channel\u002Ftag (for example `openclaw update --channel beta --yes --json`) and verify `openclaw --version`, `openclaw update status --json`, gateway RPC, and an agent turn after the command.\n- For unpublished targets, pack the candidate on the host, serve the `.tgz` over the harness HTTP server, and point the guest updater at that served package. Prefer `openclaw update --tag http:\u002F\u002F\u003Chost-ip>:\u003Cport>\u002Fopenclaw-\u003Cversion>.tgz --yes --json`; when channel persistence also matters, pass `--channel \u003Cstable|beta>` and set `OPENCLAW_UPDATE_PACKAGE_SPEC` to the same served URL in the guest update environment. The command under test must still be `openclaw update`, not direct npm.\n- For unpublished local-fix validation, remember the old baseline updater code still controls the first hop. A fix that lives only in the new updater code cannot change that already-running old process; the served candidate must either keep package\u002Fplugin metadata compatible with the baseline host or the baseline itself must include the updater fix.\n- For beta\u002Fstable verification, resolve the tag immediately before the run (`npm view openclaw@beta version dist.tarball` or `npm view openclaw@latest ...`). Tags can move while a long VM matrix is already running; restart the matrix when the intended prerelease appears after an earlier registry 404\u002Ftag-lag check.\n- Use the configured secret workflow to inject only the provider keys needed by OpenAI\u002FAnthropic lanes. Do not print secrets or env dumps; pass provider secrets through the guest exec environment.\n- Same-guest update verification should set the default model explicitly to `openai\u002Fgpt-5.4` before the agent turn and use a fresh explicit `--session-id` so old session model state does not leak into the check.\n- The aggregate npm-update wrapper must resolve the Linux VM with the same Ubuntu fallback policy as `parallels-linux-smoke.sh` before both fresh and update lanes. Treat any Ubuntu guest with major version `>= 24` as acceptable when the exact default VM is missing, preferring the newest versioned Ubuntu guest with a fresh poweroff snapshot. On Peter's current host today, use `Ubuntu 26.04`.\n- On macOS same-guest update checks, restart the gateway after the npm upgrade before `gateway status` \u002F `agent`; launchd can otherwise report a loaded service while the old process has exited and the fresh process is not RPC-ready yet.\n- The npm-update aggregate's macOS update leg writes the guest update script as root, then runs it as the desktop user. If `prlctl exec \"$MACOS_VM\" --current-user ...` cannot authenticate, retry through plain root `prlctl exec` plus `sudo -u \u003Cdesktop-user> \u002Fusr\u002Fbin\u002Fenv HOME=\u002FUsers\u002F\u003Cdesktop-user> USER=\u003Cdesktop-user> LOGNAME=\u003Cdesktop-user> PATH=\u002Fopt\u002Fhomebrew\u002Fbin:\u002Fopt\u002Fhomebrew\u002Fopt\u002Fnode\u002Fbin:\u002Fusr\u002Fbin:\u002Fbin:\u002Fusr\u002Fsbin:\u002Fsbin ...`. That is a Parallels transport fallback; still verify `openclaw --version`, gateway RPC, and an agent turn after the update.\n- On Windows same-guest update checks, restart the gateway after the npm upgrade before `gateway status` \u002F `agent`; in-place global npm updates can otherwise leave stale hashed `dist\u002F*` module imports alive in the running service.\n- In those Windows same-guest update checks, do not treat one nonzero `openclaw gateway restart` as definitive failure. Current login-item restarts can report failure before the background service becomes observable again; follow with a longer RPC-ready wait and use `gateway start` only as a recovery step if readiness still never returns.\n- After that Windows restart, do not trust one `gateway status --deep --require-rpc` call after a fixed sleep. Retry the RPC-ready probe for roughly 30 seconds and log each attempt; current guests can keep port `18789` bound while the fresh RPC endpoint is still coming up.\n- For Windows same-guest update checks, prefer the done-file\u002Flog-drain PowerShell runner pattern over one long-lived `prlctl exec ... powershell -EncodedCommand ...` transport. The guest can finish successfully while the outer `prlctl exec` still hangs.\n- The Windows same-guest update helper should write stage markers to its log before long steps like tgz download and `npm install -g` so the outer progress monitor does not sit on `waiting for first log line` during healthy but quiet installs.\n- Linux same-guest update verification should also export `HOME=\u002Froot`, pass `OPENAI_API_KEY` via `prlctl exec ... \u002Fusr\u002Fbin\u002Fenv`, and use `openclaw agent --local`; the fresh Linux baseline does not rely on persisted gateway credentials.\n- The npm-update wrapper now prints per-lane progress from the nested log files. If a lane still looks stuck, inspect the nested logs in `runDir` first (`macos-fresh.log`, `windows-fresh.log`, `linux-fresh.log`, `macos-update.log`, `windows-update.log`, `linux-update.log`) instead of assuming the outer wrapper hung.\n- Each run writes both `summary.json` and `summary.md`; read the markdown first for quick human triage, then the JSON\u002Ftimings for automation.\n- For full beta validation after a tag is published, prefer one command:\n  - `timeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta3 --json`\n    This resolves `beta3` to the latest `*-beta.3` version, runs latest->that-version same-guest update coverage, and then runs fresh install smoke for that exact published target on the same selected OS matrix. Use `--platform macos|windows|linux` to narrow reruns.\n- For beta 4 npm validation with agent turns, the known-good shape is:\n  - `gtimeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta4 --model openai\u002Fgpt-5.4 --json`\n    Prefer the explicit `beta4` alias over `openclaw@beta` when validating a specific prerelease number; npm tags can move.\n- If the wrapper fails a lane, read the auto-dumped tail first, then the full nested lane log under `.artifacts\u002Fparallels\u002Fopenclaw-parallels-npm-update.*`.\n- Current known macOS update-lane transport signature when the fallback is missing or bypassed: `Unable to authenticate the user. Make sure that the specified credentials are correct and try again.` Treat that as Parallels current-user authentication before blaming npm or OpenClaw.\n- A macOS packaged fresh install with global package directories or bundled files mode `0777` usually means the harness used the root `prlctl exec` fallback under a permissive umask. The POSIX guest transports should prepend `umask 022`; verify the phase preflight line before blaming npm.\n\n## CLI invocation footgun\n\n- The Parallels smoke shell scripts should tolerate a literal bare `--` arg so `pnpm test:parallels:* -- --json` and similar forwarded invocations work without needing to call `bash scripts\u002Fe2e\u002F...` directly.\n\n## macOS and Windows guest-command transport\n\nThe macOS and Windows smoke and same-guest update lanes route guest commands through\n`scripts\u002Fe2e\u002Fparallels\u002Fparallels-exec.py`; macOS hosts need `python3` with its standard\nlibrary. On verified Parallels 27.0.0 (58628) and 27.0.2 (58673) Apple-silicon installations for macOS guests,\nand 27.1.0 (58756) for Windows guests, the\nclient retains SDK login-job handles through result extraction, avoiding the\nhost CLI's intermittent `PrlJob_GetRetCode: Invalid argument` failure. This error\nis not proof that the guest needs reinstallation or another Tools update.\n\nSelection checks the actual `prlctl` on PATH and the installed CLI digest before\nexecution. Other binaries retain ordinary `prlctl`; an SDK failure never retries\nthrough another transport. Root\u002Fcurrent-user choice, raw shell-argument joining,\nstdin, stdout\u002Fstderr, and guest exit status are preserved. Windows calls pass `--windows`\nto keep the program separate from its raw arguments; POSIX calls retain shell joining.\nCallers still own shell quoting. Bare UUIDs use the CLI's braced lookup form; when that UUID is absent,\nthe client checks the original literal VM name once before any guest execution.\nOther lookup failures are terminal. Snapshot\u002Fstart\u002Fstop\u002Finput\u002Fcapture and\nLinux execution are unchanged.\n\nFor an already-owned, running macOS guest, the same transport can be checked directly:\n\n```bash\npython3 -B scripts\u002Fe2e\u002Fparallels\u002Fparallels-exec.py --timeout-ms 30000 -- exec \"\u003Cowned-macos-vm>\" --current-user \u002Fbin\u002Fecho ready\n```\n\nKeep the outer host timeout for complete lanes; the SDK wait deadline is not proof\nof guest-process termination. This is a bounded workaround, not a supported public\nSDK integration. Revalidate ABI and live command\u002Fstdio\u002Fcleanup behavior before\nadding an installed-binary digest; remove the workaround after a vendor-fixed CLI\nis verified. Restore the original snapshot and stop the guest after ad-hoc proof.\n\n## macOS flow\n\n- Preferred entrypoint: `pnpm test:parallels:macos`\n- `parallels-macos-smoke.sh --mode fresh --target-package-spec openclaw@\u003Cversion>` is an install smoke only. For published old-version -> new-version update coverage on macOS, prefer the npm-update wrapper with `--platform macos`; `parallels-macos-smoke.sh --mode upgrade --target-package-spec ...` installs the target package and does not exercise the baseline CLI's updater.\n- Default upgrade coverage on macOS should now include: fresh snapshot -> site installer pinned to the latest stable tag -> `openclaw update --channel dev` on the guest. Treat this as part of the default Tahoe regression plan, not an optional side quest.\n- `parallels-macos-smoke.sh --mode upgrade` should run that release-to-dev lane by default. Keep the older host-tgz upgrade path only when the caller explicitly passes `--target-package-spec`.\n- Because the default upgrade lane no longer needs a host tgz, skip `npm pack` + host HTTP server startup for `--mode upgrade` unless `--target-package-spec` is set. Keep the pack\u002Fserver path for `fresh` and `both`.\n- If that release-to-dev lane fails with `reason=preflight-no-good-commit` and repeated `sh: pnpm: command not found` tails from `preflight build`, treat it as an updater regression first. The fix belongs in the git\u002Fdev updater bootstrap path, not in Parallels retry logic.\n- Until the public stable train includes that updater bootstrap fix, the macOS release-to-dev lane may seed a temporary guest-local `pnpm` shim immediately before `openclaw update --channel dev`. Keep that workaround scoped to the smoke harness and remove it once the latest stable no longer needs it.\n- In Tahoe `prlctl exec --current-user` runs, prefer explicit `node ...\u002Fopenclaw.mjs ...` invocations for the release->dev handoff itself and for post-update verification. The shebanged global `openclaw` wrapper can fail with `env: node: No such file or directory`, and self-updating through the wrapper is a weaker lane than invoking the entrypoint under a fixed `node`.\n- Default to the snapshot closest to `macOS 26.5 latest`.\n- On Peter's Tahoe VM, `fresh-latest-march-2026` can hang in `prlctl snapshot-switch`; if restore times out there, rerun with `--snapshot-hint 'macOS 26.5 latest'` before blaming auth or the harness.\n- `parallels-macos-smoke.sh` now retries `snapshot-switch` once after force-stopping a stuck running\u002Fsuspended guest. If Tahoe still times out after that recovery path, then treat it as a real Parallels\u002Fhost issue and rerun manually.\n- The macOS smoke should include a dashboard load phase after gateway health: resolve the tokenized URL with `openclaw dashboard --no-open`, verify the served HTML contains the Control UI title\u002Froot shell, then open Safari and require an established localhost TCP connection from Safari to the gateway port.\n- For Tahoe `fresh.gateway-status`, prefer non-TTY `prlctl exec --current-user ... openclaw gateway status ...` plus a few short retries. `prlctl enter` can spam TTY control bytes and hang the phase log even when the CLI itself is healthy.\n- If a Tahoe lane times out in `fresh.first-agent-turn` and the phase log stops right after `__OPENCLAW_RC__:0` from `models set`, suspect the `prlctl enter` \u002F `expect` wrapper before blaming auth or the model lane. That pattern means the first guest command finished but the transport never released for the next `guest_current_user_cli` call.\n- If a packaged install regresses with `500` on `\u002F`, `\u002Fhealthz`, or `__openclaw\u002Fcontrol-ui-config.json` after `fresh.install-main` or `upgrade.install-main`, suspect bundled plugin runtime deps resolving from the package root `node_modules` rather than `dist\u002Fextensions\u002F*\u002Fnode_modules`. Repro quickly with a real `npm pack`\u002Fglobal install lane before blaming dashboard auth or Safari.\n- `prlctl exec` is fine for deterministic repo commands, but use the guest Terminal or `prlctl enter` when installer parity or shell-sensitive behavior matters.\n- Multi-word `openclaw agent --message ...` checks should go through a guest shell wrapper (`guest_current_user_sh` \u002F `guest_current_user_cli` or `\u002Fbin\u002Fsh -lc ...`), not raw `prlctl exec ... node openclaw.mjs ...`, or the message can be split into extra argv tokens and Commander reports `too many arguments for 'agent'`.\n- The same wrapper rule applies when bypassing `--current-user`: write a tiny `\u002Ftmp\u002F*.sh` on the guest and execute `\u002Fbin\u002Fbash \u002Ftmp\u002F*.sh` through the sudo desktop-user environment. Do not pass `openclaw agent --message '...'` directly as one raw `prlctl exec` command.\n- When ref-mode onboarding stores `OPENAI_API_KEY` as an env secret ref, the post-onboard agent verification should also export `OPENAI_API_KEY` for the guest command. The gateway can still reject with pairing-required and fall back to embedded execution, and that fallback needs the env-backed credential available in the shell.\n- On the fresh Tahoe snapshot, `brew` exists but `node` may be missing from PATH in noninteractive exec. Use `\u002Fopt\u002Fhomebrew\u002Fbin\u002Fnode` when needed.\n- Fresh host-served tgz installs should install as guest root with `HOME=\u002Fvar\u002Froot`, then run onboarding as the desktop user via `prlctl exec --current-user`.\n- Root-installed tgz smoke can log plugin blocks for world-writable `extensions\u002F*`; do not treat that as an onboarding or gateway failure unless plugin loading is the task.\n\n## Windows flow\n\n- This repo owns the general Windows VM lifecycle: remote `prlctl` management, clean-state checks, WSL 2, Git\u002FNode, snapshot creation\u002Frestoration, and OpenClaw smoke. Assume Parallels Desktop is installed\u002Factivated and a Windows 11 VM has been downloaded, then run:\n\n  ```bash\n  pnpm test:parallels:windows:prepare -- inventory\n  pnpm test:parallels:windows:prepare -- prepare\n  pnpm test:parallels:windows:prepare -- verify\n  ```\n\n- `prepare` inventories before mutation, requires Parallels Tools and a logged-in desktop session, rejects OpenClaw CLI\u002Fapp\u002Ftray\u002Fprocess state and WSL distros, creates a dated power-off clean-OS snapshot only on an unprepared guest, enables WSL\u002FVirtual Machine Platform, installs the signed Microsoft WSL package, sets WSL 2 as default, installs Git, Node\u002Fnpm, and the native addons' Visual C++ runtime, verifies the Windows hypervisor is active and no reboot is pending, and creates a power-off `pre-openclaw-native-e2e-\u003Cdate>` snapshot. Existing baselines without `vcruntime140.dll` fail verification; prepare a new baseline name to upgrade them.\n- When today's E2E snapshot already exists, `prepare` restores and verifies that snapshot instead of trusting its name. Treat `prepare` as destructive to post-snapshot guest changes, just like an explicit restore.\n- Package elevation resolves the exact version and SHA-256 from Microsoft's official WinGet manifests, validates the expected Authenticode publisher, and copies into a freshly ACL-restricted SYSTEM directory before execution. Keep this generic mechanism here; companion-specific package choices stay in the Windows app repo.\n- Restore `clean`, `e2e`, an exact name, or an id:\n\n  ```bash\n  pnpm test:parallels:windows:prepare -- restore --snapshot e2e\n  ```\n\n- Restoring discards all post-snapshot changes. Inventory first and do not restore while another developer or lane owns the VM. `e2e` selects the newest `pre-openclaw-native-e2e-*`; use an exact snapshot for historical reproduction.\n- For native companion work, read `..\u002F..\u002F..\u002F..\u002Fopenclaw-windows-node\u002F.agents\u002Fskills\u002Fopenclaw-proof-validation\u002FPARALLELS.md`. That optional macOS sidecar reuses this controller and adds only .NET, Windows SDK, WebView2, the app checkout, app-layer snapshots, build\u002Ftests, and native proof.\n- Preferred entrypoint: `pnpm test:parallels:windows`\n- Use the newest verified `pre-openclaw-native-e2e-*` snapshot and pass its exact name with `--snapshot-hint`.\n- Default upgrade coverage on Windows should now include: fresh snapshot -> site installer pinned to the requested stable tag -> `openclaw update --channel dev` on the guest. Keep the older host-tgz upgrade path only when the caller explicitly passes `--target-package-spec`.\n- Optional exact npm-tag baseline on Windows: `bash scripts\u002Fe2e\u002Fparallels-windows-smoke.sh --mode upgrade --target-package-spec openclaw@\u003Ctag> --json`. That lane installs the published npm tarball as baseline, then runs `openclaw update --channel dev`.\n- Optional forward-fix Windows validation: `bash scripts\u002Fe2e\u002Fparallels-windows-smoke.sh --mode upgrade --upgrade-from-packed-main --json`. That lane installs the packed current-main npm tgz as baseline, then runs `openclaw update --channel dev`.\n- Always use `prlctl exec --current-user`; plain `prlctl exec` lands in `NT AUTHORITY\\\\SYSTEM`.\n- Prefer explicit `npm.cmd` and `openclaw.cmd`.\n- Use PowerShell only as the transport with `-ExecutionPolicy Bypass`, then call the `.cmd` shims from inside it.\n- Current Windows Node installs expose `corepack` as a `.cmd` shim. If a release-to-dev lane sees `corepack` on PATH but `openclaw update --channel dev` still behaves as if corepack is missing, treat that as an exec-shim regression first.\n- If an exact published-tag Windows lane fails during preflight with `npm run build` and `'pnpm' is not recognized`, remember that the guest is still executing the old published updater. Validate the fix with `--upgrade-from-packed-main`, then wait for the next tagged npm release before expecting the historical tag lane to pass.\n- Multi-word `openclaw agent --message ...` checks should call `& $openclaw ...` inside PowerShell, not `Start-Process ... -ArgumentList` against `openclaw.cmd`, or Commander can see split argv and throw `too many arguments for 'agent'`.\n- Windows installer\u002Ftgz phases now retry once after guest-ready recheck; keep new Windows smoke steps idempotent so a transport-flake retry is safe.\n- If a Windows retry sees the VM become `suspended` or `stopped`, resume\u002Fstart it before the next `prlctl exec`; otherwise the second attempt just repeats the same `rc=255`.\n- Windows global `npm install -g` phases can stay quiet for a minute or more even when healthy; inspect the phase log before calling it hung, and only treat it as a regression once the retry wrapper or timeout trips.\n- When those Windows global installs stay quiet, the useful progress often lives in the guest npm debug log, not the helper phase log. The smoke script now streams incremental `npm-cache\u002F_logs\u002F*-debug-0.log` deltas into the phase log during long baseline\u002Fpackage installs; read those lines before assuming the lane is stalled.\n- The Windows baseline-package helpers now auto-dump the latest guest `npm-cache\u002F_logs\u002F*-debug-0.log` tail on timeout or nonzero completion. Read that tail in the phase log before opening a second guest shell.\n- The same incremental npm-debug streaming also applies to `--upgrade-from-packed-main` \u002F packaged-install baseline phases. A phase log that still says only `install.start`, `install.download-tgz`, `install.install-tgz` can still be healthy if the streamed npm-debug section shows registry fetches or bundled-plugin postinstall work.\n- Fresh Windows tgz install phases should also use the background PowerShell runner plus done-file\u002Flog-drain pattern; do not rely on one long-lived `prlctl exec ... powershell ... npm install -g` transport for package installs.\n- Windows release-to-dev helpers may log `where pnpm` diagnostically. The updater deliberately bootstraps a temporary pinned pnpm and cleans it up; permanent pnpm availability is not a post-update requirement. Require the installed OpenClaw CLI to resolve in a fresh shell using persisted Machine + User PATH.\n- Keep the CLI update deadline inside the Windows phase envelope, with separate setup\u002Freporting and cleanup allowances. If setup consumes the command's reserved budget, refuse before launching the updater. Verify version, status, and fresh-shell CLI in the subsequent verification phase; retain the top-level host hard cap.\n- Fresh Windows ref-mode onboard should use the same background PowerShell runner plus done-file\u002Flog-drain pattern as the npm-update helper, including startup materialization checks, host-side timeouts on short poll `prlctl exec` calls, and retry-on-poll-failure behavior for transient transport flakes.\n- Fresh Windows daemon-health reachability should use `openclaw gateway probe --json` with a longer timeout and treat `ok: true` as success; full `gateway status --require-rpc` checks are too eager during initial startup on current main.\n- Fresh Windows ref-mode agent verification should set `OPENAI_API_KEY` in the PowerShell environment before invoking `openclaw.cmd agent`, for the same pairing-required fallback reason as macOS.\n- The standalone Windows upgrade smoke lane should stop the managed gateway after `upgrade.install-main` and before `upgrade.onboard-ref`. Restarting before onboard can leave the old process alive on the pre-onboard token while onboard rewrites `~\u002F.openclaw\u002Fopenclaw.json`, which then fails `gateway-health` with `unauthorized: gateway token mismatch`.\n- If standalone Windows upgrade fails with a gateway token mismatch but `pnpm test:parallels:npm-update` passes, trust the mismatch as a standalone ref-onboard ordering bug first; the npm-update helper does not re-run ref-mode onboard on the same guest.\n- Keep onboarding and status output ASCII-clean in logs; fancy punctuation becomes mojibake in current capture paths.\n- If you hit an older run with `rc=255` plus an empty `fresh.install-main.log` or `upgrade.install-main.log`, treat it as a likely `prlctl exec` transport drop after guest start-up, not immediate proof of an npm\u002Fpackage failure.\n- If WSL features are enabled but `wsl.exe --version` fails, rerun `prepare`; the inbox features and the signed WSL package are separate prerequisites. If the default reverts to 1, set `wsl.exe --set-default-version 2` and rerun `verify`.\n- If `winget` detaches or prints nothing over `prlctl`, call it through `cmd.exe \u002Fd \u002Fs \u002Fc`. Avoid remote UAC: download as the desktop user, then let the controller verify the trusted manifest hash\u002Fpublisher and install from its protected SYSTEM staging directory.\n- If snapshot restore reports incompatible saved CPU state, make a power-off replacement snapshot from the known-good disk state and use its exact name. Never bypass snapshot restore for a two-lane fresh+upgrade claim.\n- If baseline verification reports OpenClaw state, restore `clean` or remove the product state deliberately; never bless a dirty guest. Check `%APPDATA%` and `%LOCALAPPDATA%` for both stable and dev companion identities plus Inno uninstall registration.\n- Long Windows installers can remain quiet while healthy. Inspect `tasklist` and installer\u002FMSI logs before declaring a hang; keep long operations behind a background runner with short host-bounded polling calls.\n\n## Linux flow\n\n- Preferred entrypoint: `pnpm test:parallels:linux`\n- Use the newest versioned Ubuntu guest with a fresh poweroff snapshot. On Peter's host today, that is `Ubuntu 26.04`.\n- If an exact requested Ubuntu VM is missing on the host, any Ubuntu guest with major version `>= 24` is acceptable; prefer the newest versioned Ubuntu guest over older fallback snapshots.\n- Use plain `prlctl exec`; `--current-user` is not the right transport on this snapshot.\n- 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`.\n- Fresh `main` tgz smoke still needs the latest-release installer first because the snapshot has no Node or npm before bootstrap.\n- This snapshot does not have a usable `systemd --user` session; managed daemon install is unsupported.\n- The Linux smoke now falls back to a manual `setsid openclaw gateway run --bind loopback --port 18789 --force` launch with `HOME=\u002Froot` and the provider secret exported, then verifies `gateway status --deep --require-rpc` when available.\n- The Linux manual gateway launch should wait for `gateway status --deep --require-rpc` inside the `gateway-start` phase; otherwise the first status probe can race the background bind and fail a healthy lane.\n- If Linux gateway bring-up fails, inspect `\u002Ftmp\u002Fopenclaw-parallels-linux-gateway.log` in the guest phase logs first; the common failure mode is a missing provider secret in the launched gateway environment.\n\n## Discord roundtrip\n\n- Discord roundtrip is optional and should be enabled with:\n  - `--discord-token-env`\n  - `--discord-guild-id`\n  - `--discord-channel-id`\n- After a successful Discord smoke\u002Froundtrip, shut down the guest VM before handoff (`prlctl stop \"$VM_NAME\"` or the concrete VM name). The macOS smoke harness should do this automatically after successful Discord proof; still stop the VM manually after ad-hoc Discord checks. Do not leave the Discord-configured guest running; it can keep reading\u002Fposting in `#maintainer` and spam Discord after the proof is complete.\n- Keep the Discord token only in a host env var.\n- Use installed `openclaw message send\u002Fread`, not `node openclaw.mjs message ...`.\n- Set `channels.discord.guilds` as one JSON object, not dotted config paths with snowflakes.\n- Avoid long `prlctl enter` or expect-driven Discord config scripts; prefer `prlctl exec --current-user \u002Fbin\u002Fsh -lc ...` with short commands.\n- For a narrower macOS-only Discord proof run, the existing `parallels-discord-roundtrip` skill is the deep-dive companion.\n",{"name":5,"description":7},"main","50efbfdd14775fb9b84cf2b98dc75840e678040a",".agents\u002Fskills\u002Fopenclaw-parallels-smoke",82862,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw","https:\u002F\u002Fopenclaw.ai","https:\u002F\u002Fgithub.com\u002Fopenclaw","Your personal, open source AI assistant.","2026-11-11 08:46:30",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add openclaw\u002Fopenclaw --skill openclaw-parallels-smoke",{"tool":53,"command":54},"bunx","bunx skills add openclaw\u002Fopenclaw --skill openclaw-parallels-smoke",{"tool":56,"command":57},"pnpm","pnpm dlx skills add openclaw\u002Fopenclaw --skill openclaw-parallels-smoke","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenclaw-parallels-smoke\u002FSKILL.md",true,[],[62,68,90,108,130,154],{"skillNo":63,"name":64,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":33},"01M698VP84FNM6G9MR1HPX7MF7","lobster","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Flobster\u002FSKILL.md",[],[64],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":33},"01M698YY8QGQ7S8TJNKJG6VTPH","xurl","xurl CLI for authenticated X posts, replies, reads\u002Fsearch, DMs, media upload, followers, auth status, or raw v2 API calls.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Fxurl\u002FSKILL.md",[],[70,75,76,77,78,79,80,81,28,82,83,84,85,86,87,88,89],"for","api","calls","replies","posts","upload","tap","brew","node","Media","search","npm","status","auth","cli",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":33},"01M698YWT1CJ0WK88WB909R9RT","weather","Current weather and forecasts with web_fetch, falling back to wttr.in curl for locations, rain, temperature, travel planning.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Fweather\u002FSKILL.md",[],[92,97,98,28,99,82,100,101,102,103,104,105,75,106,107],"travel planning","travel","fetch","curl","https","help","planning","web","back","temperature","with",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":119,"publishedAt":33},"01M698YV2Q0R0JJKAWGFS21K0N","visualize","Create inline visuals for code and explanations, or author persistent OpenClaw dashboard widgets with show_widget.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Fvisualize\u002FSKILL.md",[114],{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[110,120,121,122,123,75,107,124,125,126,127,128,9,129],"widgets","openclaw dashboard","author","inline","show","code","create","visuals","dashboard","widget",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":144,"publishedAt":33},"01M698YS2TRJH9ENG28HD9CD87","trello","Manage Trello boards, lists, and cards via the Trello REST API.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Ftrello\u002FSKILL.md",[136,141],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":142,"categoryName":143,"taxonomyType":117,"taxonomyTypeDesc":118},"01JBSEEDCAT000000000000030","开发工程师",[132,101,145,146,147,148,149,150,28,82,151,100,76,152,153],"cloud","manage","via","rest api","token","atlassian","jq","REST","developer",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":33},"01M698YQ9Q3M4W78EWV2KSCSVW","tmux","Control tmux sessions\u002Fpanes for interactive CLIs: list, capture output, send keys, paste text, monitor prompts.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Ftmux\u002FSKILL.md",[],[156,28,161,162,75,163,164,165,166,167,168,169,82,170,171,172,173,174,21],"send","darwin","keys","paste","output","control","prompts","interactive","list","capture","panes","text","monitor","sessions"]