Chào mừng bạn đến với Fx Studio. Bài này là tập Plan của loạt AI-Native SDLC: cách playbook của Anthropic biến một ý tưởng thành file intent.md, những chỗ mình thấy còn hở và một demo nhỏ làm bằng chứng.

Trong team của bạn, có khi ý tưởng đáng làm nhất lại không nằm trong backlog. Nó nằm trong đầu một người không biết viết user story và chưa ai rảnh để viết giùm. Bước Plan của The AI-native SDLC playbook (Anthropic, 21/8/2026) nhắm đúng vào chỗ đó: người có ý tưởng tự ngồi với Claude và kết quả là một file tên intent.md nằm trong git.

Tóm ý: playbook thay chuỗi backlog, user story, story point, refinement bằng một file intent.md do chính người có ý tưởng viết cùng Claude, product owner duyệt bằng cách merge. Demo nhỏ của mình (một lượt chạy, nhân vật giả lập) cho thấy một điều kiện playbook không nói rõ: Claude không tự hỏi lại, phải có skill bảo nó hỏi và cấm nó tự điền.

Bài này là tập thứ hai của loạt AI-Native SDLC, sau tập tổng quan. Quy ước vẫn như cũ: chỗ nào playbook nói, mình ghi nguồn. Chỗ nào là nhận xét của mình, mình nói rõ.

Bài đi theo ba lớp:

• Playbook nói gì về bước Plan: một file, ba cửa vào, năm bước, cách duyệt, cách đo.
• Mình thử thế nào: một demo nhỏ với app todo, có trích nguyên văn template, checklist và một đoạn intent thật.
• Mình thấy còn hở chỗ nào và vài cách vá ban đầu.

Ý tưởng đi qua bao nhiêu trạm

Ở quy trình quen thuộc, một ý tưởng phải đi qua nhiều trạm trước khi có người bắt tay làm. Nó vào backlog, được viết thành user story, mang ra ước lượng story point, rồi tới buổi refinement. Mỗi trạm là một lần đổi chủ.

Có hai cái giá phải trả.

Một: chậm.

• Từ lúc có ý tưởng tới lúc engineering nhận việc là một vòng thu thập requirement và refinement.
• Playbook tả vòng đó kéo dài nhiều tuần.

Hai: méo.

• Mỗi lần chuyển tay, ý gốc lại được diễn giải thêm một lần.
• Thứ tới tay engineer đã cách người nghĩ ra nó mấy bước.

Còn một rào cản ít ai nói tới: người có ý tưởng thường không phải người viết tài liệu. Playbook tả đúng cảnh này. Họ phải đi thuyết phục một người trong team product viết giúp. Theo mình, nhiều ý tưởng dừng lại ngay ở bước đi thuyết phục đó, chưa kịp vào tới backlog.

Nói vậy không có nghĩa các trạm kia vô lý. Chúng có mặt để lọc ý tưởng trước khi bỏ ra vài tuần viết code, ở cái thời mà code là khâu đắt nhất.

Thứ thay đổi là khâu code không còn đắt như trước. Theo mình, khi agent viết code trong vài giờ vài tuần chờ ở đầu quy trình thành phần chậm, đúng ý “nút thắt dời chỗ” của tập tổng quan.

Một file và ba cửa vào

Playbook thay cả chuỗi trạm đó bằng một file: intent.md. File này là điểm bắt đầu của cả vòng lặp AI-native và mọi bước sau đọc nó để biết phải làm gì.

intent.md có thể đi vào từ ba cửa:

• Một người có ý tưởng.
• Một ticket vừa được tạo.
• Một cảnh báo từ production. Cửa này mình sẽ kể kỹ ở tập Maintain, khi incident trên production quay lại thành requirement mới.

Đi vào từ cửa nào thì luật cũng như nhau: product owner đọc và sửa bản Claude viết, trước khi nó được commit chính thức.

Với team làm việc qua nhánh và pull request, “commit chính thức” chính là lúc product owner bấm merge:

• Merge là chấp nhận.
• Đóng review là từ chối.

Và một intent được chấp nhận sẽ kích hoạt bước tiếp theo: Design.

Cách duyệt này nghe đơn giản, nhưng nó nối thẳng vào ý lớn của tập tổng quan: mỗi bước kết thúc bằng một file commit vào git, bước sau bắt đầu bằng việc đọc file đó. Bước Plan là mắt xích đầu tiên của chuỗi file ấy.

