آموزش استفاده از مهارت unlazy و متد Depth Tree

مهارت unlazy چه کاری انجام می‌دهد

مهارت unlazy یک مهارت عامل (agent skill) است که برای جلوگیری از یک خطای خاص طراحی شده است: عاملی که گزارش می‌دهد کار انجام شده است، در حالی که هنوز به پایان نرسیده است. هستهٔ اصلی این مهارت، Depth Tree است؛ روشی که وظیفه را به لایه‌های مختلف تقسیم می‌کند و تنها لایهٔ زیرین را به عنوان کار واقعی در نظر می‌گیرد. در نسخه 2، اعمال این محدودیت از متن به فایل‌ها منتقل شد؛ بنابراین عامل باید به جای ادعای انجام کار، تکمیل آن را با استفاده از فهرستی از دستورات قابل‌اجرا اثبات کند.

این مهارت توسط Leonxlnx در github.com/Leonxlnx/unlazy تحت مجوز MIT منتشر شده است. این راهنما بر اساس نسخه 2.0.0 نوشته شده که در تاریخ 2026-08-10 منتشر شد. مهارت‌ها در این حوزه به‌سرعت تغییر می‌کنند، بنابراین پیش از کپی‌کردن هر بخشی از این راهنما در یک محیط عملیاتی، حتماً فایل CHANGELOG مخزن را مطالعه کنید.

در اینجا، مهارت به همان معنای معمول است: یک فایل SKILL.md که harness آن را در context مدل بارگذاری می‌کند، به‌شرطی که وظیفه با توضیحات آن مطابقت داشته باشد. اگر این مکانیزم برای شما جدید است، با مهارت عامل چیست و harness چگونه آن را بارگذاری می‌کند شروع کنید. unlazy شامل markdown ساده و چند اسکریپت Node است، بنابراین به هیچ سرور یا API key اختصاصی نیاز ندارد.

چرا ایجنت‌ها در 80 درصد متوقف شده و دستور سوم شما را نادیده می‌گیرند

این رفتار الگوی قابل‌تشخیصی دارد. شما چهار مورد را درخواست می‌کنید. پاسخ، مورد اول، دوم و چهارم را پوشش می‌دهد. خلاصه پایانی، هر چهار مورد را به‌عنوان تکمیل‌شده فهرست می‌کند. هیچ خطایی رخ نداده است، بنابراین هیچ‌چیز آن را علامت‌گذاری نکرده و شما یک هفته بعد متوجه این شکاف می‌شوید.

فایل README پروژه unlazy این موضوع را بر اساس پژوهش‌های منتشرشده درباره تنبلی مدل‌ها ریشه‌یابی کرده و به «قطع زودهنگام پاسخ‌ها و رعایت ناقص درخواست‌های چندبخشی» (با ارجاع به arXiv 2512.20662) اشاره می‌کند. همان README، پیش‌فرض طراحی را به‌صراحت بیان می‌کند: متن نمی‌تواند متن را مجبور به اجرا کند. درخواست از یک ایجنت برای تلاش بیشتر، صرفاً متن بیشتری است که به همان متنی اضافه می‌شود که باعث ایجاد این نقص شده است.

به همین دلیل است که نسخه 2 وضعیت خود را در فایل‌ها نگه می‌دارد. یک چک‌باکس در GATES.md خارج از حوزه اختیار مدل قرار دارد. یا آن کادر یک خط شواهد در زیر خود دارد یا ندارد، و یک اسکریپت می‌تواند بدون پرسش از ایجنت، به شما بگوید که وضعیت چگونه است.

درخت عمق، لایه به لایه

درخت عمق (Depth Tree) نوعی تجزیه است که قانونی برای محل مجاز انجام کار دارد. طبق مرجع این روش:

در محل اتصال‌های طبیعی تقسیم کنید، در صورت امکان به‌صورت دوتایی، تا عمق N لایه.

برگ‌ها تنها مکان‌هایی هستند که کار واقعی در آن‌ها انجام می‌شود؛ هر لایه بالاتر از آن‌ها، صرفاً تجزیه و یکپارچه‌سازی است.

