Work safely and correctly in Nix-managed development environments. Use this skill whenever the user is working in a repository that may use Nix, on NixOS, or when build/test/dev commands might depend on a flake dev shell. Always check for a flake.nix before running project commands, prefer the existing dev shell when already inside one, and use `nix develop . -c ...` when tools are not available outside the shell.
Use this skill to avoid running project commands outside the environment they were designed for.
On this machine, Nix usage is common and repositories may expect commands to run inside a flake-based dev shell. Many failures that look like missing tools, wrong versions, or inconsistent formatting are really just "not inside the right Nix environment yet."
Before running project-specific build, test, lint, format, generation, or dev-server commands:
flake.nix in the current directory.flake.nix exists, prefer running commands within that flake's dev shell.Do not make a big ceremony out of this. Just verify the environment early so the rest of the work is reliable.
At the start of work on a project, check for:
flake.nixflake.lock as supporting evidenceUsually the nearest relevant flake.nix in the repo is the right one.
If there is no flake.nix, continue normally unless the user tells you there is another Nix entrypoint.
If the environment already indicates a Nix shell, prefer using it directly.
Useful signals include:
IN_NIX_SHELLPATHnix developWhen already inside the right shell, run commands normally.
When a project command depends on the development environment and you are not already in it, run it via:
nix develop . -c <command>
If the relevant flake.nix is in a parent or different project directory, run the command from that directory or use an equivalent form that targets the correct flake.
nix develop . -cUse it for commands such as:
Examples:
nix develop . -c npm test
nix develop . -c cargo test
nix develop . -c mix test
nix develop . -c just check
You usually do not need nix develop for simple file inspection or basic shell builtins.
Examples that normally do not need wrapping:
The goal is reliability, not ritual.
If a command fails with errors that suggest missing binaries, wrong tool versions, or an unavailable runtime:
flake.nix exists.nix develop . -c ... if you were not already using it.Treat Nix environment mismatch as an early hypothesis, not a last resort.
Be brief and practical. You usually do not need to explain Nix unless it affects the work.
Good examples:
flake.nix, so I’ll run tests through nix develop to match the project environment."For project work on this machine:
flake.nix earlynix develop . -c ...