From 3648b4d5359e67ca5689ec70f7d1e978f1926945 Mon Sep 17 00:00:00 2001 From: Tibo De Peuter Date: Tue, 17 Mar 2026 21:44:54 +0100 Subject: [PATCH] meta: add AI agent rules and skills Create a modular, context-aware style guide for AI code assistants. - Add nixos-architecture skill for .nix file generation and networking patterns - Add dns-management rule to enforce Bind9 SOA serial increments - Add cicd-networking rule for direct-IP runner authentication - Add git-workflow rule to enforce conventional and atomic commits --- .agent/rules/ci-cd-networking-constraints.md | 13 ++++++ .agent/rules/dns-management.md | 14 ++++++ .agent/rules/git-workflow.md | 21 +++++++++ .agent/skills/nixos-architecture/SKILL.md | 47 ++++++++++++++++++++ 4 files changed, 95 insertions(+) create mode 100644 .agent/rules/ci-cd-networking-constraints.md create mode 100644 .agent/rules/dns-management.md create mode 100644 .agent/rules/git-workflow.md create mode 100644 .agent/skills/nixos-architecture/SKILL.md diff --git a/.agent/rules/ci-cd-networking-constraints.md b/.agent/rules/ci-cd-networking-constraints.md new file mode 100644 index 0000000..89c1866 --- /dev/null +++ b/.agent/rules/ci-cd-networking-constraints.md @@ -0,0 +1,13 @@ +--- +name: cicd-networking +description: Networking constraints for CI/CD workflow files (Gitea/GitHub Actions). +globs: [".github/workflows/.yml", ".github/workflows/.yaml", ".gitea/workflows/.yml", ".gitea/workflows/.yaml"] +--- + +# Bos55 CI/CD Networking Constraints + +When generating or modifying CI/CD workflows, strictly follow these networking practices: + +1. **IP-Based Login for Reliability** + - When CI runners (like Gitea Actions) need to interact with internal services for authentication or deployment, always use direct IP addresses (e.g., `192.168.0.25`) for machine-to-machine login steps. + - **Why?** This bypasses potential DNS resolution issues or delays within the isolated runner environment, ensuring maximum robustness during automated CI/CD runs. diff --git a/.agent/rules/dns-management.md b/.agent/rules/dns-management.md new file mode 100644 index 0000000..e8e6a7b --- /dev/null +++ b/.agent/rules/dns-management.md @@ -0,0 +1,14 @@ +--- +name: dns-management +description: Hard constraints for modifying Bind9 DNS zone files. +globs: ["db.", ".zone"] +--- + +# Bos55 DNS Management Constraints + +When modifying or generating Bind9 zone files, you MUST strictly adhere to the following rules: + +1. **Serial Increment (CRITICAL)** + - Every single time you modify a Bind9 zone file (e.g., `db.depeuter.dev`), you MUST increment the Serial number in the SOA record. Failure to do so will cause DNS propagation to fail. +2. **Domain Name Specificity** + - Prefer a single, well-defined explicit domain (e.g., `nix-cache.depeuter.dev`) instead of creating multiple aliases or using magic values. Keep records clean and explicit. diff --git a/.agent/rules/git-workflow.md b/.agent/rules/git-workflow.md new file mode 100644 index 0000000..6d41ee2 --- /dev/null +++ b/.agent/rules/git-workflow.md @@ -0,0 +1,21 @@ +--- +name: git-workflow +description: Rules for generating Git commit messages and managing branch workflows. +globs: ["COMMIT_EDITMSG", ".git/*"] +--- + +# Git Workflow Constraints + +When generating commit messages, reviewing code for a commit, or planning a branch workflow, strictly follow these standards: + +1. **Commit Formatting** + - **Conventional Commits**: You MUST format all commit messages using conventional prefixes: `feat:`, `fix:`, `docs:`, `refactor:`, `ci:`, `meta:`. + - **Clarity**: Ensure the message clearly explains *what* changed and *why*. +2. **Atomic Commits** + - Group changes by a single logical concern. + - NEVER mix documentation updates, core infrastructure code, and style guide changes in the same commit. + - Ensure that the generated commit is easily revertible without breaking unrelated features. +3. **Branching Workflow** + - Always assume changes will be pushed to a feature branch to create a Pull Request. + - Do not suggest or generate commands that push directly to the main branch. + diff --git a/.agent/skills/nixos-architecture/SKILL.md b/.agent/skills/nixos-architecture/SKILL.md new file mode 100644 index 0000000..2eb63bf --- /dev/null +++ b/.agent/skills/nixos-architecture/SKILL.md @@ -0,0 +1,47 @@ +--- +name: bos55-nix-architecture +description: Implementation patterns for NixOS configurations, networking, and service modules. +globs: [".nix", "hosts/**/", "modules//*", "secrets//*"] +--- + +# NixOS Architecture Skill + +When generating or modifying NixOS configuration files for the Bos55 project, strictly adhere to the following architectural patterns: + +## 1. Minimal Hardcoding & Dynamic Discovery + +- **Local IP Ownership**: Define IPv4/IPv6 addresses **only** within their respective host configuration files (e.g., `hosts//default.nix`). Do not use global IP mapping modules. +- **Inter-Host Discovery**: Resolve a host's IP or port by evaluating its configuration at build time. Never hardcode another host's IP. + **Pattern Example**: + ``` + let + bcConfig = inputs.self.nixosConfigurations.BinaryCache.config; + bcIp = (pkgs.lib.head bcConfig.networking.interfaces.ens18.ipv4.addresses).address; + in "http://${bcIp}:8080" + ``` +- **Unified Variables**: Use local variables (e.g., `let dbName = "attic"; in ...`) for shared values between host services and containers to ensure consistency. + +## 2. Modular Service Encapsulation + +- **Self-Contained Modules**: Service modules (`modules/services//default.nix`) must manage their own configurations. Prefer `lib.mkOption` over hardcoded strings for domains, ports, and credentials. +- **Firewall Responsibility**: Open ports (e.g., TCP 8080, SSH 22) directly within the service module based on its own options. Do not open service ports manually in host files. +- **Remote Builders**: Define `nix.settings.trusted-users`, `builder` user, and SSH rules directly within the service module if it supports remote building (e.g., Attic). + +## 3. Networking & Connectivity + +- **Container-to-Host**: Host services must connect to companion containers using the container name, not the bridge IP or `localhost`. +- **Host Resolution**: Map the container name to `127.0.0.1` using `networking.extraHosts` in the host service module to route traffic seamlessly. +- **Domain Deferral**: Client modules must defer their default domain settings to the server module's defined domain option. + +## 4. Secrets Management + +- **Sops-Nix Exclusivity**: Manage all secrets via `sops-nix`. +- **Centralized Config**: Rely on `modules/common/default.nix` for fleet-wide settings like `defaultSopsFile` and `age.keyFile`. +- **References**: Always reference credentials dynamically using `config.sops.secrets."path/to/secret".path`. + +## 5. Security & Documentation + +- **Supply Chain Protection**: Always verify and lock Nix flake inputs. Use fixed-output derivations for external resource downloads. +- **Assumptions Documentation**: Clearly document environment assumptions (e.g., Proxmox virtualization, Tailscale networking, and specific IP ranges) in host or service READMEs. +- **Project Structure**: Maintain the strict separation of `hosts/`, `modules/`, `users/`, and `secrets/` to ensure clear ownership and security boundaries. +