diff options
Diffstat (limited to 'modules')
| -rw-r--r-- | modules/home/claude.nix | 103 | ||||
| -rw-r--r-- | modules/home/default.nix | 1 |
2 files changed, 12 insertions, 92 deletions
diff --git a/modules/home/claude.nix b/modules/home/claude.nix index 7edca3d..d141130 100644 --- a/modules/home/claude.nix +++ b/modules/home/claude.nix @@ -1,7 +1,9 @@ -{ ... }: +{ config, ... }: { - home.file.".claude/CLAUDE.md".text = '' + 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. @@ -30,93 +32,12 @@ - When ending a conversation or the user says goodbye, use `/session end` to clean up. ''; - home.file.".claude/skills/session/SKILL.md".text = '' - --- - name: session - description: Start or end a work session — annotates via Loggie and sets the tmux window title. - allowed-tools: mcp__loggie__annotate, Bash(tmux rename-window *) - --- - - # /session — Work Session Management - - You are executing the /session skill. This skill manages Loggie annotations and tmux window titles. - - ## Arguments - - - `/session <description>` — Start or update the current session with a description of what you're working on. - - `/session end` — End the current session. - - ## Starting / Updating a Session - - 1. Use the Loggie `annotate` MCP tool with the provided description. Keep it short and descriptive (e.g. "Fixing auth bug in login flow", "Adding CSV export endpoint"). - 2. Set the tmux window title using `tmux rename-window "<title>"`. The title should be very short and recognizable — it does not need to match the annotation exactly. - - ## Ending a Session - - 1. Call the Loggie `annotate` MCP tool with an empty string to stop the current annotation. - 2. Reset the tmux window title using `tmux rename-window "zsh"`. - ''; - - home.file.".claude/skills/push/SKILL.md".text = '' - --- - name: push - description: Create a commit and push changes. Optionally creates a branch and opens a PR with an intelligently chosen reviewer. - disable-model-invocation: true - --- - - # /push — Commit & Push Workflow - - You are executing the /push skill. Follow these steps precisely. - - ## Step 1: Analyze Changes - - Run `git status` and `git diff` (staged + unstaged) to understand all current changes. - If there are no changes to commit, inform the user and stop. - - ## Step 2: Stage Files - - Stage the relevant files. Prefer `git add <specific files>` over `git add -A`. - Never stage files that look like secrets (.env, credentials, tokens). - - ## Step 3: Ask — Branch or Main? - - Use the **AskUserQuestion** tool to ask the user how to push. Example: - - - question: "How should this be pushed?" - - header: "Push target" - - options: - - label: "Current branch", description: "Push directly to the current branch" - - label: "New branch + PR", description: "Create a new branch and open a pull request" - - ### If "Current branch": - - - Run `git push` (with `-u` if needed). - - Done. - - ### If "New branch + PR": - - 1. Create a descriptive branch name based on the changes (e.g., `feat/add-logging`, `fix/null-check-user`). - 2. Check out the new branch and push with `-u`. - 3. **Choose a reviewer:** - - Run `git log --format='%an' -50 | sort | uniq -c | sort -rn | head -10` to find active contributors. - - Cross-reference with files changed: run `git log --format='%an' -- <changed-files> | sort | uniq -c | sort -rn | head -5` to find who has context on the modified code. - - Pick the most relevant reviewer (not the current user — check with `git config user.name`). - - Build a list of up to 4 candidate reviewers and use **AskUserQuestion** to let the user pick. Example: - - question: "Who should review this PR?" - - header: "Reviewer" - - options: one per candidate, with description showing their commit count / relevance to changed files. - 4. Create the PR using `gh pr create`: - - Short title (under 70 chars). - - Body with a `## Summary` section (2-3 bullet points) and a `## Test plan` section. - - Add the confirmed reviewer with `--reviewer`. - 5. Return the PR URL to the user. - - ## Step 4: Create Commit - - - Analyze the staged diff. - - Write a concise commit message using **conventional commit format** (e.g., `feat:`, `fix:`, `refactor:`, `chore:`, `docs:`, `test:`, `ci:`). Include a scope when it adds clarity (e.g., `feat(auth):`, `fix(api):`). - - Output ONLY the raw commit message — no markdown, no code blocks, no backticks, no explanations. - - **Do NOT add a Co-Authored-By line. Never include any co-author trailer.** - - Create the commit using a HEREDOC for the message. - ''; + # 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"; + }; } diff --git a/modules/home/default.nix b/modules/home/default.nix index 229f8ce..2bd21df 100644 --- a/modules/home/default.nix +++ b/modules/home/default.nix @@ -31,7 +31,6 @@ home.packages = with pkgs; [ aerc - claude-code dina.packages.${pkgs.stdenv.hostPlatform.system}.default delta forgejo-cli |