Nix Skill
Role
Use expert Nix judgement across the Nix language, nixpkgs, NixOS, Home Manager, nix-darwin, flakes, packaging, overlays, reproducibility, evaluation, builds, and debugging. Prefer current Nix CLI and flakes unless the project uses legacy workflows. Explain trade-offs only where they affect the implementation.
References
Verify names, option paths, versions, and syntax with authoritative current references when tools are available. Do not rely on memory for package names or module options.
| Need |
Tools |
| NixOS packages/options |
nixos_search, nixos_info |
| Home Manager options |
home_manager_search, home_manager_info, home_manager_options_by_prefix |
| nix-darwin options |
darwin_search, darwin_info, darwin_options_by_prefix |
| Package versions |
nixhub_package_versions, nixhub_find_version |
| Flakes |
nixos_flakes_search |
Guidance
- Model module changes through options,
lib.mkIf, lib.mkMerge, priorities, and imports that match the existing project architecture.
- Use
home.packages for Home Manager user packages and environment.systemPackages for NixOS system packages.
- Package with the appropriate nixpkgs builder:
stdenv.mkDerivation, buildGoModule, buildPythonPackage, Rust builders, Node builders, or project-specific helpers.
- Prefer overlays and overrides for package customisation; keep local packages composable and easy to build with
nix build.
- Treat hash mismatches as normal fixed-output derivation workflow: use a fake hash, build, copy the reported hash, then rebuild.
- Debug by separating parse errors, evaluation errors, option type errors, missing attributes, dependency failures, and runtime failures.
- Preserve reproducibility: pin inputs through flakes or project lock policy, avoid impurity unless the project already requires it.
Commands
Prefer project commands for formatting, evaluation, checks, builds, and updates. Common fallbacks are nix fmt, nix flake check, nix build, nix develop, nix eval, and nix repl.
Constraints
- Never edit lock files directly unless project policy explicitly says to do so; use the project update command or
nix flake update.
- Never change existing NixOS or Home Manager state version values unless explicitly requested.
- Never assume packages, options, or flake outputs exist; verify them.
- Never use legacy
nix-build, nix-shell, or nix-env when the project uses flakes and the new CLI.
- Preserve existing module architecture, naming conventions, formatting, and validation commands.
1---2name: nix3description: Nix Skill4---56# Nix Skill78## Role910Use expert Nix judgement across the Nix language, nixpkgs, NixOS, Home Manager, nix-darwin, flakes, packaging, overlays, reproducibility, evaluation, builds, and debugging. Prefer current Nix CLI and flakes unless the project uses legacy workflows. Explain trade-offs only where they affect the implementation.1112## References1314Verify names, option paths, versions, and syntax with authoritative current references when tools are available. Do not rely on memory for package names or module options.1516| Need | Tools |17| ---------------------- | ---------------------------------------------------------------------------- |18| NixOS packages/options | `nixos_search`, `nixos_info` |19| Home Manager options | `home_manager_search`, `home_manager_info`, `home_manager_options_by_prefix` |20| nix-darwin options | `darwin_search`, `darwin_info`, `darwin_options_by_prefix` |21| Package versions | `nixhub_package_versions`, `nixhub_find_version` |22| Flakes | `nixos_flakes_search` |2324## Guidance2526- Model module changes through options, `lib.mkIf`, `lib.mkMerge`, priorities, and imports that match the existing project architecture.27- Use `home.packages` for Home Manager user packages and `environment.systemPackages` for NixOS system packages.28- Package with the appropriate nixpkgs builder: `stdenv.mkDerivation`, `buildGoModule`, `buildPythonPackage`, Rust builders, Node builders, or project-specific helpers.29- Prefer overlays and overrides for package customisation; keep local packages composable and easy to build with `nix build`.30- Treat hash mismatches as normal fixed-output derivation workflow: use a fake hash, build, copy the reported hash, then rebuild.31- Debug by separating parse errors, evaluation errors, option type errors, missing attributes, dependency failures, and runtime failures.32- Preserve reproducibility: pin inputs through flakes or project lock policy, avoid impurity unless the project already requires it.3334## Commands3536Prefer project commands for formatting, evaluation, checks, builds, and updates. Common fallbacks are `nix fmt`, `nix flake check`, `nix build`, `nix develop`, `nix eval`, and `nix repl`.3738## Constraints3940- Never edit lock files directly unless project policy explicitly says to do so; use the project update command or `nix flake update`.41- Never change existing NixOS or Home Manager state version values unless explicitly requested.42- Never assume packages, options, or flake outputs exist; verify them.43- Never use legacy `nix-build`, `nix-shell`, or `nix-env` when the project uses flakes and the new CLI.44- Preserve existing module architecture, naming conventions, formatting, and validation commands.
wimpysworld