Stop driving Slicer by hand - give your agent the wheel - SlicerVM Blog<br>svg]:px-2.5 font-mono -ml-2" href="/blog/">Back to Blog

Can you remember the excitement of tab completion powered by an LLM - directly in your IDE? Local Linux VMs followed the same pattern: tools like Orbstack, Lima, and UTM give you a nice UI, but you're still clicking, editing config, and SSH-ing in by hand.

Slicer gives you Linux microVMs, with systemd, a dedicated kernel, and full OS, that boot in under a second. You can drive it by hand with the CLI, or you can hand the work off to your AI agent and just say:

Test our changes on my mini PC at 192.168.0.2.<br>Install K3s, deploy the local version of the Helm chart, and<br>add the remote cluster to my local kubeconfig so I can use<br>kubectl.

Test that kubectl is working, and that the application started<br>properly, without errors - before you hand it back.

The Slicer agent skills teach your agent how to launch, manage, and work with Slicer VMs so prompts like that actually work end to end.

In this article we'll walk through a number of practical examples that show what the slicer agent skills can do. We used OpenCode to run the examples, but the same skills work with any agent that supports the Agent Skills standard, like Claude Code or Codex.

Run a temporary Docker daemon

Test a systemd service end to end on your Mac

Build and test an ArgoCD Application for your new microservice

Spin up an agent with its own worktree

Set up an Arm Docker Builder on a Raspberry Pi

Clone a private repo through Slicer Proxy without a credential

Agent Skills - the secret sauce

The core use-slicer skill covers everything from daemon connection to VM creation, command execution, file transfer, port forwarding, and agent sandboxes. Additional companion skills extend the capabilities further:

use-k3sup — provision single-node or HA k3s clusters with k3sup

use-slicer-worktrees — push git worktrees into VMs, let agents commit, pull changes back

use-slicer-proxy — filter egress, audit traffic, and inject secrets into VM HTTP requests

Combining these skills lets your agent run end-to-end workflows.

1. Run a temporary Docker daemon

You want a clean Docker setup that does not pollute your host and can be thrown away anytime. Launch a Slicer VM to run the Docker daemon and port-forward its socket, so the local Docker CLI works just like it would against a local daemon.

The prompt you could give to your agent:

Setup docker on slicer and show me the command to forward<br>the docker socket for local use.

The agent loads the use-slicer skill to discover if a Slicer instance is running, launches a new VM, and uses the slicer vm exec command to install Docker on the VM.

At the end it prints out the commands to forward the Docker socket to your local host. Additionally, the agent gives a couple of Docker command examples that can be run against the forwarded socket.

slicer vm forward sbox-1 -L /tmp/docker.sock:/var/run/docker.sock &<br>export DOCKER_HOST=unix:///tmp/docker.sock<br>After starting the port forward, docker ps, docker run, and any other Docker command behave as usual. Every container runs inside the slicer VM, leaving your host untouched:

$ docker run -d --name demo alpine sleep 300<br>$ docker ps<br>CONTAINER ID IMAGE COMMAND STATUS NAMES<br>5580e8ace925 alpine "sleep 300" Up 1 second demo<br>2. Test a systemd service end to end on your Mac

Say you're on a Mac and want to test a systemd unit file against real Linux, not a container shim or cloud VM you have to request. A sandbox Slicer VM gives you a real kernel with systemd in under a second.

Here's a prompt you could give to your agent:

Create a sandbox VM and test the Caddy systemd service file.

Install Caddy via the official script, copy the unit file from<br>https://raw.githubusercontent.com/caddyserver/dist/master/init/caddy.service<br>to /etc/systemd/system/caddy.service, and write a Caddyfile at<br>/etc/caddy/Caddyfile serving "Hello from Slicer" on :80.

Enable and start the service, verify with systemctl status caddy,<br>port-forward 8080 from the VM to my localhost and curl it,<br>then test systemctl reload caddy.

Summarize the test results and any issues, did the service file work<br>as-is, were there problems with permissions, capabilities, or the<br>Type=notify behavior?

The agent chains a handful of Slicer commands end-to-end: slicer vm add to create the VM, slicer vm exec to install Caddy and write the unit file inside the VM, and slicer vm forward to map a VM port to your localhost. It then runs the test as instructed and reports back with the summary you asked for.

3. Build and test an ArgoCD Application for your new microservice

Your team has created an application and wants to deploy it to Kubernetes using ArgoCD for continuous delivery. By spinning up a temporary Kubernetes cluster in a Slicer VM and running ArgoCD on it, the agent can test the ArgoCD application while building it.

A prompt for your agent might look like this. In this example we ask it...