Khám phá Learn Stream About Jokes
COHORT 2 Foundation — Claude Code — 3 buổi Zoom · 21 · 24 · 28/07, 20:00 Đăng ký →
Playbook

ClaudeKit / AgentKit — Playbook copy-paste

Năm việc thật: xây, sửa, soi, ship, cứu phiên. Mỗi việc một chuỗi lệnh, copy từng bước. Không cần thuộc lệnh.

Tài liệu gốc xếp lệnh theo công nghệ. Nhưng tới lúc mở máy làm thật, câu hỏi thường không phải “mình cần lệnh nào”, mà là “mình đang xử lý việc gì”.

Năm luồng dưới đây phủ gần hết một tuần làm việc bình thường: xây, sửa, soi, ship, và cứu phiên đang rối. Chọn đúng việc trước mặt bạn, rồi copy từng bước. Trang sau là bản đồ 84 lệnh để tra thêm khi cần.

ClaudeKit · Playbook

Đừng hỏi "lệnh nào".
Hỏi "mình đang làm việc gì".

Chín việc dưới đây phủ gần hết một tuần làm việc thật. Chọn việc của bạn, rồi copy từng bước. Ô đen là lệnh gõ trong Claude — không cần thuộc, cứ copy. Nhưng ô cam thì bạn phải tự quyết: đó là chỗ AI dừng lại chờ bạn.

1 lệnh · bạn duyệt ở 5 cổng
Từ thư mục trống tới dự án chạy được

/ck:bootstrap không tự viết code. Nó điều phối mười một chặng và gọi /ck:plan, /ck:cook hộ bạn ở bên trong. Bạn đỡ phải gõ — nhưng nó dừng lại xin ý bạn ở năm chỗ, và chỗ nào bạn cũng có quyền bắt nó làm lại.

01

Mở Claude Code ngay trong thư mục trống. Bootstrap tự chạy git init giúp bạn.

▸ Gõ trong Claude
/ck:bootstrap "app chat realtime, Next.js + auth" --full
Bốn chế độ, chọn đúng một — chúng khác nhau ở chỗ bạn được duyệt bao nhiêu lần: --full duyệt mọi chặng (bên trong gọi /ck:plan --hard) · --fast bỏ nghiên cứu, chỉ còn cổng của cook · --auto--parallel chỉ duyệt ở chặng Design. Người mới cứ dùng --full.

Bên trong nó chạy mười một chặng — và dừng lại hỏi bạn ở năm chỗ. Ô cam là chỗ nó chờ bạn gật đầu:

git initresearchtech stackdesignplancooktestreviewdocsonboard
Ở chặng plan và cook, nó tự gọi /ck:plan --hard/ck:cook — hai lệnh này bạn không cần gõ. Nhưng "không cần gõ" không có nghĩa là bạn ngồi im. Năm chặng cam kia, chặng nào nó cũng trình kết quả ra rồi chờ bạn duyệt mới đi tiếp. Ba chặng dưới đây là ba chỗ bạn phải lên tiếng.
VIỆC CỦA BẠN — CỔNG NGHIÊN CỨU & CHỌN CÔNG NGHỆ

Nó hỏi từng câu một, rồi trình 2–3 phương án stack kèm hơn thiệt để bạn chọn.

Chưa ưng phương án nào thì cứ nói ra — nó dựng lại phương án khác. Bạn không bị nhốt trong mấy lựa chọn nó đưa: có stack riêng trong đầu rồi thì nói luôn từ đầu, nó bỏ qua bước tự đề xuất. Đổi ý về stack ở đây tốn một phút; đổi sau khi code xong thì tốn cả tuần.
CỔNG BẮT BUỘC — KẾ HOẠCH

Nó chạy /ck:plan --hard hộ bạn, ghi ra plan.md, rồi đứng lại chờ. Luật trong skill ghi nguyên văn: không được code khi bạn chưa duyệt.

