Vss Search Archive logo

Vss Search Archive

OrganizationPopular
NVIDIA-AI-Blueprints
vss-search-archive

Use this skill when a user wants to search archived VSS video or ingest or delete a source for search. Do not use it for visual Q&A, live captioning, or video summarization.

Overview

PublisherNVIDIA-AI-Blueprints
Repositoryvideo-search-and-summarization
Skill namevss-search-archive
Stars
1.9K
Forks
393
Bundled files
7
LicenseApache-2.0
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 7 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by NVIDIA-AI-Blueprints on GitHub. Read the source before you install it.

Installation

Install the Vss Search Archive AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/NVIDIA-AI-Blueprints/video-search-and-summarization.git /tmp/video-search-and-summarization
mkdir -p .claude/skills
cp -r /tmp/video-search-and-summarization/skills/operations/vss-search-archive .claude/skills/vss-search-archive
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Vss Search Archive in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Vss Search Archive on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Vss Search Archive is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Purpose

Operate archive search from the caller's host. Compose and Kubernetes use the same vss configure and vss search run commands; only the deployment origin differs. Source ingestion and deletion are Agent-backed when the deployment has an agent /api route; on a build without one, they belong to vss-manage-video-io-storage references/provision-vios-source.md.

Hard boundaries

  • Run the project-local CLI on the host. Never use docker exec, kubectl exec, a pod shell, or a globally installed vss as a substitute.
  • Never improvise a mutation against Elasticsearch, RTVI-CV, RTVI-Embed, storage-ms, or VST. Two paths are sanctioned, and the deployment picks which: the Agent upload/delete lifecycle where an agent /api route answers, and vss-manage-video-io-storage references/provision-vios-source.md where none does. That recipe owns the direct calls this rule otherwise forbids.
  • Never remove, broaden, or silently substitute a requested source constraint.
  • Similarity is retrieval evidence, not proof of visual presence.
  • The CLI attempts critic verification by default. Do not separately inspect screenshots or call another verifier during the initial search turn.
  • Offer delegated verification only when every displayed result is unverified, and only after displaying them and receiving explicit user confirmation. If any result is confirmed or rejected, do not hand off any result to another verifier.

Prerequisites

  • A running VSS search profile and its host-reachable Compose or Ingress origin.
  • A checkout containing libs/vss, host uv, curl, and jq.
  • vss vios list for source listing and inspection (same CLI, same recorded origin).

Resolve and validate the checkout once:

bash
VSS_REPO_ROOT="${VSS_REPO_ROOT:-$HOME/video-search-and-summarization}"
test -f "${VSS_REPO_ROOT}/libs/vss/pyproject.toml" || {
  echo "VSS checkout not found at ${VSS_REPO_ROOT}; set VSS_REPO_ROOT explicitly" >&2
  exit 1
}
VSS=(uv run --project "${VSS_REPO_ROOT}/libs/vss" vss)
cd "${VSS_REPO_ROOT}" && "${VSS[@]}" search run --help >/dev/null || exit 1

libs/vss is the library's own workspace, so no extras and no --no-dev are needed — the agent stack is not in it.

Resolve the deployment through its one public/host origin:

bash
if [ -z "${VSS_ORIGIN:-}" ]; then
  VSS_ORIGIN=$("${VSS[@]}" configure show 2>/dev/null |
    jq -er '.base_url | select(type == "string" and length > 0)') || {
      echo "Provide the Compose or Ingress origin" >&2
      exit 1
    }
fi
VSS_ORIGIN="${VSS_ORIGIN%/}"
VST_URL="${VSS_ORIGIN}"
VSS_VIOS_URL="${VSS_ORIGIN}/vst"
"${VSS[@]}" configure --base-url "${VSS_ORIGIN}" || exit 1

In a persisted multi-step workflow, reuse the origin recorded by the prepared deployment as above. Do not repeat public-origin selection, edit routing, or redeploy merely because the next agent turn did not inherit shell variables.

See deployment resolution for the deployment-owned VSS_PUBLIC_URL contract. On Kubernetes, never use port-forwarding, Service DNS, NodePorts, or a guessed Helm release. Routes not exposed through the Ingress are recorded as absent and a search path needing one exits 4.

