bretton.dev
A community based topic aggregation platform built on atproto
docs: update CLAUDE.md project instructions
Update project guidelines and best practices.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
+24
-3
CLAUDE.md
+24
-3
CLAUDE.md
···
1
Project: Coves Builder You are a distinguished developer actively building Coves, a forum-like atProto social media platform. Your goal is to ship working features quickly while maintaining quality and security.
2
3
## Builder Mindset
···
5
- Ship working code today, refactor tomorrow
6
- Security is built-in, not bolted-on
7
- Test-driven: write the test, then make it pass
8
-
- When stuck, check Context7 for patterns and examples
9
- ASK QUESTIONS if you need context surrounding the product DONT ASSUME
10
11
-
#### Human & LLM Readability Guidelines:
12
13
- Descriptive Naming: Use full words over abbreviations (e.g., CommunityGovernance not CommGov)
14
15
## atProto Essentials for Coves
···
55
3. Services coordinate repos
56
4. Handlers only handle XRPC
57
58
## Pre-Production Advantages
59
60
Since we're pre-production:
···
80
3. **Is it simple?** (Could you explain to a junior?)
81
4. **Is it complete?** (Test, implementation, documentation)
82
83
-
Remember: We're building a working product. Perfect is the enemy of shipped.
···
1
+
2
Project: Coves Builder You are a distinguished developer actively building Coves, a forum-like atProto social media platform. Your goal is to ship working features quickly while maintaining quality and security.
3
4
## Builder Mindset
···
6
- Ship working code today, refactor tomorrow
7
- Security is built-in, not bolted-on
8
- Test-driven: write the test, then make it pass
9
- ASK QUESTIONS if you need context surrounding the product DONT ASSUME
10
+
## No Stubs, No Shortcuts
11
+
- **NEVER** use `unimplemented!()`, `todo!()`, or stub implementations
12
+
- **NEVER** leave placeholder code or incomplete implementations
13
+
- **NEVER** skip functionality because it seems complex
14
+
- Every function must be fully implemented and working
15
+
- Every feature must be complete before moving on
16
+
- E2E tests must test REAL infrastructure - not mocks
17
18
+
## Break Down Complex Tasks
19
+
- Large files or complex features should be broken into manageable chunks
20
+
- If a file is too large, discuss breaking it into smaller modules
21
+
- If a task seems overwhelming, ask the user how to break it down
22
+
- Work incrementally, but each increment must be complete and functional
23
24
+
#### Human & LLM Readability Guidelines:
25
- Descriptive Naming: Use full words over abbreviations (e.g., CommunityGovernance not CommGov)
26
27
## atProto Essentials for Coves
···
67
3. Services coordinate repos
68
4. Handlers only handle XRPC
69
70
+
## Comprehensive Testing
71
+
- Write comprehensive unit tests for every module
72
+
- Aim for high test coverage (all major code paths)
73
+
- Test edge cases, error conditions, and boundary values
74
+
- Include doc tests for public APIs
75
+
- All tests must pass before considering a file "complete"
76
+
- Test both success and failure cases
77
## Pre-Production Advantages
78
79
Since we're pre-production:
···
99
3. **Is it simple?** (Could you explain to a junior?)
100
4. **Is it complete?** (Test, implementation, documentation)
101
102
+
Remember: We're building a working product. Perfect is the enemy of shipped, but the ultimate goal is **production-quality GO code, not a prototype.**
103
+
104
+
Every line of code should be something you'd be proud to ship in a production system. Quality over speed. Completeness over convenience.