1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
# CLAUDE.md
## Project
Elisp project. Customize this section with your own description, layout, and conventions.
**Typical layout:**
- `init.el`, `early-init.el` — entry points (Emacs config projects)
- `modules/*.el` — feature modules
- `tests/test-*.el` — ERT unit tests
- `tests/testutil-*.el` — shared test fixtures and mocks
## Build & Test Commands
If the project has a Makefile, document targets here. Common pattern:
```bash
make test # All tests
make test-file FILE=tests/test-foo.el # One file
make test-name TEST=pattern # Match test names
make validate-parens # Balanced parens in modules
make validate-modules # Load all modules to verify they compile
make compile # Byte-compile (writes .elc)
make lint # checkdoc + package-lint + elisp-lint
```
Alternative build tools: `eldev`, `cask`, or direct `emacs --batch` invocations.
## Language Rules
See rule files in `.claude/rules/`:
- `elisp.md` — code style and patterns
- `elisp-testing.md` — ERT conventions
- `verification.md` — verify-before-claim-done discipline
## Git Workflow
- Conventional commit prefixes: `feat:`, `fix:`, `refactor:`, `test:`, `docs:`, `chore:`
- Pre-commit hook in `githooks/` scans for secrets and runs `check-parens` on staged `.el` files
- Activate on fresh clone: `git config core.hooksPath githooks`
## Problem-Solving Approach
Investigate before fixing. When diagnosing a bug:
1. Read the relevant module and trace what actually happens
2. Identify the root cause, not a surface symptom
3. Write a failing test that captures the correct behavior
4. Fix, then re-run tests
## Testing Discipline
TDD is the default: write a failing test before any implementation. If you can't write the test, you don't yet understand the change. Details in `.claude/rules/elisp-testing.md`.
## Editing Discipline
A PostToolUse hook runs `check-parens` + `byte-compile-file` on every `.el` file after Edit/Write/MultiEdit. Byte-compile warnings (free variables, wrong argument counts) are signal — read them.
Prefer Write over cumulative Edits for nontrivial new code. Small functions (under 15 lines) are near-impossible to get wrong; deeply nested code is where paren errors hide.
## What Not to Do
- Don't add features beyond what was asked
- Don't refactor surrounding code when fixing a bug
- Don't add comments to code you didn't change
- Don't create abstractions for one-time operations
- Don't commit `.env` files, credentials, or API keys — pre-commit hook catches common patterns but isn't a substitute for care
|
