Quy trình 4 AI làm việc nối ca: Bạn chỉ cần duyệt ở phút cuối

Ý tưởng gốc rất đơn giản: Thay vì bắt một AI vừa nghĩ vừa làm vừa tự chấm điểm mình, ta chia việc ra cho bốn AI, mỗi con một vai, và bắt chúng bàn giao cho nhau bằng file. Nghe thì to tát nhưng tất cả những gì bạn phải làm chỉ là bỏ năm file text vào đúng chỗ trong dự án.

Trang này có đủ: Nội dung nguyên vẹn của năm file đó để bạn copy về, chỗ đặt từng file, cách cài cho người chưa từng mở thư mục ẩn bao giờ, và những cái bẫy khiến dây chuyền đứng im giữa đêm mà ít ai nói tới.

1. Vì sao chia bốn vai lại ăn đứt một AI ôm hết

Trước khi vào việc, mấy chữ sẽ gặp đi gặp lại trong bài, giải thích theo kiểu nói chuyện:

• Agent (hay subagent): Một “nhân viên AI” có bản mô tả công việc riêng. Bạn viết bản mô tả đó vào một file, Claude Code đọc file rồi nhập vai đúng như vậy mỗi khi được gọi. Y như thuê thêm người và đưa họ tờ giấy ghi rõ làm gì, không được làm gì.[1]
• Codebase (hay repo): Toàn bộ code của dự án bạn đang làm, nằm trong một thư mục do git quản lý.
• Cửa sổ ngữ cảnh: Trí nhớ làm việc của AI trong một phiên, và nó có giới hạn. Cứ hình dung cái bàn làm việc: Chất càng nhiều giấy tờ lên bàn thì càng khó vớ đúng tờ mình cần.
• Token: Đơn vị AI đọc và viết, đại khái một từ tiếng Việt tốn vài token. Tiền tính theo token, nên “tốn nhiều token” chính là “tốn nhiều tiền”.
• Lệnh gạch chéo: Câu lệnh tắt do bạn tự đặt, gõ dấu / kèm tên lệnh trong Claude Code là nó chạy. Lát nữa ta sẽ đặt một lệnh tên /ship.[2]

Chuyện gì xảy ra khi một AI ôm hết

Bắt một con vừa lên kế hoạch, vừa gõ code, vừa viết test, vừa tự chấm bài, thì mọi thứ dồn chung vào một cửa sổ ngữ cảnh. Ghi chú kế hoạch nằm cạnh code, code nằm cạnh log lỗi, log lỗi nằm cạnh nhận xét review. Cái bàn đầy giấy, và chất lượng tụt xuống không phải vì AI dốt mà vì nó đang gánh bốn vai một lúc.

Còn một chuyện tế nhị hơn. Khi người viết code cũng chính là người chấm code, nó sẽ nghiêng về kết luận nào mà nó vá được. Test đỏ thì nó sửa code cho xanh, thay vì dừng lại nói với bạn rằng thiết kế đang sai từ gốc. Bạn nhận được một mớ test xanh và một cảm giác an toàn giả.

Chia bốn thì mỗi con nhẹ đầu

Planner chỉ nghĩ chuyện kế hoạch. Coder chỉ nghĩ chuyện thi công. Tester chỉ nghĩ chuyện bắt lỗi. Reviewer chỉ nghĩ chuyện duyệt hay không duyệt. Bàn làm việc của con nào cũng gọn, và không con nào phải bênh vực sản phẩm của chính mình.

Thứ giữ cả dây chuyền lại với nhau: Cuốn sổ bàn giao

Bốn agent không nói chuyện trực tiếp với nhau. Chúng để lại file trong một thư mục chung tên là .bangiao, và con sau đọc file của con trước. Planner để lại bản kế hoạch. Coder đọc kế hoạch, làm xong thì để lại bản tóm tắt đã sửa những gì. Tester đọc bản tóm tắt, chạy test xong để lại kết quả. Reviewer đọc cả ba rồi để lại phán quyết.

