What does this skill do, and when should you use it?
This skill is for operators bringing up NVIDIA Dynamo model endpoints on Kubernetes. It selects an existing recipe from the recipes tree using the requested model, framework, deployment mode, and GPU configuration, then performs preflight checks and lightweight validation. With cluster access, it applies model-cache and deployment manifests and runs a minimal OpenAI-compatible smoke test. It does not author new manifests, handle router-only work, or provide full day-two troubleshooting.
Reads the recipes tree, the selected recipe README, model-cache manifests, deploy.yaml, and perf.yaml when present; runs scripts/recipe_tool.py list and validate; checks Git status, Kubernetes context, storage classes, nodes, namespace, and the Hugging Face Secret; minimally patches storageClassName, image values, model paths, GPU resources, router mode, or namespace when required; applies manifests with kubectl and waits for resources; port-forwards the frontend service, checks /v1/models, and performs a basic chat-completion smoke test; reports the selected recipe, patched values, executed or pending commands, endpoint, smoke-test result, and unresolved blockers.
- A Kubernetes operator needs to bring up an existing Dynamo recipe for a specific model, vLLM, sglang, TRT-LLM, or tokenspeed framework, deployment mode, and GPU type/count.
- A cluster already has model-cache infrastructure and an HF Secret, but the recipe needs an environment-specific storage class, image tag, GPU setting, or router mode.
- An operator wants recipe discovery and validation before deployment, or needs exact commands because kubectl is unavailable or the cluster is unreachable.
- A deployment owner needs a minimal acceptance check that the Dynamo frontend exposes /v1/models and can serve one OpenAI-compatible chat request.
How do you install this skill?
- Obtain explicit user confirmation before kubectl apply, namespace creation, or Secret creation, and add change previews, rollback, and scope verification.
- Although the skill requires a Secret for the HF token, review logging, environment-variable exposure, third-party images, and model-download data flows before deployment.
- The benchmark verdict is FAIL and lacks real Tier 3 result details; do not treat the documented smoke test as proven success.
- The skill does not document Chinese interaction or Hugging Face/image reachability from mainland-China networks; additional configuration may be required.
- Shell / CLI
- Network access
- Local filesystem
Python 3.10+kubectlGitcurl
Install the individual skill with the supported skills CLI command: npx skills add nvidia/skills --skill dynamo-recipe-runner --yes. The supplied source does not document the exact destination folder selected by the CLI.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/dynamo-recipe-runner" ~/.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?
Ask an agent to use dynamo-recipe-runner to select and deploy a Dynamo Kubernetes recipe, supplying or permitting inference of the model, framework, deployment mode, GPU type/count, Kubernetes context, namespace, HF Secret, and storage class. Also specify whether commands should be executed or only produced. If the cluster is unreachable, it should perform selection and validation and return exact commands instead of claiming deployment success.
What are this skill's strengths and limitations?
- Works with existing recipes and limits changes to recipe-specific values.
- Covers a practical bring-up sequence from preflight and validation through deployment and endpoint smoke testing.
- Explicitly prevents writing Hugging Face tokens to files or logs.
- Includes symptom-based next steps for storage, PVC, Secret, image-pull, frontend, and connectivity issues.
- Requires Python 3.10+, kubectl, a usable Kubernetes context, and appropriate cluster permissions.
- Operates only on the existing recipes tree and does not author new manifests.
- Smoke testing is intentionally minimal; full router and endpoint coverage requires dynamo-router-starter.
- Multi-node disaggregated transport correctness is out of scope and requires dynamo-interconnect-check.
- The supplied material provides no concrete recipe inventory, deployment results, or platform-specific test evidence.
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 Recipe Runner this page ✓ NVIDIA · Official | 50 · Use with care | ★ 3.8k | today | Apache-2.0 |
| AI Runway AKS Deployment Guide ✓ Microsoft · Official | 51 · Use with care | ★ 2.7k | 3mo ago | MIT |
| Dynamo Interconnect Readiness Check ✓ NVIDIA · Official | 52 · Use with care | ★ 3.8k | today | Apache-2.0 |
| GKE Cluster Creation Advisor ✓ Google · Official | 48 · Use with care | ★ 22k | today | Apache-2.0 |
| GKE AI Inference Deployment Assistant ✓ Google · Official | 46 · Use with care | ★ 22k | today | Apache-2.0 |
Its scope differs from dynamo-router-starter, which is named for router-only mode work. Failed or unhealthy deployments should be handed to dynamo-troubleshoot, while multi-node disaggregated transport correctness should be checked with dynamo-interconnect-check.
How did FollowSkills review this skill?
The skill declares file_read, network, and kubectl_exec permissions; it requires read-only preflight checks, Kubernetes Secrets for the HF token, existing recipes only, and minimal patches. However, its default flow includes kubectl apply, namespace creation, and Secret creation without explicit stepwise user confirmation, pre-change backup, rollback instructions, or complete data-flow disclosure, so points are deducted.
The source provides recipe_tool.py discovery and lightweight validation, preflight commands, common blockers, and escalation paths. However, there are no committed tests for key paths, validation coverage is limited, readiness checks lack consistent timeout and diagnostic handling, shell commands coexist ambiguously with the run_script protocol, and the benchmark reports duplicate content, so points are deducted.
The intended audience, required inputs, model/framework/GPU/deployment-mode scenarios, non-fit ranges, and negative boundaries for router-starter and troubleshoot are reasonably clear; evals.json also includes positive and negative cases. Chinese-language interaction, mainland-China network reachability, and alternatives for Hugging Face access are not addressed, so points are deducted.
The files provide purpose, prerequisites, inputs, workflow, scripts, examples, an output contract, limitations, troubleshooting, references, Apache-2.0 licensing, and version 1.2.0 metadata. Changelog, stable maintenance ownership, and a clear update path are incomplete; the benchmark flags unexpected skill-card and signature files and duplicate content, so points are deducted.
The documented workflow covers selecting an existing recipe, validation, minimal patching, deployment, and an OpenAI-compatible smoke test, with a defined output contract. However, the static materials contain no successful deployment or directly usable third-party execution evidence, and the benchmark overall verdict is FAIL; the score is therefore limited by the static ceiling.
The evidence includes source code, evaluation cases, a static NVSkills-Eval report, CI references, and auditable commands. However, the benchmark lacks Tier 3 details and actual result signals, and there is no committed test suite covering the key paths or independent cross-source reproduction, so the static ceiling and deductions apply.
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 →