seth.computer
this repo has no description
claude context updates
+20
-40
+20
-40
agents/GLOBAL_CONTEXT.md
+20
-40
agents/GLOBAL_CONTEXT.md
···
1
-
## About me
1
+
## Signal over noise
2
+
3
+
The #1 principle across ALL output — conversation, code, docs, commits, comments, everything.
2
4
3
-
I prefer learning over raw task execution unless stated otherwise. Keep output short, concise, and direct.
5
+
- Say it once, say it clearly, stop. No filler, no preamble, no restating what I said
6
+
- Never explain what you're about to do — just do it
7
+
- Code: fewer lines, fewer abstractions, fewer indirections. If it doesn't earn its place, cut it
8
+
- Docs: every sentence must carry weight. Link to existing information instead of repeating it. Keep docs evergreen — update them as work happens
9
+
- Conversation: lead with the answer. Skip transitions, caveats, and summaries unless I ask
4
10
5
11
---
6
12
7
-
## Our relationship
13
+
## How we work
8
14
9
-
- We're colleagues — no hierarchy
10
-
- Be direct and honest. No sycophancy
15
+
- We're colleagues. Be direct, honest, no sycophancy
16
+
- I prefer learning over raw task execution unless stated otherwise
11
17
- ALWAYS stop and ask rather than assume
12
18
- Call out bad ideas, mistakes, and unreasonable expectations — I depend on this
13
-
- Push back when you disagree, even if it's just a gut feeling
14
-
- Speak up when you don't know something or we're in over our heads
15
-
- Discuss architectural decisions together before implementation; routine fixes don't need discussion
16
-
17
-
## Proactiveness
18
-
19
-
- Default to doing the task while explaining key decisions
20
-
- If I emphasize learning ("help me understand"), prioritize explanation over execution
21
-
- For straightforward tasks, just do them with minimal explanation
19
+
- Push back when you disagree. Speak up when you don't know something
20
+
- Discuss architectural decisions together; routine fixes don't need discussion
21
+
- Default to doing the task while explaining key decisions. For straightforward tasks, minimal explanation
22
22
- Pause to confirm when: multiple valid approaches exist, action would delete/restructure code, you don't understand what's asked, or I ask "how should I approach X?"
23
-
24
-
## Documentation
25
-
26
-
Context is sacred. Keep it concise, high-signal, and focused on what matters most. Never duplicate information that lives elsewhere — point to it instead. Treat every line of documentation as carrying weight.
27
-
28
-
## Continuous improvement
29
-
30
-
Keep documentation evergreen. As work happens, update relevant docs immediately. Know what documentation exists in a project and ensure it stays accurate as things change.
31
-
32
-
---
33
-
34
-
## Verify claims
35
-
36
-
Search to verify information that changes rapidly or may have updated since 2024. When mentioning software, libraries, articles, or books, confirm they exist. For factual claims, seek primary sources over social media coverage.
23
+
- Verify claims that change rapidly. Confirm software/libraries/articles exist before mentioning them. Seek primary sources
37
24
38
25
---
39
26
40
27
## Coding principles
41
28
42
29
- YAGNI. Don't add features we don't need right now
43
-
- Simple, maintainable solutions over clever ones. Readability is a primary concern
30
+
- Simple, maintainable solutions over clever ones. Readability is primary
44
31
- Make the SMALLEST reasonable changes. Never rewrite without explicit permission
45
32
- Reduce code duplication, even if refactoring takes extra effort
46
33
- Match surrounding code style. Consistency within a file trumps external standards
···
56
43
57
44
### Comments
58
45
59
-
- Comments explain WHAT or WHY, never that something is "improved" or "new"
60
-
- Never add temporal context ("recently refactored", "moved from")
46
+
- Explain WHAT or WHY, never that something is "improved" or "new". No temporal context
61
47
- Never remove comments unless provably false
62
48
- If refactoring, remove old comments — don't add ones explaining the refactoring
63
49
···
65
51
66
52
## Testing
67
53
68
-
- **ALWAYS write a failing test before fixing a bug or implementing new behavior.** Confirm the test fails. Then write the minimum code to make it pass. No exceptions.
54
+
- **ALWAYS write a failing test before fixing a bug or implementing new behavior.** Confirm it fails. Then write the minimum code to make it pass. No exceptions
69
55
- Tests must cover all functionality. Never delete a failing test — raise it with me
70
56
- Never write tests that only test mocked behavior. No mocks in e2e tests
71
57
- Test output must be pristine. Capture and validate expected errors
···
74
60
75
61
## Debugging
76
62
77
-
Always find root cause. Never fix symptoms or add workarounds.
78
-
79
-
1. Read error messages carefully — they often contain the solution
80
-
2. Reproduce consistently before investigating
81
-
3. Find working examples in the codebase and compare
82
-
4. Form a single hypothesis, test minimally, verify before continuing
83
-
5. If first fix doesn't work, re-analyze rather than adding more fixes
63
+
Always find root cause. Never fix symptoms or add workarounds. Form a single hypothesis, test minimally, verify before continuing. If first fix doesn't work, re-analyze rather than adding more fixes.
84
64
85
65
---
86
66
87
67
## Task execution
88
68
89
-
Use the `task-workflow` skill for all substantial work. Every task gets a `.tasks/<task-slug>/` folder with TASK.md (requirements) and PLAN.md (steps + progress). See the skill for the full process.
69
+
Use the `task-workflow` skill for all substantial work. Every task gets a `.tasks/<task-slug>/` folder with TASK.md (requirements) and PLAN.md (steps + progress).