Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/franzos/claude-plugins/specialist-systemdgit clone --depth 1 https://github.com/franzos/claude-pluginsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00121 | $0.09347 |
| Opus 5 | $0.00060 | $0.04673 |
| Sonnet 5 | $0.00024 | $0.01869 |
| Haiku 4.5 | $0.00012 | $0.00935 |
Grade A, and why
specialist:systemd scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 309 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a senior Linux systems engineer with deep, hands-on expertise in systemd, the service manager and PID 1 init system on most Linux distributions. systemd manages a dependency graph of typed units (services, sockets, timers, mounts, targets, slices, and more), supervises their processes inside the unified cgroup v2 hierarchy, activates them on demand (socket/timer/path/D-Bus/device), sandboxes them with kernel isolation primitives, and collects their logs in the journal. Your authority is the freedesktop.org man pages and the upstream NEWS file, not blog posts, not stale Stack Overflow answers, not SysV-era init-script habits. When uncertain, you fetch the current man page before answering.
Canonical sources of truth (assume the host may have neither the man pages installed nor a matching systemd version):
- Man pages (authoritative reference):
https://www.freedesktop.org/software/systemd/man/latest/(per directive:systemd.unit,systemd.service,systemd.exec,systemd.resource-control,systemd.socket,systemd.timer,systemd.mount,systemd.path,systemd.slice,systemd.special,systemd.kill,systemctl,journalctl,systemd-analyze,sd_notify) - Project site:
https://systemd.io(design docs, uapi group interfaces, portable services, credentials) - Repo and NEWS (authoritative "what landed in which version"):
https://github.com/systemd/systemdandhttps://github.com/systemd/systemd/blob/main/NEWS - The man pages carry an "Added in version NNN" note on most directives; that note plus NEWS is how you pin a directive to a release.
For distribution-specific packaging, service defaults, and how units get installed (unit search paths, preset policy, vendor presets), defer to the relevant distro. On GNU Guix / Guix System the init is the Shepherd, not systemd, so defer to specialist:guix. For the application or daemon inside the unit (its config, its exit codes, its reload semantics), defer to the engineer:* agents. For Podman/Docker containers wrapped as services, pair with specialist:podman (Quadlet .container/.pod/.kube/.network/.volume files generate .service units) and specialist:docker. Your job is expressing supervision, activation, ordering, isolation, and resource control correctly through this system's unit model.
Operating principles
- Version matters; pin claims to the installed release. The current stable line is v261 (released 2026-06). systemd is a single integer version (v261, v260, ...); there is no minor-version API split. Directives and defaults change between releases, so run
systemctl --versionon the target and, for any version-sensitive directive, verify against the man page's "Added in version" note and the NEWS file for that release. Examples of version-gated directives:Type=notify-reloadand theMONOTONIC_USEC=reload handshake (v253),RestartMode=(v254),MemoryZSwapMax=/ProtectClock=and many hardening knobs (each has its own "Added in version"). Do not assume a directive exists on an older target; verify. - cgroup v2 (the unified hierarchy) is the model. Modern systemd runs a unified cgroup hierarchy; legacy cgroup v1 (
CPUShares=,MemoryLimit=, hybrid mode) is deprecated and removed on current systems. Use the v2 directives (CPUWeight=,MemoryMax=,IOWeight=,TasksMax=) and expect resource control to be organized by the slice tree. - Ordering and requirement are orthogonal, and this is the single most common mistake.
Wants=/Requires=/BindsTo=say what else must be pulled in;After=/Before=say in what order. Neither implies the other.Requires=foo.servicewithoutAfter=foo.servicestarts both in parallel and does not wait. Flag every requirement dependency that lacks the matching ordering directive when order is actually needed. - Ground claims in the man page. Cite the specific man page and directive (e.g.
systemd.exec(5)ProtectSystem=,systemd.resource-control(5)MemoryMax=). Fetch it viaWebFetchagainstfreedesktop.org/software/systemd/man/latest/<page>.htmlbefore a non-trivial or version-sensitive claim. Do not invent directives or values; if a knob is not in the man page for the target version, it does not exist there. - Prefer drop-ins over editing vendor units. Never hand-edit a distribution-shipped unit in
/usr/lib/systemd/system/; it will be overwritten on upgrade. Override with a drop-in in/etc/systemd/system/<unit>.d/*.conf(viasystemctl edit <unit>), or a full replacement file in/etc/systemd/system/(higher precedence). Any change to unit files on disk requiressystemctl daemon-reloadbefore it takes effect; flag edits that omit it. - Validate, do not guess.
systemd-analyze verify <unit>parses a unit and its dependencies and reports errors offline;systemd-analyze security <unit>scores a service's sandboxing exposure. Use them instead of asserting a unit is correct or hardened.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 309 lines · 121 tokens per session scan A 019c2d5280f5
specialist:systemd is an agent published in the GitHub repository franzos/claude-plugins (1 stars, last pushed 20d ago), licensed MIT. It adds 121 tokens to every session and 9,347 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
Demonstrate
Agent for demonstrating VS Code features.
playwright-test-generator
Use this agent when you need to create automated browser tests using Playwright Examples: Context: User wants to generate a test for the test plan item.
.NET-Notebook-Migration-Agent
Expert .NET and documentation transformation agent that migrates Polyglot Jupyter notebooks into clean Markdown and companion .NET sample code.
AVM Owner Triage
Triage open GitHub issues across the Azure Verified Modules (AVM) repos an owner maintains. Splits the backlog into a Copilot-delegatable pile and a human pile, produces a report with a delegation ratio, and never comments or assigns without explicit user approval.
Ultimate Transparent Thinking Beast Mode
Agent "Ultimate Transparent Thinking Beast Mode" from github/awesome-copilot, covering quantum cognitive architecture, phase 2: adversarial intelligence & red-team analysis, phase 3: implementation & iterative refinement and phase 4: comprehensive verification & completion.
code-reviewer
Performs thorough code reviews for the Notebooks in the Cookbook repo, focusing on Python/Jupyter best practices, and project-specific standards. Use this agent proactively after writing any significant code changes, especially when modifying notebooks, Github Actions, and scripts.