unlazy skill và phương pháp Depth Tree cho agent

Chức năng của skill unlazy

Skill unlazy được xây dựng để ngăn một lỗi: coding agent báo đã hoàn tất trước khi công việc thực sự hoàn tất. Thành phần cốt lõi là Depth Tree, một phương pháp chia task thành các lớp và chỉ coi lớp thấp nhất là công việc thực tế. Version 2 chuyển cơ chế thực thi từ prose vào các file, vì vậy agent phải chứng minh đã hoàn tất bằng danh sách các lệnh có thể chạy, thay vì chỉ khẳng định.

Skill này do Leonxlnx phát hành tại github.com/Leonxlnx/unlazy theo MIT license. Hướng dẫn này áp dụng cho version 2.0.0, phát hành ngày 2026-08-10. Các skill trong lĩnh vực này thay đổi nhanh, vì vậy hãy đọc CHANGELOG của repo trước khi sao chép nội dung này vào một setup mà bạn để chạy lâu dài.

Trong ngữ cảnh này, skill có nghĩa như thông thường: một file SKILL.md được harness nạp vào context của model khi task khớp với mô tả của file. Nếu cơ chế này còn mới với bạn, hãy bắt đầu bằng skill của agent là gì và harness nạp skill như thế nào. unlazy chỉ gồm markdown thuần và một vài Node script, nên không cần server hoặc API key riêng.

Vì sao agent dừng ở 80% và bỏ qua yêu cầu thứ ba của bạn

Hành vi này có một mẫu hình dễ nhận ra. Bạn yêu cầu bốn việc. Câu trả lời bao quát việc thứ nhất, thứ hai và thứ tư. Phần tóm tắt cuối liệt kê cả bốn việc là đã hoàn tất. Không có lỗi nào được phát sinh nên không có cảnh báo nào, và một tuần sau bạn mới phát hiện phần bị thiếu.

README của unlazy đặt vấn đề này trong bối cảnh các nghiên cứu đã công bố về sự lười của model, với trích dẫn “cắt ngắn câu trả lời quá sớm và tuân thủ không đầy đủ các yêu cầu gồm nhiều phần” (citation là arXiv 2512.20662). README cũng nêu rõ tiền đề thiết kế: prose không thể thực thi prose. Bảo agent cố gắng hơn chỉ tạo thêm prose, được đưa vào chính context đã tạo ra phần thiếu đó.

Đó là lý do version 2 lưu state trong các file. Checkbox trong GATES.md nằm ngoài quyền quyết định của model. Hoặc checkbox có một dòng bằng chứng bên dưới, hoặc không có; script có thể cho bạn biết trạng thái đó mà không cần hỏi agent.

Cây độ sâu, từng lớp một

Cây độ sâu là cách phân rã công việc kèm quy tắc về nơi được phép thực hiện công việc. Tài liệu tham chiếu của phương pháp này nêu rõ:

Tách tại các điểm nối tự nhiên, dùng nhị phân khi các điểm nối tự nhiên cho phép, với độ sâu N lớp.

Chỉ các lá mới là nơi thực hiện công việc thực tế; mọi lớp phía trên chỉ dùng để phân rã và tích hợp.

Một lá lớn hơn một bullet point. Tài liệu tham chiếu quy định kích thước tối thiểu:

Một lá là một đơn vị công việc thực tế. Cần ít nhất mười phút tập trung, một sản phẩm bàn giao thống nhất và một file gates.

Mức tối thiểu này ngăn cây sâu biến thành công việc hình thức. Nếu một lá ghi là "đổi tên biến", nó không đạt yêu cầu, và phép tách ngay phía trên đã đi sâu hơn một lớp so với cần thiết.

Sau đó, mỗi lá trải qua bốn lượt: triển khai hoàn chỉnh, không để placeholder; đọc lại như một chuyên gia trong lĩnh vực; tìm lỗi; rồi polish những phần có thể polish mà không tốn thêm công sức đáng kể. Đây cũng là lý do lá cần đạt kích thước tối thiểu. Thực hiện bốn lượt trên một thay đổi mất hai phút chỉ là hình thức.