Đúng kiểu ca trực nối ca trong nhà máy: Người về ghi sổ, người vào đọc sổ rồi làm tiếp. Không ai cần biết ba người kia đang nghĩ gì trong đầu.

Yêu cầu của bạn
      ↓
[ Planner · Opus 5 ]     →  .bangiao/ke-hoach.md
      ↓
[ Coder · Sonnet 4.6 ]   →  code trong repo + .bangiao/thay-doi.md
      ↓
[ Tester · Sonnet 4.6 ]  →  file test + .bangiao/ket-qua-test.md
      ↓
[ Reviewer · Opus 5 ]    →  .bangiao/danh-gia.md  (CHỐT / CẦN SỬA / CHẶN)
      ↓
   Bạn đọc, bạn quyết, bạn gộp nhánh

2. Dựng dây chuyền trong 5 phút

Cả bộ máy này chỉ nằm trong hai thư mục, đặt ngay trong dự án của bạn:

• .claude/agents/ chứa bốn file mô tả bốn agent. Mỗi file ghi rõ nó là ai, được đụng vào công cụ nào, chạy trên model nào.
• .claude/commands/ chứa file ship.md, tức người nhạc trưởng gọi bốn agent kia ra theo đúng thứ tự.

Riêng .bangiao/ thì bạn khỏi tạo. Planner sẽ tự sinh ra nó ngay lần chạy đầu tiên.

du-an-cua-ban/
├── .claude/
│   ├── agents/
│   │   ├── planner.md
│   │   ├── coder.md
│   │   ├── tester.md
│   │   └── reviewer.md
│   └── commands/
│       └── ship.md
├── .bangiao/           ← Planner tự tạo ở lần chạy đầu
└── ... code của bạn ...

3. Agent 1 (Planner): Người vẽ bản thiết kế

Planner tuyệt đối không gõ một dòng code nào. Việc duy nhất của nó là biến câu yêu cầu mơ hồ của bạn thành một bản kế hoạch cụ thể tới mức Coder cứ thế làm mà không phải đoán chữ nào.

Bản kế hoạch ở đây giống bản vẽ thi công hơn là một cái tóm tắt: Sửa file nào, viết hàm gì, hàm nhận vào và trả ra cái gì, gặp tình huống oái oăm nào thì phải xử lý ra sao.

Planner để lại gì trên sổ bàn giao

Đúng một file: .bangiao/ke-hoach.md. Trong đó có đường dẫn từng file, chữ ký từng hàm, danh sách trường hợp biên, và tên file mẫu để Coder bắt chước cách viết. Chỗ nào còn mơ hồ, nó không đoán bừa mà ghi lên đầu file thành mục CÂU HỎI CÒN BỎ NGỎ, và cả dây chuyền dừng ngay tại đó để chờ bạn trả lời.

Vì sao con này được chạy Opus 5

Kế hoạch là bước có đòn bẩy lớn nhất. Vẽ sai bản thiết kế thì thợ càng giỏi càng xây nhanh ra một cái nhà sai. Opus 5 là model mạnh nhất hiện có ở khoản suy luận kiến trúc và nhìn ra những tình huống ít ai nghĩ tới, mà nó lại chỉ chạy đúng một lượt cho mỗi tính năng, nên phần đắt thêm không đáng bao nhiêu so với cái nó cứu được.

planner.md (người vẽ bản thiết kế)

Đọc codebase rồi viết kế hoạch ra .bangiao/ke-hoach.md. Chỉ có bốn công cụ Read, Grep, Glob, Write. Cố tình không cho Edit và Bash để nó không thể lỡ tay sửa code dù muốn.

Đặt tại .claude/agents/ · Model: Opus 5 · Không đụng được vào code

---
name: planner
description: Biến một yêu cầu tính năng thành bản kế hoạch triển khai. Chặng đầu tiên của dây chuyền bốn agent.
tools: Read, Grep, Glob, Write
model: opus
---

Bạn là chuyên gia lập kế hoạch. Bạn KHÔNG viết code.

Khi nhận một yêu cầu tính năng:

