Skill unlazy và phương pháp Depth Tree

Skill unlazy làm gì

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 theo các ranh giới thực tế và đặt các điều kiện nghiệm thu riêng cho từng node lá. Version 2 chuyển cơ chế enforcement từ prose vào các file, nên agent phải chứng minh việc hoàn tất bằng một danh sách command có thể chạy được thay vì tự khẳng định.

Skill này do Leonxlnx phát hành tại github.com/Leonxlnx/unlazy theo MIT license. Hiện không có release được gắn tag để pin: tính đến 2026-10-11, cả danh sách tag và release của repo đều trống. Guide này ban đầu được viết dựa trên source milestone 2.0.0 ngày 2026-08-10. Ngày 2026-10-11, chúng tôi kiểm tra lại guide với source hiện tại trên main. CHANGELOG ghi source đó là "Unreleased, target 2.1.0" và nêu rõ source này không tuyên bố có Git tag hoặc GitHub Release cho 2.1.0. Chạy command cài đặt hôm nay sẽ lấy source mới hơn đó, không phải 2.0.0. 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 copy 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 thông thường: một file SKILL.md mà harness nạp vào context của model khi task khớp với phần 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 là markdown thuần kết hợp với một vài Node script, nên không cần server và cũng không cần API key riêng.

Tại 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 dạng dễ nhận biết. Bạn yêu cầu bốn việc. Câu trả lời đề cập đến 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 ghi nhận, nên không có cảnh báo nào xuất hiện. Bạn chỉ phát hiện phần bị thiếu sau một tuần.

README của unlazy dựa trên các nghiên cứu đã công bố về hiện tượng model làm việc qua loa. README trích dẫn arXiv 2512.20662 với phát hiện rằng: "Các prompt nhiều phần, có nội dung chi tiết, vẫn chỉ được tuân thủ một phần và bị cắt sớm trên các model được thử nghiệm". Phần mô tả nguyên tắc của gates nêu rõ tiền đề thiết kế: "Các quy tắc ở trên là văn xuôi, và văn xuôi là lớp mà project này vốn đã xem là yếu nhất." Bảo agent cố gắng hơn chỉ tạo thêm văn xuôi, trong cùng context đã dẫn đến thiếu sót đó.

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

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

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

Chỉ tách tại ranh giới thực của domain, component hoặc verification. Không bắt buộc phải tách nhị phân.

Đặt layer 1 là task được yêu cầu.

Các leaf chứa deliverable. Mỗi layer phía trên sẽ tích hợp và verification kết quả do các node con trả về.

Một leaf lớn hơn một bullet point. Tài liệu tham chiếu xác định kích thước leaf theo outcome, không theo thời gian:

Mỗi leaf phải là một deliverable nhất quán.

Gộp các leaf nhỏ nằm liền kề; tách một leaf nếu nó che giấu nhiều outcome độc lập.

Quy tắc này ngăn cây sâu biến thành công việc hình thức. Nếu một leaf có nội dung là "đổi tên biến", nó không đạt yêu cầu, và lần tách ở phía trên đã đi quá một layer.

Sau đó, mỗi leaf chạy qua 4 pass: triển khai hoàn chỉnh, không để placeholder; đọc lại theo cách một domain expert sẽ đọc; tìm lỗi; rồi áp dụng các cải tiến dễ thực hiện, lặp lại cho đến khi một pass cải tiến đầy đủ không tìm thấy gì. Các pass này cũng là lý do cần gộp những leaf quá nhỏ. Chạy 4 pass cho một thay đổi mất 2 phút chỉ là hình thức.

Bạn chọn depth khi invoke skill:

/unlazy tree 5 refactor the payment module

Bạn cũng có thể dùng ngôn ngữ thông thường, 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

Các phiên bản trước của hướng dẫn này trích dẫn các khoảng depth kèm số lượng leaf cho từng depth. Tài liệu tham chiếu hiện tại không có bất kỳ số lượng leaf nào, và viết: "Không được xem depth là một cam kết số học về effort hoặc token." Chỉ còn lại hướng dẫn định tính: "Dùng cây nông hoặc solo ledger cho một feature, bug hunt có phạm vi rõ ràng hoặc tài liệu." Dùng orchestrated tree cho các trường hợp có nhiều deliverable nhất quán được hưởng lợi từ context mới hoặc quyền sở hữu độc lập. Chỉ nên dùng cây sâu hơn khi các branch bổ sung tương ứng với các ranh giới tích hợp thực tế.

