The Skills Layer: 191 Domain Automation Routines

Above OpenClaw's agent SDK and the MCP tool servers described in earlier sections sits the layer that gives NetClaw its network-engineering competence: a library of 191 skills that live in the repository's workspace/skills/ directory. Where MCP servers expose atomic tools — connect to a device, run a query, return JSON — a skill packages the procedure for using those tools to accomplish a bounded operational goal: audit an OSPF LSDB, check an F5 pool's health, reconcile NetBox against discovered state. This section explains what a skill is in NetClaw's terms, surveys the twelve-plus functional categories the skills fall into, and examines the deliberate decision to gate change management at the skill boundary rather than scattering approval checks across the whole library.

What a Skill Is and Where It Lives

A NetClaw skill follows the Anthropic-style Agent Skills convention: a self-contained, filesystem-based package of procedural knowledge that the agent loads dynamically when a task matches its description. Each skill is a directory under workspace/skills/ containing a SKILL.md manifest — Markdown instructions with YAML frontmatter carrying the metadata the agent uses for discovery — alongside any scripts, templates, or reference assets the workflow needs. The manifest encodes how to perform the task, not merely what to return: the stepwise workflow, the tools to orchestrate, guardrails, retry behavior, and output schema.

---
name: pyats-topology
description: Discover Layer 2/3 topology across a testbed, parse CDP/LLDP
  neighbors, and emit a compact adjacency graph. Use when the operator asks
  to map, discover, or diagram device connectivity.
triggers: [topology, discover, neighbors, CDP, LLDP, adjacency]
---

## Workflow
1. Load the testbed and connect to in-scope devices.
2. For each device, `device.parse("show cdp neighbors detail")`.
3. Merge per-device neighbor tables into a single adjacency graph.
4. Encode the graph in GCF (Graph Compact Format) to reduce token cost.
5. Return the graph; hand off to `netbox-reconcile` if drift-checking is requested.

This structure makes skills executable (invoked and run), reusable across sessions and tasks, and governable — each carries its own applicability conditions and interface. Because a skill owns a narrow responsibility, the model has less room to hallucinate than a monolithic "do networking" prompt would allow. Skills are also composable: pyats-topology discovers devices, netbox-reconcile flags drift against the source of truth, and github-ops commits the findings as config-as-code — a chain assembled at runtime from single-purpose parts. Every skill action is recorded to GAIT, the Git-based immutable audit trail, and network-graph payloads are encoded in GCF for a 55–83% token reduction, with session deduplication reaching roughly 91% savings by the third call.

graph TD
    G["Operator goal"] -->|"trigger matching"| S["Skill (SKILL.md workflow)"]
    S -->|"orchestrates"| T["MCP tools (atomic)"]
    subgraph Composition["Runtime skill chain"]
        A["pyats-topology (discover)"] --> B["netbox-reconcile (flag drift)"]
        B --> C["github-ops (config-as-code)"]
    end
    S -.-> A

The Skill Categories

The 191 skills organize into more than a dozen functional families. At the foundation sit the pyATS device skills, which wrap Cisco's pyATS test framework and its Genie library — 2000+ CLI parsers and OPS feature models (OSPF, BGP, interfaces) — to turn show output into structured data and to run before/after learn/diff state validation. Vendor and domain families extend that reach across Cisco (ACI, ISE, Meraki, NSO, FMC, Catalyst Center, SD-WAN, RADKit), Juniper, Arista, F5, Aruba, and the major clouds. A separate observability cluster maps to Grafana, Prometheus, Datadog, Splunk, ThousandEyes, Kubeshark, and SuzieQ, while security skills cover nmap scanning, packet analysis via tshark, firewall rule shadowing detection, and CVE correlation. Lab environments (CML, ContainerLab, GNS3) and visualization tooling round out the set.

Counts within grouped rows aggregate the finer-grained families the README enumerates; the categorical breakdown is authoritative in the NetClaw README. Two families deserve a closer look. The observability and security skills exist to answer complementary questions: observability skills ("what is happening and how does it affect users?") pull metrics, logs, and traces from Prometheus TSDBs, Grafana dashboards, and ThousandEyes path agents; security skills ("what is exposed and does it match a known vulnerability?") drive nmap host discovery and version detection, then correlate services against CVE data with CVSS scoring. The visualization skills — three of them — convert discovered state into pictures: Canvas A2UI renders inline charts, a Draw.io skill emits topology diagrams, and a UML skill produces diagrams via Kroki, so the output of a discovery run can be handed straight to a human as a drawing rather than a wall of JSON.

Skill-Level Change Gating as a Design Choice

The most consequential architectural decision in the skills layer is where change discipline is enforced. Rather than embed a "should I ask for approval?" check inside each of the 191 skills, NetClaw concentrates change-management logic in a small number of dedicated, ITSM-aware skills. The servicenow-change-workflow skill owns the full ServiceNow change-request lifecycle — pre-change validation, approval wait, execution, and rollback — and other mutating skills defer to that discipline rather than reimplementing it.

Operator: "Push the approved VLAN change to the access switches."
  └─ aruba-cx-switching (ITSM-gated) detects a mutating operation
     └─ delegates to servicenow-change-workflow
        ├─ pre-change check  → capture Genie learn() baseline
        ├─ CR approval gate  → block until CR is approved
        ├─ execute change    → apply VLAN config
        └─ verify + rollback → learn()/diff(); revert on failure

Skills carrying this gating include pyats-config-mgmt (a Baseline → Plan → Apply → Verify loop built on Genie's learn/diff), aci-change-deploy, f5-config-mgmt, aruba-cx-switching, grafana-observability for dashboard and alert edits, and protocol-participation, whose route injection and withdrawal is CR-gated unless NETCLAW_LAB_MODE=true marks the environment as a lab. A parallel human-in-the-loop track handles decisions that policy cannot pre-approve: ise-incident-response requires explicit human sign-off before quarantining an endpoint, and humanrail-escalation routes low-confidence, pre-destructive, or ambiguous situations to paid human reviewers.

Concentrating gates this way yields a single source of truth for change discipline. Auditing whether NetClaw handles change control correctly means reading a handful of gating skills, not diffing approval logic across the entire library; updating the approval policy means editing one workflow; and every destructive path funnels through the same audited, GAIT-recorded chokepoint. It is the skills-layer expression of the broader NetClaw principle that automation should be composable and fast by default but deliberately narrow and human-checked wherever it touches production state.

flowchart TD
    M1["pyats-config-mgmt"] --> CR["servicenow-change-workflow (CR lifecycle)"]
    M2["aci-change-deploy"] --> CR
    M3["f5-config-mgmt"] --> CR
    M4["aruba-cx-switching"] --> CR
    M5["protocol-participation"] --> CR
    H1["ise-incident-response"] --> HITL["Human-in-the-loop sign-off"]
    H2["humanrail-escalation"] --> HITL
    CR --> GAIT["GAIT audit trail"]
    HITL --> GAIT

References