Đây là chỗ đáng để bạn khó tính nhất. Mở plan.md ra đọc cho kỹ. Ba đường đi tiếp, chọn một:
· Ưng rồi → bảo nó chạy tiếp.
· Sai vài chỗ → tự tay chỉnh lại plan.md theo ý bạn, rồi bảo nó đọc lại file mà làm.
· Sai từ gốc → phủ quyết, bắt nó lập lại kế hoạch khác.
VIỆC CỦA BẠN — CỔNG CODE

Sang chặng cook, với --full nó vẫn dừng cho bạn xem ở từng bước, không phải code một lèo tới sáng.

Người mới hay tưởng AI đưa gì thì phải nhận nấy. Không phải vậy: bạn là người cầm lái, nó chỉ chạy giúp. Mấy cái cổng này không phải thủ tục cho có — nó là chỗ để bạn bẻ lái trước khi đi quá xa. Thấy nó đi lệch mà cứ gật cho xong, thì cuối cùng bạn nhận về một dự án của nó, không phải của bạn.
VIỆC CỦA BẠN — KHI BẠN CỨ PHẢI SỬA HOÀI

Nếu chặng nào bạn cũng thấy phải uốn lại, thì bootstrap không hợp với bạn ở việc này. Bỏ nó, tự cầm lái:

▸ Gõ trong Claude
/ck:plan "..." --hard
/clear
/ck:cook @plan.md
Đúng ba lệnh đó là tình huống "Xây một tính năng" ở ô chọn phía trên — bạn gõ từng lệnh, dừng ở đâu tuỳ bạn. Bootstrap hợp khi bạn ở thế "cứ làm đi, tôi duyệt". Còn khi bạn đã có ý riêng ở từng bước, tự gõ lại nhanh hơn là ngồi sửa nó.
02

Ghi lại quyết định khi vừa xong, lúc lý do còn nóng hổi.

▸ Gõ trong Claude
/ck:journal
Chính skill bootstrap cũng dặn chạy lệnh này khi kết thúc. Vì sao chọn stack đó, đã cân nhắc gì rồi bỏ — tuần sau quay lại, bạn sẽ cảm ơn chính mình. Gõ trần là nó tự đọc thay đổi gần đây rồi viết; muốn ghim vào một chuyện cụ thể thì đưa chủ đề: /ck:journal "vì sao bỏ Postgres chọn SQLite".
03

Đưa nó lên mạng. Nó tự nhận diện stack và nền tảng.

▸ Gõ trong Claude
/ck:deploy
Nếu chưa rõ deploy đi đâu, nó sẽ hỏi lại bạn. Muốn chỉ đích danh thì đưa thẳng nền tảng và môi trường: /ck:deploy vercel production. Hơn 15 nền tảng, và nó tự lo biến môi trường với bước build.
Từ ý tưởng tới code đã test

Bốn bước, và một cổng bắt buộc ở giữa. Bỏ cổng đó là tự làm khó mình.

01

Đọc lãnh thổ trước khi vẽ bản đồ. Nhiều agent quét song song xem code liên quan nằm đâu, ai gọi nó.

▸ Gõ trong Claude
/ck:scout "auth"
Có bước này thì AI không phải đoán. Bỏ nó, mọi bước sau đều đứng trên cát.
02

Bắt nó viết kế hoạch — rồi tự tấn công kế hoạch đó.

▸ Gõ trong Claude
/ck:plan "thêm đăng nhập Google" --hard
--hard tự thả một đội phản biện vào: người soi bảo mật, người dựng kịch bản hỏng, người phá giả định ngầm. Kế hoạch sống sót qua họ mới đáng để code.
VIỆC CỦA BẠN

Mở plan.md ra đọc. Sửa chỗ nào bạn không đồng ý.

Sửa một kế hoạch mất 2 phút. Sửa lại codebase thì lâu hơn nhiều. Đây là lúc rẻ nhất để đổi ý.
CỔNG BẮT BUỘC

Dọn trí nhớ. Kế hoạch đã nằm an toàn trong file — phần hội thoại thì không cần nữa.

▸ Gõ trong Claude
/clear
Bạn không mất gì cả: plan nằm trong file, code nằm trong git. Phần bỏ đi chỉ là nháp của giai đoạn bàn bạc — giữ lại chỉ làm AI khó tập trung.
03

Để nó xây, và để nó tự chặn mình.

▸ Gõ trong Claude
/ck:cook @plan.md --tdd
Chạy hết dây chuyền: code → test → quét tác dụng phụ → tự review. Test chưa xanh thì nó không đi tiếp. Dấu @ nghĩa là "đọc file này". --tdd bắt nó viết test trước khi viết code — chậm hơn một chút, nhưng thứ nó xây ra khớp với thứ bạn định nghĩa. Muốn ngồi duyệt từng chặng thì thêm --interactive; đang vội thì --fast.
Một lệnh, sáu bước có bằng chứng

Đừng tả lại lỗi bằng lời. Đưa log. Có bằng chứng thì sửa trúng hơn.

VIỆC CỦA BẠN — TRƯỚC TIÊN

Bắt lỗi ra file. Đây là bước duy nhất chạy trong terminal thật, không phải trong Claude.

▸ Gõ trong terminal
$ npm run dev 2>&1 | tee logs.txt
Tả lại lỗi bằng trí nhớ thì AI phải đoán. Đưa log thì nó có bằng chứng.
01

Sáu bước, không vá mù.

▸ Gõ trong Claude
/ck:fix "đọc logs.txt và sửa lỗi"
Dò → tìm nguyên nhân gốc → đánh giá → sửa → xác minh → quét tác dụng phụ toàn vùng. Ba lần sửa hỏng là nó tự dừng thay vì cày cố.

Bạn sẽ thấy nó tick từng bước, chứ không phải im lặng rồi quăng ra một cục diff:

scoutdiagnoseđánh giásửaxác minhquét tác dụng phụ
Hai ô đậm là cổng cứng — chưa xong hai bước đó thì nó không được phép đề xuất bản sửa. Ở bước diagnose, nó phải trả lời được sáu câu bằng bằng chứng có file:line: triệu chứng đúng nguyên văn, cách tái hiện, mong đợi vs thực tế, nguyên nhân gốc, vì sao giờ mới lộ, và vùng ảnh hưởng. Chỗ nào còn "chắc là", "hình như" — nó quay lại hỏi bạn, không đoán bừa.
02

Bốn chế độ — chỉ đổi khi bạn có lý do. Không ghi gì thì nó chạy --auto.

▸ Gõ trong Claude
/ck:fix "lint đỏ ở src/api" --quick
--auto (mặc định) tự chạy, nhưng bản sửa rủi ro cao thì vẫn dừng xin phép bạn · --quick chỉ dành cho lỗi vặt — lint, type error — vì nó nới cổng cứng để đi nhanh; đừng dùng cho bug thật · --review hỏi ý bạn ở từng bước · --parallel chia nhiều lỗi cho nhiều agent chạy song song.
VIỆC CỦA BẠN — CHỖ RẼ

Nếu bạn chưa biết lỗi nằm ở đâu, đừng gọi /ck:fix vội — hỏi trước đã.

▸ Gõ trong Claude
/ck:debug "login trả 500 sau khi đổi middleware"
/ck:debug chỉ truy nguyên nhân rồi dừng lại báo cáo — không đụng vào code. Hiểu rõ rồi mới /ck:fix. Thật ra /ck:fix cũng gọi /ck:debug ở bên trong, nên gọi tay chỉ để bạn xem trước khi cho sửa.
Ba tầng soi, từ diff tới PR

Chạy cái đầu là đủ cho việc thường ngày. Hai cái sau dành cho thay đổi có rủi ro.

01

Soi phần đang chờ commit. Gõ trần là nó tự lấy diff hiện tại.

▸ Gõ trong Claude
/ck:code-review --pending
Đi theo protocol Spec → Quality → Verify: săn bug, regression, chỗ lệch khỏi ý định ban đầu. --pending chỉ là cách nói rõ ra "soi phần chưa commit". Nó nhận cả ba kiểu đầu vào khác: số PR (/ck:code-review 142), một mã commit, hoặc codebase để quét cả repo — cái cuối này chậm, đừng dùng cho việc thường ngày.
02

Năm chuyên gia cãi nhau về thay đổi của bạn — và cãi trước khi bạn code, không phải sau.

▸ Gõ trong Claude
/ck:predict "chuyển session sang JWT" --files "src/auth/**"
Kiến trúc, bảo mật, hiệu năng, UX, vận hành — mỗi persona soi một góc rồi ra báo cáo. Nó cần bạn mô tả thay đổi, chứ không tự đọc diff như /ck:code-review. --files khoanh vùng cho nó đỡ đoán. Dùng khi thay đổi chạm vào tiền, auth, hoặc dữ liệu người dùng — rẻ nhất là nghe họ cãi lúc còn chưa viết dòng nào.
03

Khi code đã thành một PR.

▸ Gõ trong Claude
/ck:review-pr 142 --fix --reply
Soi trùng lặp công việc cũ, chuẩn dự án, breaking change, và các mẫu "AI-slop". --fix tự vá, --reply đăng nhận xét thẳng lên GitHub — hai cờ này đều ghi ra ngoài thế giới thật, nên lần đầu cứ chạy trần (/ck:review-pr 142), đọc báo cáo, rồi mới bật.
Commit sạch, ship có nghi thức

Cùng một nghi thức mỗi lần, nên bạn không quên bước nào lúc vội.

01

Commit sạch, tự quét secret.

▸ Gõ trong Claude
/ck:git cm
Tự tách commit theo type/scope chuẩn conventional. Quét bảo mật trước khi ghi — một API key lỡ tay bị chặn ngay tại đây. cm là commit; đổi đuôi là đổi việc: cp commit rồi push, pr mở PR, merge-pr review-rồi-merge một PR có sẵn.
02

Một lệnh, cả pipeline ship. Lần đầu chạy ở một repo lạ thì diễn tập trước.

▸ Gõ trong Claude
/ck:ship beta --dry-run
Merge nhánh đích → chạy test → review trước khi land → bump version → cập nhật CHANGELOG → push → mở PR. beta về dev, official về main. --dry-run cho bạn xem nó định làm gì mà không làm thật — bỏ ra sau khi đã thấy đường đi đúng. Có --skip-tests đấy, nhưng bạn không muốn dùng nó đâu.
KHÁC BOOTSTRAP — CHỖ NÀY NÓ KHÔNG HỎI BẠN

/ck:bootstrap dừng lại xin ý bạn ở từng chặng. /ck:ship thì không. Nó chạy một mạch tới lúc push và mở PR.

Luật của nó ghi rõ: chỉ dừng đúng ba trường hợp — test đỏ, review phát hiện lỗi nghiêm trọng, hoặc phải nâng version lớn. Ngoài ba cái đó, nó không hỏi lại câu nào. Nên với repo lạ, --dry-run chính là cái phanh duy nhất của bạn: xem nó định đụng vào nhánh nào, push đi đâu — rồi mới chạy thật. Đọc trước khi bấm, chứ đừng bấm rồi mới đọc.
03

Nó tự nhận diện stack và nền tảng.

▸ Gõ trong Claude
/ck:deploy
Hơn 15 nền tảng: Vercel, Cloudflare, Netlify, Railway, Fly.io, AWS, GCP… Tự lo biến môi trường và bước build.
Ngã ba đường: resume, hay bắt đầu lại?

