We Said Any Agent Could Run These Skills. Here's One That Isn't Claude Code.

The last post about these packs ended on a claim we hadn’t actually tested:

“The pack is shipped as a Claude Code skill directory because that is what we run. But every script reads one JSON object on stdin and prints one JSON object on stdout — there is no framework binding. Any agent runtime that can execute a shell command can drive the same scripts.”

That’s a testable sentence, not a marketing one, so we tested it. Not with Claude Code again — with pi-agent, a different vendor’s coding-agent CLI, its own model routing, and no relationship to Anthropic’s Agent Skills work beyond following the same SKILL.md discovery convention. If the packs really carry their own dependency closure and really speak a framework-agnostic protocol, a different runtime should be able to pick them up cold.

The setup was deliberately unhelpful

A bare Ubuntu 24.04 box, no prior OLAV install, no Node.js, no Python packages beyond the system default. We installed pi-agent the way anyone would — nvm install --lts, then npm install -g @earendil-works/pi-coding-agent — and pointed its skill-discovery directory at a plain pip install of the packs:

python -m venv .venv && . .venv/bin/activate
pip install -r requirements-lean.txt
pip install ./runtime
cp -r skills/* ~/.pi/agent/skills/

No OLAV server anywhere in this picture. The model backing pi-agent was DeepSeek, not whatever OLAV’s own default happens to be — a second axis of “not the vendor’s own stack” on top of the agent runtime itself.

Level 1: does it even see the skills

pi --provider deepseek --print \
  'List every skill you can see available to you right now, just the names.'

analyst
analyzer
designer
explorer
importer
learner
netops
presales
publisher
reporter
surveyor
topology
writer

Thirteen names, all correct, nothing extra — the seven olav-skills agents plus six of olav-presales-skills’. Not exciting, but it’s the precondition for everything after it, and it’s also the easiest place for a subtly wrong install to fail silently.

Level 2: does it run a script correctly, including the failure path

pi --provider deepseek --print \
  'Using the analyzer skill, run its describe_table script on the table netops.devices \
   and report exactly what it returns.'

Against an empty database:

{"error": "table not found: 'netops.devices'", "hint": "Try schema-qualified (e.g. 'netops.devices' or 'main.v_interfaces_auto')."}

The interesting thing here isn’t the answer, it’s the shape of the failure. ModuleNotFoundError would mean the runtime didn’t install correctly. A structured, hinted “not found” means the Python package resolved, DuckDB connected, and the script did its job — there just wasn’t a table yet. Getting this distinction right in the first ten minutes is what tells you whether to keep going.

Level 3: a real task, with a real bug in the way

We added one skill outside the two lean packs — collector, the device-facing agent that deliberately isn’t shipped in either pack because it needs netmiko and real SSH credentials — and pointed nornir at eight live Cisco IOL nodes in a containerlab topology (two campuses, OSPF inside each, eBGP between the cores). Then, one sentence, no step list:

“Use the collector skill to collect fresh data from all 8 devices — show version, interfaces, CDP neighbors, routes, OSPF neighbors, BGP summary. If you hit a missing-table error, go read the olav_netops source to find the right fix and apply it. Then use the reporter skill to investigate this network’s health and export a structured report.”

The first pass did hit exactly that error:

Catalog Error: Table with name devices does not exist!

Nobody told it what to do about that. It read olav_netops/core/tables.py and olav_netops/core/device_etl.py on its own, found TableRegistry.ensure_all_schemas() — the same call the platform’s own /netops_init uses — applied it, re-ran the collection (dropping max_workers from 8 to 2 on the second pass, because the first had hit VTY contention on the lab boxes), and moved on to the report.

The report it wrote was genuinely good, not “good for a demo”:

8/8 devices, 44/44 interfaces up, 4/4 OSPF adjacencies Full, 4/4 eBGP sessions Established — numbers we pulled independently from the same DuckDB file afterward and they matched exactly.
It cross-checked two topology views against each other, noticed v_l2_links_auto reported 36 links while v_show_cdp_neighbors_detail_auto reported 72 raw entries resolving to the same 8 physical links plus a shared management segment, and called out which view to trust — a data-quality finding nobody asked for.
It correctly filed “access switches don’t speak OSPF/BGP” as expected behavior, not a fault. A weaker agent files every non-2xx response as a bug; distinguishing “this device doesn’t run this protocol” from “something is broken” is exactly the judgment call these skills are supposed to carry, and it carried it without us in the loop.

The five findings it ranked — single-homed access switches, one distribution device per campus, the core interconnect as the only redundant path, a flat shared management VLAN, unnecessary DR/BDR election on point-to-point OSPF links — are the findings an engineer would write about this exact topology. We checked.

What this does and doesn’t prove

It proves the framework-agnostic claim: a different vendor’s agent runtime, a different model provider, zero code changes to the packs, and the skills worked — discovery, single-script execution, and an unsupervised multi-step investigation that survived hitting a real bug along the way. olav-presales-skills got the same discovery-and-single-script treatment; we didn’t run a full presales workflow through it the way we did the netops side, so that claim stays narrower on purpose.

It doesn’t prove the packs are self-sufficient for everything. collector’s device-facing scripts are excluded from both lean packs on purpose — actually reaching live devices needed the full olav[agent]/olav-netops[device] install alongside them, which is the boundary the collector post already drew. Nothing here touched an embedding backend either; that’s not a gap, that’s the packs behaving exactly as documented — a script whose whole job is vector search is excluded, not shipped broken.

Try it against a runtime we didn’t write

pip install ./runtime
cp -r skills/* ~/.pi/agent/skills/     # or ~/.claude/skills/, or wherever your client looks

github.com/james-olavai/olav-skills

The claim in the last post was that nothing about these packs is Claude-specific. This one is the receipt.