1. Đọc những phần liên quan của codebase để nắm quy ước đang có: Cách đặt
   tên, cấu trúc thư mục, thư viện đang dùng, kiểu viết test.

2. Viết bản kế hoạch ra .bangiao/ke-hoach.md với đủ các mục sau:
   - Những file cần tạo mới hoặc cần sửa, kèm đường dẫn chính xác.
   - Chữ ký hàm hoặc interface cần có.
   - Các trường hợp biên bắt buộc phải xử lý.
   - Quy ước cần bám theo, ghi rõ TÊN FILE để copy quy ước từ đó.

3. Chỗ nào còn mơ hồ thì gom lên ĐẦU file thành mục CÂU HỎI CÒN BỎ NGỎ.
   Tuyệt đối không tự đoán ý người dùng.

Viết ngắn và chặt. Coder chỉ đọc đúng file này chứ không đọc gì khác, nên
đừng để hở chỗ nào, và cũng đừng thêm thắt yêu cầu mà không ai đòi.

4. Agent 2 (Coder): Người thi công

Coder cầm bản thiết kế và xây đúng như bản thiết kế. Nó không bàn lại kế hoạch, không tự chấm điểm mình, không tiện tay dọn dẹp mấy file bên cạnh. Chỉ xây.

Coder để lại gì trên sổ bàn giao

Code thật trong repo, kèm file .bangiao/thay-doi.md ghi đã đụng vào những file nào, mỗi chỗ sửa để làm gì, và chỗ nào Tester nên soi kỹ. Chính bản ghi này giúp Tester biết cần nhắm vào đâu thay vì test lan man.

Vì sao con này chạy Sonnet 4.6

Khi bản thiết kế đã rõ, việc còn lại là gõ cho nhanh, cho chính xác, cho đúng phong cách repo. Đó đúng là sở trường của Sonnet 4.6, mà giá lại rẻ hơn Opus 5 nhiều lần. Coder cũng là con sinh ra nhiều chữ nhất trong cả dây chuyền, nên để nó ở model rẻ là chỗ tiết kiệm lớn nhất.

coder.md (người thi công)

Đọc .bangiao/ke-hoach.md, viết code, rồi ghi tóm tắt ra .bangiao/thay-doi.md. Có đủ bộ công cụ vì đây là agent duy nhất được phép chạm vào code sản phẩm.

Đặt tại .claude/agents/ · Model: Sonnet 4.6 · Được sửa code

---
name: coder
description: Triển khai bản kế hoạch nằm ở .bangiao/ke-hoach.md. Chặng thứ hai của dây chuyền, chạy ngay sau planner.
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
---

Bạn là chuyên gia triển khai.

1. Đọc trọn file .bangiao/ke-hoach.md. Nếu trong đó có mục CÂU HỎI CÒN BỎ
   NGỎ, hãy DỪNG LẠI và nêu các câu hỏi đó ra, đừng tự đoán.

2. Xây đúng những gì bản kế hoạch mô tả. Bám theo các quy ước mà nó chỉ
   định. Không thêm tính năng nào mà kế hoạch không yêu cầu.

3. Ghi tóm tắt ngắn ra .bangiao/thay-doi.md, gồm: Những file đã thay đổi,
   mỗi chỗ sửa để làm gì, và chỗ nào Tester nên soi kỹ.

Code bạn viết phải khớp phong cách sẵn có của repo. Không dọn dẹp, không
cải tiến những đoạn code không liên quan, không làm gì nằm ngoài phạm vi
bản kế hoạch.

5. Agent 3 (Tester): Người nghiệm thu

Tester đọc xem thợ vừa xây gì, rồi viết test để chứng minh cái đó chạy đúng, rồi chạy thử. Test rớt thì cả dây chuyền dừng. Nó không được cầm búa đi sửa, chỉ được ghi vào sổ là chỗ nào hỏng.

Tester để lại gì trên sổ bàn giao

Các file test trong repo, kèm .bangiao/ket-qua-test.md nói rõ xanh hết hay là con nào rớt và rớt vì lý do gì.

Vì sao không cho nó tự sửa lỗi

