Prepare and reset persistent Linux development guests on macOS. Use when comparing container machine, Lima or Colima, and full VMs for distros, init systems, services, custom boot, disks, Rosetta, or nested virtualization.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Prepare and reset persistent Linux development guests on macOS. Use when comparing container machine, Lima or Colima, and full VMs for distros, init systems, services, custom boot, disks, Rosetta, or nested virtualization.
Linux Development VM Workflow
Purpose
Prepare one persistent Linux development environment whose lifecycle, host integrations, provenance, validation, and reset path are explicit.
When To Use
Use for distro-specific builds, services, systemd or another init system, repeated shells, full-system tests, custom kernels, EFI boot, or GUI Linux.
Use to decide between container machine, Lima/Colima, and a full VM by required fidelity rather than product preference.
Do not use for a single portable application image; use the container owner skills.
Discover current official documentation and installed versions/help for every candidate tool.
Select the smallest adequate path:
container machine: OCI-backed persistent Linux, init/services, repeated interactive development
Lima/Colima adapter: tool-managed Linux environment when its documented lifecycle and integration match the task
full Virtualization framework VM: custom boot/kernel/disk/devices, full-system or GUI behavior, or tighter integration control
Record distro/image/kernel provenance, architecture, CPU, memory, disks, network, mounts, sockets, credentials, and expected lifetime.
Keep host home, writeable shares, SSH agent, credentials, clipboard, and unrestricted network opt-in. A development convenience is not a security boundary.
Configure Linux or EFI boot, virtio devices, provisioning, services, Rosetta, and nested virtualization only when the selected path and current host/guest support them.
Define create, provision, start, shell/SSH, stop, update, checkpoint/reset, export, and remove semantics using the selected tool's vocabulary.
Validate the distro matrix: identity, architecture, toolchain, build, tests, services, filesystem semantics, network, reboot persistence, and cleanup.
Inputs
Completed virtualization shape record.
Distro/version, architecture, system services, boot/kernel needs, toolchain, resources, integrations, and reset frequency.
Exact selected tool version and official documentation.
Outputs
Selected Linux guest path and rejected alternatives.
Provenance and resource/integration record.
Exact lifecycle and provisioning path.
Distro-matrix validation and reset/teardown evidence.
Guards and Stop Conditions
Do not call container machine a macOS VM, ordinary application container, or Compose replacement.
Do not assume Docker, Apple container, Lima, Colima, or a custom VM share flags or lifecycle semantics.
Do not enable home sharing for untrusted work; hand security research to prepare-isolated-analysis-lab.
Do not promise Rosetta or nested virtualization without host, OS, kernel, and device proof.
Do not commit images, kernels, disks, credentials, or machine-local runtime state.
Stop when provenance, capacity, reset strategy, host integration, or required fidelity cannot be verified.
Announce before starting a VM/service, downloading an image, or creating a large disk.
Fallbacks and Handoffs
Use server-side-swift:apple-containerization-workflow for container machine command semantics.
Use server-side-swift:docker-workflow for Dockerfiles, Compose, registries, and portable OCI deployment.
Use virtualization-framework-workflow for custom full-VM implementation.
Use xcode-build-run-workflow, swift-package-build-run-workflow, or stack-specific skills after the guest is ready.
Use prepare-isolated-analysis-lab for disposable hostile-workload controls.
