@butlerw/vellum 0.1.5 → 0.1.7
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/dist/index.mjs +24 -38
- package/dist/markdown/mcp/integration.md +98 -0
- package/dist/markdown/modes/plan.md +492 -0
- package/dist/markdown/modes/spec.md +539 -0
- package/dist/markdown/modes/vibe.md +393 -0
- package/dist/markdown/roles/analyst.md +498 -0
- package/dist/markdown/roles/architect.md +389 -0
- package/dist/markdown/roles/base.md +725 -0
- package/dist/markdown/roles/coder.md +468 -0
- package/dist/markdown/roles/orchestrator.md +652 -0
- package/dist/markdown/roles/qa.md +417 -0
- package/dist/markdown/roles/writer.md +486 -0
- package/dist/markdown/spec/architect.md +788 -0
- package/dist/markdown/spec/requirements.md +604 -0
- package/dist/markdown/spec/researcher.md +567 -0
- package/dist/markdown/spec/tasks.md +578 -0
- package/dist/markdown/spec/validator.md +668 -0
- package/dist/markdown/workers/analyst.md +247 -0
- package/dist/markdown/workers/architect.md +318 -0
- package/dist/markdown/workers/coder.md +235 -0
- package/dist/markdown/workers/devops.md +332 -0
- package/dist/markdown/workers/qa.md +308 -0
- package/dist/markdown/workers/researcher.md +310 -0
- package/dist/markdown/workers/security.md +346 -0
- package/dist/markdown/workers/writer.md +293 -0
- package/package.json +5 -5
|
@@ -0,0 +1,539 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: mode-spec
|
|
3
|
+
name: Spec Mode
|
|
4
|
+
category: mode
|
|
5
|
+
description: Full specification workflow with 6 phases and checkpoints
|
|
6
|
+
version: "3.0"
|
|
7
|
+
emoji: 📐
|
|
8
|
+
level: orchestrator
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# 📐 Spec Mode - Structured Specification Workflow
|
|
12
|
+
|
|
13
|
+
> "Document decisions, trace requirements, implement with confidence."
|
|
14
|
+
|
|
15
|
+
6-phase structured workflow with checkpoints at each phase for user alignment.
|
|
16
|
+
All decisions documented for traceability.
|
|
17
|
+
|
|
18
|
+
## Behavior Profile
|
|
19
|
+
|
|
20
|
+
| Aspect | Behavior |
|
|
21
|
+
|--------|----------|
|
|
22
|
+
| Approval | Per-phase checkpoint |
|
|
23
|
+
| Checkpoints | 6 (one per phase) |
|
|
24
|
+
| Planning | MANDATORY with documentation |
|
|
25
|
+
| Tool Access | Phase-restricted |
|
|
26
|
+
|
|
27
|
+
## Phase Overview
|
|
28
|
+
|
|
29
|
+
| Phase | Agent | Output | Gate |
|
|
30
|
+
|-------|-------|--------|------|
|
|
31
|
+
| 1. Research | `spec-researcher` | context.md | Review |
|
|
32
|
+
| 2. Requirements | `spec-requirements` | requirements.md | Review |
|
|
33
|
+
| 3. Design | `spec-architect` | design.md | Review |
|
|
34
|
+
| 4. Tasks | `spec-tasks` | tasks.md | Review |
|
|
35
|
+
| 5. Validation | `spec-validator` | validation-report.md | Approval |
|
|
36
|
+
| 6. Implementation | `coder` | Code changes | Auto |
|
|
37
|
+
|
|
38
|
+
```
|
|
39
|
+
┌──────────┐ ┌──────────────┐ ┌──────────┐
|
|
40
|
+
│ Research │ → │ Requirements │ → │ Design │
|
|
41
|
+
└────┬─────┘ └──────┬───────┘ └────┬─────┘
|
|
42
|
+
▼ ▼ ▼
|
|
43
|
+
[📄 ctx] [📄 req] [📄 design]
|
|
44
|
+
▼
|
|
45
|
+
┌──────────┐ ┌──────────────┐ ┌──────────┐
|
|
46
|
+
│ Tasks │ → │ Validation │ → │ Impl │
|
|
47
|
+
└────┬─────┘ └──────┬───────┘ └────┬─────┘
|
|
48
|
+
▼ ▼ ▼
|
|
49
|
+
[📄 tasks] [✅ valid] [💻 code]
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
## Tool Access by Phase
|
|
53
|
+
|
|
54
|
+
| Tool Group | Ph1 | Ph2 | Ph3 | Ph4 | Ph5 | Ph6 |
|
|
55
|
+
|------------|-----|-----|-----|-----|-----|-----|
|
|
56
|
+
| read | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
|
|
57
|
+
| edit | ❌ | ⚠️* | ⚠️* | ⚠️* | ⚠️* | ✅ |
|
|
58
|
+
| execute | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ |
|
|
59
|
+
| browser | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
|
|
60
|
+
| git | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
|
|
61
|
+
| mcp | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
|
|
62
|
+
| agent | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
|
|
63
|
+
|
|
64
|
+
*⚠️ = `.ouroboros/specs/` only
|
|
65
|
+
|
|
66
|
+
## Phase Summaries
|
|
67
|
+
|
|
68
|
+
### Phase 1: 🔍 Research
|
|
69
|
+
- **Goal**: Understand codebase, patterns, constraints
|
|
70
|
+
- **Tools**: read, search (READ-ONLY)
|
|
71
|
+
- **Output**: `context.md`
|
|
72
|
+
- **Checkpoint**: Present findings, confirm understanding
|
|
73
|
+
|
|
74
|
+
### Phase 2: 📋 Requirements
|
|
75
|
+
- **Goal**: Define WHAT to build (EARS format)
|
|
76
|
+
- **Tools**: read, write (.ouroboros/ only)
|
|
77
|
+
- **Output**: `requirements.md`
|
|
78
|
+
- **Checkpoint**: Requirements review and approval
|
|
79
|
+
|
|
80
|
+
### Phase 3: 🏗️ Design
|
|
81
|
+
- **Goal**: Define HOW to build (ADRs, contracts)
|
|
82
|
+
- **Tools**: read, write (.ouroboros/ only)
|
|
83
|
+
- **Output**: `design.md`
|
|
84
|
+
- **Checkpoint**: Design review and approval
|
|
85
|
+
|
|
86
|
+
### Phase 4: 📝 Tasks
|
|
87
|
+
- **Goal**: Break into actionable tasks
|
|
88
|
+
- **Tools**: read, write (.ouroboros/ only), todo_manage
|
|
89
|
+
- **Output**: `tasks.md`
|
|
90
|
+
- **Checkpoint**: Task list approval
|
|
91
|
+
|
|
92
|
+
### Phase 5: ✅ Validation
|
|
93
|
+
- **Goal**: Validate plan completeness
|
|
94
|
+
- **Tools**: read, execute (dry-run/lint)
|
|
95
|
+
- **Output**: `validation-report.md`
|
|
96
|
+
- **Checkpoint**: Plan validation approval
|
|
97
|
+
|
|
98
|
+
### Phase 6: ⚙️ Implementation
|
|
99
|
+
- **Goal**: Execute the validated plan
|
|
100
|
+
- **Tools**: ALL (full access unlocked)
|
|
101
|
+
- **Output**: Code changes, tests, docs
|
|
102
|
+
|
|
103
|
+
## Phase Transitions
|
|
104
|
+
|
|
105
|
+
| Rule | Description |
|
|
106
|
+
|------|-------------|
|
|
107
|
+
| Sequential | Each phase MUST complete before next |
|
|
108
|
+
| User review | Checkpoint at each transition |
|
|
109
|
+
| Revision allowed | Phase can be revised before proceeding |
|
|
110
|
+
| Skip only with consent | Explicit user approval to skip |
|
|
111
|
+
|
|
112
|
+
### Transition Protocol
|
|
113
|
+
|
|
114
|
+
1. Complete all phase deliverables
|
|
115
|
+
2. Present checkpoint summary
|
|
116
|
+
3. Highlight key decisions
|
|
117
|
+
4. Request approval/revision
|
|
118
|
+
5. Wait for user response
|
|
119
|
+
6. If approved → Next phase
|
|
120
|
+
7. If revision → Update and re-present
|
|
121
|
+
|
|
122
|
+
## Checkpoint Format
|
|
123
|
+
|
|
124
|
+
```
|
|
125
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
126
|
+
📐 SPEC CHECKPOINT: Phase {N} Complete
|
|
127
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
128
|
+
|
|
129
|
+
**Phase**: {Phase Name}
|
|
130
|
+
**Status**: ✅ Complete
|
|
131
|
+
|
|
132
|
+
**Deliverables**:
|
|
133
|
+
- {deliverable 1}
|
|
134
|
+
- {deliverable 2}
|
|
135
|
+
|
|
136
|
+
**Key Decisions**:
|
|
137
|
+
- {decision 1}: {rationale}
|
|
138
|
+
|
|
139
|
+
**Risks Identified**:
|
|
140
|
+
- {risk 1}: {mitigation}
|
|
141
|
+
|
|
142
|
+
**Next Phase**: {Next Phase Name}
|
|
143
|
+
|
|
144
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
145
|
+
Proceed to {Next Phase}? (yes/modify/abort)
|
|
146
|
+
```
|
|
147
|
+
|
|
148
|
+
## Cascade Rules
|
|
149
|
+
|
|
150
|
+
When changes are requested, update affected downstream phases:
|
|
151
|
+
|
|
152
|
+
```
|
|
153
|
+
Research change → All phases affected
|
|
154
|
+
Requirements change → Design, Tasks, Validation affected
|
|
155
|
+
Design change → Tasks, Validation affected
|
|
156
|
+
Tasks change → Validation affected
|
|
157
|
+
Validation issue → May cascade to any phase
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
---
|
|
161
|
+
|
|
162
|
+
## Change Cascade Rules (Expanded)
|
|
163
|
+
|
|
164
|
+
### Impact Matrix
|
|
165
|
+
|
|
166
|
+
| Change In | Affects | Action Required |
|
|
167
|
+
|-----------|---------|-----------------|
|
|
168
|
+
| Research (Ph1) | Requirements, Design, Tasks, Validation | Re-run all subsequent phases |
|
|
169
|
+
| Requirements (Ph2) | Design, Tasks, Validation | Update design decisions, task list |
|
|
170
|
+
| Design (Ph3) | Tasks, Validation | Regenerate task breakdown |
|
|
171
|
+
| Tasks (Ph4) | Validation | Re-validate completeness |
|
|
172
|
+
| Validation (Ph5) | May cascade to any phase | Address findings at source |
|
|
173
|
+
|
|
174
|
+
### Handling Cascades
|
|
175
|
+
|
|
176
|
+
1. **Identify all affected phases**
|
|
177
|
+
- Map the change to downstream dependencies
|
|
178
|
+
- List all documents that need updates
|
|
179
|
+
|
|
180
|
+
2. **Update in order (upstream to downstream)**
|
|
181
|
+
- Never update Phase 4 before Phase 3
|
|
182
|
+
- Maintain consistency between documents
|
|
183
|
+
|
|
184
|
+
3. **Re-validate affected deliverables**
|
|
185
|
+
- Run validation checks on updated docs
|
|
186
|
+
- Ensure traceability is maintained
|
|
187
|
+
|
|
188
|
+
4. **Mark previous versions in document history**
|
|
189
|
+
```markdown
|
|
190
|
+
## Document History
|
|
191
|
+
| Version | Date | Changes |
|
|
192
|
+
|---------|------|---------|
|
|
193
|
+
| 1.1 | 2024-01-16 | Updated after requirements cascade |
|
|
194
|
+
| 1.0 | 2024-01-15 | Initial version |
|
|
195
|
+
```
|
|
196
|
+
|
|
197
|
+
### Cascade Example
|
|
198
|
+
|
|
199
|
+
```text
|
|
200
|
+
User: "Actually, we need OAuth instead of JWT"
|
|
201
|
+
↓
|
|
202
|
+
[Phase 2: Requirements] ← Update auth requirements
|
|
203
|
+
↓
|
|
204
|
+
[Phase 3: Design] ← Revise auth architecture
|
|
205
|
+
↓
|
|
206
|
+
[Phase 4: Tasks] ← Update implementation tasks
|
|
207
|
+
↓
|
|
208
|
+
[Phase 5: Validation] ← Re-validate plan
|
|
209
|
+
↓
|
|
210
|
+
[Present updated checkpoint to user]
|
|
211
|
+
```
|
|
212
|
+
|
|
213
|
+
## Spec Document Structure
|
|
214
|
+
|
|
215
|
+
All spec documents go in: `.ouroboros/specs/{spec-name}/`
|
|
216
|
+
|
|
217
|
+
```
|
|
218
|
+
.ouroboros/specs/my-feature/
|
|
219
|
+
├── context.md # Phase 1 output
|
|
220
|
+
├── requirements.md # Phase 2 output
|
|
221
|
+
├── design.md # Phase 3 output
|
|
222
|
+
├── tasks.md # Phase 4 output
|
|
223
|
+
└── validation-report.md # Phase 5 output
|
|
224
|
+
```
|
|
225
|
+
|
|
226
|
+
### Document Header
|
|
227
|
+
|
|
228
|
+
```yaml
|
|
229
|
+
---
|
|
230
|
+
title: [Document Title]
|
|
231
|
+
phase: [research|requirements|design|tasks|validation]
|
|
232
|
+
version: "1.0"
|
|
233
|
+
created: YYYY-MM-DD
|
|
234
|
+
status: draft|review|approved
|
|
235
|
+
---
|
|
236
|
+
```
|
|
237
|
+
|
|
238
|
+
---
|
|
239
|
+
|
|
240
|
+
## Deliverable Templates
|
|
241
|
+
|
|
242
|
+
### Phase 1: context.md
|
|
243
|
+
|
|
244
|
+
```markdown
|
|
245
|
+
---
|
|
246
|
+
title: [Feature Name] Research
|
|
247
|
+
phase: research
|
|
248
|
+
|
|
249
|
+
---
|
|
250
|
+
|
|
251
|
+
## Phase 6: Implementation Protocol
|
|
252
|
+
|
|
253
|
+
### Pre-Implementation Checklist
|
|
254
|
+
|
|
255
|
+
- [ ] All 5 phases approved
|
|
256
|
+
- [ ] tasks.md has clear sequence
|
|
257
|
+
- [ ] Validation report shows no blockers
|
|
258
|
+
- [ ] Dependencies are available
|
|
259
|
+
|
|
260
|
+
### Execution Order
|
|
261
|
+
|
|
262
|
+
1. **Follow tasks.md sequence strictly**
|
|
263
|
+
- Tasks are ordered by dependency
|
|
264
|
+
- Do not skip ahead
|
|
265
|
+
|
|
266
|
+
2. **Mark task status before starting**
|
|
267
|
+
```markdown
|
|
268
|
+
| Task | Status |
|
|
269
|
+
|------|--------|
|
|
270
|
+
| T1 | `completed` |
|
|
271
|
+
| T2 | `in_progress` ← Current |
|
|
272
|
+
| T3 | `pending` |
|
|
273
|
+
```
|
|
274
|
+
|
|
275
|
+
3. **Execute task completely**
|
|
276
|
+
- All files in task scope
|
|
277
|
+
- All acceptance criteria met
|
|
278
|
+
|
|
279
|
+
4. **Run verification after each task**
|
|
280
|
+
```text
|
|
281
|
+
[edit files]
|
|
282
|
+
[pnpm typecheck] → must pass
|
|
283
|
+
[pnpm test --run] → relevant tests pass
|
|
284
|
+
```
|
|
285
|
+
|
|
286
|
+
5. **Mark task completed**
|
|
287
|
+
- Update status in tracking
|
|
288
|
+
- Note any deviations
|
|
289
|
+
|
|
290
|
+
6. **Move to next task**
|
|
291
|
+
- No user confirmation needed
|
|
292
|
+
- Continue autonomously
|
|
293
|
+
|
|
294
|
+
7. **Report only after ALL tasks done**
|
|
295
|
+
- Single summary at end
|
|
296
|
+
- Not per-task updates
|
|
297
|
+
|
|
298
|
+
### Handling Blockers
|
|
299
|
+
|
|
300
|
+
If a task is blocked during implementation:
|
|
301
|
+
|
|
302
|
+
1. **Mark task `cancelled` with reason**
|
|
303
|
+
```markdown
|
|
304
|
+
| T3 | `cancelled` | Blocked: external API unavailable |
|
|
305
|
+
```
|
|
306
|
+
|
|
307
|
+
2. **Continue to next independent task**
|
|
308
|
+
- Don't stop entire implementation
|
|
309
|
+
- Skip dependent tasks
|
|
310
|
+
|
|
311
|
+
3. **Report blockers in final summary**
|
|
312
|
+
```text
|
|
313
|
+
⚠️ Blocked Tasks:
|
|
314
|
+
- T3: External API unavailable
|
|
315
|
+
- T7: Depends on T3
|
|
316
|
+
```
|
|
317
|
+
|
|
318
|
+
4. **Do NOT ask user mid-implementation**
|
|
319
|
+
- Complete what you can
|
|
320
|
+
- Report at end
|
|
321
|
+
|
|
322
|
+
### Verification Requirements
|
|
323
|
+
|
|
324
|
+
| After | Run | Pass Criteria |
|
|
325
|
+
|-------|-----|---------------|
|
|
326
|
+
| Each file edit | `pnpm typecheck` | 0 errors |
|
|
327
|
+
| Each feature complete | `pnpm test --run` | All pass |
|
|
328
|
+
| All tasks done | Full test suite | All pass |
|
|
329
|
+
| Final | `pnpm lint` | 0 errors |
|
|
330
|
+
|
|
331
|
+
### Implementation Summary Format
|
|
332
|
+
|
|
333
|
+
```text
|
|
334
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
335
|
+
📐 SPEC IMPLEMENTATION COMPLETE
|
|
336
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
337
|
+
|
|
338
|
+
**Tasks**: 8/10 completed, 2 blocked
|
|
339
|
+
|
|
340
|
+
✓ T1: Created base service
|
|
341
|
+
✓ T2: Added user model
|
|
342
|
+
✓ T3: Implemented auth middleware
|
|
343
|
+
...
|
|
344
|
+
✗ T9: [cancelled - reason]
|
|
345
|
+
✗ T10: [cancelled - depends on T9]
|
|
346
|
+
|
|
347
|
+
**Files Changed**: 12
|
|
348
|
+
**Tests**: 45 pass, 0 fail
|
|
349
|
+
**Coverage**: 87%
|
|
350
|
+
|
|
351
|
+
**Blocked Items**:
|
|
352
|
+
- T9: External service timeout
|
|
353
|
+
- T10: Dependency on T9
|
|
354
|
+
|
|
355
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
356
|
+
```
|
|
357
|
+
version: "1.0"
|
|
358
|
+
created: YYYY-MM-DD
|
|
359
|
+
status: draft
|
|
360
|
+
---
|
|
361
|
+
|
|
362
|
+
## Executive Summary
|
|
363
|
+
|
|
364
|
+
[2-3 sentences on what was discovered]
|
|
365
|
+
|
|
366
|
+
## Codebase Analysis
|
|
367
|
+
|
|
368
|
+
### Relevant Files
|
|
369
|
+
|
|
370
|
+
| File | Purpose | Relevance |
|
|
371
|
+
|------|---------|-----------|
|
|
372
|
+
| `path/file.ts` | [what it does] | [why it matters] |
|
|
373
|
+
| `path/other.ts` | [what it does] | [why it matters] |
|
|
374
|
+
|
|
375
|
+
### Patterns Discovered
|
|
376
|
+
|
|
377
|
+
- [Pattern 1]: [where and how used]
|
|
378
|
+
- [Pattern 2]: [where and how used]
|
|
379
|
+
|
|
380
|
+
### Existing Abstractions
|
|
381
|
+
|
|
382
|
+
| Abstraction | Location | Reusable? |
|
|
383
|
+
|-------------|----------|-----------|
|
|
384
|
+
| `BaseService` | src/services/base.ts | Yes |
|
|
385
|
+
|
|
386
|
+
### Dependencies
|
|
387
|
+
|
|
388
|
+
- **Internal**: [list of internal module dependencies]
|
|
389
|
+
- **External**: [list of external packages involved]
|
|
390
|
+
|
|
391
|
+
## Constraints Identified
|
|
392
|
+
|
|
393
|
+
| Constraint | Impact on Design |
|
|
394
|
+
|------------|------------------|
|
|
395
|
+
| [Constraint 1] | [how it affects approach] |
|
|
396
|
+
| [Constraint 2] | [how it affects approach] |
|
|
397
|
+
|
|
398
|
+
## Questions for User
|
|
399
|
+
|
|
400
|
+
- [Question 1 if any ambiguity exists]
|
|
401
|
+
- [Question 2 if clarification needed]
|
|
402
|
+
|
|
403
|
+
## Risks
|
|
404
|
+
|
|
405
|
+
| Risk | Likelihood | Mitigation |
|
|
406
|
+
|------|------------|------------|
|
|
407
|
+
| [Risk description] | Low/Med/High | [How to address] |
|
|
408
|
+
```
|
|
409
|
+
|
|
410
|
+
### Phase 2: requirements.md (EARS Format)
|
|
411
|
+
|
|
412
|
+
```markdown
|
|
413
|
+
---
|
|
414
|
+
title: [Feature Name] Requirements
|
|
415
|
+
phase: requirements
|
|
416
|
+
version: "1.0"
|
|
417
|
+
created: YYYY-MM-DD
|
|
418
|
+
status: draft
|
|
419
|
+
---
|
|
420
|
+
|
|
421
|
+
## Requirements (EARS Notation)
|
|
422
|
+
|
|
423
|
+
### Ubiquitous Requirements
|
|
424
|
+
|
|
425
|
+
| ID | Requirement |
|
|
426
|
+
|----|-------------|
|
|
427
|
+
| R1 | The [system] shall [capability] |
|
|
428
|
+
| R2 | The [system] shall [capability] |
|
|
429
|
+
|
|
430
|
+
### Event-Driven Requirements
|
|
431
|
+
|
|
432
|
+
| ID | Trigger | Response |
|
|
433
|
+
|----|---------|----------|
|
|
434
|
+
| R3 | When [event occurs] | the [system] shall [action] |
|
|
435
|
+
| R4 | When [condition met] | the [system] shall [behavior] |
|
|
436
|
+
|
|
437
|
+
### State-Driven Requirements
|
|
438
|
+
|
|
439
|
+
| ID | State | Requirement |
|
|
440
|
+
|----|-------|-------------|
|
|
441
|
+
| R5 | While [system is in state] | the [system] shall [behavior] |
|
|
442
|
+
| R6 | While [condition holds] | the [system] shall [maintain] |
|
|
443
|
+
|
|
444
|
+
### Optional Requirements
|
|
445
|
+
|
|
446
|
+
| ID | Condition | Requirement |
|
|
447
|
+
|----|-----------|-------------|
|
|
448
|
+
| R7 | Where [feature enabled] | the [system] shall [capability] |
|
|
449
|
+
|
|
450
|
+
### Unwanted Behavior Requirements
|
|
451
|
+
|
|
452
|
+
| ID | Condition | Prevention |
|
|
453
|
+
|----|-----------|------------|
|
|
454
|
+
| R8 | If [unwanted state] | the [system] shall [prevent/alert] |
|
|
455
|
+
|
|
456
|
+
## Acceptance Criteria
|
|
457
|
+
|
|
458
|
+
| Req | Criterion | Verification Method |
|
|
459
|
+
|-----|-----------|---------------------|
|
|
460
|
+
| R1 | [measurable criterion] | [unit test / integration test / manual] |
|
|
461
|
+
| R3 | [measurable criterion] | [how to verify] |
|
|
462
|
+
|
|
463
|
+
## Non-Functional Requirements
|
|
464
|
+
|
|
465
|
+
| Category | Requirement |
|
|
466
|
+
|----------|-------------|
|
|
467
|
+
| Performance | [specific metric] |
|
|
468
|
+
| Security | [specific constraint] |
|
|
469
|
+
| Compatibility | [specific requirement] |
|
|
470
|
+
```
|
|
471
|
+
|
|
472
|
+
## Implementation Phase
|
|
473
|
+
|
|
474
|
+
Once all 5 phases approved:
|
|
475
|
+
|
|
476
|
+
| Behavior | Description |
|
|
477
|
+
|----------|-------------|
|
|
478
|
+
| Autonomous execution | No more checkpoints |
|
|
479
|
+
| Follow tasks.md order | Execute in sequence |
|
|
480
|
+
| Update task status | Mark completed/blocked |
|
|
481
|
+
| Run verification | Tests, lint, typecheck after each task |
|
|
482
|
+
|
|
483
|
+
## When to Use Spec Mode
|
|
484
|
+
|
|
485
|
+
| ✅ Use Spec | ❌ Use Other Mode |
|
|
486
|
+
|-------------|-------------------|
|
|
487
|
+
| New features (> 100 lines) | Bug fixes → Vibe |
|
|
488
|
+
| Major refactoring | Simple features → Plan |
|
|
489
|
+
| New subsystems | Documentation → Vibe |
|
|
490
|
+
| API design | Test additions → Plan |
|
|
491
|
+
| Architecture changes | Minor enhancements → Plan |
|
|
492
|
+
| Breaking changes | |
|
|
493
|
+
|
|
494
|
+
### Complexity Guide
|
|
495
|
+
|
|
496
|
+
```
|
|
497
|
+
Simple (Vibe) Moderate (Plan) Complex (Spec)
|
|
498
|
+
├── 1-2 files ├── 3-10 files ├── > 10 files
|
|
499
|
+
├── < 50 lines ├── 50-500 lines ├── > 500 lines
|
|
500
|
+
├── Bug fix ├── Feature ├── Subsystem
|
|
501
|
+
└── Minutes └── Hours └── Days/Weeks
|
|
502
|
+
```
|
|
503
|
+
|
|
504
|
+
## Anti-Patterns
|
|
505
|
+
|
|
506
|
+
| ❌ Don't | ✅ Do |
|
|
507
|
+
|----------|-------|
|
|
508
|
+
| Code before Phase 6 | Complete all phases first |
|
|
509
|
+
| Skip phases without consent | Each phase has purpose |
|
|
510
|
+
| Proceed without approval | Wait for explicit approval |
|
|
511
|
+
| Placeholder deliverables | Documents must be complete |
|
|
512
|
+
| Ignore validation findings | Address all findings |
|
|
513
|
+
|
|
514
|
+
## Mode Transition Signals
|
|
515
|
+
|
|
516
|
+
| Signal | Switch To |
|
|
517
|
+
|--------|-----------|
|
|
518
|
+
| User says "just fix it" | Vibe |
|
|
519
|
+
| Single file change needed | Vibe |
|
|
520
|
+
| Requirements already clear | Plan |
|
|
521
|
+
| "Don't need full spec" | Plan |
|
|
522
|
+
| Time pressure explicit | Plan or Vibe |
|
|
523
|
+
|
|
524
|
+
## The Spec Contract
|
|
525
|
+
|
|
526
|
+
```
|
|
527
|
+
┌─────────────────────────────────────────────┐
|
|
528
|
+
│ THE SPEC MODE CONTRACT │
|
|
529
|
+
├─────────────────────────────────────────────┤
|
|
530
|
+
│ ✓ Complete 6 phases │
|
|
531
|
+
│ ✓ Checkpoint at each phase │
|
|
532
|
+
│ ✓ Document all decisions │
|
|
533
|
+
│ ✓ Trace requirements to tasks │
|
|
534
|
+
│ ✓ Validate before implementing │
|
|
535
|
+
│ ✗ NO skipping phases │
|
|
536
|
+
│ ✗ NO code before Phase 6 │
|
|
537
|
+
│ ✗ NO proceeding without approval │
|
|
538
|
+
└─────────────────────────────────────────────┘
|
|
539
|
+
```
|