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