For deployment readiness, ingestion, fixture cleanup, index checks, RTSP, or deletion, read source lifecycle completely before acting. Re-run vss configure after the first ingestion: the recorded raw family is what enables frame-level lookups (it gates frames_index, which attribute and fusion need for frame enrichment). Only source-type selection is independent of the index inventory.

Mandatory search workflow

  1. Confirm the selected deployment is the search profile. If required routes are unavailable, ask whether to reconnect or deploy it with the /vss-build-vision-ai stock Search workflow; do not target another profile.

  2. When the user names a file, camera, or sensor, list registered sources with "${VSS[@]}" vios list before invoking the search CLI — it reads the origin vss configure recorded, so it takes no endpoint. Accept only an exact source, stream ID, or one unambiguous normalized substring match.

    • No match: report the missing source, list available names, and ask the user to clarify or explicitly request ingestion. Stop without probing the search CLI, deploying, or ingesting. Never continue with a different source. Answering about warehouse_sample when the request named warehouse-ladder returns a confident answer about the wrong video, and nothing downstream can tell it was substituted.
    • Several matches: ask the user to choose and stop.
    • Never substitute another video or run an unrestricted search as a probe.

    Preserve both the matched source's .sensorId and .name. The --video-source value depends on the search path, not the source type (optional for every path): embed matches the sensor ID literally; attribute and object match the name literally; only tag resolves a source name to its VST sensor ID (passing an already-id through). fusion does not resolve — its embedding leg filters by sensor ID literally — so hand fusion the preserved sensor ID (the tag leg accepts IDs too). For every path an unknown source yields an empty, narrowed result, not an error. Set --source-type video_file for uploads or --source-type rtsp for live streams. This selects the index partition for that media kind from a fixed uploads anchor (not a discovered index), independently of the identifier, so it is correct regardless of ingestion order.

  3. Decompose the request before choosing a path; do not pick by surface form. run embed accepts any sentence, so being one sentence is not evidence for embed. Separate each specific detectable property (white jacket, red hard hat) from the actions/relations only embeddings capture, then choose:

    • a detectable property plus an action or relation is present → run fusion (even within one sentence)
    • free-text intent with no detectable property → run embed
    • detectable properties only, no action or relation → run attribute
    • explicit tracked object IDs → run object
    • explicit keyword or tag intent — lexical (BM25) match against indexed VLM tags, with no detectable property and no semantic free-text → run tag

    --attribute is for specific detectable properties, not generic nouns or actions. A property counts only when RT-CV detects it on the subject (attire, PPE, color-on-person), not object identity or an object's own color; keep red forklift wholly in --query. worker in a hard hat carrying a cone has a property (hard hat) and an action (carrying a cone): run fusion --query "worker in a hard hat carrying a cone" --attribute "hard hat". Reserve embed for genuinely attribute-free intent. run tag is for explicit lexical intent — matching indexed VLM tag keywords by BM25 — not semantic similarity; reserve it for keyword/tag queries that name no detectable property.

  4. Construct the invocation as a Bash array and validate only its exact stdout. Read CLI usage for every supported flag.

bash
: "${SEARCH_PATH:?set embed|attribute|fusion|object|tag}"
: "${SOURCE_TYPE:?set video_file or rtsp}"
TOP_K="${TOP_K:-3}"
VIDEO_SOURCES=() # sensor IDs for embed/fusion; names for attribute/object/tag
: "${SOURCE_SCOPED:?set true for a resolved scope; false only when unrestricted}"
if [ "${SOURCE_SCOPED}" = true ] && [ "${#VIDEO_SOURCES[@]}" -eq 0 ]; then
  echo "Resolved source scope is empty; refusing an unrestricted search" >&2
  exit 1
fi
SEARCH_COMMAND=(
  "${VSS[@]}" search run "${SEARCH_PATH}"
  --source-type "${SOURCE_TYPE}" --top-k "${TOP_K}" --raw
)
for source in "${VIDEO_SOURCES[@]}"; do
  SEARCH_COMMAND+=(--video-source "${source}")
done
# Append --query, repeatable --attribute, --object-id, and time bounds as needed.
if ! SEARCH_JSON=$("${SEARCH_COMMAND[@]}"); then
  echo "Search command failed" >&2
  exit 1
