You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CLAUDE.md
+67-8Lines changed: 67 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,10 +2,6 @@
2
2
3
3
**MANDATORY**: Act as principal-level engineer. Follow these guidelines exactly.
4
4
5
-
## CANONICAL REFERENCE
6
-
7
-
This is a reference to shared Socket standards. See `../socket-registry/CLAUDE.md` for canonical source.
8
-
9
5
## 👤 USER CONTEXT
10
6
11
7
-**Identify users by git credentials**: Extract name from git commit author, GitHub account, or context
@@ -19,14 +15,53 @@ This is a reference to shared Socket standards. See `../socket-registry/CLAUDE.m
19
15
20
16
**MANDATORY**: Review CLAUDE.md before any action. No exceptions.
21
17
18
+
- Before ANY structural refactor on a file >300 LOC: remove dead code, unused exports, unused imports first — commit that cleanup separately before the real work
19
+
- Multi-file changes: break into phases (≤5 files each), verify each phase before the next
20
+
- When pointed to existing code as a reference: study it before building — working code is a better spec than any description
21
+
- Work from raw error data, not theories — if a bug report has no error output, ask for it
22
+
- On "yes", "do it", or "go": execute immediately, no plan recap
23
+
22
24
## VERIFICATION PROTOCOL
23
25
24
26
**MANDATORY**: Before claiming any task is complete:
25
27
26
-
1. Test the solution end-to-end
27
-
2. Verify all changes work as expected
28
-
3. Run the actual commands to confirm functionality
29
-
4. Never claim "Done" without verification
28
+
1. Run the actual command — execute the script, run the test, check the output
29
+
2. State what you verified, not just "looks good"
30
+
3.**FORBIDDEN**: Claiming "Done" when any test output shows failures, or characterizing incomplete/broken work as complete
31
+
4. If type-check or lint is configured, run it and fix ALL errors before reporting done
32
+
5. Re-read every file modified; confirm nothing references something that no longer exists
33
+
34
+
## CONTEXT & EDIT SAFETY
35
+
36
+
- After 10+ messages: re-read any file before editing it — do not trust remembered contents
37
+
- Read files >500 LOC in chunks using offset/limit; never assume one read captured the whole file
38
+
- Before every edit: re-read the file. After every edit: re-read to confirm the change applied correctly
39
+
- When renaming anything, search separately for: direct calls, type references, string literals, dynamic imports, re-exports, test files — one grep is not enough
40
+
- Never fix a display/rendering problem by duplicating state — one source of truth, everything reads from it
41
+
42
+
## JUDGMENT PROTOCOL
43
+
44
+
- If the user's request is based on a misconception, say so before executing
45
+
- If you spot a bug adjacent to what was asked, flag it: "I also noticed X — want me to fix it?"
46
+
- You are a collaborator, not just an executor
47
+
48
+
## SCOPE PROTOCOL
49
+
50
+
- Do not add features, refactor, or make improvements beyond what was asked — band-aids when asked for band-aids
51
+
- Try the simplest approach first; if architecture is actually flawed, flag it and wait for approval before restructuring
52
+
- When asked to "make a plan," output only the plan — no code until given the go-ahead
53
+
54
+
## SELF-EVALUATION
55
+
56
+
- Before calling anything done: present two views — what a perfectionist would reject vs. what a pragmatist would ship — let the user decide
57
+
- After fixing a bug: explain why it happened and what category of bug it represents
58
+
- If a fix doesn't work after two attempts: stop, re-read the relevant section top-down, state where the mental model was wrong, propose something fundamentally different
59
+
- If asked to "step back" or "we're going in circles": drop everything, rethink from scratch
60
+
61
+
## HOUSEKEEPING
62
+
63
+
- Before risky changes: offer to checkpoint — "want me to commit before this?"
64
+
- If a file is getting unwieldy (>400 LOC): flag it — "this is big enough to cause pain — want me to split it?"
30
65
31
66
## Critical Rules
32
67
@@ -378,6 +413,7 @@ Socket CLI integrates with various third-party tools and services:
378
413
-**Array destructuring**: Use object notation `{ 0: key, 1: data }` instead of array destructuring `[key, data]`
379
414
-**Dynamic imports**: 🚨 FORBIDDEN - Never use dynamic imports (`await import()`). Always use static imports at the top of the file
380
415
-**Sorting**: 🚨 MANDATORY - Always sort lists, exports, and items in documentation headers alphabetically/alphanumerically for consistency
416
+
-**Comment policy**: Default to NO comments. Only add one when the WHY is non-obvious to a senior engineer reading the code cold
381
417
-**Comment placement**: Place comments on their own line, not to the right of code
382
418
-**Comment formatting**: Use fewer hyphens/dashes and prefer commas, colons, or semicolons for better readability
383
419
-**Await in loops**: When using `await` inside for-loops, sequential processing is acceptable when iterations depend on each other
@@ -424,6 +460,29 @@ Socket CLI integrates with various third-party tools and services:
424
460
-**Formatting**: Uses Oxfmt for code formatting with 2-space indentation
425
461
-**Line length**: Target 80 character line width where practical
426
462
463
+
### Completion Protocol
464
+
-**NEVER claim done with something 80% complete** — finish 100% before reporting
465
+
- When a multi-step change doesn't immediately show gains, commit and keep iterating — don't revert
466
+
- If one approach fails, fix forward: analyze why, adjust, rebuild, re-measure — not `git checkout`
467
+
- After EVERY code change: build, test, verify, commit. This is a single atomic unit
468
+
- Reverting is a last resort after exhausting forward fixes — and requires explicit user approval
469
+
470
+
### File System as State
471
+
The file system is working memory. Use it actively:
472
+
- Write intermediate results and analysis to files in `.claude/`
473
+
- Use `.claude/` for plans, status tracking, and cross-session context
474
+
- When debugging, save logs and outputs to files for reproducible verification
475
+
- Don't hold large analysis in context — write it down, reference it later
476
+
477
+
### Self-Improvement
478
+
- After ANY correction from the user: log the pattern to memory so the same mistake is never repeated
479
+
- Convert mistakes into strict rules — don't just note them, enforce them
480
+
- After fixing a bug: explain why it happened and whether anything prevents that category of bug in the future
481
+
482
+
### Context Awareness
483
+
- Tool results over 50K characters are silently truncated — if search returns suspiciously few results, narrow scope and re-run
484
+
- For tasks touching >5 files: use sub-agents with worktree isolation to prevent context decay
0 commit comments