Isaac for Healthcare E2E Workflow
Run the Isaac for Healthcare pipeline from recording through validation.
The skill clearly defines a full pipeline and forbids detached execution, but it instructs agents to clone a remote repository by default without confirmation, then launch simulation, collect/process data, train models, and create external side effects. It does not pin or verify the cloned code, define permission boundaries, address potentially sensitive data, or provide rollback/cleanup procedures; the stop script and generic no-secrets guidance are insufficient for full credit.
The ordered commands, environment variable handling, stages, output locations, resume parameters, and troubleshooting cases are coherent, and the skill requires inspecting the summary or failure log. Static files do not establish dependency availability, key-path reproducibility, or robust abnormal-input handling; environment names remain placeholders, so the score is conservatively limited by static evidence.
Activation conditions, pipeline scope, skip flags, inference-only behavior, and resume scenarios are reasonably clear for explicit i4h end-to-end requests. There is no concrete valid-environment inventory, hardware/resource contract, or sufficiently detailed non-fit boundary. The workflow relies primarily on an English GitHub-hosted dependency and provides no Chinese-language guidance or mainland-China reachability assurance, so points are deducted.
The frontmatter supplies the name, version 0.6.0, description, author, and Apache-2.0 license. The document is layered across purpose, base code, execution, outputs, monitoring, stopping, prerequisites, limitations, and troubleshooting. It lacks dedicated Instructions and Examples sections, a changelog, a clear maintenance/update path, and pinned dependency versions; the supplied repository license metadata is NOASSERTION, so full marks are not justified.
The skill gives a directly actionable record-through-validate path and specifies stage status and artifact reporting. The evaluation files contain two positive routing tasks and report some correctness and effectiveness uplift. However, there are only two positive cases, no negative-trigger cases, and no static proof that real outputs are complete and directly usable or that costs are proportionate; the score stays below the static ceiling.
The committed benchmark includes a versioned evaluation date, tasks, expected behaviors, and result tables, providing limited auditable evidence. It is not a committed CI workflow or test suite covering the skill's key paths, has only two tasks, and lacks independent corroboration. No commands were executed during this review, so evidence coverage remains limited.
- Confirm the environment, hardware, data locations, and long-running cost before execution; the skill defaults to cloning remote code and launching the full pipeline.
- Pin and verify the i4h-workflows revision, and document installation, network requirements, least-privilege permissions, sensitive-data handling, and cleanup/recovery after failure.
- The GitHub dependency may be unreachable from mainland-China networks; provide an accessible mirror or offline path, plus a valid-environment inventory and Chinese guidance.
- The benchmark has only two positive tasks and no negative-trigger cases, so semantic routing, boundary behavior, and end-to-end artifact quality remain insufficiently demonstrated.
What does this skill do, and when should you use it?
i4h-workflow-e2e runs the complete Isaac for Healthcare agentic workflow end to end. It executes recording, mimic, annotation or filtering, replay, conversion, visualization, fine-tuning, and validation in sequence. The skill reuses an existing i4h-workflows checkout or clones one when the required workflow tree is unavailable. After completion, it expects the agent to inspect the final summary and report run details and artifacts.
Resolves a repository containing workflows/agentic/; invokes workflows/agentic/scripts/e2e/run.sh; supports dry runs, selected skipped stages, and resuming from an existing run directory; writes per-stage logs, workflow.log, SUMMARY.txt, data, LeRobot outputs, and checkpoints for trainable environments; exposes the latest run through runs/.latest; and can invoke stop.sh to stop workflow processes when needed.
- An Isaac for Healthcare developer needs a complete end-to-end smoke test for a valid environment.
- A demo operator needs to show the workflow from data recording through model validation.
- A workflow maintainer needs to resume execution from a prior stage and run directory.
- A debugger wants to inspect the planned stages with a dry run before starting the full pipeline.
What are this skill's strengths and limitations?
- Covers the complete pipeline from recording through validation.
- Supports dry runs, stage skipping, and resumption from an existing run.
- Produces explicit logs, a final summary, data, and checkpoints where applicable.
- Documents the special assemble_trocar behavior: fine-tuning and checkpoint validation are skipped.
- Requires a valid --env name.
- Depends on a prepared workflow environment and .venv; it does not replace the dedicated setup skill.
- A full run may be long, and policy record or verify stages open a simulation window by default.
- The source does not provide a list of valid environments, a platform matrix, or performance measurements.
- assemble_trocar is inference-only and does not produce fine-tuning or checkpoint-validation outputs.
How do you install this skill?
Install the skill from the NVIDIA/skills catalog with the skills CLI:
npx skills add nvidia/skills --skill i4h-workflow-e2e --yes
The README does not document a client-specific local installation directory; the client loads the installed skill for relevant tasks.
How do you use this skill?
Ensure that an i4h-workflows checkout and its .venv are available, then provide a valid environment name. Example trigger: “Run an end-to-end smoke test for i4h-workflows with env <env>.” The skill runs:
${REPO_ROOT}/workflows/agentic/scripts/e2e/run.sh --env <env>
Use --dry-run --env <env> first when appropriate. Set ARENA_HEADLESS=1 only when the user explicitly requests headless execution. Inspect runs/.latest/logs/SUMMARY.txt after completion. To stop the workflow when needed, run stop.sh all --env <env>.