Khi không chỉ định depth, tài liệu tham chiếu nói hãy "chọn cây nhỏ nhất có thể thể hiện mọi deliverable độc lập và integration point". Khi bạn chỉ định một con số không phù hợp với công việc, tài liệu yêu cầu agent nêu rõ điều đó thay vì thêm nội dung cho đủ: "Nếu depth được yêu cầu sẽ tạo ra các leaf hình thức, hãy nêu rõ sự không phù hợp và dùng cách phân rã trung thực gần nhất." Depth mô tả công việc, nên tăng số lượng depth không làm chất lượng tăng.

Gates file có dạng như thế nào

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à pass, và pass cũng yêu cầu command exit với mã 0. EVIDENCE bắt đầu tại pending. Sau một lần chạy đạt, checker điền vào đó một output fingerprint thay cho raw output. Manual gate không có command, nên bạn ghi lại sự kiện nhỏ nhất chứng minh kết quả. Skill cung cấp scripts/gate-check.mjs để thực hiện việc này. Với --status, skill báo những gate vẫn còn mở mà không chạy command hoặc thay đổi file, để bạn audit một lần chạy mà không cần đọc transcript. Skill chỉ chạy các ledger command khi bạn truyền --approve, vì vậy hãy đọc kỹ từng command và từng script mà command đó gọi trước khi truyền tham số này. Một scripts/gate-lint.mjs riêng dùng để kiểm tra chất lượng của ledger mà không chạy gì.

Quy tắc reporting trong SKILL.md chỉ gói gọn trong một dòng:

Không tạo báo cáo hoàn tất khi bất kỳ gate bắt buộc nào chưa đạt, đã bị bỏ, bị trì hoãn hoặc đang chờ quyết định của owner.

Ngoài ra, agent được yêu cầu “đo lại mọi số liệu và tuyên bố hoàn tất ngay trước khi báo cáo”. Một gate không thể được đóng chỉ vì agent cảm thấy đã xong. Đóng gate cần một lần chạy có output khớp hoặc không khớp với EXPECT.

Hãy viết gates file để một người khác 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ó báo lỗi rõ ràng khi file trống hoặc không tồn tại.

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

Khi một cây đủ lớn để 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 về phương pháp đặt hợp đồng trước khi fan-out: "Sửa các hợp đồng trước khi fan-out." Kế hoạch liệt kê mọi kết quả bắt buộc trong PLAN.md, "sau đó ghi lại các interface, format, giả định dùng chung, quy ước lỗi, cách đặt tên và quyền sở hữu trước khi một leaf 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 riêng. Lỗi chỉ xuất hiện tại nơi chúng kết nối với nhau. Điểm kết nối đó thuộc trách nhiệm của layer phía trên, và tài liệu tham chiếu về orchestration nêu rõ: "Kiểm tra lại các child, sau đó chạy các kiểm tra interface, end-to-end và regression."

Trong chế độ orchestration, driver được yêu cầu "chỉ cung cấp cho mỗi leaf hợp đồng dùng chung, phạm vi ownership và dependency chính xác của leaf đó, cùng ledger riêng của nó" và "không để lộ lịch sử của các leaf không liên quan." Mỗi ledger của leaf khai báo các path mà leaf đó được phép ghi, và các path OWNS đó không được chồng lấn với path của bất kỳ leaf nào khác được dispatch cùng lúc. Khi một subagent trả kết quả, driver phải "chạy lại các gate có thể chạy của leaf vừa trả về, bao gồm cả những gate đã được kiểm tra trước đó", vì --status tự nó không phải là kiểm tra lại. Một leaf có các ô được đánh dấu nhưng không có bằng chứng thực tế sẽ không vượt qua lần chạy lại đó.

Orchestration có giới hạn tối thiểu. Tài liệu tham chiếu về orchestration nói: "Tiếp tục làm một mình khi một context tập trung có thể triển khai và xác minh task mà không che giấu các deliverable độc lập." Mỗi subagent phải tự xây dựng lại cách hiểu về task từ đầu, nên với task nhỏ, chi phí setup này lớn hơn lợi ích từ sự tập trung mới.

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

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

