4 Skills Claude Code của Quỳnh

Claude Code là công cụ AI làm việc trực tiếp với mã nguồn và file dự án. Mỗi skill xử lý một việc cụ thể; JTBD là cách mô tả hoàn cảnh, việc cần làm và kết quả mong muốn. Token là đơn vị dung lượng văn bản AI xử lý. Bấm từng tab để xem chi tiết.

Câu chuyện 60 giây

Ngày làm việc của mình có vài bước lặp lại. Xong một đầu việc, mình cập nhật sổ và tạo commit (lưu một mốc thay đổi vào Git) — cùng lúc đó một dấu phiên làm việc cũng được lưu lại. Sáng hôm sau mình xem lại việc hôm qua rồi lập kế hoạch hôm nay. Tới một cột mốc dự án, mình ghi lại lý do đằng sau các quyết định. Khi cần đọc trên điện thoại hay chia sẻ, mình gửi tài liệu qua Telegram. Ba skill đầu nối nhau qua hai kho chung: task-log (sổ việc code trong dự án) và vibe-history (kho các phiên làm việc); còn telegram-send là kênh đưa kết quả ra ngoài.

done ghi kết quả vào hai kho chung: task-log (việc code) và vibe-history (phiên làm việc). daily-report đọc task-log; retrospective đọc cả task-log lẫn vibe-history. telegram-send không đụng kho nào — nó đưa chính các báo cáo/tài liệu đó ra Telegram.

ghi việc lưu mốc phiên việc non-code đọc mỗi sáng đọc đọc qua qmd gửi output ra ngoài 📌 done ghi cả 2 kho + commit 🗂️ Obsidian vault việc non-code (riêng daily-report) 📒 task-log sổ việc code /dự án 🗄️ vibe-history kho phiên làm việc 🌅 daily-report báo cáo mỗi sáng 📖 retrospective tài liệu tri thức 📤 telegram-send đưa output ra Telegram (không dùng kho chung)

Hai kho chung viền đậm xanh: task-log (việc code theo dự án) và vibe-history (phiên làm việc). Obsidian vault (viền nét đứt) là nguồn việc non-code chỉ của daily-report. Đường nét đứt xanh dương = telegram-send gửi output ra ngoài (quan hệ theo luồng, không qua kho chung).

Hai kho chung, hai đường hồi cứu

done ghi vào task-log (trạng thái, giờ, kết quả) rồi commit; ngay sau đó lưu một dấu phiên vào vibe-history. Một lần chạy, ghi vào cả hai kho.
daily-report đọc task-log (việc code) + Obsidian vault (việc non-code) để dựng “Hôm qua”. Nó không đọc vibe-history.
retrospective đọc cả hai — task-log (lý do đã chốt) và vibe-history (quá trình suy nghĩ, qua vibe-history-search) — cộng bản ghi phiên và git.
telegram-send đứng cuối luồng: gửi báo cáo/tài liệu do hai skill trên tạo ra sang Telegram. Không đụng kho chung nào.

Mỗi phiên làm việc có một mục công việc không?

Không hẳn. Đầu phiên chỉ có một dấu mốc ghi giờ bắt đầu để đo khoảng nghỉ; đó chưa phải là một đầu việc. Khi mình đưa yêu cầu cụ thể thì mới mở mục công việc. Việc phát sinh dài hơn 5 phút được tách riêng, còn việc ngắn hơn được ghi cùng mục chính.

Một đầu việc ghi những gì

1Số thứ tự, mô tả, giờ bắt đầu, giờ kết thúc và thời gian thực hiện.
2Bối cảnh nghiệp vụ: Vấn đề → Phương án → Quyết định (viết cho người đọc, không phải tên biến/hàm).
3Trạng thái: đã xong, đã tạo commit kèm mã nhận diện, hoặc đã từ chối. Khi chốt xong, mình chỉ thêm kết quả và giữ nguyên bối cảnh đã ghi.

Quy tắc khớp dữ liệu

Ngày là khóa nối chính: task-log, việc trong kho ghi chú, tên file báo cáo và mốc kế hoạch ngày/tháng đều dùng ngày theo giờ Sài Gòn. Registry và longest-prefix là bảng ánh xạ thư mục mã nguồn sang tên mảng, trong đó hệ thống chọn đường dẫn cha khớp dài nhất. Nhờ ngày và bảng này, dữ liệu từ nhiều nơi vẫn được xếp đúng dự án.

📌
done
Chốt một đầu việc, cập nhật sổ và lưu thay đổi
~830 tokens
Khi làm xong một đầu việc, mình muốn chốt bằng một lệnh, để task-log được cập nhật và thay đổi được lưu thành một commit có nội dung rõ ràng.
phân loại ghi sổ lưu phiên xác nhận? 🔍 Đọc thay đổi git diff 1 📝 Ghi task-log task-log.md 2 📦 Commit git commit 3 📸 Lưu mốc phiên vibe-history 4 🗂️ Xác nhận GitHub issue gh issue 5

