[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71QC66QB2H6YHR8J5WYFEWG":3,"skill-same:01M71QC66QB2H6YHR8J5WYFEWG":160},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":14,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M71QC66QB2H6YHR8J5WYFEWG","vss-manage-alerts",null,"Use for VSS alert workflows — real-time monitoring, Alert-Bridge subscriptions, Slack notifications, incident queries, camera onboarding. Not for non-alert analytics.","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-alerts\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"alerts","manage","vss manage alerts","use","real-time","for","NVIDIA","camera","analytics","slack","notifications","monitoring","team","workflows","Blueprint","search","incident","time","bridge","Video","2026-11-10 13:02:02",false,"---\nname: vss-manage-alerts\ndescription: Use for VSS alert workflows — real-time monitoring, Alert-Bridge subscriptions, Slack notifications, incident queries, camera onboarding. Not for non-alert analytics.\nlicense: Apache-2.0\nmetadata:\n  version: \"3.2.0\"\n  author: \"NVIDIA Video Search and Summarization Team \u003Cvss-team@nvidia.com>\"\n  github-url: \"https:\u002F\u002Fgithub.com\u002FNVIDIA-AI-Blueprints\u002Fvideo-search-and-summarization\"\n  tags: \"nvidia blueprint operational\"\n---\n## Purpose\n\nOperate the VSS alert pipeline (mode detection, Alert-Bridge subscriptions, Slack notifications, queries, camera onboarding, verifier-prompt customization).\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\nFollow the routing tables and step-by-step workflows below. Each section that ends in *workflow*, *quick start*, or *flow* is intended to be executed top-to-bottom. Detailed reference material lives in `references\u002F` and helper scripts live in `scripts\u002F` — call them via `run_script` when the skill points to a script by name.\n\n## Examples\n\nRunnable end-to-end scenarios live under `evals\u002F` (each `*.json` manifest); inline `curl` blocks appear in each workflow below. Replay with `nv-base validate \u003Cthis-skill-dir> --agent-eval`.\n\n## Limitations\n\nRequires the matching VSS profile\u002Fmicroservice deployed and reachable. NGC-hosted models\u002FNIMs are subject to rate-limits, GPU-memory needs, and license terms; concurrency and storage limits depend on host hardware and the profile's compose file.\n\n## Troubleshooting\n\n- **Connection refused** → microservice not running: probe `\u002Fdocs` or `\u002Fhealth`, redeploy via `vss-deploy-profile`.\n- **HTTP 401\u002F403 on NGC pulls** → missing\u002Fexpired `NGC_CLI_API_KEY`: `docker login nvcr.io` and re-export the key.\n- **OOM \u002F model load failure** → insufficient GPU memory: use a smaller variant or `docker compose down` to free GPUs.\n\n# VSS Alert Management\n\nThe alerts profile runs in one of two modes (chosen at `\u002Fvss-deploy-profile -p alerts -m {verification,real-time}`) — see **The Two Modes** table below. This skill routes by **deployed mode + user intent** (monitoring vs subscription CRUD vs Slack webhook).\n\n## When to Use\n\n- Start\u002Fstop a real-time alert on a sensor (\"Start real-time alert for boxes dropped on warehouse_sample\")\n- Create\u002Flist\u002Fstop realtime subscription rules on Alert Bridge\n- Set up or manage Slack incident notifications\n- List or query detected incidents \u002F alerts; check verdicts (confirmed\u002Frejected\u002Funverified)\n- Add a new camera to the alerts pipeline; customize VLM-verifier prompts (CV mode)\n\n---\n\n## Deployment prerequisite\n\nRequires the VSS **alerts** profile on `$HOST_IP` in either `verification` (CV) or `real-time` (VLM) mode.\n\n```bash\n# Either vss-rtvi-cv (CV mode) OR vss-rtvi-vlm (VLM mode) must be present.\ncurl -sf --max-time 5 \"http:\u002F\u002F${HOST_IP}:8000\u002Fdocs\" >\u002Fdev\u002Fnull \\\n  && docker ps --format '{{.Names}}' \\\n     | grep -qE '^(vss-rtvi-cv|vss-rtvi-vlm)$'\n```\n\nIf the probe fails, ask which mode to deploy and hand off to `\u002Fvss-deploy-profile -p alerts -m \u003Cmode>` (decline → stop; pre-authorized autonomous deploy → run directly with `verification` by default). If it passes, detect the mode per Step 1.\n\n---\n\n## The Two Modes (Deploy-Time Choice)\n\n| Mode | Deploy flag | Env (`.env`) | What runs | What is available |\n|---|---|---|---|---|\n| **CV (verification)** | `-m verification` | `MODE=2d_cv` | RT-CV (Grounding DINO) + Behavior Analytics + `alert-bridge` VLM verifier + **`rtvi-vlm`** | **Both** static CV pipeline (Workflow A) **and** dynamic VLM real-time alerts (Workflows B\u002FD) |\n| **VLM (real-time)** | `-m real-time` | `MODE=2d_vlm` | `alert-bridge` + `rtvi-vlm` | **Only** dynamic VLM real-time alerts (Workflows B\u002FD) and `alert-bridge` backend. No static CV pipeline. |\n\n**Switching modes** uses the `vss-deploy-profile` teardown + deploy flow with the other `-m` flag (VLM → CV adds the CV pipeline; CV → VLM tears it down). `rtvi-vlm` runs in both modes.\n\n---\n\n## Step 1 — Detect the Currently Deployed Mode\n\nBefore running any alert workflow, check which mode is live. Use **CV-only** containers as the signal — `vss-rtvi-vlm` is **not** a reliable mode signal because it runs in both modes.\n\n```bash\n# CV verification mode (vss-behavior-analytics + vss-rtvi-cv are CV-only)\ndocker ps --format '{{.Names}}' | grep -qx vss-behavior-analytics && echo \"mode=CV\"\n\n# VLM real-time mode (no CV pipeline; vss-rtvi-vlm still runs)\ndocker ps --format '{{.Names}}' | grep -qx vss-behavior-analytics || \\\n  docker ps --format '{{.Names}}' | grep -qx vss-rtvi-vlm && echo \"mode=VLM\"\n```\n\nIf `vss-behavior-analytics` is present → **CV mode** (which also has `vss-rtvi-vlm`).\nIf only `vss-rtvi-vlm` is present (and no CV pipeline) → **VLM mode**.\nIf neither matches, the alerts profile is not deployed — direct the user to the `vss-deploy-profile` skill.\n\nAlternative signal (preferred when `docker ps` isn't accessible): check the profile's `generated.env`:\n\n```bash\ngrep -E '^MODE=' deploy\u002Fdocker\u002Fdeveloper-profiles\u002Fdev-profile-alerts\u002Fgenerated.env\n# MODE=2d_cv   → CV mode (full superset)\n# MODE=2d_vlm  → VLM real-time mode (vss-rtvi-vlm only; no vss-rtvi-cv)\n```\n\n---\n\n## Step 2 — Route by Deployed Mode\n\n| Deployed mode | User asks about… | Action |\n|---|---|---|\n| **VLM real-time** | Slack webhook setup\u002Fstatus\u002Ftest\u002Fstop | **Workflow E** — `references\u002Falert-notify.md` |\n| **VLM real-time** | rule CRUD, or a realtime alert on a sensor with a detection condition, or stop\u002Fdelete a named alert (by `alert_type`\u002Fcondition or rule ID) | **Workflow D** — `references\u002Falert-subscriptions.md` (incl. two-step stop\u002Fconfirm) |\n| **CV verification** | subscription\u002Frule CRUD or Slack\u002Fnotification setup | Refuse — see canonical refusal text below |\n| **CV or VLM** | generic start\u002Fstop monitoring **without** a detection condition | **Workflow B (VLM)** — call the VSS Agent; `rtvi-vlm` runs in both modes |\n| **CV or VLM** | incident lookup \u002F *what happened* (recent alerts, time-range, casual \"any alerts today?\") | **Workflow C (Query)** — works on both; **always run the query, never answer from memory** |\n| **CV** | static CV alert onboarding \u002F verdict-prompt customization | **Workflow A (CV)** — onboard RTSP via `vss-manage-video-io-storage`; pipeline auto-picks it up |\n| **VLM** | a CV \u002F behavior-analytics \u002F PPE-rule alert needing the static CV pipeline | **Redeployment required** — confirm first, then `vss-deploy-profile -m verification` |\n\n**Always confirm before triggering a redeploy.** A mode switch stops all currently-running monitoring and restarts services.\n\n### Intent precedence (first match wins)\n\n1. **Workflow E (Slack)** — Slack-specific keywords (`slack`, `webhook` + `slack`, `bot token`, `slack channel`). `notify` alone is **not** sufficient.\n2. **Workflow D (Subscriptions)** — sensor **plus** a detection condition, rule CRUD keywords (`rule`, `subscription`, rule ID), **or stopping\u002Fdeleting a named alert by type\u002Fcondition** (\"stop the PPE alert\", \"delete the collision rule\"). A named `alert_type`\u002Fcondition = an existing **rule** → D's two-step stop protocol (`GET \u002Fapi\u002Fv1\u002Frealtime` → yes\u002Fno confirm → delete), never Workflow B.\n3. **Workflow B (VLM monitoring)** — generic start\u002Fstop on a sensor with **no** detection condition and **no** alert-type qualifier (\"start\u002Fstop real-time alert for sensor X\"). A stop that names a type (\"stop the **PPE** alert\") is a rule stop → Workflow D.\n4. **Workflow C (Query)** — incident lookup \u002F *what happened* (`show\u002Flist incidents`, `recent alerts`, time-range queries, **and casual \"any alerts…?\" \u002F \"any alerts so far today?\" \u002F \"what's been triggered?\" phrasings**). Bare `alerts` (without `rule`\u002F`subscription`\u002F`active rules`) means **incidents** → Workflow C, never Workflow D.\n5. **Workflow A (CV)** — CV deployment handling for anything not matched above.\n\n> **`alerts` vs `alert rules` (C vs D) — pick exactly one, never both:**\n> *what happened \u002F has been triggered* (incidents) → **Workflow C**\n> (`POST \u002Fgenerate`). *What\n> rules\u002Fsubscriptions are configured or active* → **Workflow D** (the\n> **bare** `GET \u002Fapi\u002Fv1\u002Frealtime`, no `\u002Fincidents`). Bare `alerts` =\n> incidents (C); `alert rules` \u002F `subscriptions` \u002F `active rules` =\n> inventory (D). Never answer from memory; run the one correct call —\n> full endpoint detail in Workflow C below.\n\n**Disambiguation (B vs D):** if a sensor is named with start\u002Fmonitor language but the detection condition is unclear, ask:\n> *\"Do you want me to (a) create a persistent alert rule on Alert Bridge that keeps running until you delete it, or (b) start a one-time monitoring session via the VSS Agent?\"*\n\n**Stop routing (B vs D):** \"Stop the **<type>** alert\" (names an `alert_type`\u002Fcondition like PPE, collision, fire) = stop a **subscription rule** → **Workflow D** (find via `GET \u002Fapi\u002Fv1\u002Frealtime`, then the two-step stop\u002Fconfirm protocol in `references\u002Falert-subscriptions.md`; do **not** call `POST \u002Fgenerate`). A bare \"stop real-time alert \u002F stop monitoring on <sensor>\" with **no** type qualifier = Workflow B.\n\nIf a prompt mixes workflows (\"start monitoring and send to Slack\"), ask one clarifying question to split execution order.\n\n### CV-mode refusal text for D and E intents\n\nWhen the deployed mode is CV verification and the user asks for an alert-subscription or Slack\u002Fnotification intent, refuse with this message verbatim:\n\n> \"Alert subscriptions and Slack notifications are only supported in VLM real-time mode. Your current deployment is `\u003CCV verification | not deployed>`. To use these features, redeploy with `\u002Fvss-deploy-profile -p alerts -m real-time` (note: switching tears down current CV monitoring).\"\n\nNo auto-redeploy. The user decides whether to switch modes.\n\n---\n\n## Prereq for Either Mode: Sensor Must Be in VIOS\n\nBoth modes require the camera registered in VIOS first (via the `vss-manage-video-io-storage` skill):\n\n- RTSP URL \u002F IP camera → add it with `POST \u002Fsensor\u002Fadd` (that skill's Section 6); record the `sensorId` \u002F name.\n- Named existing sensor → confirm it appears in `GET \u002Fsensor\u002Flist` before proceeding.\n\nOn **CV**, adding the RTSP is the *entire* onboarding step (pipeline auto-picks it up). On **VLM**, it is a prerequisite to Workflow B.\n\n---\n\n## The Agent `\u002Fgenerate` Endpoint\n\nAll VLM-flow actions and all query actions go through the VSS Agent's natural-language endpoint:\n\n```bash\nAGENT=\"http:\u002F\u002F\u003CAGENT_ENDPOINT>\"   # default http:\u002F\u002Flocalhost:8000 on the alerts profile\n\ncurl -s -X POST \"$AGENT\u002Fgenerate\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"input_message\": \"\u003Cnatural-language request>\"}' | jq .\n```\n\n**Endpoint resolution:** use the agent endpoint from the active VSS deployment context. If unavailable, ask the user. Do not discover via filesystem.\n\n**Availability check:** `curl -sf --connect-timeout 5 \"$AGENT\u002Fdocs\"`.\n\nDo not call the `rtvi-vlm` microservice endpoints directly — always go through the agent. The agent internally dispatches to `rtvi_vlm_alert`, `rtvi_prompt_gen`, and `video_analytics_mcp.get_incidents`.\n\n---\n\n## Workflow A — CV Mode (`-m verification` \u002F `MODE=2d_cv`)\n\nCV alerts are **deployment-driven, not request-driven** — there is no agent\ncall to \"create\" one.\n\n1. Check if the sensor is in VIOS via `vss-manage-video-io-storage`'s `GET \u002Fsensor\u002Flist` (idempotent — don't blindly `POST \u002Fsensor\u002Fadd`).\n2. If missing, onboard via that skill's `POST \u002Fsensor\u002Fadd`. The CV pipeline auto-picks up the stream once registered and online.\n3. Confirm online: `curl -s \"http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002F\u003CsensorId>\u002Fstatus\" | jq .`\n4. Alerts land in Elasticsearch (Behavior Analytics → `alert-bridge` verification per `alert_type_config.json`). Query with **Workflow C**.\n\nA static-CV-pipeline alert on a VLM-only deployment is a mode mismatch — see the routing table above.\n\n---\n\n## Workflow B — VLM Real-time Monitoring (CV or VLM mode)\n\nGeneric start \u002F stop intents through the VSS Agent for a named sensor\nwithout a detection condition (if a condition is present, route to\nWorkflow D). `rtvi-vlm` runs in both modes.\n\n```bash\n# start: input_message = \"Start real-time alert for sensor \u003Cid>\"\n# stop:  input_message = \"Stop real-time alert for sensor \u003Cid>\"\ncurl -s -X POST \"$AGENT\u002Fgenerate\" -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"input_message\": \"\u003Cstart|stop> real-time alert for sensor \u003Cid>\"}' | jq .\n```\n\nUnder the hood: `rtvi_prompt_gen` → `rtvi_vlm_alert action=\"start\"`.\nEvery chunk is captioned; a chunk whose VLM response contains `yes`\u002F`true`\n(case-insensitive) publishes an incident to `mdx-vlm-incidents`. Prompts\nmust force a Yes\u002FNo answer. A static-CV-pipeline request on a VLM-only\ndeployment is a mode mismatch — see the routing table.\n\n---\n\n## Workflow D — Alert Subscriptions (VLM real-time mode only)\n\nCreate \u002F list \u002F delete persistent realtime alert rules on Alert Bridge.\nRoute here when the prompt has rule keywords (`rule`, `subscription`, a rule\nID) **or** when it pairs a specific sensor with a specific detection\ncondition (e.g. \"Set up a realtime alert on warehouse-dock-1 for PPE\nviolations\", \"Watch sensor entrance-1 for tailgating\", \"Stop rule\n496aebd1-…\").\n\n**Not here:** generic start\u002Fstop without a condition (→ Workflow B) or Slack\noperations (→ Workflow E).\n\nLoad and follow `references\u002Falert-subscriptions.md` as the authoritative\nplaybook for subscription CRUD. VLM real-time mode only; refuse with the\ncanonical refusal text on CV.\n\n---\n\n## Workflow E — Slack Notifications (VLM real-time mode only)\n\nUse when the user **explicitly mentions Slack or the webhook relay** (start\u002Fstop webhook server, check status\u002Fhealth, send a test message, set Slack channel\u002Ftoken). The word `notify` alone is **not** enough.\n\n> **`alert-notify` (port 9090) ≠ `vss-alert-bridge` (`\u002Fapi\u002Fv1\u002Frealtime`).**\n> Do NOT touch `vss-alert-bridge` for Slack ops.\n\nRoutes here: \"Set up Slack notifications\", \"Check if alert-notify is running\", \"Send a test alert to Slack\". Does **not** route here: \"Notify me when someone enters the zone\" (→ D\u002FB), \"Alert and notify on my phone\" (ambiguous — ask).\n\nLoad and follow `references\u002Falert-notify.md`. Code lives in `scripts\u002Falert-notify\u002F`. VLM real-time mode only.\n\n---\n\n## Workflow C — Query \u002F List Alerts (works on either mode)\n\nBoth CV- and VLM-generated alerts land in Elasticsearch and are\nqueryable via the agent's `video_analytics_mcp.get_incidents` tool. POST\nnatural-language requests to `$AGENT\u002Fgenerate` — \"Show me recent alerts\nfor sensor X\", \"List confirmed alerts from the last hour\", \"Show\ncollision incidents from Camera_02 between `\u003CISO>` and `\u003CISO>`\".\n\n**Casual phrasings route here too.** Questions like \"Any alerts so far\ntoday?\", \"Any alerts today?\", \"What's been triggered?\", or \"Anything\ndetected lately?\" are incident queries — issue a `POST \u002Fgenerate` (e.g.\n`{\"input_message\": \"List alerts from today\"}`) and summarize the result.\n**Never answer these from memory and never reply \"no alerts\" without\nrunning the query.** A bare \"alerts\" question is *always* an incident\nlookup (Workflow C), not a subscription-rule listing (Workflow D).\n\n> **Do NOT list subscription rules for an incident query.** The **bare**\n> `GET \u002Fapi\u002Fv1\u002Frealtime` (no `\u002Fincidents`) lists *rules* (Workflow D) and\n> is wrong for \"what happened\" — never call\u002Fprobe it or load the Workflow\n> D playbook for an incident query.\n>\n> **Empty result is a valid answer.** If no incidents match (e.g. a\n> freshly deployed system with no activity yet), report that **none were\n> found \u002F the count is 0** for the requested period and STOP — do not fall\n> back to listing rules or hunting other endpoints.\n\nFor\nricher \u002F non-natural-language filtering (sensor-level, time-series,\ncounts) use the **`vss-query-analytics` skill** (VA-MCP on port 9901).\n\n### Verdict interpretation & CV verifier prompts (CV mode only)\n\nCV alerts carry a VLM verification verdict (`confirmed` \u002F `rejected` \u002F\n`unverified`); VLM real-time incidents have no separate verdict (the\ntrigger is itself a Yes\u002FNo VLM answer). CV-path verifier prompts are\ncustomizable via `alert_type_config.json` (restart `alert-bridge` to\napply). See `references\u002Fcv-verifier-prompts.md` for the verdict table,\nfield meanings, and the prompt-customization rules.\n\n---\n\n## Cross-Skill Links\n\n| Task | Skill |\n|---|---|\n| Deploy, redeploy, or switch alert mode | **`vss-deploy-profile`** — `-p alerts -m {verification,real-time}` |\n| Add an RTSP\u002FIP camera, list sensors, snapshots, clips | **`vss-manage-video-io-storage`** (Section 6 for Add Sensor) |\n| Time-range incident \u002F occupancy \u002F PPE metrics from Elasticsearch | **`vss-query-analytics`** (VA-MCP :9901) |\n| Detailed incident report from an alert | **`vss-generate-video-report`** |\n| Subscriptions \u002F Slack sub-workflows | `references\u002Falert-subscriptions.md`, `references\u002Falert-notify.md` (code in `scripts\u002Falert-notify\u002F`) |\n\n---\n\n## Gotchas\n\n- **`alert-notify` (port 9090) ≠ `vss-alert-bridge`.** Slack ops → Workflow E (`alert-notify`); never route Slack to `vss-alert-bridge`'s `\u002Fapi\u002Fv1\u002Frealtime`.\n- **Workflow scope by mode:** A is CV-only; B and C work on either mode; D and E are VLM real-time only (refuse on CV with the canonical text).\n- **Don't use `vss-rtvi-vlm` as a mode signal** — it runs in both modes. Use `vss-behavior-analytics` (CV-only) or the `MODE` env var.\n- **A mode switch tears down the current deployment** — running VLM streams and un-persisted CV alert state are lost.\n- **Always go through `$AGENT\u002Fgenerate`** — never call `rtvi-vlm` directly. The VLM trigger is a `\"yes\"`\u002F`\"true\"` token match (case-insensitive); `rtvi_prompt_gen` enforces the Yes\u002FNo pattern, so don't hand-craft prompts that break it.\n- **Sensor must already be in VIOS** for either mode (use `vss-manage-video-io-storage` for RTSP-only inputs).\n\nbump:1\n","## Purpose\n\nOperate the VSS alert pipeline (mode detection, Alert-Bridge subscriptions, Slack notifications, queries, camera onboarding, verifier-prompt customization).\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\nFollow the routing tables and step-by-step workflows below. Each section that ends in *workflow*, *quick start*, or *flow* is intended to be executed top-to-bottom. Detailed reference material lives in `references\u002F` and helper scripts live in `scripts\u002F` — call them via `run_script` when the skill points to a script by name.\n\n## Examples\n\nRunnable end-to-end scenarios live under `evals\u002F` (each `*.json` manifest); inline `curl` blocks appear in each workflow below. Replay with `nv-base validate \u003Cthis-skill-dir> --agent-eval`.\n\n## Limitations\n\nRequires the matching VSS profile\u002Fmicroservice deployed and reachable. NGC-hosted models\u002FNIMs are subject to rate-limits, GPU-memory needs, and license terms; concurrency and storage limits depend on host hardware and the profile's compose file.\n\n## Troubleshooting\n\n- **Connection refused** → microservice not running: probe `\u002Fdocs` or `\u002Fhealth`, redeploy via `vss-deploy-profile`.\n- **HTTP 401\u002F403 on NGC pulls** → missing\u002Fexpired `NGC_CLI_API_KEY`: `docker login nvcr.io` and re-export the key.\n- **OOM \u002F model load failure** → insufficient GPU memory: use a smaller variant or `docker compose down` to free GPUs.\n\n# VSS Alert Management\n\nThe alerts profile runs in one of two modes (chosen at `\u002Fvss-deploy-profile -p alerts -m {verification,real-time}`) — see **The Two Modes** table below. This skill routes by **deployed mode + user intent** (monitoring vs subscription CRUD vs Slack webhook).\n\n## When to Use\n\n- Start\u002Fstop a real-time alert on a sensor (\"Start real-time alert for boxes dropped on warehouse_sample\")\n- Create\u002Flist\u002Fstop realtime subscription rules on Alert Bridge\n- Set up or manage Slack incident notifications\n- List or query detected incidents \u002F alerts; check verdicts (confirmed\u002Frejected\u002Funverified)\n- Add a new camera to the alerts pipeline; customize VLM-verifier prompts (CV mode)\n\n---\n\n## Deployment prerequisite\n\nRequires the VSS **alerts** profile on `$HOST_IP` in either `verification` (CV) or `real-time` (VLM) mode.\n\n```bash\n# Either vss-rtvi-cv (CV mode) OR vss-rtvi-vlm (VLM mode) must be present.\ncurl -sf --max-time 5 \"http:\u002F\u002F${HOST_IP}:8000\u002Fdocs\" >\u002Fdev\u002Fnull \\\n  && docker ps --format '{{.Names}}' \\\n     | grep -qE '^(vss-rtvi-cv|vss-rtvi-vlm)$'\n```\n\nIf the probe fails, ask which mode to deploy and hand off to `\u002Fvss-deploy-profile -p alerts -m \u003Cmode>` (decline → stop; pre-authorized autonomous deploy → run directly with `verification` by default). If it passes, detect the mode per Step 1.\n\n---\n\n## The Two Modes (Deploy-Time Choice)\n\n| Mode | Deploy flag | Env (`.env`) | What runs | What is available |\n|---|---|---|---|---|\n| **CV (verification)** | `-m verification` | `MODE=2d_cv` | RT-CV (Grounding DINO) + Behavior Analytics + `alert-bridge` VLM verifier + **`rtvi-vlm`** | **Both** static CV pipeline (Workflow A) **and** dynamic VLM real-time alerts (Workflows B\u002FD) |\n| **VLM (real-time)** | `-m real-time` | `MODE=2d_vlm` | `alert-bridge` + `rtvi-vlm` | **Only** dynamic VLM real-time alerts (Workflows B\u002FD) and `alert-bridge` backend. No static CV pipeline. |\n\n**Switching modes** uses the `vss-deploy-profile` teardown + deploy flow with the other `-m` flag (VLM → CV adds the CV pipeline; CV → VLM tears it down). `rtvi-vlm` runs in both modes.\n\n---\n\n## Step 1 — Detect the Currently Deployed Mode\n\nBefore running any alert workflow, check which mode is live. Use **CV-only** containers as the signal — `vss-rtvi-vlm` is **not** a reliable mode signal because it runs in both modes.\n\n```bash\n# CV verification mode (vss-behavior-analytics + vss-rtvi-cv are CV-only)\ndocker ps --format '{{.Names}}' | grep -qx vss-behavior-analytics && echo \"mode=CV\"\n\n# VLM real-time mode (no CV pipeline; vss-rtvi-vlm still runs)\ndocker ps --format '{{.Names}}' | grep -qx vss-behavior-analytics || \\\n  docker ps --format '{{.Names}}' | grep -qx vss-rtvi-vlm && echo \"mode=VLM\"\n```\n\nIf `vss-behavior-analytics` is present → **CV mode** (which also has `vss-rtvi-vlm`).\nIf only `vss-rtvi-vlm` is present (and no CV pipeline) → **VLM mode**.\nIf neither matches, the alerts profile is not deployed — direct the user to the `vss-deploy-profile` skill.\n\nAlternative signal (preferred when `docker ps` isn't accessible): check the profile's `generated.env`:\n\n```bash\ngrep -E '^MODE=' deploy\u002Fdocker\u002Fdeveloper-profiles\u002Fdev-profile-alerts\u002Fgenerated.env\n# MODE=2d_cv   → CV mode (full superset)\n# MODE=2d_vlm  → VLM real-time mode (vss-rtvi-vlm only; no vss-rtvi-cv)\n```\n\n---\n\n## Step 2 — Route by Deployed Mode\n\n| Deployed mode | User asks about… | Action |\n|---|---|---|\n| **VLM real-time** | Slack webhook setup\u002Fstatus\u002Ftest\u002Fstop | **Workflow E** — `references\u002Falert-notify.md` |\n| **VLM real-time** | rule CRUD, or a realtime alert on a sensor with a detection condition, or stop\u002Fdelete a named alert (by `alert_type`\u002Fcondition or rule ID) | **Workflow D** — `references\u002Falert-subscriptions.md` (incl. two-step stop\u002Fconfirm) |\n| **CV verification** | subscription\u002Frule CRUD or Slack\u002Fnotification setup | Refuse — see canonical refusal text below |\n| **CV or VLM** | generic start\u002Fstop monitoring **without** a detection condition | **Workflow B (VLM)** — call the VSS Agent; `rtvi-vlm` runs in both modes |\n| **CV or VLM** | incident lookup \u002F *what happened* (recent alerts, time-range, casual \"any alerts today?\") | **Workflow C (Query)** — works on both; **always run the query, never answer from memory** |\n| **CV** | static CV alert onboarding \u002F verdict-prompt customization | **Workflow A (CV)** — onboard RTSP via `vss-manage-video-io-storage`; pipeline auto-picks it up |\n| **VLM** | a CV \u002F behavior-analytics \u002F PPE-rule alert needing the static CV pipeline | **Redeployment required** — confirm first, then `vss-deploy-profile -m verification` |\n\n**Always confirm before triggering a redeploy.** A mode switch stops all currently-running monitoring and restarts services.\n\n### Intent precedence (first match wins)\n\n1. **Workflow E (Slack)** — Slack-specific keywords (`slack`, `webhook` + `slack`, `bot token`, `slack channel`). `notify` alone is **not** sufficient.\n2. **Workflow D (Subscriptions)** — sensor **plus** a detection condition, rule CRUD keywords (`rule`, `subscription`, rule ID), **or stopping\u002Fdeleting a named alert by type\u002Fcondition** (\"stop the PPE alert\", \"delete the collision rule\"). A named `alert_type`\u002Fcondition = an existing **rule** → D's two-step stop protocol (`GET \u002Fapi\u002Fv1\u002Frealtime` → yes\u002Fno confirm → delete), never Workflow B.\n3. **Workflow B (VLM monitoring)** — generic start\u002Fstop on a sensor with **no** detection condition and **no** alert-type qualifier (\"start\u002Fstop real-time alert for sensor X\"). A stop that names a type (\"stop the **PPE** alert\") is a rule stop → Workflow D.\n4. **Workflow C (Query)** — incident lookup \u002F *what happened* (`show\u002Flist incidents`, `recent alerts`, time-range queries, **and casual \"any alerts…?\" \u002F \"any alerts so far today?\" \u002F \"what's been triggered?\" phrasings**). Bare `alerts` (without `rule`\u002F`subscription`\u002F`active rules`) means **incidents** → Workflow C, never Workflow D.\n5. **Workflow A (CV)** — CV deployment handling for anything not matched above.\n\n> **`alerts` vs `alert rules` (C vs D) — pick exactly one, never both:**\n> *what happened \u002F has been triggered* (incidents) → **Workflow C**\n> (`POST \u002Fgenerate`). *What\n> rules\u002Fsubscriptions are configured or active* → **Workflow D** (the\n> **bare** `GET \u002Fapi\u002Fv1\u002Frealtime`, no `\u002Fincidents`). Bare `alerts` =\n> incidents (C); `alert rules` \u002F `subscriptions` \u002F `active rules` =\n> inventory (D). Never answer from memory; run the one correct call —\n> full endpoint detail in Workflow C below.\n\n**Disambiguation (B vs D):** if a sensor is named with start\u002Fmonitor language but the detection condition is unclear, ask:\n> *\"Do you want me to (a) create a persistent alert rule on Alert Bridge that keeps running until you delete it, or (b) start a one-time monitoring session via the VSS Agent?\"*\n\n**Stop routing (B vs D):** \"Stop the **<type>** alert\" (names an `alert_type`\u002Fcondition like PPE, collision, fire) = stop a **subscription rule** → **Workflow D** (find via `GET \u002Fapi\u002Fv1\u002Frealtime`, then the two-step stop\u002Fconfirm protocol in `references\u002Falert-subscriptions.md`; do **not** call `POST \u002Fgenerate`). A bare \"stop real-time alert \u002F stop monitoring on <sensor>\" with **no** type qualifier = Workflow B.\n\nIf a prompt mixes workflows (\"start monitoring and send to Slack\"), ask one clarifying question to split execution order.\n\n### CV-mode refusal text for D and E intents\n\nWhen the deployed mode is CV verification and the user asks for an alert-subscription or Slack\u002Fnotification intent, refuse with this message verbatim:\n\n> \"Alert subscriptions and Slack notifications are only supported in VLM real-time mode. Your current deployment is `\u003CCV verification | not deployed>`. To use these features, redeploy with `\u002Fvss-deploy-profile -p alerts -m real-time` (note: switching tears down current CV monitoring).\"\n\nNo auto-redeploy. The user decides whether to switch modes.\n\n---\n\n## Prereq for Either Mode: Sensor Must Be in VIOS\n\nBoth modes require the camera registered in VIOS first (via the `vss-manage-video-io-storage` skill):\n\n- RTSP URL \u002F IP camera → add it with `POST \u002Fsensor\u002Fadd` (that skill's Section 6); record the `sensorId` \u002F name.\n- Named existing sensor → confirm it appears in `GET \u002Fsensor\u002Flist` before proceeding.\n\nOn **CV**, adding the RTSP is the *entire* onboarding step (pipeline auto-picks it up). On **VLM**, it is a prerequisite to Workflow B.\n\n---\n\n## The Agent `\u002Fgenerate` Endpoint\n\nAll VLM-flow actions and all query actions go through the VSS Agent's natural-language endpoint:\n\n```bash\nAGENT=\"http:\u002F\u002F\u003CAGENT_ENDPOINT>\"   # default http:\u002F\u002Flocalhost:8000 on the alerts profile\n\ncurl -s -X POST \"$AGENT\u002Fgenerate\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"input_message\": \"\u003Cnatural-language request>\"}' | jq .\n```\n\n**Endpoint resolution:** use the agent endpoint from the active VSS deployment context. If unavailable, ask the user. Do not discover via filesystem.\n\n**Availability check:** `curl -sf --connect-timeout 5 \"$AGENT\u002Fdocs\"`.\n\nDo not call the `rtvi-vlm` microservice endpoints directly — always go through the agent. The agent internally dispatches to `rtvi_vlm_alert`, `rtvi_prompt_gen`, and `video_analytics_mcp.get_incidents`.\n\n---\n\n## Workflow A — CV Mode (`-m verification` \u002F `MODE=2d_cv`)\n\nCV alerts are **deployment-driven, not request-driven** — there is no agent\ncall to \"create\" one.\n\n1. Check if the sensor is in VIOS via `vss-manage-video-io-storage`'s `GET \u002Fsensor\u002Flist` (idempotent — don't blindly `POST \u002Fsensor\u002Fadd`).\n2. If missing, onboard via that skill's `POST \u002Fsensor\u002Fadd`. The CV pipeline auto-picks up the stream once registered and online.\n3. Confirm online: `curl -s \"http:\u002F\u002F\u003CVST_ENDPOINT>\u002Fvst\u002Fapi\u002Fv1\u002Fsensor\u002F\u003CsensorId>\u002Fstatus\" | jq .`\n4. Alerts land in Elasticsearch (Behavior Analytics → `alert-bridge` verification per `alert_type_config.json`). Query with **Workflow C**.\n\nA static-CV-pipeline alert on a VLM-only deployment is a mode mismatch — see the routing table above.\n\n---\n\n## Workflow B — VLM Real-time Monitoring (CV or VLM mode)\n\nGeneric start \u002F stop intents through the VSS Agent for a named sensor\nwithout a detection condition (if a condition is present, route to\nWorkflow D). `rtvi-vlm` runs in both modes.\n\n```bash\n# start: input_message = \"Start real-time alert for sensor \u003Cid>\"\n# stop:  input_message = \"Stop real-time alert for sensor \u003Cid>\"\ncurl -s -X POST \"$AGENT\u002Fgenerate\" -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"input_message\": \"\u003Cstart|stop> real-time alert for sensor \u003Cid>\"}' | jq .\n```\n\nUnder the hood: `rtvi_prompt_gen` → `rtvi_vlm_alert action=\"start\"`.\nEvery chunk is captioned; a chunk whose VLM response contains `yes`\u002F`true`\n(case-insensitive) publishes an incident to `mdx-vlm-incidents`. Prompts\nmust force a Yes\u002FNo answer. A static-CV-pipeline request on a VLM-only\ndeployment is a mode mismatch — see the routing table.\n\n---\n\n## Workflow D — Alert Subscriptions (VLM real-time mode only)\n\nCreate \u002F list \u002F delete persistent realtime alert rules on Alert Bridge.\nRoute here when the prompt has rule keywords (`rule`, `subscription`, a rule\nID) **or** when it pairs a specific sensor with a specific detection\ncondition (e.g. \"Set up a realtime alert on warehouse-dock-1 for PPE\nviolations\", \"Watch sensor entrance-1 for tailgating\", \"Stop rule\n496aebd1-…\").\n\n**Not here:** generic start\u002Fstop without a condition (→ Workflow B) or Slack\noperations (→ Workflow E).\n\nLoad and follow `references\u002Falert-subscriptions.md` as the authoritative\nplaybook for subscription CRUD. VLM real-time mode only; refuse with the\ncanonical refusal text on CV.\n\n---\n\n## Workflow E — Slack Notifications (VLM real-time mode only)\n\nUse when the user **explicitly mentions Slack or the webhook relay** (start\u002Fstop webhook server, check status\u002Fhealth, send a test message, set Slack channel\u002Ftoken). The word `notify` alone is **not** enough.\n\n> **`alert-notify` (port 9090) ≠ `vss-alert-bridge` (`\u002Fapi\u002Fv1\u002Frealtime`).**\n> Do NOT touch `vss-alert-bridge` for Slack ops.\n\nRoutes here: \"Set up Slack notifications\", \"Check if alert-notify is running\", \"Send a test alert to Slack\". Does **not** route here: \"Notify me when someone enters the zone\" (→ D\u002FB), \"Alert and notify on my phone\" (ambiguous — ask).\n\nLoad and follow `references\u002Falert-notify.md`. Code lives in `scripts\u002Falert-notify\u002F`. VLM real-time mode only.\n\n---\n\n## Workflow C — Query \u002F List Alerts (works on either mode)\n\nBoth CV- and VLM-generated alerts land in Elasticsearch and are\nqueryable via the agent's `video_analytics_mcp.get_incidents` tool. POST\nnatural-language requests to `$AGENT\u002Fgenerate` — \"Show me recent alerts\nfor sensor X\", \"List confirmed alerts from the last hour\", \"Show\ncollision incidents from Camera_02 between `\u003CISO>` and `\u003CISO>`\".\n\n**Casual phrasings route here too.** Questions like \"Any alerts so far\ntoday?\", \"Any alerts today?\", \"What's been triggered?\", or \"Anything\ndetected lately?\" are incident queries — issue a `POST \u002Fgenerate` (e.g.\n`{\"input_message\": \"List alerts from today\"}`) and summarize the result.\n**Never answer these from memory and never reply \"no alerts\" without\nrunning the query.** A bare \"alerts\" question is *always* an incident\nlookup (Workflow C), not a subscription-rule listing (Workflow D).\n\n> **Do NOT list subscription rules for an incident query.** The **bare**\n> `GET \u002Fapi\u002Fv1\u002Frealtime` (no `\u002Fincidents`) lists *rules* (Workflow D) and\n> is wrong for \"what happened\" — never call\u002Fprobe it or load the Workflow\n> D playbook for an incident query.\n>\n> **Empty result is a valid answer.** If no incidents match (e.g. a\n> freshly deployed system with no activity yet), report that **none were\n> found \u002F the count is 0** for the requested period and STOP — do not fall\n> back to listing rules or hunting other endpoints.\n\nFor\nricher \u002F non-natural-language filtering (sensor-level, time-series,\ncounts) use the **`vss-query-analytics` skill** (VA-MCP on port 9901).\n\n### Verdict interpretation & CV verifier prompts (CV mode only)\n\nCV alerts carry a VLM verification verdict (`confirmed` \u002F `rejected` \u002F\n`unverified`); VLM real-time incidents have no separate verdict (the\ntrigger is itself a Yes\u002FNo VLM answer). CV-path verifier prompts are\ncustomizable via `alert_type_config.json` (restart `alert-bridge` to\napply). See `references\u002Fcv-verifier-prompts.md` for the verdict table,\nfield meanings, and the prompt-customization rules.\n\n---\n\n## Cross-Skill Links\n\n| Task | Skill |\n|---|---|\n| Deploy, redeploy, or switch alert mode | **`vss-deploy-profile`** — `-p alerts -m {verification,real-time}` |\n| Add an RTSP\u002FIP camera, list sensors, snapshots, clips | **`vss-manage-video-io-storage`** (Section 6 for Add Sensor) |\n| Time-range incident \u002F occupancy \u002F PPE metrics from Elasticsearch | **`vss-query-analytics`** (VA-MCP :9901) |\n| Detailed incident report from an alert | **`vss-generate-video-report`** |\n| Subscriptions \u002F Slack sub-workflows | `references\u002Falert-subscriptions.md`, `references\u002Falert-notify.md` (code in `scripts\u002Falert-notify\u002F`) |\n\n---\n\n## Gotchas\n\n- **`alert-notify` (port 9090) ≠ `vss-alert-bridge`.** Slack ops → Workflow E (`alert-notify`); never route Slack to `vss-alert-bridge`'s `\u002Fapi\u002Fv1\u002Frealtime`.\n- **Workflow scope by mode:** A is CV-only; B and C work on either mode; D and E are VLM real-time only (refuse on CV with the canonical text).\n- **Don't use `vss-rtvi-vlm` as a mode signal** — it runs in both modes. Use `vss-behavior-analytics` (CV-only) or the `MODE` env var.\n- **A mode switch tears down the current deployment** — running VLM streams and un-persisted CV alert state are lost.\n- **Always go through `$AGENT\u002Fgenerate`** — never call `rtvi-vlm` directly. The VLM trigger is a `\"yes\"`\u002F`\"true\"` token match (case-insensitive); `rtvi_prompt_gen` enforces the Yes\u002FNo pattern, so don't hand-craft prompts that break it.\n- **Sensor must already be in VIOS** for either mode (use `vss-manage-video-io-storage` for RTSP-only inputs).\n\nbump:1\n",{"name":5,"license":15,"metadata":52,"description":7},{"tags":53,"author":54,"version":55,"github-url":56},"nvidia blueprint operational","NVIDIA Video Search and Summarization Team \u003Cvss-team@nvidia.com>","3.2.0","https:\u002F\u002Fgithub.com\u002FNVIDIA-AI-Blueprints\u002Fvideo-search-and-summarization","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fvss-manage-alerts","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":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add pattanation\u002FNorvik --skill vss-manage-alerts",{"tool":70,"command":71},"bunx","bunx skills add pattanation\u002FNorvik --skill vss-manage-alerts",{"tool":73,"command":74},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill vss-manage-alerts","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002FSKILL.md",true,[78,84,88,92,96,100,104,108,112,116,122,126,130,134,138,142,146,150,154],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"BENCHMARK.md","REFERENCE","参考文档",3479,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002FBENCHMARK.md",{"path":85,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":86,"sourceHtmlUrl":87},"evals\u002Falerts_vlm_real_time.json",5660,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fevals\u002Falerts_vlm_real_time.json",{"path":89,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":90,"sourceHtmlUrl":91},"evals\u002Fevals.json",8127,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fevals\u002Fevals.json",{"path":93,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":94,"sourceHtmlUrl":95},"evals\u002Frouting_vlm_c_vs_d.json",2989,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fevals\u002Frouting_vlm_c_vs_d.json",{"path":97,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":98,"sourceHtmlUrl":99},"evals\u002Fsubscriptions_create_phrasings.json",8311,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fevals\u002Fsubscriptions_create_phrasings.json",{"path":101,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":102,"sourceHtmlUrl":103},"evals\u002Fsubscriptions_lifecycle.json",5450,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fevals\u002Fsubscriptions_lifecycle.json",{"path":105,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Falert-notify.md",16768,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Freferences\u002Falert-notify.md",{"path":109,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":110,"sourceHtmlUrl":111},"references\u002Falert-subscriptions.md",21713,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Freferences\u002Falert-subscriptions.md",{"path":113,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":114,"sourceHtmlUrl":115},"references\u002Fcv-verifier-prompts.md",1690,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Freferences\u002Fcv-verifier-prompts.md",{"path":117,"resourceType":118,"resourceTypeDesc":119,"sizeBytes":120,"sourceHtmlUrl":121},"scripts\u002Falert-notify\u002F.env.example","SCRIPT","脚本",1263,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fscripts\u002Falert-notify\u002F.env.example",{"path":123,"resourceType":118,"resourceTypeDesc":119,"sizeBytes":124,"sourceHtmlUrl":125},"scripts\u002Falert-notify\u002F.gitignore",30,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fscripts\u002Falert-notify\u002F.gitignore",{"path":127,"resourceType":118,"resourceTypeDesc":119,"sizeBytes":128,"sourceHtmlUrl":129},"scripts\u002Falert-notify\u002Fincident_utils.py",2374,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fscripts\u002Falert-notify\u002Fincident_utils.py",{"path":131,"resourceType":118,"resourceTypeDesc":119,"sizeBytes":132,"sourceHtmlUrl":133},"scripts\u002Falert-notify\u002Fnotifier_base.py",2413,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fscripts\u002Falert-notify\u002Fnotifier_base.py",{"path":135,"resourceType":118,"resourceTypeDesc":119,"sizeBytes":136,"sourceHtmlUrl":137},"scripts\u002Falert-notify\u002Fopen_claw_dashboard_notifier.py",11507,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fscripts\u002Falert-notify\u002Fopen_claw_dashboard_notifier.py",{"path":139,"resourceType":118,"resourceTypeDesc":119,"sizeBytes":140,"sourceHtmlUrl":141},"scripts\u002Falert-notify\u002Frequirements.txt",103,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fscripts\u002Falert-notify\u002Frequirements.txt",{"path":143,"resourceType":118,"resourceTypeDesc":119,"sizeBytes":144,"sourceHtmlUrl":145},"scripts\u002Falert-notify\u002Fserver.py",15838,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fscripts\u002Falert-notify\u002Fserver.py",{"path":147,"resourceType":118,"resourceTypeDesc":119,"sizeBytes":148,"sourceHtmlUrl":149},"scripts\u002Falert-notify\u002Fslack_notifier.py",8348,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fscripts\u002Falert-notify\u002Fslack_notifier.py",{"path":151,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":152,"sourceHtmlUrl":153},"skill-card.md",4091,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fskill-card.md",{"path":155,"resourceType":156,"resourceTypeDesc":157,"sizeBytes":158,"sourceHtmlUrl":159},"skill.oms.sig","OTHER","其他",8349,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvss-manage-alerts\u002Fskill.oms.sig",[161,191,216,240,262,277],{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":165,"sourceHtmlUrl":166,"categories":167,"keywords":174,"publishedAt":47},"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",[168,171],{"categoryNo":169,"categoryName":170,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":172,"categoryName":173,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[175,176,177,32,178,179,180,181,182,183,184,185,186,187,188,189,190],"webapp","testing","webapp testing","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":195,"sourceHtmlUrl":196,"categories":197,"keywords":199,"publishedAt":47},"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",[198],{"categoryNo":172,"categoryName":173,"taxonomyType":21,"taxonomyTypeDesc":22},[200,201,202,187,203,204,205,32,206,207,180,208,30,209,210,211,212,213,214,215],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","file","components","react","multi","state","routing","state management",{"skillNo":217,"name":218,"nameZh":6,"description":219,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":220,"licenseFileUrl":221,"sourceHtmlUrl":222,"categories":223,"keywords":225,"publishedAt":47},"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",[224],{"categoryNo":172,"categoryName":173,"taxonomyType":21,"taxonomyTypeDesc":22},[226,227,228,229,230,231,232,233,234,235,236,237,238,239],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":241,"name":242,"nameZh":6,"description":243,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":220,"licenseFileUrl":244,"sourceHtmlUrl":245,"categories":246,"keywords":249,"publishedAt":47},"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",[247,248],{"categoryNo":169,"categoryName":170,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":172,"categoryName":173,"taxonomyType":21,"taxonomyTypeDesc":22},[250,176,251,237,252,186,253,254,255,232,256,32,257,258,259,30,260,238,261],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":263,"name":264,"nameZh":6,"description":265,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":220,"licenseFileUrl":266,"sourceHtmlUrl":267,"categories":268,"keywords":270,"publishedAt":47},"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",[269],{"categoryNo":172,"categoryName":173,"taxonomyType":21,"taxonomyTypeDesc":22},[271,237,272,252,273,255,274,232,260,275,276],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":278,"name":279,"nameZh":6,"description":280,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":220,"licenseFileUrl":281,"sourceHtmlUrl":282,"categories":283,"keywords":285,"publishedAt":47},"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",[284],{"categoryNo":172,"categoryName":173,"taxonomyType":21,"taxonomyTypeDesc":22},[286,237,252,287,229,288,289,290,271,291,292,293,294,295,296,32,297,30,298,299],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]