OpenClaw Skills: Give agents the tools to operate the stack #180
Description
Context
OpenClaw instances today are smart but blind — they have LLM inference but no structured way to interact with the stack they're running on. Skills bridge this gap by giving agents typed, permissioned tools to observe and act on infrastructure.
The existing architecture already has the right security boundaries:
- OpenClaw pods have read-only RBAC in their own namespace
- Obol Agent SA (
agentnamespace) has admin RBAC in every network namespace - Skills are dynamically loaded via ConfigMap (
obol openclaw skills sync)
What's missing is the actual skill implementations.
Planned Skills
P0 — obol-rpc
Blockchain RPC via eRPC — eth_blockNumber, eth_getBalance, eth_call, eth_getLogs, chain ID detection, etc.
OpenClaw already sees ERPC_URL as an env var. This skill wraps it into structured tool calls so the agent doesn't need to hand-craft JSON-RPC payloads. It's the foundation — an agent that can't read chain state can't do anything useful with the networks it's running.
P1 — obol-k8s
Kubernetes situational awareness — get pods, read logs, list events, describe resources, list namespaces.
Uses the OpenClaw ServiceAccount token (already has read-only RBAC when serviceAccount.automount: true). This is the agent's eyes into its own environment — "what's running, what's healthy, what just happened."
The Obol Agent SA already has cluster-wide read + per-namespace admin. For elevated operations (see P2 below), skills can use the agent SA instead of the OpenClaw SA, keeping the privilege boundary clear.
P1 — ethereum-wingman
Higher-level Ethereum tools — contract interaction, ENS resolution, token balances, gas estimation, transaction building.
Built on top of obol-rpc but at a higher abstraction layer. External reference: https://ethwingman.com/. This is where agents start creating value — reading contract state, monitoring positions, preparing transactions.
P2 — obol-network
Network lifecycle management — list available/installed networks, install new ones, sync deployments, delete them.
Wraps the obol network CLI operations. This is the first write-path skill — an agent that can provision its own blockchain infrastructure. Requires elevated permissions (Obol Agent SA or equivalent).
P2 — obol-monitoring
Health checks and metrics — query Prometheus for pod health, resource usage, network sync progress, alerting thresholds.
The Prometheus stack (monitoring namespace) is already deployed. This skill gives agents quantitative observability rather than just "list pods" — CPU/memory trends, sync percentages, error rates.
P3 — obol-spawn (self-replication)
Spawn new OpenClaw instances from within OpenClaw.
This is the automaton endgame — a permissioned agent that can create new versions of itself. The original plan called this obol-helm-spawn (spawn whitelisted Helm charts via K8s Job pattern), but that's redundant with obol-k8s + obol-network. What we actually need is narrower and more useful:
An OpenClaw instance calls obol-spawn → the skill creates a new namespace, deploys a new OpenClaw chart with a specified genesis prompt and model config, and returns the new instance ID. The parent retains awareness of its children.
This is not raw Helm/K8s write access — it's a curated, single-purpose operation that reuses the existing obol openclaw setup flow. The security model is:
- Allowlisted operation (spawn OpenClaw only, not arbitrary charts)
- Parent must have the
spawnpermission flag - Child inherits parent's model config (or a subset)
- Lineage tracked (parent ID stored in child's config)
This maps directly to the Automaton pattern of self-replicating agents with survival pressure, but scoped to the safe, local Obol Stack environment.
Architecture Notes
Permission Tiers
| Tier | SA Used | Scope | Skills |
|---|---|---|---|
| Read-only | OpenClaw SA | Own namespace | obol-rpc, obol-k8s (read), obol-monitoring |
| Network read | Obol Agent SA | All namespaces | obol-k8s (cluster), ethereum-wingman |
| Write | Obol Agent SA | Allowlisted ops | obol-network, obol-spawn |
Why not obol-helm-spawn?
The original plan had a P3 skill for "spawn whitelisted Helm charts from within OpenClaw (via K8s Job pattern)." This is three things collapsed into one:
- Read K8s → already
obol-k8s - Deploy networks → already
obol-network - Spawn new agents → the actual novel capability
Raw Helm write access is both too powerful (security risk) and too low-level (the agent shouldn't care about Helm). The right abstraction is purpose-built skills that map to obol CLI operations, not generic K8s/Helm access.
Relates to
obol openclaw#132 —obol openclaw(umbrella)- Implement AgentCapability CRD for service registration #126 — AgentCapability CRD for service registration
- Proposal: Dynamic Network Discovery via Kubernetes API & Standardized Labeling #114 — Dynamic Network Discovery via Kubernetes API