skills/air-gapped/docker/docker-pixi-project-offline/SKILL.md
Scripted process to build and verify a Pixi-managed project in Docker, then produce a portable WORKDIR/product directory for air-gapped use.
npx skillsauth add igamenovoer/magic-context docker-pixi-project-offlineInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Prepare an existing Pixi-managed project for an air-gapped environment by:
This skill includes helper scripts under scripts/. Prefer using them (each supports --help) rather than retyping the manual steps.
PROJECT_DIR: path to the Pixi project on the host (pixi.toml or pyproject.toml), orPROJECT_PATH_IN_CONTAINER: path to the Pixi project already present inside a containerVERIFY_SPEC: one of:
python -m yourpkg --help)smoke)./scripts/smoke.sh) plus what counts as successIMAGE: a Docker image that contains Pixi (recommended), orCONTAINER_ID: an already-running container to useRESOURCES_DIR: any extra runtime resources to bundle alongside the project (models, data files, binaries)CONTAINER_WORKDIR_PATH: where the scripts stage files inside the container (use this if /workdir already exists or is reserved in the image/container)WORKDIR (host output dir): where the scripts write the generated workdir on the host (default: <workspace>/tmp/workdir-<ts>)pixi.lock exists and is up to date.WORKDIR/: a self-contained workspace holding the staged project, resources, Pixi cache, and logs/test outputs.WORKDIR/product/: the deliverable directory (you pack and ship this folder; archiving is out of scope for this skill).Use a single work directory so “inputs + outputs” are easy to copy/inspect:
WORKDIR/project/<project_name>/: staged project copy (input to product generation)WORKDIR/resources/: optional resources to include (input to product generation)WORKDIR/pixi-cache/: Pixi cache produced during the online build (input to product generation)WORKDIR/out/: logs and test outputs onlyWORKDIR/helpers/: helper scripts used during preparation (not shipped to air-gapped)
WORKDIR/helpers/make-archive-ready-product.sh: creates/overwrites WORKDIR/product/WORKDIR/product/: generated deliverable (created/overwritten by WORKDIR/helpers/make-archive-ready-product.sh)WORKDIR/product/ must be self-contained and include:
WORKDIR/product/<project_name>/: project directory containing Pixi manifest (pixi.toml or pyproject.toml) and the minimal files needed to runWORKDIR/product/res/ (optional): binary data/resources required at runtimeWORKDIR/product/pkg-cache/: Pixi package cache containing everything needed to install without internetWORKDIR/product/envs.sh: manual environment setup (users can source envs.sh before running Pixi commands)WORKDIR/product/bootstrap-project.sh: bootstraps the project (sources envs.sh then runs pixi install for <project_name>/ using pkg-cache/)All scripts are in this skill directory:
scripts/create-workdir-from-host.shscripts/create-workdir-from-container.shscripts/make-archive-ready-product.shscripts/final-verify-product.shEach script is intended to be manually invokable and provides --help.
The create-workdir-* scripts also copy scripts/make-archive-ready-product.sh into WORKDIR/helpers/ for portability.
Acceptable forms:
smoke (run as pixi run smoke)./scripts/smoke.sh (define success: exit code 0, expected output, created files, etc.)python -c "import yourpkg; print('ok')"When executing, capture output into WORKDIR/out/ so the workdir contains the proof.
WORKDIR/Use exactly one of the following paths:
This stages a filtered copy of the project into WORKDIR/project/<project_name>/, runs pixi install, and runs verification (optional):
./scripts/create-workdir-from-host.sh --help
./scripts/create-workdir-from-host.sh \
--image your-pixi-image:tag \
--project-dir /path/to/project \
--resources-dir /path/to/resources \
--container-workdir-path /tmp/workdir \
--verify-run -- python -c 'import yourpkg; print("ok")'
If the project directory already exists in a running container, create /workdir in that container and copy it back to the host:
./scripts/create-workdir-from-container.sh --help
./scripts/create-workdir-from-container.sh \
--container-id <CONTAINER_ID> \
--project-path-in-container /path/to/project \
--container-workdir-path /tmp/workdir \
--verify-task smoke
WORKDIR/product/./tmp/pixi-offline-work/helpers/make-archive-ready-product.sh --help
./tmp/pixi-offline-work/helpers/make-archive-ready-product.sh \
--workdir ./tmp/pixi-offline-work --project-name <project_name>
Verify the product (not the staged project) in an offline/no-network container. This is the final verification step.
./scripts/final-verify-product.sh --help
./scripts/final-verify-product.sh \
--image your-pixi-image:tag \
--product-dir ./tmp/pixi-offline-work/product \
--out-dir ./tmp/pixi-offline-work/out \
--project-name <project_name> \
--verify-run -- python -c 'import yourpkg; print("ok")'
If this passes with networking disabled, it demonstrates that pixi install is satisfied by product/pkg-cache/.
After WORKDIR/product/ is created and verified, the remaining steps (packing, transferring, extracting, and running in the air-gapped environment) are the user’s responsibility.
./bootstrap-project.sh and then pixi run ... with --network none..env, credentials, SSH keys, or tokens.When you want this to be push-button, add a small orchestrator that:
scripts/ in a single commanddata-ai
Create readable Mermaid diagrams inside Markdown files. Use for flowcharts and sequence diagrams that must render cleanly in common Markdown renderers (e.g., GitHub) without horizontal scrolling. Covers fenced mermaid blocks, init/theme styling, label wrapping with <br/>, and sequenceDiagram layout rules (short IDs, wrapped labels, don’t break identifiers).
development
Manual invocation only; use only when the user explicitly requests `make-program-tutorial` by exact name, OR when the user asks to use a skill to create an SDK/API/library tutorial. Create a clear, reproducible, step-by-step tutorial for a specific API/SDK/library (or a set of functions/classes), with runnable examples, expected outputs, and basic troubleshooting.
testing
Use when the user wants to create a self-hosted, offline-installable Conda channel (mirror) containing a specific subset of packages using Pixi.
tools
Guides the agent to setup a new or existing Pixi environment for compiling C++ and CUDA code. It ensures the correct compilers, toolkits, and CMake configurations are in place for a robust user-space build.