spec-lite 1.0.0

package/skills/spec-domain/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: spec-domain
+description: Điền hoặc cập nhật domain.md — Domain Knowledge (entities, business rules, terminology). Dùng sau khi prd.md đã có nội dung.
+---
+
+# spec-domain
+
+## Overview
+
+Tạo nội dung cho `specs/main/domain.md` thông qua interview có cấu trúc. Domain là ngôn ngữ chung của hệ thống — nó định nghĩa các khái niệm business, entities, business rules, và events mà toàn bộ team (cả business lẫn tech) dùng chung.
+
+Domain không chứa: implementation details, DB schema, framework-specific code, hay bất cứ thứ gì thuộc về `sad.md`, `fdd.md`.
+
+## When to Use
+
+- `domain.md` chưa có hoặc còn rỗng, và `prd.md` đã có nội dung
+- Cần bổ sung entity hoặc business rule mới phát sinh từ một integration
+- Cascade proposals từ `spec.md` hoặc `tech.md` yêu cầu cập nhật domain
+
+## When NOT to Use
+
+- `prd.md` chưa có nội dung → chạy `/spec-prd` trước
+- Đang muốn thiết kế kiến trúc kỹ thuật → dùng `/spec-sad`
+- Đang muốn định nghĩa feature-level requirements → dùng `/spec-frd`
+
+---
+
+## Process
+
+### Bước 1: Kiểm tra preconditions
+
+**Đọc `specs/main/prd.md`:**
+
+- **Chưa tồn tại hoặc là template** → dừng ngay:
+  > `prd.md` chưa có nội dung. Hãy chạy `/spec-prd` trước để có PRD trước khi định nghĩa domain.
+
+- **Đã có nội dung** → đọc để lấy context: scope, problem statement, target users. Dùng làm nền để hỏi về entities.
+
+**Đọc `specs/main/domain.md`:**
+
+- **Chưa tồn tại** → tạo thư mục `specs/main/` nếu chưa có, tiến hành Bước 2 (full interview).
+
+- **Đã có nội dung thực** → quét toàn bộ sections, hiển thị trạng thái từng section, rồi hỏi user muốn làm gì.
+
+  **Các sections cần quét** (theo thứ tự):
+
+  | # | Section | Có nội dung thực? |
+  | --- | --- | --- |
+  | 1 | Terminology | ✓ đã có / ✗ trống/thiếu |
+  | 2 | Entities | ✓ đã có / ✗ trống/thiếu |
+  | 3 | Business Rules | ✓ đã có / ✗ trống/thiếu |
+  | 4 | Domain Events | ✓ đã có / ✗ trống/thiếu |
+
+  Một section được coi là **trống/thiếu** nếu: không tồn tại trong file, hoặc chỉ chứa placeholder template (dấu `{}`), hoặc không có dòng nội dung thực. Ngoài các sections trên, **ghi nhận các sections thừa** — những `##` heading có trong file nhưng không có trong template.
+
+  Sau khi quét, liệt kê tất cả sections **theo đúng thứ tự xuất hiện trong file**, đánh số liên tục:
+
+  ```
+  domain.md hiện tại:
+    [1] Terminology         ✓ đã có
+    [2] Entities            ✓ đã có
+    [3] Business Rules      ✗ chưa có — cần bổ sung
+    [4] Risks               ⚠ không có trong template
+    [5] Domain Events       ✓ đã có
+    [A] Interview tất cả sections
+
+  Chọn số hoặc A:
+  ```
+
+  - User chọn số section thuộc template → interview section đó rồi merge vào file.
+  - User chọn số section thừa (⚠) → xoá section đó khỏi file ngay, không hỏi thêm.
+  - User chọn A → interview tuần tự tất cả sections thuộc template (sections thừa không bị đụng tới).
+
+---
+
+### Bước 2: Gather — interview có cấu trúc
+
+Trước khi hỏi, tóm tắt ngắn context đọc được từ `prd.md` (nếu có) và surface assumptions:
+
+```
+TỪ PRD TÔI HIỂU:
+- Hệ thống giải quyết: {problem statement ngắn gọn}
+- Các khái niệm tôi thấy xuất hiện: {list terms từ prd}
+
+ASSUMPTIONS TÔI ĐANG ĐẶT RA:
+1. {assumption 1}
+2. {assumption 2}
+→ Sửa lại nếu sai trước khi tiếp tục.
+```
+
+Sau đó hỏi tuần tự từng phần — không hỏi tất cả cùng lúc:
+
+**Phần 1 — Terminology:**
+> Có thuật ngữ nghiệp vụ nào đặc thù cần định nghĩa rõ không? (Ví dụ: "đơn hàng" trong hệ thống này nghĩa là gì chính xác?)
+> Liệt kê những term hay bị dùng sai hoặc có nhiều cách hiểu.
+
+**Phần 2 — Entities:**
+> Hệ thống làm việc với những "đối tượng" nghiệp vụ nào? (Ví dụ: User, Order, Product...)
+> Với mỗi entity: nó đại diện cho cái gì trong business? Attributes nào quan trọng? Có lifecycle (state machine) không?
+
+Với mỗi entity được đề cập, hỏi tiếp:
+> Entity này có trạng thái (state) thay đổi theo thời gian không? Nếu có, các trạng thái đó là gì và khi nào chuyển đổi?
+
+**Phần 3 — Business Rules:**
+> Có quy tắc nghiệp vụ nào bất biến không? (Ví dụ: "Không thể hủy đơn hàng đã giao", "User chưa verify không được thanh toán")
+> Ghi theo format: rule — khi nào apply — ngoại lệ nếu có.
+
+**Phần 4 — Domain Events:** *(hỏi nếu hệ thống có event-driven behavior)*
+> Có sự kiện nghiệp vụ nào quan trọng cần track không? (Ví dụ: OrderPlaced, PaymentFailed...)
+> Khi nào xảy ra? Data gì đi kèm?
+
+Nếu câu trả lời vague → hỏi lại. Ví dụ:
+- "có nhiều loại user" → "liệt kê cụ thể từng loại và điểm khác nhau giữa chúng là gì?"
+- "đơn hàng có nhiều trạng thái" → "liệt kê hết các trạng thái và vẽ luồng chuyển đổi"
+
+---
+
+### Bước 3: Write — sinh draft
+
+Dùng `.claude/templates/main/domain-template.md` làm skeleton, điền nội dung từ interview vào từng section.
+
+Hiển thị draft cho user xem — **chưa ghi file**.
+
+---
+
+### Bước 4: Review — xác nhận với user
+
+Trình bày draft và hỏi:
+> Draft Domain trên đã đúng chưa? Có entity nào thiếu, business rule nào sai không?
+
+Chỉ ghi file sau khi user confirm. Nếu user yêu cầu chỉnh sửa → cập nhật draft → hỏi lại.
+
+---
+
+### Bước 5: Save
+
+Ghi nội dung đã được confirm vào `specs/main/domain.md`.
+
+Thông báo kết quả:
+```
+✓ specs/main/domain.md đã được cập nhật (status: draft)
+
+Bước tiếp theo:
+  - /spec-sad → thiết kế kiến trúc kỹ thuật (dùng prd.md + domain.md làm context)
+  - (sau sad) /spec-frd {feature-name} → định nghĩa requirements của từng feature
+```
+
+---
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+| --- | --- |
+| "Entities thì ai cũng biết rồi, không cần ghi" | Entity chưa được viết ra là entity chưa được đồng thuận. Dev và BA có thể hiểu khác nhau. |
+| "Business rules thì ghi trong code thôi" | Business rules trong code không ai đọc được ngoài dev. Domain là ngôn ngữ chung cho cả team. |
+| "State machine phức tạp, thêm sau" | State machine ảnh hưởng trực tiếp đến data model và API design. Thiếu nó là thiếu constraint quan trọng. |
+| "Terminology thì khỏi cần, ai cũng hiểu" | "Order" trong hệ thống bán lẻ khác "Order" trong hệ thống sản xuất. Định nghĩa rõ tránh miscommunication. |
+
+## Red Flags
+
+- Entity chỉ có tên, không có attributes hay mô tả
+- Business rules ghi dưới dạng technical ("validate bằng regex") thay vì business ("số điện thoại phải là số Việt Nam")
+- Terminology section trống trong khi domain có nhiều thuật ngữ đặc thù
+- Attributes dùng DB type (`VARCHAR`, `INT`) thay vì business type (`text`, `number`)
+
+## Verification
+
+Trước khi kết thúc, kiểm tra:
+
+- [ ] Frontmatter đầy đủ và đúng schema
+- [ ] Mỗi term trong Terminology có definition rõ ràng, không mơ hồ
+- [ ] Mỗi entity có mô tả business context (không chỉ là tên)
+- [ ] Attributes dùng business type, không phải DB type
+- [ ] State machine chỉ có ở entity có lifecycle thực sự
+- [ ] Business rules có ID (`DOM-R01`...), condition, và exception rõ ràng
+- [ ] User đã confirm trước khi file được ghi

