OpenClaw OA Operator

Install, configure, operate, and productize OA monitoring and self-heal workflows for OpenClaw workspaces. Use when Codex needs to set up or repair `oa-cli`,...

Security Scan

The skill's instructions and bundled smoke-test script match the described OA operator purpose, but the package metadata omits required runtime binaries (oa, curl) and so the skill's declared requirements are inconsistent with what it actually needs.

Purpose & Capability

The skill's name, description, SKILL.md, and included references all describe OA operations, dashboard refinement, and packaging guidance — that aligns with the files and script. However, the registry metadata declares no required binaries or env vars while the smoke-test script and docs explicitly require the 'oa' CLI and 'curl', which is an incoherence between claimed requirements and actual runtime needs.

Instruction Scope

SKILL.md stays within the stated purpose: it directs the agent to inspect workspace files (config.yaml, self_heal_rules.yaml, scripts/), run verification (oa collect, oa serve), interpret metrics, and prepare packaging. The instructions do not ask the agent to read unrelated system secrets or transmit data to unexpected external endpoints. They do recommend screenshots and local verification, which can expose private data if not handled carefully, but the docs explicitly warn to scrub before publishing.

Install Mechanism

There is no install spec (instruction-only plus a helper script), so nothing is downloaded or written by an installer. This is low-risk for arbitrary code retrieval. The only executable content is the provided shell script, which runs local commands.

Credentials

The skill declares no required environment variables or credentials, and the SKILL.md likewise doesn't request secrets. However, the smoke-test script relies on the 'oa' CLI, whose configuration (config.yaml) may reference external endpoints, credentials, or paths; users should verify those workspace configs for secrets or remote credentials before running. The metadata omission of required binaries (oa, curl) is the primary proportionality mismatch.

Persistence & Privilege

The skill is not always-enabled, does not request elevated or persistent system-wide privileges, and contains no install step that modifies other skills or global agent settings. Autonomous invocation is allowed (platform default) and is not combined with other privilege red flags.

What to consider before installing

This skill appears to be what it claims (an operator for OA) and contains a harmless smoke-test script, but metadata mismatches mean you should be cautious before running it. Before installing or invoking: 1) Verify the 'oa' CLI and 'curl' are present (the package metadata does not list them but the script and docs require them). 2) Inspect the workspace files referenced (config.yaml, self_heal_rules.yaml, any scripts/ or patches/) for embedded credentials, absolute paths, or external endpoints that could be contacted when 'oa collect' runs. 3) Run the smoke test in an isolated or staging environment first (it runs oa collect and queries localhost API endpoints). 4) If you plan to publish or give the skill broader access, update the skill metadata to declare required binaries and any env vars, and follow the release-readiness guidance to scrub machine-specific data. If you want me to, I can list the exact commands to check the workspace files for secrets or run the smoke test safely in a container.

Use this skill to operate OA as an observability and self-heal layer for OpenClaw. Focus on stable workflows, explain what the data means, and keep public packaging separate from machine-specific local setup.

Quick Start

• Inspect the workspace for config.yaml, self_heal_rules.yaml, scripts/, patches/, pipelines/, and any dashboard override such as dashboard-zh/.
• Determine whether the user wants local operations, dashboard refinement, or publishable packaging. Do not switch UI structure without explicit approval once the user picks a preferred layout.
• Prefer the simplest stable path: use upstream OA behavior unless the workspace already carries justified overrides.
• Run the smallest useful verification after each meaningful change: API check, script smoke check, or dashboard screenshot.
• Use scripts/oa_workspace_smoke_test.sh for a minimal end-to-end workspace check when OA is already configured.

Operate OA Locally

1. Confirm the current OA surface. Use existing workspace scripts first if present, especially wrappers such as scripts/start_oa_server.sh, scripts/stop_oa_server.sh, and scripts/manage_oa_launchd.sh.
2. Verify the runtime before editing UI. Check that oa collect can populate data and that oa serve exposes the expected endpoints before diagnosing the dashboard.
3. Treat configuration files as policy. Read config.yaml for goals, thresholds, OpenClaw path, and agent scope. Read self_heal_rules.yaml before changing remediation behavior.
4. Keep verification concrete. Validate /api/health, /api/goals, /api/team-health, /api/traces, and any self-heal endpoints used by the current dashboard.

Interpret Metrics And Self-Heal State

• Explain G1 and G2 first because they are usually the most stable built-ins: cron reliability and team health.
• Explain custom goals only after confirming their pipelines and metric sources exist in the workspace.
• Distinguish clearly between:
  • signal quality issues
  • pipeline failures
  • dashboard rendering issues
  • self-heal policy breaches
• For self-heal work, preserve the loop:
  • detect
  • fix
  • verify
  • learn
• Before running command-mode fixers, inspect the concrete command template, placeholders, and target paths. Prefer non-destructive fixers and keep fallback ticketing enabled when available.

Refine Dashboards Safely

• Preserve the user's chosen layout once they say a version is clearer. Improve copy, density, and data mapping before changing structure.
• Prefer upstream OA layout when the user values clarity and comparability to the original repository.
• Use project-level overrides only when there is a clear need for localization, extra tabs, or richer diagnostics.
• After UI edits, verify both desktop and mobile views with real screenshots instead of assuming the layout works.

Package For ClawHub

• Prefer a skill when the value is workflow knowledge: install OA, operate it, interpret metrics, and guide self-heal decisions.
• Prefer a plugin when the value is a long-running service, HTTP routes, background workers, or a productized dashboard experience.
• Remove machine-specific defaults before public packaging:
  • absolute paths
  • local ports and launchd labels
  • local agent rosters
  • user-specific ticket directories
  • local backup and artifact paths
• Package reusable instructions, checklists, and safe defaults. Do not package private workspace snapshots as public examples.
• Read references/release-readiness.md before preparing a public release.
• Read references/smoke-test.md before claiming the package is publish-ready.

Deliverables

• For local operations, report what changed, how it was verified, and what remains risky.
• For release preparation, produce:
  • a public versus private diff
  • a publish-readiness checklist
  • proposed listing copy
  • a recommendation of skill versus plugin