omgkit 2.1.1 → 2.3.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/databases/mongodb/SKILL.md +81 -28
- package/plugin/skills/databases/prisma/SKILL.md +87 -32
- package/plugin/skills/databases/redis/SKILL.md +80 -27
- package/plugin/skills/devops/aws/SKILL.md +80 -26
- package/plugin/skills/devops/github-actions/SKILL.md +84 -32
- package/plugin/skills/devops/kubernetes/SKILL.md +94 -32
- package/plugin/skills/devops/performance-profiling/SKILL.md +59 -863
- package/plugin/skills/frameworks/django/SKILL.md +158 -24
- package/plugin/skills/frameworks/express/SKILL.md +153 -33
- package/plugin/skills/frameworks/fastapi/SKILL.md +153 -34
- package/plugin/skills/frameworks/laravel/SKILL.md +146 -33
- package/plugin/skills/frameworks/nestjs/SKILL.md +137 -25
- package/plugin/skills/frameworks/rails/SKILL.md +594 -28
- package/plugin/skills/frameworks/react/SKILL.md +94 -962
- package/plugin/skills/frameworks/spring/SKILL.md +528 -35
- package/plugin/skills/frameworks/vue/SKILL.md +147 -25
- package/plugin/skills/frontend/accessibility/SKILL.md +145 -36
- package/plugin/skills/frontend/frontend-design/SKILL.md +114 -29
- package/plugin/skills/frontend/responsive/SKILL.md +131 -28
- package/plugin/skills/frontend/shadcn-ui/SKILL.md +133 -43
- package/plugin/skills/frontend/tailwindcss/SKILL.md +105 -37
- package/plugin/skills/frontend/threejs/SKILL.md +110 -35
- package/plugin/skills/languages/javascript/SKILL.md +195 -34
- package/plugin/skills/methodology/brainstorming/SKILL.md +98 -30
- package/plugin/skills/methodology/defense-in-depth/SKILL.md +83 -37
- package/plugin/skills/methodology/dispatching-parallel-agents/SKILL.md +92 -31
- package/plugin/skills/methodology/executing-plans/SKILL.md +117 -28
- package/plugin/skills/methodology/finishing-development-branch/SKILL.md +111 -32
- package/plugin/skills/methodology/problem-solving/SKILL.md +65 -311
- package/plugin/skills/methodology/receiving-code-review/SKILL.md +76 -27
- package/plugin/skills/methodology/requesting-code-review/SKILL.md +93 -22
- package/plugin/skills/methodology/root-cause-tracing/SKILL.md +75 -40
- package/plugin/skills/methodology/sequential-thinking/SKILL.md +75 -224
- package/plugin/skills/methodology/systematic-debugging/SKILL.md +81 -35
- package/plugin/skills/methodology/test-driven-development/SKILL.md +120 -26
- package/plugin/skills/methodology/testing-anti-patterns/SKILL.md +88 -35
- package/plugin/skills/methodology/token-optimization/SKILL.md +73 -34
- package/plugin/skills/methodology/verification-before-completion/SKILL.md +128 -28
- package/plugin/skills/methodology/writing-plans/SKILL.md +105 -20
- package/plugin/skills/omega/omega-architecture/SKILL.md +178 -40
- package/plugin/skills/omega/omega-coding/SKILL.md +247 -41
- package/plugin/skills/omega/omega-sprint/SKILL.md +208 -46
- package/plugin/skills/omega/omega-testing/SKILL.md +253 -42
- package/plugin/skills/omega/omega-thinking/SKILL.md +263 -51
- package/plugin/skills/security/better-auth/SKILL.md +83 -34
- package/plugin/skills/security/oauth/SKILL.md +118 -35
- package/plugin/skills/security/owasp/SKILL.md +112 -35
- package/plugin/skills/testing/playwright/SKILL.md +141 -38
- package/plugin/skills/testing/pytest/SKILL.md +137 -38
- package/plugin/skills/testing/vitest/SKILL.md +124 -39
- 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
|
@@ -1,34 +1,119 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: writing-plans
|
|
3
|
-
description:
|
|
3
|
+
description: AI agent creates structured implementation plans with task breakdown, dependency mapping, risk assessment, and file-level detail. Use when planning features, projects, or complex implementations.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
# Writing Plans
|
|
6
|
+
# Writing Plans
|
|
7
7
|
|
|
8
|
-
##
|
|
9
|
-
|
|
8
|
+
## Quick Start
|
|
9
|
+
|
|
10
|
+
1. **Summarize** - Executive summary with goals, non-goals, background
|
|
11
|
+
2. **Design** - High-level approach, architecture diagram, key decisions
|
|
12
|
+
3. **Break Down** - Tasks in 2-4 hour chunks with file locations
|
|
13
|
+
4. **Map Dependencies** - Identify critical path and parallel opportunities
|
|
14
|
+
5. **Assess Risks** - Likelihood x Impact matrix with mitigations
|
|
15
|
+
6. **Estimate** - Three-point estimation with buffers
|
|
16
|
+
|
|
17
|
+
## Features
|
|
18
|
+
|
|
19
|
+
| Feature | Description | Guide |
|
|
20
|
+
|---------|-------------|-------|
|
|
21
|
+
| Plan Structure | Comprehensive template | Summary, design, tasks, testing, risks |
|
|
22
|
+
| Task Breakdown | Manageable work units | 2-4 hours, single owner, clear criteria |
|
|
23
|
+
| Dependency Mapping | Sequence and parallelize | Critical path, hard/soft dependencies |
|
|
24
|
+
| Risk Assessment | Anticipate problems | Likelihood x Impact matrix |
|
|
25
|
+
| Effort Estimation | Realistic timing | Three-point: (O + 4M + P) / 6 |
|
|
26
|
+
| File-Level Detail | Exact code locations | New files, modifications, line numbers |
|
|
27
|
+
|
|
28
|
+
## Common Patterns
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
# Plan Structure
|
|
10
32
|
# Plan: [Feature Name]
|
|
11
33
|
|
|
12
|
-
##
|
|
13
|
-
|
|
34
|
+
## Metadata
|
|
35
|
+
- Status: Draft | Approved | In Progress
|
|
36
|
+
- Estimated Duration: [X days]
|
|
37
|
+
- Priority: P0 | P1 | P2
|
|
38
|
+
|
|
39
|
+
## Goals & Non-Goals
|
|
40
|
+
Goals: [What this WILL accomplish]
|
|
41
|
+
Non-Goals: [What this will NOT address]
|
|
14
42
|
|
|
15
|
-
##
|
|
16
|
-
|
|
17
|
-
2. [ ] [Task] - [2-5 min] - `path/file.ts:line`
|
|
43
|
+
## Design Overview
|
|
44
|
+
[High-level approach, architecture diagram]
|
|
18
45
|
|
|
19
|
-
##
|
|
20
|
-
- `src/file.ts` - [What changes]
|
|
46
|
+
## Implementation Tasks
|
|
21
47
|
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
-
|
|
48
|
+
### Phase 1: [Foundation] - [X days]
|
|
49
|
+
#### Task 1.1: [Name]
|
|
50
|
+
- Description: [What]
|
|
51
|
+
- Estimate: [X hours]
|
|
52
|
+
- Files: `src/file.ts:45-60`
|
|
53
|
+
- Dependencies: None
|
|
54
|
+
- Acceptance Criteria:
|
|
55
|
+
- [ ] [Criterion 1]
|
|
56
|
+
- [ ] [Criterion 2]
|
|
25
57
|
|
|
26
|
-
## Risks
|
|
58
|
+
## Risks & Mitigations
|
|
27
59
|
| Risk | Likelihood | Impact | Mitigation |
|
|
60
|
+
|------|------------|--------|------------|
|
|
61
|
+
| [Risk] | High | High | [Strategy] |
|
|
28
62
|
```
|
|
29
63
|
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
64
|
+
```
|
|
65
|
+
# Dependency Diagram
|
|
66
|
+
[START]
|
|
67
|
+
|
|
|
68
|
+
+----------+----------+
|
|
69
|
+
| | |
|
|
70
|
+
[Task 1] [Task 2] [Task 3] <- Parallel
|
|
71
|
+
| | |
|
|
72
|
+
+-----+----+ |
|
|
73
|
+
| |
|
|
74
|
+
[Task 4] [Task 5]
|
|
75
|
+
| |
|
|
76
|
+
+-------+-------+
|
|
77
|
+
|
|
|
78
|
+
[Task 6] <- Integration
|
|
79
|
+
|
|
|
80
|
+
[COMPLETE]
|
|
81
|
+
|
|
82
|
+
Critical Path: 1 -> 4 -> 6 (determines min duration)
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
```
|
|
86
|
+
# Effort Estimation
|
|
87
|
+
Three-Point: (Optimistic + 4*MostLikely + Pessimistic) / 6
|
|
88
|
+
|
|
89
|
+
Example - OAuth Implementation:
|
|
90
|
+
- Optimistic: 4 hours (works first try)
|
|
91
|
+
- Most Likely: 8 hours (normal dev)
|
|
92
|
+
- Pessimistic: 16 hours (issues)
|
|
93
|
+
Estimate = (4 + 32 + 16) / 6 = 8.7 hours
|
|
94
|
+
|
|
95
|
+
Buffers:
|
|
96
|
+
- Individual tasks: 20%
|
|
97
|
+
- Phase total: 30%
|
|
98
|
+
- Project total: 40%
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
## Best Practices
|
|
102
|
+
|
|
103
|
+
| Do | Avoid |
|
|
104
|
+
|----|-------|
|
|
105
|
+
| Keep tasks to 2-4 hour chunks | Vague tasks ("implement feature") |
|
|
106
|
+
| Include exact file locations | Skipping background/context |
|
|
107
|
+
| Specify clear acceptance criteria | Ignoring non-functional requirements |
|
|
108
|
+
| Map dependencies explicitly | Underestimating integration work |
|
|
109
|
+
| Build in buffer for unknowns | Planning more than 2 weeks in detail |
|
|
110
|
+
| Include testing in the plan | Hiding risks or uncertainties |
|
|
111
|
+
| Review plan with stakeholders | Assuming requirements are complete |
|
|
112
|
+
| Update plan as you learn | Forgetting rollback plans |
|
|
113
|
+
|
|
114
|
+
## Related Skills
|
|
115
|
+
|
|
116
|
+
- `executing-plans` - Follow plans systematically
|
|
117
|
+
- `thinking-sequentially` - Structure reasoning for plans
|
|
118
|
+
- `brainstorming-ideas` - Generate options for plans
|
|
119
|
+
- `verifying-before-completion` - Validate plan completion
|
|
@@ -1,59 +1,197 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: omega-
|
|
3
|
-
description: Omega
|
|
2
|
+
name: architecting-omega-systems
|
|
3
|
+
description: Designs scalable, resilient architectures using the 7 Omega principles. Use when building systems that need to scale to millions of users or designing platform-level infrastructure.
|
|
4
|
+
category: omega
|
|
5
|
+
triggers:
|
|
6
|
+
- omega architecture
|
|
7
|
+
- system design
|
|
8
|
+
- scalable architecture
|
|
9
|
+
- distributed systems
|
|
4
10
|
---
|
|
5
11
|
|
|
6
|
-
# Omega
|
|
12
|
+
# Architecting Omega Systems
|
|
7
13
|
|
|
8
|
-
|
|
14
|
+
Build **scalable, resilient, and future-proof systems** following the 7 Omega Principles for platform-grade architecture.
|
|
9
15
|
|
|
10
|
-
|
|
11
|
-
- Build systems, not features
|
|
12
|
-
- Automate everything
|
|
13
|
-
- Create multipliers
|
|
16
|
+
## Quick Start
|
|
14
17
|
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
-
|
|
18
|
+
```yaml
|
|
19
|
+
# 1. Define architectural requirements
|
|
20
|
+
Architecture:
|
|
21
|
+
Name: "E-commerce Platform"
|
|
22
|
+
Scale: "1M+ concurrent users"
|
|
23
|
+
Principles: [leverage, abstraction, agentic, antifragile]
|
|
19
24
|
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
25
|
+
# 2. Apply Omega decision framework
|
|
26
|
+
Decision:
|
|
27
|
+
Question: "Monolith or microservices?"
|
|
28
|
+
Omega_Check:
|
|
29
|
+
- Leverage: "Does this multiply capability?"
|
|
30
|
+
- Scale: "Zero-marginal-cost at 1000x?"
|
|
31
|
+
- Resilience: "Self-healing under stress?"
|
|
24
32
|
|
|
25
|
-
|
|
26
|
-
-
|
|
27
|
-
|
|
28
|
-
|
|
33
|
+
# 3. Design with antifragility
|
|
34
|
+
Pattern: Event-Driven + Circuit Breakers + Auto-Scaling
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## Features
|
|
38
|
+
|
|
39
|
+
| Feature | Description | Guide |
|
|
40
|
+
|---------|-------------|-------|
|
|
41
|
+
| 7 Omega Principles | Core architectural tenets for scalable systems | Apply all 7 to every decision |
|
|
42
|
+
| Leverage Architecture | Systems that amplify effort, not add to it | Build frameworks, not features |
|
|
43
|
+
| Agentic Services | Autonomous, self-healing microservices | Circuit breakers + health monitors |
|
|
44
|
+
| Zero-Marginal-Cost | Platform economics at scale | Edge compute + aggressive caching |
|
|
45
|
+
| Event-Driven Design | Loose coupling via event bus | Kafka/Redis streams + sagas |
|
|
46
|
+
| Antifragile Patterns | Systems that strengthen under stress | Chaos engineering + adaptive config |
|
|
47
|
+
| Decision Framework | Systematic architecture evaluation | Omega checklist for every choice |
|
|
29
48
|
|
|
30
|
-
##
|
|
49
|
+
## Common Patterns
|
|
31
50
|
|
|
32
|
-
###
|
|
51
|
+
### The 7 Omega Principles
|
|
52
|
+
|
|
53
|
+
```
|
|
54
|
+
1. LEVERAGE MULTIPLICATION - Build systems that amplify effort
|
|
55
|
+
2. TRANSCENDENT ABSTRACTION - Solve classes of problems
|
|
56
|
+
3. AGENTIC DECOMPOSITION - Autonomous, self-managing services
|
|
57
|
+
4. RECURSIVE IMPROVEMENT - Systems that optimize themselves
|
|
58
|
+
5. ZERO-MARGINAL-COST - No cost per user at scale
|
|
59
|
+
6. ANTIFRAGILE DESIGN - Grow stronger under stress
|
|
60
|
+
7. COMPOSABLE PRIMITIVES - Lego blocks that combine infinitely
|
|
33
61
|
```
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
62
|
+
|
|
63
|
+
### Leverage Architecture Pattern
|
|
64
|
+
|
|
65
|
+
```typescript
|
|
66
|
+
// ONE implementation handles ALL entity types
|
|
67
|
+
class LeveragedEntitySystem {
|
|
68
|
+
async create<T>(type: string, data: T): Promise<T> {
|
|
69
|
+
const validated = await this.validators.get(type)?.validate(data);
|
|
70
|
+
await this.runHooks(type, 'beforeCreate', validated);
|
|
71
|
+
const result = await this.storage.create(type, validated);
|
|
72
|
+
await this.runHooks(type, 'afterCreate', result);
|
|
73
|
+
return result as T;
|
|
74
|
+
}
|
|
75
|
+
|
|
76
|
+
// New entity = configuration, not code
|
|
77
|
+
registerEntityType(type: string, config: EntityConfig): void {
|
|
78
|
+
this.validators.set(type, createValidator(config.schema));
|
|
79
|
+
}
|
|
80
|
+
}
|
|
37
81
|
```
|
|
38
82
|
|
|
39
|
-
###
|
|
83
|
+
### Agentic Service Pattern
|
|
84
|
+
|
|
85
|
+
```typescript
|
|
86
|
+
abstract class AgenticService {
|
|
87
|
+
private circuitBreaker: CircuitBreaker;
|
|
88
|
+
private healthMonitor: HealthMonitor;
|
|
89
|
+
private autoScaler: AutoScaler;
|
|
90
|
+
|
|
91
|
+
constructor() {
|
|
92
|
+
// Self-monitoring
|
|
93
|
+
this.healthMonitor = new HealthMonitor({
|
|
94
|
+
onUnhealthy: () => this.selfHeal()
|
|
95
|
+
});
|
|
96
|
+
|
|
97
|
+
// Self-protecting
|
|
98
|
+
this.circuitBreaker = new CircuitBreaker({
|
|
99
|
+
failureThreshold: 5,
|
|
100
|
+
onOpen: () => this.notifyDegradation()
|
|
101
|
+
});
|
|
102
|
+
}
|
|
103
|
+
|
|
104
|
+
protected async executeWithResilience<T>(
|
|
105
|
+
operation: () => Promise<T>,
|
|
106
|
+
fallback?: () => T
|
|
107
|
+
): Promise<T> {
|
|
108
|
+
return this.circuitBreaker.execute(operation, fallback);
|
|
109
|
+
}
|
|
110
|
+
}
|
|
40
111
|
```
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
112
|
+
|
|
113
|
+
### Zero-Marginal-Cost Pattern
|
|
114
|
+
|
|
115
|
+
```typescript
|
|
116
|
+
// Edge-first architecture
|
|
117
|
+
const platformConfig = {
|
|
118
|
+
compute: { provider: 'cloudflare-workers', pricing: 'per-invocation' },
|
|
119
|
+
storage: { provider: 'r2', cdn: { enabled: true, ttl: '1y' } },
|
|
120
|
+
database: { provider: 'planetscale', sharding: 'automatic' },
|
|
121
|
+
cache: {
|
|
122
|
+
layers: [
|
|
123
|
+
{ type: 'browser', ttl: '1h' },
|
|
124
|
+
{ type: 'cdn-edge', ttl: '24h' },
|
|
125
|
+
{ type: 'origin', ttl: '5m' }
|
|
126
|
+
]
|
|
127
|
+
}
|
|
128
|
+
};
|
|
46
129
|
```
|
|
47
130
|
|
|
48
|
-
###
|
|
131
|
+
### Event-Driven Saga Pattern
|
|
132
|
+
|
|
133
|
+
```typescript
|
|
134
|
+
class OrderSaga {
|
|
135
|
+
constructor(eventBus: EventBus) {
|
|
136
|
+
eventBus.subscribe('order.created', this.handleOrderCreated);
|
|
137
|
+
eventBus.subscribe('payment.failed', this.handlePaymentFailed);
|
|
138
|
+
}
|
|
139
|
+
|
|
140
|
+
handleOrderCreated = async (event: DomainEvent<Order>) => {
|
|
141
|
+
await this.eventBus.publish({
|
|
142
|
+
type: 'inventory.reserve',
|
|
143
|
+
data: { orderId: event.data.id, items: event.data.items },
|
|
144
|
+
correlationId: event.correlationId
|
|
145
|
+
});
|
|
146
|
+
};
|
|
147
|
+
|
|
148
|
+
handlePaymentFailed = async (event: DomainEvent) => {
|
|
149
|
+
// Compensating action
|
|
150
|
+
await this.eventBus.publish({ type: 'inventory.release', ... });
|
|
151
|
+
await this.eventBus.publish({ type: 'order.cancelled', ... });
|
|
152
|
+
};
|
|
153
|
+
}
|
|
49
154
|
```
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
155
|
+
|
|
156
|
+
### Architecture Decision Template
|
|
157
|
+
|
|
158
|
+
```markdown
|
|
159
|
+
## Omega Architecture Decision
|
|
160
|
+
|
|
161
|
+
### Context
|
|
162
|
+
[Problem and constraints]
|
|
163
|
+
|
|
164
|
+
### Omega Principles Check
|
|
165
|
+
| Principle | Question | Assessment |
|
|
166
|
+
|-----------|----------|------------|
|
|
167
|
+
| Leverage | Does this multiply capability? | |
|
|
168
|
+
| Abstraction | Solving class of problems? | |
|
|
169
|
+
| Agentic | Can it operate autonomously? | |
|
|
170
|
+
| Recursive | Will it self-improve? | |
|
|
171
|
+
| Zero-Marginal | Sub-linear cost scaling? | |
|
|
172
|
+
| Antifragile | Stronger under stress? | |
|
|
173
|
+
| Composable | Combines with other components? | |
|
|
174
|
+
|
|
175
|
+
### Scale Analysis
|
|
176
|
+
- 10x load: [Impact]
|
|
177
|
+
- 100x load: [Impact]
|
|
178
|
+
- 1000x load: [Impact]
|
|
179
|
+
|
|
180
|
+
### Decision
|
|
181
|
+
[Chosen approach with rationale]
|
|
53
182
|
```
|
|
54
183
|
|
|
55
|
-
##
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
184
|
+
## Best Practices
|
|
185
|
+
|
|
186
|
+
| Do | Avoid |
|
|
187
|
+
|----|-------|
|
|
188
|
+
| Apply all 7 Omega principles to every decision | Building monoliths that cannot decompose |
|
|
189
|
+
| Design for 1000x scale from day one | Tight coupling between services |
|
|
190
|
+
| Use event-driven patterns for loose coupling | Ignoring failure modes in design |
|
|
191
|
+
| Implement circuit breakers at all boundaries | Scaling vertically when horizontal is possible |
|
|
192
|
+
| Build self-healing capabilities into services | Hardcoding configuration values |
|
|
193
|
+
| Measure and optimize cost per transaction | Skipping capacity planning |
|
|
194
|
+
| Document decisions using ADR template | Deploying without health checks |
|
|
195
|
+
| Test failure scenarios with chaos engineering | Synchronous calls for non-critical paths |
|
|
196
|
+
| Use infrastructure as code | Ignoring data consistency requirements |
|
|
197
|
+
| Implement observability everywhere | Underestimating distributed system complexity |
|
|
@@ -1,61 +1,267 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: omega-
|
|
3
|
-
description: AI-first development patterns. Use
|
|
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
|
+
category: omega
|
|
5
|
+
triggers:
|
|
6
|
+
- omega coding
|
|
7
|
+
- ai-first development
|
|
8
|
+
- ai assisted coding
|
|
9
|
+
- prompt driven
|
|
10
|
+
- leverage multiplication
|
|
4
11
|
---
|
|
5
12
|
|
|
6
|
-
# Omega
|
|
13
|
+
# Coding with Omega Leverage
|
|
7
14
|
|
|
8
|
-
|
|
15
|
+
Master **AI-first development** patterns that multiply productivity 10-100x through specification-driven generation and systematic AI collaboration.
|
|
9
16
|
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
17
|
+
## Quick Start
|
|
18
|
+
|
|
19
|
+
```yaml
|
|
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"
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
## Features
|
|
41
|
+
|
|
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 |
|
|
51
|
+
|
|
52
|
+
## Common Patterns
|
|
53
|
+
|
|
54
|
+
### The 7 Omega Principles in Code
|
|
15
55
|
|
|
16
|
-
### 2. Prompt-Driven Development
|
|
17
|
-
```markdown
|
|
18
|
-
1. Write clear requirements
|
|
19
|
-
2. Let AI generate first draft
|
|
20
|
-
3. Review and refine
|
|
21
|
-
4. Iterate with feedback
|
|
22
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
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
### Specification Template
|
|
67
|
+
|
|
68
|
+
```yaml
|
|
69
|
+
component:
|
|
70
|
+
name: UserAuthService
|
|
71
|
+
description: Authentication and session management
|
|
23
72
|
|
|
24
|
-
|
|
73
|
+
requirements:
|
|
74
|
+
functional:
|
|
75
|
+
- FR1: Register with email/password
|
|
76
|
+
- FR2: Login with credentials
|
|
77
|
+
- FR3: Logout and invalidate session
|
|
78
|
+
non_functional:
|
|
79
|
+
- NFR1: Response < 200ms
|
|
80
|
+
- NFR2: PCI-DSS compliant
|
|
81
|
+
|
|
82
|
+
interface:
|
|
83
|
+
methods:
|
|
84
|
+
- name: register
|
|
85
|
+
input: { email: "string", password: "string (min 8 chars)" }
|
|
86
|
+
output: { success: boolean, userId?: string, error?: Error }
|
|
87
|
+
- name: login
|
|
88
|
+
input: { email: "string", password: "string" }
|
|
89
|
+
output: { success: boolean, token?: "JWT 24h", error?: Error }
|
|
90
|
+
|
|
91
|
+
testing:
|
|
92
|
+
unit: [password validation, token generation]
|
|
93
|
+
integration: [registration flow, login flow]
|
|
94
|
+
edge_cases: [duplicate email, invalid credentials]
|
|
25
95
|
```
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
96
|
+
|
|
97
|
+
### Iterative Refinement Loop
|
|
98
|
+
|
|
99
|
+
```typescript
|
|
100
|
+
async function omegaDevelopment(spec: Specification): Promise<Code> {
|
|
101
|
+
let code = await generateFromSpec(spec);
|
|
102
|
+
let iteration = 0;
|
|
103
|
+
|
|
104
|
+
while (iteration < 5) {
|
|
105
|
+
const results = await runTests(code);
|
|
106
|
+
|
|
107
|
+
if (results.allPassing && results.coverage >= 80) {
|
|
108
|
+
return code; // Done!
|
|
109
|
+
}
|
|
110
|
+
|
|
111
|
+
const issues = analyzeResults(results);
|
|
112
|
+
code = await refineCode(code, issues);
|
|
113
|
+
iteration++;
|
|
114
|
+
}
|
|
115
|
+
|
|
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!
|
|
29
123
|
```
|
|
30
124
|
|
|
31
|
-
|
|
125
|
+
### Prompt Templates
|
|
32
126
|
|
|
33
|
-
### Specification First
|
|
34
127
|
```markdown
|
|
35
|
-
##
|
|
128
|
+
## Component Generation
|
|
129
|
+
Create a [TYPE] component named [NAME] with:
|
|
130
|
+
|
|
131
|
+
Requirements:
|
|
132
|
+
- [Req 1]
|
|
133
|
+
- [Req 2]
|
|
134
|
+
|
|
135
|
+
Interface:
|
|
136
|
+
[Define inputs, outputs, methods]
|
|
137
|
+
|
|
138
|
+
Constraints:
|
|
139
|
+
- Language: TypeScript
|
|
140
|
+
- Error handling: Return Result types
|
|
141
|
+
- Include unit tests
|
|
36
142
|
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
143
|
+
## Refactoring Request
|
|
144
|
+
Refactor this code to:
|
|
145
|
+
1. [Improvement 1]
|
|
146
|
+
2. [Improvement 2]
|
|
40
147
|
|
|
41
|
-
|
|
42
|
-
- Email must be unique
|
|
43
|
-
- Password hashed with bcrypt
|
|
148
|
+
Current code: [paste]
|
|
44
149
|
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
150
|
+
Preserve: functionality, API, types
|
|
151
|
+
|
|
152
|
+
## Bug Fix Request
|
|
153
|
+
Fix the bug in this code:
|
|
154
|
+
|
|
155
|
+
Code: [paste]
|
|
156
|
+
Bug: [description]
|
|
157
|
+
Expected: [behavior]
|
|
158
|
+
Actual: [behavior]
|
|
159
|
+
|
|
160
|
+
Provide: root cause, fixed code, regression test
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
### Leverage Multiplication Tactics
|
|
164
|
+
|
|
165
|
+
```typescript
|
|
166
|
+
// Tactic 1: Generate, Don't Write
|
|
167
|
+
// Schema -> API -> Controllers -> Services -> Tests
|
|
168
|
+
// All generated, all consistent, all in minutes
|
|
169
|
+
|
|
170
|
+
// Tactic 2: Transform, Don't Recreate
|
|
171
|
+
// "Convert JavaScript to TypeScript with types"
|
|
172
|
+
// "Add error handling to all async functions"
|
|
173
|
+
|
|
174
|
+
// Tactic 3: Batch Operations
|
|
175
|
+
// "Add JSDoc to all exports in src/utils/"
|
|
176
|
+
// "Update all class components to functional"
|
|
177
|
+
|
|
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
|
|
184
|
+
|
|
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"
|
|
48
194
|
```
|
|
49
195
|
|
|
50
|
-
###
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
196
|
+
### Quality Code Patterns
|
|
197
|
+
|
|
198
|
+
```typescript
|
|
199
|
+
// 1. Self-documenting with branded types
|
|
200
|
+
interface User {
|
|
201
|
+
id: UserId; // Branded type
|
|
202
|
+
email: Email; // Validated type
|
|
203
|
+
status: UserStatus; // Union type
|
|
204
|
+
}
|
|
205
|
+
|
|
206
|
+
// 2. Pure functions where possible
|
|
207
|
+
const calculateTotal = (items: LineItem[]): Money =>
|
|
208
|
+
items.reduce((sum, item) => sum.add(item.price.multiply(item.quantity)), Money.zero());
|
|
209
|
+
|
|
210
|
+
// 3. Explicit error handling with Result types
|
|
211
|
+
type Result<T, E = Error> = { success: true; value: T } | { success: false; error: E };
|
|
212
|
+
|
|
213
|
+
async function findUser(id: UserId): Promise<Result<User, NotFoundError>> {
|
|
214
|
+
const user = await db.users.find(id);
|
|
215
|
+
if (!user) return { success: false, error: new NotFoundError('User', id) };
|
|
216
|
+
return { success: true, value: user };
|
|
217
|
+
}
|
|
218
|
+
|
|
219
|
+
// 4. Composable pipelines
|
|
220
|
+
const processDocument = pipe(parseMarkdown, extractEntities, enrichWithContext, generateSummary);
|
|
221
|
+
|
|
222
|
+
// 5. Dependency injection for testability
|
|
223
|
+
class OrderService {
|
|
224
|
+
constructor(
|
|
225
|
+
private readonly repo: OrderRepository,
|
|
226
|
+
private readonly payment: PaymentGateway
|
|
227
|
+
) {}
|
|
228
|
+
}
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
### Abstraction Levels
|
|
232
|
+
|
|
233
|
+
```typescript
|
|
234
|
+
// Level 1: Solve one problem (avoid)
|
|
235
|
+
function validateEmail(email: string): boolean {
|
|
236
|
+
return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
|
|
237
|
+
}
|
|
238
|
+
|
|
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
|
+
}
|
|
246
|
+
|
|
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
|
+
]);
|
|
252
|
+
```
|
|
56
253
|
|
|
57
254
|
## Best Practices
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
255
|
+
|
|
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 |
|