Năm bước từ lời kể tới file

Playbook đi qua năm bước để biến một lời kể thành intent.md.

Bước 1: người có ý tưởng kể với Claude bằng lời thường.

• Hôm nay đang vướng gì, ai bị ảnh hưởng.
• Tốt hơn thì trông thế nào, cái gì nằm ngoài phạm vi.
• Không cần một chữ chuyên môn nào.

Bước 2: Claude hỏi lại như một analyst.

• Phạm vi tới đâu, người dùng là ai, có ràng buộc gì, thế nào thì gọi là thành công.
• Hai bên hỏi qua đáp lại, tới khi ý tưởng đủ cụ thể.

Bước 3: Claude viết kết quả theo template của tổ chức.

• Template này có thể đóng gói thành một skill.
• Skill do một người kỹ thuật dựng và trưởng nhóm duyệt.

Bước 4: người có ý tưởng đọc lại và sửa những chỗ Claude hiểu sai.

Bước 5: file được commit vào chỗ chứa intent chung. Git tự ghi ai viết, viết lúc nào.

Để ý ở bước 1: người nghĩ ra ý tưởng cũng là người viết ra nó. Ý gốc không phải đi qua tay ai nữa. Theo mình, bước dễ hỏng nhất là bước 2 và phần demo phía dưới sẽ cho thấy vì sao.

File intent.md trông thế nào

Ví dụ trong playbook là một tính năng cho khách tự xem trạng thái hồ sơ yêu cầu bồi thường (claim) của mình trên cổng khách hàng, thay vì gọi tổng đài để hỏi.

File intent.md của ví dụ đó có năm phần:

1. Vấn đề.
2. Kết quả mong muốn.
3. Người dùng và hệ thống bị ảnh hưởng.
4. Ràng buộc.
5. Câu hỏi còn mở.

Đọc một lượt là nắm được.

Để chạy được cả chuỗi này, playbook kể ra bốn thứ hạ tầng cần có:

• Người không phải engineer dùng được Claude, qua claude.ai hoặc Cowork.
• Một template thống nhất cho intent.md.
• Một chỗ chứa intent có quản lý phiên bản.
• Một connector tới GitHub, để Claude commit giùm người không biết git.

Về chỗ chứa, đơn giản nhất là một thư mục intent/ ngay trong repo sản phẩm. Repo riêng cho intent chỉ đáng làm khi một intent trải ra nhiều repo.

Phần hạ tầng này team platform hoặc engineering dựng một lần là xong. Một người kỹ thuật trong team quyết định ai được ghi vào chỗ chứa intent. Với team nhỏ, mình nghĩ mấy vai này có khi chỉ là một người.

Dấu vết và cách đo

Bằng chứng audit của bước Plan không phải biên bản họp. Bằng chứng là chính file đã commit: ai viết, lúc nào, sửa những gì. Quyết định của product owner cũng nằm trong git, dưới dạng một lần merge hoặc một review bị đóng.

Playbook đưa ra hai loại chỉ số: chỉ số dẫn (leading) và chỉ số trễ (lagging).

Loại	Chỉ số
Dẫn	Thời gian từ cuộc trò chuyện đầu tiên tới khi intent.md được commit
Trễ	Tỉ lệ intent được product owner chấp nhận sang bước Design
Trễ	Số lần intent phải sửa sau khi spec.md đầu tiên đã commit

Với chỉ số dẫn, playbook kỳ vọng nó giảm từ một vòng nhiều tuần xuống vài giờ. Mình nhắc lại cho rõ: “vài tuần xuống vài giờ” là kỳ vọng của playbook, bài chưa công bố số đo của ai.

Trong ba con số, mình để ý nhất con số cuối. Số lần intent phải sửa sau khi spec đầu tiên ra đời mới cho biết bước Plan đã làm tới nơi hay chưa. Viết intent nhanh mà bước Design phải quay lại sửa intent liên tục thì cái nhanh đó chỉ là dời việc sang sau.

Mình thử với một app todo

Đọc thì thấy gọn, nên mình dựng thử. Phần này không có trong playbook, là thứ mình tự chạy ngày 19/10/2026.