npx skills add Leonxlnx/unlazy

Thêm -g để cài đặt ở cấp người dùng hoặc --all để cài đặt cho mọi agent mà CLI phát hiện. Lệnh này cài phiên bản hiện có trên main tại thời điểm đó. Không có bản release được gắn tag, vì vậy README hướng dẫn bạn ghim một commit cụ thể nếu cần bản cài đặt không tự thay đổi.

Cài đặt thủ công là clone repository 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ưa:

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

Đường dẫn được in ra cho biết file đã có trên ổ đĩa. No such file or directory nghĩa là repository được clone sang 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. Cũng không nên chỉ tin vào thông báo của agent. Agent nói skill đã được cài đặt không có nghĩa là file đã được xác nhận tồn tại. Checker và hook tùy chọn cần Node 16 trở lên, đồng thời không dùng package runtime bên thứ ba.

Tính đến 2026-10-11, README mô tả 2 harness: Claude Code, nơi bạn gọi skill bằng /unlazy, và Codex CLI, nơi bạn gọi bằng $unlazy. README không mô tả cách dùng với các harness không có skill loader, nên việc dán SKILL.md vào file rules của một tool khác vẫn chưa được kiểm thử. Nếu muốn biết điều gì giúp SKILL.md được load ổn định ngay từ đầu, tự viết agent skill giải thích frontmatter và cơ chế khớp description 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à các 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ố kết thúc lượt của mình. Hook này quét ledger và trạng thái dispatch của session hiện tại, rồi chặn việc dừng khi các gate chưa đạt. Vì vậy, lượt chạy không thể kết thúc khi vẫn còn mục chưa được kiểm tra. Hook không tự chạy các bước kiểm tra và cũng không tự thực hiện model call nào. Tuy nhiên, hook không hoàn toàn miễn phí. Tài liệu tham chiếu về token economy ghi rõ: “Một lần block sẽ khiến agent tiếp tục chạy thêm, và việc đó tiêu tốn thêm tài nguyên model.” Để xem cơ chế chung và các event khác có thể gắn hook, hãy xem cách Claude Code hook chạy quanh một lượt. README yêu cầu chỉ cài hook khi người dùng đồng ý. README cũng yêu cầu thêm .claude/settings.local.json, .unlazy/ và .unlazy-hook-state.json vào ignore rules.

Hook có một cơ chế thoát, và cơ chế này quan trọng hơn vẻ ngoài của nó. Nếu agent không đạt thêm tiến triển nào về gate trong 6 lần dừng liên tiếp bị block, hook sẽ cho phép agent thoát thay vì giữ agent trong vòng lặp. Các lần chỉnh sửa chỉ thay đổi metadata cũng không reset bộ đếm đó. Một dòng ABANDON: <gate> <reason> cũng cho phép session kết thúc, nhưng dưới dạng bàn giao rõ ràng thay vì được xem là đạt. Gate bị bỏ dở sẽ được báo cáo là kết quả không thành công, không phải công việc đã hoàn tất. Nếu thiếu hai cơ chế thoát này, một gate không thể đạt trong môi trường của bạn sẽ tiếp tục tiêu tốn token cho đến khi bạn tự kill session.

Trên Codex hoặc bất kỳ harness nào khác, install-hooks.mjs không có nơi để cài đặt, vì nó chỉ ghi các file settings của Claude. Bạn vẫn có file gates và các bước kiểm tra 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. Trong trường hợp đó, file gates chỉ là tài liệu mà bạn phải tự đọc.

unlazy hay ponytail: bạn cần skill nào?

Hai skill này nổi lên trong cùng một giai đoạn và kéo khối lượng công việc theo hai hướng ngược nhau, nên rất dễ nhầm lẫn.

ponytail khiến agent hành xử như một senior developer luôn đặt câu hỏi đầu tiên là liệu đoạn code đó có cần tồn tại hay không. Skill này 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 độ nỗ lực 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 dựa trên lỗi thực tế bạn đang thấy. 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 lazy senior developer của nó. Nếu agent bỏ dở mục thứ ba trong yêu cầu gồm bốn phần rồi báo thành công, bạn cần unlazy.

Bạn 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 đó chuyển 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 lá cho những phần việc mà ponytail vốn đã xóa bỏ, rồi phải trả thêm chi phí cho toàn bộ nỗ lực đó. Đây là thứ tự tôi khuyến nghị, không phải một integration được hai project ghi nhận.