1Làm gì

Kết thúc một đầu việc: cập nhật task-log, tạo commit theo quy ước, lưu một mốc vào vibe-history, rồi hỏi mình có muốn tạo hoặc đóng GitHub issue hay không.

2Cơ chế

  1. Ghi task-log trước: đánh dấu đã xong, thêm giờ kết thúc, thời gian thực hiện và kết quả.
  2. Tạo commit theo quy ước đặt tên.
  3. Lưu dấu phiên vào vibe-history; bỏ qua nếu phiên không được theo dõi và không chặn các bước còn lại.
  4. Hỏi trước khi tạo hoặc đóng GitHub issue.

3Khi nào dùng / KHÔNG dùng

Nên dùng
  • Xong một đầu việc và muốn lưu kết quả cùng thay đổi mã nguồn.
Không dùng
  • Dùng thay cho việc đẩy mã nguồn hoặc triển khai.
  • Tự tạo issue khi chưa hỏi.

4Ưu điểm / Hạn chế

👍Ưu điểm
  • Cập nhật sổ, lưu thay đổi và ghi dấu phiên trong một lần chạy.
  • Giữ kết quả công việc đi cùng mã nguồn.
👎Hạn chế
  • Chỉ tạo commit trên máy, không đẩy lên kho từ xa.
  • Dự án cần có task-log.
  • Bước GitHub issue cần mình xác nhận.

5Cách dùng nên giữ

  • Task-log viết theo hướng nghiệp vụ (Vấn đề → Phương án → Quyết định).
  • Có thể để mô tả trống để skill đề xuất từ phần thay đổi, rồi mình kiểm tra lại.
  • Nếu commit bị hook chặn thì dừng lại, không dùng --no-verify.

6Token tiêu hao