Câu hỏi "context còn khoẻ không" quyết định bạn đi đường nào. Trả lời sai thì chở nguyên đống rối đi tiếp.

VIỆC CỦA BẠN — CHỌN ĐƯỜNG TRƯỚC

Chỉ có một câu hỏi, và bạn là người trả lời: phiên cũ còn dùng được không?

Còn khoẻ — phiên vừa dừng vài phút trước, AI vẫn đang bám đúng việc → đi bước 01. · Đã đuối — phiên kéo dài cả buổi, AI bắt đầu quên đầu quên đuôi, hoặc bạn quay lại sau vài ngày → đừng resume, mở phiên mới rồi đi bước 02. Resume một phiên đã rối là chở nguyên đống rối đó theo.
01

Nếu context vẫn còn khoẻ — chọn phiên cũ, nhận lại toàn bộ ngữ cảnh, đi tiếp đúng chỗ vừa dừng.

▸ Gõ trong Claude
/resume
Không có tiền tố ck: — đây là lệnh của chính Claude Code, không phải của kit. Nó hiện danh sách các phiên cũ trong đúng thư mục này để bạn chọn.
02

Lấy lại trí nhớ của chính bạn — mở phiên mới, rồi bắt nó đọc lại hiện trạng từ git.

▸ Gõ trong Claude
/ck:watzup
Không tham số nào cả — cứ gõ trần. Nó không đọc lịch sử chat (chat đã mất rồi); nó dựng lại hiện trạng từ thứ còn sót lại trên đĩa: nhánh git, worktree, và các file kế hoạch còn dở.

Bạn nhận về một bản bàn giao, không phải một cục tóm tắt lan man:

đang ở đâuvừa làm gìkế hoạch còn dở · % xongroadmap5–6 việc tiếp theocảnh báo
Ô đậm là phần đáng tiền: nó đếm số ô - [ ] đã tick trong các file plan để ra phần trăm hoàn thành, rồi xếp hạng việc tiếp theo — kế hoạch đang dở dang và nằm đúng nhánh bạn đang đứng được ưu tiên lên đầu, kèm một dòng lý do. Nó chỉ đọc, không đổi nhánh, không commit — nên chạy lúc nào cũng an toàn.
Nhận repo lạ, chưa biết bắt đầu từ đâu

Đừng đọc từ file đầu tiên. Hỏi đúng câu, và bắt AI đọc hộ.

01

Quét trước, đọc sau. Nhiều agent chạy song song tìm xem thứ bạn cần nằm ở đâu.

▸ Gõ trong Claude
/ck:scout "luồng đăng nhập" ts
Nó trả về đúng những file liên quan, thay vì bắt bạn mò từng thư mục. Chữ thứ hai (ts) là phần mở rộng — không bắt buộc, nhưng ở repo lớn nó cắt bớt nhiễu rất nhiều. Đây là lệnh rẻ nhất để chạy đầu tiên: nhiều agent quét song song, trả về danh sách file chứ không đổ cả repo vào ngữ cảnh.
02

Hỏi thẳng. Chỉ đọc, không sửa file nào — bước an toàn nhất để thăm dò.

▸ Gõ trong Claude
/ck:ask "token refresh xảy ra ở đâu, ai gọi nó?"
Hỏi được câu cụ thể là đã hiểu một nửa. Chưa chốt được hướng? Dùng /ck:brainstorm — nó hỏi ngược lại bạn.
03

Viết lại thành tài liệu, để lần sau không phải mò lại.

▸ Gõ trong Claude
/ck:docs init
Đây cũng là cách tiết kiệm token mạnh nhất: lần sau chỉ cần bảo nó "đọc tài liệu này", khỏi quét lại cả repo. Ba việc, chọn một: init dựng tài liệu từ đầu · update cập nhật lại sau khi code đã đổi · summarize tóm tắt nhanh. Chỉ chạy init một lần — về sau dùng update, đừng dựng lại từ đầu.
Quét nhanh trước, soi sâu sau