Chi phí của depth trên agent chạy trên VPS là gì?

Công sức được tính bằng token, và với agent chạy trên VPS bằng API key của bạn, token đồng nghĩa với chi phí. Project hiện không còn đưa ra con số cụ thể về mức chi phí mà unlazy làm tăng.

Các phiên bản trước của hướng dẫn này từng lập biểu đồ về token output và các hệ số chi phí, dựa trên phép so sánh chạy 6 lần của các tác giả. Sau đó, các tác giả đã rút lại những số liệu này. File references/token-economy.md hiện cho biết các prompt thô, trace, output và bản ghi chấm điểm dùng để tạo ra chúng đã bị thiếu khỏi repository, "so those numbers are not reproducible here", đồng thời thêm: "Do not use them as product guarantees." Tài liệu tham chiếu về phương pháp còn nói rõ hơn: "Do not treat depth as an arithmetic promise about effort or tokens." Chúng tôi đã xóa các con số thay vì lặp lại những số liệu mà chính tác giả không còn bảo đảm.

Những gì tài liệu tham chiếu vẫn nói về chi phí chỉ mang tính định hướng. Khuyến nghị mở đầu là "Move repeated, deterministic verification into commands and keep orchestration context narrow." Chế độ solo dùng thêm token output trong một context. Chế độ orchestrated tạo thêm context, và mỗi context mới phải đọc contract cùng ledger riêng trước khi làm được việc có ích. Tài liệu tham chiếu cảnh báo theo cả hai hướng: "Do not orchestrate a task that one focused session can implement and verify cleanly." Tài liệu cũng cảnh báo không nên giữ toàn bộ quá trình build trong một context chỉ để tránh overhead của subagent, khi các leaf và contract đã rõ ràng.

Bốn thiết lập sau đây được suy ra từ đó:

• Chọn depth nhỏ nhất mà các leaf là những đơn vị công việc thực tế, rồi dừng lại. Depth không cần thiết là chi phí không cần thiết.
• Dùng chế độ solo khi một session tập trung có thể build và verify task, vì chi phí thiết lập subagent trong trường hợp đó cao hơn lợi ích mà context mới mang lại.
• Cài Stop hook nếu bạn dùng Claude Code. Hook không tự gọi model, nhưng mỗi lần block sẽ đưa agent quay lại làm việc, và phần công việc đó vẫn bị tính phí.
• Đặt mức trần chi tiêu cứng ở cấp account trước khi bắt đầu một tác vụ dài.

Điểm cuối cùng là điều cần nói rõ. Một skill được thiết kế để không dừng sớm thì về bản chất sẽ tiếp tục làm việc. Quản lý ngân sách và cảnh báo là công việc riêng, không phải việc của prompt. kiểm soát chi phí của agent trên VPS trình bày các mức giới hạn nên thiết lập trước.

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

Repo từng công bố một bài test riêng, việc đáng ra phải phổ biến hơn. Sau đó repo đã rút lại bài test đó, điều còn hiếm hơn. README hiện chỉ nói rằng “Các phiên bản README trước đây cũng dẫn một phép so sánh nội bộ gồm sáu lần chạy” và “Các artifact thô cần để tái tạo chính xác những tỷ lệ và số lượng đó không có trong repository này”. README khuyên: “Hãy xem các kết quả này là dữ liệu đầu vào lịch sử cho thiết kế, không phải cam kết về benchmark.”

Thiết lập đó vẫn còn trong research/validation-protocol.md: hai tác vụ build, mỗi tác vụ có ba điều kiện (không có skill, tree 3, tree 6), và mỗi lần chạy dùng một thư mục cùng một session mới. Protocol gọi đây là “phép so sánh thăm dò do maintainer chạy”. Protocol nói rằng không thể tái tạo hoặc audit từ repository các tỷ lệ token, số defect tự phát hiện, số lỗi runtime và lỗi số liệu báo cáo do phép so sánh này tạo ra. Protocol cũng nói không được mô tả phép so sánh này là bằng chứng cho thấy unlazy tạo ra một mức cải thiện hoặc hệ số chi phí cụ thể. Các phiên bản trước của hướng dẫn này từng lập biểu đồ số lượng theo từng lần chạy từ bài test đó. Sau khi tác giả rút lại kết quả, chúng tôi đã xóa các số liệu này.

