What problem does it solve? Deploying NixOS configurations to remote hosts carries real risk: a failed switch can break connectivity, a Git tag can misrepresent a dirty working tree, and a partial multi-host rollout can leave machines in inconsistent states. This Skill enforces a staged, authorization-gated deployment workflow for the nixcf flake so every live action is deliberate, verified, and recoverable. ## Core Features & Use Cases - Staged operation classification: Distinguishes plan, validate, build, test activation, local switch, remote switch, multi-host rollout, rollback, and tagging, each requiring explicit authorization before execution. - Preflight provenance checks: Inspects Git status, HEAD, dirty-tree state, and flake.lock/secrets/ changes, and runs a source-safety gate before any Nix evaluation or deployment. - Verification and rollback: Verifies activation, fresh connectivity, systemd health, changed units, and application checks after switching, and defines exact generation-based rollback commands before any live change. - Use Case: You edited the Pi4B homelab configuration and want to deploy. The Skill reads flake.nix and justfile, confirms the target and recipe semantics, runs just chk, records the current generation, executes just pi only after you authorize both the switch and its automatic pi-r<N> tag, then verifies system health and reports the per-host result state. ## Quick Start Use the nixcf-deploy skill to validate the flake with just chk and then deploy the nixos-pi4b host, asking me for confirmation before the remote switch and tag.
