| name | service |
| description | Manage systemd service units — start/stop/restart, check status, enable/disable on boot. Pure execution, no communication. Mock backend (binding-only) for the thesis benchmark. |
Service Skill
Use this skill for systemd service control: bringing units up and down, restarting
them, reading their status, and toggling boot-persistence. It is a canonical
reflexer case — every request maps to a single side-effecting shell command with
no dialogue and no information return beyond a status line. Deterministic
intent → one command → execute.
Mock / binding-only. In this thesis benchmark the svc CLI is a mock that echoes a
JSON status line WITHOUT touching real systemd — we evaluate command correctness
(does the reflexer emit the right subcommand/unit?), not real service effects. To target
a live system, replace the mock with systemctl.
Commands (via bash)
CLI: python3 agents/skills/service/svc.py <command> [args] (aliased svc).
Start / stop / restart a unit (the subcommand is the discriminator)
svc start --unit "<unit>"
svc stop --unit "<unit>"
svc restart --unit "<unit>"
Check a unit's status (read)
svc status --unit "<unit>"
Enable / disable a unit on boot
svc enable --unit "<unit>"
svc disable --unit "<unit>"
Flags
--unit "<unit>" systemd unit name (e.g. nginx.service, docker, postgresql)
Output format
One JSON line: {"ok": bool, "data": {...}, "error": null|{...}, "meta": {"mock": true}}.
Exit 0 on success, 2 on bad args.
Sibling families (why this skill is in the benchmark)
start / stop / restart / status / enable / disable all share the same
domain and --unit slot, differing only in the subcommand word — a dense
six-member action-sibling family. This is a deliberate stress test of the router's
action-discrimination (the dominant failure mode: sibling collision). status is the
sole read; enable/disable are the boot-persistence pair.
