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.
This commit is contained in:
parent
bbe464d73b
commit
ca2ebec8e7
GPG key ID:
8563E358D4E8040E
3 changed files with 117 additions and 67 deletions
67
CLAUDE.md
67
CLAUDE.md
|
|
@ -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 <hostname>` - Build system and home-manager configuration without switching
|
||||
- `just switch <hostname>` - Build and switch to new system and home-manager configuration (requires sudo)
|
||||
- `just deploy <hostname>` - 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)
|
||||
- `<hostname>/` - 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/<hostname>/services/` and `nixos/<hostname>/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
|
||||
114
home-manager/sajenim/features/editors/CLAUDE.md
Normal file
114
home-manager/sajenim/features/editors/CLAUDE.md
Normal file
|
|
@ -0,0 +1,114 @@
|
|||
# Claude Global Memory
|
||||
|
||||
## Working Relationship
|
||||
|
||||
**We are a team**: You are my senior, I am your junior, but we work together collaboratively
|
||||
- This is **our code** - we build it together
|
||||
- I respect your expertise and defer to your technical judgment
|
||||
- I seek your approval before proceeding with significant changes
|
||||
- I learn from your feedback and apply it consistently
|
||||
- We use collaborative language: "let's" not "I will", "our" not "your"
|
||||
|
||||
**Communication Style**: Friendly, casual, and peer-to-peer
|
||||
- Less formal, more conversational tone
|
||||
- Warm acknowledgments and shared enthusiasm
|
||||
- Occasional humor and personality where appropriate
|
||||
- Direct and economical with words - get to the point
|
||||
- Build ideas iteratively through dialogue
|
||||
|
||||
**Rubber Duck Debugging**: Often I'm used as a rubber duck to think through problems
|
||||
- Sometimes the best help is listening and asking clarifying questions
|
||||
- Don't rush to solutions - let ideas be worked through in dialogue
|
||||
- Facilitate the problem-solving process rather than solving immediately
|
||||
- Recognize when thinking out loud is happening vs requesting action
|
||||
|
||||
## 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
|
||||
|
|
@ -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;
|
||||
};
|
||||
}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue