What does this skill do, and when should you use it?
HSB QA Test Runner is designed for quality assurance on Holoscan Sensor Bridge hardware. It reads a user-supplied test plan and filters cases according to the platform, board, and sensor setup. Executable tests run inside the demo container with pass/fail evaluation against the plan. The workflow produces a structured report and cleans up containers, temporary artifacts, and session state.
Reads a test plan from a local file or web link; uses SSH to check the remote devkit, board, sensors, and demo container; reads FPGA version and board identity; builds an executable test list using the hardware setup and the repository's examples directory; runs tests sequentially inside the demo container with pass/fail evaluation; analyzes failure logs and suggests fixes; generates an optionally saved structured results report; and removes test containers, temporary files, and session state.
- An HSB developer needs to run a complete QA plan on a devkit whose SSH, container, board, and sensors are already configured.
- A hardware engineer needs tests filtered for a particular platform, board type, and sensor configuration.
- A test engineer needs per-case pass/fail results with failure analysis and recommended remediation.
- A team wants to reuse verified connectivity and hardware session state when rerunning tests in the same session.
How do you install this skill?
- Execution uses --privileged, --net host, /dev mounts, and sudo; users should confirm host, device, and privilege scope before running.
- Phase 4 automatically stops/removes test containers and deletes temporary session state; preserve diagnostic material and back up reports externally when needed.
- The test plan and remote URL content influence executed commands; review their provenance before allowing unverified or untrusted input into shell execution.
- The documentation claims global deployment but provides no evidence of mainland-China reachability or a Chinese-language operating path.
- Shell / CLI
- Network access
- Local filesystem
SSHDockerHoloscan Sensor Bridge devkitdemo container
Install the skill from the NVIDIA/skills repository with the skills CLI:
npx skills add nvidia/skills --skill hsb-test --agent codex --yes
The README does not document a specific installation directory for other clients, although it supports installation for clients such as Claude Code.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/hsb-test" ~/.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?
Use it only when explicitly invoked by the user. On the first run, provide SSH_TARGET and REMOTE_ROOT, supply a test-document path or URL, and confirm whether to start Phase 0. The workflow proceeds through Phase 0 verification, Phase 1 test-plan intake and approval, Phase 2 execution, Phase 3 reporting, and Phase 4 cleanup. It documents /hsb-test plus --full, --verbose, --timeout N, and --y options; support for these extensions depends on the client.
What are this skill's strengths and limitations?
- Covers the workflow from hardware verification through reporting and cleanup.
- Filters tests for the user's hardware setup and skips manual or extra-equipment cases.
- Records per-test pass/fail outcomes and lets the user decide whether to continue after failures.
- Can reuse verified session state to skip repeated connectivity checks within the same session.
- Requires a prepared Holoscan Sensor Bridge devkit, SSH access, a demo container, and connected hardware.
- Depends on remote SSH, Docker containers, and physical HSB hardware, so it is not a pure software testing workflow.
- The test document, supported platform combinations, and automation coverage must be supplied or confirmed; SKILL.md does not list fixed test cases.
- Uses Claude Code-style slash commands, arguments, and session-path conventions that may require adaptation elsewhere.
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 |
|---|---|---|---|---|
| HSB QA Test Runner this page ✓ NVIDIA · Official | 46 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| Holoscan Sensor Bridge App Runner ✓ NVIDIA · Official | 45 · Not recommended | ★ 3.6k | 13d ago | Apache-2.0 |
| SkillHub Development Workflow | 59 · Recommended | ★ 5.2k | 14d ago | Apache-2.0 |
| Playwright Development Guide ✓ Microsoft · Official | 45 · Not recommended | ★ 98k | 13d ago | Apache-2.0 |
| Optional-Dependency Smoke Tests (agent-service-toolkit) | 64 · Recommended | ★ 4.5k | 23d ago | MIT |
How did FollowSkills review this skill?
The skill requires explicit confirmation, limits use to explicit invocation, and discloses the SSH target, remote directory, test plan, and phases. However, it uses SSH, sudo, privileged Docker, host networking, /dev mounts, xhost, and automatic cleanup; sensitive-data handling and rollback boundaries are incomplete, so points are deducted.
The workflow documents phase gates, timeouts, failure summaries, retries, and connectivity re-verification. However, it depends on remote hardware, containers, WebFetch, and other skills; some command and variable handling is fragile; and no skill-level executable test suite is provided. The static cap is 10, so points are deducted.
The audience, hardware configurations, automated/manual classification, timeouts, and interaction rules are fairly clear. However, the skill is limited to specifically deployed HSB hardware, lacks explicit non-fit boundaries and Chinese-language guidance, and does not assess reachability of remote dependencies, so points are deducted.
The files provide a name, version, author, Apache-2.0 license, tags, phase documentation, help, examples, references, and a benchmark report. However, the recommended Instructions/Examples/Purpose structure is absent, and installation dependencies, maintenance ownership, changelog, and troubleshooting coverage are incomplete, so points are deducted.
The core goal is clear: filter, execute, evaluate, and report tests from a supplied plan. However, usefulness depends on a user-supplied plan, live hardware, and a remote container, while coverage and direct usability are supported only by limited internal evaluation claims. The static cap is 7, so points are deducted.
The source includes detailed commands, pass/fail criteria, evaluation tasks, and limited benchmark results, providing some auditability. However, there is no independent CI, committed key-path test suite, or multi-source corroboration, and the benchmark covers only two positive tasks, so points are deducted.
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 →