setup-arena

name	setup-arena
description	Sets up and verifies a runnable Isaac Lab-Arena checkout using the supported native uv or Docker route. Use when installing Arena, preparing a fresh checkout to run examples or evaluations, choosing between uv and Docker, starting or attaching to the Arena container, mounting datasets/models/evaluation outputs, enabling cuRobo, or checking whether an installation is ready. Do not use for contributor hooks, forced image rebuilds, pytest regression testing, or experiment configuration.
allowed-tools	Read Grep Glob Skill Bash(git rev-parse *) Bash(git submodule *) Bash(head *) Bash(id -un) Bash(test -d *) Bash(test -x *) Bash(uv --version) Bash(uv sync *) Bash(nvidia-smi *) Bash(.venv/bin/python *) Bash(./docker/run_docker.sh *) Bash(docker exec *) Bash(docker images *) Bash(docker inspect *) Bash(docker ps *) Bash(docker stop isaaclab_arena-*)

Setup Arena

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

1. Confirm that the command is running from the repository root.
2. Inspect the existing .venv, submodule state, Docker image/container state, GPU visibility, and requested host mount paths with read-only commands.
3. Reuse a healthy existing runtime. Do not reinstall or rebuild it without a reason.
4. 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.

References

• Evaluation scenarios
• Installation workflow