یک برگ بزرگ‌تر از یک نکتهٔ فهرست‌وار است. این مرجع یک حداقل اندازه تعیین کرده است:

یک برگ، واحدی واقعی از کار است. ده دقیقه یا بیشتر تلاش متمرکز، یک خروجی منسجم، یک فایل نهایی.

این حداقل اندازه همان چیزی است که مانع از تبدیل شدن یک درخت عمیق به کارهای بیهوده می‌شود. اگر یک برگ شامل «تغییر نام متغیر» باشد، در این آزمون مردود است و تقسیم‌بندی انجام‌شده در لایهٔ بالاتر، یک سطح بیش از حد پیش رفته است.

هر برگ سپس چهار مرحله را طی می‌کند: پیاده‌سازی کامل بدون هیچ جای‌گذاری موقت، بازخوانی آن به شیوه‌ای که یک متخصص حوزه انجام می‌دهد، جستجو برای یافتن نقص‌ها، و در نهایت صیقل دادن در مواردی که هزینهٔ اضافی ندارد. این مراحل، دلیل دیگر نیاز برگ به حداقل اندازه است. انجام چهار مرحله برای تغییری که 2 دقیقه زمان می‌برد، صرفاً نمایش است.

شما هنگام فراخوانی این مهارت، عمق را انتخاب می‌کنید:

/unlazy tree 5 refactor the payment module

زبان ساده نیز کارساز است، زیرا توصیف مهارت به‌جای تطبیق با یک slash command، با قصد کاربر مطابقت پیدا می‌کند:

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

این مرجع، بازه‌های عمق را ارائه می‌دهد. tree 2 یا 3 برای یک قابلیت، جستجوی باگ یا یک سند است که به‌صورت انفرادی در یک جلسه و در قالب 2 تا 4 برگ انجام می‌شود. tree 4 یا 5 برای یک زیرسیستم، بازنویسی کد (refactor) یا یک بررسی جدی است، جایی که 8 تا 16 برگ «فراتر از ظرفیت نگهداری یک زمینه ذهنی» است. tree 6 یا 7 یک پروژه کامل است که در حالت هماهنگ‌شده اجرا می‌شود و برگ‌ها روی واحدهای کاری مجزا نگاشت می‌شوند.

وقتی عمقی را تعیین نمی‌کنید، به مهارت دستور داده می‌شود که «کوچک‌ترین N را انتخاب کند که برگ‌هایش با بخش‌های طبیعی وظیفه مطابقت داشته باشد» و به‌طور صریح به آن گفته می‌شود که به‌صورت پیش‌فرض یک لایه عمیق‌تر نرود. عمق، توصیف‌کنندهٔ کار است، بنابراین افزایش بی‌دلیل عدد، کیفیت را بهبود نمی‌بخشد.

ساختار یک فایل gates

پیش از شروع هر کاری، عامل (agent) معیارهای پذیرش را در یک فایل gates می‌نویسد. هر gate یک چک‌باکس است که دستوری در زیر آن قرار دارد.

# 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 همان دستور است. EXPECT خروجی مورد انتظار برای تایید موفقیت است. EVIDENCE از pending شروع می‌شود و باید با آنچه دستور در واقعیت چاپ کرده است، جایگزین شود. این skill شامل scripts/gate-check.mjs برای اسکن کردن این فایل‌ها و گزارش وضعیت gateهای باز است؛ این یعنی می‌توانید بدون خواندن متن کامل تراکنش (transcript)، یک اجرا را حسابرسی کنید.

فلسفهٔ این کار در یک جمله خلاصه می‌شود و SKILL.md آن را این‌گونه بیان می‌کند:

گزارش مجموعه‌ای از ادعاهاست که با یک دفتر کل (ledger) پشتیبانی می‌شود، نه صرفاً حسی از تکمیل شدن کار.

قانون بعدی این است: «تا زمانی که دفتر کل کامل نشده، گزارشی ارائه نشود». همچنین طبق قانون گزارش‌دهی، هر عددی در خلاصهٔ نهایی باید در زمان گزارش مجدداً اندازه‌گیری شود یا با برچسب تاییدنشده (unverified) مشخص گردد. یک gate نمی‌تواند صرفاً به این دلیل که عامل احساس می‌کند کار تمام شده است بسته شود؛ زیرا بستن آن به معنای درج خروجی است که یا با EXPECT مطابقت دارد یا ندارد.

