TASK_SPEC có thể kiểm tra được

"Làm một công cụ tính xem mỗi người phải trả bao nhiêu tiền ở nhà hàng." Yêu cầu nghe có vẻ rõ ràng, cho đến khi bắt đầu tìm hiểu. Chia đều hay mỗi người trả tiền món mình gọi? Tiền boa đã nằm trong hóa đơn chưa? Nếu tổng tiền không chia đều cho mọi người thì hiển thị gì?

Ta sẽ cùng Claude Code lập đặc tả: bạn mô tả nhiệm vụ và chọn phương án, agent ghi lại vào tệp, còn bạn kiểm tra nội dung. Bắt đầu bằng một yêu cầu ngắn, rồi dần hoàn thiện TASK_SPEC để có thể bắt tay vào làm.

"Làm cho tử tế" không phải là một nhiệm vụ

Hãy hình dung bạn chỉ muốn chia hóa đơn thật nhanh, nhưng agent lại thêm tính năng đăng ký và lưu lịch sử nhà hàng. Để lưu hóa đơn, nó cần cả server. Bạn định mở một tệp trong trình duyệt, giờ lại phải tìm hiểu cách chạy và xóa những phần thừa. Mỗi bổ sung riêng lẻ đều có vẻ hữu ích, nhưng kết quả cuối cùng đã khác xa ý định ban đầu.

Khi làm việc với mã, điều chưa nói rõ có thể biến thành những thay đổi thực tế trong tệp. Chuỗi sự việc thường là:

Sơ đồ cho thấy một quyết định bị bỏ sót có thể kéo theo thêm việc. Agent có thể hỏi lại, nhưng tốt hơn là nhận ra điểm chưa rõ trước khi sửa mã. Ngay từ yêu cầu đầu tiên, bạn đã có thể xác định hướng đi và giới hạn:

Chưa rõ:
Làm một công cụ tính xem mỗi người phải trả bao nhiêu tiền ở nhà hàng.

Cụ thể hơn:
Cần một trang duy nhất: nhập tổng hóa đơn và số người,
hiển thị số tiền mỗi người phải trả. Chia đều.
Không làm tài khoản, lịch sử hóa đơn hay chia theo món.

Yêu cầu thứ hai chưa giải đáp hết mọi câu hỏi. Nhưng nó đã loại trừ một số sản phẩm khác nhau có thể được tạo ra từ yêu cầu đầu tiên. Tiếp theo, agent sẽ giúp tìm những chỗ còn thiếu và ghi lại các quyết định của bạn.

Một nhiệm vụ trong một tệp

TASK_SPEC là bản ghi các điều kiện của một nhiệm vụ: cần kết quả gì, công việc kết thúc ở đâu và bạn sẽ kiểm tra ra sao. Thường bản ghi này được lưu thành tệp Markdown TASK_SPEC.md cạnh dự án. Tên gọi này không gắn với định dạng hay lệnh đặc biệt nào. Bạn cũng có thể gửi điều kiện trong tin nhắn, nhưng tệp sẽ tiện đọc lại và cập nhật hơn.

Bạn không cần tự viết TASK_SPEC. Tiện hơn là cùng agent xây dựng rồi kiểm tra xem agent đã ghi lại các quyết định của bạn thế nào. Bạn có thể mô tả nhiệm vụ bằng lời bình thường, trả lời câu hỏi và yêu cầu chỉnh cách diễn đạt. Agent quản lý tệp, còn bạn kiểm tra ý nghĩa.

1. bạn mô tả kết quả mình muốn và thảo luận những điểm chưa rõ;
2. agent đề xuất các phương án, bạn chọn phương án phù hợp;
3. agent ghi quyết định vào TASK_SPEC và cho bạn xem phần mới thêm hoặc chỉnh sửa;
4. bạn đọc phần đó trong tệp: ý nghĩa có được giữ nguyên, có điều kiện thừa không, có mâu thuẫn với nội dung cũ không. Nếu có vấn đề, hãy yêu cầu sửa rồi kiểm tra lại.

Sau mỗi quyết định riêng lẻ, bạn chỉ cần kiểm tra các dòng liên quan và điều kiện gắn với chúng. Trước khi triển khai, hãy đọc lại toàn bộ tệp: từng dòng riêng có thể đúng, nhưng khi ghép lại thì đòi hỏi những điều không tương thích. Tin nhắn "tôi đã cập nhật đặc tả" chưa cho biết chính xác nội dung nào đã vào tài liệu.

