spec-lite 1.0.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/bin/cli.js +26 -0
- package/package.json +20 -0
- package/skills/planning-and-task-breakdown/SKILL.md +249 -0
- package/skills/scaffold/SKILL.md +294 -0
- package/skills/spec-domain/SKILL.md +176 -0
- package/skills/spec-new/SKILL.md +263 -0
- package/skills/spec-plan/SKILL.md +193 -0
- package/skills/spec-prd/SKILL.md +176 -0
- package/skills/spec-sad/SKILL.md +202 -0
- package/skills/spec-tech/SKILL.md +195 -0
- package/skills/test-driven-development/SKILL.md +379 -0
- package/templates/integrations/plan-template.md +42 -0
- package/templates/integrations/spec-template.md +68 -0
- package/templates/integrations/tech-template.md +59 -0
- package/templates/integrations/todo-template.md +22 -0
- package/templates/main/domain-template.md +60 -0
- package/templates/main/feature/fdd-template.md +55 -0
- package/templates/main/feature/frd-template.md +73 -0
- package/templates/main/prd-template.md +53 -0
- package/templates/main/sad-template.md +68 -0
package/bin/cli.js
ADDED
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
import { cpSync, mkdirSync, existsSync } from 'fs'
|
|
3
|
+
import { join, dirname } from 'path'
|
|
4
|
+
import { fileURLToPath } from 'url'
|
|
5
|
+
|
|
6
|
+
const __dirname = dirname(fileURLToPath(import.meta.url))
|
|
7
|
+
const cwd = process.cwd()
|
|
8
|
+
const [,, command] = process.argv
|
|
9
|
+
|
|
10
|
+
if (command === 'install') {
|
|
11
|
+
const pkgRoot = join(__dirname, '..')
|
|
12
|
+
const claudeDir = join(cwd, '.claude')
|
|
13
|
+
|
|
14
|
+
mkdirSync(claudeDir, { recursive: true })
|
|
15
|
+
|
|
16
|
+
// Copy skills → .claude/skills/
|
|
17
|
+
cpSync(join(pkgRoot, 'skills'), join(claudeDir, 'skills'), { recursive: true })
|
|
18
|
+
console.log('✓ skills → .claude/skills/')
|
|
19
|
+
|
|
20
|
+
// Copy templates → .claude/templates/
|
|
21
|
+
cpSync(join(pkgRoot, 'templates'), join(claudeDir, 'templates'), { recursive: true })
|
|
22
|
+
console.log('✓ templates → .claude/templates/')
|
|
23
|
+
} else {
|
|
24
|
+
console.log('Usage: npx @torus-engineering/spec-lite install')
|
|
25
|
+
process.exit(1)
|
|
26
|
+
}
|
package/package.json
ADDED
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "spec-lite",
|
|
3
|
+
"version": "1.0.0",
|
|
4
|
+
"description": "Spec-driven development kit for Claude Code",
|
|
5
|
+
"type": "module",
|
|
6
|
+
"bin": {
|
|
7
|
+
"spec-lite": "./bin/cli.js"
|
|
8
|
+
},
|
|
9
|
+
"files": [
|
|
10
|
+
"bin/",
|
|
11
|
+
"skills/",
|
|
12
|
+
"templates/"
|
|
13
|
+
],
|
|
14
|
+
"engines": {
|
|
15
|
+
"node": ">=18"
|
|
16
|
+
},
|
|
17
|
+
"publishConfig": {
|
|
18
|
+
"access": "public"
|
|
19
|
+
}
|
|
20
|
+
}
|
|
@@ -0,0 +1,249 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: planning-and-task-breakdown
|
|
3
|
+
description: Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Planning and Task Breakdown
|
|
7
|
+
|
|
8
|
+
## Overview
|
|
9
|
+
|
|
10
|
+
Decompose work into small, verifiable tasks with explicit acceptance criteria. Good task breakdown is the difference between an agent that completes work reliably and one that produces a tangled mess. Every task should be small enough to implement, test, and verify in a single focused session.
|
|
11
|
+
|
|
12
|
+
## When to Use
|
|
13
|
+
|
|
14
|
+
- You have a spec and need to break it into implementable units
|
|
15
|
+
- A task feels too large or vague to start
|
|
16
|
+
- Work needs to be parallelized across multiple agents or sessions
|
|
17
|
+
- You need to communicate scope to a human
|
|
18
|
+
- The implementation order isn't obvious
|
|
19
|
+
|
|
20
|
+
**When NOT to use:** Single-file changes with obvious scope, or when the spec already contains well-defined tasks.
|
|
21
|
+
|
|
22
|
+
## The Planning Process
|
|
23
|
+
|
|
24
|
+
### Step 1: Enter Plan Mode
|
|
25
|
+
|
|
26
|
+
Before writing any code, operate in read-only mode:
|
|
27
|
+
|
|
28
|
+
- Read the spec and relevant codebase sections
|
|
29
|
+
- Identify existing patterns and conventions
|
|
30
|
+
- Map dependencies between components
|
|
31
|
+
- Note risks and unknowns
|
|
32
|
+
|
|
33
|
+
**Do NOT write code during planning.** The output is a plan document, not implementation.
|
|
34
|
+
|
|
35
|
+
### Step 2: Identify the Dependency Graph
|
|
36
|
+
|
|
37
|
+
Map what depends on what:
|
|
38
|
+
|
|
39
|
+
```
|
|
40
|
+
Database schema
|
|
41
|
+
│
|
|
42
|
+
├── API models/types
|
|
43
|
+
│ │
|
|
44
|
+
│ ├── API endpoints
|
|
45
|
+
│ │ │
|
|
46
|
+
│ │ └── Frontend API client
|
|
47
|
+
│ │ │
|
|
48
|
+
│ │ └── UI components
|
|
49
|
+
│ │
|
|
50
|
+
│ └── Validation logic
|
|
51
|
+
│
|
|
52
|
+
└── Seed data / migrations
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
Implementation order follows the dependency graph bottom-up: build foundations first.
|
|
56
|
+
|
|
57
|
+
### Step 3: Slice Vertically
|
|
58
|
+
|
|
59
|
+
Instead of building all the database, then all the API, then all the UI — build one complete feature path at a time:
|
|
60
|
+
|
|
61
|
+
**Bad (horizontal slicing):**
|
|
62
|
+
```
|
|
63
|
+
Task 1: Build entire database schema
|
|
64
|
+
Task 2: Build all API endpoints
|
|
65
|
+
Task 3: Build all UI components
|
|
66
|
+
Task 4: Connect everything
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
**Good (vertical slicing):**
|
|
70
|
+
```
|
|
71
|
+
Task 1: User can create an account (schema + API + UI for registration)
|
|
72
|
+
Task 2: User can log in (auth schema + API + UI for login)
|
|
73
|
+
Task 3: User can create a task (task schema + API + UI for creation)
|
|
74
|
+
Task 4: User can view task list (query + API + UI for list view)
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
Each vertical slice delivers working, testable functionality.
|
|
78
|
+
|
|
79
|
+
### Step 4: Write Tasks
|
|
80
|
+
|
|
81
|
+
Each task follows this structure:
|
|
82
|
+
|
|
83
|
+
```markdown
|
|
84
|
+
#### T001 — [Short descriptive title, starts with a verb]
|
|
85
|
+
|
|
86
|
+
[One paragraph describing what this task delivers]
|
|
87
|
+
|
|
88
|
+
**depends:** [T-IDs this task depends on, or —]
|
|
89
|
+
**verify:** [AC-001, AC-002] [specific test cases that must pass — e.g. unit tests: valid input, missing field 400]
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
**`verify:` field rules:**
|
|
93
|
+
|
|
94
|
+
| Task type | verify? | Example |
|
|
95
|
+
|-----------|---------|---------|
|
|
96
|
+
| Has behavior (service, endpoint, validation) | Yes — specific unit tests | `**verify:** [AC-001] unit tests — valid input, missing field 400, duplicate 409` |
|
|
97
|
+
| Pure infrastructure (migration, config) | Yes — smoke check | `**verify:** migration runs clean, rollback succeeds` |
|
|
98
|
+
| Task IS the test (Verification phase) | Yes — result | `**verify:** integration tests pass — happy path + error cases` |
|
|
99
|
+
| No behavior (docs, rename, comment) | No | *(omit field)* |
|
|
100
|
+
|
|
101
|
+
Rule: add `verify:` when *"if this code were deleted, which test would fail?"* can be answered. Must be specific enough for an agent to know what to write — not just "tests pass". Reference AC IDs when the task covers specific criteria.
|
|
102
|
+
|
|
103
|
+
### Step 5: Order and Phases
|
|
104
|
+
|
|
105
|
+
Arrange tasks so that:
|
|
106
|
+
|
|
107
|
+
1. Dependencies are satisfied (build foundation first)
|
|
108
|
+
2. Each task leaves the system in a working state
|
|
109
|
+
3. High-risk tasks are early (fail fast)
|
|
110
|
+
|
|
111
|
+
**Final phase is always Verification** — contains integration/e2e tests that can only be written after all components are complete. Replace checkpoint markers with this phase:
|
|
112
|
+
|
|
113
|
+
```markdown
|
|
114
|
+
### Phase N: Verification
|
|
115
|
+
|
|
116
|
+
#### T00N — [integration test description]
|
|
117
|
+
|
|
118
|
+
[Describe the end-to-end flow being tested]
|
|
119
|
+
|
|
120
|
+
**depends:** T001, T002, ...
|
|
121
|
+
**verify:** integration tests pass — [happy path + error cases spanning multiple components]
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
## Task Sizing Guidelines
|
|
125
|
+
|
|
126
|
+
| Size | Files | Scope | Example |
|
|
127
|
+
|------|-------|-------|---------|
|
|
128
|
+
| **XS** | 1 | Single function or config change | Add a validation rule |
|
|
129
|
+
| **S** | 1-2 | One component or endpoint | Add a new API endpoint |
|
|
130
|
+
| **M** | 3-5 | One feature slice | User registration flow |
|
|
131
|
+
| **L** | 5-8 | Multi-component feature | Search with filtering and pagination |
|
|
132
|
+
| **XL** | 8+ | **Too large — break it down further** | — |
|
|
133
|
+
|
|
134
|
+
If a task is L or larger, it should be broken into smaller tasks. An agent performs best on S and M tasks.
|
|
135
|
+
|
|
136
|
+
**When to break a task down further:**
|
|
137
|
+
- It would take more than one focused session (roughly 2+ hours of agent work)
|
|
138
|
+
- You cannot describe the acceptance criteria in 3 or fewer bullet points
|
|
139
|
+
- It touches two or more independent subsystems (e.g., auth and billing)
|
|
140
|
+
- You find yourself writing "and" in the task title (a sign it is two tasks)
|
|
141
|
+
|
|
142
|
+
## Output Files
|
|
143
|
+
|
|
144
|
+
Save the plan as two files:
|
|
145
|
+
|
|
146
|
+
- **`plan.md`** — design document: per-task description, dependencies, verify conditions. Stable after approval — not modified during execution.
|
|
147
|
+
- **`todo.md`** — execution tracker: flat checklist. Agent ticks `[x]` after each task is done.
|
|
148
|
+
|
|
149
|
+
## Plan Document Template
|
|
150
|
+
|
|
151
|
+
**`plan.md`:**
|
|
152
|
+
|
|
153
|
+
```markdown
|
|
154
|
+
---
|
|
155
|
+
id: "{slug}"
|
|
156
|
+
slug: "{slug}"
|
|
157
|
+
title: "{title} — Implementation Plan"
|
|
158
|
+
features: ["{F-XXX}"]
|
|
159
|
+
status: draft
|
|
160
|
+
created: {YYYY-MM-DD}
|
|
161
|
+
---
|
|
162
|
+
|
|
163
|
+
## Summary
|
|
164
|
+
|
|
165
|
+
[2-3 sentences on what will be implemented]
|
|
166
|
+
|
|
167
|
+
## Tasks
|
|
168
|
+
|
|
169
|
+
### Phase 1: [Phase name]
|
|
170
|
+
|
|
171
|
+
#### T001 — [task title]
|
|
172
|
+
|
|
173
|
+
[What this task delivers]
|
|
174
|
+
|
|
175
|
+
**depends:** —
|
|
176
|
+
**verify:** [verify condition or omit if no behavior]
|
|
177
|
+
|
|
178
|
+
#### T002 — [task title]
|
|
179
|
+
|
|
180
|
+
[What this task delivers]
|
|
181
|
+
|
|
182
|
+
**depends:** T001
|
|
183
|
+
**verify:** [AC-001] unit tests — [specific cases]
|
|
184
|
+
|
|
185
|
+
### Phase N: Verification
|
|
186
|
+
|
|
187
|
+
#### T00N — [integration test description]
|
|
188
|
+
|
|
189
|
+
[End-to-end flow being tested]
|
|
190
|
+
|
|
191
|
+
**depends:** T001, T002
|
|
192
|
+
**verify:** integration tests pass — [happy path + error cases]
|
|
193
|
+
|
|
194
|
+
## Definition of Done
|
|
195
|
+
|
|
196
|
+
- [ ] [AC from spec — concise, preserve intent]
|
|
197
|
+
- [ ] All unit tests pass
|
|
198
|
+
- [ ] All integration tests pass
|
|
199
|
+
```
|
|
200
|
+
|
|
201
|
+
**`todo.md`:**
|
|
202
|
+
|
|
203
|
+
```markdown
|
|
204
|
+
# [title] — Todo
|
|
205
|
+
|
|
206
|
+
### Phase 1: [Phase name]
|
|
207
|
+
- [ ] T001 — [task title]
|
|
208
|
+
- [ ] T002 — [task title]
|
|
209
|
+
|
|
210
|
+
### Phase N: Verification
|
|
211
|
+
- [ ] T00N — [integration test description]
|
|
212
|
+
```
|
|
213
|
+
|
|
214
|
+
## Parallelization Opportunities
|
|
215
|
+
|
|
216
|
+
When multiple agents or sessions are available:
|
|
217
|
+
|
|
218
|
+
- **Safe to parallelize:** Independent feature slices, tests for already-implemented features, documentation
|
|
219
|
+
- **Must be sequential:** Database migrations, shared state changes, dependency chains
|
|
220
|
+
- **Needs coordination:** Features that share an API contract (define the contract first, then parallelize)
|
|
221
|
+
|
|
222
|
+
## Common Rationalizations
|
|
223
|
+
|
|
224
|
+
| Rationalization | Reality |
|
|
225
|
+
|---|---|
|
|
226
|
+
| "I'll figure it out as I go" | That's how you end up with a tangled mess and rework. 10 minutes of planning saves hours. |
|
|
227
|
+
| "The tasks are obvious" | Write them down anyway. Explicit tasks surface hidden dependencies and forgotten edge cases. |
|
|
228
|
+
| "Planning is overhead" | Planning is the task. Implementation without a plan is just typing. |
|
|
229
|
+
| "I can hold it all in my head" | Context windows are finite. Written plans survive session boundaries and compaction. |
|
|
230
|
+
|
|
231
|
+
## Red Flags
|
|
232
|
+
|
|
233
|
+
- Starting implementation without a written task list
|
|
234
|
+
- Tasks that say "implement the feature" without acceptance criteria
|
|
235
|
+
- No verification steps in the plan
|
|
236
|
+
- All tasks are XL-sized
|
|
237
|
+
- No checkpoints between tasks
|
|
238
|
+
- Dependency order isn't considered
|
|
239
|
+
|
|
240
|
+
## Verification
|
|
241
|
+
|
|
242
|
+
Before starting implementation, confirm:
|
|
243
|
+
|
|
244
|
+
- [ ] Every task with behavior has a `verify:` field with specific test cases
|
|
245
|
+
- [ ] Task dependencies are identified and ordered correctly
|
|
246
|
+
- [ ] No task touches more than ~5 files
|
|
247
|
+
- [ ] Final phase is Verification (integration/e2e tests)
|
|
248
|
+
- [ ] todo.md is in sync with plan.md (same phases, same task IDs)
|
|
249
|
+
- [ ] The human has reviewed and approved the plan
|
|
@@ -0,0 +1,294 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: scaffold
|
|
3
|
+
description: Khởi tạo project scaffold dựa trên sad.md — tạo plan.md và todo.md rồi thực thi theo plan. Chạy một lần duy nhất trước khi implement integration đầu tiên.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# scaffold
|
|
7
|
+
|
|
8
|
+
## Overview
|
|
9
|
+
|
|
10
|
+
Đọc `specs/main/sad.md`, phân rã thành plan.md và todo.md cho bước khởi tạo project, sau đó thực thi từng task theo thứ tự.
|
|
11
|
+
|
|
12
|
+
Khác với `/spec-plan` — skill này không dừng lại sau khi sinh plan. Sau khi user confirm, nó execute luôn.
|
|
13
|
+
|
|
14
|
+
## When to Use
|
|
15
|
+
|
|
16
|
+
- Project chưa được khởi tạo
|
|
17
|
+
- Muốn có một record rõ ràng về cách project được setup
|
|
18
|
+
|
|
19
|
+
## When NOT to Use
|
|
20
|
+
|
|
21
|
+
- `specs/main/sad.md` chưa có → chạy `/spec-sad` trước
|
|
22
|
+
- Project đã được khởi tạo rồi → implement trực tiếp
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## Process
|
|
27
|
+
|
|
28
|
+
### Bước 1: Kiểm tra preconditions
|
|
29
|
+
|
|
30
|
+
Đọc `specs/main/sad.md`:
|
|
31
|
+
|
|
32
|
+
- **Không tồn tại hoặc là template** → dừng ngay:
|
|
33
|
+
> `sad.md` chưa có nội dung. Hãy chạy `/spec-sad` trước.
|
|
34
|
+
|
|
35
|
+
- **Đã có nội dung** → tiếp tục.
|
|
36
|
+
|
|
37
|
+
Kiểm tra `specs/integrations/000-scaffold/`:
|
|
38
|
+
|
|
39
|
+
- **Không có plan.md và todo.md** → tiếp tục Bước 2 (sinh mới).
|
|
40
|
+
|
|
41
|
+
- **Có plan.md nhưng không có todo.md** → hỏi:
|
|
42
|
+
> `plan.md` đã tồn tại nhưng thiếu `todo.md`. Ghi đè và chạy lại từ đầu?
|
|
43
|
+
|
|
44
|
+
- **Có cả plan.md và todo.md** → đọc todo.md, đếm tasks:
|
|
45
|
+
- Nếu **tất cả tasks đã `[x]`** → thông báo:
|
|
46
|
+
> Scaffold đã hoàn thành ({N}/{N} tasks). Muốn chạy lại từ đầu?
|
|
47
|
+
- Nếu user muốn chạy lại → tiếp tục Bước 2.
|
|
48
|
+
- Nếu không → dừng.
|
|
49
|
+
- Nếu **có tasks chưa done** → hiển thị tiến độ:
|
|
50
|
+
```
|
|
51
|
+
Scaffold đang ở giữa chừng ({done}/{total} tasks done):
|
|
52
|
+
✓ T001 · {task title}
|
|
53
|
+
✓ T002 · {task title}
|
|
54
|
+
○ T003 · {task title} ← chưa làm
|
|
55
|
+
○ T004 · {task title}
|
|
56
|
+
|
|
57
|
+
Tiếp tục từ T003?
|
|
58
|
+
```
|
|
59
|
+
- Nếu user confirm → **nhảy thẳng đến Bước 6**, bắt đầu từ task đầu tiên chưa `[x]`.
|
|
60
|
+
- Nếu user muốn chạy lại → tiếp tục Bước 2.
|
|
61
|
+
|
|
62
|
+
---
|
|
63
|
+
|
|
64
|
+
### Bước 2: Load context từ sad.md
|
|
65
|
+
|
|
66
|
+
Extract các thông tin cần thiết để sinh plan:
|
|
67
|
+
|
|
68
|
+
- **Tech Stack** — từng layer và technology
|
|
69
|
+
- **Infrastructure Overview** — môi trường, provider, deployment strategy
|
|
70
|
+
- **Architectural Guardrails** — các constraints ảnh hưởng đến project setup
|
|
71
|
+
|
|
72
|
+
Surface context và hỏi những gì sad.md không có:
|
|
73
|
+
|
|
74
|
+
```
|
|
75
|
+
TỪ SAD.MD TÔI HIỂU:
|
|
76
|
+
- Framework: {tech stack}
|
|
77
|
+
- Database: {tech stack}
|
|
78
|
+
- Deploy: {infrastructure}
|
|
79
|
+
- Guardrails liên quan đến scaffold: {list GUARD IDs}
|
|
80
|
+
|
|
81
|
+
CẦN THÊM:
|
|
82
|
+
1. Project name là gì?
|
|
83
|
+
2. Package manager? (npm / pnpm / yarn) [default: npm]
|
|
84
|
+
→ Sửa lại nếu sai trước khi tiếp tục.
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
Chỉ hỏi những gì thực sự không thể suy ra từ sad.md.
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
### Bước 3: Sinh plan.md và todo.md
|
|
92
|
+
|
|
93
|
+
Phân rã scaffold thành tasks có thứ tự. Mỗi task phải:
|
|
94
|
+
- Thực thi được bởi agent (chạy command hoặc tạo file)
|
|
95
|
+
- Có verification rõ ràng trước khi mark done
|
|
96
|
+
- Phụ thuộc đúng thứ tự
|
|
97
|
+
|
|
98
|
+
**Dependency graph điển hình cho scaffold:**
|
|
99
|
+
|
|
100
|
+
```
|
|
101
|
+
Verify (project chạy được)
|
|
102
|
+
│
|
|
103
|
+
Directory structure
|
|
104
|
+
│
|
|
105
|
+
Config & env vars ──── ORM init
|
|
106
|
+
│
|
|
107
|
+
Install dependencies
|
|
108
|
+
│
|
|
109
|
+
Initialize framework
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
**Phases điển hình** (điều chỉnh theo tech stack thực tế):
|
|
113
|
+
|
|
114
|
+
- **Phase 1: Initialize** — khởi tạo project framework (create-next-app, create-vite, django-admin startproject, v.v.)
|
|
115
|
+
- **Phase 2: Dependencies** — cài packages theo tech stack và guardrails
|
|
116
|
+
- **Phase 3: Configuration** — init ORM, setup env file template, config files
|
|
117
|
+
- **Phase 4: Directory Structure** — tạo thư mục theo layer architecture trong sad.md
|
|
118
|
+
- **Phase 5: Verify** — project chạy được, kết nối DB thành công
|
|
119
|
+
|
|
120
|
+
**Output format** (theo spec-plan convention):
|
|
121
|
+
|
|
122
|
+
```markdown
|
|
123
|
+
---
|
|
124
|
+
id: "000-scaffold"
|
|
125
|
+
slug: "000-scaffold"
|
|
126
|
+
title: "Project Scaffold — Setup Plan"
|
|
127
|
+
status: draft
|
|
128
|
+
created: {YYYY-MM-DD}
|
|
129
|
+
---
|
|
130
|
+
|
|
131
|
+
## Summary
|
|
132
|
+
|
|
133
|
+
{2-3 câu mô tả những gì sẽ được khởi tạo, dựa trên tech stack từ sad.md}
|
|
134
|
+
|
|
135
|
+
## Dependency Graph
|
|
136
|
+
|
|
137
|
+
{ASCII diagram — bottom = foundations, top = verify}
|
|
138
|
+
|
|
139
|
+
## Tasks
|
|
140
|
+
|
|
141
|
+
### Phase 1: Initialize
|
|
142
|
+
|
|
143
|
+
#### T001 · {task title — starts with a verb}
|
|
144
|
+
|
|
145
|
+
**Mục tiêu:** {One sentence: task này deliver gì}
|
|
146
|
+
|
|
147
|
+
**depends:** —
|
|
148
|
+
|
|
149
|
+
**Các bước:**
|
|
150
|
+
1. {Command hoặc action cụ thể}
|
|
151
|
+
2. {Command hoặc action cụ thể}
|
|
152
|
+
|
|
153
|
+
**Verification:**
|
|
154
|
+
- [ ] {Kết quả quan sát được sau khi task hoàn thành}
|
|
155
|
+
|
|
156
|
+
---
|
|
157
|
+
|
|
158
|
+
...
|
|
159
|
+
|
|
160
|
+
### Phase N: Verify
|
|
161
|
+
|
|
162
|
+
#### T00N · Verify scaffold hoạt động
|
|
163
|
+
|
|
164
|
+
**Mục tiêu:** Xác nhận project chạy được và mọi connections hoạt động.
|
|
165
|
+
|
|
166
|
+
**depends:** T001, T002, ...
|
|
167
|
+
|
|
168
|
+
**Các bước:**
|
|
169
|
+
1. Chạy dev server
|
|
170
|
+
2. Verify kết nối database (nếu có)
|
|
171
|
+
|
|
172
|
+
**Verification:**
|
|
173
|
+
- [ ] Dev server start không lỗi
|
|
174
|
+
- [ ] {DB connection verify nếu applicable}
|
|
175
|
+
|
|
176
|
+
---
|
|
177
|
+
|
|
178
|
+
## Definition of Done
|
|
179
|
+
|
|
180
|
+
- [ ] Project khởi chạy thành công ở local
|
|
181
|
+
- [ ] Tất cả dependencies đã được install
|
|
182
|
+
- [ ] Directory structure khớp với architecture trong sad.md
|
|
183
|
+
- [ ] Env template có đủ variables cần thiết
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
**todo.md format:**
|
|
187
|
+
|
|
188
|
+
```markdown
|
|
189
|
+
# Project Scaffold — Todo
|
|
190
|
+
|
|
191
|
+
### Phase 1: Initialize
|
|
192
|
+
- [ ] T001 · {task title}
|
|
193
|
+
|
|
194
|
+
### Phase 2: Dependencies
|
|
195
|
+
- [ ] T002 · {task title}
|
|
196
|
+
|
|
197
|
+
...
|
|
198
|
+
|
|
199
|
+
### Phase N: Verify
|
|
200
|
+
- [ ] T00N · Verify scaffold hoạt động
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
Hiển thị draft cho user — **chưa ghi file**.
|
|
204
|
+
|
|
205
|
+
---
|
|
206
|
+
|
|
207
|
+
### Bước 4: Review — xác nhận với user
|
|
208
|
+
|
|
209
|
+
> Draft trên đúng chưa? Confirm để ghi file và bắt đầu thực thi.
|
|
210
|
+
|
|
211
|
+
Chỉ tiếp tục sau khi user confirm. Nếu cần chỉnh → cập nhật draft → hỏi lại.
|
|
212
|
+
|
|
213
|
+
---
|
|
214
|
+
|
|
215
|
+
### Bước 5: Ghi file
|
|
216
|
+
|
|
217
|
+
Tạo thư mục `specs/integrations/000-scaffold/` nếu chưa có.
|
|
218
|
+
|
|
219
|
+
Ghi:
|
|
220
|
+
- `specs/integrations/000-scaffold/plan.md`
|
|
221
|
+
- `specs/integrations/000-scaffold/todo.md`
|
|
222
|
+
|
|
223
|
+
---
|
|
224
|
+
|
|
225
|
+
### Bước 6: Thực thi plan
|
|
226
|
+
|
|
227
|
+
Thực thi từng task theo thứ tự trong plan.md:
|
|
228
|
+
|
|
229
|
+
```
|
|
230
|
+
Bắt đầu thực thi scaffold...
|
|
231
|
+
|
|
232
|
+
[T001] {task title}
|
|
233
|
+
→ {action}
|
|
234
|
+
✓ Verification passed
|
|
235
|
+
✓ todo.md updated
|
|
236
|
+
|
|
237
|
+
[T002] {task title}
|
|
238
|
+
→ {action}
|
|
239
|
+
✓ Verification passed
|
|
240
|
+
✓ todo.md updated
|
|
241
|
+
|
|
242
|
+
...
|
|
243
|
+
```
|
|
244
|
+
|
|
245
|
+
**Rules:**
|
|
246
|
+
|
|
247
|
+
1. Thực thi đúng thứ tự — không skip task, không parallelize trừ khi `depends` cho phép
|
|
248
|
+
2. Sau mỗi task: chạy verification steps trong `**Verification:**`
|
|
249
|
+
3. Nếu verification pass → mark `[x]` trong todo.md → tiếp tục task tiếp theo
|
|
250
|
+
4. Nếu verification fail → dừng ngay, báo lỗi cụ thể, không tiếp tục:
|
|
251
|
+
|
|
252
|
+
```
|
|
253
|
+
✗ T002 · {task title} — FAILED
|
|
254
|
+
|
|
255
|
+
Lỗi: {error message}
|
|
256
|
+
Bước đã thực thi: {bước số mấy}
|
|
257
|
+
|
|
258
|
+
Cần xử lý thủ công trước khi tiếp tục.
|
|
259
|
+
```
|
|
260
|
+
|
|
261
|
+
5. Không tự ý bỏ qua lỗi hoặc retry quá 1 lần
|
|
262
|
+
|
|
263
|
+
---
|
|
264
|
+
|
|
265
|
+
### Bước 7: Hoàn thành
|
|
266
|
+
|
|
267
|
+
Sau khi tất cả tasks pass:
|
|
268
|
+
|
|
269
|
+
```
|
|
270
|
+
✓ Scaffold hoàn thành
|
|
271
|
+
|
|
272
|
+
specs/integrations/000-scaffold/plan.md
|
|
273
|
+
specs/integrations/000-scaffold/todo.md
|
|
274
|
+
|
|
275
|
+
Tất cả tasks: {N}/{N} ✓
|
|
276
|
+
|
|
277
|
+
Bước tiếp theo:
|
|
278
|
+
- Điền các giá trị thực vào .env.local
|
|
279
|
+
{nếu có manual steps} - {manual step cần làm}
|
|
280
|
+
- /spec-new → bắt đầu integration đầu tiên
|
|
281
|
+
```
|
|
282
|
+
|
|
283
|
+
---
|
|
284
|
+
|
|
285
|
+
## Verification
|
|
286
|
+
|
|
287
|
+
Trước khi kết thúc, kiểm tra:
|
|
288
|
+
|
|
289
|
+
- [ ] sad.md đã được đọc và tech stack được extract đúng
|
|
290
|
+
- [ ] plan.md có Dependency Graph
|
|
291
|
+
- [ ] Mỗi task có: Mục tiêu / depends / Các bước / Verification
|
|
292
|
+
- [ ] todo.md đồng bộ với plan.md
|
|
293
|
+
- [ ] User đã confirm plan trước khi execute
|
|
294
|
+
- [ ] Mọi task verification pass trước khi mark done
|