Khi kích hoạt
~830
nạp cùng lúc
Nạp thêm khi cần
0
không có bước nặng
🌅
daily-report
Tổng hợp việc hôm qua và lập kế hoạch hôm nay
~2.620 tokens
Mỗi sáng, mình muốn tổng hợp việc hôm qua và lập kế hoạch hôm nay, để biết việc nào đã xong, việc nào còn vướng và việc nào cần làm tiếp.
3 NGUỒN DỮ LIỆU dữ liệu đã gộp đã duyệt 📒 Sổ việc mã nguồn task-log.md 1 🗂️ Ghi chú Obsidian vault tasks/ 2 🗺️ Mảng dự án projects/*.md 3 🍳 Gộp đầu việc AI gộp theo chủ đề 4 Hỏi xác nhận DUYỆT TRƯỚC KHI GHI 5 🍽️ Ghi báo cáo + cập nhật việc journal/reports + tasks/ 6

1Làm gì

Tổng hợp task-log thành báo cáo ngắn bằng tiếng Việt, nhóm các việc cùng mục tiêu, đối chiếu việc chưa xong và hỏi thêm việc chưa được ghi.

2Cơ chế

  1. Chạy script lấy các mục đúng ngày từ task-log và kho ghi chú.
  2. Nhóm các việc cùng mục tiêu thành 2–3 ý cho mỗi mảng.
  3. Đối chiếu việc chưa xong từ báo cáo trước.
  4. Hỏi mình về những việc chưa được ghi.
  5. Luôn cho mình duyệt bản nháp trước khi ghi file.
  6. Lưu báo cáo và cập nhật việc vào Obsidian; task-log chỉ được đọc.

3Khi nào dùng / KHÔNG dùng

Nên dùng
  • Đầu ngày để lập kế hoạch.
  • Cuối ngày để tổng hợp kết quả.
Không dùng
  • Tự ghi đè file khi chưa hỏi.

4Ưu điểm / Hạn chế

👍Ưu điểm
  • Chuyển nhiều mục chi tiết thành báo cáo ngắn.
  • Giữ liên kết với nội dung gốc theo ngày và dự án.
👎Hạn chế
  • Phụ thuộc vào các mục có ngày rõ ràng.
  • Cần mình duyệt vì AI thực hiện việc nhóm và diễn đạt.

5Cách dùng nên giữ

  • Ghi ngày trong dòng Time để mục việc không bị bỏ sót.
  • Đọc lại bản nháp trước khi cho phép ghi file.

6Token tiêu hao

Khi kích hoạt
~2.620
nạp cùng lúc
Nạp thêm khi cần
+~4.600
khi định dạng và cập nhật việc
📖
retrospective
Ghi lại lịch sử và lý do đằng sau các quyết định dự án
~1.850 tokens
Khi dự án tới một cột mốc hoặc cần bàn giao, mình muốn ghi lại vì sao dự án được xây dựng theo cách hiện tại, để người tiếp nhận hoặc AI hiểu các quyết định mà không phải đọc toàn bộ mã nguồn.
Bốn nguồn tư liệu 💬 Nhật ký phiên bản ghi phiên 1 🔎 Kho tìm kiếm vibe-history / qmd 2 📒 Sổ công việc task-log.md 3 🌿 Lịch sử git log 4 tổng hợp + đánh giá ⚖️ Đánh giá tư liệu mức tư liệu High / Medium / Low 5 dựng tài liệu 📖 Tài liệu tri thức tài liệu dự án 12 mục + (Inferred) 6

1Làm gì

Tạo một tài liệu tri thức dự án từ đặc tả, task-log, lịch sử Git và các phiên cũ. Tài liệu trình bày bối cảnh, diễn tiến, quyết định kiến trúc, nguyên tắc cần giữ và bài học có bằng chứng.

2Cơ chế

  1. Script kiểm tra bốn nguồn: bản ghi phiên, vibe-history, task-log và lịch sử Git.
  2. Đánh giá chất lượng dấu vết ở ba mức High, Medium hoặc Low.
  3. Soạn tài liệu theo mẫu và quy tắc viết; phần suy ra được gắn nhãn (Inferred).

3Khi nào dùng / KHÔNG dùng

Nên dùng
  • Khi phiên bản đầu tiên đã hoàn thành.
  • Khi bàn giao dự án.
  • Khi giúp người mới hiểu dự án.
Không dùng
  • Viết tài liệu API (cách phần mềm khác gọi hệ thống).
  • Viết hướng dẫn thao tác cho người dùng.

4Ưu điểm / Hạn chế

👍Ưu điểm
  • Giữ lại lý do và quyết định dễ thất lạc.
  • Có đường dẫn về nguồn bằng chứng.
👎Hạn chế
  • Chất lượng phụ thuộc dấu vết còn lại.
  • Dùng nhiều token (đơn vị dung lượng văn bản AI xử lý).
  • Phù hợp nhất khi dự án vừa tới một cột mốc.

5Cách dùng nên giữ

  • Chạy ngay trong phiên vừa làm dự án để còn đủ bối cảnh.
  • Ghi rõ lý do và kết quả trong task-log để mức tin cậy có cơ sở đạt High.

6Token tiêu hao

Khi kích hoạt
~1.850
nạp cùng lúc
Nạp thêm khi cần
+~3.900
khi soạn tài liệu
📤
telegram-send
Gửi nội dung hoặc file sang Telegram bằng một lệnh
~450 tokens
Khi có báo cáo hoặc tài liệu cần đọc ngoài máy tính, mình muốn gửi sang Telegram bằng một lệnh, để xem trên điện thoại hoặc chia sẻ với nhóm đã chọn.
tham số vào đã phân loại đã gửi 🔑 Đọc cấu hình config.env 1 🗂️ Phân loại tham số -f / -c / text 2 📮 Gửi tới Telegram API Telegram 3 🧾 Đọc kết quả thành công / lỗi 4

1Làm gì

Gửi phần chữ hoặc file như Markdown, PDF và ảnh tới Telegram qua bot đã cấu hình sẵn.

2Cơ chế

  1. Script đọc bot token và chat ID từ file cấu hình ngoài kho mã nguồn.
  2. Dùng curl gọi sendMessage cho phần chữ hoặc sendDocument cho file.
  3. Đọc kết quả bằng lệnh shell có sẵn, không cần Python.

3Khi nào dùng / KHÔNG dùng

Nên dùng
  • Đọc file hoặc báo cáo trên điện thoại.
  • Gửi thông báo vào nhóm đã cấu hình.
Lưu ý bảo mật
  • Không đưa bot token vào hội thoại, log hoặc commit.
  • Phần chữ được gửi dạng thuần, không định dạng Markdown.

4Ưu điểm / Hạn chế

👍Ưu điểm
  • Một lệnh cho cả phần chữ và nhiều file.
  • Báo kết quả từng lần gửi và trả mã kết thúc phù hợp.
👎Hạn chế
  • Mỗi file không quá 50 MB.
  • Phần chữ phải đặt trước cờ -f.
  • Phần chữ không có định dạng.

5Cách dùng nên giữ

  • Đặt phần chữ trước -f.
  • Lời chú thích nên có tên dự án và mã commit ngắn để biết file thuộc thay đổi nào.
  • Muốn có định dạng thì gửi file .md.

6Token tiêu hao

Khi kích hoạt
~450
ít nhất trong bốn skill
Nạp thêm khi cần
0
không có bước nặng