Imported from sebastian-zm/nix-darwin (
AGENTS.md). Install upstream withnpx skills add sebastian-zm/nix-darwin. Copyright stays with the author.
Repository Guidelines
Project Structure & Module Organization
This flake config lives at the repository root. flake.nix defines inputs and exposes the darwinConfigurations.Sebastians-MacBook-Pro target, while flake.lock pins exact revisions. System options, editor packages, and plugin wiring are kept in configuration.nix; split new modules into modules/<feature>.nix and import them from configuration.nix to keep the root concise.
Build, Test, and Development Commands
Run darwin-rebuild build --flake .#Sebastians-MacBook-Pro to produce the system derivation without activating it. Use darwin-rebuild switch --flake .#Sebastians-MacBook-Pro when you are ready to apply changes. Execute nix flake check before submitting to validate the flake and catch syntax or evaluation errors.
Coding Style & Naming Conventions
Write Nix with two-space indentation and trailing semicolons on attribute sets. Group related options under attribute paths (for example environment.systemPackages) and keep package lists alphabetized. Prefer the attribute-set style ({ pkgs, ... }:) for modules and share common arguments via specialArgs. Format all edits with nix fmt (Nix 2.18+) or nixpkgs-fmt to ensure stable diffs.
Testing Guidelines
Extend or add integration tests by invoking nix flake check after every change; it runs evaluation checks for all configurations. When altering services or packages, follow a dry run with darwin-rebuild switch --flake .#Sebastians-MacBook-Pro --dry-run to verify activation succeeds before touching the live system. Name additional module tests after the feature they exercise (for example tests/networking.nix).
Commit & Pull Request Guidelines
Use short, imperative commit subjects mirroring the existing history (e.g., add vscode extensions, switch to binary ghidra). Commits should isolate logical changes—separate package additions from service tweaks. Pull requests must describe the motivation, summarize the configuration impact, and link related issues. Include the exact command output (build or switch) in the PR body so reviewers can reproduce your result.
Security & Configuration Tips
Never commit machine-specific secrets or private SSH keys; reference secure paths under $HOME/Library/Application Support or keychains instead. When introducing new inputs, prefer read-only tokens and document any required environment variables in the PR to aid other maintainers.