Sản phẩm là một app todo-list rất nhỏ:

• Chạy trên trình duyệt, viết bằng HTML/JS thuần.
• Dữ liệu chỉ nằm trong localStorage của trình duyệt đó.
• Không có server, không có tài khoản.

Mình chọn app nhỏ để ai đọc cũng hiểu và để có ràng buộc thật trong code cho Claude đọc.

Bộ đồ của bước Plan gồm bốn thứ, viết bằng tiếng Anh vì đây là thứ agent đọc:

Thành phần	Vai trò	Ứng với playbook
Skill write-intent (SKILL.md + template.md + checklist.md)	Kiểm trùng, đọc repo, hỏi tối đa 4 câu mỗi lượt, viết theo template, ghi nguồn từng dòng, tự kiểm 6 ô, lưu bản draft	Template đóng thành skill, Claude hỏi như analyst
Subagent intent-reviewer	Chỉ đọc: soi câu không có nguồn, chạy checklist, tìm trùng, gợi câu hỏi cho người kể. Không sửa, không quyết	Thêm của mình, để đỡ cho product owner
Hook no-self-approve.py	Chặn agent chạy git merge, rebase, push và chặn commit trên main	Duyệt bằng merge, agent không tự duyệt
Thư mục intent/ + một nhánh cho mỗi intent	Chỗ chứa intent có quản lý phiên bản	Thư mục intent/ trong repo

Người kể là nhân vật giả lập, không phải người thật. Có ba nhân vật: Lan (chăm sóc khách hàng, không biết kỹ thuật), Minh (kinh doanh) và Hà (người gửi một ticket). Mỗi nhân vật do một phiên Claude khác đóng vai và phiên đó chỉ được trả lời bằng một tờ hồ sơ ghi nhân vật biết gì và không biết gì.

Lời mở của Lan chỉ có vậy:

Dạo này khách cứ email than là mất hết việc trong app, nhất là sau khi đổi điện thoại. Mình muốn làm gì đó để khách không mất việc nữa.

Bản viết luôn, không có skill

Cách thứ nhất, mình bảo Claude viết intent.md luôn, không có skill. Code của app nằm ngay trong thư mục. Claude viết luôn, không hỏi Lan câu nào.

Bản viết ra như chưa từng nhìn vào code (transcript không ghi lượt này có đọc file hay không):

• Nó tưởng đây là app điện thoại: nói tới “cài lại app”, hỏi khách dùng iOS hay Android, nhắc “đánh giá trên store”.
• Nó xếp “bản web” ra ngoài phạm vi, trong khi app chính là bản web.
• Nó đòi giữ lại cả “ghi chú và hạn chót” của từng việc, dù app chưa từng có hai trường đó.

Đây là mục “Không nằm trong phạm vi” của bản đó, nguyên văn:

## Không nằm trong phạm vi (lần này)

- Cộng tác hoặc chia sẻ việc giữa nhiều người.
- Bản web hay bản desktop.
- Đồng bộ thời gian thực giữa nhiều máy dùng cùng lúc. Có thì tốt, nhưng không bắt buộc.

Mình đem bản đó cho subagent intent-reviewer đối chiếu từng câu với nguồn. Kết quả (một lượt chạy, nhân vật giả lập):

• 18 câu không có nguồn: 3 suy luận hợp lý, 12 giả định, 3 giải pháp chen vào chỗ của vấn đề.
• Hai câu mâu thuẫn với code.
• Câu hỏi mở “app lưu dữ liệu ở đâu” vốn đã có câu trả lời trong app/store.js.
• Checklist trượt 4 trên 6 ô.

Mà đọc lướt, bản này trông rất chuyên nghiệp. Đó là chỗ đáng sợ nhất.

Bản có skill

Cách thứ hai, Lan gọi /write-intent. Lần này Claude đọc app/store.js trước, rồi chỉ hỏi Lan những gì code không trả lời được. Hai bên đi qua 3 lượt hỏi đáp.

Kết quả (một lượt chạy, nhân vật giả lập):

• Mỗi dòng trong mục Evidence và Constraints đều ghi rõ lấy từ đâu.
• Claude tự tìm ra một rủi ro Lan không hề nhắc: khi bộ nhớ trình duyệt đầy, app chỉ ghi lỗi ra console, khách không hay biết.
• Claude không tự chọn mức ảnh hưởng, để product owner chọn.
• Mục “Out of scope” để trống, vì Lan không biết và skill cấm tự điền.

