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

@@ -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.

.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.

.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.
+

.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/<HostName>/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/<service>/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.
+