[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71QCAMT1W7V0P87VW68ARR3":3,"skill-same:01M71QCAMT1W7V0P87VW68ARR3":118},{"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},"01M71QCAMT1W7V0P87VW68ARR3","vss-manage-video-io-storage",null,"Use to call the VIOS REST API (sensor list, timelines, clip extraction, snapshots, add\u002Fdelete sensors and streams). Not for VLM inference or search.","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-manage-video-io-storage\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"vss manage video io storage","manage","io","storage","Video","sensors","github","delete","REST","api","Blueprint","snapshots","use","call","sensor","streams","clip","search","for","NVIDIA","2026-11-10 13:02:02",false,"---\nname: vss-manage-video-io-storage\ndescription: Use to call the VIOS REST API (sensor list, timelines, clip extraction, snapshots, add\u002Fdelete sensors and streams). Not for VLM inference or search.\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 operational\"\n---\n## Purpose\n\nManage VIOS and NvStreamer API operations for VSS video input\u002Foutput and\nstorage workflows: sensors, streams, uploads, snapshots, clips, timelines, and\nrecording status.\n\n## Prerequisites\n\n- Active VSS deployment reachable on `$HOST_IP` (see `vss-deploy-profile` and `references\u002F`).\n- NGC credentials in `$NGC_CLI_API_KEY` and `$NVIDIA_API_KEY` for any image pulls.\n- `curl`, `jq`, and Docker available on the caller.\n\n## Instructions\n\n# VIOS Operations\n\nCall the VIOS REST API to manage cameras\u002Fsensors, RTSP streams, recordings, snapshots, and storage. Use when asked to: add a camera, add an RTSP stream, list sensors, show configured sensors\u002Fcameras\u002Fstreams, check stream status, get a snapshot, download a clip, upload a video file, or manage video storage. Query the VIOS API directly using curl — do not navigate the UI.\n\n**Upload routing rule:**\n- If the user asks to \"upload `\u003Cfile>.mp4` to VIOS\", \"upload a video file\", or otherwise means storing a local video as a VIOS file-backed sensor, use the direct VIOS API: `PUT \u002Fvst\u002Fapi\u002Fv1\u002Fstorage\u002Ffile\u002F{filename}` from [`references\u002Fapi-reference.md`](references\u002Fapi-reference.md) Section 8.\n- Use NvStreamer only when the user explicitly needs a live\u002Fsynthetic RTSP camera feed, asks for NvStreamer, or asks to retrieve an RTSP URL.\n- Do not substitute the NvStreamer upload -> RTSP URL -> VIOS `\u002Fsensor\u002Fadd` handoff for a plain VIOS MP4 upload request.\n\n**Do NOT use this skill for:**\n- VLM inference or ad-hoc visual Q&A about a clip — use `vss-ask-video`.\n- Semantic search across the archive, or ingesting video for search — use `vss-search-archive`.\n- Narrative summaries of a recorded clip — use `vss-summarize-video`.\n- Incident-range or alert-window reports — use `vss-generate-video-report` Mode B.\n- Reading analytics metrics, incidents, or alerts — use `vss-query-analytics`.\n\n## Reference contracts shipped with this skill\n\nThis skill bundles four reference files under `references\u002F`. Read whichever applies to the task in front of you:\n\n| File | Purpose | Audience |\n|---|---|---|\n| [`references\u002Fapi-reference.md`](references\u002Fapi-reference.md) | The full VIOS REST API reference (the runtime contract) — sensor management, storage, snapshots, clip extraction, WebRTC live\u002Freplay, RTSP proxy, recorder, service configuration, service discovery. **Read this when invoking any VIOS API operation.** | Operational users + this skill itself |\n| [`references\u002Fnvstreamer-api-reference.md`](references\u002Fnvstreamer-api-reference.md) | The **NvStreamer REST API reference** — version, sensor list\u002Finfo\u002Fstatus\u002Fstreams, the three upload methods (PUT v2 \u002F PUT v1 \u002F POST multipart) with the `nvstreamer-*` custom headers, delete, snapshots (frame-indexed live, timestamp-indexed storage), storage info, filesystem scan. NvStreamer (`vss-vios-nvstreamer`, the streamer-adaptor variant of `launch_vst`) is **brought up by the same profiles that bring VIOS up** — `dev-profile-alerts`, `dev-profile-lvs`, `dev-profile-search`, all warehouse profiles. See `integrate-vios-service.md § Topology B` for the deployment side. **Read this when serving test \u002F sample videos as synthetic RTSP, retrieving the RTSP URL NvStreamer generated for a file, or driving the canonical NvStreamer → VIOS handoff** (upload to NvStreamer → read RTSP URL → register that URL with VIOS via `\u002Fsensor\u002Fadd`). | Operational users + skill authors composing the upload → RTSP URL → VIOS `\u002Fsensor\u002Fadd` flow |\n| [`references\u002Fintegrate-vios-service.md`](references\u002Fintegrate-vios-service.md) | The **integration contract** — how VIOS plugs into other VSS microservices. Documents required peer services (RT-VLM, ELK, Kafka, Redis, `sdr-controller` \u002F SDRC), the structured `component_services:` block consumed by the `vss-build-vision-agent` skill's Step 4, integration inputs\u002Foutputs (Kafka topics, REST endpoints, file paths), environment variables, network requirements, and known integration constraints (e.g. the `\u002Furl`-variant double-`http:\u002F\u002F` bug, the VIOS + SDRC patching requirement). **Read this when authoring a skill that talks to VIOS as a peer, when composing a new VSS deployment, or when debugging caption-pipeline wiring.** | Skill authors, deployment composers, pair-file maintainers |\n| [`references\u002Fdeploy-vios-service.md`](references\u002Fdeploy-vios-service.md) | The **deployment contract** — what it takes to bring VIOS up. Documents container images and tags (`nvcr.io\u002Fnvidia\u002Fvss-core\u002Fvss-vios-*:3.2.0`), GPU \u002F CPU \u002F memory \u002F storage requirements, startup behavior + healthcheck tuning, required environment variables (notably `VST_INSTALL_ADDITIONAL_PACKAGES=true` for the libav apt-install step that gates uploads), known deployment issues (volume drift, libav missing, 502 from leftover containers), prerequisites, dry-run, verify-deployment, and tear-down commands. **Read this when VIOS isn't running and you (or your caller) need to deploy it standalone, when debugging container-startup failures, or when authoring a deploy skill that wraps VIOS.** | Operators, deploy-skill authors |\n\n## Deployment prerequisite — VIOS MUST be running\n\nThis skill is primarily an API client and assumes VIOS is already up and reachable at the VST ingress (default `http:\u002F\u002F${HOST_IP}:30888`). It does not deploy VIOS itself, but when VIOS is unreachable it coordinates a deploy using its bundled deployment runbook ([`references\u002Fdeploy-vios-service.md`](references\u002Fdeploy-vios-service.md)) or hands off to the full-stack `\u002Fvss-deploy-profile` skill. Before doing any work:\n\n1. **Probe VIOS:**\n   ```bash\n   curl -sf --max-time 5 \"http:\u002F\u002F${HOST_IP}:30888\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Fversion\" >\u002Fdev\u002Fnull\n   ```\n\n2. **If the probe fails, VIOS is not deployed.** Offer two paths forward:\n\n   > *\"VIOS is not reachable at `http:\u002F\u002F${HOST_IP}:30888` — no deployment is currently up. You have two options:*\n   > *(a) Bring up VIOS standalone using this skill's bundled [`references\u002Fdeploy-vios-service.md`](references\u002Fdeploy-vios-service.md) runbook — image tags, env vars (notably `VST_INSTALL_ADDITIONAL_PACKAGES=true`), host directories, NGC login, bring-up command, healthcheck loop, and known deployment issues are all documented there. This is the right path if you only need VIOS itself (no RT-VLM \u002F ELK \u002F etc.) or if you're composing a custom profile.*\n   > *(b) Deploy a full VSS profile that includes VIOS via the `\u002Fvss-deploy-profile` skill — `base` (recommended), `lvs`, `search`, or `alerts` all bring VIOS up alongside other components. This is the right path if you want a complete VSS stack.*\n   > *Which would you like?\"*\n\n   - If the user picks (a) → walk them through `references\u002Fdeploy-vios-service.md` step by step. Pay particular attention to its `§ Environment Variables — Required for Upload-to-Caption Path` and `§ Known Deployment Issues` sections — the libav-missing failure (`VST_INSTALL_ADDITIONAL_PACKAGES=true`) and the volume-drift hang (`docker compose up --yes` or `docker volume rm` first) are the two most common bring-up blockers. After deploy succeeds and the probe in step 1 passes, return here.\n   - If the user picks (b) → hand off to `\u002Fvss-deploy-profile -p \u003Cprofile>` (default `base`). Return here once it succeeds.\n   - If the user declines both → **stop**. VIOS operations require the VST backend to be up; do not attempt to fabricate responses or proceed with a degraded mode.\n\n   *Pre-authorized autonomous mode:* if your caller has granted explicit pre-authorization to deploy prerequisites (e.g. the request says \"pre-authorized to deploy prerequisites\", or you are running in a non-interactive evaluation harness with that permission), skip the confirmation and prefer path (a) — bring up VIOS standalone via this skill's bundled `references\u002Fdeploy-vios-service.md` — unless the request explicitly asks for a full VSS profile, in which case invoke `\u002Fvss-deploy-profile -p base`.\n\n3. **If the probe passes, proceed.** VIOS is up; all operations below are safe to execute.\n\n---\n\n## Known limitation — leftover containers from prior deploys\n\n`GET \u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Flist` and `GET \u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002F\u003CsensorId>\u002Fstreams`\ncan return **HTTP 502 Bad Gateway** or stale results when leftover `*-smc`\nVST containers from an earlier deploy survive teardown and win the\n`network_mode: host` port-bind race on `:30000` \u002F `:30888`. **Remediation:\nre-run `\u002Fvss-deploy-profile`** — its Step 0 teardown grep clears the full\n`sensor-ms-*` \u002F `vst-ingress-*` \u002F `sdr-*` \u002F `sdrc-*` \u002F `rtspserver-ms-*` set.\nOther paths (`storage\u002Ffile\u002F*` upload, `*\u002Fpicture\u002Furl` snapshot, `*\u002Furl` clip\nextraction) are unaffected. Full failure-mode catalogue, remediation, and the\ncurrent routing contract (direct vs SDRC; SDR\u002FEnvoy removed in PR #711) live in\n`references\u002Fdeploy-vios-service.md § Known Deployment Issues` and\n[issue #151](https:\u002F\u002Fgithub.com\u002FNVIDIA-AI-Blueprints\u002Fvideo-search-and-summarization\u002Fissues\u002F151).\n\n---\n\n## Setup\n\n**Base URL:** `http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1`\n\n**Endpoint Resolution:**\n- Use the VIOS endpoint associated with the active VSS deployment. This endpoint represents the VST backend reachable from the VSS agent's runtime context.\n- Do NOT attempt to discover host, IP, or port via shell commands, filesystem access, or static configuration files.\n- Assume the VSS deployment context already provides the correct network endpoint for VST.\n\n**Availability Check:**\n- Before making any API call, verify that the VST backend is reachable via the VSS deployment endpoint:\n  ```bash\n  curl -sf --connect-timeout 5 http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Fversion\n  ```\n- If the backend is unavailable (non-zero exit code or connection error), fail gracefully and report the error to the user. See the **Deployment prerequisite** section above for the deploy-or-stop branch.\n\n**Fallback:**\n- If endpoint information is not available from context, explicitly ask the user to provide the VST endpoint (host\u002FIP and port).\n\n**Run all curl commands yourself** — never instruct the user to run commands manually.\n\n**Auth:** Optional. Most deployments run without auth. If a `401` is returned, retry with `-H \"Authorization: Bearer \u003Ctoken>\"` and ask the user for the token.\n\n**Start\u002Fend time handling:** Any API that requires `startTime`\u002F`endTime`:\n- If the user provides them, use those values directly.\n- If the user does not provide them, first fetch the timelines for the relevant stream to find valid recorded ranges, then pick appropriate values from the response before calling the API. Never fabricate timestamps.\n\n**Resolving sensorId \u002F streamId:** If the user has not provided a sensorId or streamId, look it up automatically using one of:\n- `GET \u002Fsensor\u002Flist` — lists all sensors with their `sensorId`\n- `GET \u002Fsensor\u002F{sensorId}\u002Fstreams` — lists streams for a specific sensor with their `streamId`\n- `GET \u002Fsensor\u002Fstreams` — lists all streams across all sensors\n- `GET \u002Flive\u002Fstreams` — lists all active live streams\n- `GET \u002Freplay\u002Fstreams` — lists all available replay streams\n\nIf a sensor has only one stream, `sensorId` and `streamId` are equal and can be used interchangeably.\n\n---\n\n## Service Map\n\n| Capability | URL prefix | Authoritative reference |\n|---|---|---|\n| Version \u002F health check | `\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Fversion` | `references\u002Fapi-reference.md` |\n| Sensor list \u002F info \u002F status \u002F add \u002F delete | `\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002F` | `references\u002Fapi-reference.md` |\n| Sensor streams | `\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Fstreams`, `\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002F{id}\u002Fstreams` | `references\u002Fapi-reference.md` |\n| Network scan | `\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Fscan` | `references\u002Fapi-reference.md` |\n| Recording timelines | `\u002Fvst\u002Fapi\u002Fv1\u002Fstorage\u002F` | `references\u002Fapi-reference.md` |\n| Video clip download \u002F URL | `\u002Fvst\u002Fapi\u002Fv1\u002Fstorage\u002F` | `references\u002Fapi-reference.md` (operations) + `references\u002Fintegrate-vios-service.md § Known Integration Constraints` (Finding 8: `\u002Furl` double-`http:\u002F\u002F` bug — prefer binary direct endpoints) |\n| File upload \u002F delete | `\u002Fvst\u002Fapi\u002Fv1\u002Fstorage\u002F` | `references\u002Fapi-reference.md` (PUT v2 + legacy v1 endpoints) + `references\u002Fdeploy-vios-service.md § Known Deployment Issues` (Finding 9: libav-missing failure mode) |\n| Live streams \u002F snapshot (picture) | `\u002Fvst\u002Fapi\u002Fv1\u002Flive\u002F` | `references\u002Fapi-reference.md` |\n| Replay streams \u002F historical snapshot | `\u002Fvst\u002Fapi\u002Fv1\u002Freplay\u002F` | `references\u002Fapi-reference.md` (operations) + `references\u002Fintegrate-vios-service.md § Known Integration Constraints` (Finding 8) |\n| **NvStreamer**: file-to-RTSP republisher (upload, retrieve generated RTSP URL, filesystem scan, frame snapshots) | `http:\u002F\u002F${HOST_IP}:${NVSTREAMER_HTTP_PORT:-31000}\u002Fvst\u002Fapi\u002Fv1\u002F` | `references\u002Fnvstreamer-api-reference.md` (the streamer endpoint is **separate** from the VIOS gateway — different port, `type: \"streamer\"` on `\u002Fversion`) |\n\n---\n\n## Operations\n\nThe full VIOS REST API reference — sensor management, storage, snapshots, clip extraction, WebRTC live\u002Freplay, RTSP proxy, recorder, service configuration, and service discovery — lives in [`references\u002Fapi-reference.md`](references\u002Fapi-reference.md). Read that file when invoking any operation.\n\nWhen a request involves serving an on-disk video file as a synthetic RTSP camera (upload a sample to NvStreamer, retrieve the auto-generated RTSP URL, register that URL with VIOS), point at the NvStreamer endpoint and follow [`references\u002Fnvstreamer-api-reference.md`](references\u002Fnvstreamer-api-reference.md) for the surface. NvStreamer comes up automatically with any VIOS-using profile that ships it; do not deploy it separately.\n\nFor integration- and deployment-time questions about how VIOS interacts with other microservices or how it's brought up, defer to [`references\u002Fintegrate-vios-service.md`](references\u002Fintegrate-vios-service.md) and [`references\u002Fdeploy-vios-service.md`](references\u002Fdeploy-vios-service.md) respectively (see the **Reference contracts** table above for what each covers).\n\n---\n\n## Workflow: sensor name\u002FIP -> clip or snapshot\n\nWhen the user has a sensor name or IP but needs a clip or snapshot:\n\n0. Verify VST is reachable (see Setup — Availability Check):\n   ```bash\n   curl -sf --connect-timeout 5 \"http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Fversion\"\n   ```\n1. List sensors to find `sensorId`:\n   ```bash\n   curl -s \"http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Flist\" | jq .\n   ```\n2. Get streams for that sensor to find `streamId` (prefer `isMain: true`):\n   ```bash\n   curl -s \"http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002F\u003CsensorId>\u002Fstreams\" | jq .\n   ```\n3. Check timelines to confirm a recording exists in the requested range:\n   ```bash\n   curl -s \"http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1\u002Fstorage\u002F\u003CstreamId>\u002Ftimelines\" | jq .\n   ```\n4. Download clip or snapshot using the `streamId`. Prefer the **binary direct endpoints** (`\u002Fstorage\u002Ffile\u002F\u003CstreamId>?startTime=...&endTime=...`, `\u002Freplay\u002Fstream\u002F\u003CstreamId>\u002Fpicture?startTime=...`, `\u002Fstorage\u002Fstream\u002F\u003CstreamId>\u002Fpicture?startTime=...`) over the `\u002Furl` JSON envelope variants — see `references\u002Fintegrate-vios-service.md § Known Integration Constraints` Finding 8 (the `\u002Furl` variants return double-`http:\u002F\u002F` URLs in 3.2.0 and require client-side stripping).\n\n---\n\n## Responses\n\n**Success with data:** JSON object or array.\n\n**Success with no data:** `null` — a `null` response means the API call succeeded but there is no data to return (e.g. no schedule configured, scan returned no results). It is not an error.\n\n**Success with boolean:** Some endpoints return `true` on success (e.g. `DELETE \u002Fsensor\u002F{sensorId}`).\n\n**Error:** JSON object with `error_code` and `error_message`:\n```json\n{\n  \"error_code\": \"VMSInternalError\",\n  \"error_message\": \"VMS internal processing error\"\n}\n```\n\nCommon codes: `VMSInternalError`, `VMSNotFound`, `VMSInvalidParameter`.\n\nIf you see `InvalidParameterError: Failed to get media information` on a PUT upload, this is the libav-missing failure mode — VIOS was deployed without `VST_INSTALL_ADDITIONAL_PACKAGES=true`. See `references\u002Fdeploy-vios-service.md § Known Deployment Issues` Finding 9 for the fix.\n\nIf you see double-`http:\u002F\u002F` prefixes in `imageUrl` or `videoUrl` fields on `\u002Furl`-variant responses, that's Finding 8 — strip the leading `http:\u002F\u002F` client-side or switch to binary direct endpoints.\n\n---\n\n## Examples\n\nExample operation prompts:\n- \"List the active VIOS sensors and show their stream status.\"\n- \"Upload this sample video to VIOS and return the generated stream id.\"\n- \"Download a two-second clip from this sensor's recording timeline.\"\n- \"Use NvStreamer to upload a file and retrieve its generated RTSP URL.\"\n\n## Limitations\n\n- VIOS operations require a reachable VST backend; stop or deploy prerequisites\n  when the health probe fails.\n- Most deployments do not require auth, but a deployment can add an external\n  auth layer.\n- Container-side paths in examples use `${VST_CONTAINER_ROOT}` as a neutral\n  placeholder for the VST install root inside the container. Resolve it from the\n  active deployment before using path examples.\n- Do not print API keys, bearer tokens, or generated credentials in logs or\n  final responses.\n\n## Troubleshooting\n\n- **Error**: health probe fails. **Cause**: VIOS is not deployed or the endpoint\n  is wrong. **Solution**: follow the deployment prerequisite flow or ask for the\n  correct VST endpoint.\n- **Error**: uploads fail with `Failed to get media information`. **Cause**:\n  libav packages were not installed in the VIOS container. **Solution**: set\n  `VST_INSTALL_ADDITIONAL_PACKAGES=true` and redeploy.\n- **Error**: `\u002Furl` responses contain `http:\u002F\u002Fhttp:\u002F\u002F...`. **Cause**: known URL\n  construction defect. **Solution**: use binary direct endpoints or strip the\n  duplicated prefix.\n\n---\n\n## Tips\n\n- **jq:** All JSON responses are piped through `jq .` for readability. Binary responses (clip download, snapshot) are not — they use `-o \u003Cfile>` instead.\n- **Time format:** Always ISO 8601 UTC, e.g. `2026-04-10T10:30:00Z` or `2026-04-10T10:30:00.000Z`.\n- **streamId header:** Live\u002Freplay\u002Frecorder endpoints require `streamId` as BOTH a path parameter AND a request header — include both.\n- **Large clips:** Use the binary direct `\u002Fstorage\u002Ffile\u002F\u003Cid>?...&container=mp4` endpoint with `-o clip.mp4` for direct streaming. The `\u002Furl` envelope variant has the Finding 8 double-`http:\u002F\u002F` defect — avoid until upstream fixes it or use client-side prefix stripping.\n- **Sensor vs stream ID:** `sensorId` identifies a camera; `streamId` identifies a specific video stream from that camera (a sensor can have a main stream and sub-streams).\n- **Identifying sensor type (RTSP vs uploaded file):** Call `GET \u002Fsensor\u002F\u003CsensorId>\u002Fstreams` and inspect the `url` field of each stream. If `url` starts with `rtsp:\u002F\u002F` it is a live RTSP\u002FIP camera stream. If `url` is a file path (e.g. `\"${VST_CONTAINER_ROOT}\u002Fstreamer_videos\u002FTruckAccident.mp4\"`) it is an uploaded file sensor. This determines which delete flow to use — see Section 8.\n- **Upload timestamp is honored for the recorded timeline:** When uploading a file via `PUT \u002Fvst\u002Fapi\u002Fv1\u002Fstorage\u002Ffile\u002F\u003Cfilename>?timestamp=\u003Ciso>`, the timeline returned by `GET \u002Fstorage\u002F\u003CstreamId>\u002Ftimelines` is anchored at the supplied timestamp, not the upload wall-clock time. Subsequent snapshot \u002F clip queries MUST use timestamps within this range — fetch the timeline first. See `references\u002Fapi-reference.md § 8` and `references\u002Fintegrate-vios-service.md § Integration Interfaces > Inputs > Upload video file` for the authoritative contract.\n- **Endpoint resolution:** The VST endpoint is provided by the VSS deployment context. Do not attempt manual IP\u002Fport discovery. If unavailable, ask the user. All curl examples use `\u003CVST_ENDPOINT>` as a placeholder — substitute the resolved endpoint before executing.\n","## Purpose\n\nManage VIOS and NvStreamer API operations for VSS video input\u002Foutput and\nstorage workflows: sensors, streams, uploads, snapshots, clips, timelines, and\nrecording status.\n\n## Prerequisites\n\n- Active VSS deployment reachable on `$HOST_IP` (see `vss-deploy-profile` and `references\u002F`).\n- NGC credentials in `$NGC_CLI_API_KEY` and `$NVIDIA_API_KEY` for any image pulls.\n- `curl`, `jq`, and Docker available on the caller.\n\n## Instructions\n\n# VIOS Operations\n\nCall the VIOS REST API to manage cameras\u002Fsensors, RTSP streams, recordings, snapshots, and storage. Use when asked to: add a camera, add an RTSP stream, list sensors, show configured sensors\u002Fcameras\u002Fstreams, check stream status, get a snapshot, download a clip, upload a video file, or manage video storage. Query the VIOS API directly using curl — do not navigate the UI.\n\n**Upload routing rule:**\n- If the user asks to \"upload `\u003Cfile>.mp4` to VIOS\", \"upload a video file\", or otherwise means storing a local video as a VIOS file-backed sensor, use the direct VIOS API: `PUT \u002Fvst\u002Fapi\u002Fv1\u002Fstorage\u002Ffile\u002F{filename}` from [`references\u002Fapi-reference.md`](references\u002Fapi-reference.md) Section 8.\n- Use NvStreamer only when the user explicitly needs a live\u002Fsynthetic RTSP camera feed, asks for NvStreamer, or asks to retrieve an RTSP URL.\n- Do not substitute the NvStreamer upload -> RTSP URL -> VIOS `\u002Fsensor\u002Fadd` handoff for a plain VIOS MP4 upload request.\n\n**Do NOT use this skill for:**\n- VLM inference or ad-hoc visual Q&A about a clip — use `vss-ask-video`.\n- Semantic search across the archive, or ingesting video for search — use `vss-search-archive`.\n- Narrative summaries of a recorded clip — use `vss-summarize-video`.\n- Incident-range or alert-window reports — use `vss-generate-video-report` Mode B.\n- Reading analytics metrics, incidents, or alerts — use `vss-query-analytics`.\n\n## Reference contracts shipped with this skill\n\nThis skill bundles four reference files under `references\u002F`. Read whichever applies to the task in front of you:\n\n| File | Purpose | Audience |\n|---|---|---|\n| [`references\u002Fapi-reference.md`](references\u002Fapi-reference.md) | The full VIOS REST API reference (the runtime contract) — sensor management, storage, snapshots, clip extraction, WebRTC live\u002Freplay, RTSP proxy, recorder, service configuration, service discovery. **Read this when invoking any VIOS API operation.** | Operational users + this skill itself |\n| [`references\u002Fnvstreamer-api-reference.md`](references\u002Fnvstreamer-api-reference.md) | The **NvStreamer REST API reference** — version, sensor list\u002Finfo\u002Fstatus\u002Fstreams, the three upload methods (PUT v2 \u002F PUT v1 \u002F POST multipart) with the `nvstreamer-*` custom headers, delete, snapshots (frame-indexed live, timestamp-indexed storage), storage info, filesystem scan. NvStreamer (`vss-vios-nvstreamer`, the streamer-adaptor variant of `launch_vst`) is **brought up by the same profiles that bring VIOS up** — `dev-profile-alerts`, `dev-profile-lvs`, `dev-profile-search`, all warehouse profiles. See `integrate-vios-service.md § Topology B` for the deployment side. **Read this when serving test \u002F sample videos as synthetic RTSP, retrieving the RTSP URL NvStreamer generated for a file, or driving the canonical NvStreamer → VIOS handoff** (upload to NvStreamer → read RTSP URL → register that URL with VIOS via `\u002Fsensor\u002Fadd`). | Operational users + skill authors composing the upload → RTSP URL → VIOS `\u002Fsensor\u002Fadd` flow |\n| [`references\u002Fintegrate-vios-service.md`](references\u002Fintegrate-vios-service.md) | The **integration contract** — how VIOS plugs into other VSS microservices. Documents required peer services (RT-VLM, ELK, Kafka, Redis, `sdr-controller` \u002F SDRC), the structured `component_services:` block consumed by the `vss-build-vision-agent` skill's Step 4, integration inputs\u002Foutputs (Kafka topics, REST endpoints, file paths), environment variables, network requirements, and known integration constraints (e.g. the `\u002Furl`-variant double-`http:\u002F\u002F` bug, the VIOS + SDRC patching requirement). **Read this when authoring a skill that talks to VIOS as a peer, when composing a new VSS deployment, or when debugging caption-pipeline wiring.** | Skill authors, deployment composers, pair-file maintainers |\n| [`references\u002Fdeploy-vios-service.md`](references\u002Fdeploy-vios-service.md) | The **deployment contract** — what it takes to bring VIOS up. Documents container images and tags (`nvcr.io\u002Fnvidia\u002Fvss-core\u002Fvss-vios-*:3.2.0`), GPU \u002F CPU \u002F memory \u002F storage requirements, startup behavior + healthcheck tuning, required environment variables (notably `VST_INSTALL_ADDITIONAL_PACKAGES=true` for the libav apt-install step that gates uploads), known deployment issues (volume drift, libav missing, 502 from leftover containers), prerequisites, dry-run, verify-deployment, and tear-down commands. **Read this when VIOS isn't running and you (or your caller) need to deploy it standalone, when debugging container-startup failures, or when authoring a deploy skill that wraps VIOS.** | Operators, deploy-skill authors |\n\n## Deployment prerequisite — VIOS MUST be running\n\nThis skill is primarily an API client and assumes VIOS is already up and reachable at the VST ingress (default `http:\u002F\u002F${HOST_IP}:30888`). It does not deploy VIOS itself, but when VIOS is unreachable it coordinates a deploy using its bundled deployment runbook ([`references\u002Fdeploy-vios-service.md`](references\u002Fdeploy-vios-service.md)) or hands off to the full-stack `\u002Fvss-deploy-profile` skill. Before doing any work:\n\n1. **Probe VIOS:**\n   ```bash\n   curl -sf --max-time 5 \"http:\u002F\u002F${HOST_IP}:30888\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Fversion\" >\u002Fdev\u002Fnull\n   ```\n\n2. **If the probe fails, VIOS is not deployed.** Offer two paths forward:\n\n   > *\"VIOS is not reachable at `http:\u002F\u002F${HOST_IP}:30888` — no deployment is currently up. You have two options:*\n   > *(a) Bring up VIOS standalone using this skill's bundled [`references\u002Fdeploy-vios-service.md`](references\u002Fdeploy-vios-service.md) runbook — image tags, env vars (notably `VST_INSTALL_ADDITIONAL_PACKAGES=true`), host directories, NGC login, bring-up command, healthcheck loop, and known deployment issues are all documented there. This is the right path if you only need VIOS itself (no RT-VLM \u002F ELK \u002F etc.) or if you're composing a custom profile.*\n   > *(b) Deploy a full VSS profile that includes VIOS via the `\u002Fvss-deploy-profile` skill — `base` (recommended), `lvs`, `search`, or `alerts` all bring VIOS up alongside other components. This is the right path if you want a complete VSS stack.*\n   > *Which would you like?\"*\n\n   - If the user picks (a) → walk them through `references\u002Fdeploy-vios-service.md` step by step. Pay particular attention to its `§ Environment Variables — Required for Upload-to-Caption Path` and `§ Known Deployment Issues` sections — the libav-missing failure (`VST_INSTALL_ADDITIONAL_PACKAGES=true`) and the volume-drift hang (`docker compose up --yes` or `docker volume rm` first) are the two most common bring-up blockers. After deploy succeeds and the probe in step 1 passes, return here.\n   - If the user picks (b) → hand off to `\u002Fvss-deploy-profile -p \u003Cprofile>` (default `base`). Return here once it succeeds.\n   - If the user declines both → **stop**. VIOS operations require the VST backend to be up; do not attempt to fabricate responses or proceed with a degraded mode.\n\n   *Pre-authorized autonomous mode:* if your caller has granted explicit pre-authorization to deploy prerequisites (e.g. the request says \"pre-authorized to deploy prerequisites\", or you are running in a non-interactive evaluation harness with that permission), skip the confirmation and prefer path (a) — bring up VIOS standalone via this skill's bundled `references\u002Fdeploy-vios-service.md` — unless the request explicitly asks for a full VSS profile, in which case invoke `\u002Fvss-deploy-profile -p base`.\n\n3. **If the probe passes, proceed.** VIOS is up; all operations below are safe to execute.\n\n---\n\n## Known limitation — leftover containers from prior deploys\n\n`GET \u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Flist` and `GET \u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002F\u003CsensorId>\u002Fstreams`\ncan return **HTTP 502 Bad Gateway** or stale results when leftover `*-smc`\nVST containers from an earlier deploy survive teardown and win the\n`network_mode: host` port-bind race on `:30000` \u002F `:30888`. **Remediation:\nre-run `\u002Fvss-deploy-profile`** — its Step 0 teardown grep clears the full\n`sensor-ms-*` \u002F `vst-ingress-*` \u002F `sdr-*` \u002F `sdrc-*` \u002F `rtspserver-ms-*` set.\nOther paths (`storage\u002Ffile\u002F*` upload, `*\u002Fpicture\u002Furl` snapshot, `*\u002Furl` clip\nextraction) are unaffected. Full failure-mode catalogue, remediation, and the\ncurrent routing contract (direct vs SDRC; SDR\u002FEnvoy removed in PR #711) live in\n`references\u002Fdeploy-vios-service.md § Known Deployment Issues` and\n[issue #151](https:\u002F\u002Fgithub.com\u002FNVIDIA-AI-Blueprints\u002Fvideo-search-and-summarization\u002Fissues\u002F151).\n\n---\n\n## Setup\n\n**Base URL:** `http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1`\n\n**Endpoint Resolution:**\n- Use the VIOS endpoint associated with the active VSS deployment. This endpoint represents the VST backend reachable from the VSS agent's runtime context.\n- Do NOT attempt to discover host, IP, or port via shell commands, filesystem access, or static configuration files.\n- Assume the VSS deployment context already provides the correct network endpoint for VST.\n\n**Availability Check:**\n- Before making any API call, verify that the VST backend is reachable via the VSS deployment endpoint:\n  ```bash\n  curl -sf --connect-timeout 5 http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Fversion\n  ```\n- If the backend is unavailable (non-zero exit code or connection error), fail gracefully and report the error to the user. See the **Deployment prerequisite** section above for the deploy-or-stop branch.\n\n**Fallback:**\n- If endpoint information is not available from context, explicitly ask the user to provide the VST endpoint (host\u002FIP and port).\n\n**Run all curl commands yourself** — never instruct the user to run commands manually.\n\n**Auth:** Optional. Most deployments run without auth. If a `401` is returned, retry with `-H \"Authorization: Bearer \u003Ctoken>\"` and ask the user for the token.\n\n**Start\u002Fend time handling:** Any API that requires `startTime`\u002F`endTime`:\n- If the user provides them, use those values directly.\n- If the user does not provide them, first fetch the timelines for the relevant stream to find valid recorded ranges, then pick appropriate values from the response before calling the API. Never fabricate timestamps.\n\n**Resolving sensorId \u002F streamId:** If the user has not provided a sensorId or streamId, look it up automatically using one of:\n- `GET \u002Fsensor\u002Flist` — lists all sensors with their `sensorId`\n- `GET \u002Fsensor\u002F{sensorId}\u002Fstreams` — lists streams for a specific sensor with their `streamId`\n- `GET \u002Fsensor\u002Fstreams` — lists all streams across all sensors\n- `GET \u002Flive\u002Fstreams` — lists all active live streams\n- `GET \u002Freplay\u002Fstreams` — lists all available replay streams\n\nIf a sensor has only one stream, `sensorId` and `streamId` are equal and can be used interchangeably.\n\n---\n\n## Service Map\n\n| Capability | URL prefix | Authoritative reference |\n|---|---|---|\n| Version \u002F health check | `\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Fversion` | `references\u002Fapi-reference.md` |\n| Sensor list \u002F info \u002F status \u002F add \u002F delete | `\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002F` | `references\u002Fapi-reference.md` |\n| Sensor streams | `\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Fstreams`, `\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002F{id}\u002Fstreams` | `references\u002Fapi-reference.md` |\n| Network scan | `\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Fscan` | `references\u002Fapi-reference.md` |\n| Recording timelines | `\u002Fvst\u002Fapi\u002Fv1\u002Fstorage\u002F` | `references\u002Fapi-reference.md` |\n| Video clip download \u002F URL | `\u002Fvst\u002Fapi\u002Fv1\u002Fstorage\u002F` | `references\u002Fapi-reference.md` (operations) + `references\u002Fintegrate-vios-service.md § Known Integration Constraints` (Finding 8: `\u002Furl` double-`http:\u002F\u002F` bug — prefer binary direct endpoints) |\n| File upload \u002F delete | `\u002Fvst\u002Fapi\u002Fv1\u002Fstorage\u002F` | `references\u002Fapi-reference.md` (PUT v2 + legacy v1 endpoints) + `references\u002Fdeploy-vios-service.md § Known Deployment Issues` (Finding 9: libav-missing failure mode) |\n| Live streams \u002F snapshot (picture) | `\u002Fvst\u002Fapi\u002Fv1\u002Flive\u002F` | `references\u002Fapi-reference.md` |\n| Replay streams \u002F historical snapshot | `\u002Fvst\u002Fapi\u002Fv1\u002Freplay\u002F` | `references\u002Fapi-reference.md` (operations) + `references\u002Fintegrate-vios-service.md § Known Integration Constraints` (Finding 8) |\n| **NvStreamer**: file-to-RTSP republisher (upload, retrieve generated RTSP URL, filesystem scan, frame snapshots) | `http:\u002F\u002F${HOST_IP}:${NVSTREAMER_HTTP_PORT:-31000}\u002Fvst\u002Fapi\u002Fv1\u002F` | `references\u002Fnvstreamer-api-reference.md` (the streamer endpoint is **separate** from the VIOS gateway — different port, `type: \"streamer\"` on `\u002Fversion`) |\n\n---\n\n## Operations\n\nThe full VIOS REST API reference — sensor management, storage, snapshots, clip extraction, WebRTC live\u002Freplay, RTSP proxy, recorder, service configuration, and service discovery — lives in [`references\u002Fapi-reference.md`](references\u002Fapi-reference.md). Read that file when invoking any operation.\n\nWhen a request involves serving an on-disk video file as a synthetic RTSP camera (upload a sample to NvStreamer, retrieve the auto-generated RTSP URL, register that URL with VIOS), point at the NvStreamer endpoint and follow [`references\u002Fnvstreamer-api-reference.md`](references\u002Fnvstreamer-api-reference.md) for the surface. NvStreamer comes up automatically with any VIOS-using profile that ships it; do not deploy it separately.\n\nFor integration- and deployment-time questions about how VIOS interacts with other microservices or how it's brought up, defer to [`references\u002Fintegrate-vios-service.md`](references\u002Fintegrate-vios-service.md) and [`references\u002Fdeploy-vios-service.md`](references\u002Fdeploy-vios-service.md) respectively (see the **Reference contracts** table above for what each covers).\n\n---\n\n## Workflow: sensor name\u002FIP -> clip or snapshot\n\nWhen the user has a sensor name or IP but needs a clip or snapshot:\n\n0. Verify VST is reachable (see Setup — Availability Check):\n   ```bash\n   curl -sf --connect-timeout 5 \"http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Fversion\"\n   ```\n1. List sensors to find `sensorId`:\n   ```bash\n   curl -s \"http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002Flist\" | jq .\n   ```\n2. Get streams for that sensor to find `streamId` (prefer `isMain: true`):\n   ```bash\n   curl -s \"http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002F\u003CsensorId>\u002Fstreams\" | jq .\n   ```\n3. Check timelines to confirm a recording exists in the requested range:\n   ```bash\n   curl -s \"http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1\u002Fstorage\u002F\u003CstreamId>\u002Ftimelines\" | jq .\n   ```\n4. Download clip or snapshot using the `streamId`. Prefer the **binary direct endpoints** (`\u002Fstorage\u002Ffile\u002F\u003CstreamId>?startTime=...&endTime=...`, `\u002Freplay\u002Fstream\u002F\u003CstreamId>\u002Fpicture?startTime=...`, `\u002Fstorage\u002Fstream\u002F\u003CstreamId>\u002Fpicture?startTime=...`) over the `\u002Furl` JSON envelope variants — see `references\u002Fintegrate-vios-service.md § Known Integration Constraints` Finding 8 (the `\u002Furl` variants return double-`http:\u002F\u002F` URLs in 3.2.0 and require client-side stripping).\n\n---\n\n## Responses\n\n**Success with data:** JSON object or array.\n\n**Success with no data:** `null` — a `null` response means the API call succeeded but there is no data to return (e.g. no schedule configured, scan returned no results). It is not an error.\n\n**Success with boolean:** Some endpoints return `true` on success (e.g. `DELETE \u002Fsensor\u002F{sensorId}`).\n\n**Error:** JSON object with `error_code` and `error_message`:\n```json\n{\n  \"error_code\": \"VMSInternalError\",\n  \"error_message\": \"VMS internal processing error\"\n}\n```\n\nCommon codes: `VMSInternalError`, `VMSNotFound`, `VMSInvalidParameter`.\n\nIf you see `InvalidParameterError: Failed to get media information` on a PUT upload, this is the libav-missing failure mode — VIOS was deployed without `VST_INSTALL_ADDITIONAL_PACKAGES=true`. See `references\u002Fdeploy-vios-service.md § Known Deployment Issues` Finding 9 for the fix.\n\nIf you see double-`http:\u002F\u002F` prefixes in `imageUrl` or `videoUrl` fields on `\u002Furl`-variant responses, that's Finding 8 — strip the leading `http:\u002F\u002F` client-side or switch to binary direct endpoints.\n\n---\n\n## Examples\n\nExample operation prompts:\n- \"List the active VIOS sensors and show their stream status.\"\n- \"Upload this sample video to VIOS and return the generated stream id.\"\n- \"Download a two-second clip from this sensor's recording timeline.\"\n- \"Use NvStreamer to upload a file and retrieve its generated RTSP URL.\"\n\n## Limitations\n\n- VIOS operations require a reachable VST backend; stop or deploy prerequisites\n  when the health probe fails.\n- Most deployments do not require auth, but a deployment can add an external\n  auth layer.\n- Container-side paths in examples use `${VST_CONTAINER_ROOT}` as a neutral\n  placeholder for the VST install root inside the container. Resolve it from the\n  active deployment before using path examples.\n- Do not print API keys, bearer tokens, or generated credentials in logs or\n  final responses.\n\n## Troubleshooting\n\n- **Error**: health probe fails. **Cause**: VIOS is not deployed or the endpoint\n  is wrong. **Solution**: follow the deployment prerequisite flow or ask for the\n  correct VST endpoint.\n- **Error**: uploads fail with `Failed to get media information`. **Cause**:\n  libav packages were not installed in the VIOS container. **Solution**: set\n  `VST_INSTALL_ADDITIONAL_PACKAGES=true` and redeploy.\n- **Error**: `\u002Furl` responses contain `http:\u002F\u002Fhttp:\u002F\u002F...`. **Cause**: known URL\n  construction defect. **Solution**: use binary direct endpoints or strip the\n  duplicated prefix.\n\n---\n\n## Tips\n\n- **jq:** All JSON responses are piped through `jq .` for readability. Binary responses (clip download, snapshot) are not — they use `-o \u003Cfile>` instead.\n- **Time format:** Always ISO 8601 UTC, e.g. `2026-04-10T10:30:00Z` or `2026-04-10T10:30:00.000Z`.\n- **streamId header:** Live\u002Freplay\u002Frecorder endpoints require `streamId` as BOTH a path parameter AND a request header — include both.\n- **Large clips:** Use the binary direct `\u002Fstorage\u002Ffile\u002F\u003Cid>?...&container=mp4` endpoint with `-o clip.mp4` for direct streaming. The `\u002Furl` envelope variant has the Finding 8 double-`http:\u002F\u002F` defect — avoid until upstream fixes it or use client-side prefix stripping.\n- **Sensor vs stream ID:** `sensorId` identifies a camera; `streamId` identifies a specific video stream from that camera (a sensor can have a main stream and sub-streams).\n- **Identifying sensor type (RTSP vs uploaded file):** Call `GET \u002Fsensor\u002F\u003CsensorId>\u002Fstreams` and inspect the `url` field of each stream. If `url` starts with `rtsp:\u002F\u002F` it is a live RTSP\u002FIP camera stream. If `url` is a file path (e.g. `\"${VST_CONTAINER_ROOT}\u002Fstreamer_videos\u002FTruckAccident.mp4\"`) it is an uploaded file sensor. This determines which delete flow to use — see Section 8.\n- **Upload timestamp is honored for the recorded timeline:** When uploading a file via `PUT \u002Fvst\u002Fapi\u002Fv1\u002Fstorage\u002Ffile\u002F\u003Cfilename>?timestamp=\u003Ciso>`, the timeline returned by `GET \u002Fstorage\u002F\u003CstreamId>\u002Ftimelines` is anchored at the supplied timestamp, not the upload wall-clock time. Subsequent snapshot \u002F clip queries MUST use timestamps within this range — fetch the timeline first. See `references\u002Fapi-reference.md § 8` and `references\u002Fintegrate-vios-service.md § Integration Interfaces > Inputs > Upload video file` for the authoritative contract.\n- **Endpoint resolution:** The VST endpoint is provided by the VSS deployment context. Do not attempt manual IP\u002Fport discovery. If unavailable, ask the user. All curl examples use `\u003CVST_ENDPOINT>` as a placeholder — substitute the resolved endpoint before executing.\n",{"name":5,"license":15,"metadata":49,"description":7},{"tags":50,"version":51,"github-url":52},"nvidia blueprint operational","3.2.0","https:\u002F\u002Fgithub.com\u002FNVIDIA-AI-Blueprints\u002Fvideo-search-and-summarization","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fvss-manage-video-io-storage","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-manage-video-io-storage",{"tool":66,"command":67},"bunx","bunx skills add pattanation\u002FNorvik --skill vss-manage-video-io-storage",{"tool":69,"command":70},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill vss-manage-video-io-storage","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-video-io-storage\u002FSKILL.md",true,[74,80,84,88,92,96,100,104,108,112],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"BENCHMARK.md","REFERENCE","参考文档",4405,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-video-io-storage\u002FBENCHMARK.md",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"evals\u002Fevals.json",2298,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-video-io-storage\u002Fevals\u002Fevals.json",{"path":85,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":86,"sourceHtmlUrl":87},"evals\u002Fnvstreamer_ops.json",10195,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-video-io-storage\u002Fevals\u002Fnvstreamer_ops.json",{"path":89,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":90,"sourceHtmlUrl":91},"evals\u002Fvios_ops.json",11470,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-video-io-storage\u002Fevals\u002Fvios_ops.json",{"path":93,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fapi-reference.md",58098,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-video-io-storage\u002Freferences\u002Fapi-reference.md",{"path":97,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fdeploy-vios-service.md",34862,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-video-io-storage\u002Freferences\u002Fdeploy-vios-service.md",{"path":101,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fintegrate-vios-service.md",46985,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-video-io-storage\u002Freferences\u002Fintegrate-vios-service.md",{"path":105,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Fnvstreamer-api-reference.md",22739,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-video-io-storage\u002Freferences\u002Fnvstreamer-api-reference.md",{"path":109,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":110,"sourceHtmlUrl":111},"skill-card.md",3969,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-video-io-storage\u002Fskill-card.md",{"path":113,"resourceType":114,"resourceTypeDesc":115,"sizeBytes":116,"sourceHtmlUrl":117},"skill.oms.sig","OTHER","其他",6061,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-video-io-storage\u002Fskill.oms.sig",[119,149,174,197,219,234],{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":123,"sourceHtmlUrl":124,"categories":125,"keywords":132,"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",[126,129],{"categoryNo":127,"categoryName":128,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":130,"categoryName":131,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[133,134,135,42,136,137,138,139,140,141,142,143,144,145,146,147,148],"webapp","testing","webapp testing","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":153,"sourceHtmlUrl":154,"categories":155,"keywords":157,"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",[156],{"categoryNo":130,"categoryName":131,"taxonomyType":21,"taxonomyTypeDesc":22},[158,159,160,145,161,162,163,42,164,165,138,166,36,167,168,169,170,171,172,173],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","file","components","react","multi","state","routing","state management",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":178,"licenseFileUrl":179,"sourceHtmlUrl":180,"categories":181,"keywords":183,"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",[182],{"categoryNo":130,"categoryName":131,"taxonomyType":21,"taxonomyTypeDesc":22},[184,185,186,187,188,189,30,190,191,192,193,194,195,196],"functions","vueuse","vueuse functions","project","nuxt","apply","concise","build","https","features","vue","js","composables",{"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":178,"licenseFileUrl":201,"sourceHtmlUrl":202,"categories":203,"keywords":206,"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",[204,205],{"categoryNo":127,"categoryName":128,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":130,"categoryName":131,"taxonomyType":21,"taxonomyTypeDesc":22},[207,134,208,194,209,144,210,211,212,30,213,42,214,215,216,36,217,195,218],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":220,"name":221,"nameZh":6,"description":222,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":178,"licenseFileUrl":223,"sourceHtmlUrl":224,"categories":225,"keywords":227,"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",[226],{"categoryNo":130,"categoryName":131,"taxonomyType":21,"taxonomyTypeDesc":22},[228,194,229,209,230,212,231,30,217,232,233],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":178,"licenseFileUrl":238,"sourceHtmlUrl":239,"categories":240,"keywords":242,"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",[241],{"categoryNo":130,"categoryName":131,"taxonomyType":21,"taxonomyTypeDesc":22},[243,194,209,244,187,245,246,33,228,247,248,249,250,251,252,42,253,36,254,255],"vue best practices","Composition","files","tasks","pinia","work","options","ssr","typescript","as","vite","load","standard"]