Cho Tester sửa code là quay về đúng cái bẫy ban đầu: Người nghiệm thu kiêm luôn người thi công thì chẳng ai còn nghiệm thu thật nữa. Test rớt nghĩa là dây chuyền dừng, để Reviewer phán hoặc để sáng mai bạn tự xử. Cái giữ cho dây chuyền đáng tin chính là chuyện mỗi con chỉ làm đúng phần việc của mình.

tester.md (người nghiệm thu)

Đọc bản tóm tắt thay đổi và bản kế hoạch, viết test cho đường chạy thuận lợi, cho các trường hợp biên và ít nhất một trường hợp phải thất bại, chạy thử rồi ghi kết quả ra .bangiao/ket-qua-test.md.

Đặt tại .claude/agents/ · Model: Sonnet 4.6 · Chỉ viết file test

---
name: tester
description: Viết và chạy test cho những thay đổi mô tả trong .bangiao/thay-doi.md. Chặng thứ ba của dây chuyền.
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
---

Bạn là chuyên gia kiểm thử.

1. Đọc .bangiao/thay-doi.md để biết vừa có gì được xây và nằm ở đâu.

2. Đọc các file đã thay đổi và bản kế hoạch ở .bangiao/ke-hoach.md.

3. Viết test bao được ba nhóm: Đường chạy thuận lợi, các trường hợp biên
   mà bản kế hoạch đã nêu tên, và ít nhất một trường hợp phải thất bại.
   Dùng đúng framework test mà repo đang dùng.

4. Chạy test. Có con nào rớt thì ghi phần rớt vào .bangiao/ket-qua-test.md
   rồi DỪNG LẠI. Không tự sửa code.

5. Xanh hết thì cũng ghi rõ vào .bangiao/ket-qua-test.md.

Bạn chỉ được tạo và sửa file test. Không đụng vào code sản phẩm, kể cả
khi bạn đã nhìn ra chỗ sai và biết cách vá trong ba giây.

Bạn kiểm thử hành vi, không kiểm thử ruột gan bên trong. Một test rớt
nghĩa là dây chuyền dừng cho Reviewer xử lý, chứ không phải để bạn lách
cho nó xanh.

6. Agent 4 (Reviewer): Người ký duyệt

Đây là cánh cửa cuối cùng trước khi có thứ gì đó chạm tới nhánh chính. Nó đọc hết mọi thứ ba con kia để lại, tự chạy git diff để xem code thật, rồi phán. Con này cũng chạy Opus 5, vì bắt được một lỗi tinh vi ở đây rẻ hơn nhiều so với việc gặp lại nó khi khách hàng đang dùng.

Chi tiết quan trọng nhất: Reviewer không được sửa

Đây là chủ ý, không phải quên cấp quyền. Nếu Reviewer sửa được code, gặp chỗ gợn nó sẽ vá cho êm rồi ghi “ổn” vào sổ, thế là bản đánh giá mất sạch giá trị. Một con chỉ được nhìn thì chẳng còn cách nào khác ngoài nói thật những gì nó thấy. Chính cái ràng buộc cứng đó làm nên chất lượng của bước cuối.

Cách siết cũng chỉ là một dòng: Ở mục tools: bạn cho nó Read, Grep, Glob và Bash, không Write, không Edit. Tài liệu chính thức của Claude Code cũng khuyên cấp cho mỗi subagent đúng bộ công cụ tối thiểu mà vai đó cần, không hơn.[1]

Bash thì vẫn phải để lại, vì không có nó thì Reviewer không chạy được git diff. Muốn chặt hơn nữa thì bỏ luôn Bash và tự dán kết quả diff vào cho nó đọc, đổi lại bạn mất khả năng chạy tự động qua đêm.

Ba phán quyết

Kết quả nằm ở .bangiao/danh-gia.md, luôn mở đầu bằng một trong ba chữ. Chữ “gộp nhánh” bên dưới nghĩa là đưa nhánh tính năng nhập vào nhánh chính:

