Skip to content
cccskills
FreePublished on GitHub

ocm-operator

OCM/OpenClaw envs: create, clone, upgrade, runtimes, services, logs, cleanup.

The English summary is being prepared. Showing the original description.

See how to install

Files included (5)

  • SKILL.md4.3 KB
  • agents/openai.yaml271 B
  • references/command-cookbook.md5.2 KB
  • references/local-paths.md2.0 KB
  • references/safety-and-state.md3.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

OCM Operator

Operating Model

Use OCM as the control plane for OpenClaw. Treat an OCM environment as the isolation boundary: it owns OPENCLAW_HOME, state, config, workspace, gateway port, runtime/launcher binding, and service policy.

Prefer OCM commands over raw OpenClaw commands whenever the task touches:

  • env creation, cloning, migration, export/import, snapshots, or cleanup
  • runtime install/build/verify/update/remove
  • upgrades or release testing
  • background gateway services
  • logs, status, TUI/dashboard, plugin checks, model checks

Run OpenClaw inside an env with:

ocm @<env> -- <openclaw args>

Use ocm env exec <env> -- <command> only when you need a non-OpenClaw command inside the env, such as env, node, or shell tooling.

First Steps

  1. Inspect current state before changing it:
ocm env list
ocm service status
ocm runtime list
  1. Read help for the exact surface before using unfamiliar flags:
ocm help start
ocm help env
ocm help runtime
ocm help service
ocm help logs
ocm help upgrade
  1. For detailed command patterns, read references/command-cookbook.md.

  2. For destructive operations, service boundaries, or real user state, read references/safety-and-state.md before acting.

  3. For this machine's common paths and release-test defaults, read references/local-paths.md.

Decision Guide

  • Start a normal runtime-backed env: use ocm start <env> --runtime <runtime> or ocm start <env> --version <version>.
  • Start a fresh user env: use ocm start <env> --runtime <runtime> first; use --onboard only when testing interactive onboarding specifically.
  • Use source-backed OpenClaw development: use ocm dev <env> --repo <repo>. Do not use this as proof of release packaging.
  • Test release behavior from local OpenClaw source: use ocm runtime build-local <runtime> --repo <repo> --force, then test envs against that runtime.
  • Test existing-user upgrade behavior: clone the existing env, upgrade the clone, and never mutate the source env directly.
  • Run OpenClaw commands in an env: use ocm @<env> -- ....
  • Read logs: use ocm logs <env>.
  • Manage background gateway state: use ocm service status/start/stop/restart.
  • Clean up: use ocm env destroy <env> --yes; this removes env snapshots, OCM service policy, and OCM-created dev worktrees.

Safety Rules

  • Treat important user envs such as Violet and Shaks as durable state. Clone first for testing unless the user explicitly asks to mutate them.
  • Remove envs with ocm env destroy.
  • Manage OCM env gateway lifecycle with ocm service.
  • Remember OCM injects OPENCLAW_SERVICE_REPAIR_POLICY=external for env-run OpenClaw processes, so openclaw doctor --fix should repair normal env state but skip OpenClaw-owned service lifecycle repair.
  • Do not treat ocm dev, pnpm openclaw, or a source worktree as release validation. For release behavior, build and use a package runtime.
  • Clean up temporary envs, services, worktrees, tarballs, and retained simulation envs.
  • If a command could change real user data, run read-only inspection or clone first, then report the exact command you plan to run if there is ambiguity.

Verification Standard

Finish by exercising the relevant command path. Prefer these checks:

ocm env list
ocm service status <env>
ocm logs <env> --tail 100
ocm @<env> -- --version
ocm @<env> -- status
ocm @<env> -- doctor --fix

Add plugin/model/TUI checks when the task touches plugins, model auth/catalog, onboarding, or gateway connectivity:

ocm @<env> -- plugins list
ocm @<env> -- plugins update --all --dry-run
ocm @<env> -- models list
ocm @<env> -- tui

Reporting

Keep reports quiet and useful:

  • lead with pass/fail/blocker status
  • include the exact command for failures
  • include concise evidence for passes
  • separate OCM issues from OpenClaw runtime/package issues
  • say which relevant checks were skipped
  • include cleanup performed

Use this failure shape:

Failure:
- Command: `<exact command>`
- Expected: <expected state>
- Actual: <observed state/output>
- Impact: <why it matters>
- Likely owner: OCM | OpenClaw | test setup | external dependency
- Paste to fixer: <short actionable summary>

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use the Crabbox wrapper for OpenClaw remote validation across Linux, macOS, Windows, and WSL2, including delegated Blacksmith Testbox proof. Report the actual provider and id.

The English summary is being prepared. Showing the original description.

openclaw/Kova11Updated Oct 19, 2026

Kova/OpenClaw validation: benchmarks, release gates, scenarios, perf reports.

The English summary is being prepared. Showing the original description.

openclaw/Kova11Updated Oct 19, 2026

See all skills by openclaw

Report a problem with this skill