TASK_SPEC khác CLAUDE.md ở mục đích sử dụng. "Mọi nhãn trong dự án đều bằng tiếng Việt" là quy tắc chung của dự án. "Trong nhiệm vụ này, ta thêm cách tính tiền boa" là điều kiện của công việc cụ thể. Điều đầu nên nằm trong CLAUDE.md, điều sau trong TASK_SPEC.

Độ dài tài liệu tùy thuộc vào nhiệm vụ. Nếu chỉ cần sửa lỗi chính tả trên một trang đã có, đặc tả như sau là đủ:

Sửa nhãn nút trên trang chia hóa đơn:
"Tinh" → "Tính". Không thay đổi gì khác.
Kiểm tra nhãn mới hiển thị và nút vẫn tính toán như trước.

Đây là TASK_SPEC ngắn, đôi khi được gọi là tiny spec. Hầu như không có gì cần thảo luận ở đây. Còn công cụ tính mới có thể hoạt động theo nhiều cách, nên hai dòng là chưa đủ. Hãy ghi lại những quyết định ảnh hưởng đến kết quả; riêng số lượng tiêu đề không đảm bảo điều gì cả.

Bắt đầu từ kết quả

Hãy hình dung dự án chưa tồn tại. Một nhóm bạn muốn mở một trang trong trình duyệt, nhập tổng hóa đơn và biết mỗi người phải trả bao nhiêu. Ta sẽ giao agent tạo bản nháp:

Tạo TASK_SPEC.md cho trang chia hóa đơn.
Dự án chưa có. Nhập tổng hóa đơn và số người,
nhấn "Tính" thì thấy phần tiền mỗi người.
Kết quả cần là index.html, mở được trong trình duyệt mà không cần cài đặt.
Ghi lại các điều kiện đã thống nhất, đánh dấu điều chưa rõ bằng câu hỏi.
Hiển thị nội dung đã ghi. Chưa viết mã của trang.

Đây là ví dụ minh họa phần đầu tiên của tệp:

## NGỮ CẢNH
Một nhóm bạn ở nhà hàng muốn nhanh chóng chia hóa đơn chung.
Dự án chưa có, thư mục làm việc đang trống.

## HÀNH VI MONG MUỐN
Người dùng nhập tổng hóa đơn và số người.
Sau khi nhấn "Tính", thấy số tiền mỗi người phải trả.
Kết quả công việc: trang index.html,
có thể mở trong trình duyệt mà không cần cài đặt.

Mở TASK_SPEC.md trong trình soạn thảo và đối chiếu nội dung với yêu cầu: có đủ hai trường nhập, thao tác và kết quả cho mỗi người. Nếu agent thêm phần nhập tên hoặc bắt buộc đăng ký, đó là những điều kiện chưa được thống nhất. Hãy yêu cầu xóa chúng khỏi tệp rồi kiểm tra lại.

Giờ ta đã biết ai sẽ dùng trang và họ nhận được gì. Ta cũng đã gọi tên artifact, tức kết quả cụ thể trong công việc của agent: tệp trang web. Với nhiệm vụ khác, đó có thể là phân tích lỗi hoặc kế hoạch thay đổi không kèm mã. Hãy nói rõ điều này.

Để ý rằng ta chưa chọn hàm JavaScript hay chỉ định cách lưu danh sách người tham gia. Đó là các quyết định triển khai. Trong đặc tả, điều quan trọng hơn là ghi lại những gì người dùng sẽ thấy: dữ liệu nhập, thao tác và kết quả.

Giới hạn phạm vi nhiệm vụ

Giờ ta sẽ xác định phiên bản đầu tiên dừng ở đâu. Hãy yêu cầu agent ghi lại các giới hạn đã thống nhất và hiển thị phần vừa cập nhật:

## SCOPE
Một trang: nhập tổng tiền và số người,
chia đều tổng hóa đơn, hiển thị phần tiền mỗi người.

## NON-GOALS
Không có tài khoản hay lịch sử hóa đơn: không cần lưu dữ liệu.
Không chia theo món: phiên bản đầu chia đều.
Giới hạn triển khai: một tệp HTML chứa style và script,
không server hay thư viện bên ngoài.
Trang phải mở được bằng cách nhấp đúp.

Ở đây, ta không chỉ kiểm tra xem các điều bị loại trừ có được ghi ra hay không. Chia đều phải nằm trong phạm vi nhiệm vụ, còn chia theo món thì ở ngoài. Nếu agent ghi ngược, hãy sửa tài liệu trước khi bắt đầu làm trang.

