[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71QBN321JBPRXZWM94FA31V":3,"skill-same:01M71QBN321JBPRXZWM94FA31V":196},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":14,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":59,"install":60,"resources":73},"01M71QBN321JBPRXZWM94FA31V","vss-deploy-profile",null,"Use to select, configure, deploy, verify, debug, or tear down a VSS profile (base, search, lvs, warehouse, edge). Not for standalone microservices — use the vss-deploy-* skill.","pattanation\u002FNorvik","pattanation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235419268?v=4","01M71M5THHYYB15ME8R2E4FCZG","Patta","01M71M5TJM1NDM992M8PDKYR2K",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"deploy","profile","vss deploy profile","github","microservices","debug","use","edge","deployment","for","down","NVIDIA","warehouse","configure","Blueprint","search","select","LVS","standalone","Video","2026-11-10 13:02:02",false,"---\nname: vss-deploy-profile\ndescription: Use to select, configure, deploy, verify, debug, or tear down a VSS profile (base, search, lvs, warehouse, edge). Not for standalone microservices — use the vss-deploy-* skill.\nlicense: Apache-2.0\nmetadata:\n  version: \"3.2.0\"\n  github-url: \"https:\u002F\u002Fgithub.com\u002FNVIDIA-AI-Blueprints\u002Fvideo-search-and-summarization\"\n  tags: \"nvidia blueprint deployment\"\n---\n# VSS Deploy\n\n## Available Scripts\n\n| Script | Purpose | Arguments |\n|---|---|---|\n| `scripts\u002Fnormalize_resolved_yml.py` | Strip optional `depends_on` entries for services filtered out of `resolved.yml` before deploy. | Path to `resolved.yml` |\n| `scripts\u002Fprobe_remote_models.sh` | Probe an OpenAI-compatible remote LLM\u002FVLM endpoint and verify the selected model id. | Base URL, optional expected model id |\n\n## Profile Routing\n\nMatch the user's request to a profile, then load that profile's reference for sizing, services, env recipes, and debugging.\n\n| User says | Profile | Reference |\n|---|---|---|\n| \"deploy vss\" \u002F \"deploy base\" | `base` | [`references\u002Fbase.md`](references\u002Fbase.md) |\n| \"deploy alerts\" \u002F \"alert verification\" \u002F \"real-time alerts\" \u002F \"deploy for incident report\" | `alerts` | [`references\u002Falerts.md`](references\u002Falerts.md) |\n| \"deploy lvs\" \u002F \"video summarization\" | `lvs` | [`references\u002Flvs-profile.md`](references\u002Flvs-profile.md) |\n| \"deploy search\" \u002F \"video search\" | `search` | [`references\u002Fsearch.md`](references\u002Fsearch.md) |\n| \"deploy warehouse\" \u002F \"warehouse blueprint\" \u002F \"vss warehouse\" | `warehouse` | [`references\u002Fwarehouse.md`](references\u002Fwarehouse.md) |\n| \"debug warehouse\" \u002F \"warehouse not working\" \u002F \"warehouse FPS low\" \u002F \"warehouse BEV out of sync\" | `warehouse` (debug) | [`references\u002Fwarehouse-debug.md`](references\u002Fwarehouse-debug.md) |\n\n**Edge hardware routing** (DGX Spark, AGX\u002FIGX Thor): see [`references\u002Fedge.md`](references\u002Fedge.md). DGX Spark uses the Spark Nano 9B standalone local LLM on port `30081`; AGX\u002FIGX Thor uses the Edge 4B standalone vLLM fallback.\n\n**Each profile's reference owns its sizing table.** Don't pick a deployment shape from this file — open the profile reference and check minimum GPU count for the host's hardware against the (mode × platform) matrix there.\n\n## Instructions\n\nThe deployment flow is always: copy `.env` to `generated.env`, apply overrides, dry-run compose into `resolved.yml`, review, normalize, deploy, then wait for readiness.\n\n```bash\n# 1. cp dev-profile-\u003Cprofile>\u002F.env dev-profile-\u003Cprofile>\u002Fgenerated.env  (clean copy)\n# 2. Apply env overrides to generated.env  (source .env stays untouched)\n# 3. docker compose --env-file generated.env config > resolved.yml      (dry-run)\n# 4. Review resolved.yml\n# 5. docker compose --env-file generated.env -f resolved.yml up -d\n```\n\n`.env` is read-only checked-in defaults; `generated.env` is the per-deploy working copy. Step 1c covers this in full.\n\n## Prerequisites\n\n1. **Repo path** — auto-detect `video-search-and-summarization\u002F` before\n   asking the user. Use the detected path as `$REPO` for all subsequent\n   commands.\n2. **Credential gates** — see [`references\u002Fcredentials.md`](references\u002Fcredentials.md): `NGC_CLI_API_KEY` for local\u002Flocal_shared NIM pulls, `NVIDIA_API_KEY` for remote NIM endpoints, and `HF_TOKEN` for edge recipes that use gated HF models.\n3. **System prerequisites (GPU driver, Docker, NVIDIA Container Toolkit, kernel sysctls, and — if `ufw` is active — the [Docker-bridge→host firewall allow](references\u002Fprerequisites.md#firewall) so bridge NIMs can fetch clips from host-mode VST)** — full checks in [`references\u002Fprerequisites.md`](references\u002Fprerequisites.md). Canonical hardware\u002Fdriver matrix is the [VSS prerequisites page](https:\u002F\u002Fdocs.nvidia.com\u002Fvss\u002F3.2.0\u002Fprerequisites.html).\n\nThe auto-detect snippet (git-root, then a common-path probe gated on\n`deploy\u002Fdocker\u002Fcompose.yml` + `dev-profile.sh` + `skills\u002Fvss-deploy-profile`)\nlives in [`references\u002Fprerequisites.md`](references\u002Fprerequisites.md#repo-detect).\nExport the resolved `$REPO`; if detection fails, ask the user for the checkout path.\n\n### Pre-flight check\n\nRun before every deploy. The full system checklist and remediation steps live\nin [`references\u002Fprerequisites.md`](references\u002Fprerequisites.md#preflight).\nFor DGX Spark \u002F IGX Thor \u002F AGX Thor, also run the cache-cleaner check in\n[`references\u002Fedge.md`](references\u002Fedge.md#cache-cleaner-every-edge-deploy).\n\n**Detect sudo mode first.** Several pre-flight remediations and the\nedge cache-cleaner installer call `sudo`. If the host requires a\nsudo password, those steps will silently no-op under `sudo -n` and\nleave the deploy in a half-prepared state.\n\n```bash\nif sudo -n true 2>\u002Fdev\u002Fnull; then\n  echo \"passwordless sudo — pre-flight will auto-install missing pieces\"\nelse\n  echo \"sudo requires password — pre-flight will NOT auto-install; hand commands to the user\"\nfi\n```\n\nWhen sudo needs a password, the skill **must not** run privileged\ninstallers itself. Surface the copy-pasteable command block from\n`references\u002Fprerequisites.md` to the user with a *\"run this once and\nconfirm\"* handoff, then resume after the user replies.\n\nMinimum smoke test (must succeed):\n\n```bash\nnvidia-smi --query-gpu=index,name --format=csv,noheader\ndocker info 2>\u002Fdev\u002Fnull | grep -qi runtimes \\\n  && docker run --rm --gpus all ubuntu:22.04 nvidia-smi >\u002Fdev\u002Fnull 2>&1 \\\n  && echo \"nvidia runtime OK\"\n```\n\nIf the smoke test fails, do not proceed; open\n[`references\u002Fprerequisites.md`](references\u002Fprerequisites.md#preflight)\nfor the remediation tree.\n\n## Model Selection\n\n- `$LLM_REMOTE_URL` \u002F `$VLM_REMOTE_URL` if the user asks for remote\n- `$NGC_CLI_API_KEY` (local NIMs) or `$NVIDIA_API_KEY` (remote)\n\n**Endpoint intent gate.** Don't infer remote placement from stray env vars\n(`LLM_ENDPOINT_URL`, `VLM_ENDPOINT_URL`, `LLM_BASE_URL`, `VLM_BASE_URL` may be\nleftovers). Use remote LLM\u002FVLM only when (1) the user asked for \u002F supplied a\nremote endpoint, (2) local sizing can't fit the selected models and the user\nagrees, or (3) an edge recipe needs a standalone local service VSS treats as\n`remote` (e.g. DGX Spark Nano 9B on `localhost:30081`). If an endpoint var is\nset but the user didn't ask for remote, surface it in Step 1 and ask — never\nsilently deploy remote because a var happened to exist.\n\nIf no combination on this host satisfies the profile's sizing requirements, **stop and report the blocker** — don't silently pick another shape.\n\n> **Edge shared mode is platform-specific.** Full recipes are in [`references\u002Fedge.md`](references\u002Fedge.md).\n\n## Deployment Flow\n\nAlways follow this sequence. Never skip the dry-run.\n\n### Step 0 — Tear down any existing deployment + clear data volumes\n\nIf a deployment already exists, tear it down AND clear stale data volumes before redeploying. \n\nFull procedure lives in [`references\u002Fteardown.md`](references\u002Fteardown.md).\n\n### Step 0a — Credentials gate (run before any env mutation)\n\nValidate every credential and selected remote endpoint the chosen profile\nneeds **before** Step 1c copies `.env` to `generated.env`. A 401 here is a\n30-second failure; the same 401 inside a NIM cold-start is a 10–20 min\nfailure. Run the discovery and probe flow in\n[`references\u002Fcredentials.md`](references\u002Fcredentials.md), including\n`scripts\u002Fprobe_remote_models.sh` for any LLM\u002FVLM endpoint you plan to write\ninto `generated.env`. Map the result against the chosen mode: missing\nor invalid required credentials\u002Fendpoints are blockers, optional credentials\nare not.\n\n### Step 1 — Gather context\n\nBefore building env overrides, confirm:\n\n| Value | How to determine |\n|---|---|\n| **Profile** | Match user intent to the routing table above. Default: `base` |\n| **Repo path** | Use the `$REPO` value auto-detected in prerequisites. If auto-detect failed, ask the user for the checkout path before continuing. |\n| **Hardware** | `nvidia-smi --query-gpu=name,memory.total --format=csv,noheader` |\n| **LLM\u002FVLM placement** | Explicitly decide local \u002F local_shared \u002F remote. Cross-reference available GPUs against the chosen profile's **Minimum GPU count** table. If endpoint env vars are present but the user did not request remote, ask whether to use or ignore them. |\n| **API keys** | `NGC_CLI_API_KEY` for local NIMs, `NVIDIA_API_KEY` for remote |\n| **`HOST_IP`** | In-cluster dial address: `ip route get 1.1.1.1` src (like `dev-profile.sh`; correct on LAN + cloud). If that interface is a VPN\u002Ftunnel, fall back to the LAN IP and **prompt the user** — [Network addressing](references\u002Fprerequisites.md#addressing). |\n| **`EXTERNAL_IP`** | Browser-facing address; defaults to `${HOST_IP}`. Override when the browser path differs — cloud public IP, Brev secure-link (Step 1d), or tunnel; **ask the user where they browse from if unsure**. [Network addressing](references\u002Fprerequisites.md#addressing). |\n| **`HAPROXY_PORT`** | Browser-facing ingress port. Default `7777`; ensure it is free. |\n\nBefore `docker compose up`, verify `EXTERNAL_IP`, `HAPROXY_PORT`, `VSS_PUBLIC_HOST`, and `VSS_PUBLIC_PORT` are populated with browser-reachable values. Otherwise the stack may appear healthy while UI\u002FAPI\u002FVST links 404 or loop through Cloudflare Access.\n\n### Step 1b — Prepare the data directory\n\nLayout (asset paths, ownership, mount points, profile-specific subdirs) is documented in [`references\u002Fdata-directory.md`](references\u002Fdata-directory.md). Read that file before deploying for the first time on a host or when changing profiles.\n\n\n### Step 1c — Initialize `generated.env`\n\nThe skill's per-deploy working copy. Always start from a fresh copy of the source `.env` , never mutate the source.\n\n```bash\nPROFILE=base\nENV_SRC=$REPO\u002Fdeploy\u002Fdocker\u002Fdeveloper-profiles\u002Fdev-profile-$PROFILE\u002F.env\nENV_GEN=$REPO\u002Fdeploy\u002Fdocker\u002Fdeveloper-profiles\u002Fdev-profile-$PROFILE\u002Fgenerated.env\n\ncp \"$ENV_SRC\" \"$ENV_GEN\"\n```\n\nAll subsequent writes (Brev `EXTERNAL_IP`, the env_overrides dict from Step 2) go to `$ENV_GEN`. `$ENV_SRC` is read-only from here on.\n\n### Step 1d — Brev only: detect first, then set `EXTERNAL_IP` to the secure-link domain\n\n**Detect Brev before anything else** — a Brev-provisioned instance sets `BREV_ENV_ID` in `\u002Fetc\u002Fenvironment`; nothing else does:\n\n```bash\ngrep -qE '^BREV_ENV_ID=' \u002Fetc\u002Fenvironment && echo \"on Brev\" || echo \"not Brev\"\n```\n\n- **not Brev** → skip the rest of this step and **do not read [`references\u002Fbrev.md`](references\u002Fbrev.md)**; keep the normal `${HOST_IP}`-based `EXTERNAL_IP`.\n- **on Brev** → apply the Brev secure-link overrides from [`references\u002Fbrev.md` § Setup flow](references\u002Fbrev.md#setup-flow) to `generated.env` (NOT `.env`). Those set `EXTERNAL_IP` \u002F `VSS_PUBLIC_HOST` to the secure-link domain **and** `VSS_PUBLIC_HTTP_PROTOCOL=https` \u002F `VSS_PUBLIC_WS_PROTOCOL=wss` \u002F `VSS_PUBLIC_PORT=443` — setting `EXTERNAL_IP` alone leaves `http:\u002F\u002F…:7777` UI\u002FAPI\u002FWS links that the browser blocks as mixed content.\n\n### Step 2 — Build env_overrides\n\nProduce an `env_overrides` dict from the user request and the gathered\ncontext: explicitly choose remote\u002Flocal LLM\u002FVLM, set credentials, point at\nendpoints, set platform-specific flags. Do not let existing shell env vars\nsilently pick placement; write the selected `LLM_MODE` \u002F `VLM_MODE` and\nmatching endpoint\u002Fmodel fields into `generated.env`. The full mapping (every\noverride key, when it applies, defaults, profile-specific differences) lives\nin [`references\u002Fenv-overrides.md`](references\u002Fenv-overrides.md). Each profile\nreference has worked examples for that profile's common scenarios.\n\n\n### Step 3 — Apply overrides + dry-run\n\n**Working env file:** `\u003Crepo>\u002Fdeploy\u002Fdocker\u002Fdeveloper-profiles\u002Fdev-profile-\u003Cprofile>\u002Fgenerated.env` (created in Step 1c).\n\n> **Reminder (see Step 1c):** apply all overrides (Step 2 dict + Brev `EXTERNAL_IP`) to `generated.env`; `--env-file` always points at it, and post-deploy verifiers read it for the actually-deployed values.\n\n```bash\n# (Step 1c already ran: cp $ENV_SRC $ENV_GEN)\n\n# Apply the env_overrides dict from Step 2 to generated.env\n# (read lines, update matching keys, append new keys, write)\n# Example:\n#   sed -i \"s|^LLM_MODE=.*|LLM_MODE=remote|\" \"$ENV_GEN\"\n#   sed -i \"s|^LLM_BASE_URL=.*|LLM_BASE_URL=http:\u002F\u002Flocalhost:30081|\" \"$ENV_GEN\"\n\n# Resolve compose\ncd $REPO\u002Fdeploy\u002Fdocker\ndocker compose --env-file $ENV_GEN config > resolved.yml\n```\n\nThe resolved YAML is saved to `\u003Crepo>\u002Fdeploy\u002Fdocker\u002Fresolved.yml`.\n\n### Step 3b — Verify resolved.yml has no unexpanded ${...} tokens\n\nUnexpanded `${VAR}` tokens in `resolved.yml` mean compose did not see those env values. Diagnostic procedure and common culprits live in [`references\u002Ftroubleshooting.md`](references\u002Ftroubleshooting.md).\n\n\n### Step 3c — Verify access to selected NGC artifacts\n\nDo this after `resolved.yml` exists and before `docker compose up`. The NGC\ntoken probe in Step 0a proves only that the key authenticates; it does not\nprove the key's org\u002Fteam can access the selected image or model repositories.\n\nBuild the artifact list from the actual selected deployment:\n\n- `resolved.yml`: every `image:` under `nvcr.io\u002F...` that Compose will pull.\n- `$ENV_GEN`: NGC-backed model\u002Fresource paths such as\n  `RTVI_VLM_MODEL_PATH=ngc:nim\u002Fnvidia\u002Fcosmos-reason2-8b:hf-1208`. Skip\n  `none`, `git:...`, local paths, and remote endpoint URLs.\n- Profile staging steps: any NGC model\u002Fresource downloads documented in the\n  profile reference, such as alerts\u002Fsearch perception model staging.\n\nProbe each selected artifact with the normalized NGC key before continuing:\n\n- Container images: `docker manifest inspect \u003Cnvcr.io\u002F...>` after `docker\n  login nvcr.io` — for gated `nvcr.io` repos a `401`\u002F`403` here is a definitive\n  no-entitlement signal (manifest read requires the same org\u002Fteam grant as the\n  layer pull); or the matching `ngc registry image info ...` when the artifact\n  maps cleanly to an NGC image path.\n- NGC model\u002Fresource paths (e.g. the Cosmos checkpoint RT-VLM downloads at\n  runtime): run the matching `ngc registry model info ...` or `ngc registry\n  resource info ...` for the exact repo\u002Ftag the profile will load or download;\n  these use NGC's scoped auth. Do NOT probe a model with `docker manifest\n  inspect` (returns \"no such manifest\" because a model is not an OCI image) or a\n  raw `Authorization: Bearer \u003Ckey>` REST call (returns `403` because that is not\n  NGC's auth flow); both are expected false negatives, not entitlement failures.\n  If the `ngc` CLI is unavailable, treat the container-image probe above as the\n  entitlement signal, since NGC grants org\u002Fteam access across images and models\n  together.\n- Profile-staged TAO\u002Fperception models: run the corresponding `ngc registry\n  model info ...` \u002F `resource info ...` for each repo\u002Ftag before the staging\n  block downloads files.\n\nIf any probe returns `401`, `403`, `permission`, `not being a member of the\norganization that owns the repo`, missing org\u002Frepo, or a similar access error,\nstop and prompt the user for an NGC key from an org\u002Fteam entitled to those\nartifacts. Do not start Compose and discover the failure during NIM cold start.\n\n### Step 3d — Strip dangling optional `depends_on` from resolved.yml\n\n\n**MUST run after Step 3, before Step 5.** Skipping this aborts the deploy:\n\nNormalize - drop optional dependencies for services filtered out from resolved.yml\n\n```bash\n# From the repo root\nuv run skills\u002Fvss-deploy-profile\u002Fscripts\u002Fnormalize_resolved_yml.py \"$REPO\u002Fdeploy\u002Fdocker\u002Fresolved.yml\"\n```\nIf `uv` isn't on the host, install it once with `curl -LsSf https:\u002F\u002Fastral.sh\u002Fuv\u002Finstall.sh | sh` (no root needed).\n**Re-validate** before `up -d`:\n\n```bash\ndocker compose -f \"$REPO\u002Fdeploy\u002Fdocker\u002Fresolved.yml\" config --quiet && echo \"resolved.yml OK\"\n```\n\nIf validation still fails after the normalizer runs, capture the error and inspect — that's a different bug (a dependency that's not optional, or another schema violation), not the dangling-depends_on case.\n\n### Step 4 — Review\n\nShow the user a summary of what will be deployed:\n\n- Profile name and hardware\n- LLM\u002FVLM models and mode (local\u002Fremote\u002Flocal_shared)\n- Services that will start\n- GPU device assignment\n- Key endpoints (UI port, agent port)\n\nAsk: **\"Looks good — deploy now?\"** and wait for confirmation before Step 5.\n\n**Exception — autonomous mode.** If the user's request already asks you to run autonomously (e.g. \"deploy X autonomously\", \"run without confirmation\", \"non-interactive\"), skip the confirmation prompt and proceed straight to Step 5. This path exists so automated eval \u002F CI invocations don't hang waiting for a human reply they'll never get. In all other cases, a human must approve.\n\n### Step 5 — Deploy\n\n```bash\ncd $REPO\u002Fdeploy\u002Fdocker\ndocker compose --env-file $ENV_GEN -f resolved.yml up -d\n```\n\n> **`--env-file` is mandatory.** Without the same `generated.env` used in Step 3, `COMPOSE_PROFILES` may be unset and `up -d` can exit 0 with zero selected services.\n\n> **Avoid broad `--force-recreate` on ordinary retries** — it destroys warm\n> NIM containers (another 3–5 min torch.compile + CUDA-graph capture each).\n> Fix the root cause (usually perms or an env typo) and just re-run `up -d`;\n> use targeted `--force-recreate --no-deps \u003Cservice...>` only when a profile\n> reference documents it as the recovery path.\n\n`docker compose up -d` only creates containers; it does not wait for internal services to finish warming. Never declare deploy success until the readiness gates pass.\n\n### Step 5b — Wait until the stack is actually healthy\n\n**Gate 0 — container count must be > 0.** Refuse to proceed past `up -d` until the started count (`docker compose -f resolved.yml ps -q | wc -l`) is non-zero and ≥ the expected count (`config --services | wc -l`); a zero\u002Fshort count almost always means a missing `--env-file` in Step 5. The exact gate plus the full readiness procedure live in [`references\u002Freadiness.md`](references\u002Freadiness.md).\n\nCold deploys can take 10–20 min, and each profile reference lists the required endpoints. **Never declare deploy done after `up -d`; only after every documented endpoint succeeds.**\n\n## Tear Down\n\nTo tear down a deployment — full host reclaim or cache-preserving redeploy \u002F profile\nswitch — follow [`references\u002Fteardown.md`](references\u002Fteardown.md). Always tear down\nby the `mdx` project with `-v --remove-orphans`; a plain `docker compose down` leaves\nvolumes and networks behind.\n\n## Debugging a Deployment\n\nUse this workflow when the user asks to \"debug the deploy\", \"verify it's working\", \"why is the agent not responding\", or similar. The goal is to confirm the full video-ingestion-to-agent-answer path, not just that containers are \"Up\".\n\nEach profile reference has a **Debugging** section listing the exact commands and failure-mode table for that profile.\n\n### Quick checks (all profiles)\n\n```bash\n# 1. All expected containers Up\ndocker ps --format 'table {{.Names}}\\t{{.Status}}'\n\n# 2. Agent API + UI responding\ncurl -sf http:\u002F\u002Flocalhost:8000\u002Fhealth >\u002Fdev\u002Fnull && echo \"agent OK\"\ncurl -sf http:\u002F\u002Flocalhost:3000\u002F >\u002Fdev\u002Fnull && echo \"ui OK\"\n```\n\nThe LLM\u002FVLM NIM probes — including the `*_MODE=remote` handling that skips\n`localhost:3008x` (where a connection refused is expected) and probes the\nselected `*_BASE_URL\u002Fv1\u002Fmodels` via `scripts\u002Fprobe_remote_models.sh` — are in\n[`references\u002Ftroubleshooting.md`](references\u002Ftroubleshooting.md#nim-probes).\n\n## Limitations\n\n- This skill deploys compose-based VSS profiles only; standalone microservice deployment belongs to the matching `vss-deploy-*` skill.\n- Hardware sizing, model placement, and profile-specific readiness are owned by profile references; do not infer them from memory.\n- Privileged host remediation requires user approval when passwordless sudo is unavailable.\n\n## Troubleshooting\n\nThe common-error quick reference, the full symptom → cause → fix table, the\nunexpanded-`${...}` diagnostic, and the NIM endpoint probes are consolidated in\n[`references\u002Ftroubleshooting.md`](references\u002Ftroubleshooting.md) — start there\nfor any deploy, runtime, or probe failure, then continue in the matching\nper-profile reference's Debugging section.\n","# VSS Deploy\n\n## Available Scripts\n\n| Script | Purpose | Arguments |\n|---|---|---|\n| `scripts\u002Fnormalize_resolved_yml.py` | Strip optional `depends_on` entries for services filtered out of `resolved.yml` before deploy. | Path to `resolved.yml` |\n| `scripts\u002Fprobe_remote_models.sh` | Probe an OpenAI-compatible remote LLM\u002FVLM endpoint and verify the selected model id. | Base URL, optional expected model id |\n\n## Profile Routing\n\nMatch the user's request to a profile, then load that profile's reference for sizing, services, env recipes, and debugging.\n\n| User says | Profile | Reference |\n|---|---|---|\n| \"deploy vss\" \u002F \"deploy base\" | `base` | [`references\u002Fbase.md`](references\u002Fbase.md) |\n| \"deploy alerts\" \u002F \"alert verification\" \u002F \"real-time alerts\" \u002F \"deploy for incident report\" | `alerts` | [`references\u002Falerts.md`](references\u002Falerts.md) |\n| \"deploy lvs\" \u002F \"video summarization\" | `lvs` | [`references\u002Flvs-profile.md`](references\u002Flvs-profile.md) |\n| \"deploy search\" \u002F \"video search\" | `search` | [`references\u002Fsearch.md`](references\u002Fsearch.md) |\n| \"deploy warehouse\" \u002F \"warehouse blueprint\" \u002F \"vss warehouse\" | `warehouse` | [`references\u002Fwarehouse.md`](references\u002Fwarehouse.md) |\n| \"debug warehouse\" \u002F \"warehouse not working\" \u002F \"warehouse FPS low\" \u002F \"warehouse BEV out of sync\" | `warehouse` (debug) | [`references\u002Fwarehouse-debug.md`](references\u002Fwarehouse-debug.md) |\n\n**Edge hardware routing** (DGX Spark, AGX\u002FIGX Thor): see [`references\u002Fedge.md`](references\u002Fedge.md). DGX Spark uses the Spark Nano 9B standalone local LLM on port `30081`; AGX\u002FIGX Thor uses the Edge 4B standalone vLLM fallback.\n\n**Each profile's reference owns its sizing table.** Don't pick a deployment shape from this file — open the profile reference and check minimum GPU count for the host's hardware against the (mode × platform) matrix there.\n\n## Instructions\n\nThe deployment flow is always: copy `.env` to `generated.env`, apply overrides, dry-run compose into `resolved.yml`, review, normalize, deploy, then wait for readiness.\n\n```bash\n# 1. cp dev-profile-\u003Cprofile>\u002F.env dev-profile-\u003Cprofile>\u002Fgenerated.env  (clean copy)\n# 2. Apply env overrides to generated.env  (source .env stays untouched)\n# 3. docker compose --env-file generated.env config > resolved.yml      (dry-run)\n# 4. Review resolved.yml\n# 5. docker compose --env-file generated.env -f resolved.yml up -d\n```\n\n`.env` is read-only checked-in defaults; `generated.env` is the per-deploy working copy. Step 1c covers this in full.\n\n## Prerequisites\n\n1. **Repo path** — auto-detect `video-search-and-summarization\u002F` before\n   asking the user. Use the detected path as `$REPO` for all subsequent\n   commands.\n2. **Credential gates** — see [`references\u002Fcredentials.md`](references\u002Fcredentials.md): `NGC_CLI_API_KEY` for local\u002Flocal_shared NIM pulls, `NVIDIA_API_KEY` for remote NIM endpoints, and `HF_TOKEN` for edge recipes that use gated HF models.\n3. **System prerequisites (GPU driver, Docker, NVIDIA Container Toolkit, kernel sysctls, and — if `ufw` is active — the [Docker-bridge→host firewall allow](references\u002Fprerequisites.md#firewall) so bridge NIMs can fetch clips from host-mode VST)** — full checks in [`references\u002Fprerequisites.md`](references\u002Fprerequisites.md). Canonical hardware\u002Fdriver matrix is the [VSS prerequisites page](https:\u002F\u002Fdocs.nvidia.com\u002Fvss\u002F3.2.0\u002Fprerequisites.html).\n\nThe auto-detect snippet (git-root, then a common-path probe gated on\n`deploy\u002Fdocker\u002Fcompose.yml` + `dev-profile.sh` + `skills\u002Fvss-deploy-profile`)\nlives in [`references\u002Fprerequisites.md`](references\u002Fprerequisites.md#repo-detect).\nExport the resolved `$REPO`; if detection fails, ask the user for the checkout path.\n\n### Pre-flight check\n\nRun before every deploy. The full system checklist and remediation steps live\nin [`references\u002Fprerequisites.md`](references\u002Fprerequisites.md#preflight).\nFor DGX Spark \u002F IGX Thor \u002F AGX Thor, also run the cache-cleaner check in\n[`references\u002Fedge.md`](references\u002Fedge.md#cache-cleaner-every-edge-deploy).\n\n**Detect sudo mode first.** Several pre-flight remediations and the\nedge cache-cleaner installer call `sudo`. If the host requires a\nsudo password, those steps will silently no-op under `sudo -n` and\nleave the deploy in a half-prepared state.\n\n```bash\nif sudo -n true 2>\u002Fdev\u002Fnull; then\n  echo \"passwordless sudo — pre-flight will auto-install missing pieces\"\nelse\n  echo \"sudo requires password — pre-flight will NOT auto-install; hand commands to the user\"\nfi\n```\n\nWhen sudo needs a password, the skill **must not** run privileged\ninstallers itself. Surface the copy-pasteable command block from\n`references\u002Fprerequisites.md` to the user with a *\"run this once and\nconfirm\"* handoff, then resume after the user replies.\n\nMinimum smoke test (must succeed):\n\n```bash\nnvidia-smi --query-gpu=index,name --format=csv,noheader\ndocker info 2>\u002Fdev\u002Fnull | grep -qi runtimes \\\n  && docker run --rm --gpus all ubuntu:22.04 nvidia-smi >\u002Fdev\u002Fnull 2>&1 \\\n  && echo \"nvidia runtime OK\"\n```\n\nIf the smoke test fails, do not proceed; open\n[`references\u002Fprerequisites.md`](references\u002Fprerequisites.md#preflight)\nfor the remediation tree.\n\n## Model Selection\n\n- `$LLM_REMOTE_URL` \u002F `$VLM_REMOTE_URL` if the user asks for remote\n- `$NGC_CLI_API_KEY` (local NIMs) or `$NVIDIA_API_KEY` (remote)\n\n**Endpoint intent gate.** Don't infer remote placement from stray env vars\n(`LLM_ENDPOINT_URL`, `VLM_ENDPOINT_URL`, `LLM_BASE_URL`, `VLM_BASE_URL` may be\nleftovers). Use remote LLM\u002FVLM only when (1) the user asked for \u002F supplied a\nremote endpoint, (2) local sizing can't fit the selected models and the user\nagrees, or (3) an edge recipe needs a standalone local service VSS treats as\n`remote` (e.g. DGX Spark Nano 9B on `localhost:30081`). If an endpoint var is\nset but the user didn't ask for remote, surface it in Step 1 and ask — never\nsilently deploy remote because a var happened to exist.\n\nIf no combination on this host satisfies the profile's sizing requirements, **stop and report the blocker** — don't silently pick another shape.\n\n> **Edge shared mode is platform-specific.** Full recipes are in [`references\u002Fedge.md`](references\u002Fedge.md).\n\n## Deployment Flow\n\nAlways follow this sequence. Never skip the dry-run.\n\n### Step 0 — Tear down any existing deployment + clear data volumes\n\nIf a deployment already exists, tear it down AND clear stale data volumes before redeploying. \n\nFull procedure lives in [`references\u002Fteardown.md`](references\u002Fteardown.md).\n\n### Step 0a — Credentials gate (run before any env mutation)\n\nValidate every credential and selected remote endpoint the chosen profile\nneeds **before** Step 1c copies `.env` to `generated.env`. A 401 here is a\n30-second failure; the same 401 inside a NIM cold-start is a 10–20 min\nfailure. Run the discovery and probe flow in\n[`references\u002Fcredentials.md`](references\u002Fcredentials.md), including\n`scripts\u002Fprobe_remote_models.sh` for any LLM\u002FVLM endpoint you plan to write\ninto `generated.env`. Map the result against the chosen mode: missing\nor invalid required credentials\u002Fendpoints are blockers, optional credentials\nare not.\n\n### Step 1 — Gather context\n\nBefore building env overrides, confirm:\n\n| Value | How to determine |\n|---|---|\n| **Profile** | Match user intent to the routing table above. Default: `base` |\n| **Repo path** | Use the `$REPO` value auto-detected in prerequisites. If auto-detect failed, ask the user for the checkout path before continuing. |\n| **Hardware** | `nvidia-smi --query-gpu=name,memory.total --format=csv,noheader` |\n| **LLM\u002FVLM placement** | Explicitly decide local \u002F local_shared \u002F remote. Cross-reference available GPUs against the chosen profile's **Minimum GPU count** table. If endpoint env vars are present but the user did not request remote, ask whether to use or ignore them. |\n| **API keys** | `NGC_CLI_API_KEY` for local NIMs, `NVIDIA_API_KEY` for remote |\n| **`HOST_IP`** | In-cluster dial address: `ip route get 1.1.1.1` src (like `dev-profile.sh`; correct on LAN + cloud). If that interface is a VPN\u002Ftunnel, fall back to the LAN IP and **prompt the user** — [Network addressing](references\u002Fprerequisites.md#addressing). |\n| **`EXTERNAL_IP`** | Browser-facing address; defaults to `${HOST_IP}`. Override when the browser path differs — cloud public IP, Brev secure-link (Step 1d), or tunnel; **ask the user where they browse from if unsure**. [Network addressing](references\u002Fprerequisites.md#addressing). |\n| **`HAPROXY_PORT`** | Browser-facing ingress port. Default `7777`; ensure it is free. |\n\nBefore `docker compose up`, verify `EXTERNAL_IP`, `HAPROXY_PORT`, `VSS_PUBLIC_HOST`, and `VSS_PUBLIC_PORT` are populated with browser-reachable values. Otherwise the stack may appear healthy while UI\u002FAPI\u002FVST links 404 or loop through Cloudflare Access.\n\n### Step 1b — Prepare the data directory\n\nLayout (asset paths, ownership, mount points, profile-specific subdirs) is documented in [`references\u002Fdata-directory.md`](references\u002Fdata-directory.md). Read that file before deploying for the first time on a host or when changing profiles.\n\n\n### Step 1c — Initialize `generated.env`\n\nThe skill's per-deploy working copy. Always start from a fresh copy of the source `.env` , never mutate the source.\n\n```bash\nPROFILE=base\nENV_SRC=$REPO\u002Fdeploy\u002Fdocker\u002Fdeveloper-profiles\u002Fdev-profile-$PROFILE\u002F.env\nENV_GEN=$REPO\u002Fdeploy\u002Fdocker\u002Fdeveloper-profiles\u002Fdev-profile-$PROFILE\u002Fgenerated.env\n\ncp \"$ENV_SRC\" \"$ENV_GEN\"\n```\n\nAll subsequent writes (Brev `EXTERNAL_IP`, the env_overrides dict from Step 2) go to `$ENV_GEN`. `$ENV_SRC` is read-only from here on.\n\n### Step 1d — Brev only: detect first, then set `EXTERNAL_IP` to the secure-link domain\n\n**Detect Brev before anything else** — a Brev-provisioned instance sets `BREV_ENV_ID` in `\u002Fetc\u002Fenvironment`; nothing else does:\n\n```bash\ngrep -qE '^BREV_ENV_ID=' \u002Fetc\u002Fenvironment && echo \"on Brev\" || echo \"not Brev\"\n```\n\n- **not Brev** → skip the rest of this step and **do not read [`references\u002Fbrev.md`](references\u002Fbrev.md)**; keep the normal `${HOST_IP}`-based `EXTERNAL_IP`.\n- **on Brev** → apply the Brev secure-link overrides from [`references\u002Fbrev.md` § Setup flow](references\u002Fbrev.md#setup-flow) to `generated.env` (NOT `.env`). Those set `EXTERNAL_IP` \u002F `VSS_PUBLIC_HOST` to the secure-link domain **and** `VSS_PUBLIC_HTTP_PROTOCOL=https` \u002F `VSS_PUBLIC_WS_PROTOCOL=wss` \u002F `VSS_PUBLIC_PORT=443` — setting `EXTERNAL_IP` alone leaves `http:\u002F\u002F…:7777` UI\u002FAPI\u002FWS links that the browser blocks as mixed content.\n\n### Step 2 — Build env_overrides\n\nProduce an `env_overrides` dict from the user request and the gathered\ncontext: explicitly choose remote\u002Flocal LLM\u002FVLM, set credentials, point at\nendpoints, set platform-specific flags. Do not let existing shell env vars\nsilently pick placement; write the selected `LLM_MODE` \u002F `VLM_MODE` and\nmatching endpoint\u002Fmodel fields into `generated.env`. The full mapping (every\noverride key, when it applies, defaults, profile-specific differences) lives\nin [`references\u002Fenv-overrides.md`](references\u002Fenv-overrides.md). Each profile\nreference has worked examples for that profile's common scenarios.\n\n\n### Step 3 — Apply overrides + dry-run\n\n**Working env file:** `\u003Crepo>\u002Fdeploy\u002Fdocker\u002Fdeveloper-profiles\u002Fdev-profile-\u003Cprofile>\u002Fgenerated.env` (created in Step 1c).\n\n> **Reminder (see Step 1c):** apply all overrides (Step 2 dict + Brev `EXTERNAL_IP`) to `generated.env`; `--env-file` always points at it, and post-deploy verifiers read it for the actually-deployed values.\n\n```bash\n# (Step 1c already ran: cp $ENV_SRC $ENV_GEN)\n\n# Apply the env_overrides dict from Step 2 to generated.env\n# (read lines, update matching keys, append new keys, write)\n# Example:\n#   sed -i \"s|^LLM_MODE=.*|LLM_MODE=remote|\" \"$ENV_GEN\"\n#   sed -i \"s|^LLM_BASE_URL=.*|LLM_BASE_URL=http:\u002F\u002Flocalhost:30081|\" \"$ENV_GEN\"\n\n# Resolve compose\ncd $REPO\u002Fdeploy\u002Fdocker\ndocker compose --env-file $ENV_GEN config > resolved.yml\n```\n\nThe resolved YAML is saved to `\u003Crepo>\u002Fdeploy\u002Fdocker\u002Fresolved.yml`.\n\n### Step 3b — Verify resolved.yml has no unexpanded ${...} tokens\n\nUnexpanded `${VAR}` tokens in `resolved.yml` mean compose did not see those env values. Diagnostic procedure and common culprits live in [`references\u002Ftroubleshooting.md`](references\u002Ftroubleshooting.md).\n\n\n### Step 3c — Verify access to selected NGC artifacts\n\nDo this after `resolved.yml` exists and before `docker compose up`. The NGC\ntoken probe in Step 0a proves only that the key authenticates; it does not\nprove the key's org\u002Fteam can access the selected image or model repositories.\n\nBuild the artifact list from the actual selected deployment:\n\n- `resolved.yml`: every `image:` under `nvcr.io\u002F...` that Compose will pull.\n- `$ENV_GEN`: NGC-backed model\u002Fresource paths such as\n  `RTVI_VLM_MODEL_PATH=ngc:nim\u002Fnvidia\u002Fcosmos-reason2-8b:hf-1208`. Skip\n  `none`, `git:...`, local paths, and remote endpoint URLs.\n- Profile staging steps: any NGC model\u002Fresource downloads documented in the\n  profile reference, such as alerts\u002Fsearch perception model staging.\n\nProbe each selected artifact with the normalized NGC key before continuing:\n\n- Container images: `docker manifest inspect \u003Cnvcr.io\u002F...>` after `docker\n  login nvcr.io` — for gated `nvcr.io` repos a `401`\u002F`403` here is a definitive\n  no-entitlement signal (manifest read requires the same org\u002Fteam grant as the\n  layer pull); or the matching `ngc registry image info ...` when the artifact\n  maps cleanly to an NGC image path.\n- NGC model\u002Fresource paths (e.g. the Cosmos checkpoint RT-VLM downloads at\n  runtime): run the matching `ngc registry model info ...` or `ngc registry\n  resource info ...` for the exact repo\u002Ftag the profile will load or download;\n  these use NGC's scoped auth. Do NOT probe a model with `docker manifest\n  inspect` (returns \"no such manifest\" because a model is not an OCI image) or a\n  raw `Authorization: Bearer \u003Ckey>` REST call (returns `403` because that is not\n  NGC's auth flow); both are expected false negatives, not entitlement failures.\n  If the `ngc` CLI is unavailable, treat the container-image probe above as the\n  entitlement signal, since NGC grants org\u002Fteam access across images and models\n  together.\n- Profile-staged TAO\u002Fperception models: run the corresponding `ngc registry\n  model info ...` \u002F `resource info ...` for each repo\u002Ftag before the staging\n  block downloads files.\n\nIf any probe returns `401`, `403`, `permission`, `not being a member of the\norganization that owns the repo`, missing org\u002Frepo, or a similar access error,\nstop and prompt the user for an NGC key from an org\u002Fteam entitled to those\nartifacts. Do not start Compose and discover the failure during NIM cold start.\n\n### Step 3d — Strip dangling optional `depends_on` from resolved.yml\n\n\n**MUST run after Step 3, before Step 5.** Skipping this aborts the deploy:\n\nNormalize - drop optional dependencies for services filtered out from resolved.yml\n\n```bash\n# From the repo root\nuv run skills\u002Fvss-deploy-profile\u002Fscripts\u002Fnormalize_resolved_yml.py \"$REPO\u002Fdeploy\u002Fdocker\u002Fresolved.yml\"\n```\nIf `uv` isn't on the host, install it once with `curl -LsSf https:\u002F\u002Fastral.sh\u002Fuv\u002Finstall.sh | sh` (no root needed).\n**Re-validate** before `up -d`:\n\n```bash\ndocker compose -f \"$REPO\u002Fdeploy\u002Fdocker\u002Fresolved.yml\" config --quiet && echo \"resolved.yml OK\"\n```\n\nIf validation still fails after the normalizer runs, capture the error and inspect — that's a different bug (a dependency that's not optional, or another schema violation), not the dangling-depends_on case.\n\n### Step 4 — Review\n\nShow the user a summary of what will be deployed:\n\n- Profile name and hardware\n- LLM\u002FVLM models and mode (local\u002Fremote\u002Flocal_shared)\n- Services that will start\n- GPU device assignment\n- Key endpoints (UI port, agent port)\n\nAsk: **\"Looks good — deploy now?\"** and wait for confirmation before Step 5.\n\n**Exception — autonomous mode.** If the user's request already asks you to run autonomously (e.g. \"deploy X autonomously\", \"run without confirmation\", \"non-interactive\"), skip the confirmation prompt and proceed straight to Step 5. This path exists so automated eval \u002F CI invocations don't hang waiting for a human reply they'll never get. In all other cases, a human must approve.\n\n### Step 5 — Deploy\n\n```bash\ncd $REPO\u002Fdeploy\u002Fdocker\ndocker compose --env-file $ENV_GEN -f resolved.yml up -d\n```\n\n> **`--env-file` is mandatory.** Without the same `generated.env` used in Step 3, `COMPOSE_PROFILES` may be unset and `up -d` can exit 0 with zero selected services.\n\n> **Avoid broad `--force-recreate` on ordinary retries** — it destroys warm\n> NIM containers (another 3–5 min torch.compile + CUDA-graph capture each).\n> Fix the root cause (usually perms or an env typo) and just re-run `up -d`;\n> use targeted `--force-recreate --no-deps \u003Cservice...>` only when a profile\n> reference documents it as the recovery path.\n\n`docker compose up -d` only creates containers; it does not wait for internal services to finish warming. Never declare deploy success until the readiness gates pass.\n\n### Step 5b — Wait until the stack is actually healthy\n\n**Gate 0 — container count must be > 0.** Refuse to proceed past `up -d` until the started count (`docker compose -f resolved.yml ps -q | wc -l`) is non-zero and ≥ the expected count (`config --services | wc -l`); a zero\u002Fshort count almost always means a missing `--env-file` in Step 5. The exact gate plus the full readiness procedure live in [`references\u002Freadiness.md`](references\u002Freadiness.md).\n\nCold deploys can take 10–20 min, and each profile reference lists the required endpoints. **Never declare deploy done after `up -d`; only after every documented endpoint succeeds.**\n\n## Tear Down\n\nTo tear down a deployment — full host reclaim or cache-preserving redeploy \u002F profile\nswitch — follow [`references\u002Fteardown.md`](references\u002Fteardown.md). Always tear down\nby the `mdx` project with `-v --remove-orphans`; a plain `docker compose down` leaves\nvolumes and networks behind.\n\n## Debugging a Deployment\n\nUse this workflow when the user asks to \"debug the deploy\", \"verify it's working\", \"why is the agent not responding\", or similar. The goal is to confirm the full video-ingestion-to-agent-answer path, not just that containers are \"Up\".\n\nEach profile reference has a **Debugging** section listing the exact commands and failure-mode table for that profile.\n\n### Quick checks (all profiles)\n\n```bash\n# 1. All expected containers Up\ndocker ps --format 'table {{.Names}}\\t{{.Status}}'\n\n# 2. Agent API + UI responding\ncurl -sf http:\u002F\u002Flocalhost:8000\u002Fhealth >\u002Fdev\u002Fnull && echo \"agent OK\"\ncurl -sf http:\u002F\u002Flocalhost:3000\u002F >\u002Fdev\u002Fnull && echo \"ui OK\"\n```\n\nThe LLM\u002FVLM NIM probes — including the `*_MODE=remote` handling that skips\n`localhost:3008x` (where a connection refused is expected) and probes the\nselected `*_BASE_URL\u002Fv1\u002Fmodels` via `scripts\u002Fprobe_remote_models.sh` — are in\n[`references\u002Ftroubleshooting.md`](references\u002Ftroubleshooting.md#nim-probes).\n\n## Limitations\n\n- This skill deploys compose-based VSS profiles only; standalone microservice deployment belongs to the matching `vss-deploy-*` skill.\n- Hardware sizing, model placement, and profile-specific readiness are owned by profile references; do not infer them from memory.\n- Privileged host remediation requires user approval when passwordless sudo is unavailable.\n\n## Troubleshooting\n\nThe common-error quick reference, the full symptom → cause → fix table, the\nunexpanded-`${...}` diagnostic, and the NIM endpoint probes are consolidated in\n[`references\u002Ftroubleshooting.md`](references\u002Ftroubleshooting.md) — start there\nfor any deploy, runtime, or probe failure, then continue in the matching\nper-profile reference's Debugging section.\n",{"name":5,"license":15,"metadata":49,"description":7},{"tags":50,"version":51,"github-url":52},"nvidia blueprint deployment","3.2.0","https:\u002F\u002Fgithub.com\u002FNVIDIA-AI-Blueprints\u002Fvideo-search-and-summarization","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fvss-deploy-profile","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik","https:\u002F\u002Fnorvik-orpin.vercel.app","https:\u002F\u002Fgithub.com\u002Fpattanation","2026-07-17 11:17:04",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add pattanation\u002FNorvik --skill vss-deploy-profile",{"tool":66,"command":67},"bunx","bunx skills add pattanation\u002FNorvik --skill vss-deploy-profile",{"tool":69,"command":70},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill vss-deploy-profile","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002FSKILL.md",true,[74,80,84,88,92,96,100,104,108,112,116,120,124,128,132,136,140,144,148,152,156,160,164,168,172,178,182,186,190],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"BENCHMARK.md","REFERENCE","参考文档",3680,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002FBENCHMARK.md",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"evals\u002Falerts_cv.json",1180,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Fevals\u002Falerts_cv.json",{"path":85,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":86,"sourceHtmlUrl":87},"evals\u002Falerts_vlm.json",1053,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Fevals\u002Falerts_vlm.json",{"path":89,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":90,"sourceHtmlUrl":91},"evals\u002Fbase.json",954,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Fevals\u002Fbase.json",{"path":93,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":94,"sourceHtmlUrl":95},"evals\u002Fevals.json",8363,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Fevals\u002Fevals.json",{"path":97,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":98,"sourceHtmlUrl":99},"evals\u002Flvs.json",864,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Fevals\u002Flvs.json",{"path":101,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":102,"sourceHtmlUrl":103},"evals\u002Fsearch.json",867,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Fevals\u002Fsearch.json",{"path":105,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":106,"sourceHtmlUrl":107},"evals\u002Fwarehouse.json",2114,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Fevals\u002Fwarehouse.json",{"path":109,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":110,"sourceHtmlUrl":111},"references\u002Falerts.md",23019,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Falerts.md",{"path":113,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":114,"sourceHtmlUrl":115},"references\u002Fbase.md",29641,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Fbase.md",{"path":117,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":118,"sourceHtmlUrl":119},"references\u002Fbrev.md",5467,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Fbrev.md",{"path":121,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":122,"sourceHtmlUrl":123},"references\u002Fcredentials.md",4229,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Fcredentials.md",{"path":125,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":126,"sourceHtmlUrl":127},"references\u002Fdata-directory.md",1937,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Fdata-directory.md",{"path":129,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":130,"sourceHtmlUrl":131},"references\u002Fedge.md",15005,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Fedge.md",{"path":133,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":134,"sourceHtmlUrl":135},"references\u002Fenv-overrides.md",6482,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Fenv-overrides.md",{"path":137,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":138,"sourceHtmlUrl":139},"references\u002Flvs-profile.md",18081,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Flvs-profile.md",{"path":141,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":142,"sourceHtmlUrl":143},"references\u002Fngc.md",3430,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Fngc.md",{"path":145,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":146,"sourceHtmlUrl":147},"references\u002Fprerequisites.md",16461,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Fprerequisites.md",{"path":149,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":150,"sourceHtmlUrl":151},"references\u002Freadiness.md",3276,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Freadiness.md",{"path":153,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":154,"sourceHtmlUrl":155},"references\u002Fsearch.md",24894,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Fsearch.md",{"path":157,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":158,"sourceHtmlUrl":159},"references\u002Fteardown.md",6757,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Fteardown.md",{"path":161,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":162,"sourceHtmlUrl":163},"references\u002Ftroubleshooting.md",13455,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Ftroubleshooting.md",{"path":165,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":166,"sourceHtmlUrl":167},"references\u002Fwarehouse-debug.md",32346,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Fwarehouse-debug.md",{"path":169,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":170,"sourceHtmlUrl":171},"references\u002Fwarehouse.md",58362,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Freferences\u002Fwarehouse.md",{"path":173,"resourceType":174,"resourceTypeDesc":175,"sizeBytes":176,"sourceHtmlUrl":177},"scripts\u002Fcheck_credentials.sh","SCRIPT","脚本",2527,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Fscripts\u002Fcheck_credentials.sh",{"path":179,"resourceType":174,"resourceTypeDesc":175,"sizeBytes":180,"sourceHtmlUrl":181},"scripts\u002Fnormalize_resolved_yml.py",6279,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Fscripts\u002Fnormalize_resolved_yml.py",{"path":183,"resourceType":174,"resourceTypeDesc":175,"sizeBytes":184,"sourceHtmlUrl":185},"scripts\u002Fprobe_remote_models.sh",2682,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Fscripts\u002Fprobe_remote_models.sh",{"path":187,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":188,"sourceHtmlUrl":189},"skill-card.md",4113,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Fskill-card.md",{"path":191,"resourceType":192,"resourceTypeDesc":193,"sizeBytes":194,"sourceHtmlUrl":195},"skill.oms.sig","OTHER","其他",10445,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-deploy-profile\u002Fskill.oms.sig",[197,227,252,275,297,312],{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":201,"sourceHtmlUrl":202,"categories":203,"keywords":210,"publishedAt":44},"01M71QDV4DM8T19HEHWATEF1K4","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[204,207],{"categoryNo":205,"categoryName":206,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":208,"categoryName":209,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[211,212,213,33,214,215,216,217,218,219,220,221,222,223,224,225,226],"webapp","testing","webapp testing","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots",{"skillNo":228,"name":229,"nameZh":6,"description":230,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":231,"sourceHtmlUrl":232,"categories":233,"keywords":235,"publishedAt":44},"01M71QDH2GGMXGA9105C9W1N7B","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FSKILL.md",[234],{"categoryNo":208,"categoryName":209,"taxonomyType":21,"taxonomyTypeDesc":22},[236,237,238,223,239,240,241,33,242,243,216,244,30,245,246,247,248,249,250,251],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","file","components","react","multi","state","routing","state management",{"skillNo":253,"name":254,"nameZh":6,"description":255,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":256,"licenseFileUrl":257,"sourceHtmlUrl":258,"categories":259,"keywords":261,"publishedAt":44},"01M71QD9T2XC3EWMQNN9ACNWQ1","vueuse-functions","Apply VueUse composables where appropriate to build concise, maintainable Vue.js \u002F Nuxt features.","MIT","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FSKILL.md",[260],{"categoryNo":208,"categoryName":209,"taxonomyType":21,"taxonomyTypeDesc":22},[262,263,264,265,266,267,27,268,269,270,271,272,273,274],"functions","vueuse","vueuse functions","project","nuxt","apply","concise","build","https","features","vue","js","composables",{"skillNo":276,"name":277,"nameZh":6,"description":278,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":256,"licenseFileUrl":279,"sourceHtmlUrl":280,"categories":281,"keywords":284,"publishedAt":44},"01M71QD51HWSGYMCMB7RW7PGK8","vue-testing-best-practices","Use for Vue.js testing. Covers Vitest, Vue Test Utils, component testing, mocking, testing patterns, and Playwright for E2E testing.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FSKILL.md",[282,283],{"categoryNo":205,"categoryName":206,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":208,"categoryName":209,"taxonomyType":21,"taxonomyTypeDesc":22},[285,212,286,272,287,222,288,289,290,27,291,33,292,293,294,30,295,273,296],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":298,"name":299,"nameZh":6,"description":300,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":256,"licenseFileUrl":301,"sourceHtmlUrl":302,"categories":303,"keywords":305,"publishedAt":44},"01M71QD358H2DJ9THJRBP77T3T","vue-router-best-practices","Vue Router 4 patterns, navigation guards, route params, and route-component lifecycle interactions.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FSKILL.md",[304],{"categoryNo":208,"categoryName":209,"taxonomyType":21,"taxonomyTypeDesc":22},[306,272,307,287,308,290,309,27,295,310,311],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":313,"name":314,"nameZh":6,"description":315,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":256,"licenseFileUrl":316,"sourceHtmlUrl":317,"categories":318,"keywords":320,"publishedAt":44},"01M71QCYPNWDE2MQZ1TF3ED5S4","vue-best-practices","MUST be used for Vue.js tasks. Strongly recommends Composition API with `\u003Cscript setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FSKILL.md",[319],{"categoryNo":208,"categoryName":209,"taxonomyType":21,"taxonomyTypeDesc":22},[321,272,287,322,265,323,324,325,306,326,327,328,329,330,331,33,332,30,333,334],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]