gateها را طوری بنویسید که یک غریبه هم بتواند آن‌ها را اجرا کند. «به نظر خوب می‌رسد» یک بررسی نیست. دستور test -s dist/index.html && echo ok که ok را چاپ می‌کند، یک بررسی است؛ زیرا در صورت خالی بودن یا نبودن فایل، با صدای بلند شکست می‌خورد.

قرارداد PLAN.md، پیش از هرگونه کار موازی

هنگامی که یک درخت به اندازه کافی گسترده می‌شود که برگ‌ها در زمینه‌های جداگانه اجرا شوند، آن برگ‌ها دیگر فرض‌های مشترک نخواهند داشت. ارجاع به متد، قراردادی را پیش از مرحله fan-out قرار می‌دهد:

قراردادها پیش از fan-out. رابط‌ها، مالکیت داده‌ها، نام‌گذاری و قراردادهای خطا باید پیش از شروع کار هر برگ، در فایل PLAN.md درج شوند.

دلیل این امر ملموس است. اگر به دو زیرعامل (subagent) گفته شود که «مدیریت خطا را اضافه کنید»، هر کدام دو ساختار خطای متفاوت ابداع خواهند کرد و هر دو برگ از دروازه‌های (gates) خود عبور می‌کنند، زیرا هر کدام به‌صورت محلی درست عمل کرده‌اند. شکست تنها در نقطه‌ای ظاهر می‌شود که آن‌ها به هم می‌رسند. دروازه‌های شاخه (branch gates) برای چنین لحظه‌ای وجود دارند: دروازه‌های یک شاخه ثابت می‌کنند که «فرزندان ادغام شده‌اند، رابط‌ها مطابقت دارند، رفتار سرتاسری کار می‌کند و هیچ رگرسیونی در خواهرخوانده‌ها رخ نداده است».

در حالت ارکستراسی (orchestrated mode)، درایور بخش قرارداد از فایل PLAN.md را به هر زیرعامل می‌دهد، نه کل فایل و نه تاریخچه خودِ درایور را؛ به‌علاوه، فایل دروازه‌های همان برگ را نیز عیناً ارائه می‌کند. هنگامی که زیرعامل بازمی‌گردد، درایور خودِ بررسی‌ها را دوباره اجرا می‌کند. زیرعاملی که «جعبه‌های خود را بدون ارائه مدرک تیک زده باشد»، با ذکر دقیق دروازه‌های برآورده‌نشده، به عقب بازگردانده می‌شود.

ارکستراسی یک حد کف دارد. طبق مرجع، برای کارهایی که کمتر از حدود نیم ساعت زمان واقعی می‌برند، بهتر است به‌صورت انفرادی کار کنید؛ زیرا هر زیرعامل باید درک خود از وظیفه را از صفر بازسازی کند و هزینه این راه‌اندازی، بیشتر از دستاوردی است که توجه تازه به همراه می‌آورد.

چگونه مهارت unlazy را نصب کنیم؟

مسیر پشتیبانی‌شده، استفاده از CLI مهارت‌ها است:

npx skills add Leonxlnx/unlazy

نصب دستی از طریق clone کردن در دایرکتوری مهارت‌های agent شما انجام می‌شود:

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

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

سپس بررسی کنید که فایل در جای درست قرار گرفته باشد:

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

چاپ شدن مسیر به این معناست که فایل روی دیسک موجود است. خطای No such file or directory نشان می‌دهد که clone در جای دیگری انجام شده است؛ این اتفاق معمولاً زمانی رخ می‌دهد که دایرکتوری مهارت‌ها با نامی که تصور می‌کردید وجود نداشته و git یک دایرکتوری جدید ایجاد کرده است. به گفتهٔ خودِ agent نیز در این مورد اعتماد نکنید. اعلان نصب در فایل README نیز با همین هشدار پایان می‌یابد: «تا زمانی که واقعاً وجود فایل روی دیسک را تأیید نکرده‌اید، به من نگویید که نصب شده است.»