Scope mô tả khối lượng công việc. Có thể xác định qua màn hình và kịch bản như ví dụ này. Đường dẫn cụ thể sẽ hữu ích khi đã biết, nhưng không nhất thiết phải bắt đầu bằng danh sách tệp. Nếu bạn đang sửa một dự án có sẵn mà chưa biết trang cần tìm nằm ở đâu, hãy yêu cầu Claude Code tìm nó trước, không chỉnh sửa, rồi giải thích vì sao chọn tệp đó. Sau đó thêm đường dẫn vào đặc tả. Điều chưa biết thì cứ để đó, đừng tự nghĩ ra.

Non-goals là những điều ta chủ động loại trừ. "Không có lịch sử hóa đơn" xác định giới hạn rõ hơn câu "đừng thêm gì thừa". Một lý do ngắn cũng hữu ích cho bạn: một tuần sau vẫn thấy rằng việc lưu dữ liệu đã được cân nhắc rồi quyết định không làm.

Giới hạn triển khai trả lời một câu hỏi khác: cách làm nào phù hợp với ta. Tài khoản là tính năng thừa, còn server là cách xây dựng giải pháp mà ta loại trừ ở đây. Trong tài liệu ngắn, có thể đặt các điều kiện này chung một mục, miễn là đánh dấu rõ đó là giới hạn.

Giới hạn phải cho phép tạo ra kết quả mong muốn. Nếu sau này cần tài khoản dùng chung và lịch sử trên nhiều thiết bị, ta phải xem lại yêu cầu "một tệp HTML chạy cục bộ". Không thể vừa đòi tính năng mới vừa giữ giới hạn khiến tính năng đó không thể thực hiện được.

Đồng xu bị bỏ quên

Mọi thứ có vẻ đã đủ rõ ràng. Hãy kiểm tra đặc tả trước khi viết mã: nhóm ba người, hóa đơn là 1000. Mỗi người sẽ thấy số tiền bao nhiêu?

333,33 + 333,33 + 333,33 = 999,99

Còn thiếu một xu. Ta có thể cộng xu đó cho người đầu tiên, người cuối cùng hoặc để mọi người chọn. Câu "chia đều" chưa giải quyết được việc này. Đây là câu hỏi bạn cần tự quyết định, không liên quan đến kiến thức JavaScript.

Với trang của mình, ta sẽ chọn cách này: phần tiền mỗi người chênh nhau không quá một xu; số xu còn lại được chia lần lượt, mỗi người đầu danh sách nhận một xu. Khi chia 1000 cho ba người, kết quả là 333,34; 333,33; 333,33. Còn với 1000,01 thì có hai xu dư: 333,34; 333,34; 333,33. Toàn bộ số tiền được chia hết, tổng các phần khớp với hóa đơn.

Giờ hãy yêu cầu agent ghi quyết định đã chọn vào tài liệu:

Ghi quy tắc làm tròn vào phần hành vi mong muốn của TASK_SPEC.md.
Hiển thị các dòng đã thay đổi. Chưa sửa mã.

Kiểm tra xem tệp đã có nội dung như sau chưa:

Tổng các phần tiền phải bằng đúng tổng hóa đơn.
Chênh lệch giữa các phần không quá 0,01.
Số xu dư được chia cho những người đầu danh sách, mỗi người một xu;
trang có giải thích quy tắc này.

Hãy đọc thật kỹ cụm "cho những người đầu danh sách, mỗi người một xu". Nếu agent ghi "toàn bộ số dư cộng cho người đầu tiên", nó đã thay đổi quyết định: khi còn hai xu, người đầu sẽ trả nhiều hơn những người khác 0,02. Yêu cầu sửa dòng đó rồi kiểm tra tệp lần nữa. Cần đúng ý, không nhất thiết phải trùng từng chữ.

Đó là lý do nên thử đưa số cụ thể vào đặc tả. Ta tìm ra quyết định còn thiếu trước khi agent tự chọn phương án rồi viết mã theo nó. Mới chỉ cần sửa vài dòng thôi.

Để Claude đặt câu hỏi

Bạn có thể chưa nhận ra hết những chỗ còn thiếu. Hãy gửi bản nháp cho agent và nhờ nó tập trung làm rõ đặc tả:

