work-in-progress atproto PDS
typescript
atproto
pds
atcute
chore: update CLAUDE.md
+25
-10
+25
-10
CLAUDE.md
+25
-10
CLAUDE.md
···
26
26
(e.g., when passing the method as a callback that needs `this` binding)
27
27
- use braces for control statements, even single-line bodies
28
28
- use bare blocks `{ }` to group related code and limit variable scope
29
+
- prefer `switch` over `if`/`else if` chains when branching on a single discriminant value
29
30
- avoid barrel exports (index files that re-export from other modules); import directly from source
30
31
- use `// #region <name>` and `// #endregion` to denote regions when a file needs to contain a lot
31
32
of code
···
38
39
it does error, prefer finding a solution that satisfies the type system naturally before resorting
39
40
to an assertion
40
41
42
+
### commit workflow
43
+
44
+
we use conventional commits with these rules:
45
+
46
+
- accepted types: `feat`, `fix`, `refactor`, `docs`, `chore`
47
+
- docs
48
+
- Markdown document changes (README.md and similar)
49
+
- chore
50
+
- build/tooling/dependency changes
51
+
- test-only changes
52
+
- mass-autofixes from linters and formatters
53
+
- no scopes; write `feat: ...` / `refactor: ...`, never `feat(runtime): ...`
54
+
- append `!` after the type to mark breaking changes, e.g. `feat!:` or `refactor!:`
55
+
56
+
granularity — each commit should represent one logical change:
57
+
58
+
- split distinct changes into separate commits rather than bundling them
59
+
- pair each README update with the commit it documents, rather than batching doc updates across
60
+
multiple changes
61
+
41
62
### documentation
42
63
43
64
- documentations include README, code comments, commit messages
···
63
84
pause and ask for clarification when you're still unsure after looking into it
64
85
- in plan mode, present the plan for review before exiting to allow for feedback or follow-up
65
86
questions
66
-
- when debugging problems, isolate the root cause first before attempting fixes; suggest adding
67
-
logging and let the user reproduce and share the output, unless you can verify directly (e.g., by
68
-
running tests or reading existing error output)
69
-
70
-
### Claude Code-specific
71
-
72
-
- Explore subagent may not be accurate; verify findings as needed
73
-
- only spawn subagents when there is genuine independent work to parallelize (e.g. searching across
74
-
many files, answering a question requiring broad exploration.) never use them as file I/O proxies
75
-
— read files directly in the main context, and prefer direct tool calls when they suffice.
87
+
- when debugging problems, isolate the root cause first before attempting fixes: add logging,
88
+
reproduce the issue, narrow down the scope, and confirm the exact source of the problem
89
+
- exploration results done by subagents/subtasks may not be accurate; verify findings as needed
90
+
- do not use subagents/subtasks as file I/O proxies ("read and return the file contents")