Một bài học thiết kế vẫn còn giá trị dù các con số đã bị rút lại. Quy tắc “đo lại ngay mọi con số và tuyên bố về mức độ hoàn tất trước khi báo cáo” vẫn nằm trong SKILL.md, và template gates cảnh báo không được chép một con số được cung cấp vào EXPECT rồi coi đó là bằng chứng của chính mình. Một bản tóm tắt đầy tự tin đặt trên một build bị hỏng chính là vấn đề mà các gate được thiết kế để ngăn chặn.

Bây giờ là các giới hạn. Tính đến 2026-10-11, không còn kết quả đã công bố nào để đánh giá; chỉ còn phương pháp và một protocol cho lần chạy lại đúng quy trình. Thay vào đó, hãy kiểm tra trên công việc của bạn: chạy cùng một tác vụ hai lần, một lần không dùng gì thêm và một lần dùng file gates, sau đó đếm số gate đã đóng bằng bằng chứng 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 thuộc về bạn.

FAQ

Depth Tree trong skill unlazy là gì?

Đây là một phương pháp phân rã. Một task chỉ được tách tại ranh giới thực sự giữa domain, component hoặc bước verification. Layer 1 là task được yêu cầu. Mỗi leaf là một deliverable thống nhất với các gate riêng. Các leaf nhỏ nằm cạnh nhau sẽ được gộp lại. Một leaf che giấu nhiều kết quả độc lập sẽ được tách tiếp. Mọi layer phía trên leaf đều thực hiện tích hợp và verification: kiểm tra lại các child, rồi chạy các kiểm tra interface, end-to-end và regression. Bạn chọn độ sâu khi invoke skill, ví dụ tree 5. Nếu không chỉ định depth, skill sẽ chọn tree nhỏ nhất nhưng vẫn thể hiện mọi deliverable và integration point độc lập.

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

Có, nhưng chỉ một phần. Skill là markdown thuần túy. README có tài liệu về Codex CLI cùng với Claude Code, nên Depth Tree, gates file, các kiểm tra có thể chạy và bốn pass cho mỗi leaf đều hoạt động ở đó. Tài liệu hiện tại không đề cập đến các harness khác. 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. Ở mọi nơi khác, không có gì ngăn model kết thúc turn sớm về mặt cấu trúc. Vì vậy, chính bạn phải đọ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?

Hiện chưa ai có thể đưa ra con số đáng tin cậy. Các tỷ lệ token trước đây của tác giả được lấy từ 6 lần chạy không thể tái tạo. Tài liệu hiện tại nói không được dùng chúng như cam kết về sản phẩm, cũng không được xem depth là một cam kết số học về effort hoặc token. Hướng tác động vẫn rõ ràng. Chế độ solo thêm output vào một context. Chế độ orchestrated tạo một context mới cho mỗi leaf; context đó đọc contract và ledger trước khi làm việc. Stop hook không tự thực hiện model call nào, nhưng mỗi lần block đều gửi agent quay lại làm việc. Hãy đo trên task của chính bạn và theo billing của chính bạn.

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

Hãy chọn skill dựa trên failure đang gặp. ponytail dành cho agent viết quá nhiều, vì nó đóng vai senior developer, hỏi xem code có thực sự cần tồn tại không và ưu tiên 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, trước tiên hãy chốt scope bằng ponytail, rồi giao scope đó cho unlazy. Như vậy, bạn không phải trả effort multiplier cho phần việc lẽ ra đã 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. Thứ nhất, 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. Thứ hai, xác nhận gates file đã được ghi trước khi bắt đầu làm việc, vì hook quét ledger của session và một GATES.md không tồn tại sẽ không cung cấp gì để hook block. Thứ ba, xác nhận hook được cài ở đâu: lệnh install-hooks.mjs thuần túy chỉ ghi vào settings.local.json của project hiện tại, nên project khác cần --global. Thứ tư, hãy nhớ release valve đang hoạt động đúng thiết kế. Sau 6 lần stop liên tiếp bị block mà không có tiến triển ở gate, agent sẽ được release. Một dòng ABANDON: <gate> <reason> cố ý kết thúc attempt như một handoff có thể quan sát được, nhưng đó không phải là thành công.