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.
How do you install this skill?
- 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.
- Shell / CLI
- Network access
- Local filesystem
GitSSHDockersudoping
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.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/hsb-setup" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
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.
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 does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Holoscan Sensor Bridge Demo Bring-Up this page ✓ NVIDIA · Official | 38 · Blocked | ★ 3.6k | 13d ago | Apache-2.0 |
| HSB FPGA Flash Assistant ✓ NVIDIA · Official | 43 · Not recommended | ★ 3.6k | 13d ago | Apache-2.0 |
| TAO on SLURM ✓ NVIDIA · Official | 55 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| Home Assistant Manager Skill | 52 · Use with care | ★ 971 | 3mo ago | MIT |
| TAO NVIDIA GPU Host Setup ✓ NVIDIA · Official | 55 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
How did FollowSkills review this skill?
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.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →