@martinffx/atelier 1.2.2 → 1.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/CHANGELOG.md +19 -0
- package/README.md +22 -24
- package/agents/architect.md +1 -1
- package/agents/oracle.md +1 -1
- package/dist/atelier.js +12 -14
- package/package.json +1 -1
- package/skills/code-commit/SKILL.md +5 -13
- package/skills/code-pull-request/SKILL.md +36 -0
- package/skills/code-pull-request/references/common.md +76 -0
- package/skills/code-pull-request/references/create-pr.md +122 -0
- package/skills/code-pull-request/references/default-template.md +25 -0
- package/skills/code-pull-request/references/leave-comment.md +53 -0
- package/skills/code-pull-request/references/merge-pr.md +94 -0
- package/skills/code-pull-request/references/read-comments.md +61 -0
- package/skills/code-pull-request/references/respond-to-comment.md +66 -0
- package/skills/code-review/SKILL.md +21 -12
- package/skills/code-review/references/reviewers.md +142 -41
- package/skills/code-review/references/rq.md +48 -32
- package/skills/oracle-debug/SKILL.md +218 -0
- package/skills/{code-debug → oracle-debug}/references/bug-patterns.md +3 -3
- package/skills/oracle-domain-modelling/SKILL.md +84 -0
- package/skills/oracle-grill-me/SKILL.md +20 -0
- package/skills/spec-brainstorm/SKILL.md +91 -71
- package/skills/spec-finish/SKILL.md +20 -14
- package/skills/spec-implement/SKILL.md +3 -2
- package/skills/spec-orchestrator/SKILL.md +4 -15
- package/skills/spec-plan/SKILL.md +1 -1
- package/agents/scout.md +0 -40
- package/skills/code-commit/references/pr-workflow.md +0 -145
- package/skills/code-debug/SKILL.md +0 -199
- package/skills/code-docs/SKILL.md +0 -171
- package/skills/code-docs/references/api-docs.md +0 -116
- package/skills/code-docs/references/changelog.md +0 -64
- package/skills/code-docs/references/readme-structure.md +0 -94
- package/skills/oracle-architect/SKILL.md +0 -327
- package/skills/oracle-architect/references/api-design.md +0 -345
- package/skills/oracle-architect/references/data-modeling.md +0 -318
- package/skills/oracle-architect/references/ddd-patterns.md +0 -348
- package/skills/oracle-architect/references/interface-design.md +0 -203
- package/skills/oracle-challenge/SKILL.md +0 -126
- package/skills/oracle-doubt/SKILL.md +0 -252
- package/skills/oracle-doubt/references/adversarial-prompt.md +0 -47
- package/skills/oracle-grillme/SKILL.md +0 -160
- package/skills/oracle-security/SKILL.md +0 -225
- package/skills/oracle-security/references/security-patterns.md +0 -236
- package/skills/oracle-security/references/threat-modeling-guide.md +0 -137
- package/skills/oracle-testing/SKILL.md +0 -237
- package/skills/oracle-testing/references/anti-patterns.md +0 -618
- package/skills/oracle-testing/references/boundaries.md +0 -579
- package/skills/oracle-testing/references/core-testing.md +0 -691
- package/skills/oracle-testing/references/edge-testing.md +0 -794
- package/skills/oracle-testing/references/stub-driven-tdd.md +0 -322
- package/skills/oracle-thinkdeep/SKILL.md +0 -164
- /package/skills/{code-debug → oracle-debug}/references/language-tools.md +0 -0
- /package/skills/{code-debug → oracle-debug}/references/techniques.md +0 -0
- /package/skills/{oracle-grillme → oracle-domain-modelling}/references/ADR-FORMAT.md +0 -0
- /package/skills/{oracle-grillme → oracle-domain-modelling}/references/CONTEXT-FORMAT.md +0 -0
|
@@ -1,322 +0,0 @@
|
|
|
1
|
-
# Stub-Driven TDD Workflow
|
|
2
|
-
|
|
3
|
-
Complete workflow examples showing the Stub → Test → Implement → Refactor pattern.
|
|
4
|
-
|
|
5
|
-
## The Four-Step Pattern
|
|
6
|
-
|
|
7
|
-
```
|
|
8
|
-
1. Stub → Create minimal interface/function signatures
|
|
9
|
-
2. Test → Write tests against stubs
|
|
10
|
-
3. Implement → Make tests pass with real implementation
|
|
11
|
-
4. Refactor → Improve code while keeping tests green
|
|
12
|
-
```
|
|
13
|
-
|
|
14
|
-
## Why Stub-Driven?
|
|
15
|
-
|
|
16
|
-
**Traditional TDD problem:** Can't write tests until implementation exists
|
|
17
|
-
|
|
18
|
-
**Stub-Driven solution:** Write interface/type signatures first, test against those, then implement
|
|
19
|
-
|
|
20
|
-
**Benefits:**
|
|
21
|
-
- Tests define behavior before implementation
|
|
22
|
-
- Interfaces emerge from use cases, not speculation
|
|
23
|
-
- Refactoring is safe (tests validate behavior)
|
|
24
|
-
- Fast feedback loop (stub → test → implement)
|
|
25
|
-
|
|
26
|
-
## Complete Order Service Example
|
|
27
|
-
|
|
28
|
-
### Step 1: Stub
|
|
29
|
-
|
|
30
|
-
Define the interface and service class with stub methods:
|
|
31
|
-
|
|
32
|
-
```typescript
|
|
33
|
-
// Define repository interface from use case
|
|
34
|
-
interface OrderRepository {
|
|
35
|
-
save(order: OrderRecord): Promise<OrderRecord>;
|
|
36
|
-
findById(id: string): Promise<OrderRecord | null>;
|
|
37
|
-
delete(id: string): Promise<void>;
|
|
38
|
-
}
|
|
39
|
-
|
|
40
|
-
// Service uses stub - methods throw NotImplemented
|
|
41
|
-
class OrderService {
|
|
42
|
-
constructor(private repo: OrderRepository) {}
|
|
43
|
-
|
|
44
|
-
async createOrder(request: CreateOrderRequest): Promise<Result<Order>> {
|
|
45
|
-
throw new Error('Not implemented');
|
|
46
|
-
}
|
|
47
|
-
|
|
48
|
-
async cancelOrder(id: string): Promise<Result<void>> {
|
|
49
|
-
throw new Error('Not implemented');
|
|
50
|
-
}
|
|
51
|
-
|
|
52
|
-
async getOrder(id: string): Promise<Result<Order>> {
|
|
53
|
-
throw new Error('Not implemented');
|
|
54
|
-
}
|
|
55
|
-
}
|
|
56
|
-
|
|
57
|
-
// Export for testing
|
|
58
|
-
export { OrderService, OrderRepository };
|
|
59
|
-
```
|
|
60
|
-
|
|
61
|
-
### Step 2: Test
|
|
62
|
-
|
|
63
|
-
Write comprehensive tests against the stubs:
|
|
64
|
-
|
|
65
|
-
```typescript
|
|
66
|
-
import { describe, it, expect, beforeEach, vi } from 'vitest';
|
|
67
|
-
import { OrderService, OrderRepository } from './order-service';
|
|
68
|
-
import { CreateOrderRequest, OrderRecord, Order } from './order';
|
|
69
|
-
import { Ok, Err } from './result';
|
|
70
|
-
|
|
71
|
-
describe('OrderService', () => {
|
|
72
|
-
let service: OrderService;
|
|
73
|
-
let mockRepo: OrderRepository;
|
|
74
|
-
|
|
75
|
-
beforeEach(() => {
|
|
76
|
-
// Create stub implementation
|
|
77
|
-
mockRepo = {
|
|
78
|
-
save: vi.fn(),
|
|
79
|
-
findById: vi.fn(),
|
|
80
|
-
delete: vi.fn()
|
|
81
|
-
};
|
|
82
|
-
service = new OrderService(mockRepo);
|
|
83
|
-
});
|
|
84
|
-
|
|
85
|
-
describe('createOrder', () => {
|
|
86
|
-
it('should save valid order', async () => {
|
|
87
|
-
mockRepo.save.mockResolvedValue({
|
|
88
|
-
id: '123',
|
|
89
|
-
customer_id: 'C1',
|
|
90
|
-
items: '[]',
|
|
91
|
-
status: 'pending',
|
|
92
|
-
total: 0
|
|
93
|
-
});
|
|
94
|
-
|
|
95
|
-
const result = await service.createOrder({
|
|
96
|
-
customerId: 'C1',
|
|
97
|
-
items: [{ productId: 'P1', quantity: 2, price: 10 }]
|
|
98
|
-
});
|
|
99
|
-
|
|
100
|
-
expect(result.ok).toBe(true);
|
|
101
|
-
expect(mockRepo.save).toHaveBeenCalledWith(
|
|
102
|
-
expect.objectContaining({
|
|
103
|
-
customer_id: 'C1',
|
|
104
|
-
status: 'pending'
|
|
105
|
-
})
|
|
106
|
-
);
|
|
107
|
-
});
|
|
108
|
-
|
|
109
|
-
it('should validate order before saving', async () => {
|
|
110
|
-
const result = await service.createOrder({
|
|
111
|
-
customerId: 'C1',
|
|
112
|
-
items: [] // Invalid: empty items
|
|
113
|
-
});
|
|
114
|
-
|
|
115
|
-
expect(result.ok).toBe(false);
|
|
116
|
-
expect(mockRepo.save).not.toHaveBeenCalled();
|
|
117
|
-
});
|
|
118
|
-
|
|
119
|
-
it('should calculate total correctly', async () => {
|
|
120
|
-
mockRepo.save.mockResolvedValue({
|
|
121
|
-
id: '123',
|
|
122
|
-
customer_id: 'C1',
|
|
123
|
-
items: '[]',
|
|
124
|
-
status: 'pending',
|
|
125
|
-
total: 0
|
|
126
|
-
});
|
|
127
|
-
|
|
128
|
-
await service.createOrder({
|
|
129
|
-
customerId: 'C1',
|
|
130
|
-
items: [
|
|
131
|
-
{ productId: 'P1', quantity: 2, price: 10 },
|
|
132
|
-
{ productId: 'P2', quantity: 1, price: 15 }
|
|
133
|
-
]
|
|
134
|
-
});
|
|
135
|
-
|
|
136
|
-
expect(mockRepo.save).toHaveBeenCalledWith(
|
|
137
|
-
expect.objectContaining({ total: 35 })
|
|
138
|
-
);
|
|
139
|
-
});
|
|
140
|
-
});
|
|
141
|
-
|
|
142
|
-
describe('cancelOrder', () => {
|
|
143
|
-
it('should cancel pending order', async () => {
|
|
144
|
-
mockRepo.findById.mockResolvedValue({
|
|
145
|
-
id: '123',
|
|
146
|
-
customer_id: 'C1',
|
|
147
|
-
items: '[]',
|
|
148
|
-
status: 'pending',
|
|
149
|
-
total: 0
|
|
150
|
-
});
|
|
151
|
-
mockRepo.delete.mockResolvedValue(undefined);
|
|
152
|
-
|
|
153
|
-
const result = await service.cancelOrder('123');
|
|
154
|
-
|
|
155
|
-
expect(result.ok).toBe(true);
|
|
156
|
-
expect(mockRepo.delete).toHaveBeenCalledWith('123');
|
|
157
|
-
});
|
|
158
|
-
|
|
159
|
-
it('should reject canceling shipped order', async () => {
|
|
160
|
-
mockRepo.findById.mockResolvedValue({
|
|
161
|
-
id: '123',
|
|
162
|
-
customer_id: 'C1',
|
|
163
|
-
items: '[]',
|
|
164
|
-
status: 'shipped',
|
|
165
|
-
total: 0
|
|
166
|
-
});
|
|
167
|
-
|
|
168
|
-
const result = await service.cancelOrder('123');
|
|
169
|
-
|
|
170
|
-
expect(result.ok).toBe(false);
|
|
171
|
-
expect(mockRepo.delete).not.toHaveBeenCalled();
|
|
172
|
-
});
|
|
173
|
-
|
|
174
|
-
it('should reject canceling non-existent order', async () => {
|
|
175
|
-
mockRepo.findById.mockResolvedValue(null);
|
|
176
|
-
|
|
177
|
-
const result = await service.cancelOrder('999');
|
|
178
|
-
|
|
179
|
-
expect(result.ok).toBe(false);
|
|
180
|
-
});
|
|
181
|
-
});
|
|
182
|
-
|
|
183
|
-
describe('getOrder', () => {
|
|
184
|
-
it('should retrieve order by id', async () => {
|
|
185
|
-
mockRepo.findById.mockResolvedValue({
|
|
186
|
-
id: '123',
|
|
187
|
-
customer_id: 'C1',
|
|
188
|
-
items: '[]',
|
|
189
|
-
status: 'pending',
|
|
190
|
-
total: 0
|
|
191
|
-
});
|
|
192
|
-
|
|
193
|
-
const result = await service.getOrder('123');
|
|
194
|
-
|
|
195
|
-
expect(result.ok).toBe(true);
|
|
196
|
-
if (result.ok) {
|
|
197
|
-
expect(result.value.id).toBe('123');
|
|
198
|
-
}
|
|
199
|
-
});
|
|
200
|
-
|
|
201
|
-
it('should return error for non-existent order', async () => {
|
|
202
|
-
mockRepo.findById.mockResolvedValue(null);
|
|
203
|
-
|
|
204
|
-
const result = await service.getOrder('999');
|
|
205
|
-
|
|
206
|
-
expect(result.ok).toBe(false);
|
|
207
|
-
});
|
|
208
|
-
});
|
|
209
|
-
});
|
|
210
|
-
```
|
|
211
|
-
|
|
212
|
-
### Step 3: Implement
|
|
213
|
-
|
|
214
|
-
Make tests pass with real implementation:
|
|
215
|
-
|
|
216
|
-
```typescript
|
|
217
|
-
class OrderService {
|
|
218
|
-
constructor(private repo: OrderRepository) {}
|
|
219
|
-
|
|
220
|
-
async createOrder(request: CreateOrderRequest): Promise<Result<Order>> {
|
|
221
|
-
// Transform request to entity
|
|
222
|
-
const order = Order.fromRequest(request);
|
|
223
|
-
|
|
224
|
-
// Validate
|
|
225
|
-
const validation = order.validate();
|
|
226
|
-
if (!validation.ok) return validation;
|
|
227
|
-
|
|
228
|
-
// Save to repository
|
|
229
|
-
const record = order.toRecord();
|
|
230
|
-
const saved = await this.repo.save(record);
|
|
231
|
-
|
|
232
|
-
// Transform back to entity
|
|
233
|
-
return Ok(Order.fromRecord(saved));
|
|
234
|
-
}
|
|
235
|
-
|
|
236
|
-
async cancelOrder(id: string): Promise<Result<void>> {
|
|
237
|
-
// Find order
|
|
238
|
-
const record = await this.repo.findById(id);
|
|
239
|
-
if (!record) return Err('Order not found');
|
|
240
|
-
|
|
241
|
-
// Transform to entity
|
|
242
|
-
const order = Order.fromRecord(record);
|
|
243
|
-
|
|
244
|
-
// Check business rule
|
|
245
|
-
if (!order.canCancel()) {
|
|
246
|
-
return Err(`Cannot cancel ${order.status} order`);
|
|
247
|
-
}
|
|
248
|
-
|
|
249
|
-
// Delete
|
|
250
|
-
await this.repo.delete(id);
|
|
251
|
-
return Ok(undefined);
|
|
252
|
-
}
|
|
253
|
-
|
|
254
|
-
async getOrder(id: string): Promise<Result<Order>> {
|
|
255
|
-
// Find order
|
|
256
|
-
const record = await this.repo.findById(id);
|
|
257
|
-
if (!record) return Err('Order not found');
|
|
258
|
-
|
|
259
|
-
// Transform to entity
|
|
260
|
-
return Ok(Order.fromRecord(record));
|
|
261
|
-
}
|
|
262
|
-
}
|
|
263
|
-
```
|
|
264
|
-
|
|
265
|
-
### Step 4: Refactor
|
|
266
|
-
|
|
267
|
-
Improve code while keeping tests green:
|
|
268
|
-
|
|
269
|
-
```typescript
|
|
270
|
-
class OrderService {
|
|
271
|
-
constructor(private repo: OrderRepository) {}
|
|
272
|
-
|
|
273
|
-
async createOrder(request: CreateOrderRequest): Promise<Result<Order>> {
|
|
274
|
-
const order = Order.fromRequest(request);
|
|
275
|
-
return await this.validateAndSave(order);
|
|
276
|
-
}
|
|
277
|
-
|
|
278
|
-
async cancelOrder(id: string): Promise<Result<void>> {
|
|
279
|
-
const order = await this.findOrderOrError(id);
|
|
280
|
-
if (!order.ok) return order;
|
|
281
|
-
|
|
282
|
-
return await this.checkCancellableAndDelete(order.value);
|
|
283
|
-
}
|
|
284
|
-
|
|
285
|
-
async getOrder(id: string): Promise<Result<Order>> {
|
|
286
|
-
return await this.findOrderOrError(id);
|
|
287
|
-
}
|
|
288
|
-
|
|
289
|
-
private async validateAndSave(order: Order): Promise<Result<Order>> {
|
|
290
|
-
const validation = order.validate();
|
|
291
|
-
if (!validation.ok) return validation;
|
|
292
|
-
|
|
293
|
-
const record = order.toRecord();
|
|
294
|
-
const saved = await this.repo.save(record);
|
|
295
|
-
return Ok(Order.fromRecord(saved));
|
|
296
|
-
}
|
|
297
|
-
|
|
298
|
-
private async findOrderOrError(id: string): Promise<Result<Order>> {
|
|
299
|
-
const record = await this.repo.findById(id);
|
|
300
|
-
if (!record) return Err('Order not found');
|
|
301
|
-
return Ok(Order.fromRecord(record));
|
|
302
|
-
}
|
|
303
|
-
|
|
304
|
-
private async checkCancellableAndDelete(order: Order): Promise<Result<void>> {
|
|
305
|
-
if (!order.canCancel()) {
|
|
306
|
-
return Err(`Cannot cancel ${order.status} order`);
|
|
307
|
-
}
|
|
308
|
-
await this.repo.delete(order.id);
|
|
309
|
-
return Ok(undefined);
|
|
310
|
-
}
|
|
311
|
-
}
|
|
312
|
-
```
|
|
313
|
-
|
|
314
|
-
All tests still pass after refactoring - behavior is unchanged, only implementation improved.
|
|
315
|
-
|
|
316
|
-
## Key Takeaways
|
|
317
|
-
|
|
318
|
-
1. **Start with stubs** - Define interfaces before implementation
|
|
319
|
-
2. **Test against contracts** - Test the interface, not the implementation
|
|
320
|
-
3. **Implement once tests are clear** - Make tests pass with real code
|
|
321
|
-
4. **Refactor with confidence** - Tests validate behavior doesn't change
|
|
322
|
-
5. **Keep feedback loop fast** - Each step is quick and focused
|
|
@@ -1,164 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: oracle-thinkdeep
|
|
3
|
-
description: Extended reasoning analysis using sequential thinking. Use for deep exploration, comprehensive analysis, complex decisions, or when you need fresh perspectives on difficult problems.
|
|
4
|
-
user-invocable: true
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# ThinkDeep: Extended Reasoning Analysis
|
|
8
|
-
|
|
9
|
-
## Step 1: Parse Request Parameters
|
|
10
|
-
|
|
11
|
-
<strategist>
|
|
12
|
-
@agent-oracle
|
|
13
|
-
|
|
14
|
-
Analyze the thinkdeep request: $ARGUMENTS
|
|
15
|
-
|
|
16
|
-
**Parameter Extraction:**
|
|
17
|
-
- **Main prompt**: [extract core thinking request]
|
|
18
|
-
- **Focus areas**: [extract "architecture, performance, security" etc]
|
|
19
|
-
- **File references**: [extract "reference to file.py" patterns]
|
|
20
|
-
- **Problem context**: [extract additional context provided]
|
|
21
|
-
|
|
22
|
-
**Parsed Configuration:**
|
|
23
|
-
- Prompt: [core request]
|
|
24
|
-
- Focus areas: [identified areas]
|
|
25
|
-
- File references: [any files mentioned]
|
|
26
|
-
- Problem context: [additional context]
|
|
27
|
-
</strategist>
|
|
28
|
-
|
|
29
|
-
## Step 2: Deep Sequential Analysis
|
|
30
|
-
|
|
31
|
-
<strategist>
|
|
32
|
-
@agent-oracle
|
|
33
|
-
|
|
34
|
-
Use sequential thinking (mcp__sequential-thinking__sequentialthinking) for extended reasoning:
|
|
35
|
-
|
|
36
|
-
### Thought 1: Context Understanding
|
|
37
|
-
Analyze the current session context to understand:
|
|
38
|
-
- What has been discussed so far
|
|
39
|
-
- Previous decisions and analyses made
|
|
40
|
-
- User's specific constraints and goals
|
|
41
|
-
- Existing solutions or approaches tried
|
|
42
|
-
|
|
43
|
-
### Thought 2: Problem Decomposition
|
|
44
|
-
Break down the core issue into:
|
|
45
|
-
- Primary problem statement
|
|
46
|
-
- Key sub-problems or components
|
|
47
|
-
- Underlying assumptions and constraints
|
|
48
|
-
- Success criteria and desired outcomes
|
|
49
|
-
|
|
50
|
-
### Thought 3: Assumption Challenge
|
|
51
|
-
Question the underlying assumptions:
|
|
52
|
-
- What assumptions are we making?
|
|
53
|
-
- Are these assumptions valid in this context?
|
|
54
|
-
- What if the opposite were true?
|
|
55
|
-
- Alternative perspectives to consider
|
|
56
|
-
|
|
57
|
-
### Thought 4: Alternative Approaches Exploration
|
|
58
|
-
Explore different solution paths:
|
|
59
|
-
- Conventional approaches and their pros/cons
|
|
60
|
-
- Unconventional or innovative solutions
|
|
61
|
-
- Trade-offs between different options
|
|
62
|
-
- Hybrid or combined approaches
|
|
63
|
-
|
|
64
|
-
### Thought 5: Context Integration
|
|
65
|
-
Incorporate relevant context:
|
|
66
|
-
- File references and code patterns
|
|
67
|
-
- Previous session insights
|
|
68
|
-
- User's specific technical stack
|
|
69
|
-
- Business or project constraints
|
|
70
|
-
|
|
71
|
-
### Thought 6: Edge Case Analysis
|
|
72
|
-
Identify potential issues:
|
|
73
|
-
- What could go wrong with each approach?
|
|
74
|
-
- Edge cases and failure modes
|
|
75
|
-
- Scalability and performance concerns
|
|
76
|
-
- Security and maintenance implications
|
|
77
|
-
|
|
78
|
-
### Thought 7: Risk Assessment
|
|
79
|
-
Evaluate risks for each option:
|
|
80
|
-
- Implementation complexity
|
|
81
|
-
- Technical debt potential
|
|
82
|
-
- Team skill requirements
|
|
83
|
-
- Timeline and resource impacts
|
|
84
|
-
|
|
85
|
-
### Thought 8: Solution Synthesis
|
|
86
|
-
Combine insights into recommendations:
|
|
87
|
-
- Primary recommended approach
|
|
88
|
-
- Backup or alternative options
|
|
89
|
-
- Implementation considerations
|
|
90
|
-
- Next steps and validation points
|
|
91
|
-
|
|
92
|
-
Continue sequential thinking until satisfaction, using:
|
|
93
|
-
- `isRevision: true` to refine previous thoughts
|
|
94
|
-
- `branchFromThought` to explore alternative reasoning paths
|
|
95
|
-
- `needsMoreThoughts: true` to extend analysis if needed
|
|
96
|
-
</strategist>
|
|
97
|
-
|
|
98
|
-
## Step 3: Critical Evaluation & Synthesis
|
|
99
|
-
|
|
100
|
-
**Self-Critique Questions:**
|
|
101
|
-
- Does the analysis address the user's specific context?
|
|
102
|
-
- Are the recommendations practical and implementable?
|
|
103
|
-
- Have we considered the most important constraints?
|
|
104
|
-
- Are there any blind spots or missing perspectives?
|
|
105
|
-
|
|
106
|
-
**Contextual Validation:**
|
|
107
|
-
- Fit with user's technical stack and preferences
|
|
108
|
-
- Alignment with previous decisions in session
|
|
109
|
-
- Practicality given team skills and resources
|
|
110
|
-
- Integration with existing systems or patterns
|
|
111
|
-
|
|
112
|
-
**Final Synthesis:**
|
|
113
|
-
- **Primary Recommendation**: [best approach with rationale]
|
|
114
|
-
- **Alternative Options**: [backup plans with trade-offs]
|
|
115
|
-
- **Implementation Guidance**: [key considerations and next steps]
|
|
116
|
-
- **Risk Mitigation**: [how to address identified concerns]
|
|
117
|
-
|
|
118
|
-
---
|
|
119
|
-
|
|
120
|
-
## Usage Examples
|
|
121
|
-
|
|
122
|
-
**Basic deep analysis:**
|
|
123
|
-
```
|
|
124
|
-
/atelier-thinkdeep "Analyze my authentication architecture"
|
|
125
|
-
```
|
|
126
|
-
|
|
127
|
-
**With file references:**
|
|
128
|
-
```
|
|
129
|
-
/atelier-thinkdeep "Evaluate my database schema with reference to models/user.py"
|
|
130
|
-
```
|
|
131
|
-
|
|
132
|
-
**With focus areas:**
|
|
133
|
-
```
|
|
134
|
-
/atelier-thinkdeep "Assess my microservices design focusing on performance and security"
|
|
135
|
-
```
|
|
136
|
-
|
|
137
|
-
**Complex architectural decisions:**
|
|
138
|
-
```
|
|
139
|
-
/atelier-thinkdeep "Should I use GraphQL or REST for my API considering team skills and scalability needs"
|
|
140
|
-
```
|
|
141
|
-
|
|
142
|
-
## When to Use ThinkDeep
|
|
143
|
-
|
|
144
|
-
- **Architecture decisions**: When choosing between major design approaches
|
|
145
|
-
- **Complex problem solving**: Multi-faceted issues requiring deep analysis
|
|
146
|
-
- **Assumption validation**: Challenging conventional wisdom or previous decisions
|
|
147
|
-
- **Alternative exploration**: When stuck and need fresh perspectives
|
|
148
|
-
- **Risk assessment**: Before major implementation decisions
|
|
149
|
-
|
|
150
|
-
## ThinkDeep vs Challenge
|
|
151
|
-
|
|
152
|
-
**Use /atelier-thinkdeep**: Deep exploration, comprehensive analysis, alternative discovery, complex decisions
|
|
153
|
-
**Use /atelier-challenge**: Question assumptions, test validity, assess risks, prevent automatic agreement
|
|
154
|
-
|
|
155
|
-
**Key distinction**: ThinkDeep = deep exploration, Challenge = critical evaluation
|
|
156
|
-
|
|
157
|
-
## Expected Outcomes
|
|
158
|
-
|
|
159
|
-
After using this command:
|
|
160
|
-
- Comprehensive understanding of the problem space
|
|
161
|
-
- Multiple approaches evaluated with trade-offs
|
|
162
|
-
- Clear recommendation with solid reasoning
|
|
163
|
-
- Risk assessment and mitigation strategies
|
|
164
|
-
- Actionable next steps for implementation
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|