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
|
# CLAUDE.md
## Project
Describe this project: what it is, its layout, and its conventions. This
default was seeded by `install-lang` because the installed bundle ships no
language-specific CLAUDE.md — it deliberately names no language, so replace
this section with an accurate description rather than inheriting a wrong one.
**Typical layout (edit to match):**
- entry points — the file(s) that run first
- source directories — where the real code lives
- tests — beside the code, or under a `tests/` tree
## Build & Test Commands
If the project has a Makefile, document its targets here. A common shape:
```bash
make test # run the test suite
make lint # run the linter / formatter check
make build # build the project
```
Otherwise, document the direct commands a contributor runs to test and build.
## Language Rules
Shared rules live in `.claude/rules/` (installed from `claude-rules/`):
- `commits.md` — author identity, no AI attribution, message format
- `testing.md` — TDD discipline and test-quality standards
- `verification.md` — verify-before-claim-done discipline
If a language bundle was installed, its own rule files (code style, testing
conventions) sit alongside these in `.claude/rules/`.
## Git Workflow
Commit conventions: see `.claude/rules/commits.md`.
If a `githooks/` pre-commit hook was installed, activate it on a fresh clone
with `git config core.hooksPath githooks`.
## Problem-Solving Approach
Investigate before fixing. When diagnosing a bug:
1. Read the relevant code 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/testing.md`.
## 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 credentials or API keys
|
