omgkit 2.2.0 → 2.3.1
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/README.md +3 -3
- package/package.json +1 -1
- package/plugin/skills/databases/database-management/SKILL.md +288 -0
- package/plugin/skills/databases/database-migration/SKILL.md +285 -0
- package/plugin/skills/databases/database-schema-design/SKILL.md +195 -0
- package/plugin/skills/databases/mongodb/SKILL.md +60 -776
- package/plugin/skills/databases/prisma/SKILL.md +53 -744
- package/plugin/skills/databases/redis/SKILL.md +53 -860
- package/plugin/skills/databases/supabase/SKILL.md +283 -0
- package/plugin/skills/devops/aws/SKILL.md +68 -672
- package/plugin/skills/devops/github-actions/SKILL.md +54 -657
- package/plugin/skills/devops/kubernetes/SKILL.md +67 -602
- package/plugin/skills/devops/performance-profiling/SKILL.md +59 -863
- package/plugin/skills/frameworks/django/SKILL.md +87 -853
- package/plugin/skills/frameworks/express/SKILL.md +95 -1301
- package/plugin/skills/frameworks/fastapi/SKILL.md +90 -1198
- package/plugin/skills/frameworks/laravel/SKILL.md +87 -1187
- package/plugin/skills/frameworks/nestjs/SKILL.md +106 -973
- package/plugin/skills/frameworks/react/SKILL.md +94 -962
- package/plugin/skills/frameworks/vue/SKILL.md +95 -1242
- package/plugin/skills/frontend/accessibility/SKILL.md +91 -1056
- package/plugin/skills/frontend/frontend-design/SKILL.md +69 -1262
- package/plugin/skills/frontend/responsive/SKILL.md +76 -799
- package/plugin/skills/frontend/shadcn-ui/SKILL.md +73 -921
- package/plugin/skills/frontend/tailwindcss/SKILL.md +60 -788
- package/plugin/skills/frontend/threejs/SKILL.md +72 -1266
- package/plugin/skills/languages/javascript/SKILL.md +106 -849
- package/plugin/skills/methodology/brainstorming/SKILL.md +70 -576
- package/plugin/skills/methodology/defense-in-depth/SKILL.md +79 -831
- package/plugin/skills/methodology/dispatching-parallel-agents/SKILL.md +81 -654
- package/plugin/skills/methodology/executing-plans/SKILL.md +86 -529
- package/plugin/skills/methodology/finishing-development-branch/SKILL.md +95 -586
- package/plugin/skills/methodology/problem-solving/SKILL.md +67 -681
- package/plugin/skills/methodology/receiving-code-review/SKILL.md +70 -533
- package/plugin/skills/methodology/requesting-code-review/SKILL.md +70 -610
- package/plugin/skills/methodology/root-cause-tracing/SKILL.md +70 -646
- package/plugin/skills/methodology/sequential-thinking/SKILL.md +70 -478
- package/plugin/skills/methodology/systematic-debugging/SKILL.md +66 -559
- package/plugin/skills/methodology/test-driven-development/SKILL.md +91 -752
- package/plugin/skills/methodology/testing-anti-patterns/SKILL.md +78 -687
- package/plugin/skills/methodology/token-optimization/SKILL.md +72 -602
- package/plugin/skills/methodology/verification-before-completion/SKILL.md +108 -529
- package/plugin/skills/methodology/writing-plans/SKILL.md +79 -566
- package/plugin/skills/omega/omega-architecture/SKILL.md +91 -752
- package/plugin/skills/omega/omega-coding/SKILL.md +161 -552
- package/plugin/skills/omega/omega-sprint/SKILL.md +132 -777
- package/plugin/skills/omega/omega-testing/SKILL.md +157 -845
- package/plugin/skills/omega/omega-thinking/SKILL.md +165 -606
- package/plugin/skills/security/better-auth/SKILL.md +46 -1034
- package/plugin/skills/security/oauth/SKILL.md +80 -934
- package/plugin/skills/security/owasp/SKILL.md +78 -862
- package/plugin/skills/testing/playwright/SKILL.md +77 -700
- package/plugin/skills/testing/pytest/SKILL.md +73 -811
- package/plugin/skills/testing/vitest/SKILL.md +60 -920
- package/plugin/skills/tools/document-processing/SKILL.md +111 -838
- package/plugin/skills/tools/image-processing/SKILL.md +126 -659
- package/plugin/skills/tools/mcp-development/SKILL.md +85 -758
- package/plugin/skills/tools/media-processing/SKILL.md +118 -735
- package/plugin/stdrules/SKILL_STANDARDS.md +490 -0
- package/plugin/skills/SKILL_STANDARDS.md +0 -743
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: omega-
|
|
3
|
-
description: AI-first development patterns
|
|
2
|
+
name: coding-with-omega-leverage
|
|
3
|
+
description: Applies AI-first development patterns for 10-100x productivity through specification-driven generation and leverage multiplication. Use when developing features with AI assistance or optimizing development workflows.
|
|
4
4
|
category: omega
|
|
5
5
|
triggers:
|
|
6
6
|
- omega coding
|
|
@@ -8,651 +8,260 @@ triggers:
|
|
|
8
8
|
- ai assisted coding
|
|
9
9
|
- prompt driven
|
|
10
10
|
- leverage multiplication
|
|
11
|
-
- ai development
|
|
12
11
|
---
|
|
13
12
|
|
|
14
|
-
# Omega
|
|
13
|
+
# Coding with Omega Leverage
|
|
15
14
|
|
|
16
|
-
Master **AI-first development** patterns that multiply
|
|
15
|
+
Master **AI-first development** patterns that multiply productivity 10-100x through specification-driven generation and systematic AI collaboration.
|
|
17
16
|
|
|
18
|
-
##
|
|
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
|
|
32
|
-
|
|
33
|
-
```markdown
|
|
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.
|
|
17
|
+
## Quick Start
|
|
84
18
|
|
|
85
19
|
```yaml
|
|
86
|
-
#
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
input: Implementation + tests
|
|
105
|
-
output: Review comments
|
|
106
|
-
|
|
107
|
-
documenter:
|
|
108
|
-
role: Generate documentation
|
|
109
|
-
input: Implementation
|
|
110
|
-
output: API docs + guides
|
|
111
|
-
```
|
|
112
|
-
|
|
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
|
-
}
|
|
132
|
-
```
|
|
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
|
-
};
|
|
20
|
+
# 1. Write specification first
|
|
21
|
+
Spec:
|
|
22
|
+
Component: "UserAuthService"
|
|
23
|
+
Requirements: ["register", "login", "logout", "password-reset"]
|
|
24
|
+
Interface: { input: "email, password", output: "Result<User, AuthError>" }
|
|
25
|
+
|
|
26
|
+
# 2. Generate with iterative refinement
|
|
27
|
+
Workflow:
|
|
28
|
+
- Generate: "Implement UserAuthService from spec"
|
|
29
|
+
- Test: "Run tests, check coverage"
|
|
30
|
+
- Refine: "Fix issues, add edge cases"
|
|
31
|
+
- Verify: "All tests pass, 80%+ coverage"
|
|
32
|
+
|
|
33
|
+
# 3. Apply leverage multiplication
|
|
34
|
+
Leverage:
|
|
35
|
+
Manual: "4 hours/feature"
|
|
36
|
+
AI-Assisted: "15 minutes/feature"
|
|
37
|
+
Multiplier: "16x"
|
|
145
38
|
```
|
|
146
39
|
|
|
147
|
-
|
|
148
|
-
Code that improves itself.
|
|
40
|
+
## Features
|
|
149
41
|
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
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
|
-
}
|
|
42
|
+
| Feature | Description | Guide |
|
|
43
|
+
|---------|-------------|-------|
|
|
44
|
+
| 7 Omega Principles | Core development philosophy | Apply to every coding decision |
|
|
45
|
+
| Specification-Driven | Requirements before code | YAML/TypeScript specs |
|
|
46
|
+
| Prompt Engineering | Effective AI prompts for code | Templates for generation |
|
|
47
|
+
| Iterative Refinement | Generate, test, improve loop | Max 5 iterations to pass |
|
|
48
|
+
| Leverage Tactics | 10x productivity techniques | Batch, template, transform |
|
|
49
|
+
| Quality Patterns | Self-documenting, testable code | Types, pure functions, DI |
|
|
50
|
+
| Transform, Not Recreate | Modify existing code with AI | Refactor at scale |
|
|
168
51
|
|
|
169
|
-
|
|
170
|
-
}
|
|
171
|
-
}
|
|
172
|
-
```
|
|
52
|
+
## Common Patterns
|
|
173
53
|
|
|
174
|
-
###
|
|
175
|
-
Combined systems exceed sum of parts.
|
|
54
|
+
### The 7 Omega Principles in Code
|
|
176
55
|
|
|
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
56
|
```
|
|
57
|
+
1. LEVERAGE - 1 developer + AI = 10-50 features/day
|
|
58
|
+
2. ABSTRACTION - Solve classes of problems, not instances
|
|
59
|
+
3. AGENTIC - Autonomous, specialist agent teams
|
|
60
|
+
4. AUTONOMOUS - Self-correcting, self-healing code
|
|
61
|
+
5. ZERO-MARGINAL - Build once, use infinitely
|
|
62
|
+
6. RECURSIVE - Code that improves itself
|
|
63
|
+
7. EMERGENT - Compose simple parts into powerful wholes
|
|
187
64
|
```
|
|
188
65
|
|
|
189
|
-
###
|
|
66
|
+
### Specification Template
|
|
190
67
|
|
|
191
|
-
```markdown
|
|
192
|
-
## The Perfect Specification Format
|
|
193
|
-
|
|
194
|
-
### Component Specification Template
|
|
195
68
|
```yaml
|
|
196
69
|
component:
|
|
197
70
|
name: UserAuthService
|
|
198
|
-
description:
|
|
199
|
-
version: 1.0.0
|
|
71
|
+
description: Authentication and session management
|
|
200
72
|
|
|
201
73
|
requirements:
|
|
202
74
|
functional:
|
|
203
|
-
- FR1:
|
|
204
|
-
- FR2:
|
|
205
|
-
- FR3:
|
|
206
|
-
- FR4: Sessions expire after 24 hours
|
|
207
|
-
- FR5: Support password reset via email
|
|
208
|
-
|
|
75
|
+
- FR1: Register with email/password
|
|
76
|
+
- FR2: Login with credentials
|
|
77
|
+
- FR3: Logout and invalidate session
|
|
209
78
|
non_functional:
|
|
210
|
-
- NFR1: Response
|
|
211
|
-
- NFR2:
|
|
212
|
-
- NFR3: 99.9% uptime
|
|
213
|
-
- NFR4: PCI-DSS compliant password handling
|
|
79
|
+
- NFR1: Response < 200ms
|
|
80
|
+
- NFR2: PCI-DSS compliant
|
|
214
81
|
|
|
215
82
|
interface:
|
|
216
83
|
methods:
|
|
217
84
|
- name: register
|
|
218
|
-
input:
|
|
219
|
-
|
|
220
|
-
password: string (min 8 chars, 1 uppercase, 1 number)
|
|
221
|
-
output:
|
|
222
|
-
success: boolean
|
|
223
|
-
userId?: string
|
|
224
|
-
error?: { code: string, message: string }
|
|
225
|
-
|
|
85
|
+
input: { email: "string", password: "string (min 8 chars)" }
|
|
86
|
+
output: { success: boolean, userId?: string, error?: Error }
|
|
226
87
|
- name: login
|
|
227
|
-
input:
|
|
228
|
-
|
|
229
|
-
password: string
|
|
230
|
-
output:
|
|
231
|
-
success: boolean
|
|
232
|
-
token?: string (JWT, expires 24h)
|
|
233
|
-
error?: { code: string, message: string }
|
|
234
|
-
|
|
235
|
-
- name: logout
|
|
236
|
-
input:
|
|
237
|
-
token: string
|
|
238
|
-
output:
|
|
239
|
-
success: boolean
|
|
240
|
-
|
|
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
|
|
88
|
+
input: { email: "string", password: "string" }
|
|
89
|
+
output: { success: boolean, token?: "JWT 24h", error?: Error }
|
|
251
90
|
|
|
252
91
|
testing:
|
|
253
|
-
unit:
|
|
254
|
-
|
|
255
|
-
|
|
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
|
|
92
|
+
unit: [password validation, token generation]
|
|
93
|
+
integration: [registration flow, login flow]
|
|
94
|
+
edge_cases: [duplicate email, invalid credentials]
|
|
266
95
|
```
|
|
267
96
|
|
|
268
|
-
###
|
|
97
|
+
### Iterative Refinement Loop
|
|
269
98
|
|
|
270
|
-
```
|
|
271
|
-
|
|
272
|
-
|
|
99
|
+
```typescript
|
|
100
|
+
async function omegaDevelopment(spec: Specification): Promise<Code> {
|
|
101
|
+
let code = await generateFromSpec(spec);
|
|
102
|
+
let iteration = 0;
|
|
273
103
|
|
|
274
|
-
|
|
275
|
-
|
|
104
|
+
while (iteration < 5) {
|
|
105
|
+
const results = await runTests(code);
|
|
276
106
|
|
|
277
|
-
|
|
278
|
-
|
|
107
|
+
if (results.allPassing && results.coverage >= 80) {
|
|
108
|
+
return code; // Done!
|
|
109
|
+
}
|
|
279
110
|
|
|
280
|
-
|
|
281
|
-
|
|
111
|
+
const issues = analyzeResults(results);
|
|
112
|
+
code = await refineCode(code, issues);
|
|
113
|
+
iteration++;
|
|
114
|
+
}
|
|
282
115
|
|
|
283
|
-
|
|
284
|
-
|
|
285
|
-
|
|
286
|
-
|
|
287
|
-
|
|
288
|
-
|
|
116
|
+
throw new Error('Max iterations reached');
|
|
117
|
+
}
|
|
118
|
+
|
|
119
|
+
// Iteration log example:
|
|
120
|
+
// 1: 8/12 tests pass -> Fix null checks, date handling
|
|
121
|
+
// 2: 11/12 tests pass -> Add empty input validation
|
|
122
|
+
// 3: 12/12 tests, 85% coverage -> Complete!
|
|
289
123
|
```
|
|
290
124
|
|
|
291
|
-
###
|
|
125
|
+
### Prompt Templates
|
|
292
126
|
|
|
293
127
|
```markdown
|
|
294
|
-
##
|
|
295
|
-
|
|
296
|
-
### Template: Component Generation
|
|
297
|
-
```
|
|
298
|
-
Create a [COMPONENT_TYPE] component named [NAME] with the following:
|
|
128
|
+
## Component Generation
|
|
129
|
+
Create a [TYPE] component named [NAME] with:
|
|
299
130
|
|
|
300
131
|
Requirements:
|
|
301
|
-
- [
|
|
302
|
-
- [
|
|
303
|
-
- [Requirement 3]
|
|
132
|
+
- [Req 1]
|
|
133
|
+
- [Req 2]
|
|
304
134
|
|
|
305
135
|
Interface:
|
|
306
136
|
[Define inputs, outputs, methods]
|
|
307
137
|
|
|
308
138
|
Constraints:
|
|
309
139
|
- Language: TypeScript
|
|
310
|
-
- Style: Functional programming preferred
|
|
311
140
|
- Error handling: Return Result types
|
|
312
|
-
-
|
|
313
|
-
|
|
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
|
-
```
|
|
141
|
+
- Include unit tests
|
|
322
142
|
|
|
323
|
-
|
|
324
|
-
|
|
325
|
-
Refactor the following code to:
|
|
143
|
+
## Refactoring Request
|
|
144
|
+
Refactor this code to:
|
|
326
145
|
1. [Improvement 1]
|
|
327
146
|
2. [Improvement 2]
|
|
328
147
|
|
|
329
|
-
Current code:
|
|
330
|
-
[paste code]
|
|
148
|
+
Current code: [paste]
|
|
331
149
|
|
|
332
|
-
Preserve:
|
|
333
|
-
- Existing functionality
|
|
334
|
-
- API compatibility
|
|
335
|
-
- Type signatures
|
|
150
|
+
Preserve: functionality, API, types
|
|
336
151
|
|
|
337
|
-
|
|
338
|
-
- Refactored code
|
|
339
|
-
- Explanation of changes
|
|
340
|
-
- Any breaking changes (should be none)
|
|
341
|
-
```
|
|
342
|
-
|
|
343
|
-
### Template: Bug Fix Request
|
|
344
|
-
```
|
|
152
|
+
## Bug Fix Request
|
|
345
153
|
Fix the bug in this code:
|
|
346
154
|
|
|
347
|
-
Code:
|
|
348
|
-
[
|
|
349
|
-
|
|
350
|
-
|
|
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
|
-
```
|
|
155
|
+
Code: [paste]
|
|
156
|
+
Bug: [description]
|
|
157
|
+
Expected: [behavior]
|
|
158
|
+
Actual: [behavior]
|
|
364
159
|
|
|
365
|
-
|
|
160
|
+
Provide: root cause, fixed code, regression test
|
|
366
161
|
```
|
|
367
|
-
Generate comprehensive tests for:
|
|
368
162
|
|
|
369
|
-
|
|
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
|
|
163
|
+
### Leverage Multiplication Tactics
|
|
388
164
|
|
|
389
165
|
```typescript
|
|
390
|
-
//
|
|
391
|
-
|
|
392
|
-
|
|
393
|
-
test: (code: Code) => TestResults;
|
|
394
|
-
analyze: (results: TestResults) => Issues[];
|
|
395
|
-
refine: (code: Code, issues: Issues[]) => Code;
|
|
396
|
-
}
|
|
166
|
+
// Tactic 1: Generate, Don't Write
|
|
167
|
+
// Schema -> API -> Controllers -> Services -> Tests
|
|
168
|
+
// All generated, all consistent, all in minutes
|
|
397
169
|
|
|
398
|
-
|
|
399
|
-
|
|
400
|
-
|
|
401
|
-
let iteration = 0;
|
|
402
|
-
const maxIterations = 5;
|
|
170
|
+
// Tactic 2: Transform, Don't Recreate
|
|
171
|
+
// "Convert JavaScript to TypeScript with types"
|
|
172
|
+
// "Add error handling to all async functions"
|
|
403
173
|
|
|
404
|
-
|
|
405
|
-
|
|
406
|
-
|
|
174
|
+
// Tactic 3: Batch Operations
|
|
175
|
+
// "Add JSDoc to all exports in src/utils/"
|
|
176
|
+
// "Update all class components to functional"
|
|
407
177
|
|
|
408
|
-
|
|
409
|
-
|
|
410
|
-
|
|
411
|
-
|
|
412
|
-
|
|
413
|
-
|
|
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
|
-
}
|
|
178
|
+
// Tactic 4: Template Once, Generate Many
|
|
179
|
+
const template = {
|
|
180
|
+
components: ['route', 'validation', 'service', 'repository', 'tests']
|
|
181
|
+
};
|
|
182
|
+
const resources = ['users', 'products', 'orders'];
|
|
183
|
+
// Result: 3 resources x 5 components = 15 files generated
|
|
423
184
|
|
|
424
|
-
//
|
|
425
|
-
|
|
426
|
-
|
|
427
|
-
|
|
428
|
-
|
|
429
|
-
|
|
430
|
-
|
|
431
|
-
|
|
432
|
-
|
|
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
|
-
*/
|
|
185
|
+
// Tactic 5: Test-First Specification
|
|
186
|
+
describe('ShoppingCart', () => {
|
|
187
|
+
it('calculates total', () => {
|
|
188
|
+
const cart = new ShoppingCart();
|
|
189
|
+
cart.addItem({ price: 10, quantity: 2 });
|
|
190
|
+
expect(cart.total).toBe(20);
|
|
191
|
+
});
|
|
192
|
+
});
|
|
193
|
+
// Then: "Implement ShoppingCart to pass these tests"
|
|
442
194
|
```
|
|
443
195
|
|
|
444
|
-
###
|
|
196
|
+
### Quality Code Patterns
|
|
445
197
|
|
|
446
198
|
```typescript
|
|
447
|
-
//
|
|
448
|
-
|
|
449
|
-
// 1. Self-documenting with clear types
|
|
199
|
+
// 1. Self-documenting with branded types
|
|
450
200
|
interface User {
|
|
451
|
-
id: UserId; // Branded type
|
|
452
|
-
email: Email; // Validated
|
|
453
|
-
|
|
454
|
-
status: UserStatus; // 'active' | 'suspended' | 'deleted'
|
|
201
|
+
id: UserId; // Branded type
|
|
202
|
+
email: Email; // Validated type
|
|
203
|
+
status: UserStatus; // Union type
|
|
455
204
|
}
|
|
456
205
|
|
|
457
206
|
// 2. Pure functions where possible
|
|
458
207
|
const calculateTotal = (items: LineItem[]): Money =>
|
|
459
|
-
items.reduce(
|
|
460
|
-
(sum, item) => sum.add(item.price.multiply(item.quantity)),
|
|
461
|
-
Money.zero()
|
|
462
|
-
);
|
|
208
|
+
items.reduce((sum, item) => sum.add(item.price.multiply(item.quantity)), Money.zero());
|
|
463
209
|
|
|
464
|
-
// 3. Explicit error handling
|
|
465
|
-
type Result<T, E = Error> =
|
|
466
|
-
| { success: true; value: T }
|
|
467
|
-
| { success: false; error: E };
|
|
210
|
+
// 3. Explicit error handling with Result types
|
|
211
|
+
type Result<T, E = Error> = { success: true; value: T } | { success: false; error: E };
|
|
468
212
|
|
|
469
213
|
async function findUser(id: UserId): Promise<Result<User, NotFoundError>> {
|
|
470
214
|
const user = await db.users.find(id);
|
|
471
|
-
if (!user) {
|
|
472
|
-
return { success: false, error: new NotFoundError('User', id) };
|
|
473
|
-
}
|
|
215
|
+
if (!user) return { success: false, error: new NotFoundError('User', id) };
|
|
474
216
|
return { success: true, value: user };
|
|
475
217
|
}
|
|
476
218
|
|
|
477
|
-
// 4. Composable
|
|
478
|
-
const
|
|
479
|
-
validate,
|
|
480
|
-
transform,
|
|
481
|
-
enrich,
|
|
482
|
-
persist,
|
|
483
|
-
notify
|
|
484
|
-
);
|
|
219
|
+
// 4. Composable pipelines
|
|
220
|
+
const processDocument = pipe(parseMarkdown, extractEntities, enrichWithContext, generateSummary);
|
|
485
221
|
|
|
486
|
-
// 5.
|
|
222
|
+
// 5. Dependency injection for testability
|
|
487
223
|
class OrderService {
|
|
488
224
|
constructor(
|
|
489
|
-
private readonly repo: OrderRepository,
|
|
490
|
-
private readonly payment: PaymentGateway
|
|
491
|
-
private readonly notifier: Notifier // Injected
|
|
225
|
+
private readonly repo: OrderRepository,
|
|
226
|
+
private readonly payment: PaymentGateway
|
|
492
227
|
) {}
|
|
493
|
-
|
|
494
|
-
// Each dependency can be mocked in tests
|
|
495
228
|
}
|
|
496
229
|
```
|
|
497
230
|
|
|
498
|
-
###
|
|
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
|
|
231
|
+
### Abstraction Levels
|
|
526
232
|
|
|
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
233
|
```typescript
|
|
556
|
-
//
|
|
557
|
-
|
|
558
|
-
|
|
559
|
-
|
|
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
|
|
234
|
+
// Level 1: Solve one problem (avoid)
|
|
235
|
+
function validateEmail(email: string): boolean {
|
|
236
|
+
return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
|
|
237
|
+
}
|
|
617
238
|
|
|
618
|
-
|
|
619
|
-
|
|
620
|
-
|
|
239
|
+
// Level 2: Solve the class of problems (prefer)
|
|
240
|
+
function createValidator<T>(rules: ValidationRule<T>[]): Validator<T> {
|
|
241
|
+
return (value: T) => {
|
|
242
|
+
const errors = rules.filter(r => !r.validate(value)).map(r => r.message);
|
|
243
|
+
return { valid: errors.length === 0, errors };
|
|
244
|
+
};
|
|
245
|
+
}
|
|
621
246
|
|
|
622
|
-
|
|
247
|
+
// Now email validation is just one instance:
|
|
248
|
+
const validateEmail = createValidator([
|
|
249
|
+
{ validate: v => v.includes('@'), message: 'Must contain @' },
|
|
250
|
+
{ validate: v => v.length <= 254, message: 'Too long' }
|
|
251
|
+
]);
|
|
623
252
|
```
|
|
624
253
|
|
|
625
254
|
## Best Practices
|
|
626
255
|
|
|
627
|
-
|
|
628
|
-
|
|
629
|
-
|
|
630
|
-
|
|
631
|
-
|
|
632
|
-
|
|
633
|
-
|
|
634
|
-
|
|
635
|
-
|
|
636
|
-
|
|
637
|
-
|
|
638
|
-
|
|
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/)
|
|
256
|
+
| Do | Avoid |
|
|
257
|
+
|----|-------|
|
|
258
|
+
| Write specifications before generating | Generating without clear requirements |
|
|
259
|
+
| Use iterative refinement (generate, test, improve) | Trusting generated code without verification |
|
|
260
|
+
| Leverage AI for repetitive tasks | Skipping tests for AI-generated code |
|
|
261
|
+
| Verify generated code meets requirements | Using AI for security-critical code without review |
|
|
262
|
+
| Maintain human oversight for critical logic | Losing the spec-code relationship |
|
|
263
|
+
| Build reusable templates and patterns | Over-relying on AI for creative design |
|
|
264
|
+
| Document prompts that work well | Using outdated AI models for complex tasks |
|
|
265
|
+
| Combine AI strengths with human judgment | Forgetting to understand generated code |
|
|
266
|
+
| Start simple, add complexity | Ignoring AI suggestions for improvement |
|
|
267
|
+
| Keep specifications updated | Skipping code review for AI-generated code |
|