tier کردن مهارت: مدل چهار سطلی که 80+ مهارت ما را خارج از context نگه میدارد
افشای تدریجی به این معنی است که 80 مهارت میتوانند 3,200 توکن metadata، یا صفر، هزینه داشته باشند. اینجا میگوییم چگونه هر مهارت در مخزن Statnive را به always-on، auto-invocable، manual-only یا fork دستهبندی میکنیم — و آزمون یک سؤالی که برای تصمیم استفاده میکنیم.
چرا مهارتهای بیشتر نباید معنای context کمتر را بدهد
پیکربندی Claude Code Statnive بیش از 80 مهارت را بارگذاری میکند که مدیریت محصول، scaffolding بکاند، QA، ممیزی امنیتی، الگوهای خاص WordPress، بستهبندی release و موارد بیشتر را پوشش میدهد. framework که روی آن میسازیم (jaan.to) 141 عرضه میکند. خواندن ساده: مهارتهای بیشتر، سربار context بیشتر، فضای کمتر برای کار واقعی.
ریاضی واقعی جالبتر است. 80 مهارت میتوانند 3,200 توکن metadata دائمی، یا صفر، هزینه داشته باشند، بسته به اینکه هر یک چگونه پیکربندی شده باشد. تفاوت در مدل tier کردن چهار سطلی تعریف شده توسط سیستم مهارت Claude Code، و یک آزمون یک سؤالی منفرد برای انتخاب سطل درست است.
این پست از همه چهار سطل با توزیع واقعی مهارت Statnive، آزمونی که برای تصمیم استفاده میکنیم و سه چیزی که قبل از درست انجام دادن اشتباه کردیم عبور میکند.
افشای تدریجی: مکانیزم زیربنایی
قبل از اینکه مدل tier کردن منطقی بهنظر برسد، مکانیزم بارگذاری باید منطقی بهنظر برسد. Claude Code از سه لایه افشای تدریجی برای مهارتها استفاده میکند:
| لایه | چه چیزی بارگذاری میشود | چه زمان | هزینه |
|---|---|---|---|
| 1 — Metadata | YAML frontmatter name + description | همیشه در راهاندازی | حدود 30 تا 50 توکن به ازای هر مهارت |
| 2 — Body | محتوای کامل SKILL.md | وقتی مهارت فراخوانی میشود | Anthropic توصیه میکند حداکثر 500 خط / حدود 5 هزار توکن |
| 3 — منابع بستهبندی شده | اسکریپتهای ارجاع شده، templateها، مراجع | فقط وقتی دسترسی شد | صفر هزینه baseline |
این اهرمی است که مدل tier کردن استفاده میکند. لایه metadata تنها چیزی است که همیشه در context است. هر چیز دیگر on-demand است.
برای یک framework 141 مهارته، این 4,200 تا 14,100 توکن سربار دائمی برای metadata بهتنهایی است، که با تعداد مهارت بهصورت خطی مقیاس میشود. اگر توضیحات verbose باشند بزرگتر. اگر به مهارتهای خاص بگویید رجیستری metadata را بهطور کامل رد کنند، کوچکتر — یا صفر.
یک باگ مستند (Claude Code GitHub issue #14882) گزارش میدهد که برخی مهارتهای plugin ممکن است بدنه کامل خود را در راهاندازی به جای فقط frontmatter مصرف کنند. ما این را در خروجی /context خود تماشا میکنیم. اگر خط metadata مهارت شما اعداد بسیار بالاتر از حدود 50 توکن × تعداد مهارتهای auto-invocable شما را نشان دهد، به آن برخورد میکنید.
چهار سطل
هر مهارت در مخزن Statnive در یکی از چهار سطل قرار میگیرد. یک فیلد frontmatter تعیینکننده برای هر یک:
سطل 1 — Always-On (frontmatter پیشفرض)
---
name: simplify
description: Review changed code for reuse, quality, efficiency. Auto-fixes issues.
---اینها مهارتهای workflow اصلی هستند که مدل باید بهطور خودکار به آنها مسیریابی کند. frontmatter استاندارد — بدون flag خاص. metadata در راهاندازی بارگذاری میشود؛ بدنه در فراخوانی بارگذاری میشود.
مثالهای Statnive: simplify، statnive-release، statnive-release-zip. اینها در بیشتر کارهای مرتبط با release شلیک میکنند.
هزینه به ازای هر مهارت: حدود 40 توکن metadata بهطور دائم در context.
سطل 2 — Auto-Invocable (frontmatter پیشفرض، توضیح فشرده)
از منظر Claude Code همان پیکربندی Always-On. تمایز ویراستاری است: اینها مهارتهای دامنه هستند که فقط زمانی شلیک میکنند که کلمات کلیدی راهانداز آنها مطابقت داشته باشد. انضباط در نگه داشتن توضیح راهانداز-محور و کوتاه است.
---
name: wp-rest-api
description: Use when building REST endpoints in WordPress plugins.
---توضیح بد (همچنان کار میکند، بیشتر هزینه دارد):
description: A comprehensive skill for working with the WordPress REST API,
including endpoint registration, controller patterns, schema validation,
authentication, response shaping, and CPT/taxonomy exposure...توضیح خوب (بالا): 13 توکن. توضیح بد: 38 توکن. در 60+ مهارت auto-invocable، تفاوت تقریباً 1,500 توکن صرفهجویی metadata دائمی است.
مثالهای Statnive: wp-rest-api، wp-plugin-development، wp-performance، react-best-practices، wp-block-development، همه مهارتهای برنامهریزی jaan-to:*.
هزینه به ازای هر مهارت: حدود 30 تا 50 توکن metadata بهطور دائم در context.
سطل 3 — Manual-Only (disable-model-invocation: true)
---
name: statnive-emergency-rollback
description: Emergency-only rollback procedure for a botched deploy.
disable-model-invocation: true
---مهارت وجود دارد، slash command کار میکند (/statnive-emergency-rollback)، اما metadata هرگز وارد رجیستری <available_skills> نمیشود. Claude نمیداند آن وجود دارد مگر اینکه کاربر صریحاً آن را فراخوانی کند.
هزینه به ازای هر مهارت: 0 توکن. این سطل جادویی است.
چه زمانی استفاده شود: workflowهای نادر، عملیات مخرب، هر چیزی که نمیخواهید مدل به آن auto-routing کند. اگر علامتگذاری یک مهارت بهعنوان manual-only یک workflow را از اتمام جلوگیری کند، در سطلهای 1 یا 2 جای دارد.
مثالهای Statnive: rollback اضطراری، جراحی پایگاه داده دستی، اسکریپتهای مهاجرت یکبار مصرف، هر چیزی که «در صورت نیاز» وجود دارد اما نباید فرصتطلبانه شلیک کند.
ما تقریباً نیمی از مهارتهای خود را disable-model-invocation: true علامت میزنیم. در 80+ مهارت، این حدود 1,800 توکن metadata baseline بازیابی شده است — و کیفیت مسیریابی روی مهارتهای auto-invocable باقیمانده در واقع بهبود یافت، زیرا Claude بین تقریباً تکراریها انتخاب نمیکرد.
سطل 4 — Fork / Subagent (context: fork)
---
name: simplify
description: Review changed code for reuse, quality, efficiency. Auto-fixes issues.
context: fork
---حالت Fork مهارت را در یک context subagent ایزوله با تاریخچه مکالمه خود و پنجره 200 هزار توکنی خود اجرا میکند. خروجی کار خارج از پنجره context اصلی میماند. فقط یک خلاصه برمیگردد.
برای workflowهای خودکفا مثل بازبینی کد، ممیزی امنیتی و تحقیق چندمرحلهای، این تحولآفرین است. Anthropic مستند میکند subagentها حدود 500 تا 1,000 توکن از 10,000+ کار داخلی برمیگردانند — تقریباً یک کاهش 37% در context اصلی روی وظایف پیچیدهای که در آن subagent خواندن و پردازش قابلتوجهی انجام داد.
مثالهای Statnive: simplify (سه agent بازبینی موازی، خلاصه برمیگرداند)، jaan-to:backend-pr-review، jaan-to:sec-audit-remediate، jaan-to:detect-dev. هر چیزی که فایلهای زیادی میخواند و یک حکم برمیگرداند.
هزینه به ازای هر مهارت: حدود 40 توکن metadata، اما خود کار در ایزولاسیون اتفاق میافتد.
آزمون یک سؤال
چهار سطل مثل چهار تصمیم بهنظر میرسند. در واقع یک تصمیم هستند: آیا مکالمه اصلی نیاز به دیدن کار میانی مهارت دارد؟
| پاسخ | سطل |
|---|---|
| بله — مهارت کدی مینویسد که نشست اصلی به ویرایش آن ادامه خواهد داد | Always-on یا Auto-invocable |
| نه — مهارت یک حکم، خلاصه یا گزارش برمیگرداند | Fork / subagent |
| شاید — اما هرگز نباید auto-fire شود (نادر، مخرب، عجیب) | Manual-only |
اگر «نه»، context: fork تنظیم کنید. context اصلی شما تمیز میماند و میتوانید از Haiku 4.5 ($1/$5 به ازای MTok) برای کار خواندن سنگین subagent استفاده کنید در حالی که نشست اصلی از Sonnet یا Opus استفاده میکند. این یک برد هزینه 3 برابری بالای برد context است.
اگر «بله»، در سطلهای 1 یا 2 میرود. انتخاب بین Always-On و Auto-Invocable ویراستاری است: Claude چقدر مطمئن میتواند این را از نشانههای زبان طبیعی فعال کند؟ راهاندازهای قوی و بدون ابهام در Auto-Invocable میروند. workflowهایی که مدل باید در بیشتر نشستها در نظر بگیرد در Always-On میروند.
اگر مهارت وجود دارد اما هرگز نباید auto-fire شود، آن را Manual-Only علامت بزنید و هزینه metadata آن را بازیابی کنید.
توزیع واقعی مهارت Statnive
اینجا تجزیه فعلی ما در حدود 85 مهارت است:
| سطل | تعداد | هزینه کل metadata | یادداشتها |
|---|---|---|---|
| Always-On | 8 | حدود 320 توکن | Release، simplify، برنامهریزی sprint، بازبینی PR |
| Auto-invocable | 38 | حدود 1,520 توکن | مهارتهای دامنه با کلمات کلیدی راهانداز قوی |
| Manual-only | 32 | 0 توکن | فقط slash-command |
| Fork / subagent | 7 | حدود 280 توکن | بازبینی، ممیزی، detect |
| هزینه کل metadata | 85 | حدود 2,120 توکن | حدود 1% context |
بدون tier کردن — اگر همه 85 پیشفرض بودند — تقریباً 3,400 توکن metadata دائمی میپرداختیم. 32 مهارت manual-only بهتنهایی حدود 1,280 توکن صرفهجویی میکنند. در ایزولاسیون کوچک بهنظر میرسد؛ وقتی با کاهش CLAUDE.md و MCP Tool Search انباشته میشود اهمیت دارد.
محدودیتهای بدنه: چرا 500 خط عدد درست است
طرف metadata سربار دائمی است. طرف بدنه سربار به ازای هر فراخوانی است — و به همان اندازه برای کنترل مهم.
Anthropic توصیه میکند هر SKILL.md را زیر 500 خط (حدود 5 هزار توکن) نگه دارید. تحقیق روی بهینهسازی تهاجمی این را به یک سقف سخت 600 خط به ازای هر بدنه مهارت میبرد، با هر چیزی بالای آن نیازمند استخراج مرجع: templateها، چکلیستهای طولانی، مقایسههای چند-stack، کاتالوگهای ضد الگو را از SKILL.md به فایلهای جداگانه ارجاع شده از طریق اشارهگرهای واضح خارج کنید.
الگو به این شکل است:
.claude/skills/wp-plugin-development/
├── SKILL.md # 380 lines — execution core only
└── references/
├── activation-deactivation-patterns.md # Loaded only when needed
├── settings-api-patterns.md
├── nonce-and-capability-checklist.md
└── release-packaging-checklist.mdهسته اجرا فشرده و قطعی میماند. مراجع on demand بارگذاری میشوند، صفر توکن تا زمان دسترسی هزینه دارند. ما سه مهارت سنگینترین خود را به این روش بازسازی کردیم و حدود 12,000 توکن از بودجههای فراخوانی معمولی را قطع کردیم.
فیلد دیگر کنترل بدنه که ارزش استفاده دارد:
allowed-tools: ["Read", "Grep", "Glob"]این محدود میکند کدام ابزارها مهارت میتواند به آنها دسترسی داشته باشد، که هم سربار توکن و هم سطح اجرا را کاهش میدهد. مهارتی که فقط کد میخواند نباید دسترسی Write، Bash یا ابزار MCP داشته باشد — محدود کردن toolset، schema تزریق شده وقتی مهارت شلیک میکند را محدود میکند، و کلاسهای کامل رفتار تصادفی را حذف میکند.
آنچه سه بار اول اشتباه کردیم
ملاحظات صادقانه، همان الگوی بقیه سری:
- با توضیحات verbose شروع کردیم. اولین موج مهارتهای ما توضیحات 60+ توکنی بهینه شده برای خوانندگان انسانی داشت. کار میکردند، اما 2 برابر آنچه نیاز داشتند هزینه داشتند. چرخه کاهش یک حدود 1,400 توکن metadata را در سطل auto-invocable قطع کرد.
- سه مهارت داشتیم که کارهای مشابه انجام میدادند. سطل auto-invocable
pm-roadmap-add،pm-roadmap-updateوpm-sprint-planبا راهاندازهای متداخل داشت. مسیریابی شیر یا خط شد. ما تجمیع و راهاندازها را روشن کردیم. دقت مسیریابی بالا رفت؛ هزینه metadata پایین آمد. - مهارتهای سنگینی داشتیم که از حالت fork استفاده نمیکردند.
simplifyدر ابتدا inline اجرا میشد. 30+ فایل میخواند، سه پاس بازبینی اجرا میکرد و یک گزارش 2,000 توکنی برمیگرداند — همه آن کار داخلی context اصلی را آلوده میکرد. تغییر بهcontext: forkاستفاده context اصلی معمولی را حدود 9,000 توکن به ازای هر نشست release کاهش داد.
گام اندازهگیری
مثل بقیه سری: /context تشخیصی است. خطی که برای tier کردن مهارت تماشا میکنید آن است که تعداد توکن metadata مهارت را نشان میدهد. اهدافی که استفاده میکنیم:
| منبع | هدف | سقف سخت |
|---|---|---|
| metadata مهارت | حداکثر 2,500 توکن | 5,000 |
| تعداد مهارتهای auto-invocable | حداکثر 60 | — |
| هر بدنه SKILL.md منفرد | حداکثر 500 خط / حدود 5 هزار توکن | 600 خط / حدود 8 هزار توکن |
اگر خط metadata مهارت شما بسیار بالای 5 هزار توکن است و کمتر از 100 مهارت دارید، احتمالاً یا توضیحات verbose دارید (مشکل سطل 2) یا باگ بارگذاری که قبلاً ذکر کردیم را دارید (مشکل سطل 1).
این چگونه به بقیه Statnive متصل میشود
ما 141 آزمون واحد PHP در هر commit آزمون میکنیم. release ها قبل از عرضه هر نسخه از 31 بررسی انطباق عبور میکنند. مهارتهایی که همه آن را orchestrate میکنند — statnive-release، simplify، wp-plugin-development، تولیدکنندگان QA — در حدود 2,100 توکن metadata دائمی جا میگیرند. کار اتفاق میافتد، context تمیز میماند و تیم کوچک میماند.
مدل چهار سطلی یک تمرین آکادمیک نیست. دلیلی است که میتوانیم یک plugin تحلیلی WordPress زیر بودجه 5KB tracker را بدون یک تیم پنج نفره عرضه کنیم.
Statnive را امتحان کنید
تحلیلگری حریمخصوصیمحور WordPress، ساخته شده توسط تیمی که /context را بیشتر از /help اجرا میکند. Statnive را رایگان از WordPress.org نصب کنید — دادههای شما روی سرور شما باقی میماند، کتابخانه مهارت ما زیر بودجه توکن خود میماند.