From d165d2c583983ff83da6165290d3b29c5ca280f6 Mon Sep 17 00:00:00 2001 From: Xavier Lagraula Date: Sun, 10 May 2026 22:24:21 +0200 Subject: [PATCH] Added spezcific cline rules to the framework repo. --- .clinerules/coding_nix | 32 +++++++++++++++++ .../project_nixos-infra_framework_directories | 16 +++++++++ .../project_nixos-infra_framework_goals | 12 +++++++ ...nixos-infra_framework_response_preferences | 7 ++++ ...project_nixos-infra_framework_tech_context | 9 +++++ .clinerules/role_product_manager | 35 +++++++++++++++++++ .clinerules/savings_rtk | 32 +++++++++++++++++ 7 files changed, 143 insertions(+) create mode 100644 .clinerules/coding_nix create mode 100644 .clinerules/project_nixos-infra_framework_directories create mode 100644 .clinerules/project_nixos-infra_framework_goals create mode 100644 .clinerules/project_nixos-infra_framework_response_preferences create mode 100644 .clinerules/project_nixos-infra_framework_tech_context create mode 100644 .clinerules/role_product_manager create mode 100644 .clinerules/savings_rtk diff --git a/.clinerules/coding_nix b/.clinerules/coding_nix new file mode 100644 index 0000000..7714b2c --- /dev/null +++ b/.clinerules/coding_nix @@ -0,0 +1,32 @@ +## Nix + +## General Instructions +1. Do not use Nix flakes. +2. Always check if an option (https://search.nixos.org/options), a package (https://search.nixos.org/packages) or a function (https://noogle.dev/) exists before inventing one. +3. Do not assume the development or administration workstations themselves run NixOS. The development environment is more likely Debian Trixie. +4. Use `nix-instantiate` to verify syntax and evaluation of Nix files: +``` +nix-instantiate --parse path/to/file.nix # Check syntax +nix-instantiate --eval -E 'import ./hosts/machine/configuration.nix {}' # Check evaluation +``` + +## Code Conventions +**Naming:** camelCase for variables, PascalCase for components and types. UPPER_CASE and "_" for shell environment variables. +**Types:** N/A +**Imports:** N/A +**Formatting:** +- Use exclusively `alejandra` or `nixfmt-rfc-style`. Never leave trailing whitespace. +- Prefer `inherit` for same-name variables. +- Use `with lib;` or `with builtins;` sparingly inside functions, but prefer explicit paths for clarity. +- Always declare arguments at the beginning of the file: `{ config, pkgs, lib, ... }:`. +**Modularity:** Each service must be encapsulated in a module with an `enable` option (e.g., `services.mon-service.enable = true;`). + +## Secret Management +**Strict Prohibition:** NEVER write passwords, API keys, or tokens in plaintext in `.nix` files. +**Tool:** Use **agenix**. + +## Specific Guidelines +1. **Never** expose passwords, API keys, or any secrets in plaintext. Use appropriate secret management/protection mechanisms for the context. +2. Prefer SSH keys for system authentication. +3. Limit line lengths to 78 printable characters. +4. Report any inconsistencies in practices within the project or with best practices. diff --git a/.clinerules/project_nixos-infra_framework_directories b/.clinerules/project_nixos-infra_framework_directories new file mode 100644 index 0000000..47323b4 --- /dev/null +++ b/.clinerules/project_nixos-infra_framework_directories @@ -0,0 +1,16 @@ +# Project Rules: nixos-infra + +## Directories + +### Public framework repo (nixos-infra-framework) +- `/nixos-infra-framework/modules/machine-types`: Nix modules standardizing different host types (hypervisor, VM, LXC, workstations, etc.). +- `/nixos-infra-framework/modules/services`: Nix modules standardizing different network infrastructure services (DNS, git-forge, password-manager, reverse-proxy, etc.). +- `/nixos-infra-framework/modules/user-profiles`: Nix modules standardizing different user profiles (admin, dev, office, etc.). +- `/nixos-infra-framework/overlays`: Nix overlays (last resort). +- `/nixos-infra-framework/pkgs`: Custom packages not present in Nixpkgs. +- `/nixos-infra-framework/lib`: Nix utility functions. +- `/nixos-infra-framework/scripts`: Generic operational scripts (deploy, create-lxc, etc.). +- `/nixos-infra-framework/environments/sample`: Example environment for onboarding. + +The entry point for each machine is `environments//hosts///configuration.nix`. +Modules are imported via `fetchGit` from the framework repo. \ No newline at end of file diff --git a/.clinerules/project_nixos-infra_framework_goals b/.clinerules/project_nixos-infra_framework_goals new file mode 100644 index 0000000..a47d7eb --- /dev/null +++ b/.clinerules/project_nixos-infra_framework_goals @@ -0,0 +1,12 @@ +# Project Rules: nixos-infra + +## Goals + +The goal is to enable the deployment and maintenance of network infrastructure and application services +(DNS, git repository server, password manager, file server, backup server, reverse proxy, +workstations, etc.). The git repository contains all files needed to configure and install +any machine in the fleet (OS images, configuration files, deployment and maintenance scripts). +The target is to be able to rebuild the entire fleet from a Linux workstation (not necessarily NixOS) +where this repository has been cloned. +This git repository contains the technical framework. It must not contain data/configuratin from actual +environments. diff --git a/.clinerules/project_nixos-infra_framework_response_preferences b/.clinerules/project_nixos-infra_framework_response_preferences new file mode 100644 index 0000000..3e5f6de --- /dev/null +++ b/.clinerules/project_nixos-infra_framework_response_preferences @@ -0,0 +1,7 @@ +# Project Rules: nixos-infra + +## Response Preferences +- Language: English +- Style: Technical, concise, Infrastructure as Code oriented. +- Always briefly explain *why* a specific NixOS option was chosen (reference to official options). +- Notify me if and when it was difficult or impossible to follow the instructions provided in `.ai-rules.md`. diff --git a/.clinerules/project_nixos-infra_framework_tech_context b/.clinerules/project_nixos-infra_framework_tech_context new file mode 100644 index 0000000..47dca6b --- /dev/null +++ b/.clinerules/project_nixos-infra_framework_tech_context @@ -0,0 +1,9 @@ +# Project Rules: nixos-infra + +## Technical Context +**Stack:** NixOS 25.11, agenix, bash, SSH, Proxmox VE, LXC, KVM, IPv4, IPv6 +**Environment:** VSCodium (VSCode) on Debian 13 + Cline extension for AI, bash, SSH, Gitea, IPv4, IPv6 +**Package Manager:** Nix +**Style:** Favor modularity, in the Unix philosophy. Use bash for operational tasks, with a fallback to Python if bash becomes unmaintainable. +**Tests:** Test Driven Development whenever possible. +**Hardware:** X86-64 desktop computers, an old Dell T620, an old Dell T330, a Rpi 3B diff --git a/.clinerules/role_product_manager b/.clinerules/role_product_manager new file mode 100644 index 0000000..614b206 --- /dev/null +++ b/.clinerules/role_product_manager @@ -0,0 +1,35 @@ +# Role +You are an exceptional product manager with 20 years of experience and an engineer proficient in all programming languages, skilled in assisting junior developers. + +# Goal +Help users complete their product design and development tasks in an easily understandable way, proactively completing all tasks without waiting for repeated prompting. + +## Step 1: Project Initialization +- When a user makes a request, first review the readme.md file and all code documents in the root directory to understand the project's goals, architecture, and implementation methods. If a readme file doesn't exist, create one. +- This file will serve as a manual for users to understand all provided functions and your project plan. +- Clearly describe the purpose, usage, parameter descriptions, and return value descriptions of all functions in the readme.md file to ensure user-friendly understanding and usage. + +## Step 2: Task Understanding and Execution +### Understanding User Needs +- Fully understand user needs from their perspective. Consider: "If I were the user, what would I need?" +- As a product manager, identify any gaps in user needs. Discuss and refine requirements with users until satisfaction is achieved. +- Prioritize the simplest solutions to meet user needs, avoiding overly complex or advanced approaches. + +### Code Development +- Plan step-by-step, considering user needs and existing codebase. +- Choose appropriate programming languages and frameworks to implement user requirements. +- Design code structure based on SOLID principles and use design patterns to address common problems. +- Write comprehensive comments for all code modules and include necessary monitoring to track errors. +- Opt for simple, controllable solutions over complex ones. + +### Problem Solving +- Thoroughly read the entire code file library to understand all code functions and logic. +- Analyze the root causes of user-reported code errors and propose solutions. +- Engage in multiple interactions with users, summarizing previous interactions and adjusting solutions based on feedback until user satisfaction. +- Initiate "System 2 Thinking Mode" for persistent bugs: + 1. Systematically analyze potential root causes and list all hypotheses. + 2. Design verification methods for each hypothesis. + 3. Provide three distinct solutions, detailing pros and cons for user choice. + +## Step 3: Project Summary and Optimization +- After completing the user's task, reflect on the task completion process, identify potential issues and improvements, and update the readme.md file accordingly. diff --git a/.clinerules/savings_rtk b/.clinerules/savings_rtk new file mode 100644 index 0000000..7d6c8af --- /dev/null +++ b/.clinerules/savings_rtk @@ -0,0 +1,32 @@ +# RTK - Rust Token Killer (Cline) + +**Usage**: Token-optimized CLI proxy for shell commands. + +## Rule + +Always prefix shell commands with `rtk` to minimize token consumption. + +Examples: + +```bash +rtk git status +rtk cargo test +rtk ls src/ +rtk grep "pattern" src/ +rtk find "*.rs" . +rtk docker ps +rtk gh pr list +``` + +## Meta Commands + +```bash +rtk gain # Show token savings +rtk gain --history # Command history with savings +rtk discover # Find missed RTK opportunities +rtk proxy # Run raw (no filtering, for debugging) +``` + +## Why + +RTK filters and compresses command output before it reaches the LLM context, saving 60-90% tokens on common operations. Always use `rtk ` instead of raw commands.