NVIDIA NVCF Explore Stack
Help a user or developer navigate the NVCF self-hosted stack inside the monorepo. Identify what a release is, what installs it, what it depends on, and which subtree owns the chart and the runtime image.
Instructions
This skill is for both NVCF users and NVCF developers. Users use it to understand stack dependencies, deployment order, and CI/CD migration questions. Developers use it to find the owning chart, source subtree, hook, or helmfile stage before making changes.
Use this skill long enough to answer the question, then hand off to the right execution skill. Always cite the source file path so the user can verify.
Required inputs
Read these from the monorepo root.
Authoritative (always read first when answering):
deploy/stacks/self-managed/helmfile.d/00-observability-infrastructure.yaml.gotmpldeploy/stacks/self-managed/helmfile.d/01-dependencies.yaml.gotmpldeploy/stacks/self-managed/helmfile.d/02-core.yaml.gotmpldeploy/stacks/self-managed/helmfile.d/03-observability.yaml.gotmpldeploy/stacks/observability/helmfile.d/01-observability.yaml.gotmpldeploy/stacks/nvcf-compute-plane/helmfile.d/01-dependencies.yaml.gotmpldeploy/stacks/nvcf-compute-plane/helmfile.d/02-nvca.yaml.gotmpl
Chart-level (when the chart is checked into the monorepo):
deploy/helm/<chart>/Chart.yamldeploy/helm/<chart>/values.yaml
Common questions
What deploys X
: Look up release X in the helmfile stage files. Return chart name, version, namespace, and which gotmpl file declares it. If the chart is checked in, also point at deploy/helm/<chart>/.
What does X depend on
: Return the needs: chain for that release plus the stage gate it sits behind (control-plane stages 0 -> 1 -> 2 -> 3, then compute-plane). Include any profile, condition:, or component mode that gates whether X deploys at all.
What hooks run for X
: Read the checked-in chart under deploy/helm/<chart>/ when available. Search its templates/ directory for Helm hook annotations, weights, hook events (pre-install / post-install), images used, and purpose. Cite the chart-relative template file path. If the chart is not checked in, cite its Helmfile chart reference and state that local templates are unavailable.
Walk me through the full deployment order
: Summarize control-plane stages 0 through 3 from the self-managed gotmpl files. Stage 0 delegates to the shared observability Helmfile when observability.profile is enabled. Stage 3 installs State Metrics and the function autoscaler for control and all. Then summarize the compute-plane stage from deploy/stacks/nvcf-compute-plane/helmfile.d/01-dependencies.yaml.gotmpl and deploy/stacks/nvcf-compute-plane/helmfile.d/02-nvca.yaml.gotmpl. Call out which releases run in parallel inside a stage and which are serialized by needs:.
Which subtree do I edit to change X
: Point at the Helmfile path for orchestration, deploy/helm/<chart>/ for checked-in chart wiring, and the image source under src/, infra/, or migrations/ for runtime behavior. If a referenced chart is not checked in, report its Helmfile chart reference and do not claim a local source path.
What namespaces does the stack use
: Return the list from the helmfile (namespace: per release).
Subtree mapping
The stack lives in three layers across the monorepo:
| Concern | Lives at |
|---|---|
| Helmfile orchestration (stage ordering, env wiring, secrets flow) | deploy/stacks/self-managed/ |
| Chart manifests, helm hooks, values | deploy/helm/<chart>/ when checked in; otherwise use the Helmfile chart reference |
| Runtime application code, migrations | src/, infra/, migrations/ |
When a question crosses layers, answer by layer and tell the user the order to edit (chart wiring first if the deploy contract changes, image source if behavior changes).
Tone
Assume the user is onboarding to the stack. Be concise. Always include the chart name, version, and the gotmpl path when referencing a release. Prefer one short paragraph plus a code-block citation over prose.
Skill handoff candidates
After exploring, suggest the next skill when applicable:
nvcf-self-managed-installationfor installing, upgrading, or tearing down the stackdocs/dev/local-development.mdfor k3d / local cluster worknvcf-self-managed-clifornvcf-cliusage against an installed stackdocs/AGENTS.mdandfern/versions/main.ymlfor routing the user to a published docs pagetools/ci/check-doc-version-syncfor keeping the documentation manifest in sync with the docs version catalog