Bạn chọn độ sâu khi invoke skill:

/unlazy tree 5 refactor the payment module

Bạn cũng có thể dùng ngôn ngữ tự nhiên, vì phần mô tả của skill khớp theo intent thay vì theo slash command:

tree 3 build the landing page and do not stop until every gate is checked

Tài liệu tham chiếu đưa ra các khoảng độ sâu. tree 2 hoặc 3 phù hợp với một feature, một đợt tìm lỗi hoặc một tài liệu, được thực hiện một mình trong một session với 2 đến 4 lá. tree 4 hoặc 5 phù hợp với một subsystem, một đợt refactor hoặc một lần review nghiêm túc, trong đó 8 đến 16 lá là "nhiều hơn mức một context có thể xử lý tốt". tree 6 hoặc 7 phù hợp với toàn bộ một project, chạy ở orchestrated mode với các lá được ánh xạ vào những work unit không chồng lấn.

Khi không chỉ định độ sâu, skill được yêu cầu "chọn N nhỏ nhất sao cho các lá khớp với những phần tự nhiên của task", đồng thời được yêu cầu rõ ràng là mặc định không đi sâu thêm một lớp. Độ sâu mô tả công việc, vì vậy tăng con số này không làm chất lượng tăng lên.

Cấu trúc của một gates file

Trước khi bắt đầu công việc, agent ghi các tiêu chí nghiệm thu vào một gates file. Mỗi gate là một checkbox, bên dưới có một command.

# Gates: pricing section

- [ ] G1: three tiers render with real copy
  CHECK: node check.js pricing --tiers
  EXPECT: 3/3 tiers ok
  EVIDENCE: pending

- [ ] G2: annual toggle changes both price and label
  CHECK: node check.js pricing --toggle
  EXPECT: toggle ok
  EVIDENCE: pending

CHECK là command. EXPECT là output được tính là đạt. EVIDENCE bắt đầu bằng pending và phải được thay thế bằng nội dung command thực sự in ra. Skill cung cấp scripts/gate-check.mjs để quét các file này và báo những gate vẫn còn mở. Nhờ đó, bạn có thể audit một lần chạy mà không cần đọc transcript.

Triết lý này được tóm tắt trong một dòng, và SKILL.md cũng ghi đúng một dòng:

Một báo cáo là tập hợp các nhận định có ledger chứng minh, không phải cảm giác rằng công việc đã hoàn tất.

Quy tắc tiếp theo là "không có báo cáo khi ledger chưa đầy đủ". Quy tắc báo cáo cũng yêu cầu mọi con số trong bản tóm tắt cuối phải được đo lại tại thời điểm báo cáo hoặc được đánh dấu là chưa xác minh. Một gate không thể đóng chỉ vì agent cảm thấy đã xong. Đóng gate nghĩa là dán output khớp hoặc không khớp với EXPECT.

Hãy viết các gate để một người không quen hệ thống cũng có thể chạy. "Có vẻ ổn" không phải là một phép kiểm tra. test -s dist/index.html && echo ok in ra ok là một phép kiểm tra, vì nó sẽ báo lỗi rõ ràng khi file trống hoặc không tồn tại.

Hợp đồng trong PLAN.md trước khi làm việc song song

Khi cây công việc đủ rộng để các leaf chạy trong những context riêng, các leaf không còn dùng chung các giả định. Tài liệu tham chiếu yêu cầu đặt một hợp đồng trước khi fan-out:

Hợp đồng trước fan-out. Interface, quyền sở hữu dữ liệu, quy ước đặt tên và quy ước lỗi phải được ghi vào PLAN.md trước khi bất kỳ leaf nào bắt đầu.