Đọc @TASK_SPEC.md. Giúp tôi tìm những điều kiện còn thiếu.
Mỗi lần chỉ hỏi một câu, đồng thời đề xuất một câu trả lời.
Đừng xem phương án của bạn là đã thống nhất cho đến khi tôi trả lời.
Sau mỗi quyết định được thống nhất, cập nhật TASK_SPEC.md
và hiển thị phần đã thay đổi để tôi kiểm tra.
Chưa viết mã.

Dưới đây là ví dụ về cuộc trao đổi như vậy. Trong phiên làm việc của bạn, câu hỏi có thể khác; điều cần theo dõi ở đây là câu trả lời làm thay đổi tài liệu ra sao.

Claude: "Tiền boa đã nằm trong hóa đơn hay được cộng riêng? Tôi đề xuất một trường riêng để nhập phần trăm, mặc định là 0."
Bạn: "Tính riêng. Tính phần trăm trên hóa đơn, cộng tiền boa vào rồi chia tổng. Hiển thị số tiền boa và tổng tiền trên trang."

Claude: "Nếu tiền boa có phần lẻ của một xu thì làm tròn thế nào? Tôi đề xuất làm tròn đến xu gần nhất, đúng nửa xu thì làm tròn lên."
Bạn: "Được. Làm tròn tiền boa trước, sau đó cộng vào hóa đơn. Rồi chia tổng theo quy tắc của ta."

Claude: "Chấp nhận giá trị nào? Tôi đề xuất số tiền dương dùng dấu chấm hoặc dấu phẩy, số người là số nguyên từ 1 trở lên và phần trăm là số nguyên không âm. Nếu có lỗi thì hiện gợi ý cạnh trường nhập."
Bạn: "Được. Số tiền có tối đa hai chữ số sau dấu phân cách, không có khoảng trắng giữa hàng nghìn. Nếu trường nhập trống hoặc giá trị không hợp lệ thì ẩn kết quả, kể cả khi đã tính trước đó."

Ta đã làm rõ không chỉ tiền boa. Giờ đã xác định dữ liệu đầu vào hợp lệ, thứ tự làm tròn và cách xử lý lỗi. Sau khi ghi lại câu trả lời, hãy đối chiếu phần vừa cập nhật trong tệp:

Tiền boa: một trường riêng để nhập phần trăm nguyên từ 0, mặc định là 0.
Tính tiền boa dựa trên hóa đơn và làm tròn đến xu gần nhất;
đúng nửa xu thì làm tròn lên.
Cộng tiền boa đã làm tròn vào hóa đơn, rồi chia tổng.
Hiển thị tiền boa, tổng tiền và phần của mỗi người.
Nếu giá trị trống hoặc không hợp lệ thì ẩn kết quả,
hiện gợi ý cạnh trường nhập tương ứng.

Kiểm tra thứ tự: trước tiên làm tròn tiền boa, sau đó cộng vào hóa đơn rồi mới chia tổng. Cùng những từ đó nhưng đổi thứ tự sẽ tạo ra yêu cầu khác. Hãy yêu cầu agent cập nhật cả scope: phiên bản đầu đã có thêm trường tiền boa và cách tính tổng. Kiểm tra xem nó đã sửa cả hai mục hay chỉ xác nhận trong chat.

Kết quả và cách kiểm tra

"Tổng các phần tiền bằng tổng hóa đơn" là yêu cầu về kết quả. "Nhập 1000, ba người và tiền boa 0%; nhấn nút; thấy các khoản 333,34, 333,33 và 333,33" là một bước kiểm tra. Nó xác định thao tác và kết quả cần quan sát.

Hãy yêu cầu agent thêm một vài bước kiểm tra như vậy vào tệp ngay bây giờ, trước khi triển khai. Ta sẽ tự đối chiếu các con số mong đợi. Nếu không, rất dễ chấp nhận kết quả vừa làm xong rồi vô thức điều chỉnh kỳ vọng cho khớp với trang.

Dòng 10,05 kiểm tra thứ tự thao tác: 10% là 1,005, làm tròn thành 1,01. Nếu làm tròn ở bước khác, tổng có thể khác. Để kiểm tra định dạng, hãy lặp lại với dấu chấm: nhập 10.05 cũng phải cho cùng kết quả. Ngoài ra, hãy thử số tiền âm, số người dạng thập phân, phần trăm âm hoặc thập phân, và để trống trường tiền boa: không trường hợp nào được tính.

