omgkit 2.1.0 → 2.2.0
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.
- package/package.json +1 -1
- package/plugin/skills/SKILL_STANDARDS.md +743 -0
- package/plugin/skills/databases/mongodb/SKILL.md +797 -28
- package/plugin/skills/databases/postgresql/SKILL.md +494 -18
- package/plugin/skills/databases/prisma/SKILL.md +776 -30
- package/plugin/skills/databases/redis/SKILL.md +885 -25
- package/plugin/skills/devops/aws/SKILL.md +686 -28
- package/plugin/skills/devops/docker/SKILL.md +466 -18
- package/plugin/skills/devops/github-actions/SKILL.md +684 -29
- package/plugin/skills/devops/kubernetes/SKILL.md +621 -24
- package/plugin/skills/frameworks/django/SKILL.md +920 -20
- package/plugin/skills/frameworks/express/SKILL.md +1361 -35
- package/plugin/skills/frameworks/fastapi/SKILL.md +1260 -33
- package/plugin/skills/frameworks/laravel/SKILL.md +1244 -31
- package/plugin/skills/frameworks/nestjs/SKILL.md +1005 -26
- package/plugin/skills/frameworks/nextjs/SKILL.md +407 -44
- package/plugin/skills/frameworks/rails/SKILL.md +594 -28
- package/plugin/skills/frameworks/react/SKILL.md +1006 -32
- package/plugin/skills/frameworks/spring/SKILL.md +528 -35
- package/plugin/skills/frameworks/vue/SKILL.md +1296 -27
- package/plugin/skills/frontend/accessibility/SKILL.md +1108 -34
- package/plugin/skills/frontend/frontend-design/SKILL.md +1304 -26
- package/plugin/skills/frontend/responsive/SKILL.md +847 -21
- package/plugin/skills/frontend/shadcn-ui/SKILL.md +976 -38
- package/plugin/skills/frontend/tailwindcss/SKILL.md +831 -35
- package/plugin/skills/frontend/threejs/SKILL.md +1298 -29
- package/plugin/skills/languages/javascript/SKILL.md +935 -31
- package/plugin/skills/languages/python/SKILL.md +489 -25
- package/plugin/skills/languages/typescript/SKILL.md +379 -30
- package/plugin/skills/methodology/brainstorming/SKILL.md +597 -23
- package/plugin/skills/methodology/defense-in-depth/SKILL.md +832 -34
- package/plugin/skills/methodology/dispatching-parallel-agents/SKILL.md +665 -31
- package/plugin/skills/methodology/executing-plans/SKILL.md +556 -24
- package/plugin/skills/methodology/finishing-development-branch/SKILL.md +595 -25
- package/plugin/skills/methodology/problem-solving/SKILL.md +429 -61
- package/plugin/skills/methodology/receiving-code-review/SKILL.md +536 -24
- package/plugin/skills/methodology/requesting-code-review/SKILL.md +632 -21
- package/plugin/skills/methodology/root-cause-tracing/SKILL.md +641 -30
- package/plugin/skills/methodology/sequential-thinking/SKILL.md +262 -3
- package/plugin/skills/methodology/systematic-debugging/SKILL.md +571 -32
- package/plugin/skills/methodology/test-driven-development/SKILL.md +779 -24
- package/plugin/skills/methodology/testing-anti-patterns/SKILL.md +691 -29
- package/plugin/skills/methodology/token-optimization/SKILL.md +598 -29
- package/plugin/skills/methodology/verification-before-completion/SKILL.md +543 -22
- package/plugin/skills/methodology/writing-plans/SKILL.md +590 -18
- package/plugin/skills/omega/omega-architecture/SKILL.md +838 -39
- package/plugin/skills/omega/omega-coding/SKILL.md +636 -39
- package/plugin/skills/omega/omega-sprint/SKILL.md +855 -48
- package/plugin/skills/omega/omega-testing/SKILL.md +940 -41
- package/plugin/skills/omega/omega-thinking/SKILL.md +703 -50
- package/plugin/skills/security/better-auth/SKILL.md +1065 -28
- package/plugin/skills/security/oauth/SKILL.md +968 -31
- package/plugin/skills/security/owasp/SKILL.md +894 -33
- package/plugin/skills/testing/playwright/SKILL.md +764 -38
- package/plugin/skills/testing/pytest/SKILL.md +873 -36
- package/plugin/skills/testing/vitest/SKILL.md +980 -35
|
@@ -1,61 +1,658 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: omega-coding
|
|
3
|
-
description: AI-first development patterns
|
|
3
|
+
description: AI-first development patterns with prompt engineering, specification-driven generation, and leverage multiplication
|
|
4
|
+
category: omega
|
|
5
|
+
triggers:
|
|
6
|
+
- omega coding
|
|
7
|
+
- ai-first development
|
|
8
|
+
- ai assisted coding
|
|
9
|
+
- prompt driven
|
|
10
|
+
- leverage multiplication
|
|
11
|
+
- ai development
|
|
4
12
|
---
|
|
5
13
|
|
|
6
|
-
# Omega Coding
|
|
14
|
+
# Omega Coding
|
|
7
15
|
|
|
8
|
-
|
|
16
|
+
Master **AI-first development** patterns that multiply your productivity 10-100x. This skill teaches specification-driven code generation, strategic prompt engineering, and systematic leverage of AI capabilities.
|
|
9
17
|
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
-
|
|
13
|
-
|
|
14
|
-
-
|
|
18
|
+
## Purpose
|
|
19
|
+
|
|
20
|
+
Transform development velocity through AI-human collaboration:
|
|
21
|
+
|
|
22
|
+
- Design specifications that generate perfect code
|
|
23
|
+
- Leverage AI for 10-100x productivity gains
|
|
24
|
+
- Build iterative refinement workflows
|
|
25
|
+
- Maintain quality through systematic verification
|
|
26
|
+
- Scale individual capabilities exponentially
|
|
27
|
+
- Apply the Omega principles to development
|
|
28
|
+
|
|
29
|
+
## Features
|
|
30
|
+
|
|
31
|
+
### 1. The Omega Principles in Code
|
|
15
32
|
|
|
16
|
-
### 2. Prompt-Driven Development
|
|
17
33
|
```markdown
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
34
|
+
## The 7 Omega Principles Applied to Development
|
|
35
|
+
|
|
36
|
+
### Ω1: Leverage Multiplication
|
|
37
|
+
```
|
|
38
|
+
Traditional: 1 developer = 1 feature/day
|
|
39
|
+
Omega: 1 developer + AI = 10-50 features/day
|
|
40
|
+
|
|
41
|
+
Leverage calculation:
|
|
42
|
+
- Manual coding: 4 hours/feature
|
|
43
|
+
- AI-assisted: 15 minutes/feature
|
|
44
|
+
- Leverage multiplier: 16x
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
**Application:**
|
|
48
|
+
- Use AI for repetitive code generation
|
|
49
|
+
- Automate boilerplate creation
|
|
50
|
+
- Generate tests from implementations
|
|
51
|
+
- Create documentation automatically
|
|
52
|
+
|
|
53
|
+
### Ω2: Transcendent Abstraction
|
|
54
|
+
Instead of solving one problem, solve the class of problems.
|
|
55
|
+
|
|
56
|
+
```typescript
|
|
57
|
+
// Level 1: Solve one problem
|
|
58
|
+
function validateEmail(email: string): boolean {
|
|
59
|
+
return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
|
|
60
|
+
}
|
|
61
|
+
|
|
62
|
+
// Level 2: Solve the class (Omega approach)
|
|
63
|
+
function createValidator<T>(
|
|
64
|
+
rules: ValidationRule<T>[]
|
|
65
|
+
): (value: T) => ValidationResult {
|
|
66
|
+
return (value: T) => {
|
|
67
|
+
const errors = rules
|
|
68
|
+
.filter(rule => !rule.validate(value))
|
|
69
|
+
.map(rule => rule.message);
|
|
70
|
+
return { valid: errors.length === 0, errors };
|
|
71
|
+
};
|
|
72
|
+
}
|
|
73
|
+
|
|
74
|
+
// Now email validation is just one instance:
|
|
75
|
+
const validateEmail = createValidator([
|
|
76
|
+
{ validate: v => typeof v === 'string', message: 'Must be string' },
|
|
77
|
+
{ validate: v => v.includes('@'), message: 'Must contain @' },
|
|
78
|
+
{ validate: v => v.length <= 254, message: 'Too long' },
|
|
79
|
+
]);
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
### Ω3: Agentic Decomposition
|
|
83
|
+
Break work into autonomous, specialist agents.
|
|
84
|
+
|
|
85
|
+
```yaml
|
|
86
|
+
# Omega development workflow
|
|
87
|
+
agents:
|
|
88
|
+
architect:
|
|
89
|
+
role: Design system structure
|
|
90
|
+
output: Architecture document
|
|
91
|
+
|
|
92
|
+
implementer:
|
|
93
|
+
role: Write production code
|
|
94
|
+
input: Architecture + specs
|
|
95
|
+
output: Implementation
|
|
96
|
+
|
|
97
|
+
tester:
|
|
98
|
+
role: Write and run tests
|
|
99
|
+
input: Implementation
|
|
100
|
+
output: Test results + coverage
|
|
101
|
+
|
|
102
|
+
reviewer:
|
|
103
|
+
role: Code review and quality
|
|
104
|
+
input: Implementation + tests
|
|
105
|
+
output: Review comments
|
|
106
|
+
|
|
107
|
+
documenter:
|
|
108
|
+
role: Generate documentation
|
|
109
|
+
input: Implementation
|
|
110
|
+
output: API docs + guides
|
|
22
111
|
```
|
|
23
112
|
|
|
24
|
-
###
|
|
113
|
+
### Ω4: Autonomous Operation
|
|
114
|
+
Systems should self-correct and self-improve.
|
|
115
|
+
|
|
116
|
+
```typescript
|
|
117
|
+
// Self-healing code pattern
|
|
118
|
+
async function withRetryAndFallback<T>(
|
|
119
|
+
primary: () => Promise<T>,
|
|
120
|
+
fallback: () => Promise<T>,
|
|
121
|
+
options: { maxRetries: number; backoff: number }
|
|
122
|
+
): Promise<T> {
|
|
123
|
+
for (let i = 0; i < options.maxRetries; i++) {
|
|
124
|
+
try {
|
|
125
|
+
return await primary();
|
|
126
|
+
} catch (error) {
|
|
127
|
+
await delay(options.backoff * Math.pow(2, i));
|
|
128
|
+
}
|
|
129
|
+
}
|
|
130
|
+
return fallback();
|
|
131
|
+
}
|
|
25
132
|
```
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
133
|
+
|
|
134
|
+
### Ω5: Zero-Marginal-Cost Scaling
|
|
135
|
+
Once built, serving N+1 costs nothing extra.
|
|
136
|
+
|
|
137
|
+
```typescript
|
|
138
|
+
// Build reusable, scalable components
|
|
139
|
+
const ComponentLibrary = {
|
|
140
|
+
Button: createReusableComponent('Button'),
|
|
141
|
+
Input: createReusableComponent('Input'),
|
|
142
|
+
Modal: createReusableComponent('Modal'),
|
|
143
|
+
// Each component: built once, used infinite times
|
|
144
|
+
};
|
|
29
145
|
```
|
|
30
146
|
|
|
31
|
-
|
|
147
|
+
### Ω6: Recursive Self-Improvement
|
|
148
|
+
Code that improves itself.
|
|
149
|
+
|
|
150
|
+
```typescript
|
|
151
|
+
// Self-optimizing query builder
|
|
152
|
+
class QueryOptimizer {
|
|
153
|
+
private performanceHistory: QueryPerformance[] = [];
|
|
154
|
+
|
|
155
|
+
async executeQuery(query: string): Promise<Result> {
|
|
156
|
+
const startTime = Date.now();
|
|
157
|
+
const result = await this.db.query(query);
|
|
158
|
+
const duration = Date.now() - startTime;
|
|
159
|
+
|
|
160
|
+
// Learn from execution
|
|
161
|
+
this.performanceHistory.push({ query, duration });
|
|
162
|
+
|
|
163
|
+
// Suggest optimizations
|
|
164
|
+
if (duration > 100) {
|
|
165
|
+
const suggestions = this.analyzeAndSuggest(query);
|
|
166
|
+
console.log('Optimization suggestions:', suggestions);
|
|
167
|
+
}
|
|
168
|
+
|
|
169
|
+
return result;
|
|
170
|
+
}
|
|
171
|
+
}
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
### Ω7: Emergent Capabilities
|
|
175
|
+
Combined systems exceed sum of parts.
|
|
176
|
+
|
|
177
|
+
```typescript
|
|
178
|
+
// Compose simple functions into powerful pipelines
|
|
179
|
+
const processDocument = pipe(
|
|
180
|
+
parseMarkdown, // Simple parsing
|
|
181
|
+
extractEntities, // Simple extraction
|
|
182
|
+
enrichWithContext, // Simple enrichment
|
|
183
|
+
generateSummary, // Simple summary
|
|
184
|
+
// Together: powerful document understanding
|
|
185
|
+
);
|
|
186
|
+
```
|
|
187
|
+
```
|
|
188
|
+
|
|
189
|
+
### 2. Specification-Driven Development
|
|
32
190
|
|
|
33
|
-
### Specification First
|
|
34
191
|
```markdown
|
|
35
|
-
##
|
|
192
|
+
## The Perfect Specification Format
|
|
193
|
+
|
|
194
|
+
### Component Specification Template
|
|
195
|
+
```yaml
|
|
196
|
+
component:
|
|
197
|
+
name: UserAuthService
|
|
198
|
+
description: Handles user authentication and session management
|
|
199
|
+
version: 1.0.0
|
|
200
|
+
|
|
201
|
+
requirements:
|
|
202
|
+
functional:
|
|
203
|
+
- FR1: Users can register with email and password
|
|
204
|
+
- FR2: Users can login with credentials
|
|
205
|
+
- FR3: Users can logout and invalidate session
|
|
206
|
+
- FR4: Sessions expire after 24 hours
|
|
207
|
+
- FR5: Support password reset via email
|
|
208
|
+
|
|
209
|
+
non_functional:
|
|
210
|
+
- NFR1: Response time < 200ms
|
|
211
|
+
- NFR2: Support 10,000 concurrent users
|
|
212
|
+
- NFR3: 99.9% uptime
|
|
213
|
+
- NFR4: PCI-DSS compliant password handling
|
|
214
|
+
|
|
215
|
+
interface:
|
|
216
|
+
methods:
|
|
217
|
+
- name: register
|
|
218
|
+
input:
|
|
219
|
+
email: string (valid email format)
|
|
220
|
+
password: string (min 8 chars, 1 uppercase, 1 number)
|
|
221
|
+
output:
|
|
222
|
+
success: boolean
|
|
223
|
+
userId?: string
|
|
224
|
+
error?: { code: string, message: string }
|
|
36
225
|
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
226
|
+
- name: login
|
|
227
|
+
input:
|
|
228
|
+
email: string
|
|
229
|
+
password: string
|
|
230
|
+
output:
|
|
231
|
+
success: boolean
|
|
232
|
+
token?: string (JWT, expires 24h)
|
|
233
|
+
error?: { code: string, message: string }
|
|
40
234
|
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
235
|
+
- name: logout
|
|
236
|
+
input:
|
|
237
|
+
token: string
|
|
238
|
+
output:
|
|
239
|
+
success: boolean
|
|
44
240
|
|
|
45
|
-
|
|
46
|
-
-
|
|
47
|
-
-
|
|
241
|
+
dependencies:
|
|
242
|
+
- Database: PostgreSQL (users table)
|
|
243
|
+
- Cache: Redis (sessions)
|
|
244
|
+
- Email: SendGrid (password reset)
|
|
245
|
+
|
|
246
|
+
security:
|
|
247
|
+
- Passwords hashed with bcrypt (cost factor 12)
|
|
248
|
+
- JWT signed with RS256
|
|
249
|
+
- Rate limiting: 5 attempts per minute
|
|
250
|
+
- Secrets in environment variables
|
|
251
|
+
|
|
252
|
+
testing:
|
|
253
|
+
unit:
|
|
254
|
+
- Test password validation rules
|
|
255
|
+
- Test token generation
|
|
256
|
+
- Test session expiry
|
|
257
|
+
integration:
|
|
258
|
+
- Test registration flow
|
|
259
|
+
- Test login/logout flow
|
|
260
|
+
- Test password reset flow
|
|
261
|
+
edge_cases:
|
|
262
|
+
- Duplicate email registration
|
|
263
|
+
- Invalid credentials
|
|
264
|
+
- Expired session
|
|
265
|
+
- Concurrent login attempts
|
|
266
|
+
```
|
|
267
|
+
|
|
268
|
+
### Specification-to-Code Workflow
|
|
269
|
+
|
|
270
|
+
```markdown
|
|
271
|
+
## Step 1: Write Specification
|
|
272
|
+
Create complete spec with all requirements.
|
|
273
|
+
|
|
274
|
+
## Step 2: Generate Interface
|
|
275
|
+
Prompt: "Generate TypeScript interface from this spec: [spec]"
|
|
276
|
+
|
|
277
|
+
## Step 3: Generate Implementation
|
|
278
|
+
Prompt: "Implement [component] following this interface and spec: [spec]"
|
|
279
|
+
|
|
280
|
+
## Step 4: Generate Tests
|
|
281
|
+
Prompt: "Generate comprehensive tests for [component] covering: [test requirements]"
|
|
282
|
+
|
|
283
|
+
## Step 5: Verify and Iterate
|
|
284
|
+
- Run tests
|
|
285
|
+
- Fix any issues
|
|
286
|
+
- Add edge cases
|
|
287
|
+
- Document
|
|
48
288
|
```
|
|
289
|
+
```
|
|
290
|
+
|
|
291
|
+
### 3. Prompt Engineering for Code
|
|
292
|
+
|
|
293
|
+
```markdown
|
|
294
|
+
## Effective Code Prompts
|
|
295
|
+
|
|
296
|
+
### Template: Component Generation
|
|
297
|
+
```
|
|
298
|
+
Create a [COMPONENT_TYPE] component named [NAME] with the following:
|
|
299
|
+
|
|
300
|
+
Requirements:
|
|
301
|
+
- [Requirement 1]
|
|
302
|
+
- [Requirement 2]
|
|
303
|
+
- [Requirement 3]
|
|
304
|
+
|
|
305
|
+
Interface:
|
|
306
|
+
[Define inputs, outputs, methods]
|
|
307
|
+
|
|
308
|
+
Constraints:
|
|
309
|
+
- Language: TypeScript
|
|
310
|
+
- Style: Functional programming preferred
|
|
311
|
+
- Error handling: Return Result types
|
|
312
|
+
- Testing: Include unit tests
|
|
49
313
|
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
314
|
+
Example usage:
|
|
315
|
+
[Show how it should be called]
|
|
316
|
+
|
|
317
|
+
Do not:
|
|
318
|
+
- Use any deprecated APIs
|
|
319
|
+
- Include console.log in production code
|
|
320
|
+
- Hardcode configuration values
|
|
321
|
+
```
|
|
322
|
+
|
|
323
|
+
### Template: Refactoring Request
|
|
324
|
+
```
|
|
325
|
+
Refactor the following code to:
|
|
326
|
+
1. [Improvement 1]
|
|
327
|
+
2. [Improvement 2]
|
|
328
|
+
|
|
329
|
+
Current code:
|
|
330
|
+
[paste code]
|
|
331
|
+
|
|
332
|
+
Preserve:
|
|
333
|
+
- Existing functionality
|
|
334
|
+
- API compatibility
|
|
335
|
+
- Type signatures
|
|
336
|
+
|
|
337
|
+
Output:
|
|
338
|
+
- Refactored code
|
|
339
|
+
- Explanation of changes
|
|
340
|
+
- Any breaking changes (should be none)
|
|
341
|
+
```
|
|
342
|
+
|
|
343
|
+
### Template: Bug Fix Request
|
|
344
|
+
```
|
|
345
|
+
Fix the bug in this code:
|
|
346
|
+
|
|
347
|
+
Code:
|
|
348
|
+
[paste code]
|
|
349
|
+
|
|
350
|
+
Bug description:
|
|
351
|
+
[describe the issue]
|
|
352
|
+
|
|
353
|
+
Expected behavior:
|
|
354
|
+
[what should happen]
|
|
355
|
+
|
|
356
|
+
Actual behavior:
|
|
357
|
+
[what actually happens]
|
|
358
|
+
|
|
359
|
+
Provide:
|
|
360
|
+
1. Root cause analysis
|
|
361
|
+
2. Fixed code
|
|
362
|
+
3. Test to prevent regression
|
|
363
|
+
```
|
|
364
|
+
|
|
365
|
+
### Template: Test Generation
|
|
366
|
+
```
|
|
367
|
+
Generate comprehensive tests for:
|
|
368
|
+
|
|
369
|
+
Code:
|
|
370
|
+
[paste code]
|
|
371
|
+
|
|
372
|
+
Test framework: [Jest/Vitest/pytest]
|
|
373
|
+
|
|
374
|
+
Cover:
|
|
375
|
+
- Happy path scenarios
|
|
376
|
+
- Edge cases: [list specific]
|
|
377
|
+
- Error conditions: [list specific]
|
|
378
|
+
- Boundary conditions
|
|
379
|
+
|
|
380
|
+
Include:
|
|
381
|
+
- Descriptive test names
|
|
382
|
+
- Arrange-Act-Assert structure
|
|
383
|
+
- Mocks for external dependencies
|
|
384
|
+
```
|
|
385
|
+
```
|
|
386
|
+
|
|
387
|
+
### 4. Iterative Refinement Pattern
|
|
388
|
+
|
|
389
|
+
```typescript
|
|
390
|
+
// The Omega refinement loop
|
|
391
|
+
interface RefinementCycle {
|
|
392
|
+
generate: () => Code;
|
|
393
|
+
test: (code: Code) => TestResults;
|
|
394
|
+
analyze: (results: TestResults) => Issues[];
|
|
395
|
+
refine: (code: Code, issues: Issues[]) => Code;
|
|
396
|
+
}
|
|
397
|
+
|
|
398
|
+
async function omegaDevelopment(spec: Specification): Promise<Code> {
|
|
399
|
+
// Initial generation
|
|
400
|
+
let code = await generateFromSpec(spec);
|
|
401
|
+
let iteration = 0;
|
|
402
|
+
const maxIterations = 5;
|
|
403
|
+
|
|
404
|
+
while (iteration < maxIterations) {
|
|
405
|
+
// Test the code
|
|
406
|
+
const results = await runTests(code);
|
|
407
|
+
|
|
408
|
+
if (results.allPassing && results.coverage >= 80) {
|
|
409
|
+
console.log(`✓ Code complete after ${iteration + 1} iterations`);
|
|
410
|
+
return code;
|
|
411
|
+
}
|
|
412
|
+
|
|
413
|
+
// Analyze failures
|
|
414
|
+
const issues = analyzeResults(results);
|
|
415
|
+
|
|
416
|
+
// Refine code
|
|
417
|
+
code = await refineCode(code, issues);
|
|
418
|
+
iteration++;
|
|
419
|
+
}
|
|
420
|
+
|
|
421
|
+
throw new Error('Max iterations reached without passing tests');
|
|
422
|
+
}
|
|
423
|
+
|
|
424
|
+
// Example iteration log:
|
|
425
|
+
/*
|
|
426
|
+
Iteration 1:
|
|
427
|
+
- Generated: UserService with 5 methods
|
|
428
|
+
- Tests: 8/12 passing
|
|
429
|
+
- Issues: Missing null checks, incorrect date handling
|
|
430
|
+
- Refinement: Added null guards, fixed Date parsing
|
|
431
|
+
|
|
432
|
+
Iteration 2:
|
|
433
|
+
- Tests: 11/12 passing
|
|
434
|
+
- Issues: Edge case for empty input
|
|
435
|
+
- Refinement: Added empty input validation
|
|
436
|
+
|
|
437
|
+
Iteration 3:
|
|
438
|
+
- Tests: 12/12 passing
|
|
439
|
+
- Coverage: 85%
|
|
440
|
+
- Complete!
|
|
441
|
+
*/
|
|
442
|
+
```
|
|
443
|
+
|
|
444
|
+
### 5. Code Quality Patterns
|
|
445
|
+
|
|
446
|
+
```typescript
|
|
447
|
+
// Omega-quality code characteristics
|
|
448
|
+
|
|
449
|
+
// 1. Self-documenting with clear types
|
|
450
|
+
interface User {
|
|
451
|
+
id: UserId; // Branded type for type safety
|
|
452
|
+
email: Email; // Validated email type
|
|
453
|
+
createdAt: Timestamp; // Unix timestamp
|
|
454
|
+
status: UserStatus; // 'active' | 'suspended' | 'deleted'
|
|
455
|
+
}
|
|
456
|
+
|
|
457
|
+
// 2. Pure functions where possible
|
|
458
|
+
const calculateTotal = (items: LineItem[]): Money =>
|
|
459
|
+
items.reduce(
|
|
460
|
+
(sum, item) => sum.add(item.price.multiply(item.quantity)),
|
|
461
|
+
Money.zero()
|
|
462
|
+
);
|
|
463
|
+
|
|
464
|
+
// 3. Explicit error handling
|
|
465
|
+
type Result<T, E = Error> =
|
|
466
|
+
| { success: true; value: T }
|
|
467
|
+
| { success: false; error: E };
|
|
468
|
+
|
|
469
|
+
async function findUser(id: UserId): Promise<Result<User, NotFoundError>> {
|
|
470
|
+
const user = await db.users.find(id);
|
|
471
|
+
if (!user) {
|
|
472
|
+
return { success: false, error: new NotFoundError('User', id) };
|
|
473
|
+
}
|
|
474
|
+
return { success: true, value: user };
|
|
475
|
+
}
|
|
476
|
+
|
|
477
|
+
// 4. Composable building blocks
|
|
478
|
+
const pipeline = pipe(
|
|
479
|
+
validate,
|
|
480
|
+
transform,
|
|
481
|
+
enrich,
|
|
482
|
+
persist,
|
|
483
|
+
notify
|
|
484
|
+
);
|
|
485
|
+
|
|
486
|
+
// 5. Testable by design
|
|
487
|
+
class OrderService {
|
|
488
|
+
constructor(
|
|
489
|
+
private readonly repo: OrderRepository, // Injected
|
|
490
|
+
private readonly payment: PaymentGateway, // Injected
|
|
491
|
+
private readonly notifier: Notifier // Injected
|
|
492
|
+
) {}
|
|
493
|
+
|
|
494
|
+
// Each dependency can be mocked in tests
|
|
495
|
+
}
|
|
496
|
+
```
|
|
497
|
+
|
|
498
|
+
### 6. Leverage Multiplication Tactics
|
|
499
|
+
|
|
500
|
+
```markdown
|
|
501
|
+
## 10x Productivity Tactics
|
|
502
|
+
|
|
503
|
+
### Tactic 1: Generate, Don't Write
|
|
504
|
+
```
|
|
505
|
+
Instead of: Writing CRUD operations manually
|
|
506
|
+
Do: Generate from schema
|
|
507
|
+
|
|
508
|
+
Schema → API endpoints → Controllers → Services → Tests
|
|
509
|
+
All generated, all consistent, all in minutes.
|
|
510
|
+
```
|
|
511
|
+
|
|
512
|
+
### Tactic 2: Transform, Don't Recreate
|
|
513
|
+
```
|
|
514
|
+
Instead of: Building from scratch
|
|
515
|
+
Do: Transform existing code
|
|
516
|
+
|
|
517
|
+
"Convert this JavaScript to TypeScript with proper types"
|
|
518
|
+
"Add error handling to all async functions"
|
|
519
|
+
"Extract repeated code into reusable utilities"
|
|
520
|
+
```
|
|
521
|
+
|
|
522
|
+
### Tactic 3: Batch Operations
|
|
523
|
+
```
|
|
524
|
+
Instead of: One file at a time
|
|
525
|
+
Do: Process multiple files
|
|
526
|
+
|
|
527
|
+
"Add JSDoc comments to all exported functions in src/utils/"
|
|
528
|
+
"Update all React class components to functional components"
|
|
529
|
+
"Add input validation to all API route handlers"
|
|
530
|
+
```
|
|
531
|
+
|
|
532
|
+
### Tactic 4: Template Once, Generate Many
|
|
533
|
+
```yaml
|
|
534
|
+
# Define template once
|
|
535
|
+
template: api_endpoint
|
|
536
|
+
components:
|
|
537
|
+
- route_handler
|
|
538
|
+
- validation_schema
|
|
539
|
+
- service_method
|
|
540
|
+
- repository_method
|
|
541
|
+
- unit_tests
|
|
542
|
+
- integration_test
|
|
543
|
+
|
|
544
|
+
# Generate for each resource
|
|
545
|
+
resources:
|
|
546
|
+
- users
|
|
547
|
+
- products
|
|
548
|
+
- orders
|
|
549
|
+
- payments
|
|
550
|
+
|
|
551
|
+
# Result: 4 resources × 6 components = 24 files generated
|
|
552
|
+
```
|
|
553
|
+
|
|
554
|
+
### Tactic 5: Test-First Specification
|
|
555
|
+
```typescript
|
|
556
|
+
// Write the test first as a specification
|
|
557
|
+
describe('ShoppingCart', () => {
|
|
558
|
+
it('should add items and calculate total', () => {
|
|
559
|
+
const cart = new ShoppingCart();
|
|
560
|
+
cart.addItem({ id: '1', name: 'Widget', price: 10, quantity: 2 });
|
|
561
|
+
cart.addItem({ id: '2', name: 'Gadget', price: 25, quantity: 1 });
|
|
562
|
+
|
|
563
|
+
expect(cart.itemCount).toBe(3);
|
|
564
|
+
expect(cart.total).toBe(45);
|
|
565
|
+
});
|
|
566
|
+
|
|
567
|
+
it('should apply percentage discount', () => {
|
|
568
|
+
const cart = new ShoppingCart();
|
|
569
|
+
cart.addItem({ id: '1', name: 'Widget', price: 100, quantity: 1 });
|
|
570
|
+
cart.applyDiscount({ type: 'percentage', value: 10 });
|
|
571
|
+
|
|
572
|
+
expect(cart.total).toBe(90);
|
|
573
|
+
});
|
|
574
|
+
});
|
|
575
|
+
|
|
576
|
+
// Then generate implementation from tests
|
|
577
|
+
// "Implement ShoppingCart class to pass these tests"
|
|
578
|
+
```
|
|
579
|
+
```
|
|
580
|
+
|
|
581
|
+
## Use Cases
|
|
582
|
+
|
|
583
|
+
### Full Feature Development
|
|
584
|
+
|
|
585
|
+
```markdown
|
|
586
|
+
## Example: Building Authentication System
|
|
587
|
+
|
|
588
|
+
### Step 1: Specification
|
|
589
|
+
```yaml
|
|
590
|
+
feature: User Authentication
|
|
591
|
+
scope:
|
|
592
|
+
- Registration with email/password
|
|
593
|
+
- Login with JWT tokens
|
|
594
|
+
- Password reset flow
|
|
595
|
+
- Session management
|
|
596
|
+
```
|
|
597
|
+
|
|
598
|
+
### Step 2: Generate Architecture
|
|
599
|
+
Prompt: "Design a scalable authentication system architecture..."
|
|
600
|
+
Output: Component diagram, data flow, technology choices
|
|
601
|
+
|
|
602
|
+
### Step 3: Generate Data Models
|
|
603
|
+
Prompt: "Generate Prisma schema for auth system..."
|
|
604
|
+
Output: User, Session, PasswordReset models
|
|
605
|
+
|
|
606
|
+
### Step 4: Generate Services
|
|
607
|
+
Prompt: "Implement AuthService with registration, login, logout..."
|
|
608
|
+
Output: Complete service implementation
|
|
609
|
+
|
|
610
|
+
### Step 5: Generate API Routes
|
|
611
|
+
Prompt: "Create Express routes for auth endpoints..."
|
|
612
|
+
Output: Route handlers with validation
|
|
613
|
+
|
|
614
|
+
### Step 6: Generate Tests
|
|
615
|
+
Prompt: "Generate comprehensive tests for AuthService..."
|
|
616
|
+
Output: Unit and integration tests
|
|
617
|
+
|
|
618
|
+
### Step 7: Generate Documentation
|
|
619
|
+
Prompt: "Create OpenAPI spec for auth endpoints..."
|
|
620
|
+
Output: API documentation
|
|
621
|
+
|
|
622
|
+
Total time: 2 hours (vs. 2-3 days traditional)
|
|
623
|
+
```
|
|
56
624
|
|
|
57
625
|
## Best Practices
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
-
|
|
626
|
+
|
|
627
|
+
### Do's
|
|
628
|
+
|
|
629
|
+
- Write clear specifications before generating code
|
|
630
|
+
- Use iterative refinement (generate, test, improve)
|
|
631
|
+
- Leverage AI for repetitive tasks
|
|
632
|
+
- Verify generated code meets requirements
|
|
633
|
+
- Maintain human oversight for critical logic
|
|
634
|
+
- Build reusable templates and patterns
|
|
635
|
+
- Document prompts that work well
|
|
636
|
+
- Combine AI strengths with human judgment
|
|
637
|
+
- Start simple and add complexity
|
|
638
|
+
- Keep specifications updated
|
|
639
|
+
|
|
640
|
+
### Don'ts
|
|
641
|
+
|
|
642
|
+
- Don't trust generated code without verification
|
|
643
|
+
- Don't skip testing generated code
|
|
644
|
+
- Don't use AI for security-critical code without expert review
|
|
645
|
+
- Don't generate without clear requirements
|
|
646
|
+
- Don't ignore AI suggestions for improvement
|
|
647
|
+
- Don't lose the specification-code relationship
|
|
648
|
+
- Don't over-rely on AI for creative design
|
|
649
|
+
- Don't skip code review for AI-generated code
|
|
650
|
+
- Don't use outdated AI models for complex tasks
|
|
651
|
+
- Don't forget to understand generated code
|
|
652
|
+
|
|
653
|
+
## References
|
|
654
|
+
|
|
655
|
+
- [GitHub Copilot Best Practices](https://github.blog/2023-06-20-how-to-write-better-prompts-for-github-copilot/)
|
|
656
|
+
- [Prompt Engineering Guide](https://www.promptingguide.ai/)
|
|
657
|
+
- [AI-Assisted Software Development](https://arxiv.org/abs/2303.17580)
|
|
658
|
+
- [The Pragmatic Programmer](https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/)
|