Lý do rất cụ thể. Hai subagent cùng được yêu cầu “thêm xử lý lỗi” sẽ tự tạo ra hai dạng lỗi khác nhau, và cả hai leaf đều vượt qua gate của mình vì mỗi leaf đều đúng trong phạm vi cục bộ. Lỗi chỉ xuất hiện khi chúng kết hợp với nhau. Branch gate tồn tại để xử lý thời điểm đó: gate của một branch chứng minh rằng “các child đã được merge, interface khớp nhau, hành vi end-to-end hoạt động và không có regression giữa các sibling”.

Trong chế độ orchestrated, driver gửi cho mỗi subagent phần contract trong PLAN.md, không gửi toàn bộ file và cũng không gửi history riêng của driver, cùng với file gates của leaf đó ở dạng nguyên văn. Khi subagent trả kết quả, driver tự chạy lại các check. Nếu subagent “tự đánh dấu các mục đã kiểm tra nhưng không có bằng chứng”, driver sẽ gửi subagent quay lại và nêu rõ các gate chưa đạt.

Orchestration có giới hạn tối thiểu. Nếu thời gian làm việc thực tế dưới khoảng nửa giờ, tài liệu tham chiếu khuyến nghị tiếp tục làm solo, vì mỗi subagent phải tự xây dựng lại hiểu biết về task từ đầu và chi phí setup đó lớn hơn lợi ích từ sự tập trung mới.

Cài skill unlazy như thế nào?

Cách được hỗ trợ là dùng skills CLI:

npx skills add Leonxlnx/unlazy

Cài thủ công bằng cách clone vào thư mục skills của agent:

git clone https://github.com/Leonxlnx/unlazy ~/.claude/skills/unlazy

git clone https://github.com/Leonxlnx/unlazy ~/.codex/skills/unlazy

Sau đó kiểm tra file đã được đặt đúng chỗ:

ls ~/.claude/skills/unlazy/SKILL.md

Đường dẫn được in ra cho biết file đã có trên disk. No such file or directory nghĩa là lệnh clone đã ghi vào nơi khác, thường do thư mục skills không tồn tại với tên bạn giả định và git đã tạo một thư mục mới. Bạn cũng không nên chỉ tin lời agent. Prompt cài đặt trong README cũng kết thúc bằng cùng cảnh báo: "Không được nói là đã cài đặt nếu bạn chưa thực sự xác minh file đã có trên disk."

Với harness không có skill loader, hãy dán nội dung của SKILL.md vào system prompt hoặc file rules. Đây là fallback được tài liệu hóa. Vì vậy, phương pháp này chạy được trên Claude Code, Codex, Cursor và mọi công cụ khác đọc file hướng dẫn markdown thuần. Nếu muốn biết điều gì giúp SKILL.md được load ổn định ngay từ đầu, viết skill agent của riêng bạn trình bày frontmatter và việc đối sánh description, vốn quyết định skill có được kích hoạt hay không.

Stop hook có hoạt động bên ngoài Claude Code không?

Không. Đây là điểm cần nói chính xác. Toàn bộ phần trên là instruction, và instruction có thể bị bỏ qua. Cơ chế enforcement mang tính cấu trúc duy nhất là Stop hook, còn Stop hook là một tính năng của Claude Code.

node <path-to-skill>/scripts/install-hooks.mjs            # this project only (settings.local.json)
node <path-to-skill>/scripts/install-hooks.mjs --global   # every project
node <path-to-skill>/scripts/install-hooks.mjs --uninstall

Stop hook chạy ngay khi agent cố gắng kết thúc lượt của mình. Hook này quét các file gates và chặn việc dừng khi vẫn còn gate chưa đạt, nhờ đó lượt chạy không thể kết thúc khi còn ô chưa được kiểm tra. Nó chỉ đọc file và không gọi model, nên README nói rằng nó tốn zero token. Để xem cơ chế tổng quát và các event khác mà bạn có thể gắn vào, xem cách hook của Claude Code chạy trong một lượt.