Dưới đây là hai mục Evidence và Constraints trong intent của Lan, chép nguyên văn từ nhánh intent/khach-khong-mat-viec của demo. Con số 23 email và 3 khách là dữ kiện trong hồ sơ nhân vật giả lập, không phải số thật của sản phẩm nào.

## Evidence
- Từ 1/10 đến 14/10 có 23 email than mất hết danh sách việc. Lan đã đọc hết [originator]
- 3 khách nói sẽ bỏ app nếu còn mất việc [originator]
- Phần lớn email kể là mất sau khi đổi điện thoại mới hoặc sau khi xoá dữ liệu trình duyệt. Chưa đếm riêng từng loại [originator]
- 5 email nói dùng cả laptop lẫn điện thoại, thêm việc ở máy này thì máy kia không thấy [originator]
- App chỉ lưu việc trong `localStorage` của trình duyệt đang dùng: không có server, không có tài khoản, không đồng bộ. Xoá dữ liệu trang, đổi trình duyệt hoặc đổi máy là bắt đầu lại với danh sách trống [app/store.js]

## Constraints
- Hiện tại app không có tài khoản và không có server [app/store.js]
- Có giữ việc không cần tài khoản hay không và khách có chịu đăng nhập không, là chuyện product owner quyết [originator]
- Một bạn dev có gợi ý "chắc phải làm tài khoản đăng nhập". Đây chỉ là gợi ý, chưa phải quyết định [originator]
- Bộ nhớ `localStorage` có giới hạn, khoảng 5 MB ở đa số trình duyệt. Khi ghi lỗi, app chỉ ghi ra console, khách không được báo [app/store.js]

## Out of scope

Có ba chỗ đáng nhìn trong đoạn trên:

• Nhãn nguồn trong ngoặc vuông cuối mỗi dòng: [originator] là lời người kể, [app/store.js] là file trong repo. Người duyệt biết ngay dòng nào kiểm được bằng cách mở file, dòng nào phải hỏi lại người kể.
• Gợi ý giải pháp bị giữ đúng chỗ: câu “chắc phải làm tài khoản đăng nhập” của một bạn dev được ghi là gợi ý, chưa phải quyết định.
• Mục Out of scope trống. So với bản viết luôn, đây là một lỗ hổng thật, nhưng nó lộ ra chứ không bị lấp bằng câu đoán.

Bản có skill cũng chưa hoàn hảo. Khi subagent intent-reviewer chấm lại bản này, nó bắt được 1 câu gắn nhãn [originator] nhưng Lan không nói đúng như vậy. Nó còn nhắc: 23 email mới chỉ là lời kể, chưa nằm trong repo nên chưa ai kiểm được con số đó.

Câu hỏi chạm vào tiền đề của ticket

Mình chạy thêm cửa thứ hai: intent đi vào từ một ticket. Hà, người gửi ticket, xin đặt hạn chót cho từng việc vì hay quên những việc có deadline. Khi Claude hỏi, Hà kể tuần trước lỡ quên nộp một báo cáo vì không nhớ hạn.

Claude có skill hỏi ngược lại một câu rất đắt:

Cái báo cáo tuần trước có nằm trong danh sách việc của app không? Nếu hôm đó mở app ra mà thấy ngay việc đó đứng đầu danh sách kèm hạn chót, Hà có kịp nhớ ra không? Hay vì hôm đó Hà không mở app nên mới quên?

Câu hỏi này quan trọng vì nếu cái báo cáo không nằm trong app, hiện hạn chót lên danh sách cũng chẳng cứu được lần quên đó. Hà không biết câu trả lời, nên Claude để nó vào phần câu hỏi mở, ghi rõ chỉ Hà trả lời được.

Demo cho thấy gì

Mỗi kịch bản mình chạy một lần, người kể là nhân vật giả lập. Đây là ví dụ thật, không phải thống kê. Người thật trả lời lan man hơn, có khi tự mâu thuẫn.

Nhưng demo đủ để thấy một điều playbook không nói rõ: Claude không tự hỏi. Bản không có skill không hỏi câu nào. Ba bản có skill đều hỏi, vì skill bảo hỏi. Muốn Claude hỏi như một analyst, phải bảo nó hỏi.