Mỗi điều kiện quan trọng đều cần một kết quả có thể quan sát. "Trang đã mở" chưa chứng minh các khoản tiền được tính đúng, cũng như một địa chỉ liên kết đúng chưa chứng minh trang cần thiết đã tải. Hãy kiểm tra đúng hành vi khiến bạn giao nhiệm vụ.

Cùng xây dựng TASK_SPEC

Agent đã ghi các quyết định vào tệp trong lúc thảo luận. Giờ hãy đọc lại từ đầu đến cuối: câu trả lời đã được ghi đủ chưa, các bước kiểm tra có khớp với yêu cầu không, còn sót điều kiện cũ nào không. Đây là tài liệu cuối cùng trong ví dụ. Nó có sáu mục chính: ngữ cảnh, hành vi mong muốn, scope, non-goals, kế hoạch kiểm tra và bước bắt đầu an toàn. Tên mục giúp tìm nhanh, còn nội dung đã hình thành từ việc phân tích nhiệm vụ.

# TASK_SPEC.md

## NGỮ CẢNH
Một nhóm bạn muốn chia hóa đơn nhà hàng.
Dự án mới chưa có; thư mục làm việc trống, ngoại trừ TASK_SPEC.md.

## HÀNH VI MONG MUỐN
Kết quả công việc: index.html có thể mở bằng cách nhấp đúp,
và một mô tả ngắn về cách kiểm tra.
Trang có ba trường nhập và nút "Tính":
- số tiền hóa đơn lớn hơn 0, tối đa hai chữ số thập phân;
  dấu phân cách là dấu chấm hoặc dấu phẩy, không phân cách hàng nghìn;
- số người là số nguyên từ 1 trở lên;
- phần trăm tiền boa là số nguyên từ 0 trở lên, mặc định là 0.
Tiền boa tính theo hóa đơn, làm tròn đến xu gần nhất;
đúng nửa xu thì làm tròn lên.
Cộng tiền boa đã làm tròn vào hóa đơn, rồi chia tổng.
Hiển thị tiền boa, tổng tiền và phần có đánh số của mỗi người.
Tổng các phần bằng tổng tiền, chênh lệch không quá 0,01.
Số dư được chia cho những người đầu danh sách, mỗi người một xu;
trang có giải thích quy tắc này.
Nếu giá trị trống hoặc không hợp lệ thì ẩn kết quả,
hiện gợi ý cạnh trường nhập sai.

## SCOPE
Một trang: ba trường nhập, tính toán, gợi ý và hiển thị số tiền.
Chia đều tổng tiền theo quy tắc phân bổ số dư đã mô tả.

## NON-GOALS
Không cần tài khoản hay lịch sử hóa đơn: không lưu dữ liệu.
Không chia theo món: đó là phiên bản khác của công cụ tính.
Giới hạn: style và script nằm trong index.html,
không server hay thư viện bên ngoài, để mở tệp cục bộ.

## KẾ HOẠCH KIỂM TRA
Mở index.html bằng cách nhấp đúp. Nhấn "Tính":
- 1000 / 3 người / 0% → 333,34; 333,33; 333,33;
- 1000,01 / 3 / 0% → 333,34; 333,34; 333,33;
- 1000 / 3 / 10% → tiền boa 100,00, tổng 1100,00,
  các phần 366,67; 366,67; 366,66;
- 10,05 / 3 / 10% → tiền boa 1,01, tổng 11,06,
  các phần 3,69; 3,69; 3,68; nhập 10.05 cũng cho kết quả đó;
- 1000 / 1 / 0% → một phần tiền là 1000,00.
Trong mỗi trường hợp, cộng các phần và so với tổng hóa đơn.
Kiểm tra số 0 và số thập phân ở số người, số tiền âm,
phần trăm âm và dạng thập phân, số tiền có hơn hai chữ số
thập phân, lần lượt để trống từng trường:
hiện gợi ý cạnh trường, ẩn kết quả, kể cả sau khi đã tính.
Kiểm tra đánh số phần tiền và giải thích cách chia xu.

## BẮT ĐẦU AN TOÀN
Đọc đặc tả và xem nội dung thư mục làm việc.
Nếu đã có tệp của dự án, dừng lại và hỏi rõ nhiệm vụ;
không ghi đè hay xóa tệp đang có.
Trước tiên đặt câu hỏi và đưa ra kế hoạch không kèm mã, sau đó chờ duyệt.
Nếu triển khai cần thay đổi ngoài scope,
hãy làm rõ đặc tả trước khi thay đổi.