Hook có một cơ chế cho phép thoát, và cơ chế này quan trọng hơn bạn tưởng. Nếu agent không đạt thêm gate nào trong sáu lần bị chặn liên tiếp, hook sẽ cho phép agent kết thúc kèm cảnh báo thay vì giữ nó trong vòng lặp. Dòng ABANDON: <gate> <reason> luôn được tôn trọng như một cách thoát hợp lệ. Nếu không có hai lối thoát này, một gate không thể đáp ứng trong môi trường của bạn sẽ tiếp tục đốt token cho đến khi bạn tự dừng session.

Trên Codex, Cursor hoặc bất kỳ harness nào khác, install-hooks.mjs không có chỗ để cài vào. Bạn vẫn có file gates và các check có thể chạy, nhưng không có cơ chế cấu trúc nào ngăn model kết thúc lượt sớm. Khi đó, file gates là tài liệu mà bạn phải tự đọc.

unlazy hay ponytail: bạn muốn dùng cái nào?

Hai skill này thịnh hành trong cùng một giai đoạn và kéo quy mô theo hai hướng ngược nhau, nên rất dễ nhầm.

ponytail khiến agent hành xử như một senior developer luôn hỏi đầu tiên liệu đoạn code đó có thực sự cần tồn tại hay không. Nó thu hẹp scope, ưu tiên standard library và giảm diff. unlazy giả định scope đã được thống nhất, rồi đẩy mức độ hoàn thiện lên cho đến khi mọi phần trong scope đều hoàn tất và được kiểm chứng.

Vì vậy, hãy chọn theo lỗi bạn thực sự đang gặp. Nếu agent biến một tính năng nhỏ thành cả một framework, bạn cần skill ponytail và persona senior developer lười biếng của nó. Nếu agent bỏ dở mục thứ ba trong một yêu cầu gồm 4 phần rồi vẫn báo thành công, bạn cần unlazy.

Có thể chạy cả hai, nhưng thứ tự rất quan trọng. Trước tiên, hãy chốt scope bằng câu hỏi của ponytail, sau đó đưa scope đã thống nhất qua các gate của unlazy. Nếu làm ngược lại, bạn sẽ xây cả một cây gồm các lá cho những phần việc mà ponytail lẽ ra đã xóa bỏ, rồi phải trả depth multiplier cho toàn bộ cây đó. Đây là thứ tự tôi khuyến nghị, không phải một cơ chế tích hợp được hai project dokument.

Chi phí của depth trên agent chạy trên VPS là bao nhiêu?

Depth là hệ số nhân công sức, còn công sức được tính bằng token. Khi agent chạy trên VPS và sử dụng API key của bạn, hệ số đó trở thành chi phí.

[
  {
    "label": "Skill run vs no skill, output tokens",
    "low_multiplier": 1.6,
    "high_multiplier": 3.9
  },
  {
    "label": "tree 6 vs tree 3, total cost",
    "low_multiplier": 1.0,
    "high_multiplier": 1.5
  }
]

Đây là số liệu do tác giả thu thập trong bài test của họ vào ngày 2026-08-10. Chúng tôi chưa tái hiện bài test, vì vậy hãy xem đây là xu hướng tương đối, không phải dự báo. Kỷ luật solo nâng output lên khoảng 1.6 đến 3.9 lần baseline, trong khi tăng tree từ 3 lên 6 trong cùng một context chỉ thêm 1.0 đến 1.5 lần, thấp hơn nhiều so với mức tám lần mà bạn có thể dự đoán từ ba lần binary split bổ sung.

Depth lớn hơn không làm chi phí tăng theo cùng tỷ lệ, vì depth phân bổ lại effort thay vì thêm context. Tài liệu tham chiếu về token economy nói rõ hệ số nhân chi phí thực sự nằm ở đâu: "Thứ nhân chi phí là orchestration, và nó nên nhân chi phí, vì mỗi leaf tạo ra một context mới." Chế độ solo nhân số output token trong một context. Chế độ orchestrated nhân số context, và mỗi context mới phải đọc lại contract cùng file gates trước khi làm được việc hữu ích.

