|
1 | | -# Global Claude Code Instructions |
| 1 | +# Claude Global Config v2.0 |
2 | 2 |
|
3 | | -This file provides baseline guidance to Claude Code across all projects. Project-specific instructions in local CLAUDE.md files will override or extend these. |
4 | | - |
5 | | -## Communication Style |
6 | | - |
7 | | -- Be direct, concise, and honest - avoid sycophantic or overly deferential language |
8 | | -- Provide constructive feedback when something could be improved |
9 | | -- Challenge assumptions when they might lead to problems |
10 | | -- Keep responses focused and to the point |
11 | | - |
12 | | -## Development Standards |
13 | | - |
14 | | -- Follow shell scripting best practices with consistent error handling |
15 | | -- Use color-coded output for different message types (success=green, warning=yellow, error=red, dry-run=cyan) |
16 | | -- All scripts should use `set -e` for fail-fast behavior |
17 | | -- Add timeout protection (30s) for potentially hanging commands |
18 | | -- Configure Git with security-conscious settings (fsckObjects enabled) |
19 | | - |
20 | | -## Safety Principles |
21 | | - |
22 | | -- Comprehensive prerequisite validation before any system changes |
23 | | -- Automatic backup of existing files before replacement |
24 | | -- Provide dry-run/preview modes for all destructive operations |
25 | | -- Detailed error handling with recovery options |
26 | | -- Optional logging for troubleshooting |
27 | | -- Signal-safe cleanup handlers for all system-modifying scripts |
28 | | -- Atomic file operations to prevent partial writes |
29 | | - |
30 | | -## File Organization |
31 | | - |
32 | | -- Use modular configuration approach when possible |
33 | | -- Separate concerns into focused, single-purpose files |
34 | | -- Support local overrides through gitignored files |
35 | | -- Prefer configuration over hardcoding |
36 | | - |
37 | | -## Code Style |
38 | | - |
39 | | -- Match existing code conventions in the project |
40 | | -- Use existing libraries and utilities rather than reinventing |
41 | | -- Follow established patterns in the codebase |
42 | | -- Never add comments unless explicitly requested |
43 | | -- Never introduce code that exposes or logs secrets |
44 | | - |
45 | | -## Testing Requirements |
46 | | - |
47 | | -- Practice test-driven development (TDD) whenever possible: |
48 | | - - Write tests first to define expected behavior |
49 | | - - Implement the minimum code needed to make tests pass |
50 | | - - Refactor while keeping tests green |
51 | | - - If TDD isn't feasible, explain why and write tests immediately after implementation |
52 | | -- Always add tests for new functionality, features, scripts, components, capabilities, or code |
53 | | -- Write unit tests for isolated functionality |
54 | | -- Write integration tests for features that interact with other components |
55 | | -- Ensure tests pass before considering a feature complete |
56 | | -- Follow existing test patterns and frameworks in the project |
57 | | -- If no test framework exists, suggest adding one before implementing features |
58 | | -- Run existing tests before making changes to ensure you don't break functionality |
| 3 | +## Core Principles |
| 4 | +- Be direct and concise |
| 5 | +- Test-driven development by default |
| 6 | +- Security-first approach |
| 7 | +- Match existing project patterns |
59 | 8 |
|
60 | 9 | ## Git Workflow |
| 10 | +- Feature branches only |
| 11 | +- Small commits (<200 LOC diffs) |
| 12 | +- Conventional commit format |
| 13 | +- Create PR unless told otherwise |
61 | 14 |
|
62 | | -- Always create a new feature branch from the main/master branch before making changes |
63 | | -- Use descriptive branch names (e.g., `feat/add-login`, `fix/memory-leak`, `docs/update-readme`) |
64 | | -- Never commit directly to the main/master branch |
65 | | -- Commit complete implementations frequently to keep diffs small and readable: |
66 | | - - Commit after each logical unit of work is complete and tested |
67 | | - - Aim for diffs under 200 lines when possible |
68 | | - - Break large features into smaller, incremental commits |
69 | | - - Each commit should represent a working state of the code |
70 | | - - Prefer multiple small commits over one large commit |
71 | | -- When asked to commit changes, also create a pull request unless explicitly told not to |
72 | | -- Follow conventional commit message formats when they exist in the project |
73 | | -- Keep commits focused and atomic - one logical change per commit |
74 | | - |
75 | | -## Security Practices |
76 | | - |
77 | | -- Always quote variables in shell scripts: `"$var"` not `$var` |
78 | | -- Validate and sanitize all user inputs |
79 | | -- Use `mktemp` for temporary files with restrictive permissions |
80 | | -- Never store secrets in code or logs |
81 | | -- Clean up sensitive data from memory/disk after use |
82 | | -- Implement proper signal handling for cleanup on interruption |
83 | | -- Use secure defaults and fail closed, not open |
84 | | - |
85 | | -## Important Behavioral Guidelines |
86 | | - |
87 | | -- Do only what has been asked; nothing more, nothing less |
88 | | -- Never create files unless absolutely necessary for the task |
89 | | -- Always prefer editing existing files over creating new ones |
90 | | -- Never proactively create documentation files (*.md) or README files unless explicitly requested |
91 | | -- Never commit changes unless explicitly asked to |
92 | | -- When blocked, ask for clarification rather than making assumptions |
| 15 | +## Development Standards |
| 16 | +- Fail-fast: `set -e` in shell scripts |
| 17 | +- Clean up after interruptions |
| 18 | +- Backup before system changes |
| 19 | +- Follow project conventions |
| 20 | + |
| 21 | +## Behavior |
| 22 | +- Do only what's asked |
| 23 | +- Prefer editing over creating files |
| 24 | +- Never create docs unless requested |
| 25 | +- Ask for clarification when blocked |
| 26 | + |
| 27 | +## Important |
| 28 | +When global CLAUDE.md updates, sync to macbook-dev-setup project. |
0 commit comments