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

Playbooks — copy các bước, dán vào Claude

Sáu tình huống thật, hai bộ kit. Chọn việc bạn đang làm, copy từng bước. Không cần nhớ lệnh.

Trang này không phải để đọc — để dùng. Chọn bộ kit hợp với việc bạn đang làm, chọn tình huống, rồi copy từng bước một.

Nếu bạn đang bắt đầu một dự án mới, dùng buildflow. Nếu bạn đang chạy một task trong repo đã có, dùng autocode-kit. Phần giải thích sâu nằm gọn phía dưới mỗi playbook — mở ra khi cần.

Claude Code Foundation · Session 3

Chọn việc bạn đang làm.
Copy các bước.

Hai bộ kit, sáu tình huống. Mỗi bước cho bạn thấy chính xác thứ cần gõ — ô sẫm là câu nói với AI, ô đen là lệnh gõ trong Claude. Bấm COPY rồi dán vào.

mode teach · 2–4 giờ
Từ ý tưởng trong đầu tới card đầu tiên

Bạn tự viết mọi artifact, AI chỉ gác cổng và từ chối những chỗ hời hợt. Đây là cách học phương pháp.

01

Copy repo buildflow vào thư mục dự án mới, mở Claude Code trong đó, rồi kiểm tra mode.

▸ Gõ trong Claude
/flow mode
Thấy mode: teach là đúng đường. Bạn luôn gõ /flow — nó tự chạy script bash bên dưới.
02

Nói cho AI biết bạn muốn gì, rồi mở chặng đầu tiên.

▸ Nói với AI
Mình muốn dựng một app nhỏ giúp chủ tiệm spa quản lý lịch hẹn.
Mình dùng buildflow, mode teach. Bắt đầu giúp mình.
▸ Rồi gõ
/flow next
Nó tạo ra flow/00-idea.mddừng lại chờ bạn viết.
VIỆC CỦA BẠN

Mở flow/00-idea.md. Viết pitch đúng 3 câu. Nêu tên một người thật đang có nỗi đau này. Tự tick các ô gate.

AI không được phép điền hộ. Người viết chính là người học. Nếu bạn viết hời hợt, bước sau nó sẽ trả lại.
CHỈ BẠN LÀM ĐƯỢC — Ở TERMINAL

Tick xong các ô gate trong file, ký tên vào chặng đó. Không ký thì cổng không mở.

▸ Gõ trong terminal, không phải trong Claude
$ bash .claude/skills/flow/runner/flow.sh sign 00-idea
AI gõ lệnh này sẽ bị từ chối: "REFUSED — sign requires a real terminal". Cố ý như vậy — chữ ký là việc của người vận hành. Nếu chưa ký, /flow next báo "unsigned: no operator signature". Sửa file sau khi ký thì chữ ký hết hiệu lực và cổng đóng lại.
03

Xin qua cổng. Đạt thì nó mở chặng sau; chưa đạt thì nó chỉ đúng chỗ còn thiếu.

▸ Gõ
/flow next
Không chắc mình viết đủ chưa? Hỏi thẳng nó:
▸ Nói với AI
Đọc flow/01-research.md giúp mình. Chỗ nào còn hời hợt
hay thiếu bằng chứng thật? Đừng sửa hộ, chỉ chỉ ra thôi.
Lặp bước ✎ và bước 03 cho tới hết chặng 05. Sáu vòng cả thảy.
04

Xong contract, sinh card build đầu tiên.

▸ Gõ
/flow card
C-001 luôn là scaffold + CI/CD: repo, pipeline deploy, /healthz trên một URL công khai.
05

Trước khi code, để AI trích test case từ chính app thay vì bịa ra từ chữ trong card.

▸ Gõ
/verify-plan C-001
VIỆC CỦA BẠN

Xây đúng phần ## Scope, chỉ chạm file trong ## Allowed files. Chạy từng bước ## Verify thật, dán output thật vào ## Evidence, rồi mới đặt status: done.

▸ Nhờ AI xây, đúng phạm vi
Xây card cards/C-001.md giúp mình. Chỉ chạm các file trong
mục Allowed files. Xong thì dừng lại, đừng tự đánh dấu done —
mình sẽ tự chạy phần Verify.
06

Cổng ra của card.

▸ Gõ
/flow check C-001
Nó đọc diff. Chạm file ngoài ô Layer: đã khai → chặn. Evidence trống → hook đã chặn từ trước đó rồi.
07

Xong hết card thì khép vòng lại. Ba câu hỏi, ba file.

▸ Gõ
/flow retro
RETRO.md (bạn lướt cổng nào, và trả giá gì?) · playbooks/ (stack dạy bạn bài học nào?) · FLOW-FEEDBACK.md (bản thân buildflow nên sửa gì?)
AI phỏng vấn một lần, rồi tự soạn kế hoạch

Nó dừng lại đúng một chỗ: cổng scope. Gates và luật "xong" không đổi — chỉ đổi ai cầm bút.

01

