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 skills add Josepavese/nido --skill nido-vm-testinggit clone --depth 1 https://github.com/Josepavese/nidoWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/josepavese/nido/nido-vm-testing)<a href="https://agentmods.dev/skills/josepavese/nido/nido-vm-testing"><img src="https://agentmods.dev/badge/skills/josepavese/nido/nido-vm-testing/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/josepavese/nido/nido-vm-testing"><img src="https://agentmods.dev/badge/skills/josepavese/nido/nido-vm-testing.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00037 | $0.01022 |
| Opus 5.5 | $0.00015 | $0.00409 |
| Sonnet 5.5 | $0.00007 | $0.00204 |
| Haiku 4.5 | $0.00004 | $0.00102 |
Grade A, and why
nido-vm-testing 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 — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Nido VM Testing
Use Nido for VM-backed tests when the result depends on a guest OS, kernel,
services or networking. Follow the requested test scope; inspect host readiness
with nido doctor when needed and select an available image with nido images list.
Disposable test workflow
- Choose an image or a prepared template, explicit CPU/memory and a unique VM name. Check storage before downloads or VM creation; linked clones retain dependencies on their base images. Keep existing VMs, templates and caches.
- Provision prerequisites with
--user-data. Keep setup non-interactive and idempotent, and separate stable template prerequisites from changing code. - Spawn with automatic host ports, then read
nido info <name> --json. Its VM object isdata.vm; discoverssh_port,ssh_userand labeledforwardingentries there instead of guessing ports or users. - Wait for SSH with a bounded deadline, then check cloud-init and the actual service/test readiness. Process-running events do not prove guest readiness.
- Transfer only the intended test inputs, run the test and export useful logs and artifacts before cleanup. Keep secrets out of reusable templates.
- Delete only the exact resources created by this run, using a trap or CI cleanup. Reconcile a failed spawn's partial effects before retrying or deleting; preserve unrelated resources and retained debugging evidence.
For a complete shell workflow, inspect or adapt
scripts/nido-ephemeral-test.sh. It waits separately
for SSH and cloud-init, uploads NIDO_PROJECT_DIR and deletes its successful spawn
on exit. NIDO_KEEP_VM=1 retains the VM on exit, including after test failure.
Choose the guest architecture
Use omitted/auto architecture for native catalog guests. For cross-ISA testing
pass CLI --arch amd64|arm64 or MCP arch; expect TCG rather than KVM/HVF/WHPX.
Do not treat an ARM guest emulated on x86 as native ARM hardware qualification.
Templates inherit their declared ISA and reject explicit conflicts. Verify the
guest with uname -m over SSH, separately from QEMU process state. A missing
image variant is an error, not permission to substitute a foreign guest.
For a pre-architecture installation, stop legacy VMs and close old clients before
updating. State conversion is automatic during current updates/installers, or
at the first invocation after an older updater/package manager. Do not run a
manual migration as a routine upgrade step. Preserve disks and backing paths;
follow the architecture guide
for preparation failures and explicit recovery/adoption of unidentified imports.
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 Changed · +3 lines ef0b09608925
- 3d ago Changed · +12 lines 5ab06d15f5d5
- 4d ago Changed · -81 lines · -32 tokens per session 58b3fffd1f9b
- 1mo ago First seen · 142 lines · 69 tokens per session scan A 517303d884bb
nido-vm-testing is a skill published in the GitHub repository Josepavese/nido (2 stars, last pushed today), licensed MIT. It adds 37 tokens to every session and 1,022 once invoked, about $0.0001 per session on Opus 5.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
coding-flow
Light coding workflow: features, fixes, refactors, unit tests, etc.; scales small to large.
coding-agents-prompting-flow
Workflow for authoring and adapting AI-agent prompts: skills, agents, workflows, rules, etc.
speak
Provides concise spoken alerts and digests through the mcp-tts MCP server. It should be selected proactively for significant AI and DevOps transitions: a substantial plan is ready, a long build/test/deploy/release/monitoring phase changes state, a major task completes, a terminal blocker or exhausted retry budget…
robotgo
Use when automating desktop GUI in Go — robotgo.Move/Click/KeyTap, CaptureImg vs CaptureScreen, bitmap.Find template matching, gohook global hotkeys, gcv OpenCV matching, clipboard and window control. RobotGo v1.3.7: cross-platform Go desktop automation for macOS/Windows/Linux. Also for black screenshots or silently…
use-workflow-tdd-cycle
A test-first coding process based on TDD, or test-driven development: write a failing test, make it pass, then improve the code.
lain-verify
Use to verify a change through Lain — "run the tests", "does it build", "what is untested", "what changed", "which branch am I on". Covers the verify package (build/test/lint/coverage/git state).