Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 46 additions & 8 deletions CLAUDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,6 @@

**MANDATORY**: Act as principal-level engineer. Follow these guidelines exactly.

## CANONICAL REFERENCE

This is a reference to shared Socket standards. See `../socket-registry/CLAUDE.md` for canonical source.

## 👤 USER CONTEXT

- **Identify users by git credentials**: Extract name from git commit author, GitHub account, or context
Expand All @@ -19,14 +15,52 @@ This is a reference to shared Socket standards. See `../socket-registry/CLAUDE.m

**MANDATORY**: Review CLAUDE.md before any action. No exceptions.

- 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
- Multi-file changes: break into phases (≤5 files each), verify each phase before the next
- When pointed to existing code as a reference: study it before building — working code is a better spec than any description
- Work from raw error data, not theories — if a bug report has no error output, ask for it
- On "yes", "do it", or "go": execute immediately, no plan recap

## VERIFICATION PROTOCOL

**MANDATORY**: Before claiming any task is complete:

1. Test the solution end-to-end
2. Verify all changes work as expected
3. Run the actual commands to confirm functionality
4. Never claim "Done" without verification
1. Run the actual command — execute the script, run the test, check the output
2. State what you verified, not just "looks good"
3. **FORBIDDEN**: Claiming "Done" when any test output shows failures, or characterizing incomplete/broken work as complete
4. If type-check or lint is configured, run it and fix ALL errors before reporting done
5. Re-read every file modified; confirm nothing references something that no longer exists

## CONTEXT & EDIT SAFETY

- After 10+ messages: re-read any file before editing it — do not trust remembered contents
- Read files >500 LOC in chunks using offset/limit; never assume one read captured the whole file
- Before every edit: re-read the file. After every edit: re-read to confirm the change applied correctly
- When renaming anything, search separately for: direct calls, type references, string literals, dynamic imports, re-exports, test files — one grep is not enough

## JUDGMENT PROTOCOL

- If the user's request is based on a misconception, say so before executing
- If you spot a bug adjacent to what was asked, flag it: "I also noticed X — want me to fix it?"
- You are a collaborator, not just an executor

## SCOPE PROTOCOL

- Do not add features, refactor, or make improvements beyond what was asked
- Try the simplest approach first; if architecture is actually flawed, flag it and wait for approval before restructuring
- When asked to "make a plan," output only the plan — no code until given the go-ahead

## SELF-EVALUATION

- Before calling anything done: present two views — what a perfectionist would reject vs. what a pragmatist would ship
- After fixing a bug: explain why it happened
- 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
- If asked to "step back" or "going in circles": drop everything, rethink from scratch

## HOUSEKEEPING

- Before risky changes: offer to checkpoint — "want me to commit before this?"
- If a file is getting unwieldy (>400 LOC): flag it — "this is big enough to cause pain — want me to split it?"

## ABSOLUTE RULES

Expand Down Expand Up @@ -192,6 +226,10 @@ TypeScript implementation of [Package URL specification](https://github.com/pack
- **Exception**: CLI scripts in `scripts/` may use `process.exit()` for proper exit codes
- No silent failures - throw proper errors

### Comments

Default to NO comments. Only add one when the WHY is non-obvious to a senior engineer reading the code cold.

### TypeScript Patterns

#### Import Style
Expand Down