Delx Ops Guardian

Automatically detects, assesses, and safely mitigates incidents in OpenClaw production agents, providing detailed reports and verified recovery.

Security Scan

The skill's runbook is largely coherent with an incident-response tool, but it implicitly requires privileged system access (service restarts, reading /root paths) while declaring no required permissions and relies on human-approval only in prose — this mismatch and the risk of autonomous invocation make it worth caution.

Purpose & Capability

The name, description, and allowed actions (checking cron, service status, logs, and performing limited restarts/cron adjustments) align with an on‑system incident-response runbook. However, the runbook expects access to systemctl, journalctl, and /root/.openclaw workspace paths — i.e., elevated system privileges — yet the skill declares no required credentials or permissions. That mismatch is noteworthy: the capability legitimately needs host-level privileges but the metadata doesn't state or limit that requirement.

Instruction Scope

SKILL.md stays within a narrow incident-response scope: detect/classify, collect evidence, propose small remediations from an explicit safe set, require human approval for higher-risk actions, verify stabilization, and publish a report. It does not instruct exfiltration or remote calls to unknown endpoints. The allowed read sources and remediation actions are spelled out and constrained.

Install Mechanism

No install spec and no code files: this is instruction-only, so nothing will be downloaded or written to disk by the skill itself. That reduces install-time risk.

Credentials

The skill does not request API keys, tokens, or environment variables — which is appropriate for an on-host runbook. But it does rely on access to system-level commands and paths (systemctl, journalctl, /root/.openclaw). Those are sensitive resources (potentially containing secrets or affecting other services). The absence of declared required privileges or an explicit statement that the agent will run with limited, audited sudo rights is a gap.

Persistence & Privilege

always:false (good) and disable-model-invocation:false (default). The SKILL.md requires human approval for many actions, but this is a soft constraint in prose — nothing in the metadata enforces human-in-the-loop at platform level. Because the skill's allowed actions include restarting services and disabling cron jobs, autonomous invocation by a model (or misuse) could have disruptive effects if platform-level approval gates are not enforced. Recommend platform enforcement of approval steps and restricting execution to trusted admins.

What to consider before installing

This skill reads system status and logs and can restart services; that requires host-level privileges (and may access /root/.openclaw). Before installing: 1) Verify you intend to grant the agent the required host permissions and limit them (scoped sudo or dedicated service account). 2) Ensure the platform enforces the human-approval steps the runbook requires (don’t rely on prose alone). 3) Confirm the workspace paths do not contain secrets and that logs are redacted. 4) Test the skill in a staging environment and restrict invocation to trusted operators. If you cannot guarantee platform-level approval enforcement or tight privilege scoping, treat this skill as risky.

name: delx-ops-guardian summary: Incident handling and operational recovery guardrails for OpenClaw production agents. owner: davidmosiah status: active

Use this skill when handling incidents, degraded automations, or gateway/memory instability in production.

Aliases

• emergency_recovery
• handle_incident
• cron_guard
• memory_guard
• gateway_guard

Scope (strict)

This skill is runbook-only and must operate under least privilege.

Allowed read sources:

• OpenClaw cron state (openclaw cron list --json)
• Service health/status (systemctl is-active <service>)
• Recent logs for incident window (journalctl -u <service> --since ... --no-pager)
• Workspace incident artifacts (/root/.openclaw/workspace/docs/ops/, /root/.openclaw/workspace/memory/)

Allowed remediation actions (safe set):

1. Retry a failed job once when failure is transient.
2. Controlled restart of the impacted service only (openclaw-gateway, openclaw, or explicitly named target from incident evidence).
3. Disable/enable only the directly impacted cron job when loop-failing.
4. Add/adjust guardrails in runbook/config docs (non-secret, reversible).

Disallowed actions:

• No credential rotation/deletion.
• No firewall/network policy mutations.
• No package installs/upgrades during incident handling.
• No bulk cron rewrites unrelated to the incident.
• No edits to unrelated services/components.

Approval policy (human-in-the-loop)

Require explicit human approval before:

• Restarting any production service more than once.
• Editing cron schedules/timezones.
• Disabling a job for more than one cycle.
• Any action with user-visible impact beyond the failing component.

Core workflow

1. Detect and classify severity (info, degraded, critical).
2. Collect evidence first (status, logs, last run, error streak).
3. Propose smallest remediation from allowed set.
4. Execute only approved/safe remediation.
5. Verify stabilization window (at least one successful cycle).
6. Publish concise incident report.

Safety rules

• Never hide persistent failures as success.
• Never expose secrets/tokens in logs or reports.
• Prefer reversible actions and document rollback path.
• Keep blast radius minimal and explicitly stated.

Output contract

Always include:

• Incident id/time window
• Root signal and blast radius
• Actions executed (and approvals)
• Evidence (status, key metric, short log excerpt)
• Final state (resolved, degraded, open)
• Next check time

Example intents

• "Gateway is flapping, recover safely."
• "Cron timed out, stabilize and prove fix."
• "Memory guard firing repeatedly, root-cause and patch."