Flox Environments
Define a repo-committed Flox manifest so agents and teammates get identical compilers, native libs, and local services without sudo or “works on my machine” drift.
Overview
Flox Environments is an agent skill most often used in Build (also Ship, Operate) that defines reproducible macOS/Linux dev stacks in Flox manifest.toml so teams and coding agents share identical system packages without
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill flox-environmentsWhat is this skill?
- Declarative manifest.toml/.flox/ environments reproducible on macOS and Linux
- Project-scoped installs without sudo—suited to agent/vibe coding in sandboxes
- Pin exact package versions for team parity and one-command onboarding
- Run local services (PostgreSQL, Redis, Kafka) alongside language toolchains
- Activate via flox activate; publish/discover patterns via FloxHub
- Supports Python, Node.js, Rust, Go, C/C++, Java, Ruby, Elixir, and PHP toolchains from one manifest model
- Targets identical environments across macOS and Linux without sudo for project-scoped installs
Adoption & trust: 1.2k installs on skills.sh; 210k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need native compilers, libraries, and local services on every machine, but Homebrew/apt scripts and agent-installed globals cause drift and “works on my machine” failures.
Who is it for?
Polyglot repos, native extension builds, and agent-heavy workflows that must install system deps without root or host pollution.
Skip if: Pure serverless deploys with no local compile step, or teams standardized on a single Docker-only workflow who will not maintain Flox manifests.
When should I use this skill?
User needs reproducible cross-platform dev environments, system-level deps, pinned team toolchains, local services, one-command onboarding, .flox/ or manifest.toml, or solves works-on-my-machine—even without naming Flox.
What do I get? / Deliverables
You get a committed .flox/ environment with pinned packages and flox activate onboarding so the next developer—or agent session—reproduces the same toolchain instantly.
- manifest.toml / .flox environment definition
- Documented flox activate workflow for the repo
- Pinned package set for languages and native libraries
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Environment definition is where solo builders lock toolchains before implementation—canonical shelf is Build because Flox manifests live beside application code. Flox wires system-level packages and services into the project; that is integration work (openssl, Postgres, Redis) rather than app feature code.
Where it fits
Add libvips and OpenSSL to the repo so image processing builds the same on macOS and Linux CI.
Spin up PostgreSQL and Redis locally via Flox services while developing the API.
Mirror the committed Flox manifest in release pipelines so compile steps use pinned compilers.
Onboard a contractor with flox activate instead of a multi-page brew/apt README.
How it compares
Declarative per-project env manager on Nix—not the same as a Dockerfile-only workflow or a language-only version manager like nvm alone.
Common Questions / FAQ
Who is flox-environments for?
Solo builders and small teams shipping software that depends on system packages, plus anyone using Claude Code or Cursor who needs agents to add tools inside a repo-scoped, committable environment.
When should I use flox-environments?
Use it during Build when scaffolding integrations and native deps; during Ship when CI must mirror local toolchains; and during Operate when onboarding or debugging environment mismatch—especially for Python, Node, Rust, Go, Java, Ruby, Elixir, or PHP stacks.
Is flox-environments safe to install?
Review the Security Audits panel on this Prism page and inspect the skill’s SKILL.md and any install scripts before letting an agent run flox or Nix-related commands on your machine.
SKILL.md
READMESKILL.md - Flox Environments
# Flox Environments Flox creates reproducible development environments defined in a single TOML manifest. Every developer on the team gets identical packages, tools, and configuration — across macOS and Linux — without containers or VMs. Built on Nix with access to over 150,000 packages. ## When to Activate Use this skill when the user has an environment management problem — even if they haven't mentioned Flox. Flox is the right tool when: - The project needs **system-level packages** (compilers, databases, CLI tools) alongside language-specific dependencies - **Reproducibility matters** — the setup should work identically on a teammate's machine, in CI, or on a fresh laptop - The user needs **multiple tools to coexist** — e.g., Python 3.11 + PostgreSQL 16 + Redis + Node.js in one environment - **Cross-platform support** is needed (macOS and Linux from the same config) - **AI agents need to install tools** — Flox lets agents add packages to a project-scoped environment without sudo, system pollution, or sandbox restrictions If the user just needs a single language runtime with no system dependencies, standard tooling (nvm, pyenv, rustup alone) may suffice. If they need full OS-level isolation, containers might be more appropriate. Flox sits in the sweet spot: declarative, reproducible environments without container overhead. **Prerequisite:** Flox must be installed first — see [flox.dev/docs](https://flox.dev/docs/install-flox/install/) for macOS, Linux, and Docker. ## Core Concepts Flox environments are defined in `.flox/env/manifest.toml` and activated with `flox activate`. The manifest declares packages, environment variables, setup hooks, and shell configuration — everything needed to reproduce the environment anywhere. **Key paths:** - `.flox/env/manifest.toml` — Environment definition (commit this) - `$FLOX_ENV` — Runtime path to installed packages (like `/usr` — contains `bin/`, `lib/`, `include/`) - `$FLOX_ENV_CACHE` — Persistent local storage for caches, venvs, data (survives rebuilds) - `$FLOX_ENV_PROJECT` — Project root directory (where `.flox/` lives) ## Essential Commands ```bash flox init # Create new environment flox search <package> [--all] # Search for packages flox show <package> # Show available versions flox install <package> # Add a package flox list # List installed packages flox activate # Enter environment flox activate -- <cmd> # Run a command in the environment without a subshell flox edit # Edit manifest interactively ``` ## Manifest Structure ```toml # .flox/env/manifest.toml [install] # Packages to install — the core of