Install System Package

Candidate Selection Rules

• Prefer Nix whenever a maintained nixpkgs package satisfies the need.
• Prefer Homebrew brew over cask for CLI tools that exist in both.
• Use cask for GUI applications or app bundles.
• If the package name differs from the executable or app name, track both names before you present options.

Required Confirmation Points

• Before editing config.
• When choosing host-specific versus shared scope.
• Before running the rebuild command.

Verification Rules

• For CLI tools, verify with command -v <command> and a lightweight version or help check when sensible.
• For GUI apps, verify the app bundle exists at the expected macOS application path.
• If the rebuild succeeds but the tool or app is not usable, treat the installation as failed.

Hard Rules

• Never use imperative brew install, brew upgrade, nix profile install, or similar one-off package installs.
• Never hide package choice or scope from the user.
• Never commit or push before rebuild and verification succeed.
• Never include unrelated working tree changes in the commit.
• If package lookup is ambiguous, show the ambiguity and ask the user.

Examples

• A task needs rg, the command is missing, and ripgrep would unblock the work. Propose pkgs.ripgrep first, show any viable Homebrew fallback, ask about host-specific versus shared scope, then proceed declaratively if the user approves.
• The user asks to install a GUI app such as Google Chrome. Prefer a cask when there is no suitable Nix package, ask about scope, edit the declared Homebrew config, rebuild, verify the app bundle, then commit and push.