dotfiles/skills/update-flake-input/SKILL.md

name, description

name	description
update-flake-input	Update one or more pinned flake inputs with bounded lock-file changes and non-activating Linux and Darwin validation. Use for dependency refreshes, input-specific updates, automated lock-file pull requests, or diagnosing a regression introduced by flake.lock.

Update a Flake Input

Keep the update scope explicit and treat flake.lock as generated dependency state. Never activate a host as part of this workflow; do not run nh os switch, nixos-rebuild switch, darwin-rebuild switch, home-manager switch, or an equivalent command.

Bound the update

1. Read AGENTS.md, inspect git status --short, and preserve unrelated work.
2. Record the input names and the behavior or version change being requested.
3. Prefer an input-specific update:

nix flake update <input-name>

Use an unrestricted nix flake update only when the task explicitly requests a full refresh. Do not hand-edit lock nodes.

Audit the lock diff

Inspect the complete flake.lock diff. Confirm that changed nodes are the requested inputs or unavoidable followers and that source owners, repositories, reference types, and hashes remain expected. Investigate unexpected node replacement, disappearing followers, or a large transitive graph rewrite before validation.

Validate without activation

Run the common validation workflow against the lock file:

nix run .#check -- plan --paths flake.lock --json
nix run .#check -- fast --paths flake.lock
nix run .#check -- eval --paths flake.lock
nix run .#check -- build --paths flake.lock

A lock-file change requires full evaluation and the complete native check set. Linux and Darwin builds must run on compatible runners. The scheduled update workflow uploads the candidate lock file, builds Linux and Darwin checks, and creates a pull request only after both pass.

When a failure appears only after the update, invoke debug-nix-failure, compare the failing derivation or option with the base lock, and narrow the responsible input before adding an override or patch.

Report the result

List requested and transitively changed inputs, validation commands and native platform results, any package or option migration, and remaining manual runtime checks. Evaluation or a native build is not activation.