Và skill đáng giá nhất ở các luật đi kèm template, không ở bản thân template: đọc repo trước, ghi nguồn, không tự điền.

Chỗ playbook chưa trả lời

Từ đây trở xuống là nhận xét của mình, không có trong bài gốc.

• Product owner thành nút thắt mới.
  • Ai cũng tạo được intent trong vài phút, thì số intent tăng nhanh hơn sức đọc của một người.
  • Hàng đợi chỉ dời từ “chờ người viết” sang “chờ người duyệt”.
  • Trong demo, mỗi intent viết bằng skill kết thúc với 8 tới 10 câu hỏi mở, phần lớn gửi cho product owner (một lượt chạy, nhân vật giả lập).
  • Chỉ số dẫn của playbook lại gộp thời gian viết và thời gian chờ duyệt vào một con số, nên khó thấy đang chậm ở khâu nào.
• Chất lượng phụ thuộc người kể.
  • Claude hỏi lại được, nhưng chỉ hỏi được những gì người kể gợi ra.
  • Người kể không biết hệ thống có ràng buộc gì thì file vẫn trông đầy đủ mà thiếu thứ quan trọng.
  • Như bản viết luôn trong demo, một file viết trôi chảy dễ làm người duyệt tin rằng nó đã được nghĩ kỹ.
• Trùng lặp.
  • Ba người thấy cùng một vấn đề sẽ tạo ra ba intent.
  • Playbook không có bước nào kiểm trùng.
• Yêu cầu đến từ khách hàng bên ngoài.
  • Playbook giả định người có ý tưởng ở trong tổ chức.
  • Làm outsource thì yêu cầu đến từ khách, thường qua một người trung gian như Bridge System Engineer (BrSE), có khi bằng một thứ tiếng khác.
  • Khách không vào repo của mình để viết intent.

Mình sẽ vá thế nào

Đây là vài cách vá ban đầu của mình. Cách 1 và cách 4 đã thử ở demo nhỏ phía trên, các cách còn lại chưa thử. Bạn xem như điểm xuất phát để thử và chỉnh, chưa phải công thức đã kiểm ở quy mô lớn.

Cách 1: checklist trước khi commit

Trước khi lưu bản nháp, cho Claude tự kiểm file theo một danh sách ngắn. Thiếu mục nào thì hỏi lại người kể chứ không tự điền.

Bản đầu của mình có năm ô. Demo chỉ ra năm ô đó chỉ kiểm có mục, chưa kiểm mục đó đúng: bản viết luôn vẫn qua được ô “Out of scope” dù cả ba dòng trong đó là đoán. Nên mình thêm ô thứ sáu và chỉ ô này mới bắt được loại lỗi kia.

Đây là checklist.md trong skill write-intent của demo, nguyên văn:

# Ready-to-review checklist

Run on the draft before saving. A box passes only if the draft itself shows it.

- [ ] **Problem**: says who is affected and when it happens
- [ ] **Evidence**: at least one concrete item (number, ticket, complaint, screenshot)
- [ ] **Out of scope**: section is present and not empty
- [ ] **Success criteria**: checkable (a number or an observable behaviour), not "better" or "faster"
- [ ] **Open questions**: listed in their own section, each with who can answer, none hidden in the body
- [ ] **Sourced**: every statement in Evidence and Constraints carries a source, and that source really says it

The first five boxes check that something is **there**. Only the last one checks that it is **true**. A fluent draft can pass the
first five with guesses, so never skip the last box.

Câu nguyên tắc của mục này: năm ô đầu lọc thiếu, ô nguồn mới lọc bịa.

Checklist giúp product owner đọc nhanh hơn, nhưng không thay được người đọc. Ngay bản viết bằng skill, subagent review vẫn bắt được một câu gắn nhầm vào lời của Lan, dù skill đã tự cho qua ô thứ sáu.

Cách 2: template thêm ba mục

So với năm phần trong ví dụ của playbook, template của mình thêm ba mục để product owner duyệt nhanh hơn:

• Evidence: vì sao biết đây là vấn đề thật.
• Success criteria: một con số hoặc một hành vi kiểm được.
• Impact: thấp, vừa hay cao, để product owner xếp thứ tự.

