nvcf-explore-stack

作成者: nvidia

モノレポ内のNVCFセルフホストスタックをナビゲートし説明します。helmfileリリースを、そのチャート、イメージソースのサブツリー、helmフック、ネームスペースなどに対応付けます。

npx skills add https://github.com/nvidia/nvcf --skill nvcf-explore-stack

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.gotmpl
  • deploy/stacks/self-managed/helmfile.d/01-dependencies.yaml.gotmpl
  • deploy/stacks/self-managed/helmfile.d/02-core.yaml.gotmpl
  • deploy/stacks/self-managed/helmfile.d/03-observability.yaml.gotmpl
  • deploy/stacks/observability/helmfile.d/01-observability.yaml.gotmpl
  • deploy/stacks/nvcf-compute-plane/helmfile.d/01-dependencies.yaml.gotmpl
  • deploy/stacks/nvcf-compute-plane/helmfile.d/02-nvca.yaml.gotmpl

Chart-level (when the chart is checked into the monorepo):

  • deploy/helm/<chart>/Chart.yaml
  • deploy/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:

ConcernLives at
Helmfile orchestration (stage ordering, env wiring, secrets flow)deploy/stacks/self-managed/
Chart manifests, helm hooks, valuesdeploy/helm/<chart>/ when checked in; otherwise use the Helmfile chart reference
Runtime application code, migrationssrc/, 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-installation for installing, upgrading, or tearing down the stack
  • docs/dev/local-development.md for k3d / local cluster work
  • nvcf-self-managed-cli for nvcf-cli usage against an installed stack
  • docs/AGENTS.md and fern/versions/main.yml for routing the user to a published docs page
  • tools/ci/check-doc-version-sync for keeping the documentation manifest in sync with the docs version catalog

nvidiaのその他のスキル

compileiq-debug
nvidia
何かがおかしいときに使用:Search()がハングする、すべての評価がINVALID_SCOREを返す、スコアが改善しない、すべての設定が同じ数値を返す、ptxasエラー…
create-github-pr
nvidia
gh CLIを使用してGitHubのプルリクエストを作成します。ユーザーが新しいPRを作成したい、コードをレビューに提出したい、またはプルリクエストを開きたい場合に使用します。トリガーキーワード -…
nemoclaw-maintainer-cross-issue-sweep
nvidia
他のオープンなIssueをスキャンし、特定のPRが修正する可能性があるものや、誤って壊す可能性があるものを見つけます。隣接修正の機会や矛盾リスクをfile:line…と共に出力します。
fhir-basics
nvidia
エージェントにFHIR R4 APIの動作方法、利用可能なリソース、検索パラメータを使ったクエリ方法、およびすべてのレスポンス形式を正しく解析する方法を教えます…
compileiq-validate-result
nvidia
検索が完了した後、かつスピードアップの申請やACFの発送の前に使用します。dump_results CSVを読み込み、トップK候補(単一目的)を抽出します…
changelog-audit
nvidia
リリース前にWarp CHANGELOG.mdを監査:失われたエントリを復元、ユーザー影響で並べ替え、エントリの文言を洗練、行折り返し、および(リリースブランチモードで)比較をバンプ…
maintain-dynamic-plugins
nvidia
NeMo Relayの動的プラグインローダー、マニフェスト、RustネイティブSDK、gRPCワーカープロトコル、PythonワーカーSDK、ドキュメント、テスト、およびリリースワークフローのカバレッジを維持する
dgx-diagnose
nvidia
一般的なDGX Station GB300の問題(CUDAクラッシュ、誤ったGPUターゲット、vLLM/SGLangコンテナのバグ、MIG状態の問題、NVLink/Fabric Managerエラーなど)を診断します。