• CHỐT: Code khớp kế hoạch, test có giá trị thật, không thấy vấn đề. Bạn đọc lại một lượt rồi gộp nhánh.
• CẦN SỬA: Chạy được nhưng có chỗ phải chỉnh. Reviewer liệt kê rõ sửa gì, ở file nào, dòng nào.
• CHẶN: Có vấn đề nặng về bảo mật, tính đúng đắn hoặc hiệu năng. Đừng gộp nhánh.

reviewer.md (người ký duyệt)

Đọc kế hoạch, bản thay đổi, kết quả test, chạy git diff, rồi ghi phán quyết CHỐT, CẦN SỬA hoặc CHẶN ra .bangiao/danh-gia.md.

Đặt tại .claude/agents/ · Model: Opus 5 · Chỉ đọc, không sửa

---
name: reviewer
description: Đánh giá lần cuối toàn bộ kết quả của dây chuyền. Chặng thứ tư, ngay trước khi con người ký duyệt.
tools: Read, Grep, Glob, Bash
model: opus
---

Bạn là reviewer cấp cao. Bạn CHỈ ĐỌC. Bạn không sửa code.

1. Đọc bản kế hoạch, bản tóm tắt thay đổi và kết quả test trong thư mục
   .bangiao/.

2. Chạy git diff để nhìn chính xác những gì đã thay đổi.

3. Trả lời ba câu: Code có khớp bản kế hoạch không? Test có giá trị thật
   hay chỉ viết cho có? Có vấn đề gì về bảo mật, hiệu năng, tính đúng đắn
   không?

4. Ghi phán quyết ra .bangiao/danh-gia.md, mở đầu bằng đúng một dòng:

   PHAN QUYET: CHOT / CAN SUA / CHAN

   Nếu là CAN SUA hoặc CHAN, liệt kê rõ cần sửa cái gì, ở file nào, dòng
   nào. Không nói chung chung.

Bạn chỉ dùng Bash cho các lệnh đọc như git diff, git log, git status.
Không chạy lệnh làm thay đổi file hay thay đổi lịch sử git.

Bạn là tuyến phòng thủ cuối. Test xanh mà code sai thì vẫn phải nói CHAN.
Xanh không đồng nghĩa với đúng.

7. Lệnh /ship: Nhạc trưởng của cả bốn

Bốn agent đứng riêng thì vẫn phải gọi từng con một. File này là người xâu chuỗi: Bạn gõ một dòng, nó gọi Planner, chờ có kế hoạch mới gọi Coder, chờ có bản thay đổi mới gọi Tester, và chỉ khi test xanh mới tới lượt Reviewer.

Chữ $ARGUMENTS trong file là chỗ trống: Mọi thứ bạn gõ sau /ship sẽ được nhét vào đúng vị trí đó.[2] Nhờ vậy một file duy nhất dùng cho mọi tính năng, không phải sửa gì thêm. Muốn đổi tên lệnh thì đổi tên file, đặt là lam.md thì lệnh thành /lam.

ship.md (nhạc trưởng)

Chạy trọn bốn chặng, tự dừng khi gặp câu hỏi bỏ ngỏ hoặc test rớt, có chốt chặn không cho chạy trên nhánh chính, và không bao giờ tự gộp nhánh.

Đặt tại .claude/commands/ · Gõ: /ship

---
description: Chạy trọn dây chuyền bốn agent cho một yêu cầu tính năng.
---

Chạy trọn dây chuyền làm tính năng cho: $ARGUMENTS

Làm lần lượt các chặng dưới đây, không nhảy cóc. Sau mỗi chặng, kiểm tra
file bàn giao đã tồn tại rồi mới sang chặng kế tiếp.

0. Xem đang đứng trên nhánh git nào. Nếu là nhánh chính (main hoặc
   master), dừng lại và báo cho tôi, không chạy tiếp.
   Sau đó dọn thư mục .bangiao/, tức xoá ke-hoach.md, thay-doi.md,
   ket-qua-test.md và danh-gia.md của lần chạy trước, để không ai đọc
   nhầm file cũ.