برای محیطی که فاقد skill loader است، محتوای SKILL.md را در system prompt یا فایل قوانین کپی کنید. این روش جایگزین مستندشده است و به همین دلیل است که این متد روی Claude Code، Codex، Cursor و هر ابزار دیگری که فایل‌های دستورالعمل markdown ساده را می‌خواند، اجرا می‌شود. اگر می‌خواهید بدانید چه چیزی باعث می‌شود یک SKILL.md به‌طور قابل‌اطمینان بارگذاری شود، بخش نوشتن مهارت agent اختصاصی خود به بررسی frontmatter و تطبیق توضیحات می‌پردازد که تعیین می‌کنند آیا مهارت اصلاً اجرا می‌شود یا خیر.

آیا Stop hook خارج از Claude Code کار می‌کند؟

خیر، و این بخشی است که باید در مورد آن دقیق بود. تمام موارد بالا دستورالعمل هستند و دستورالعمل‌ها ممکن است نادیده گرفته شوند. تنها بخش اجرایی ساختاری، Stop hook است و Stop hookها یکی از قابلیت‌های 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 در لحظه‌ای اجرا می‌شود که عامل (agent) قصد دارد نوبت خود را به پایان برساند. این hook فایل‌های gates را اسکن کرده و در صورت برآورده نشدن شرایط، از توقف جلوگیری می‌کند؛ بنابراین نوبت نمی‌تواند با یک مورد بررسی‌نشده به پایان برسد. این ابزار فایل‌ها را می‌خواند و هیچ فراخوانی مدل (model call) انجام نمی‌دهد، به همین دلیل است که در README ذکر شده که هزینه آن صفر توکن است. برای اطلاع از مکانیسم کلی و سایر رویدادهایی که می‌توانید به آن‌ها متصل شوید، به نحوه عملکرد hookهای Claude Code در طول یک نوبت مراجعه کنید.

این ابزار دارای یک سوپاپ اطمینان (release valve) است که اهمیت آن بیش از چیزی است که به نظر می‌رسد. اگر عامل در طول 6 توقف مسدودشدهٔ متوالی هیچ پیشرفتی در گیت‌ها نداشته باشد، hook به جای حبس کردن عامل، به او اجازه عبور با یک هشدار را می‌دهد. یک خط ABANDON: <gate> <reason> همیشه به عنوان یک خروج صادقانه در نظر گرفته می‌شود. بدون این دو راه گریز، گیتی که در محیط شما غیرممکن باشد، تا زمانی که خودتان نشست را متوقف نکنید، توکن‌ها را هدر می‌دهد.

در Codex، Cursor یا هر محیط دیگری، install-hooks.mjs جایی برای نصب ندارد. شما همچنان فایل gates و بررسی‌های قابل اجرا را در اختیار دارید، اما هیچ ساختار بازدارنده‌ای وجود ندارد که مدل را از پایان دادن زودهنگام نوبت منع کند. در آنجا، فایل gates صرفاً سندی است که باید خودتان آن را مطالعه کنید.

unlazy یا ponytail: کدام را می‌خواهید؟

این دو مهارت در یک فصل ترند شدند و از نظر حجم کار در جهت مخالف یکدیگر عمل می‌کنند، که باعث می‌شود به‌راحتی با هم اشتباه گرفته شوند.

مهارت ponytail باعث می‌شود ایجنت مانند یک توسعه‌دهنده ارشد رفتار کند که اولین سوالش این است که آیا اصلاً نیازی به وجود این کد هست یا خیر. این مهارت دامنه پروژه (scope) را کاهش می‌دهد، استفاده از کتابخانه استاندارد را ترجیح می‌دهد و حجم تغییرات (diff) را کوچک می‌کند. مهارت unlazy فرض می‌کند که دامنه پروژه از قبل توافق شده است و تلاش می‌کند تا زمانی که تمام بخش‌های آن تکمیل و تایید نشوند، کار را پیش ببرد.

بنابراین، بر اساس خطایی که مشاهده می‌کنید انتخاب کنید. اگر ایجنت شما یک قابلیت کوچک را به یک فریم‌ورک تبدیل می‌کند، شما به مهارت ponytail و شخصیت توسعه‌دهنده ارشد تنبل آن نیاز دارید. اگر ایجنت شما مورد سوم از یک درخواست چهار بخشی را ناتمام می‌گذارد و سپس گزارش موفقیت می‌دهد، شما به unlazy نیاز دارید.

