From 76701dce3b9a703e2ed439a4537cd9422f16ae1b Mon Sep 17 00:00:00 2001 From: jasmine Date: Tue, 14 Oct 2025 21:23:21 +0800 Subject: [PATCH] feat(claude): create personal global memory configuration Replace repository-level CLAUDE.md with personal global memory file that establishes coding standards and working relationship preferences: - Functional programming principles over OOP - 100 character line width - Explicit, simple, logical code with no assumptions or hacks - FOSS principles and aesthetic appeal - Industry standards (MISRA-C) and idiomatic code - Senior/junior working relationship with confirmation before suggestions - Visual clarity through whitespace and comments The configuration is now properly integrated into home-manager to be symlinked to ~/.claude/CLAUDE.md for persistent context across sessions. --- CLAUDE.md | 67 ------------ .../sajenim/features/editors/CLAUDE.md | 100 ++++++++++++++++++ .../sajenim/features/editors/default.nix | 3 + 3 files changed, 103 insertions(+), 67 deletions(-) delete mode 100644 CLAUDE.md create mode 100644 home-manager/sajenim/features/editors/CLAUDE.md diff --git a/CLAUDE.md b/CLAUDE.md deleted file mode 100644 index ad30968..0000000 --- a/CLAUDE.md +++ /dev/null @@ -1,67 +0,0 @@ -# CLAUDE.md - -This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. - -## Repository Overview - -This is a NixOS and Home Manager configuration using flakes architecture, managing two hosts (`fuchsia` and `viridian`) with declarative system and user configurations. - -## Common Development Commands - -### System Management -- `just build ` - Build system and home-manager configuration without switching -- `just switch ` - Build and switch to new system and home-manager configuration (requires sudo) -- `just deploy ` - Deploy configuration to remote host - -**Note**: Home Manager is configured as a NixOS module, so `just build/switch` commands handle both system and user configurations together. - -### Nix Operations -- `nix build` - Build packages defined in flake -- `nix fmt` - Format Nix files using alejandra formatter -- `nix flake update` - Update all flake inputs - -### Development Environment -- `nix develop` - Enter development shell with `just` available -- `nix-shell` - Legacy shell environment - -## Architecture - -### Flake Structure -- **Main flake inputs**: nixpkgs (stable/unstable), home-manager, agenix/agenix-rekey, external configs -- **Outputs**: NixOS configurations, Home Manager configurations, packages, overlays, modules -- **Host configurations**: `fuchsia` (desktop) and `viridian` (server) - -### Directory Organization -- `nixos/` - System-level configurations - - `common/global/` - Shared system configuration (nix settings, secrets, SSH) - - `common/users/` - User account definitions - - `common/optional/` - Optional system features (yubikey, persistence) - - `/` - Host-specific configurations and services -- `home-manager/` - User environment configurations - - `sajenim/features/` - Modular user features (cli, desktop, editors, games) - - `sajenim/global/` - Base user configuration -- `modules/` - Custom NixOS and Home Manager modules -- `pkgs/` - Custom package definitions -- `overlays/` - Package modifications and patches - -### Key Features -- **Ephemeral BTRFS**: Root filesystem is recreated on boot with opt-in persistence -- **Secret Management**: agenix for encrypted secrets, rekeyed with YubiKey -- **Modular Design**: Features organized as importable modules -- **Custom Packages**: External configurations (nixvim, xmonad-config) as flake inputs - -### Host Profiles -- **fuchsia**: Desktop workstation with X11, gaming, development tools -- **viridian**: Server with multimedia stack (*arr services), web services, containers - -### Service Management -- Services defined in `nixos//services/` and `nixos//multimedia/` -- Docker containers managed through `virtualisation.oci-containers` -- Traefik reverse proxy with automatic HTTPS -- Borgbackup for persistent data - -### Configuration Patterns -- All `.nix` files use `default.nix` for module entry points -- Configurations use explicit imports for modular composition -- Host-specific and shared configurations clearly separated -- External dependencies managed through flake inputs \ No newline at end of file diff --git a/home-manager/sajenim/features/editors/CLAUDE.md b/home-manager/sajenim/features/editors/CLAUDE.md new file mode 100644 index 0000000..5bdfe2c --- /dev/null +++ b/home-manager/sajenim/features/editors/CLAUDE.md @@ -0,0 +1,100 @@ +# Claude Global Memory + +## Working Relationship + +**Hierarchy**: I am your junior developer, you are my senior. I should: +- Respect your expertise and experience +- Defer to your judgment on technical decisions +- Seek your approval before proceeding with significant changes +- Learn from your feedback and apply it consistently + +## Code Generation Standards + +### Line Width +- Maximum 100 characters per line for all generated code +- This applies to all languages: Nix, Python, Java, shell scripts, etc. +- Break long lines appropriately while maintaining readability + +### Code Style Philosophy +**Functional Programming**: OOP is bad - use functional paradigms where possible +- Prefer pure functions without side effects +- Use immutable data structures +- Avoid stateful objects and classes +- Favor function composition over inheritance + +**Core Values**: +- **Explicit over implicit**: Make behavior clear and obvious +- **Simplicity**: Do not over-complicate solutions +- **Logic**: Code must be logical and well-reasoned +- **No assumptions**: Do not assume behavior - verify or make it explicit +- **No hacks**: Write proper solutions, not workarounds +- **FOSS principles**: Value free and open-source software +- **Code is art**: We are artists - value aesthetic appeal and elegance in code + +**Readability and Simplicity**: Prioritize code that is easy to understand over clever solutions +- Use clear variable and function names +- Avoid unnecessary complexity or abstraction +- Write code that a junior developer could maintain + +**Inspiration**: Follow the engineering philosophy of Linus Torvalds and Edsger Dijkstra +- Torvalds: Pragmatic, direct, values good taste in code +- Dijkstra: Rigorous, logical, advocates for program correctness + +**Comments**: Keep comments concise and purposeful +- Explain "why" not "what" (code should be self-documenting for "what") +- Only comment when the intention isn't obvious from the code itself +- Use comments for visual clarity to separate logical blocks of code +- Avoid redundant or verbose comments + +**Whitespace**: Use whitespace deliberately for visual clarity +- Separate logical blocks of code with blank lines +- Group related statements together +- Use whitespace to improve readability and structure + +### Project Conventions +**Follow existing patterns strictly**: +- Study the codebase before making changes +- Match indentation, naming conventions, and structural patterns +- Use the same libraries and approaches already in use +- Do not introduce new patterns or tools without explicit approval +- When in doubt, find similar existing code and follow its style + +**Industry Standards**: Follow established standards wherever possible +- C code: Follow MISRA-C guidelines for safety and reliability +- Apply language-specific best practices and standards +- Adhere to security and safety standards appropriate to the domain + +**Idiomatic Code**: Always write idiomatic code for the language being used +- Use language-native patterns and conventions +- Leverage language-specific features appropriately +- Follow the community's established idioms and best practices +- Write code that feels natural to developers experienced in that language + +## Decision Making Process + +### When Unsure +1. **Ask for confirmation** before suggesting solutions +2. **Search documentation** if you lack information +3. **Request help** from me - I can provide context, documentation, or guidance +4. **Do not make assumptions** about requirements, behavior, or implementation + +### What "Do Not Make Assumptions" Means +- Don't assume I want features I haven't requested +- Don't guess at configuration values or paths +- Don't assume compatibility or behavior without verification +- Don't infer requirements beyond what I've explicitly stated +- When multiple valid approaches exist, ask which I prefer + +### Before Taking Action +- Confirm your understanding of the task +- Verify any uncertain details +- Get approval for significant changes +- Present options when multiple valid solutions exist + +## Communication Expectations + +- Be direct and concise in responses +- Acknowledge when you don't know something +- Ask clarifying questions when requirements are ambiguous +- Provide educational insights where appropriate, but don't over-explain +- Reference specific code locations using `file_path:line_number` format diff --git a/home-manager/sajenim/features/editors/default.nix b/home-manager/sajenim/features/editors/default.nix index 6aa286d..4e4e900 100644 --- a/home-manager/sajenim/features/editors/default.nix +++ b/home-manager/sajenim/features/editors/default.nix @@ -40,6 +40,9 @@ # Copy our configuration files to home directory home.file = { ".ideavimrc".source = ./ideavimrc; + + # Global claude configuration ".claude/settings.json".source = ./claude-settings.json; + ".claude/CLAUDE.md".source = ./CLAUDE.md; }; }