package/skills/spec-new/SKILL.md

@@ -0,0 +1,263 @@
+---
+name: spec-new
+description: Tạo spec.md cho một integration mới thông qua interview có cấu trúc. Dùng khi bắt đầu implement một feature hoặc requirement mới. Nhận raw requirement từ argument hoặc chọn feature TODO từ prd.md.
+---
+
+# spec-new
+
+## Overview
+
+Tạo `spec.md` cho một integration mới trong `specs/integrations/{NNN}-{slug}/`.
+
+`spec.md` là functional spec — định nghĩa **what to build**: vấn đề, requirements, acceptance criteria, out of scope. Không chứa technical design.
+
+## When to Use
+
+- Bắt đầu implement một feature mới
+- Có raw requirement chưa được spec hóa
+- Muốn chọn một feature TODO từ prd.md để bắt đầu
+
+## When NOT to Use
+
+- `prd.md` hoặc `domain.md` chưa có → chạy `/spec-prd`, `/spec-domain` trước
+- Muốn thiết kế technical design → dùng `/spec-tech` (cần `spec.md` đã approve trước)
+- Chỉ muốn cập nhật spec đã có → edit file trực tiếp
+
+---
+
+## Process
+
+### Bước 1: Xác định input
+
+**Nếu có ARGUMENT** → đây là raw requirement, chuyển sang Bước 2.
+
+**Nếu không có ARGUMENT:**
+
+Đọc `specs/main/prd.md`. Nếu file không tồn tại hoặc là template rỗng → dừng:
+> `prd.md` chưa có nội dung. Hãy chạy `/spec-prd` trước.
+
+Đọc toàn bộ bảng Features. Hiển thị **tất cả** features kèm trạng thái — không lọc — để thấy rõ feature nào có FRD cần update:
+
+```
+Features trong PRD:
+
+  [1] F-001 — Authentication        (High)    [TODO]
+  [2] F-002 — User Profile          (Medium)  [In Progress]  → frd.md tồn tại
+  [3] F-003 — App Browsing & Opt-in (High)    [TODO]
+  [4] F-004 — Credit System         (High)    [Done]         → frd.md tồn tại
+  [5] F-006 — Admin Panel           (Medium)  [TODO]
+
+Chọn số feature để bắt đầu spec:
+```
+
+Ghi chú `→ frd.md tồn tại` nếu file `specs/main/features/{feature-id}-*/frd.md` đã có.
+
+Nếu tất cả features đều Done → thông báo:
+> Tất cả features trong prd.md đã được implement. Nếu có yêu cầu mới, hãy truyền nó trực tiếp: `/spec-new <yêu cầu>`.
+
+Sau khi user chọn feature:
+
+- Nếu feature **chưa có frd.md** → lấy feature đó làm requirement, chuyển sang Bước 2.
+- Nếu feature **đã có frd.md** → đọc file frd.md, liệt kê các sections và hỏi ngay:
+
+```
+frd.md — F-001 Authentication đã tồn tại.
+Sections hiện có:
+
+  [1] Overview
+  [2] Feature-level Acceptance Criteria
+  [3] User Stories
+  [4] Scope (In Scope / Out of Scope)
+  [5] Dependencies
+  [A] All — viết lại toàn bộ từ đầu
+
+Chọn section cần cập nhật (có thể chọn nhiều, ví dụ: 2 3):
+```
+
+Lưu lại lựa chọn section. Nếu chọn `A` → xử lý như tạo mới toàn bộ. Sau đó chuyển sang Bước 2.
+
+---
+
+### Bước 2: Load context
+
+Load các file sau (bất kể input là raw requirement hay từ prd.md):
+
+- `specs/main/prd.md` — đọc Problem Statement, Target Users, Scope, và mô tả feature liên quan nếu có
+- `specs/main/domain.md` — đọc Entities và Business Rules
+- Nếu input từ prd.md và có `specs/main/features/{feature-id}/frd.md` → đọc User Stories và Acceptance Criteria
+
+Tóm tắt context và surface assumptions:
+
+```
+TỪ PRD & DOMAIN TÔI HIỂU:
+- Vấn đề đang giải quyết: {problem statement ngắn từ prd}
+- Personas liên quan: {từ prd Target Users}
+- Entities liên quan: {từ domain.md}
+{nếu có feature cụ thể} - Feature: {ID} — {tên} — {mô tả}
+
+ASSUMPTIONS TÔI ĐANG ĐẶT RA:
+1. {assumption về scope}
+2. {assumption về persona}
+→ Sửa lại nếu sai trước khi tiếp tục.
+```
+
+---
+
+### Bước 3: Interview
+
+Hỏi tuần tự, từng phần — không hỏi tất cả cùng lúc:
+
+**Phần 1 — Problem Statement:**
+> Vấn đề cụ thể cần giải quyết trong integration này là gì? Tại sao cần làm ngay bây giờ?
+> (Đây là scope của integration này — không phải toàn bộ feature)
+
+**Phần 2 — Requirements:**
+> Requirements cụ thể là gì? Ghi theo dạng user stories: "As a {persona}, I want to {action} so that {value}"
+> Hoặc liệt kê functional requirements nếu không theo user story format.
+
+**Phần 3 — Acceptance Criteria:**
+> Điều kiện nào để biết integration này là done? Phân theo 2 loại:
+> - **Feature-level AC** (`AC-F-xxx`): criterion áp dụng cho toàn flow — không gắn với story cụ thể (ví dụ: error format, auth guard, cross-story constraints)
+> - **Story-level AC** (`AC-S-xxx`): criterion gắn với từng user story cụ thể
+> Viết theo cú pháp: GIVEN {precondition} / WHEN {action} / THEN {expected outcome}
+> `AC-F` và `AC-S` đánh số độc lập, tăng dần xuyên suốt toàn spec (không reset qua feature/story).
+
+**Phần 4 — Out of Scope:**
+> Có gì liên quan nhưng sẽ KHÔNG làm trong integration này không? Ghi rõ lý do.
+
+Nếu câu trả lời vague → hỏi lại để làm rõ. Ví dụ:
+- "user phải login được" → "login bằng gì? email/password, OAuth, hay cả hai? Response là gì?"
+- "hiển thị danh sách" → "hiển thị những field nào? có filter/sort/pagination không?"
+
+---
+
+### Bước 4: Xác định slug và output path
+
+Từ title của integration, sinh slug:
+- Lowercase, dùng dấu gạch ngang, không có ký tự đặc biệt
+- Ví dụ: "User Authentication" → `user-authentication`
+- Nếu từ prd.md: dùng `{feature-id}-{feature-slug}`, ví dụ: `f001-authentication`
+
+Xác định số thứ tự (`NNN`):
+- Liệt kê các thư mục hiện có trong `specs/integrations/` theo pattern `{NNN}-*`
+- Lấy số lớn nhất hiện có và cộng thêm 1, format 3 chữ số (ví dụ: `001`, `002`, `012`)
+- Nếu chưa có thư mục nào → bắt đầu từ `001`
+
+Output path: `specs/integrations/{NNN}-{slug}/spec.md`
+
+---
+
+### Bước 5: Write — sinh draft
+
+Tổng hợp và viết draft `spec.md`:
+
+**Cấu trúc file**: dùng `.claude/templates/integrations/spec-template.md` làm skeleton, điền nội dung từ interview vào.
+
+**Cascade Proposals** — điền theo hướng dẫn sau:
+
+### prd.md
+
+{Đề xuất cập nhật nếu phát hiện scope/feature mới cần ghi lại, hoặc "Không có thay đổi đề xuất."}
+
+### domain.md
+
+{Đề xuất cập nhật nếu phát hiện entity hoặc business rule mới, hoặc "Không có thay đổi đề xuất."}
+
+### frd.md
+
+Liệt kê **tất cả** features từ PRD và đánh giá từng cái:
+
+| Feature | Status | frd.md | Đề xuất |
+| --- | --- | --- | --- |
+| F-001 — Authentication | In Progress | tồn tại | **Cập nhật** — bổ sung US-003, AC mới về rate limiting |
+| F-002 — User Profile | TODO | chưa có | **Tạo mới** |
+| F-003 — Credit System | Done | tồn tại | Không liên quan |
+
+Với từng feature có đề xuất thay đổi, ghi rõ:
+
+**Tạo mới** `specs/main/features/{number}-{feature-slug}/frd.md`
+- Dùng khi integration này là lần đầu tiên implement feature này
+- Thư mục đặt tên theo convention: `{number}-{feature-slug}` (ví dụ: `001-authentication`)
+- Nội dung đề xuất: {tóm tắt User Stories và Acceptance Criteria từ spec.md}
+
+**Cập nhật** `specs/main/features/{number}-{feature-slug}/frd.md`
+- Dùng khi frd.md đã tồn tại và integration này bổ sung thêm stories hoặc criteria
+- Đọc file frd.md hiện tại, liệt kê các sections và hỏi user muốn update section nào:
+
+```
+frd.md — F-001 Authentication đã tồn tại.
+Sections hiện có:
+
+  [1] Overview
+  [2] Feature-level Acceptance Criteria
+  [3] User Stories
+  [4] Scope (In Scope / Out of Scope)
+  [5] Dependencies
+  [A] All — viết lại toàn bộ từ đầu
+
+Chọn section cần cập nhật (có thể chọn nhiều, ví dụ: 2 3):
+```
+
+Sau khi user chọn → chỉ sinh nội dung cho section đó. Nếu chọn `A` → sinh lại toàn bộ frd.md như tạo mới.
+
+Không được bỏ qua feature nào — kể cả feature `Done` vẫn phải đánh giá xem spec mới có làm thay đổi scope không.
+```
+
+Hiển thị draft cho user xem — **chưa ghi file**.
+
+---
+
+### Bước 6: Review — xác nhận với user
+
+> Draft trên đã đúng chưa?
+> - Acceptance Criteria có đủ và đo được không?
+> - Cascade Proposals (nếu có) — cần approve trước khi tiến hành.
+
+Chỉ ghi file sau khi user confirm. Nếu user yêu cầu chỉnh sửa → cập nhật draft → hỏi lại.
+
+---
+
+### Bước 7: Save
+
+Tạo thư mục `specs/integrations/{NNN}-{slug}/` nếu chưa có.
+
+Ghi nội dung đã confirm vào `specs/integrations/{NNN}-{slug}/spec.md`.
+
+Nếu integration này đến từ prd.md, cập nhật `specs/main/prd.md`: đổi Status của feature từ `TODO` → `In Progress` và điền link vào cột FRD.
+
+Thông báo kết quả:
+```
+✓ specs/integrations/{NNN}-{slug}/spec.md đã được tạo (status: draft)
+{nếu có} ✓ prd.md — F-XXX status cập nhật: TODO → In Progress
+
+Bước tiếp theo:
+  - Review và approve spec.md
+  - /spec-tech → thiết kế technical design dựa trên spec.md này
+```
+
+---
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+| --- | --- |
+| "Requirement rõ rồi, bỏ qua spec.md" | Acceptance Criteria chưa viết = không biết khi nào là done. Code xong vẫn có thể sai. |
+| "Out of scope thì ai cũng hiểu rồi" | Không ghi = scope creep không kiểm soát được. DEV sẽ tự quyết định implement hay không. |
+| "Cascade Proposals thì sau cập nhật cũng được" | Domain là shared context. Cập nhật trễ = các spec sau dùng context sai. |
+
+## Red Flags
+
+- Acceptance Criteria dùng từ không đo được: "hoạt động đúng", "hiển thị đẹp", "nhanh"
+- Out of Scope trống — mọi integration đều có thứ liên quan nhưng không làm
+- Open Questions để trống nhưng vẫn còn điểm mơ hồ trong requirements
+- Cascade Proposals không được review trước khi approve
+
+## Verification
+
+Trước khi ghi file, kiểm tra:
+
+- [ ] Problem Statement từ góc nhìn user/business, không mention tech
+- [ ] Mỗi Acceptance Criterion dùng cú pháp GIVEN / WHEN / THEN, có thể test được
+- [ ] Out of Scope có ít nhất 1 item
+- [ ] Cascade Proposals đã được user review
+- [ ] User đã confirm draft trước khi ghi file

package/skills/spec-plan/SKILL.md

@@ -0,0 +1,193 @@
+---
+name: spec-plan
+description: Tạo plan.md và todo.md cho một integration — phân rã tasks từ spec.md và tech.md. SDD wrapper quanh planning-and-task-breakdown — chỉ làm context loading, delegate toàn bộ breakdown cho planning-and-task-breakdown.
+---
+
+# spec-plan
+
+## Overview
+
+SDD wrapper quanh `planning-and-task-breakdown`. Nhiệm vụ duy nhất của skill này là:
+1. Load và surface đúng context từ SDD artifacts
+2. Handoff sang `planning-and-task-breakdown` để thực hiện breakdown
+
+Mọi quyết định về sizing, slicing đều thuộc về `planning-and-task-breakdown`. Output format được định nghĩa trong SKILL này.
+
+## When to Use
+
+- Có `spec.md` và/hoặc `tech.md` cho integration cần plan
+
+## When NOT to Use
+
+- Hotfix nhỏ, single-file → implement trực tiếp không cần plan
+
+---
+
+## Process
+
+### Bước 1: Xác định integration
+
+Quét `specs/integrations/`. Liệt kê tất cả integrations:
+
+```
+Integrations:
+
+  [1] f001-authentication       — User Authentication        spec✓ tech✓  plan—
+  [2] f003-app-browsing         — App Browsing & Opt-in      spec✓ tech—
+  [3] f004-credit-system        — Credit System              spec—
+
+Chọn số integration:
+```
+
+Legend: `✓` = có, `—` = chưa có
+
+Nếu có ARGUMENT → chọn luôn, không hiển thị danh sách.
+
+Nếu plan.md / todo.md đã tồn tại → hỏi trước khi ghi đè.
+
+---
+
+### Bước 2: Load và surface context
+
+Load:
+
+- `specs/integrations/{slug}/spec.md` — Requirements, Acceptance Criteria (ghi chú số AC và IDs)
+- `specs/integrations/{slug}/tech.md` — Technical Design, Interface Changes, Data Model Changes, Implementation Notes
+- `specs/main/domain.md` — Entities và Business Rules liên quan
+
+Surface tóm tắt để planning-and-task-breakdown có đủ context:
+
+```
+CONTEXT CHO PLANNING:
+- Integration: {title}
+- Yêu cầu chính: {tóm tắt từ spec.md — 2-4 bullet}
+- Acceptance Criteria: {số lượng} — Feature-level: {AC-F-001, AC-F-002...} / Story-level: {AC-S-001, AC-S-002...}
+- Thay đổi kỹ thuật: {modules, data model, interfaces từ tech.md}
+- Entities liên quan: {từ domain.md}
+
+ASSUMPTIONS:
+1. {assumption về ordering nếu có}
+→ Sửa lại nếu sai trước khi tiếp tục.
+```
+
+> **Plan mode từ đây** — chỉ đọc, không viết code.
+
+---
+
+### Bước 3: Handoff sang planning-and-task-breakdown
+
+Invoke `planning-and-task-breakdown` với context đã load. Skill đó sẽ thực hiện: dependency graph, slicing, write tasks. Output phải theo **Output Format** định nghĩa bên dưới — không dùng format mặc định của `planning-and-task-breakdown`.
+
+---
+
+## Output Format
+
+### plan.md
+
+```markdown
+---
+id: "{slug}"
+slug: "{slug}"
+title: "{title} — Implementation Plan"
+features: ["{F-XXX}"]
+status: draft
+created: {YYYY-MM-DD}
+---
+
+## Summary
+
+[2-3 sentences on what will be implemented]
+
+## Dependency Graph
+
+[ASCII diagram — bottom = foundations, top = UI. Ví dụ:]
+
+    UI Components
+         │
+    API Routes ──── Middleware
+         │
+      Services
+         │
+    Prisma Schema
+
+## Tasks
+
+### Phase 1: [Phase name]
+
+#### T001 · [task title — starts with a verb]
+
+**Mục tiêu:** [One sentence: what this task delivers]
+
+**depends:** — (hoặc T-IDs)
+
+**Các bước:**
+1. [Concrete implementation step]
+2. [Concrete implementation step]
+
+**Verification:**
+- [ ] [AC-F-001] [specific test case]
+- [ ] [smoke check or observable result]
+
+---
+
+### Phase N: Verification
+
+#### T00N · Integration tests — [flow name]
+
+**Mục tiêu:** [End-to-end flow being tested]
+
+**depends:** T001, T002, ...
+
+**Các bước:**
+1. [Test setup / seed data]
+2. [Execute happy path]
+3. [Execute error cases]
+
+**Verification:**
+- [ ] Happy path: [description]
+- [ ] Error case: [description]
+
+---
+
+## Definition of Done
+
+- [ ] [AC-F-001 / AC-S-001] [AC description — concise, preserve intent]
+- [ ] All unit tests pass
+- [ ] All integration tests pass
+```
+
+**Lưu ý format:**
+- Task ID dùng `·` (middle dot), không dùng `—`
+- `**Các bước:**` là numbered list, đủ cụ thể để agent implement không cần đoán
+- `**Verification:**` là checklist `- [ ]`, gắn AC ID khi có
+- `**depends:**` luôn có, dùng `—` nếu không có dependency
+
+### todo.md
+
+```markdown
+# [title] — Todo
+
+### Phase 1: [Phase name]
+- [ ] T001 · [task title]
+- [ ] T002 · [task title]
+
+### Phase N: Verification
+- [ ] T00N · Integration tests — [flow name]
+```
+
+---
+
+## Cascade Proposals
+
+Không có Cascade Proposals — plan.md là terminal artifact.
+
+Nếu trong quá trình breakdown phát hiện delta cần cập nhật `sad.md`, `domain.md`, hay artifacts khác → **không tự cập nhật**. Thông báo user và đề xuất tạo integration riêng để xử lý.
+
+---
+
+## Verification
+
+- [ ] Context đã được surface và user confirm trước khi breakdown
+- [ ] plan.md có section **Dependency Graph**
+- [ ] Mỗi task có đủ: Mục tiêu / depends / Các bước / Verification
+- [ ] Không viết code trong suốt quá trình