Có một chi phí thứ hai dễ bị bỏ qua, và tài liệu tham chiếu đó cũng nêu rõ. Trong bài test của họ, một lần chạy deep dạng monolithic "đã tiêu thụ khoảng 58 million cached input tokens" vì một context liên tục tăng phải chứa toàn bộ dữ liệu. Cached input có giá trên mỗi token thấp hơn, nhưng ở khối lượng đó vẫn được tính vào hóa đơn.

Từ đây có 4 thiết lập:

• Chọn depth nhỏ nhất mà các leaf là những đơn vị công việc thực sự, rồi dừng lại. Depth không cần thiết cũng là chi phí không cần thiết.
• Dùng solo mode khi công việc kéo dài dưới nửa giờ, vì chi phí setup subagent trong trường hợp này cao hơn lợi ích từ context mới.
• Cài Stop hook nếu bạn dùng Claude Code. Đây là phần duy nhất trong quy trình này chạy miễn phí.
• Đặt hard spend ceiling ở cấp account trước khi bắt đầu bất kỳ tác vụ dài nào.

Điểm cuối cùng là điều cần nói thẳng. Một skill được thiết kế để không dừng sớm sẽ tiếp tục làm việc theo đúng thiết kế. Budget và alerting là công việc riêng với prompting, còn giữ chi phí của agent trên VPS trong tầm kiểm soát trình bày các cap nên thiết lập trước.

Tác giả đã đo những gì và kết quả đó chứng minh điều gì

Repo này công bố bài test của chính mình, một việc hiếm hơn mức đáng lẽ phải có. Thiết lập của họ, trích từ README: "hai tác vụ build từ đầu (một site marketing và một hệ Mặt Trời bằng three.js), mỗi tác vụ có ba điều kiện (không có skill, tree 3, tree 6), mỗi lần chạy dùng một folder mới và session mới, cùng một model, cùng nội dung prompt. Mọi output đều được các agent độc lập review code, xác minh lại theo hướng đối kháng và test trực tiếp trong browser."

[
  {
    "label": "Self-found defects fixed, skill runs",
    "low_count": 4,
    "high_count": 10
  },
  {
    "label": "Wrong numbers in report, skill runs",
    "low_count": 1,
    "high_count": 3
  },
  {
    "label": "Wrong numbers in report, baseline runs",
    "low_count": 0,
    "high_count": 0
  }
]

Hãy đọc kỹ hàng giữa. Trong bài test của chính tác giả, skill chạy từ 4 đến 10 lỗi cố định mà agent tự phát hiện trước khi bàn giao. Sau đó, mỗi lần chạy skill đều tạo report cuối chứa từ 1 đến 3 con số sai, trong khi các lần chạy baseline chứa 0. Làm nhiều việc hơn tạo ra build tốt hơn nhưng summary tệ hơn. Đây là phát hiện đứng sau quy tắc ledger và chỉ dẫn phải đo lại mọi con số tại thời điểm viết report, hoặc đánh dấu chúng là chưa được xác minh.

Một kết quả khác của họ cũng đáng lưu ý: "Lỗi live duy nhất ở mức nghiêm trọng là một build baseline, nhưng report của nó lại khẳng định trường hợp đó đã được xử lý." Một summary đầy tự tin nằm trên một build bị hỏng chính là vấn đề mà các gate này nhằm ngăn chặn.

Bây giờ là các giới hạn. Sáu lần chạy, hai tác vụ build, một model; tất cả đều do chính tác giả của skill chạy và report. Đây không phải là một phép tái lập độc lập, và chúng tôi trích dẫn các kết luận này như tuyên bố của tác giả tại thời điểm 2026-08-10. Thay vào đó, hãy test trên công việc của bạn: chạy cùng một tác vụ 2 lần, một lần không dùng gì thêm và một lần dùng file gate, rồi đếm số gate đã đóng bằng evidence mà bạn có thể tự chạy lại. Con số đó là con số duy nhất trong lĩnh vực này thực sự thuộc về bạn.

FAQ

Depth Tree trong skill unlazy là gì?

Đây là phương pháp phân rã. Một task được tách tại các điểm tự nhiên qua N lớp, và chỉ các leaf ở lớp cuối mới được tính là công việc. Skill định nghĩa một leaf là ít nhất mười phút làm việc tập trung, với một deliverable nhất quán và một gates file. Vì vậy, nếu bạn có thể hoàn thành một leaf trong hai phút thì việc tách đã đi quá sâu một lớp. Mọi lớp phía trên leaf đều là phần phân rã và tích hợp. Mỗi nhánh có gates riêng để chứng minh các nhánh con đã được merge và các interface khớp nhau. Bạn chọn độ sâu khi invoke skill, ví dụ tree 5. Mặc định được ghi trong tài liệu là độ sâu nhỏ nhất mà các leaf trở thành đơn vị công việc thực sự.

Skill unlazy có hoạt động bên ngoài Claude Code không?

Có, nhưng chỉ một phần. Skill là plain markdown, nên Codex, Cursor và mọi công cụ đọc được SKILL.md hoặc system prompt đều có thể dùng Depth Tree, gates file, các bước kiểm tra có thể chạy và bốn pass cho mỗi leaf. Cơ chế enforcement cứng thì khác. Stop hook chặn việc kết thúc một turn khi các gate chưa đạt là tính năng của Claude Code, được cài bằng node <path-to-skill>/scripts/install-hooks.mjs. Ở các môi trường khác, không có gì ngăn model kết thúc turn sớm theo cách có cấu trúc. Vì vậy, bạn phải tự đọc gates file và gửi lại cho model.

Skill unlazy làm tăng chi phí token của tôi bao nhiêu?

Tác giả báo cáo mức từ 1.6 đến 3.9 lần số output token của một lần chạy không có skill ở solo mode, chưa tính vài trăm token overhead cho chính gates file. Việc đi sâu hơn trong cùng một context gần như không đáng kể khi so sánh, khoảng từ 1.0 đến 1.5 lần khi chuyển từ tree 3 sang tree 6. Orchestrated mode tốn kém hơn, vì mỗi leaf tạo một context mới để đọc lại contract và gates trước khi làm việc. Stop hook không thêm chi phí nào, vì nó chỉ quét các file. Đây là số liệu của tác giả tính đến 2026-08-10, không phải số đo chúng tôi tự lặp lại.

Tôi nên dùng unlazy hay ponytail?

Hãy chọn skill dựa trên lỗi đang gặp. ponytail dành cho agent viết quá nhiều, vì nó đóng vai một senior developer, hỏi xem code có thực sự cần tồn tại không và ưu tiên dùng standard library. unlazy dành cho agent hoàn thành quá ít so với yêu cầu, vì nó bắt buộc phải phân rã và không cho đóng gate nếu chưa có evidence. Nếu muốn dùng cả hai, hãy chốt scope bằng ponytail trước, rồi chuyển scope đó cho unlazy. Như vậy, bạn không phải trả effort multiplier cho phần công việc đáng lẽ nên bị xóa.

Vì sao agent của tôi vẫn dừng sớm sau khi cài unlazy?

Hãy kiểm tra 4 việc. Trước tiên, xác nhận skill đã có trên disk bằng ls ~/.claude/skills/unlazy/SKILL.md, vì clone vào một directory chưa tồn tại là lỗi thường gặp nhất. Tiếp theo, xác nhận gates file đã được ghi trước khi công việc bắt đầu, vì hook quét các gates file và một GATES.md bị thiếu sẽ không cho hook có gì để chặn. Sau đó, xác nhận vị trí cài hook: lệnh install-hooks.mjs đơn giản chỉ ghi vào settings.local.json của project hiện tại, nên project khác cần --global. Cuối cùng, hãy nhớ rằng release valve đang hoạt động đúng thiết kế: sau 6 lần stop liên tiếp bị chặn mà không có tiến triển ở gate, agent được phép tiếp tục với một cảnh báo, còn một dòng ABANDON: <gate> <reason> sẽ cố ý kết thúc lần thử.