Hai lệnh, và hai cú pháp khác nhau — chỗ này dễ gõ nhầm nhất.

01

Quét nhanh: secret hardcode, lỗ hổng dependency, OWASP Top 10.

▸ Gõ trong Claude
/ck:security-scan --full
Ở lệnh này --full là một cờ. Chạy vài phút, thấy ngay những lỗi rõ ràng nhất. Nó quét ba nhóm: secret (grep theo mẫu regex), dependency (chạy thẳng npm audit / pip audit), và mẫu code nguy hiểm. Mỗi phát hiện được chấm mức: CRITICAL / HIGH / MEDIUM. Vội thì cắt hẹp lại: --secrets-only hoặc --deps-only — chỉ mất vài chục giây. Muốn soi một góc thôi thì đưa đường dẫn: /ck:security-scan src/api/.
02

Soi sâu: STRIDE + OWASP, rồi thả bốn kẻ tấn công vào.

▸ Gõ trong Claude
/ck:security full --red-team
Chú ý: ở đây full không có hai gạch — nó là phạm vi, không phải cờ. Muốn hẹp hơn thì đưa glob: /ck:security "src/api/**" --red-team. Không có --red-team thì nó chỉ quét một lượt rồi ra báo cáo.

--red-team nghĩa là gì: nó lần lượt đội bốn cái đầu khác nhau, mỗi cái tìm một kiểu lỗ:

hacker bên ngoài·chuỗi cung ứng·người bên trong·hạ tầng
Vòng lặp này tốn thời gian và token — nên nó có phanh: --iterations 2 chặn không cho lặp quá hai vòng. Không cần chạy mỗi lần commit. Để dành cho trước ngày ra mắt, hoặc ngay sau khi bạn vừa đụng vào auth, thanh toán, dữ liệu người dùng. Sửa CSS với sửa chữ thì đừng gọi nó.
VIỆC CỦA BẠN — TRƯỚC KHI BẬT --fix

Thêm --fix thì nó tự vá các lỗi Critical/High mà nó tin là thật. Đọc báo cáo trước đã.

▸ Gõ trong Claude
/ck:security "src/api/**" --red-team --fix --iterations 2
Bảo mật là chỗ vá sai còn hại hơn không vá — một bản vá auth làm sai chỗ có thể khoá luôn người dùng thật. Chạy không có --fix trước, đọc, rồi mới quyết định cho nó tự vá.
Đóng phiên sao cho ngày mai mở lại được

Ba lệnh rẻ nhất trong cả bộ kit, và bị bỏ qua nhiều nhất.

01

Đã ship gì, đang dở gì, tiếp theo là gì.

▸ Gõ trong Claude
/ck:watzup
Chạy nó mỗi khi quay lại sau một quãng nghỉ — và ngay trước khi rời đi.
02

Ghi quyết định và lý do trước khi đóng phiên.

▸ Gõ trong Claude
/ck:journal
Cái bạn quên không phải là code — mà là vì sao bạn viết nó như vậy.
03

Nhìn lại một tuần bằng số, không bằng cảm giác.

▸ Gõ trong Claude
/ck:retro 1w --format html
Commit/ngày, churn rate, tỉ lệ test, file nào bị sửa nhiều nhất — tất cả đọc thẳng từ lịch sử git, không phải từ trí nhớ ai cả. 1w là khoảng thời gian (đổi thành 2w, 1m tuỳ bạn) · --compare so với kỳ trước, để thấy xu hướng chứ không chỉ một con số · --format html ra file mở bằng trình duyệt, tiện gửi cho người khác. File bị sửa đi sửa lại nhiều nhất thường là chỗ thiết kế đang sai — đọc con số đó trước.

Chín việc này là 90% công việc thật. Còn 84 lệnh nữa — nhưng chúng để tra cứu, không cần thuộc.

0:00

Chia sẻ ảnh

Bắt đầu gõ để tìm kiếm...