Tài liệu dài thêm nhờ những quyết định thực sự cần thiết. Nó không hướng dẫn từng bước viết JavaScript, nhưng chỉ rõ cách xử lý tiền boa và kiểm tra số xu. Nhiệm vụ của bạn có thể cần ít chi tiết hơn.

Khi viết đặc tả của mình, bạn có thể dùng bảng nhắc ngắn này:

Nếu điều kiện thay đổi

Giờ là một câu hỏi ngắn dành cho bạn. Người dùng đọc đặc tả rồi nói: "Nhập phần trăm không tiện. Tôi muốn nhập tiền boa bằng một số tiền cụ thể, chẳng hạn 100". Những phần nào trong TASK_SPEC cần cập nhật? Hãy thử kể tên trước khi đọc phần phân tích.

Trong hành vi mong muốn, trường phần trăm được thay bằng số tiền boa: giá trị không âm, dùng dấu chấm hoặc dấu phẩy và tối đa hai chữ số thập phân. Giá trị mặc định vẫn là 0. Xóa công thức phần trăm và quy tắc làm tròn tiền boa được tính ra: số tiền nhập vào chỉ cần cộng vào hóa đơn. Trong scope, cách tính thay đổi; trong kế hoạch kiểm tra, dữ liệu đầu vào và các trường hợp nhập sai cũng thay đổi. Cách chia tổng tiền và non-goals vẫn như cũ.

Bước kiểm tra "hóa đơn 1000, tiền boa 100, ba người" sẽ cho kết quả quen thuộc: 366,67; 366,67; 366,66. Nhưng chỉ nhìn các con số này thì không phân biệt được phiên bản mới với phiên bản cũ dùng tiền boa 10%. Hãy thêm một hóa đơn khác: 500 cộng 100 tiền boa cố định, chia cho hai người. Mỗi người phải trả 300; cách tính cũ với 10% sẽ cho 275. Đây là bước kiểm tra giúp nhận ra quy tắc đã thay đổi.

Yêu cầu agent cập nhật hành vi mong muốn, scope và các bước kiểm tra, sau đó hiển thị mọi phần đã sửa. Mở tệp để xác nhận công thức phần trăm cũ đã bị xóa và các bước kiểm tra mới tương ứng với việc nhập số tiền. Đừng giữ cả công thức cũ lẫn ghi chú mới "giờ nhập số tiền": đặc tả phải chỉ đưa ra một cách hiểu. Ví dụ chính ở trên vẫn dùng phương án phần trăm ban đầu; ở đây ta chỉ phân tích một thay đổi riêng.

Cách làm việc cùng Claude Code

Sau khi kiểm tra các thay đổi riêng lẻ, hãy đọc lại toàn bộ TASK_SPEC trước khi bắt đầu triển khai. Đảm bảo mục tiêu, giới hạn và các bước kiểm tra cùng mô tả một nhiệm vụ. Sau đó, hãy chỉ rõ tệp cho agent:

Đọc @TASK_SPEC.md. Trước tiên kiểm tra xem có mâu thuẫn nào
hoặc điều kiện nào cần làm rõ thêm không.
Hiển thị kế hoạch ngắn và danh sách tệp bạn sẽ tạo hoặc sửa.
Chưa sửa mã cho đến khi kế hoạch được duyệt.

Giờ bạn đã có những điều cần kiểm tra ngay cả trước khi triển khai. Nếu kế hoạch có thêm server để lưu hóa đơn, hãy yêu cầu sửa lại: lịch sử đã bị loại trừ và trang phải mở cục bộ. Nếu kế hoạch phù hợp, hãy cho phép triển khai. Sau đó mở tệp nhận được và thực hiện các kịch bản đã ghi, bao gồm cả trường hợp nhập sai sau khi tính thành công.

Non-goals vẫn chỉ là điều kiện bằng văn bản, chúng không tự động ngăn thay đổi về mặt kỹ thuật. Vì vậy, cần xem cả kế hoạch lẫn kết quả. Tin nhắn "xong rồi" của agent giúp bạn biết nó đã làm gì, nhưng không thay thế các con số cần đối chiếu.

Nếu sau khi hoàn thành bạn giữ TASK_SPEC trong dự án, hãy đánh dấu nhiệm vụ là đã đóng. Còn khi công việc vẫn đang diễn ra, hãy giữ các quyết định trong tệp luôn cập nhật. Giao cho agent việc diễn đạt và ghi lại; tự kiểm tra quyết định qua chính tài liệu: phần đã sửa sau thảo luận và toàn bộ tệp trước khi triển khai.