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
|
# Copy our configuration files to home directory
|
||||||
home.file = {
|
home.file = {
|
||||||
".ideavimrc".source = ./ideavimrc;
|
".ideavimrc".source = ./ideavimrc;
|
||||||
|
|
||||||
|
# Global claude configuration
|
||||||
".claude/settings.json".source = ./claude-settings.json;
|
".claude/settings.json".source = ./claude-settings.json;
|
||||||
|
".claude/CLAUDE.md".source = ./CLAUDE.md;
|
||||||
};
|
};
|
||||||
}
|
}
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue