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 skills/rnixai/rnix/using-rnixnpx skills add rnixai/rnix --skill using-rnixgit clone --depth 1 https://github.com/rnixai/rnixWhat 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.00162 | $0.02414 |
| Opus 5 | $0.00081 | $0.01207 |
| Sonnet 5 | $0.00032 | $0.00483 |
| Haiku 4.5 | $0.00016 | $0.00241 |
Grade A, and why
using-rnix 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 2d ago.
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 — 183 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Using Rnix
Rnix is an operating system for AI agents — "the AI-Era Unix". You drive it
with a single CLI, rnix, the way you drive Unix with ps, kill, and
strace. This skill gives you rnix's capability map and the exact commands to
run, so you can accomplish a task with rnix without reading its source.
If you already know Unix, you already know most of rnix. The novelty is what the processes are: each one is an AI agent reasoning in a loop.
Mental model
Three ideas explain almost everything:
- Everything is a Process. Every agent run is a first-class process with a
PID, a state machine (Created → Running → Suspended/Zombie → Dead), and a
resource table. You list them with
ps, end them withkill, watch them withstrace— the same verbs you already know. Processes can be suspended, resumed, and forked from checkpoints. - Everything is a File. LLMs, the filesystem, the shell, agent memory, web
search, code intelligence (LSP), and MCP tools are all exposed as virtual
devices behind a uniform file interface. Adding a capability is mounting a
device. (The concrete device catalog lives in
references/architecture.md— you rarely need it just to drive rnix.) - Orchestration is process management. Multi-agent workflows are DAGs of
processes (
compose); high-level goals are decomposed into sub-task DAGs (intent/apply); supervisor trees restart crashed agents. These are OS primitives, not application glue.
Daemon model — read this once. A background daemon holds the kernel and the
process table; the CLI talks to it over a Unix domain socket. Commands that
create work (rnix -i, rnix apply, rnix compose up, rnix run) auto-start
the daemon on first use. Passive query, attach, or lifecycle commands such as
rnix ps, rnix strace, rnix suspend, and rnix resume dial the existing
daemon; if it is stopped, start one with rnix daemon start or run a spawning
command first. Because the daemon is shared, a process you spawn in one terminal
is visible to rnix ps in another. Manage it explicitly with
rnix daemon status / rnix daemon stop.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 2d ago First seen · 183 lines · 162 tokens per session scan A ce93b1fc2029
using-rnix is a skill published in the GitHub repository rnixai/rnix (5 stars, last pushed 25d ago), licensed MIT. It adds 162 tokens to every session and 2,414 once invoked, about $0.0008 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 skills, from other repositories
foundry-config-setup
Resolve missing setup caused by a hardcoded Foundry project endpoint or model in a sample. Use when a sample fails because it uses a placeholder/hardcoded projectendpoint (for example "https://your-project.services.ai.azure.com") or a hardcoded model instead of reading them from the environment.
reflect
Review recent work, find repeated workflow patterns, and suggest reusable skills, agents, commands, config changes, or playbooks. Use when the user asks to learn from past sessions, improve recurring workflows, or identify what should be turned into reusable agent instructions.
codemap
Generate comprehensive hierarchical codemaps for UNFAMILIAR repositories. Expensive operation - only use when explicitly asked for codebase documentation or initial repository mapping.
release-notes
Draft concise release notes.
length-converter
Convert between common length units (miles, km, feet, meters) using a multiplication factor.
background
Use when the user wants to see, inspect, cancel, or prune background agents fired during prior chain runs. Read/manage .hyperflow/background/registry.json and the per-agent output buffers at .hyperflow/background/ .md. Standalone — never auto-invoked. Trigger with /hyperflow:background, "list background agents"…