1. Giao việc cho subagent planner kèm yêu cầu tính năng ở trên.
   Chờ tới khi có .bangiao/ke-hoach.md.

2. Nếu bản kế hoạch có mục CÂU HỎI CÒN BỎ NGỎ, dừng lại và đưa các câu
   hỏi đó cho tôi. Nếu không có, giao việc cho subagent coder.
   Chờ tới khi có .bangiao/thay-doi.md.

3. Giao việc cho subagent tester.
   Chờ tới khi có .bangiao/ket-qua-test.md.
   Có test rớt thì dừng lại và cho tôi xem phần rớt.

4. Giao việc cho subagent reviewer. Cho tôi xem .bangiao/danh-gia.md.

Báo lại phán quyết cuối cùng. Không gộp nhánh, không push, không tạo pull
request. Cứ để nguyên nhánh đó cho tôi tự xem.

Gõ như thế nào

Mở Claude Code trong dự án, tách nhánh mới, rồi gõ một dòng kiểu như dưới đây. Chữ “endpoint” trong ví dụ đầu là địa chỉ mà ứng dụng gọi tới trên máy chủ, ở đây là chỗ xử lý việc đăng nhập:

/ship thêm giới hạn tần suất cho endpoint đăng nhập

/ship làm trang cài đặt người dùng, có phần bật tắt nhận email thông báo

/ship viết lại module thanh toán để đỡ được nhiều loại tiền tệ

Từ đó nhạc trưởng lo phần còn lại. Trục trặc ở chặng nào thì nó dừng ngay chặng đó và nói rõ chuyện gì đã xảy ra, chứ không âm thầm đi tiếp.

8. Tiền: Ai được chạy model đắt

Nói thẳng: Chạy bốn agent tốn token hơn hẳn chạy một con. Đó là cái giá của chất lượng. Nhưng cách chia model dưới đây giữ hoá đơn ở mức chịu được, vì hai vai ngốn nhiều chữ nhất đều nằm ở model rẻ.

• Planner, Opus 5: Chạy đúng một lượt cho mỗi tính năng. Cần đầu óc tốt nhất để nhìn kiến trúc và đoán trước rắc rối. Trả thêm ở đây là trả cho chất lượng của cả ba chặng sau.
• Coder, Sonnet 4.6: Sinh nhiều chữ nhất. Nhưng xây theo bản vẽ có sẵn thì không cần tới mức suy luận của Opus 5, mà Sonnet 4.6 lại rẻ hơn nhiều lần.
• Tester, Sonnet 4.6: Cùng lý do. Viết và chạy test cho những thay đổi đã biết rõ là việc có khuôn, Sonnet 4.6 làm gọn.
• Reviewer, Opus 5: Cũng chỉ một lượt. Đây là chỗ cuối cùng còn cơ hội bắt lỗi, nên đừng tiếc.

Phần lớn token rơi vào Coder và Tester, tức hai vai đang chạy model rẻ, nên hoá đơn không đội lên theo số lượng agent. Tỉ lệ cụ thể nhảy theo độ lớn của tính năng, vậy nên đừng tin con số của ai hết, chạy vài lần rồi tự xem mức tiêu thụ của mình.

Cách chia này cũng khớp với những gì đội kỹ thuật của Anthropic chia sẻ khi họ dựng hệ nhiều agent: Chạy nhiều agent tốn token gấp bội một phiên chat thường, nên chọn model theo từng vai là cần câu chính để giữ chi phí.[3]

9. Để nó chạy trong lúc bạn ngủ

Đây là phần vui nhất, và cũng là phần nhiều người thất bại ngay đêm đầu tiên. Không phải vì dây chuyền dở, mà vì hai cái bẫy rất đời thường dưới đây.

Cấp quyền tới đâu, mất kiểm soát tới đó

Ba cách dưới đây xếp từ chặt tới lỏng. Càng xuống dưới càng ít bị hỏi, và càng ít cơ hội chặn lại khi nó làm sai.

