tlc-claude-code 1.5.7 → 1.5.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -2,6 +2,40 @@
|
|
|
2
2
|
|
|
3
3
|
Write failing tests, then implement to make them pass.
|
|
4
4
|
|
|
5
|
+
## Engineering Standards
|
|
6
|
+
|
|
7
|
+
**Code like a senior engineer with 15+ years experience.** Every line should reflect:
|
|
8
|
+
|
|
9
|
+
### Code Quality
|
|
10
|
+
- **Clean Architecture**: Separate concerns. Domain logic never depends on infrastructure.
|
|
11
|
+
- **SOLID Principles**: Single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion.
|
|
12
|
+
- **DRY but not premature**: Extract only after 3+ repetitions. Duplication is better than wrong abstraction.
|
|
13
|
+
- **Meaningful names**: Variables, functions, classes should reveal intent. No abbreviations except industry standards.
|
|
14
|
+
- **Small functions**: Each function does ONE thing. If you need comments to explain sections, extract them.
|
|
15
|
+
|
|
16
|
+
### Defensive Programming
|
|
17
|
+
- **Validate at boundaries**: All external input (user, API, file) gets validated immediately.
|
|
18
|
+
- **Fail fast**: Throw early with clear error messages. Don't let bad state propagate.
|
|
19
|
+
- **Handle edge cases**: null, undefined, empty arrays, empty strings, zero, negative numbers.
|
|
20
|
+
- **Type safety**: Use TypeScript strictly. No `any` except when interfacing with untyped libs.
|
|
21
|
+
|
|
22
|
+
### Performance Awareness
|
|
23
|
+
- **O(n) thinking**: Know the complexity of your algorithms. Avoid nested loops on large datasets.
|
|
24
|
+
- **Lazy loading**: Don't fetch/compute until needed.
|
|
25
|
+
- **Caching**: Identify expensive operations and cache appropriately.
|
|
26
|
+
- **Database queries**: No N+1. Use joins, batch operations, proper indexes.
|
|
27
|
+
|
|
28
|
+
### Security First
|
|
29
|
+
- **Never trust input**: Sanitize, escape, parameterize.
|
|
30
|
+
- **Least privilege**: Functions/modules only access what they need.
|
|
31
|
+
- **No secrets in code**: Environment variables for all credentials.
|
|
32
|
+
- **Audit trail**: Log security-relevant actions.
|
|
33
|
+
|
|
34
|
+
### Testability
|
|
35
|
+
- **Dependency injection**: Pass dependencies, don't import singletons.
|
|
36
|
+
- **Pure functions**: Same input = same output. No hidden state.
|
|
37
|
+
- **Mockable interfaces**: Code to interfaces, not implementations.
|
|
38
|
+
|
|
5
39
|
## What This Does
|
|
6
40
|
|
|
7
41
|
1. **Write failing tests** for all tasks in the phase
|
|
@@ -2,6 +2,26 @@
|
|
|
2
2
|
|
|
3
3
|
Research and create implementation plans with clear tasks.
|
|
4
4
|
|
|
5
|
+
## Architectural Standards
|
|
6
|
+
|
|
7
|
+
**Plan like a principal engineer designing for scale:**
|
|
8
|
+
|
|
9
|
+
### Structure
|
|
10
|
+
- **Layered architecture**: UI → Application → Domain → Infrastructure
|
|
11
|
+
- **Bounded contexts**: Group related functionality, minimize coupling
|
|
12
|
+
- **Dependency direction**: Always point inward (infrastructure depends on domain, never reverse)
|
|
13
|
+
|
|
14
|
+
### Design Decisions
|
|
15
|
+
- **Interface-first**: Define contracts before implementations
|
|
16
|
+
- **Extension points**: Where will this need to grow? Plan for it.
|
|
17
|
+
- **Error boundaries**: Where can failures occur? How are they handled?
|
|
18
|
+
- **Data flow**: How does data enter, transform, and exit the system?
|
|
19
|
+
|
|
20
|
+
### Task Breakdown
|
|
21
|
+
- **Vertical slices**: Each task delivers testable, visible progress
|
|
22
|
+
- **Risk-first**: Tackle unknowns and integrations early
|
|
23
|
+
- **Dependencies explicit**: Mark what blocks what
|
|
24
|
+
|
|
5
25
|
## What This Does
|
|
6
26
|
|
|
7
27
|
1. Researches how to implement the phase
|
|
@@ -2,6 +2,16 @@
|
|
|
2
2
|
|
|
3
3
|
For ad-hoc tasks that don't need full phase planning, but still deserve tests.
|
|
4
4
|
|
|
5
|
+
## Engineering Standards
|
|
6
|
+
|
|
7
|
+
Even quick tasks follow senior engineer standards:
|
|
8
|
+
- **Clean code**: Meaningful names, single responsibility, no magic values
|
|
9
|
+
- **Defensive**: Validate input, handle edge cases, fail fast
|
|
10
|
+
- **Secure**: No hardcoded secrets, sanitize user input
|
|
11
|
+
- **Testable**: Pure functions, injected dependencies
|
|
12
|
+
|
|
13
|
+
Quick doesn't mean sloppy. Every line should be production-ready.
|
|
14
|
+
|
|
5
15
|
## What This Does
|
|
6
16
|
|
|
7
17
|
1. **Ask what you want to do**
|
|
@@ -145,11 +145,35 @@ fi
|
|
|
145
145
|
2. **Invoke each configured provider** (one chunk at a time if split):
|
|
146
146
|
|
|
147
147
|
```bash
|
|
148
|
-
# For Codex (GPT-5.2) -
|
|
149
|
-
codex --print "
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
148
|
+
# For Codex (GPT-5.2) - detailed review prompt
|
|
149
|
+
codex --print "You are a senior code reviewer. Analyze this diff thoroughly:
|
|
150
|
+
|
|
151
|
+
1. **Line-by-line Analysis**: Comment on specific lines with issues
|
|
152
|
+
2. **Bugs**: Identify potential bugs, edge cases, null checks
|
|
153
|
+
3. **Security**: SQL injection, XSS, command injection, auth issues
|
|
154
|
+
4. **Performance**: N+1 queries, unnecessary loops, memory leaks
|
|
155
|
+
5. **Code Quality**: Naming, duplication, complexity, SOLID principles
|
|
156
|
+
6. **Test Coverage**: Are the changes properly tested?
|
|
157
|
+
|
|
158
|
+
For each issue found:
|
|
159
|
+
- File and line number
|
|
160
|
+
- Severity (critical/high/medium/low)
|
|
161
|
+
- What's wrong
|
|
162
|
+
- How to fix it
|
|
163
|
+
|
|
164
|
+
End with: APPROVED (no critical/high issues) or CHANGES_REQUESTED (has critical/high issues)
|
|
165
|
+
|
|
166
|
+
File: /tmp/review-diff.patch"
|
|
167
|
+
|
|
168
|
+
# For Gemini - detailed review prompt
|
|
169
|
+
gemini --print "Review this code diff as a senior engineer. Provide:
|
|
170
|
+
- Specific line-by-line feedback
|
|
171
|
+
- Security vulnerabilities with file:line references
|
|
172
|
+
- Performance concerns
|
|
173
|
+
- Code quality issues
|
|
174
|
+
- Missing test coverage
|
|
175
|
+
|
|
176
|
+
Be thorough and specific. File: /tmp/review-diff.patch"
|
|
153
177
|
```
|
|
154
178
|
|
|
155
179
|
**Large Diff Handling:**
|
|
@@ -2,6 +2,18 @@
|
|
|
2
2
|
|
|
3
3
|
One command. Context-aware. Visual dashboard.
|
|
4
4
|
|
|
5
|
+
## Engineering Mindset
|
|
6
|
+
|
|
7
|
+
**All TLC code generation follows senior engineer standards:**
|
|
8
|
+
- Clean architecture with separated concerns
|
|
9
|
+
- SOLID principles strictly applied
|
|
10
|
+
- Defensive programming with validation at boundaries
|
|
11
|
+
- Performance-aware (O(n) thinking, no N+1 queries)
|
|
12
|
+
- Security-first (no secrets in code, sanitize all input)
|
|
13
|
+
- Fully testable (dependency injection, pure functions)
|
|
14
|
+
|
|
15
|
+
See `/tlc:build` for the complete engineering standards checklist.
|
|
16
|
+
|
|
5
17
|
## What This Does
|
|
6
18
|
|
|
7
19
|
Launches the TLC dashboard - a visual interface showing project state, phases, tests, and next actions.
|