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 ndif-team/skills --skill troubleshootgit clone --depth 1 https://github.com/ndif-team/skillsWrote 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/ndif-team/skills/troubleshoot)<a href="https://agentmods.dev/skills/ndif-team/skills/troubleshoot"><img src="https://agentmods.dev/badge/skills/ndif-team/skills/troubleshoot/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/ndif-team/skills/troubleshoot"><img src="https://agentmods.dev/badge/skills/ndif-team/skills/troubleshoot.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.00181 | $0.04954 |
| Opus 5.5 | $0.00072 | $0.01982 |
| Sonnet 5.5 | $0.00036 | $0.00991 |
| Haiku 4.5 | $0.00018 | $0.00495 |
Grade A, and why
troubleshoot 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 18d 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.
curl -s localhost:8001/ping # "pong" — only proves the web process is alive How it starts
The opening of the file, as written. The whole thing — 321 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Troubleshooting a self-hosted NDIF
Triage first: decide which component to blame, then open the section. Anything
about the client's code rather than the server belongs to the nnsight plugin's
debugging and remote skills.
The first five commands
just ps # container status + health (compose), or `docker ps`
just logs api # follow one service: api | ray | dashboard | redis | minio
curl -s localhost:8001/ping # "pong" — only proves the web process is alive
curl -i localhost:8001/connected # 200 = Ray reachable, 503 = dispatcher reconnecting
ndif status # what the controller thinks is deployed, and where
Then ndif queue (asks the dispatcher directly, 5 s timeout), ndif doctor
(local prerequisites — only meaningful on a host install) and ndif version /
ndif env versus ndif env --local (version drift).
Run ndif version early. A large share of the confusing failures on this
page are a client and a server disagreeing about nnsight, transformers or torch.
Symptom index
| What you see | Section |
|---|---|
docker run exits immediately, could not select device driver ... [[gpu]] |
No GPU |
A compose container is Restarting, or api never starts with no logs |
A service will not start |
cuda_memory_bytes: 0 in the ray log; ndif status shows 0 nodes; No GPU nodes available. |
No GPU |
/connected says reconnecting, api logs Error connecting to Ray once a second |
Ray is still booting — or is not |
/ping 200 but every request hangs; redis-cli llen queue growing |
Healthy API, dead dispatcher |
A request sits in QUEUED / PROVISIONING / DEPLOYING for ages |
Stuck requests |
CANT_ACCOMMODATE: placed 0 of 1 new replicas... |
OOM on deploy vs OOM in a block |
CUDA out of memory ... N MiB allowed inside a user's block |
OOM on deploy vs OOM in a block |
ndif status cycles a replica RUNNING → UNHEALTHY |
OOM on deploy vs OOM in a block |
Job reaches COMPLETED, then the client fails to download |
COMPLETED but no result |
The model architecture on this server doesn't match... / Your request payload could not be read (...) |
Version mismatch |
Starting Ray client server failed after ~40 s, from ndif status or the dashboard |
Ray client server failed |
| A code change has no effect | The stale image |
The dashboard returns JSON instead of a UI, or 503s on /api/status |
Dashboard problems |
| Grafana panels are empty | Telemetry missing |
ndif queue prints No response from the dispatcher |
the API is down, not Redis — restart api |
ndif evict gpt2 prints nothing to evict |
model-key mismatch (revision is part of the key), or the replica is only WARM |
What ships with it
2 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.
- 18d ago First seen · 321 lines · 181 tokens per session scan A 044ee57dad09
troubleshoot is a skill published in the GitHub repository ndif-team/skills (14 stars, last pushed yesterday), licensed MIT. It adds 181 tokens to every session and 4,954 once invoked, about $0.0007 per session on Opus 5.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-09-16.
Other skills, from other repositories
image-pull-debug
Diagnose container image pull failures (ErrImagePull / ImagePullBackOff). Checks pod status, containerd logs, and events to identify root cause.
pod-pending-debug
Diagnose pod scheduling failures (Pending, Unschedulable). Checks events, node resources, taints, affinity, and PVC bindings to identify why a pod cannot be scheduled.
gke-workload-troubleshooting
Systematic Standard Operating Procedure (SOP) for diagnosing GKE workload failures, crash loops, resource OOMs, mounting errors, and connectivity timeouts.
kubernetes-specialist
Use when managing Kubernetes clusters, debugging Pods and workloads, designing Helm charts, reviewing manifests, or improving deployment, scaling, and observability practices.
node
OpenShift Node team assistant. Covers kubelet, MCO, CRI-O, crun, conmonrs, Kueue operator, Jira (OCPNODE/OCPBUGS), Red Hat KB/support cases, Prometheus, and K8s/OCP docs. Triggers on OpenShift node-layer development, deployment, debugging, or team workflow tasks. For CVE/vulnerability triage, analysis, or reporting…
archestra-dev-investigate
Use when investigating Archestra bugs or incidents — staging issues, backend 50x errors, Drizzle failed queries, DB connection pressure, deploy regressions, or Kubernetes/runtime symptoms. Orientation only; defers the process to /investigate.