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/the-void-ia/void-box/verifynpx skills add the-void-ia/void-box --skill verifygit clone --depth 1 https://github.com/the-void-ia/void-boxWhat 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.00057 | $0.01513 |
| Opus 5 | $0.00028 | $0.00757 |
| Sonnet 5 | $0.00011 | $0.00303 |
| Haiku 4.5 | $0.00006 | $0.00151 |
Grade A, and why
verify scanned grade A with 1 finding 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 3d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
# HN researcher (Claude agent + real HN API via curl+jq, writes output.md) How it starts
The opening of the file, as written. The whole thing — 128 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Run these checks in order. Stop and report at the first failure.
1. Format check
cargo fmt --all -- --check
2. Clippy (guest-agent builds as a no-op stub on non-Linux, so the same command runs on macOS)
cargo clippy --workspace --all-targets --all-features -- -D warnings
3. Tests
cargo test --workspace --all-features --verbose
cargo test --doc --workspace --all-features
Note: Integration and E2E tests (conformance, snapshot, e2e_*) require VOID_BOX_KERNEL and VOID_BOX_INITRAMFS to be set and use --ignored --test-threads=1. Only run them if the user requests VM-level validation.
4. Security audit
cargo audit --deny warnings
5. Startup bench regression gate (required before push; thresholds differ by host)
Guards against regressions in the subsecond startup path. Thresholds are host-specific because Linux/KVM and macOS/VZ have different floors — VZ cold time is dominated by Hypervisor.framework setup, not kernel init, so the slim kernel helps much less on macOS.
On Linux (fail if cold p50 > 400 ms or warm p50 > 200 ms):
cargo build --release --bin voidbox-startup-bench
export VOID_BOX_KERNEL=$PWD/target/vmlinux-slim-x86_64
export VOID_BOX_INITRAMFS=/tmp/void-box-test-rootfs.cpio.gz
./target/release/voidbox-startup-bench --iters 20 --breakdown 2>&1 | \
tee target/tmp/verify_bench.log | grep -E "^(cold|warm)\.total"
On macOS/arm64 — M-series (fail if cold p50 > 2.2 s or warm p50 > 320 ms).
Thresholds are provisional, derived from a single n=10 baseline; re-measure
at n=20 on the target host before treating them as hard gates. Intel
Mac / VZ has no baseline yet; skip this step or measure locally first.
Use cargo run so the .cargo/config.toml runner codesigns the bench
binary automatically — direct invocation of target/release/...
skips the runner and fails with a com.apple.security.virtualization
entitlement error:
export VOID_BOX_KERNEL=$PWD/target/vmlinux-slim-aarch64
export VOID_BOX_INITRAMFS=/tmp/void-box-test-rootfs.cpio.gz
cargo run --release --bin voidbox-startup-bench -- --iters 20 --breakdown 2>&1 | \
tee target/tmp/verify_bench.log | grep -E "^(cold|warm)\.total"
- If
vmlinux-slim-<arch>is missing, runscripts/build_slim_kernel.shfirst (10 min cold; cached thereafter). On macOS the script auto-re-execs inside anubuntu:24.04container — requires Docker Desktop running. - If the test rootfs is missing, run
scripts/build_test_image.sh. - Reference numbers:
- Fedora 43 / KVM / slim x86_64: cold p50 ≈ 252 ms / p95 ≈ 260 ms, warm p50 ≈ 138 ms / p95 ≈ 144 ms.
- M-series / VZ / slim aarch64: cold p50 ≈ 1.9 s, warm p50 ≈ 282 ms (n=10 baseline; re-measure at n=20 and tune thresholds when you have a stable sample).
- If the bench hangs or produces EAGAIN within 30 s, skip to
superpowers:systematic-debugging— do not push until diagnosed.
6. Real-workload smoke (Linux only, required before push when secrets are available)
Small RPCs dominate day-to-day testing, so regressions in the host→guest
path for payloads >4 KiB have slipped through before (see
fix/vsock-host-to-guest-packetize). These two specs exercise the
full production path end-to-end:
# HN researcher (Claude agent + real HN API via curl+jq, writes output.md)
ANTHROPIC_API_KEY=… \
VOID_BOX_KERNEL=$PWD/target/vmlinux-slim-x86_64 \
VOID_BOX_INITRAMFS=$PWD/target/void-box-claude.cpio.gz \
timeout 300 ./target/release/voidbox run \
--file examples/hackernews/hackernews_agent.yaml \
> target/tmp/verify_hn.log 2>&1
# OpenClaw Telegram gateway (verify + configure + smoke_message posting to Telegram)
ANTHROPIC_API_KEY=… TELEGRAM_BOT_TOKEN=… TELEGRAM_CHAT_ID=… \
VOID_BOX_KERNEL=$PWD/target/vmlinux-slim-x86_64 \
VOID_BOX_INITRAMFS=$PWD/target/void-box-claude.cpio.gz \
timeout 180 ./target/release/voidbox run \
--file examples/openclaw/openclaw_telegram.yaml \
> target/tmp/verify_openclaw.log 2>&1
Pass criteria:
- HN — log contains at least one
tool: Bashinvocation and onetool: Writetargeting/workspace/output.md(agent completed the research round-trip). - OpenClaw — log contains
step 3/4: "smoke_message" ok(the "OpenClaw prebuilt gateway started" Telegram message was posted). - Neither log should contain
control_channel: deadline reachedorResource temporarily unavailablepast the first handshake retry. - Production initramfs must be present (
scripts/build_claude_rootfs.sh); if missing, mark this step as skipped with the reason. - Secrets must come from the user's shell env (e.g. via
! export …or a~/.anthropic-key-style file) — never paste them inline.
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.
- 3d ago First seen · 128 lines · 57 tokens per session scan A 1a9a437f8a0a
verify is a skill published in the GitHub repository the-void-ia/void-box (88 stars, last pushed 6d ago), licensed Apache-2.0. It adds 57 tokens to every session and 1,513 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
opentelemetry-net-instrumentation
Provides guidance for implementing OpenTelemetry instrumentation in .NET codebases, covering tracing (Activities/Spans), metrics, logs, naming conventions, error handling, performance, SDK setup, resources, context propagation, and API design best practices.
clawmetry-selfcheck
Read your own agent telemetry from ClawMetry (waste, progress, cost) and act on it before finishing a task. Use when ClawMetry is installed on this machine and you want to check whether you are re-reading files, spinning in loops, or burning budget.
migrate-state-management
Migrate Redux or React Context to the correct state option (React Query for server state, nuqs for URL/shareable state, Zustand for global client state). Use when refactoring away from Redux/Context, moving state to the right store, or when the user asks to migrate state management.
clawmetry
Real-time observability for OpenClaw agents — local dashboard + optional encrypted cloud sync. Tracks costs, tokens, sessions, tool calls, memory, crons, and system health. Access from anywhere via ClawMetry Cloud.
otel-collector
OpenTelemetry Collector component configuration. Use when authoring, reviewing, or debugging Collector YAML for a specific receiver, processor, exporter, connector, or extension — config keys, defaults, validation rules, signal support, stability levels, and component-level gotchas. Triggers on Collector component…
otel-declarative-config
OpenTelemetry declarative YAML configuration for SDK setup. Use when configuring OpenTelemetry SDK providers (tracer, meter, logger), setting up OTLP exporters, defining sampling strategies, or writing otel config files. Triggers on "otel config", "OpenTelemetry YAML", "declarative configuration", "otelconf"…