Mức 1, duyệt tay vài đêm đầu. Chạy vài tính năng lúc bạn còn ngồi đó. Mỗi lần nó xin phép một lệnh bạn thấy hợp lý, chọn “Yes, and don’t ask again”. Claude Code tự ghi lại thành một dòng cho phép trong .claude/settings.local.json, file riêng của bạn và không bị đẩy lên git. Sau vài đêm, danh sách đó đủ để dây chuyền chạy trơn mà bạn chẳng phải nới thêm gì. Đây là cách nên chọn.

Mức 2, tự viết danh sách cho phép. Nóng ruột thì viết thẳng file, mỗi dòng là một công cụ hoặc một kiểu lệnh. Quan trọng hơn cả danh sách cho phép là danh sách chặn, vì chặn luôn thắng cho phép. Gõ /permissions trong Claude Code để xem dòng nào đang có hiệu lực và tới từ file nào.

{
  "permissions": {
    "allow": [
      "Edit",
      "Write",
      "Bash(git diff:*)",
      "Bash(git status:*)",
      "Bash(npm test:*)"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(git push:*)",
      "Bash(git checkout:*)",
      "Bash(curl:*)",
      "Read(./.env)"
    ]
  }
}

Đổi npm test thành lệnh chạy test thật của dự án bạn. Hai dòng chặn git push và git checkout giữ cho nó không đẩy code lên hay tự nhảy nhánh trong lúc bạn ngủ, còn Read(./.env) giữ file khoá bí mật nằm ngoài tầm với.

Mức 3, tắt hỏi. Có chế độ cho nó tự duyệt mọi thứ, và có cả cờ bỏ qua sạch phần xin phép. Chạy kiểu đó thì nó xoá file, gọi mạng hay chạy bất cứ lệnh nào cũng không ai cản, sáng ra gặp chuyện thì chẳng còn bước nào để lần lại. Nếu buộc phải dùng, chỉ dùng trong repo của riêng bạn, trên nhánh phụ, trên máy không chứa dữ liệu công ty hay khoá bí mật, và đã commit sạch trước khi đi ngủ.

Trước khi đi ngủ

Tách nhánh mới. Kiểm tra máy không tự ngủ. Gõ /ship kèm yêu cầu, rồi ngồi lại chừng một phút xem chặng Planner khởi động trơn tru đã, thấy nó bắt đầu đọc file thì mới yên tâm đi ngủ.

Sáng hôm sau

Mở nhánh đó, đọc .bangiao/danh-gia.md trước tiên:

• CHỐT: Đọc lại code một lượt bằng mắt mình rồi gộp nhánh. Đừng bỏ qua bước đọc.
• CẦN SỬA: Xem góp ý cụ thể, rồi tự tay sửa hoặc chạy lại dây chuyền với yêu cầu đã chỉnh cho rõ hơn. Định chạy lại thì chép .bangiao/danh-gia.md ra chỗ khác trước, vì chặng đầu của /ship dọn sạch thư mục đó.
• CHẶN: Đừng gộp. Đọc lý do, và chín trên mười lần bạn sẽ thấy gốc rễ nằm ở chỗ bản kế hoạch ban đầu thiếu một ràng buộc quan trọng.

Quyết gộp rồi thì hai dòng dưới đây là xong, chạy trong Terminal ở thư mục dự án:

git checkout main
git merge ten-tinh-nang

# đổi main thành master nếu dự án của bạn đặt tên nhánh chính như vậy
# không ưng thì bỏ luôn cả nhánh: git branch -D ten-tinh-nang

Dây chuyền không tự gộp gì hết, nó luôn để nguyên nhánh cho bạn xem lại. Nó làm việc, bạn ra quyết định, và đó là ranh giới không nên xoá.

10. Mẹo để dây chuyền chạy ngon

Bảy điều dưới đây là thứ chỉ nhận ra sau khi chạy thật vài lần. Bấm vào từng dòng để mở ra đọc:

git worktree add ../du-an-tinh-nang-a -b tinh-nang-a
cd ../du-an-tinh-nang-a

# mở Claude Code ngay trong thư mục này rồi gõ /ship
# làm xong thì dọn: git worktree remove ../du-an-tinh-nang-a