اجرای همزمان هر دو ممکن است و ترتیب آن‌ها اهمیت دارد. ابتدا دامنه کار را با پرسش‌های ponytail مشخص کنید، سپس دامنه توافق‌شده را به دروازه‌های unlazy بسپارید. اگر این کار را برعکس انجام دهید، برای کاری که ponytail آن را حذف می‌کرد، درختی از شاخ و برگ می‌سازید و سپس هزینه مضاعف برای عمق تمام آن پرداخت می‌کنید. این ترتیب‌بندی توصیه من است، نه یک ادغام مستند بین این دو پروژه.

هزینه عمق (depth) در یک agent که روی VPS میزبانی می‌شود چقدر است؟

عمق، ضریب تلاش است و تلاش همان توکن است. در یک VPS که agent را با استفاده از API key شخصی شما اجرا می‌کند، این ضریب مستقیماً به معنای هزینه مالی است.

[
  {
    "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
  }
]

این ارقام متعلق به نویسندگان و حاصل تست‌های آن‌ها در تاریخ 2026-08-10 است. ما این تست‌ها را بازتولید نکرده‌ایم، بنابراین آن‌ها را به عنوان یک الگوی کلی در نظر بگیرید، نه یک پیش‌بینی دقیق. حالت Solo discipline خروجی را تقریباً به 1.6 تا 3.9 برابر مقدار پایه افزایش داد، در حالی که حرکت از tree 3 به tree 6 در یک context واحد، تنها 1.0 تا 1.5 برابر به هزینه افزود؛ که بسیار کمتر از هشت برابری است که از سه انشعاب دوتایی (binary split) اضافی انتظار می‌رود.

افزایش عمق به نسبتِ آن گران‌تر نمی‌شود، زیرا عمق به جای افزودن contextهای جدید، تلاش را بازتوزیع می‌کند. مرجع اقتصاد توکن به صراحت بیان می‌کند که ضریب اصلی هزینه کجاست: «آنچه هزینه را چندبرابر می‌کند، ارکستراسیون (orchestration) است و باید هم چنین باشد، زیرا هر leaf یک context تازه خریداری می‌کند.» حالت Solo خروجی توکن‌ها را در یک context واحد چندبرابر می‌کند. حالت Orchestrated تعداد contextها را چندبرابر می‌کند و هر context جدید، پیش از انجام هر کار مفیدی، قرارداد و فایل gates مربوط به خود را دوباره می‌خواند.

هزینه دومی هم وجود دارد که نادیده گرفتن آن آسان است و همان مرجع به آن اشاره می‌کند. یک اجرای عمیق و یکپارچه (monolithic) در تست آن‌ها «تقریباً 58 میلیون توکن ورودی cached مصرف کرد»، زیرا یک context واحد که دائماً در حال رشد بود، همه چیز را با خود حمل می‌کرد. توکن ورودی cached به ازای هر توکن ارزان‌تر است، اما در آن حجم، همچنان در صورت‌حساب نهایی لحاظ می‌شود.

چهار تنظیمات زیر از این موضوع نتیجه می‌شود:

• کوچک‌ترین عمقی را انتخاب کنید که leafهای آن واحدهای کاری واقعی باشند، سپس متوقف شوید. عمقی که به آن نیاز ندارید، هزینه‌ای است که نباید بپردازید.
• برای کارهای کمتر از نیم ساعت در حالت Solo بمانید، زیرا هزینه راه‌اندازی subagent در آنجا بیشتر از بازدهی context تازه است.
• اگر از Claude Code استفاده می‌کنید، Stop hook را نصب کنید. این تنها بخشی از فرآیند است که به صورت رایگان اجرا می‌شود.
• پیش از شروع هر کار طولانی، یک سقف هزینه سخت (hard spend ceiling) در سطح حساب کاربری خود تعیین کنید.

