Holoscan Sensor Bridge Demo Bring-Up
Build and verify a Holoscan Sensor Bridge demo environment on NVIDIA devkits.
The skill requires explicit invocation, phase confirmations, environment disclosure, and some failure recovery, while acknowledging side effects. However, it instructs the agent to add all human users to the docker group, copy NGC credentials to all users, broadly configure X11 access, and potentially fall back to xhost +. These permissions are disproportionate to a single-user setup, with inadequate credential-flow controls and rollback. Most trust points are therefore deducted, and the unresolved excessive-permission risk triggers a block.
The phase structure, platform mapping, recovery playbook, reboot handling, and container cleanup guidance are substantial. However, the workflow depends on unavailable user-guide content, the latest external main branch, a Claude account-usage mechanism, and an undefined run_script interface; static review cannot reproduce key paths. The static ceiling applies, and abnormal-path control is not fully demonstrated.
The audience, supported platforms, invocation pattern, platform questions, and some non-fit boundaries are reasonably clear. Chinese-language support is not specified, and core operation depends on GitHub, NGC, Docker, SSH, and potentially overseas network access without a mainland-China reachability strategy.
The skill includes name, description, author, version, tags, license, phased organization, help text, failure guidance, and helper scripts. It lacks a clear changelog, maintenance ownership/update path, and complete referenced materials. BENCHMARK also reports a missing recommended Examples section, while repository license metadata is NOASSERTION.
The workflow covers cloning, host configuration, building, container launch, connectivity checks, and FPGA-version checks, so it plausibly addresses the core bring-up task. However, it relies on hardware, remote privileges, external repositories, and container images; no representative output is statically verified, and the high cost and broad permissions weaken proportionality.
The pinned source set contains scripts, platform mappings, failure cases, and one static benchmark report. However, the benchmark has only one task and there is no committed test suite, real CI coverage, or independent corroboration sufficient to verify the key execution paths statically.
- The skill has an unresolved privilege-escalation risk: adding all human users to the docker group and copying NGC credentials may broaden host and private-image access.
- xhost + and broad X11 authorization weaken session isolation and should not be default remediation.
- The workflow requires Claude Code account-usage checks, which may be unavailable in Codex; it correctly requires stopping when the budget cannot be verified, but does not provide a compatible mechanism.
- Cloning the latest main branch without pinned dependency commits or image versions reduces reproducibility.
- Core operation depends on GitHub, NGC, Docker, SSH, and hardware, with no mainland-China connectivity fallback.
What does this skill do, and when should you use it?
This skill provides an end-to-end bring-up workflow for the Holoscan Sensor Bridge demo environment. It covers remote devkit access, platform detection, repository refresh, host configuration, container build and launch, and first connectivity checks. Supported mappings include IGX Orin, AGX Orin, AGX Thor, and DGX Spark, with iGPU or dGPU build modes selected by platform. The workflow uses SSH and shell commands, verifies connectivity by pinging 192.168.0.2, and checks the FPGA version register. The skill is version 1.0.0, authored by the Holoscan Team, and licensed Apache-2.0.
Reads SSH_TARGET, REMOTE_ROOT, REMOTE_SUDO, REMOTE_SSH_OPTS, HSB_PLATFORM, and HSB_REPO; performs a mandatory token-budget preflight and presents a phased plan; detects the devkit using /sys/class/dmi/id/product_name and reconciles HSB_PLATFORM; clones or refreshes the latest main branch from the default or custom repository; studies docs/user_guide for host, container, application, and FPGA procedures; runs the platform-specific docker/build.sh --igpu or --dgpu build; launches the demo container; pings 192.168.0.2 and verifies FPGA version register 0x80; records issues, proposes safe fixes, and optionally exports a Markdown report; then stops applications and exits the container.
- An engineer using an external computer to bring up a Holoscan Sensor Bridge demo over SSH on an NVIDIA devkit.
- An IGX Orin developer who must select the correct iGPU or dGPU container build mode.
- A developer validating sensor-bridge network connectivity on AGX Orin, AGX Thor, or DGX Spark.
- A test or integration engineer checking whether the sensor FPGA version matches the HSB host software on the devkit.
What are this skill's strengths and limitations?
- Covers the full path from hardware detection through container launch and connectivity verification.
- Provides platform mappings for multiple NVIDIA devkits, including IGX Orin iGPU/dGPU modes.
- Includes phase gates, concise failure summaries, issue reporting, and optional Markdown export.
- Requires explicit invocation, reducing the risk of unintentional devkit changes.
- Requires remote target and working-directory settings and depends on SSH, sudo, Docker, Git, and network access.
- Performs host configuration, container builds, and other side-effecting operations.
- Stops before Phase 1 when token usage is insufficient or cannot be verified.
- The supplied material provides no automated test results or evidence of actual validation on every supported platform.
How do you install this skill?
Install the skill from the NVIDIA/skills collection with: npx skills add nvidia/skills --skill hsb-setup --agent codex. Alternatively, place the skills/hsb-setup/ directory in a compatible Agent Skills directory. The README does not specify a universal client-specific destination path.
How do you use this skill?
Explicitly invoke /hsb-setup [PLATFORM] [OPTIONS], for example /hsb-setup AGX Thor. SSH_TARGET and REMOTE_ROOT must be available before starting; the workflow asks for hardware, power, network, and privilege confirmation and performs the token-budget preflight. Supported options include --verbose, --repo <URL>, and --y; --y cannot bypass the preflight. Because the workflow has side effects, it must not run automatically.