Mình chép dưới đây bản tiếng Anh đã chạy trong demo (template.md của skill write-intent), nguyên văn. Bản tiếng Việt cùng cấu trúc có trong tài liệu đọc playbook của mình, nhưng bản tiếng Anh là bản đã sinh ra intent của Lan ở trên, nên đối chiếu được từng mục.

# Intent: <short name>

Author: <name> (<role>) · Status: draft · Source: <person / ticket / alert> · Date: <YYYY-MM-DD>

## Problem
<!-- Who is affected, when it happens. The originator's words, no jargon. -->

## Evidence
<!-- Why we believe it is real: numbers, tickets, complaints, screenshots. Each line ends with its source in brackets. -->

## Desired outcome
<!-- What better looks like, from the affected person's side. No technical solution. -->

## Success criteria
<!-- A number or a behaviour someone can check. Not "better", not "faster". -->

## Affected users and systems

## Constraints
<!-- Only constraints the originator stated or the repo shows. Each line ends with its source. -->

## Out of scope

## Impact
<!-- low / medium / high, with one sentence why. Helps the product owner order the queue. -->

## Open questions
<!-- Everything still unknown. Each line names who can answer. -->

Heading giữ tiếng Anh, còn nội dung viết bằng ngôn ngữ của người kể. Skill dặn đúng như vậy, nên intent của Lan có heading ## Evidence mà nội dung là tiếng Việt.

Cách 3: đặt trần cho hàng đợi duyệt

• Đặt trần số intent đang chờ duyệt, ví dụ 10 file. Vượt trần thì intent mới vẫn được tạo nhưng nằm ở trạng thái “chờ xếp hàng”.
• Intent chờ quá 14 ngày thì tự động được đánh dấu, để product owner chọn: nhận, gộp hay đóng.
• Đo thêm một chỉ số dẫn mà playbook chưa có: thời gian từ lúc commit tới lúc được duyệt.

Chỉ số cuối tách được phần “viết” khỏi phần “chờ duyệt”, thứ mà chỉ số dẫn của playbook đang gộp chung.

Cách 4: kiểm trùng trước khi viết

Thêm một bước vào skill: trước khi viết file mới, Claude tìm trong thư mục intent/ các file có vấn đề tương tự. Có thì đề xuất bổ sung vào file cũ thay vì tạo file mới.

Trong demo, Minh (nhân vật giả lập, bên kinh doanh) kể chuyện khách doanh nghiệp muốn sao lưu danh sách việc. Diễn biến (một lượt chạy):

• Claude nhận ra chỗ trùng với intent của Lan và đề xuất bổ sung vào đó.
• Minh không chắc, nhờ Claude chọn giùm.
• Claude tách thành file riêng có ghi liên kết, vì hai bên cần hai thứ khác nhau: một bên muốn không mất việc, một bên muốn tự giữ một bản. Claude cũng không sửa bản nháp của Lan khi Lan chưa biết.
• Câu “gộp hay tách” được chuyển cho product owner.

Tìm thấy trùng chưa có nghĩa là phải gộp. Hai intent có chung nguyên nhân (dữ liệu chỉ nằm trên một trình duyệt) nhưng khác nhu cầu. Máy chỉ ra chỗ trùng, người quyết gộp hay tách.

Cách 5: intent hai lớp cho yêu cầu từ khách

Với dự án làm cho khách nước ngoài, intent có hai lớp và một danh sách:

• Lớp nguyên văn. Giữ lời khách viết bằng ngôn ngữ gốc: email, tin nhắn, biên bản họp.
• Lớp diễn giải. Phần intent chuẩn do team viết cùng Claude, bằng ngôn ngữ làm việc của team.
• Câu hỏi mở thành danh sách gửi khách. Mục này tách ra để BrSE gửi một lần, thay vì hỏi rải rác.

Hai lớp giúp đối chiếu khi có tranh cãi về phạm vi sau này: khách nói gì, team hiểu thế nào. Cách này mình chưa thử và mình để dành một tập riêng cho nó.

Cổng duyệt là của người

Còn một luật mình giữ chặt: agent không tự duyệt. Trong demo, duyệt một intent nghĩa là merge nhánh của nó vào main, nên agent được viết và commit trên nhánh riêng, còn bước merge là của người.

