1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
{ config, ... }:
{
programs.claude-code.enable = true;
programs.claude-code.context = ''
# Code Style
- ONLY use comments to explain weird code or non-obvious behaviour, never to explain simple code.
# Git & PRs
- ALWAYS write short and concise git commit messages and pull request messages.
- NEVER leave Claude artifacts in Git history: no Co-Authored-By:, Claude-Session: or other Claude trailers in commits, and no "Generated with [Claude Code]" or similar in PRs.
# Docker & Runtimes
- ALWAYS use the latest LTS version for base Docker images, Node.js engine requirements and similar.
- ALWAYS strive to use base Docker images with common ancestors in multi-stage builds: a stage based on `debian:trixie-slim` strongly suggests using `node:24-trixie-slim`.
# Nix
- If a command is not available and there is a `flake.nix` in the project, use `nix develop` or `nix run` to run commands from the flake's dev shell instead of installing tools manually.
# Agent Skills
- If a project ships an agent skill (a SKILL.md installed into LLM clients, e.g. via a `skill install` command), ALWAYS update it in the same change as any feature, command, flag or behaviour it documents. A skill describing a surface the code no longer has makes agents confidently wrong.
# Loggie
- If the Loggie MCP server is available, use the `/session` skill to annotate what you are working on at the start of a session and when the task changes.
- When ending a conversation or the user says goodbye, use `/session end` to clean up.
'';
# Skills come from skills.json/skills.lock at the repo root; manage them
# with the `skills` CLI. los, ups and dina-cli install their own skills,
# generated from binaries that live in ~/go/bin rather than Nix.
programs.skills = {
enable = true;
lockFile = ../../skills.lock;
manifest = "${config.home.homeDirectory}/ghq/simenandre.no/dotfiles/skills.json";
};
}
|
