What does this skill do, and when should you use it?
This skill starts or patches Dynamo frontend routing modes and runs endpoint smoke checks. It covers round-robin, KV-aware, least-loaded, device-aware-weighted, direct, and random routing. It supports local Python frontends and Kubernetes deployments, provided workers and a loaded model already exist. Its check is a single-request smoke test, not a full throughput or latency benchmark.
It collects the runtime path, routing mode, frontend port or Kubernetes service, KV-event availability, and model name; starts a local Dynamo frontend or guides a Kubernetes frontend environment patch; enables approximate KV mode when workers do not publish KV events; runs scripts/check_router_health.py to verify /v1/models and, when a model is discoverable, one /v1/chat/completions request; and routes empty model lists, timeouts, KV hangs, and port-forward failures to concrete next steps.
- A Dynamo developer needs to start a round-robin frontend after workers are registered.
- A platform engineer wants to enable KV routing in a Kubernetes recipe and validate the service through port-forwarding.
- An operator needs to confirm that the frontend discovers a model and completes one chat request.
- A routing experimenter needs a smoke comparison of round-robin and KV routing under matched model, worker, prompt, concurrency, and sampling settings.
How do you install this skill?
- Before execution, confirm the target frontend, Kubernetes namespace, and configuration-change scope, and prepare a manual rollback plan.
- A passing smoke check does not demonstrate throughput or latency improvement; use a separate benchmark with matched workloads.
- Confirm compatibility between the deployed Dynamo version, script arguments, and KV-event settings; Chinese documentation and mainland-China network fit are not evidenced.
- The supplied license metadata is NOASSERTION even though the files declare Apache-2.0; verify licensing and attribution before publication.
- Shell / CLI
- Network access
- Local filesystem
Python 3.10+dynamo Python packagekubectl for Kubernetes runs
Install the specific skill with the default skills CLI:
npx skills add nvidia/skills --skill dynamo-router-starter --yes
The README does not document a standalone source repository or manual folder-copy procedure for this skill. The catalog is synced daily from product repositories.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/dynamo-router-starter" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Example trigger: Start or patch the Dynamo router and check the frontend endpoint.
Start a local round-robin frontend:
python3 -m dynamo.frontend --router-mode round-robin --http-port 8000
Start local KV routing and check it:
python3 -m dynamo.frontend --router-mode kv --http-port 8000
python3 scripts/check_router_health.py --base-url http://127.0.0.1:8000
For Kubernetes, port-forward the frontend service and run the same checker. If workers do not publish KV events, set DYN_ROUTER_USE_KV_EVENTS to false.
What are this skill's strengths and limitations?
- Covers six explicitly named Dynamo routing modes.
- Supports both local frontend and Kubernetes workflows.
- Provides an executable /v1/models and chat-completion smoke check.
- Clearly separates smoke validation from formal performance benchmarking.
- The smoke test makes only one chat-completion request and cannot establish throughput improvement.
- Without worker KV events, routing falls back to approximate KV mode; the skill does not repair worker configuration.
- Cross-mode latency claims require separate benchmark runs with matched workloads.
- Kubernetes use requires an already deployed Dynamo recipe, namespace access, and network reachability.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Dynamo Router Starter this page ✓ NVIDIA · Official | 53 · Use with care | ★ 3.8k | today | Apache-2.0 |
| Dynamo Deployment Troubleshooter ✓ NVIDIA · Official | 52 · Use with care | ★ 3.8k | today | Apache-2.0 |
| Dynamo Interconnect Readiness Check ✓ NVIDIA · Official | 52 · Use with care | ★ 3.8k | today | Apache-2.0 |
| Dynamo Recipe Runner ✓ NVIDIA · Official | 50 · Use with care | ★ 3.8k | today | Apache-2.0 |
| GKE ComputeClasses Advisor ✓ Google · Official | 57 · Use with care | ★ 22k | today | Apache-2.0 |
The source explicitly directs unhealthy endpoints or missing workers to dynamo-troubleshoot, and throughput or latency measurement to dynamo-benchmark.
How did FollowSkills review this skill?
The skill is scoped mainly to starting a frontend, changing Kubernetes frontend environment variables, and issuing health-check requests. No credential theft, covert exfiltration, or destructive default is evident. However, it lacks explicit user confirmation before configuration changes or service startup, least-privilege guidance, rollback steps, and sensitive-data handling notes, so points are deducted. Official NVIDIA provenance and the in-skill Apache-2.0 declaration support attribution, but the supplied license metadata is NOASSERTION, leaving governance uncertainty.
The workflow, mode mapping, health-check script, and troubleshooting handoff are broadly consistent. The script includes HTTP/JSON/URL validation, retries, and structured exit codes. Static materials do not include committed tests covering this skill's key paths, retry arguments lack boundary validation, and Dynamo/Kubernetes version compatibility is not verified; the score is therefore conservative and within the static ceiling.
Audience, modes, prerequisites, inputs, output contract, negative cases, and the boundary with troubleshooting are reasonably clear. Triggering still depends on agent judgment, while Chinese-language support, version-environment fit, and mainland-China network reachability are not addressed. The core function relies on local or Kubernetes resources rather than an entirely unreachable overseas service, so no additional network deduction is applied.
The documentation includes purpose, prerequisites, procedures, script arguments, examples, output contract, limitations, troubleshooting, references, and a version note, giving it a usable structure. However, the cited version source is not supplied, maintenance ownership, changelog, dependency pinning, and upgrade/rollback paths are incomplete, and the benchmark reports unexpected files in the skill directory, so points are deducted.
The skill directly addresses router-mode bring-up and endpoint smoke testing, and the script produces a directly usable health result. Its check covers only one chat request, mode comparison is not benchmarking, and the static materials contain no verifiable successful execution output or third-party run evidence, preventing a higher score.
The SKILL file, mode reference, script, evaluation cases, and static evaluation report provide auditable evidence, including positive and negative invocation cases. However, the report explicitly lacks Tier 3 execution results and detailed signals, with no real key-path execution evidence or independent corroboration; only limited credit is justified.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →