Prepare the product runtime only, then stop at readiness evidence. Do not select policies, datasets, experiment configurations, or output directories. Do not install contributor hooks, run the full pytest suite, or interpret experiment artifacts.
Use the checked-out documentation
Before changing state, read docs/pages/quickstart/installation.rst from the current checkout. Its
support table, prerequisites, and commands are the source of truth. If this skill differs from the
documentation, follow the documentation and report the mismatch.
Honor an installation method the user already requested. Otherwise, choose the least restrictive supported route:
| Route | Use it when |
|---|---|
| Native uv | Default when uv is available; supports evaluation, imitation learning, reinforcement learning, and agentic environment generation. |
| Docker | Use when requested, when the existing workflow is container-based, or when cuRobo reachability validation is required. |
Do not silently switch routes. Native uv does not provide the optional cuRobo package; use Docker
with -c for ik_reachable validation.
Preflight and confirmation
- Confirm that the command is running from the repository root.
- Inspect the existing
.venv, submodule state, Docker image/container state, GPU visibility, and requested host mount paths with read-only commands. - Reuse a healthy existing runtime. Do not reinstall or rebuild it without a reason.
- Show the chosen route, exact documented commands, expected downloads/build, and any required EULA or host-directory changes. Ask once before starting a large sync or image build.
Run the documentation read and safe read-only preflight immediately; do not ask for confirmation or defer them as a proposed plan. Confirmation is only for the state-changing sync, build, or stop that follows the preflight.
If a prerequisite is missing, report the failed check and the documented recovery. Do not install or change GPU drivers, Docker, the NVIDIA Container Toolkit, or other system packages without explicit approval.
Native uv route
Initialize the source submodules and sync the environment:
git submodule update --init --recursive
uv sync --extra dev
Use .venv/bin/python for non-interactive commands.
Accept the Isaac Sim EULA for launch commands:
OMNI_KIT_ACCEPT_EULA=YES ACCEPT_EULA=Y \
.venv/bin/python -c "import isaaclab_arena; print(isaaclab_arena.__file__)"
Require the import to resolve from the current checkout. Then run the short zero-action validation
command documented in docs/pages/quickstart/installation.rst, unless the user asks to skip a
simulation launch.
Docker route
Initialize source submodules, then launch from the repository root:
git submodule update --init --recursive
./docker/run_docker.sh
Use these options only when the request needs them:
| Flag | Purpose |
|---|---|
-d <path> |
Mount datasets at /datasets. |
-m <path> |
Mount models at /models. |
-e <path> |
Mount evaluation outputs at /eval. |
-c |
Build/use the cuRobo image for reachability validation. |
-s <suffix> |
Override the automatic per-checkout container suffix. |
Confirm that each explicitly requested mount path exists before launching. Mount flags apply only when creating a container; they do not change an already-running container. If the requested configuration differs, explain that recreation is required and obtain approval before stopping the checkout-specific Arena container. Before asking for approval, inspect its exact name, image, and mounts and show the complete reconstructed launcher command. Populate this shape from the inspected configuration instead of relying on launcher defaults:
./docker/run_docker.sh [-c] [-s <current-suffix>] -d <new-datasets> \
[-m <current-models>] [-e <current-evaluation>]
Include -c for an existing cuRobo image, -s for an existing suffix, and each current model or
evaluation mount. Replace only the mount the user asked to change, and stop the container only after
the user approves that exact command.
The launcher builds a missing image, starts this checkout's container, and attaches interactively.
Keep that process alive in a terminal session. Do not force a rebuild here; use dev-container for
an explicit contributor rebuild or image-debugging request.
List the containers for this checkout without hardcoding a name:
docker ps --filter "volume=$(git rev-parse --show-toplevel)" --format '{{.Names}}\t{{.Image}}'
Select the exact name matching the chosen image flavor and suffix and assign it to
ARENA_CONTAINER. Do not take an arbitrary first match because regular and cuRobo containers can
coexist for one checkout.
Verify the editable source mount as the host user:
docker exec "$ARENA_CONTAINER" su $(id -un) -c \
"cd /workspaces/isaaclab_arena && \
/isaac-sim/python.sh -c 'import isaaclab_arena; print(isaaclab_arena.__file__)'"
Require a path under /workspaces/isaaclab_arena/. Then run the short zero-action validation from
the installation documentation inside the container, unless the user asks to skip it.
Finish
Report the selected route and concrete evidence: interpreter or container, import path, and zero-action exit status when run. Treat setup readiness separately from policy success.
Use dev-container for contributor bootstrap or forced rebuilds and run-tests only when the user
explicitly asks for regression testing. Treat any requested experiment as the next workflow after
setup; do not absorb its policy, configuration, execution, or artifact checks into this skill.