Skill: Handoff Quality Standard

Mục đích: Đảm bảo phiên mới tiếp tục LIỀN MẠCH trong 1-2 phút, KHÔNG lãng phí 30 phút + hàng chục tool calls đọc lại context. Áp dụng: MỌI phiên. Desktop + CLI. Bắt buộc.

---

VẤN ĐỀ GỐC

• Context Opus ngắn, token đắt. Mỗi phiên mới = người mới tham gia lần đầu.
• Handoff thiếu → phiên mới tốn 10-15 tool calls chỉ để đọc lại → 30 phút + chi phí token user phải gánh.
• Sai lầm do handoff kém: lặp lại lỗi cũ, quên quyết định đã đưa ra, vi phạm nguyên tắc đã thống nhất.

---

TIÊU CHUẨN HANDOFF — 7 MỤC BẮT BUỘC

1. TÓM TẮT 1 CÂU

"Phiên này làm gì, kết quả gì, vấn đề gì."

2. QUYẾT ĐỊNH KỸ THUẬT CỤ THỂ

KHÔNG viết chung chung "đã fix". PHẢI ghi:

• Entity nào: tên, ID, collection, field cụ thể
• Thay đổi gì: giá trị cũ → giá trị mới
• Tại sao: căn cứ luật/nguyên tắc nào
• Ví dụ: "APR-0143: workflow_categories governance_role='excluded' → REJECTED. Lý do: Điều 0-B — junction table = atom quan hệ, không được excluded. Revert về 'observed'."

3. SAI LẦM + BÀI HỌC (CRITICAL)

Phiên sau PHẢI BIẾT để KHÔNG lặp lại:

• Sai gì: mô tả cụ thể hành động sai
• Vi phạm nguyên tắc nào: quote §code
• Đã sửa chưa: status
• Anti-pattern nào đã ghi: AP-NN
• Ví dụ: "Desktop dùng directus_create_item trực tiếp tạo MOD-005 → vi phạm DOT 100% (AP-09). Khai tay = fix 1 lần, không phải giải pháp."

4. TRẠNG THÁI DỮ LIỆU CỤ THỂ

KHÔNG viết "hệ thống sạch". PHẢI ghi con số:

• approval_requests: pending=0, applied=142, rejected=1
• Directus entities mới tạo: modules id=6 (MOD-005), tasks id=17 (TASK-017)
• Cron entries: có/không, tần suất
• Scanner results: orphan count, last run

5. PROMPT ĐÃ SOẠN — NỘI DUNG TÓM TẮT

Nếu đã soạn prompt cho CLI:

• Tên: S145-M1
• Targets chính: list 1 dòng mỗi target
• Điểm khác so với template thông thường: ghi rõ (ví dụ: "thêm fix DOT-116 scanner rule + verify birth pipeline")
• Ở đâu: Artifact trong phiên chat (anh copy) hoặc Agent Data path

6. VIỆC TIẾP THEO — CÓ ĐỦ THÔNG TIN ĐỂ LÀM NGAY

KHÔNG viết "tiếp tục M4". PHẢI ghi:

• Bước 1 cụ thể: "Copy prompt S145-M1 từ artifact → giao CLI chạy"
• Input cần: files nào, data nào
• Output mong đợi: report ở đâu, verify gì
• Ai làm: Desktop hay CLI

7. TÀI LIỆU ĐÃ THAY ĐỔI PHIÊN NÀY

• Path + revision + thay đổi gì (1 dòng)
• Ví dụ: "OR v6.4→v6.5 (rev 298→299): +TD-428+429, roadmap updated"
• Ví dụ: "anti-patterns.md rev 1→2: +AP-09 (làm tay), +AP-10 (excluded=giấu)"

---

CHECKLIST TRƯỚC KHI KẾT THÚC PHIÊN

#	Kiểm tra	☐
1	Tóm tắt 1 câu có đủ "làm gì + kết quả + vấn đề"?
2	Mọi quyết định kỹ thuật ghi CỤ THỂ (entity, ID, field, giá trị)?
3	Sai lầm + bài học ghi rõ (hành động sai, nguyên tắc vi phạm, AP-NN)?
4	Trạng thái dữ liệu có CON SỐ (không chung chung)?
5	Prompt đã soạn có tóm tắt targets + điểm khác biệt?
6	Việc tiếp theo ghi ĐỦ để phiên mới làm ngay mà KHÔNG hỏi user?
7	Tài liệu đã thay đổi: path + revision + thay đổi gì?

---

LƯU Ý ĐẶC BIỆT

• KHÔNG ghi "(Giữ nguyên)" cho các section — phiên mới không biết nội dung là gì.
• KHÔNG ghi "search_knowledge(...)" làm hướng dẫn — phiên mới đọc handoff PHẢI ĐỦ, không cần search thêm. Search chỉ dùng khi cần chi tiết luật/architecture.
• Ghi SỐ LIỆU tuyệt đối — "0 orphans" tốt hơn "hệ thống sạch".
• Handoff = tài liệu DUY NHẤT phiên mới cần đọc. Nếu phiên mới phải đọc thêm 5 files nữa = handoff THẤT BẠI.
• Ưu tiên: ĐÚNG > ĐẸP. Handoff xấu nhưng đủ thông tin tốt hơn handoff đẹp nhưng chung chung.

---

Skill v1.0 | S145 | Rút từ bài học: handoff kém → 30 phút + token lãng phí mỗi phiên mới.