نکته آخر صادقانه‌ترین مورد است. مهارتی که برای رد کردنِ توقف‌های زودهنگام طراحی شده، ذاتاً مهارتی است که به کار خود ادامه می‌دهد. بودجه‌بندی و هشداردهی، وظیفه‌ای جدا از پرامپت‌نویسی است و کنترل هزینه agent روی VPS به سقف‌هایی می‌پردازد که ارزش دارند از همان ابتدا اعمال شوند.

آنچه نویسندگان اندازه‌گیری کردند و اثبات آن

این مخزن تست اختصاصی خود را منتشر می‌کند که از آنچه باید باشد، نادرتر است. تنظیمات آن‌ها، به نقل از README: «دو وظیفه ساخت از صفر (یک سایت بازاریابی و یک منظومه شمسی three.js)، سه وضعیت برای هر کدام (بدون مهارت، tree 3، tree 6)، یک پوشه تازه و یک نشست تازه برای هر اجرا، مدل یکسان، بدنه پرامپت یکسان. تمام خروجی‌ها توسط عوامل مستقل بررسی کد شدند، به‌صورت خصمانه بازبینی شدند و به‌صورت زنده در مرورگر تست شدند.»

[
  {
    "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
  }
]

ردیف میانی را دو بار بخوانید. در تست خود نویسندگان، اجرای مهارت 4 تا 10 نقص را که عامل به‌تنهایی پیش از تحویل یافته بود، اصلاح کرد و هر اجرای مهارت سپس گزارش نهایی را ارائه داد که حاوی 1 تا 3 عدد اشتباه بود، در مقابل 0 در اجراهای پایه. کار بیشتر منجر به ساخت‌های بهتر و خلاصه‌های بدتر شد. این یافته‌ای است که پشت قانون دفتر کل و دستورالعمل بازسنجی هر عدد در زمان گزارش‌دهی یا علامت‌گذاری آن به‌عنوان تأییدنشده قرار دارد.

یکی دیگر از نتایج آن‌ها ارزش نگهداری دارد: «تنها شکست سخت و زنده، یک ساخت پایه بود و گزارش آن ادعا می‌کرد که مورد مدیریت شده است.» یک خلاصه مطمئن که بر روی یک ساخت خراب قرار گرفته، دقیقاً همان چیزی است که گیت‌ها برای آن طراحی شده‌اند.

حال محدودیت‌ها. شش اجرا، دو وظیفه ساخت، یک مدل، اجرا و گزارش‌شده توسط خود نویسنده مهارت. هیچ‌چیز در اینجا تکرار مستقل نیست و ما آن را به‌عنوان ادعاهای نویسندگان تا تاریخ 2026-08-10 نقل می‌کنیم. آن را روی کار خودتان تست کنید: همان وظیفه را دو بار اجرا کنید، یک بار به‌صورت ساده و یک بار با یک فایل گیت، سپس گیت‌هایی را بشمارید که با شواهدی که خودتان می‌توانید دوباره اجرا کنید، بسته شده‌اند. آن شمارش تنها عددی در این حوزه است که متعلق به شماست.

FAQ

Depth Tree در مهارت unlazy چیست؟

این یک روش تجزیه (decomposition) است. یک وظیفه در نقاط اتصال طبیعی خود در طول N لایه تقسیم می‌شود و تنها برگ‌های موجود در پایین‌ترین سطح به عنوان کار محسوب می‌شوند. این مهارت، یک برگ را به عنوان ده دقیقه یا بیشتر تلاش متمرکز با یک خروجی منسجم و یک فایل gates تعریف می‌کند؛ بنابراین اگر برگی دارید که می‌توانید در دو دقیقه تمام کنید، یعنی تقسیم‌بندی یک لایه بیش از حد عمیق انجام شده است. هر لایه بالاتر از برگ‌ها، مربوط به تجزیه و یکپارچه‌سازی است و هر شاخه، gates مخصوص به خود را دارد که ثابت می‌کند فرزندان با هم ادغام شده‌اند و رابط‌ها (interfaces) با هم مطابقت دارند. شما هنگام فراخوانی، عمق را انتخاب می‌کنید، برای مثال tree 5، و مقدار پیش‌فرض مستند شده، کوچک‌ترین عمقی است که برگ‌های آن واحدهای واقعی کار باشند.