fi
printf '%s' "${SEARCH_JSON}" |
  jq -e 'type == "object" and (.data | type == "array")' >/dev/null || {
    echo "Search did not return a SearchOutput object with a data array" >&2
    exit 1
  }

Do not pass endpoint, index, model, deployment, profile, or base-URL flags to search run; vss configure owns those values. Do not replace a failed CLI call with /api/v1/search or private backend access.

  1. Validate each nonempty hit's exact returned screenshot_url with a bounded GET for availability only. Its normalized scheme, host, and effective port always match the origin recorded by vss configure, because the CLI stamps that origin into every hit — a localhost media URL means the deployment was configured against a localhost origin, not that the URL is malformed. On Brev, prefer the public HTTPS secure-link origin. If setup used the documented host-reachable fallback after its one bounded public probe failed, accept only that exact recorded origin and label its media URLs host-local; do not restart routing diagnosis. Reject credentials in the URL and never rewrite the URL or add a streamId routing header. Discard the response body; availability is not visual evidence.

  2. Read every hit's verification object:

    • confirmed: the critic found all requested visual criteria in that clip.
    • rejected: the critic found a visual criterion was not met.
    • unverified: no usable critic verdict was produced. This includes a missing VLM, inaccessible media, and malformed or inconclusive output.

The CLI is fail-open: verification failure must not discard or fail retrieval. Never derive a verdict from similarity, filenames, object IDs, or screenshot availability. Treat boolean criteria_met values as critic evidence only.

  1. Format nonempty results without raw JSON:
text
## Video Search Results
<each hit's exact source, start/end, similarity, complete media URL,
verification result, and criteria when present>

Similarity scores are retrieval evidence; the separate verification result
records whether the bounded clip satisfied the visual request.

## Verification Step
Would you like me to verify the unverified search results?

Include ## Verification Step only when the nonempty displayed result set is entirely unverified. If any displayed result is confirmed or rejected, omit it even when other hits are unverified. Never deploy a VLM or call vss-ask-video automatically during this results turn.

  1. If the user explicitly confirms, read search-result verification completely and delegate the displayed hits only after confirming again that every one is still unverified. Preserve their exact bounded intervals and the complete original visual intent. Keep at most three delegations in flight. Never hand off a partially verified result set.

  2. If .data is empty, report zero candidates faithfully — a fact about retrieval, not about the video. Do not claim the object is absent, describe what the footage contains, or argue it is not something you would expect there: a threshold or embedding gap yields the same empty result as a genuine absence. Offer a specific query or similarity-threshold refinement while preserving the source. Never broaden the search silently.

Natural-language Agent responses

Use the host CLI for deterministic structured search. If a caller explicitly requires the deployment Agent to decompose a natural-language request, its /api/v1/search response is conversational text, not SearchOutput. Validate the known text field and present it as prose; never run .data[], screenshot, or verification parsing against that response or invent structured hit rows.

Troubleshooting

  • CLI unavailable: verify VSS_REPO_ROOT points at the checkout, and stop.
  • Exit 2: read the selected path's --help; do not guess flags.
  • Exit 3: a recorded backend is unreachable; repair routing and reconfigure.
  • Exit 4: run vss configure --base-url <origin> or choose a path whose required services are actually routed.
  • Exit 5: ingest the source, wait for readiness, and re-run vss configure.
  • Missing/ambiguous source: stop for clarification; never substitute.
  • Missing RT-VLM: retrieval remains valid and results remain unverified.
  • Authentication: use the operator-approved route. Never place secrets in prompts, flags, generated files, logs, or skill output.

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Vss Search Archive AI skill do?

Use this skill when a user wants to search archived VSS video or ingest or delete a source for search. Do not use it for visual Q&A, live captioning, or video summarization.

Why use Vss Search Archive on TypingMind?

Because you install it once and use it with any model. Vss Search Archive is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Vss Search Archive in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/NVIDIA-AI-Blueprints/video-search-and-summarization/tree/develop/skills/operations/vss-search-archive. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Vss Search Archive?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Vss Search Archive?

As many as you like. As long as a model supports skills, you can use Vss Search Archive with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Vss Search Archive AI skill free?

Yes. It is published on GitHub by NVIDIA-AI-Blueprints under the Apache-2.0 license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