Đổi mode sang work.

▸ Gõ
/flow mode work
02

Kể trước bối cảnh — nó sẽ không hỏi lại những gì bạn đã nói. Càng kể kỹ, càng ít bị phỏng vấn.

▸ Nói với AI
Mình dựng app đặt lịch cho một tiệm spa thật ở Đà Nẵng —
chị chủ đang ghi sổ tay và hay trùng lịch.
Ngân sách: 2 tuần, làm buổi tối.
Stack: Cloudflare Workers + Hono + D1. Deploy lên Cloudflare.
Bắt buộc có: đặt lịch, xem lịch trong ngày.
Cắt được: thanh toán online, app mobile.
Thành công = chị ấy bỏ hẳn sổ tay sau 2 tuần.
▸ Rồi gõ
/flow next
Nó hỏi thêm tối đa 2 lượt, mỗi lượt tối đa 4 câu — chỉ hỏi thứ không suy ra được.
VIỆC CỦA BẠN — DUY NHẤT MỘT LẦN

Nó dừng ở cổng scope và đưa bạn: bảng impact×grade, ba tính năng nó tự đề xuất (mặc định để OUT), danh sách cắt, và khuyến nghị GO / KILL.

KILL cũng là thắng. Bạn vừa cứu chính ngân sách thời gian của mình. Giữ flow/ làm hồ sơ, mở bản buildflow mới cho ý tưởng kế tiếp.
CHỈ BẠN LÀM ĐƯỢC — Ở TERMINAL

Duyệt bảng scope xong, ký vào chặng đó. Mode work đổi ai cầm bút — không đổi việc ai ký.

▸ Gõ trong terminal, không phải trong Claude
$ bash .claude/skills/flow/runner/flow.sh sign 02-scope
Mỗi cổng cần một chữ ký. AI gõ lệnh này sẽ bị từ chối — chữ ký là việc của người vận hành. Sửa file sau khi ký thì chữ ký hết hiệu lực, cổng đóng lại.
03

Duyệt scope xong, nó chạy tiếp tới hết chặng 05. Sinh bộ card trước đã — không có card thì hai lệnh sau đều từ chối.

▸ Gõ
/flow card
/flow ready trả lời "No cards yet — /flow card", còn /flow auto báo "PREFLIGHT FAIL — no cards". Chạy lệnh này trước.
04

Duyệt scope xong, nó chạy tiếp tới hết chặng 05 và giao cả bộ card trong một bản tóm tắt. Xem card nào xây được ngay.

▸ Gõ
/flow ready
Cho biết nhóm card nào chạy song song an toàn.
05

Để nó tự xây. Nó tự chạy preflight trước — chỉ đi tiếp khi thấy PREFLIGHT OK.

▸ Gõ
/flow auto
Một subagent mỗi card. Nhóm 2+ card → mỗi agent một worktree riêng. Bạn (planner) tự chạy ## Verify, không tin lời subagent báo về.
VIỆC CỦA BẠN

Đọc AUTO-LOG.md — không phải đọc scrollback. Card cần credential, cần bạn duyệt mock UI, hay deploy lần đầu → nó tự gắn blocked-on-operator rồi đi làm card khác.

▸ Quay lại sau, hỏi nó
Đọc AUTO-LOG.md rồi tóm tắt giúp mình: card nào xong,
card nào đang chờ mình, card nào fail và vì sao.
Card fail 2 lần thì nó dừng card đó và đi tiếp. Không cày cố.
Không bắt đầu từ lời hứa — bắt đầu từ bằng chứng

App đã chạy thật. Ba cổng thay vì sáu. Card đầu tiên không phải tính năng mới.

01

Đổi đường ngay lập tức, trước khi làm bất cứ việc gì khác.