آیا مهارت unlazy خارج از Claude Code کار می‌کند؟

تا حدی. این مهارت از نوع markdown ساده است، بنابراین Codex، Cursor و هر ابزاری که بتواند SKILL.md یا یک system prompt را بخواند، می‌تواند از Depth Tree، فایل gates، بررسی‌های قابل اجرا و چهار مرحله (pass) برای هر برگ استفاده کند. اعمال سخت‌گیرانه (Hard enforcement) متفاوت است. قلاب Stop که پایان یک نوبت را تا زمانی که gates برآورده نشده‌اند مسدود می‌کند، یکی از ویژگی‌های Claude Code است که با node <path-to-skill>/scripts/install-hooks.mjs نصب می‌شود. در هر جای دیگر، هیچ چیز ساختاری مانع از آن نمی‌شود که مدل نوبت خود را زودتر تمام کند، بنابراین شما کسی هستید که فایل gates را می‌خوانید و آن را بازمی‌گردانید.

مهارت unlazy چقدر به صورت‌حساب توکن من اضافه می‌کند؟

نویسندگان گزارش می‌دهند که این مهارت در حالت solo، بین 1.6 تا 3.9 برابرِ توکن‌های خروجی یک اجرای بدون مهارت، به علاوه چند صد توکن سربار برای خود فایل gates هزینه دارد. در مقایسه، عمیق‌تر شدن در یک context واحد تقریباً رایگان است، حدود 1.0 تا 1.5 برابر هنگام حرکت از درخت 3 به درخت 6. حالت orchestrated گران است، زیرا هر برگ یک context تازه می‌خرد که پیش از شروع کار، قرارداد و gates آن را دوباره می‌خواند. قلاب Stop هیچ هزینه‌ای اضافه نمی‌کند، زیرا فقط فایل‌ها را اسکن می‌کند. این ارقام متعلق به نویسندگان در تاریخ 2026-08-10 است و ما آن‌ها را تکرار نکرده‌ایم.

آیا باید از unlazy استفاده کنم یا ponytail؟

مهارت را با خطایی که پیش رو دارید مطابقت دهید. ponytail برای عاملی (agent) است که بیش از حد می‌نویسد، زیرا نقش یک توسعه‌دهنده ارشد را بازی می‌کند که می‌پرسد آیا کد واقعاً نیاز به وجود دارد یا خیر و ابتدا به سراغ کتابخانه استاندارد می‌رود. unlazy برای عاملی است که بخش کمی از آنچه خواسته‌اید را به پایان می‌رساند، زیرا تجزیه را اجباری می‌کند و تا زمانی که مدرکی ارائه نشود، از بستن یک gate خودداری می‌کند. اگر هر دو را می‌خواهید، ابتدا محدوده (scope) را با ponytail مشخص کنید، سپس آن محدوده را به unlazy بسپارید تا هرگز برای کاری که باید حذف می‌شده، ضریب تلاش پرداخت نکنید.

چرا عامل من پس از نصب unlazy همچنان زود متوقف می‌شود؟

چهار مورد را بررسی کنید. اول، تأیید کنید که مهارت با ls ~/.claude/skills/unlazy/SKILL.md روی دیسک قرار دارد، زیرا کلون کردن در دایرکتوری که وجود نداشته، خطای رایجی است. دوم، تأیید کنید که پیش از شروع کار، یک فایل gates نوشته شده است، زیرا قلاب، فایل‌های gates را اسکن می‌کند و نبود GATES.md باعث می‌شود چیزی برای مسدود کردن وجود نداشته باشد. سوم، تأیید کنید که قلاب کجا نصب شده است: اجرای ساده install-hooks.mjs فقط در settings.local.json همین پروژه می‌نویسد، بنابراین پروژه دیگر به --global نیاز دارد. چهارم، به یاد داشته باشید که سوپاپ اطمینان (release valve) طبق طراحی کار می‌کند، زیرا شش توقف مسدود شده متوالی بدون پیشرفت در gate، به عامل اجازه می‌دهد با یک هشدار ادامه دهد و یک خط ABANDON: <gate> <reason> به عمد تلاش را پایان می‌دهد.