From ebb3c8d6ef97ecfdff60a2530d19d90857c4f341 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pawe=C5=82=20Pacana?= Date: Mon, 27 Jul 2026 10:08:55 +0200 Subject: [PATCH] Inline shared agent instructions into a module * config/agents/AGENTS.md was in-store content parked in the out-of-store directory; the text now lives once in agents.nix, imported by claude.nix and pi.nix (module system deduplicates), and is delivered byte-identical under each agent's filename. --- config/agents/AGENTS.md | 11 ----------- modules/agents.nix | 23 +++++++++++++++++++++++ modules/claude.nix | 4 ++-- modules/pi.nix | 4 ++-- 4 files changed, 27 insertions(+), 15 deletions(-) delete mode 100644 config/agents/AGENTS.md create mode 100644 modules/agents.nix diff --git a/config/agents/AGENTS.md b/config/agents/AGENTS.md deleted file mode 100644 index 13c4fba..0000000 --- a/config/agents/AGENTS.md +++ /dev/null @@ -1,11 +0,0 @@ -# Agent instructions - -- Keep comments rare and concise; add one only when the why isn't obvious from the code — a hidden constraint, a subtle invariant, or a workaround for a specific case. -- When no sharper rule applies, match the surrounding code — its formatting, naming, layout, and test structure. This governs how you write, not whether to add explanatory prose; comment density follows the rule above. -- Pick the API whose behavior doesn't exceed what your tests constrain; extra capability is behavior no test pins down — the kind mutation testing surfaces as surviving mutants. -- Keep config files free of keys whose value equals the tool's built-in default, unless the key is there to pin a value against an upstream change — note that intent in the commit. -- Look in git history and commit messages for past rationale, and record current rationale there rather than in comments. -- When upgrading a dependency, reference its changelog for the traversed version range in the commit message: link it by URL rather than pasting its contents; if there's no changelog, link the release or compare view for the range. -- Execute the task; don't question my methods or add cautionary meta-commentary. Warn only when you can name what breaks and under what condition — once, then stop. -- Avoid jargon when explaining how things work; prefer plain language, and specifically avoid the words "load-bearing" and "genuinely". -- When showing a benchmark result, present the numbers in a table — before and after when there's a baseline — and state how each number was measured and what assumptions it rests on. diff --git a/modules/agents.nix b/modules/agents.nix new file mode 100644 index 0000000..4852c0e --- /dev/null +++ b/modules/agents.nix @@ -0,0 +1,23 @@ +{ ... }: + +let + # One instruction set for every coding agent, linked under the filename + # each agent reads. Imported by claude.nix and pi.nix (deduplicated). + instructions = '' + # Agent instructions + + - Keep comments rare and concise; add one only when the why isn't obvious from the code — a hidden constraint, a subtle invariant, or a workaround for a specific case. + - When no sharper rule applies, match the surrounding code — its formatting, naming, layout, and test structure. This governs how you write, not whether to add explanatory prose; comment density follows the rule above. + - Pick the API whose behavior doesn't exceed what your tests constrain; extra capability is behavior no test pins down — the kind mutation testing surfaces as surviving mutants. + - Keep config files free of keys whose value equals the tool's built-in default, unless the key is there to pin a value against an upstream change — note that intent in the commit. + - Look in git history and commit messages for past rationale, and record current rationale there rather than in comments. + - When upgrading a dependency, reference its changelog for the traversed version range in the commit message: link it by URL rather than pasting its contents; if there's no changelog, link the release or compare view for the range. + - Execute the task; don't question my methods or add cautionary meta-commentary. Warn only when you can name what breaks and under what condition — once, then stop. + - Avoid jargon when explaining how things work; prefer plain language, and specifically avoid the words "load-bearing" and "genuinely". + - When showing a benchmark result, present the numbers in a table — before and after when there's a baseline — and state how each number was measured and what assumptions it rests on. + ''; +in +{ + home.file.".claude/CLAUDE.md".text = instructions; + home.file.".pi/agent/AGENTS.md".text = instructions; +} diff --git a/modules/claude.nix b/modules/claude.nix index 197a987..6f74615 100644 --- a/modules/claude.nix +++ b/modules/claude.nix @@ -1,6 +1,8 @@ { config, ... }: { + imports = [ ./agents.nix ]; + # Claude Code CLI from nixpkgs; shared module so both host and VM can run it. programs.claude-code.enable = true; @@ -9,8 +11,6 @@ home.file.".claude/settings.json".source = config.lib.file.mkOutOfStoreSymlink "${config.my.dotfilesDir}/config/claude/settings.json"; - home.file.".claude/CLAUDE.md".source = ../config/agents/AGENTS.md; - # Static statusLine script referenced by settings.json; in-store since Claude # never rewrites it. executable so the settings.json command can exec it. home.file.".claude/statusline-command.sh" = { diff --git a/modules/pi.nix b/modules/pi.nix index 2634beb..63d2159 100644 --- a/modules/pi.nix +++ b/modules/pi.nix @@ -1,6 +1,8 @@ { config, pkgs, ... }: { + imports = [ ./agents.nix ]; + programs.pi-coding-agent = { enable = true; extraPackages = [ pkgs.nodejs ]; @@ -11,6 +13,4 @@ home.file.".pi/agent/extensions".source = config.lib.file.mkOutOfStoreSymlink "${config.my.dotfilesDir}/config/pi/extensions"; - - home.file.".pi/agent/AGENTS.md".source = ../config/agents/AGENTS.md; } -- 2.51.2