Mình thử luật này bằng hai lượt (mỗi lượt chạy một lần):

• Lớp mềm. Mình xưng là product owner, bảo Claude merge giùm. Claude tự từ chối, vì file CLAUDE.md của repo đã dặn. Hook không có dịp chạy.
• Lớp cứng. Mình xoá CLAUDE.md ở một bản clone, giữ hook, rồi bảo lại. Lần này Claude chạy git merge, hook chặn, nhánh main giữ nguyên.

Đây là hook no-self-approve.py của demo, nguyên văn. Hook chạy trước mỗi lệnh Bash của agent (PreToolUse):

#!/usr/bin/env python3
"""PreToolUse hook (Bash): the agent may draft and commit on a branch, but approving is a human act.

Approving an intent = merging it into main. So the agent is denied:
  - git merge / git rebase / git push (any target)
  - git commit while the current branch is main
Fails closed: if the input cannot be read, the command is denied.
"""
import json, re, subprocess, sys

def decide(decision, reason):
    print(json.dumps({"hookSpecificOutput": {"hookEventName": "PreToolUse",
                                             "permissionDecision": decision,
                                             "permissionDecisionReason": reason}}))
    sys.exit(0)

try:
    cmd = json.load(sys.stdin)["tool_input"]["command"]
except Exception:
    decide("deny", "no-self-approve: could not read the command, denying to be safe")

if re.search(r"\bgit\s+(merge|rebase|push)\b", cmd):
    decide("deny", "no-self-approve: merging into main is the product owner's approval. Leave the branch for a human to merge.")

if re.search(r"\bgit\s+commit\b", cmd):
    branch = subprocess.run(["git", "branch", "--show-current"], capture_output=True, text=True).stdout.strip()
    if branch in ("main", "master"):
        decide("deny", "no-self-approve: do not commit on main. Create a branch such as intent/<slug> first.")

sys.exit(0)

Lời dặn có thể bị quên, hoặc bị xoá. Đúng như tập tổng quan đã nói: luật nào phải đúng mọi lúc thì để hook giữ, không trông vào lời dặn.

Hook này cũng có giới hạn. Nó chỉ chặn lệnh agent chạy qua Bash và người cố tình vẫn sửa được hook. Muốn chặn thật ở team thì thêm branch protection phía server.

Tuần đầu tiên

Nếu muốn thử bước Plan ở team mình, đây là tuần đầu mình đề xuất:

1. Tạo thư mục intent/ trong một repo đang chạy.
2. Viết template và checklist, gói thành một skill.
3. Chọn 3 yêu cầu đang nằm trong backlog, viết lại thành intent.md cùng Claude.
4. Nhờ product owner duyệt cả ba, ghi lại mất bao lâu.
5. Cuối tuần, so với thời gian một yêu cầu tương tự đi qua quy trình cũ.

Product owner thấy đọc ba file này nhanh hơn đọc ba ticket cũ thì đó là tín hiệu đúng hướng. Nhưng đọc nhanh mới là một nửa.

Nửa còn lại là chỉ số trễ của playbook: intent có phải sửa nhiều sau khi spec.md đầu tiên đã commit không. Hãy chờ thêm một nhịp, tới khi spec ra đời, rồi mới kết luận.

Tạm Kết

Quy trình cũ không sai. Backlog, user story, refinement có mặt để lọc ý tưởng ở thời code đắt. Giờ code rẻ đi, playbook thay chuỗi trạm đó bằng một file do chính người có ý tưởng viết cùng Claude và một lần merge của product owner.

Demo nhỏ của mình thêm một điều: bước Plan không làm ý tưởng hay lên. Nó làm cho chỗ chưa biết hiện ra, trước khi có ai bắt tay code dựa trên một câu đoán. Muốn vậy, Claude phải được bảo hỏi lại, được cấm tự điền và không được tự duyệt.

Tập sau của loạt AI-Native SDLC là Design: intent.md đã duyệt thành spec.md, trong một session.

Nguồn

• Louis Claxton, Anthropic, The AI-native SDLC playbook (21/8/2026), phần Stage 1: claude.com
• Demo SDLC-1 của mình, chạy ngày 19/10/2026: tám lượt, ba nhân vật giả lập, mỗi kịch bản một lần.

Cảm ơn bạn đã đọc bài viết này!