▸ Gõ
/flow track brownfield
Lỡ bắt đầu greenfield? rm -rf flow/* TRACK rồi chạy lại. Đã có file trong flow/ thì không đổi track được — cố ý như vậy, để artifact không bị mồ côi.
02

Quét app thật. Mọi finding đều phải trích file:line.

▸ Nói với AI
App này là API đặt lịch, chạy Cloudflare Workers + D1.
Mình muốn thêm gửi email xác nhận, mà sợ làm vỡ luồng thanh toán.
Quét giúp mình trước.
▸ Rồi gõ
/audit
Ra flow/00-xray.md: findings F1..Fn xếp theo severity × evidence, tách riêng khỏi phần đề xuất. Bạn mới là người quyết đề xuất nào thành card.
03

Đóng băng findings, để về sau diff được xem mình đã sửa gì.

▸ Gõ
/flow rescan baseline
04

Đi qua ba cổng: 00-xray01-scope02-contract-delta. Chạy lệnh này ba lần.

▸ Gõ
/flow next
CHỈ BẠN LÀM ĐƯỢC — Ở TERMINAL

Ba cổng brownfield, mỗi cổng một chữ ký: 00-xray, 01-scope, 02-contract-delta.

▸ Gõ trong terminal, không phải trong Claude
$ bash .claude/skills/flow/runner/flow.sh sign 00-xray
Mỗi cổng cần một chữ ký. AI gõ lệnh này sẽ bị từ chối — chữ ký là việc của người vận hành. Sửa file sau khi ký thì chữ ký hết hiệu lực, cổng đóng lại.
05

Sinh card đầu tiên.

▸ Gõ
/flow card
C-001 = characterization — ghim lại những gì không được phép vỡ. Chỉ sau đó mới tới C-002 cho tính năng mới.
06

Trích test case từ chính app: Zod schema, ràng buộc DB, route surface, test sẵn có.

▸ Gõ
/verify-plan C-001
Chỉ 3–5 journey quan trọng nhất mới xứng đáng e2e. Suite toàn e2e là nguồn flake số một.
Hai loại lệnh — đừng gõ nhầm

Bạn luôn gõ trong Claude: /flow …, /audit, /verify-plan C-NNN. /flow tự gọi script bash flow.sh bên dưới rồi trả kết quả nguyên văn cho bạn. Còn /flow audit thì không tồn tại/audit là một skill riêng.

Mở lại repo sau một tuần, không nhớ đang dở gì

Một lệnh, không tham số. File chính là trạng thái — nó đọc thư mục và nói bạn đang đứng ở đâu.

01

Hỏi thẳng nó.

▸ Gõ
/flow
Cho biết mode hiện tại, chặng đang đứng, và cổng nào còn kẹt.
02

Đọc kỹ dòng cảnh báo hook, nếu có.

Nếu nó in "HOOKS MAY NOT BE ARMED — the gate is currently ADVICE, not law" thì cổng của bạn chỉ còn là lời khuyên: không có gì ngăn AI tự tick ô gate hay tự viết source. Sửa xong thì khởi động lại Claude — hook chỉ nạp lúc mở phiên.
Dừng lại ở cổng scope — và đó là một kết quả tốt

buildflow coi bỏ cuộc đúng lúc là một lối ra hợp lệ, không phải thất bại. Bạn vừa tiết kiệm chính thời gian của mình.

01

Để AI soạn nhanh tới cổng scope.

▸ Gõ
/flow mode work
02

Đi tới khi nó dừng ở 02-scope và đưa bảng impact × grade kèm khuyến nghị GO / KILL.

▸ Gõ
/flow next
QUYẾT ĐỊNH CỦA BẠN

Đọc bảng. Không có kênh cụ thể để lấy 10 người dùng đầu? Không nêu được một người thật đang có nỗi đau này? Đó chính là tín hiệu KILL.

Chính runner cũng nói vậy khi cổng chưa đạt: "No advance. Fix flow/…md first. (Killing the idea here is also a valid exit.)" Giữ lại thư mục flow/ làm hồ sơ, rồi mở một bản buildflow mới cho ý tưởng kế tiếp.
Đóng băng lỗi cũ, rồi chứng minh đã sửa xong

Chỉ dành cho brownfield. Đóng băng trước khi sửa — không có ảnh chụp lúc đầu thì về sau không so được.

01

Quét xong (/audit), đóng băng danh sách findings.

▸ Gõ
/flow rescan baseline
Chưa /audit thì nó từ chối: "no flow/00-xray.md — run /audit first".
VIỆC CỦA BẠN

Xây các card sửa lỗi như bình thường.

02

Quét lại, rồi so với ảnh chụp lúc đầu.

▸ Gõ
/audit
▸ Rồi gõ
/flow rescan report
Nó liệt kê [STILL OPEN] — lỗi cũ chưa sửa — và [NEW] — lỗi bạn vừa tạo ra khi sửa. Cột thứ hai mới là cột đáng sợ.
Hiểu sâu hơn về buildflow — sáu cổng, giải phẫu một card, sơ đồ 11 ô
01

Một câu luật, mọi thứ khác theo sau

Nếu bạn chỉ nhớ một dòng từ buildflow, hãy nhớ dòng này.

Luật trung tâm

Xong = bằng chứng ngoài đời thật.
"Test xanh" chỉ là giữa đường.

Mỗi card phải nêu done-evidence ngay từ đầu: một URL bạn bấm được, output của một lệnh curl, một dòng thật trong database. Một hook bash exit 2 sẽ chặn nếu bạn đánh dấu status: done mà mục ## Evidence còn trống.

Điều bất ngờ nhất

Dừng ý tưởng ở cổng scope là một thành công, không phải thất bại. Bạn vừa tiết kiệm chính ngân sách thời gian của mình. Giữ lại thư mục flow/ làm hồ sơ, rồi mở một bản buildflow mới cho ý tưởng kế tiếp.

02

Sáu chặng, sáu cổng

Chạy /flow next: nó kiểm cổng của chặng hiện tại. Đạt → mở template chặng sau. Chưa đạt → nó nói đúng chỗ còn thiếu. Dưới đây là checklist thật của từng cổng.

00
Ý tưởng
flow/00-idea.md
Cổng đòi hỏi
Pitch đúng 3 câu, không hơn
Nêu tên được ít nhất một người thật đang có nỗi đau này
01
Nghiên cứu
flow/01-research.md
Cổng đòi hỏi
Bạn thật sự đã mở 3 công cụ đối thủ, kèm link và một nhận xét thật thà
Trích 3 lời than phiền thật của người dùng, có nguồn
Viết ra giá thật đối thủ đang thu, và ai đang trả
Nêu một kênh cụ thể để có 10 người dùng đầu — một nơi, không phải "mạng xã hội"
02
Phạm vi
flow/02-scope.md
Cổng đòi hỏi
Mỗi tính năng có impact (H/M/L) kèm lý do kinh doanh và một grade (A/B/C)
Không tính năng L-impact nào trên grade A sống sót vào v1
Mọi C còn trong scope đều được biện minh bằng đường 1, 2 hoặc 3
03
PRD
flow/03-prd.md
Cổng đòi hỏi
Success metric là một con số. "Tiết kiệm thời gian" trượt; "phản hồi đầu < 2h" đạt
Bảng ánh xạ pain → feature: mỗi pain có bằng chứng, mỗi feature giết ít nhất một pain
Một người lạ dựng được v1 từ đây mà không cần hỏi bạn câu nào
04
ADR — quyết định kiến trúc
flow/04-adr.md
Cổng đòi hỏi
Mỗi quyết định có một dòng "vì sao"một dòng "đã loại bỏ gì"
Danh sách những thứ KHÔNG làm đã được viết ra
Đã quyết đủ: lưu trữ dữ liệu, cách xác thực, nơi deploy
05
Contract — cái mối nối
flow/05-contract.md
Cổng đòi hỏi
Mọi tính năng trong PRD ánh xạ tới ít nhất một endpoint
Mỗi endpoint có cả shape request lẫn response
Cột auth điền đủ cho mọi endpoint: public / token / admin
Vì sao contract là chặng cuối của phần kế hoạch

Contract là cái mối nối.

Nó được viết trước khi có một dòng code nào. Backend xây theo nó, UI tiêu thụ từ nó. Không bên nào được ứng biến. Nếu contract sai — sửa flow/05-contract.md trước, rồi mới code theo.

03

Một card = một ô

Đây là thước đo "card này có to quá không". Mỗi card khai báo đúng một ô trên dòng Layer:. /flow check đọc diff và chặn nếu bạn chạm sang ô khác. Card chạm hai ô = hai trách nhiệm = hai card.

REQUEST PIPELINE — 11 Ô Route Validation Authn Authz Command Domain Persistence Event chưa tồn tại Listener chưa tồn tại Adapter chưa tồn tại Audit MỘT CARD = MỘT Ô ô đã có code trong repo ô còn trống — card sẽ tạo ra nó Ô trống không phải lỗi — nó là một phát hiện. Khai báo Layer: Listener rồi chạm vào routes/ → BỊ CHẶN.
04

Giải phẫu một card

Card là brief của một phiên làm việc. Một phiên, một card. /flow check là cổng ra.

CARDS/C-003.MD
# C-003 — resident reply endpoint status: todo deps: C-001, C-002 Layer: Command ← đúng MỘT ô ## Scope ← nếu là hai việc, tách thành hai card ## Allowed files ← diff bước ra ngoài = /flow check chặn ## Verify ← /verify-plan trích case TỪ app, không bịa ## Done-evidence ← nêu TRƯỚC khi xây: người ta THẤY gì? ## Evidence ← dán output thật vào đây, rồi mới status: done
Hook chặn #1

gate-before-code.sh — không cho ghi source code khi các cổng kế hoạch còn mở.

Hook chặn #2

no-done-without-evidence.sh — không cho đặt status: done khi mục Evidence trống.

Vì sao là hook, không phải lời nhắc

Một skill là lời khuyên — model có thể tự nói vòng qua nó. Một hook là luật: exit 2 và lệnh ghi file không bao giờ xảy ra. Cả hai hook đều fail-open: hook lỗi thì cho qua, vì một cái cổng kẹt cứng còn tệ hơn không có cổng.

05

Thứ tự xây, không phải thứ tự thích

Contract trước, rồi một lát cắt dọc mỏng tới URL đã deploy, rồi mới đi rộng. Lát cắt sớm vừa là liều động lực, vừa là bằng chứng tích hợp.

C-1Scaffold + CI/CD — repo, pipeline deploy, /healthz trên URL công khaiURL healthz
C-2Lát cắt dọc — một endpoint + một trang xấu xí gọi nó, đã deploytrang chạy thật
C-3Backend — mỗi card một nhóm endpoint, xây theo contract/docs có schema đúng
C-4Contract-test — quét mọi endpoint với edge + failure case trên API đã deploysuite xanh
C-5UI mock — HTML tĩnh, chữ thật, không logic. Mock chính là buổi design reviewoperator đã xem & duyệt
C-6Frontend — hiện thực đúng mock đã duyệt, tiêu thụ contractgiao diện chạy
C-7E2E — test trình duyệt trên app ĐÃ DEPLOY; chạy nó cũng là verify-livetrace + video

Vì sao mock trước framework: sửa một mock tốn vài giây, sửa một framework tốn cả lượt deploy.

06

Hai đường: app mới và app đang chạy

Mặc định là greenfield. App đã có code? Đổi đường ngay lập tức, trước khi làm gì khác.

Greenfield · 6 cổng
Bắt đầu từ con số không

Từ một ý tưởng chưa có dòng code nào.

00-idea01-research02-scope
03-prd04-adr05-contract
Bắt đầu từ: một lời hứa
/flow card → C-001 = scaffold
Brownfield · 3 cổng
App đã chạy sẵn

Bạn không pitch ý tưởng — bạn nâng cấp một hệ thống đang sống.

00-xray01-scope02-contract-delta
/audit quét code, mọi finding trích file:line
Bắt đầu từ: bằng chứng
/flow card → C-001 = characterization
Hai loại lệnh — khác nhau ở chỗ ai làm việc

Tất cả đều gõ trong Claude. /flow track|next|card|checkcổng máy móc — nó chạy script bash bên dưới rồi trả kết quả nguyên văn. /audit/verify-planskill — AI đọc code, thả agent đi dò. /flow audit không tồn tại.

~3–4 giờ người · 3–7 ngày
Một tính năng, từ ý tưởng tới PR đã merge

Bảy lệnh, và bạn chỉ thật sự làm việc ở hai chỗ: chốt Scope OUT, và đọc card trước khi dispatch.

01

Xem mình đang đứng ở đâu trước khi động vào gì.

▸ Gõ
/mindful brief
Ra bảng: đang ở nấc nào trên thang PRD → ADR → journey → ExecPlan → cards → dispatch → review → merge, card nào đang bay, tín hiệu gì từ ba retro gần nhất.
02

Viết PRD. Nó phỏng vấn bạn 8–10 câu rồi mới soạn — và từ chối brief dưới 20 chữ.

▸ Nói với AI
/prd-author Thêm tính năng rút gọn link cho dashboard.
Người dùng là marketer, họ đang dán link dài vào bài post
và không đo được click. Cần đếm click theo ngày.
Chưa cần custom domain trong v1.
Ra docs/prd/0001-<slug>.md. Nó không cho chốt khi thiếu Scope OUTOpen questions.
VIỆC CỦA BẠN · ~45 PHÚT

Mài phần Scope OUT. Đây là việc đắt giá nhất trong cả tính năng — mọi thứ sau đó đều nở ra từ đây.

Cắt được gì thì cắt ngay bây giờ. Cắt ở PRD tốn một dòng; cắt lúc code tốn cả một card.
03

Mỗi quyết định kiến trúc một ADR. Lặp lệnh này 2–4 lần cho mỗi tính năng.

▸ Nói với AI
/adr-author Lưu mapping slug → URL ở đâu:
Postgres hay Redis? Cần đọc rất nhiều, ghi ít.
Bắt buộc ít nhất 2 phương án thay thế và phải viết ra mặt tiêu cực bạn chấp nhận. Trạng thái mặc định là proposed — bạn tự đổi thành accepted.
04

Journey = hợp đồng "xong" của tính năng, viết bằng thứ người dùng quan sát được.

▸ Gõ
/journey-author PRD-0001
Nhắc tới class, bảng, endpoint là nó trả lại. Journey chỉ được nói Given/When/Then.
05

Chia phase. Phase 0 luôn là "viết E2E từ journey, xác nhận nó fail".

▸ Gõ
/execplan-author PRD-0001
Quá 8 phase là nó từ chối — dấu hiệu bạn chưa chia nhỏ vấn đề.
06

Sinh card. Mỗi card có allowed_files, acceptance criteria, và cách tự verify.

▸ Gõ (một lần cho mỗi phase)
/task-card T-001 tạo bảng links + migration
Plan có ≥6 card và phụ thuộc rắc rối? Dùng /task-graph <feature> để vẽ DAG. Plan tuần tự tầm thường thì nó từ chối vẽ.
VIỆC CỦA BẠN · ~25 PHÚT

Đọc từng card trước khi dispatch. Đây là 25 phút có đòn bẩy cao nhất trong cả quy trình.

▸ Nhờ nó soi hộ
Đọc docs/tasks/url-shortener/T-001.md giúp mình.
Scope có bị rộng quá không? allowed_files có thiếu file nào
mà chắc chắn phải sửa không? Chỉ ra, đừng sửa.
07

Thả card vào worktree riêng. Nó tạo nhánh t-001-<slug> và spawn một executor mới.

▸ Xem trước, không chạy
/task-dispatch T-001 --dry-run
▸ Rồi chạy thật
/task-dispatch T-001
hỏi bạn "yes" trước khi spawn — đó mới là cổng thật. Card thiếu allowed_filestừ chối dispatch.
08

Executor báo về bằng PR. Chấm nó.

▸ Gõ
/review-pass T-001
Ra PASS / REQUEST-CHANGES / ESCALATE, mỗi finding trích file:line. Nhiều hơn 3 comment nghĩa là card đã quá to.
09

PASS rồi thì merge. Chưa có scheduler tự động — bạn gõ tay.

▸ Gõ trong terminal
$ gh pr merge --squash --delete-branch
Lặp bước 07→09 cho từng card. Tính năng xong khi E2E của journey chuyển xanh.
Bug production — sửa một lần, khoá vĩnh viễn

Không PRD, không ADR. Cái test bạn viết ra mới là thứ ngăn nó quay lại.

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

Tái tạo bug tại chỗ. Xác nhận bạn thấy nó bằng mắt, không phải đoán.

Chưa tái tạo được thì chưa sửa được. Bước này không có lệnh nào thay thế.
01

Viết một test fail đúng lý do — pha đỏ. Đây là bước khoá bug lại.

▸ Nói với AI
Bug: slug có ký tự hoa thì redirect trả 404,
mà lẽ ra phải không phân biệt hoa thường.
Viết cho mình một test fail đúng vì lý do đó, chạy trên HEAD.
Chưa sửa code vội.
Xác nhận nó đỏ vì đúng nguyên nhân, không phải đỏ vì lý do khác.
02

Soạn card sửa. Thường một card là đủ, đôi khi hai.

▸ Nói với AI
/task-card T-042 sửa lookup slug thành không phân biệt
hoa thường; test vừa viết phải chuyển xanh
03

Thả vào worktree. Executor sửa trong đó, không đụng vào cây làm việc của bạn.

▸ Gõ
/task-dispatch T-042
Test mới phải chuyển xanh, và mọi test cũ vẫn phải xanh.
04

Chấm rồi merge.

▸ Gõ
/review-pass T-042
▸ Rồi trong terminal
$ gh pr merge --squash --delete-branch
Từ giờ, cái test đó ngăn bug quay lại mãi mãi. Đó mới là sản phẩm thật của quy trình này — không phải dòng code sửa.
05

Bug này có phải dấu hiệu của một luật còn thiếu không?

▸ Hỏi nó
/mindful tune slug lookup phân biệt hoa thường
Nếu có, thêm một rule vào .harness/invariants.yaml, gắn source: trỏ về đúng con bug này. Chỉ thêm khi đã bị đau thật — không bao giờ thêm trước.
Cài kit vào một repo đã có sẵn

Pre-flight khắt khe: sai một điều là nó dừng. Đó là điểm cộng, không phải phiền toái.

01

Mở một phiên Claude Code trong repo autocode-kit (không phải trong dự án đích). Xem trước nó định làm gì.

▸ Gõ
/harness-bootstrap /duong/dan/toi/du-an --dry-run
Pre-flight kiểm: đích phải là git repo; .harness/ phải vắng mặt (cài mới) hoặc có mặt (nâng cấp); CLAUDE.md của bạn được giữ nguyên.
02

Ổn rồi thì cài thật.

▸ Gõ
/harness-bootstrap /duong/dan/toi/du-an
Nó copy skill + .harness/ sang, rồi ghi dự án vào watched-projects.yaml. Nâng cấp về sau: thêm --upgrade.
03

cd sang dự án đích, mở phiên Claude Code mới ở đó, rồi xem harness đứng đâu.

▸ Gõ
/mindful brief
Dự án mới thì chưa có retro, chưa có ExecPlan — nó báo vậy một cách bình thản.
04

Kiểm cái cổng máy. Lúc này nó chưa có luật nào, và đó là chủ ý.

▸ Gõ trong terminal
$ python3 .harness/check_invariants.py --full
rules: []. Bạn chỉ thêm luật khi một ADR hoặc một con bug đã làm nó trở nên cụ thể — không bao giờ thêm phòng xa.
VIỆC CỦA BẠN · ~30 PHÚT MỖI TUẦN

Mỗi tuần, nhìn lại chỗ nào card hay kẹt, hay bị REQUEST-CHANGES. Chọn đúng một thứ để siết.

▸ Nói với AI
/mindful drift
Một rule mới trong invariants.yaml, hoặc một convention rõ hơn trong CLAUDE.md, hoặc sửa template card. Tuần sau harness chặt hơn tuần này.
Đừng bật tự trị quá sớm

Harness chỉ đáng tin khi bộ test đã xanh ổn định và bạn đã chạy tay quy trình ít nhất một lần. Tự động hoá một quy trình chưa đáng tin chỉ nhân rộng những chỗ còn lệch.

Mở repo ra, không biết đang đứng ở đâu trên thang

Thang của kit: prd → adr → journey → execplan → cards → dispatch → review → merge. Hỏi nó, đừng đoán.

01

Hỏi bước kế tiếp. Nó đọc trạng thái trên đĩa rồi trả lời.

▸ Gõ trong Claude
/mindful next
Đây là lệnh dùng nhiều nhất của mindful — nó là router, không phải một chặng trong pipeline.
02

Nghi ngờ harness đang lỏng dần? Bắt nó tự soi.

▸ Gõ trong Claude
/mindful drift
Trả về chỗ kỷ luật đang trôi, kèm một việc nên siết lại. Muốn chỉnh tham số thì /mindful tune.
Chỉ soi một card, rồi tự tay merge

Không cần chạy cả pipeline. Một lệnh review, một lệnh merge.

01

Soi diff của đúng một card.

▸ Gõ trong Claude
/review-pass T-203
Ra PASS, REQUEST-CHANGES hoặc ESCALATE, kèm bằng chứng file:line. Tối đa 3 nhận xét — nhiều hơn nghĩa là card quá to. Diff chạm file ngoài allowed_filestự động ESCALATE.
02

PASS rồi thì merge. Chưa có skill auto-merge — đây là bước cơ học duy nhất bạn gõ tay.

▸ Gõ trong terminal
$ gh pr merge --squash --delete-branch
Merge là việc đảo ngược được bằng một revert commit — đó là lý do kit cho phép nó chạy tự động ở chế độ khác.
Giao cả epic cho nó, sáng mai đọc log

Chạy không cần trông. Nhưng đọc kỹ cảnh báo dưới đây trước khi bấm.

CẦN QUYẾT ĐỊNH TRƯỚC KHI CHẠY

Ở chế độ goblock, planner tự review rồi tự merge chính việc của executor mìnhkhông có cổng người thứ hai ở bước merge.

Tài liệu kit nói thẳng: hợp cho dự án mới, việc rủi ro thấp. Việc nhạy cảm thì dispatch và review tự động, còn merge tự tay — hoặc ngồi trông.
01

Mô tả epic (ít nhất ~20 chữ) rồi thả nó chạy.

▸ Nói với AI
/mindful block "thêm luồng đặt lịch cho tiệm spa: chọn dịch vụ, chọn giờ, xác nhận qua email, huỷ trước 2 tiếng"
Nó phỏng vấn thêm tối đa 2 lượt, rồi chạy tới hết.
02

Muốn từng bước một, có phanh? Dùng go thay vì block.

▸ Gõ trong Claude
/mindful go
Tối đa 10 vòng lặp mỗi lần gọi. Hết 10 vòng nó dừng và bảo bạn gọi lại — phanh này để một lỗi state-machine không dispatch mãi không thôi. Nó in [go N/10] để bạn thấy đang ở vòng nào.
VIỆC CỦA BẠN — SÁNG HÔM SAU

Đọc log của run, không đọc scrollback.

Card nào xong, card nào chờ bạn, card nào fail và vì sao.
Hiểu sâu hơn về autocode-kit — chín bước, cái cổng, bốn việc chỉ bạn làm được
01

Công việc của bạn đổi chỗ

Đây là toàn bộ lời hứa của autocode-kit, gói trong một câu đổi vai.

Vai cũ
Viết code · review code · debug code

Nút cổ chai là tốc độ gõ phímngân sách chú ý của bạn.

Vai mới
Viết spec · siết harness · quyết chuyện khó

Nút cổ chai giờ là phán đoán của bạn. Đó là thứ đáng để dành.

02

Chín bước, mỗi bước một lệnh

Mỗi bước phỏng vấn bạn rồi mới soạn. Không có bước nào tự chạy ngầm — cả 12 skill đều disable-model-invocation, tức là chỉ chạy khi bạn gọi tên.

SOẠN THẢO — BẠN DUYỆT TỪNG ARTIFACT /prd-author cái gì & vì sao /adr-author vì sao đường này /journey-author người dùng thấy gì /execplan-author chia phase /task-graph DAG khi cần THỰC THI — MÁY CHẠY, CỔNG GÁC /task-card card có allowed_files /task-dispatch worktree riêng biệt /review-pass PASS / CHANGES / ESC check_invariants.py mọi rule đều BLOCKING merge E2E xanh Phase 0 của MỌI ExecPlan là một bài E2E cố tình fail. Xanh được nó, nghĩa là tính năng thật sự xong. Hôm nay dispatch là THỦ CÔNG: bạn gọi /task-dispatch từng card. Scheduler tự động chưa được xây.
03

Mỗi skill đều biết nói không

Đây là thứ làm autocode-kit khác một đống prompt. Một skill không từ chối được thì không đáng tin để chạy khi bạn ngủ. Dưới đây là những lời từ chối có thật, trích từ chính mã nguồn.

/prd-author
Từ chối brief mỏng

Dưới 20 chữ là nó trả lại và yêu cầu bạn viết thêm bối cảnh. Cũng không cho chốt PRD khi thiếu Scope OUTOpen questions.

/adr-author
Từ chối quyết định một chiều

Bắt buộc ít nhất 2 phương án thay thế và phải viết ra mặt tiêu cực bạn chấp nhận. Mặc định trạng thái là proposed, không phải accepted.

/journey-author
Từ chối ngôn ngữ triển khai

Journey chỉ được nói về thứ người dùng quan sát được. Nhắc tới class, bảng, endpoint là nó trả lại.

/execplan-author
Từ chối quá 8 phase

Nhiều hơn 8 nghĩa là bạn chưa chia nhỏ vấn đề. Phase 0 luôn là "viết E2E từ journey, xác nhận nó fail".

/task-graph
Từ chối vẽ DAG vô ích

Plan chạy tuần tự tầm thường thì nó không vẽ đồ thị — nó bảo bạn dùng cờ phase của ExecPlan cho gọn.

/task-dispatch
Từ chối card không an toàn

Card thiếu allowed_files thì không được phép dispatch. Chọn cmux mà không có cmux? Nó từ chối, chứ không lặng lẽ tụt về tmux.

/test-author
Từ chối mock database

Integration test không được mock DB — dùng testcontainers thật. Mỗi hàm public phải có đủ happy + edge + error.

/e2e-author
Từ chối assert tautology

Chỉ được assert vào hành vi quan sát được. Một test luôn đúng thì không phải test.

/review-pass
Từ chối review dài dòng

Tối đa 0–3 comment. Nhiều hơn nghĩa là card đã quá to — vấn đề nằm ở khâu chia card, không phải khâu review.

/harness-bootstrap
Từ chối cài lên nền bẩn

Pre-flight: phải là git repo, .harness/ phải vắng mặt (cài mới) hoặc có mặt (nâng cấp), CLAUDE.md phải được giữ nguyên. Sai một điều là dừng.

04

Cái cổng thay bạn gác

Khi bạn buông tay, phải có thứ gì đó vẫn nói không. Đó là .harness/invariants.yaml — và điều đáng chú ý nhất là nó ship ra với con số không luật nào.

.HARNESS/INVARIANTS.YAMLshipped empty
version: 1 last_reviewed: 2026-06-03 # Cố tình ĐỂ TRỐNG. Kit ship ra không mang luật nào. # Dự án tự thêm luật khi một ADR hoặc một con bug đã bắt được # khiến nó trở nên cụ thể — không bao giờ thêm trước. rules: []
forbidden_pattern

Cấm một regex xuất hiện trong đường dẫn được chỉ định

forbidden_import

Cấm import một package nhất định

human_checkpoint

Bắt buộc một người thật nhìn qua

forbidden_path

Thư mục này không được phép tồn tại

required_path

Đường dẫn này bắt buộc phải có

required_unique_path

Đúng một, không hơn — ví dụ một binary dưới cmd/

Không có mức "cảnh báo"

Mọi rule khi được thêm vào đều là BLOCKING. Không có warn level. Thấy một rule quá chặt trong thực tế? Hạ nó qua retro, công khai — chứ không lặng lẽ bỏ qua. Mỗi rule mang một trường source truy ngược về đúng cái ADR hoặc cái bug đã sinh ra nó.

05

Card chạy ở đâu, ai chấm

Mỗi card được thả vào một thế giới riêng, để nó có hỏng thì cũng hỏng một mình.

Cô lập
Một worktree cho mỗi card

/task-dispatch tạo một git worktree trên nhánh t-NNN-<slug>, rồi spawn một executor Claude Code hoàn toàn mới trong đó. Tự dò cmux > tmux > print. Operator phải gõ "yes" trước khi spawn — đó mới là cái cổng thật, không phải một cái cờ config.

Chấm điểm
Bash chấm phần máy, LLM chấm phần người

/review-pass chia đôi: runner bash kiểm scope và chạy lệnh verify một cách tất định; LLM đi qua từng acceptance criteria và soi convention. Mỗi finding phải trích file:line. Không có "trông ổn đấy".

PASS

Card đạt. Mở đường cho merge.

REQUEST-CHANGES

Có việc phải sửa, và đã chỉ đúng dòng.

ESCALATE

Vượt tầm card này. Cần một con người.

06

Bốn việc chỉ bạn mới làm được

Thuộc bốn dòng này. Mọi thứ khác đã có skill hoặc script lo.

01Quyết phạm vi PRD — đặc biệt là phần Scope OUT~45 phút · mỗi feature
02Đọc task card trước khi dispatch — 25 phút đòn bẩy cao nhất~25 phút · mỗi feature
03Xử lý hàng đợi cần người xem~12 phút · mỗi mục
04Quyết định siết harness hằng tuần — thêm một rule, sửa một convention~30 phút · mỗi tuần
Nên biết trước khi bắt đầu

Kit này chưa có scheduler tự động — tài liệu STEPS.md có mô tả một scheduler.py, nhưng SKILLS.md nói rõ nó chưa được xây. Hôm nay bạn dispatch thủ công, từng card một, qua /task-dispatch. Muốn auto-merge? Chạy gh pr merge --squash sau khi /review-pass trả PASS.

0:00

Chia sẻ ảnh

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