«مهارت‌های سفارشی»؛ راهکار جدید برای حفظ بافت پروژه در مدل‌های زبانی

تصور کنید هر بار شروع به کدنویسی می‌کنید، ۱۰ دقیقه از زمانتان صرف توضیح دوباره‌ی وضعیت پروژه به هوش مصنوعی می‌شود. شما باید توضیح دهید که در پروژه کجا هستید، آخرین بار چه تغییراتی دادید و کدام بخش‌ها نیمه‌تمام مانده‌اند. شاید حتی مجبور باشید به مدل بگویید که یک Migration خاص را دست نزند. احتمالاً نسخه‌ای از این briefing را تا پنجاه بار تایپ کرده‌اید. Claude Code (نسخه ۲.۱.x) با معرفی دستورات سفارشی اسلش (Slash Commands)، این مقدمه‌های دستی و خسته‌کننده را حذف می‌کند تا مدل پیش از پردازش هر درخواست، آخرین وضعیت مخزن کد را به‌طور خودکار دریافت کند.

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

بسیاری از ما با پدیده‌ی «لغزش زمینه» (Context Drift) دست‌وپنجه نرم می‌کنیم؛ یعنی شکافی که بین حافظه‌ی مدل از جلسه‌ی قبل و وضعیت واقعی کد ایجاد می‌شود. همان‌طور که در تحلیل قبلی ما درباره‌ی رقابت KODA AI و Claude Code در بنچمارک‌های محاسباتی اشاره کردیم، کاربرد واقعی یک عامل (Agent) — شبیه به دستیاری که تمام جزئیات میز کار شما را می‌داند — کمتر به قدرت محاسباتی خام و بیشتر به بازدهی دسترسی به زمینه‌ی پروژه بستگی دارد. این تلاش برای انتقال حافظه و درک عمیق از پروژه، مشابه رویکردی است که در ابزارهایی مانند Coders Talk برای حفظ «چرایی» تصمیمات برنامه‌نویسان دیده می‌شود.

مکانیسم مهارت‌های سفارشی

به نقل از راهنمای فنی منتشر شده در ۹ اوت ۲۰۲۶، هسته‌ی این اتوماسیون دایرکتوری .claude/skills/ است. کاربران با ایجاد پوشه‌ای به نام دستور مورد نظر (مثلاً prime) و قرار دادن یک فایل SKILL.md در آن، دستور /prime را می‌سازند. نام پوشه مستقیماً نام دستور را تعیین می‌کند: برای مثال، پوشه‌ی prime به شما دستور /prime را می‌دهد.

Claude Code پوشه‌های مهارت را رصد می‌کند و هر مهارت جدید یا ویرایش شده را در لحظه‌ی ذخیره، شناسایی می‌کند و نیازی به ری‌استارت برنامه نیست. تنها یک استثنا وجود دارد: اگر در ابتدای شروع جلسه، پوشه‌ی .claude/skills/ وجود نداشته باشد، باید برنامه را یک بار ری‌استارت کنید تا رصد این پوشه آغاز شود. پس از آن، تمام ذخیره‌ها به‌صورت زنده اعمال می‌شوند.

این مهارت‌ها صرفاً میان‌برهای متنی نیستند، بلکه از «تزریق زمینه‌ی پویا» (Dynamic Context Injection) پشتیبانی می‌کنند. این قابلیت به عامل اجازه می‌دهد دستورات شل (Shell) را اجرا کرده و فایل‌ها را در لحظه بخواند. مستندات این فرآیند را به‌گونه‌ای توصیف می‌کنند که ابتدا دستور اجرا شده و خروجی آن در پرامپت درج می‌شود؛ بنابراین مدل به‌جای دریافت دستور «برو و اطلاعات را پیدا کن»، مستقیماً داده‌های واقعی را دریافت می‌کند (مستندات Claude Code: تزریق زمینه پویا و سینتکس دستورات اسلش).

• تزریق دستور: خطوطی که با ! شروع می‌شوند (مانند !git log --oneline -10) یک دستور شل را اجرا کرده و خروجی را مستقیماً در پرامپت وارد می‌کنند.
• درج فایل: خطوطی که با @ شروع می‌شوند (مانند @NOTES.md) محتوای کامل یک فایل خاص را به جلسه می‌کشند.

ساخت یک گزارش وضعیت زنده

یک دستور /prime حرفه‌ای معمولاً ترکیبی از این ابزارهاست تا یک گزارش وضعیت چهارخطی ارائه دهد. به‌جای یک جمله‌ی ایستا، یک گزارش زنده از بلوک YAML در ابتدای فایل (Frontmatter) برای تعریف رفتار خود استفاده می‌کند. این بلوک شامل description (متنی که در منو کنار دستور نمایش داده می‌شود) و argument-hint (راهنمای خاکستری که بعد از تایپ دستور ظاهر می‌شود) است.

به عنوان مثال، یک پیاده‌سازی قدرتمند می‌تواند به این شکل باشد:

description: Load where this project stands and print a short situation report
argument-hint: "[optional focus area]"
allowed-tools: Bash(git log *) Bash(git status *)

Recent work on this branch:
!git log --oneline -10
Branch and uncommitted right now:
!git status --short --branch
Current state notes, read in full:
@NOTES.md

Give me a four-line situation report: what branch I am on, what changed recently, what is unfinished, and what to pick up next. If I named a focus area ($ARGUMENTS), orient every line to it.

با تزریق git status --short --branch و یک فایل اختصاصی NOTES.md (که باید فایلی کوتاه برای وضعیت جاری باشد و نه تاریخچه‌ی کامل پروژه)، توسعه‌دهنده تضمین می‌کند که مدل دقیقاً می‌داند کدام شاخه فعال است و چه مواردی نیمه‌تمام مانده است. استفاده از $ARGUMENTS اجازه می‌دهد هدفمند عمل کنیم؛ مثلاً با تایپ /prime the auth refactor عبارت «the auth refactor» در جایگاه متغیر قرار گرفته و تمام گزارش روی بازسازی بخش احراز هویت متمرکز می‌شود.

کاربرد واقعی: گاوصندوق یادداشت‌ها

برای درک بهتر بازدهی این سیستم، پروژه‌ی بزرگی مانند یک «گاوصندوق یادداشت‌ها» (Notes Vault) را تصور کنید. قوانین این پروژه ایجاب می‌کند که پیش از هر تغییری، کاربر باید وضعیت خط لوله (Pipeline)، یادداشت‌های جاری (Working Briefing) و حیاتیات مخزن (Vault Vitals) را بخواند و بررسی کند که هیچ‌کدام قدیمی نشده باشند. پیش از این، کاربر باید سه فایل را باز می‌کرد و دستی بررسی می‌کرد که اطلاعات به‌روز باشند.

دستور /prime این فرآیند را خودکار می‌کند؛ تمام سه منبع را تزریق کرده و با یک درخواست خواندن به پایان می‌رساند. وقتی روی یک وضعیت زنده اجرا شود، می‌تواند گزارشی دقیق مانند این برگرداند:

۱. خط لوله: قرمز. یک هشدار قرمز (پس‌افت بررسی دانش) و دو هشدار زرد (پاک‌سازی هفتگی که ۱۲ روز تأخیر دارد و صف Staging که در حال پر شدن است).
۲. محدودیت اصلی: گلوگاه خروجی. ۶ مورد در انتظار ارسال، همگی بحرانی، که قدیمی‌ترین آن‌ها ۶۴ روز است. پیش از ساخت، ارسال کنید.
۳. جلسه قبل: تکمیل و ارسال اولین قطعه از یک سری جدید.
۴. گام بعد: آماده‌سازی یکی از قطعات ساخته‌شده و پارک‌شده برای انتشار.

هدف نهایی این است که وضعیت پروژه — تنها چیزی که واقعاً اهمیت دارد — و نقطه‌ی شروع، پیش از آنکه کاربر کلمه‌ای بگوید، اسمبل شده باشند.

مدیریت دسترسی‌ها و ابزارها

برای جلوگیری از توقف مدل و درخواست اجازه در هر بار اجرای دستور، کاربران می‌توانند allowed-tools را در YAML تعریف کنند. مثلاً مشخص کردن Bash(git log *) به عامل اجازه می‌دهد بدون وقفه در جریان کاری، لاگ‌ها را بخواند.

• تطبیق الگو: هر ورودی یک الگو است. Bash(git log *) یعنی هر دستوری که با git log شروع شود، بدون نیاز به تایید اجرا شود.
• محدودیت امنیتی: توصیه می‌شود دسترسی‌ها را محدود نگه دارید. دادن دسترسی کلی Bash(git *) می‌تواند دستورات خطرناکی مثل git push یا git reset را بدون تایید اجرا کند.
• محدودیت جلسه: این مجوزها فقط برای نوبتی (Turn) که /prime اجرا می‌شود معتبرند و با ارسال پیام بعدی پاک می‌شوند؛ بنابراین یک حفره امنیتی دائمی ایجاد نمی‌کنند.

یک نکته فنی (Wrinkle) مربوط به متغیرهای محیطی است. برای مثال، خطی که TZ='Europe/London' date را اجرا می‌کند، ممکن است به‌دلیل وجود TZ= در ابتدا، با پیشوند دستور تطبیق پیدا نکند. این باعث می‌شود در اولین اجرا، مدل باز هم درخواست اجازه کند. در چنین مواردی، ساده‌سازی دستور یا تایید یک‌باره‌ی آن راهکار است.

تفاوت مهارت‌ها با CLAUDE.md

تفاوت حیاتی میان این مهارت‌های پویا و فایل استاندارد CLAUDE.md وجود دارد. فایل CLAUDE.md برای حقایق پایدار — مثل معماری، قراردادهای کدنویسی و قوانین پروژه — طراحی شده است که در طول جلسات ثابت می‌مانند. این فایل به‌طور خودکار در هر جلسه بارگذاری می‌شود، به همین دلیل مکان مناسبی برای داده‌های متغیر (Volatile) نیست.

در مقابل، دستورات اسلش برای چیزهایی هستند که تغییر می‌کنند. لیست کامیت‌ها یا یک خط وضعیت، لحظه‌ای که نوشته می‌شوند قدیمی می‌شوند. با ذخیره کردن «رویهٔ بازیابی» (Procedure) به‌جای «خودِ داده»، توسعه‌دهنده تضمین می‌کند که هوش مصنوعی همیشه با حقیقت کار می‌کند. جای تعریف اینکه تست‌ها کجا هستند در CLAUDE.md است، اما اینکه آخرین بار چه چیزی را لمس کردید، چه چیزی کامیت نشده یا امروز صبح چه چیزی «در آتش می‌سوزد»، جایگاهش در دستور /prime است.

حفاظ‌ها و عیب‌یابی

بر اساس بررسی منابع متعدد، کاربران باید هنگام وارد کردن مهارت‌ها از مخازن خارجی محتاط باشند. چون این فایل‌ها می‌توانند دستورات شل اجرا کنند و ابزارهای خود را پیش‌تایید کنند، باید با همان دقتی بررسی شوند که یک اسکریپت اجرایی بررسی می‌شود. همیشه خطوط ! و allowed-tools را پیش از اجرا بخوانید. در این راستا، بررسی تاثیر هوک‌های امنیتی بر جلوگیری از نشت داده‌های حساس برای درک لایه‌های حفاظتی در محیط‌های محلی ضروری است.

همچنین مدیریت هزینه توکن (Token) ضروری است. هر چیزی که از طریق دستور اسلش تزریق شود، در تاریخچه گفتگو می‌ماند و در هر نوبت بعدی هزینه می‌کند. اگر دستور /prime تبدیل به یک دامپ کامل از پروژه شود، منجر به مصرف غیرضروری توکن‌ها می‌شود. اگر دستوری بیش از حد حجیم شد، زمان آن است که تعداد فایل‌های متصل را کاهش دهید.

اگر دستوری اجرا نشد، این موارد را بررسی کنید:

• دیده شدن: اگر در لیست / نیست، مطمئن شوید فایل دقیقاً در .claude/skills/prime/SKILL.md است. توجه کنید مهارت‌های موجود در ~/.claude/skills/ در تمام پروژه‌ها کار می‌کنند اما ممکن است راهنمای (Hint) آن‌ها در منو نمایش داده نشود.
• تجزیه (Parsing): یک بلوک YAML بدشکل باعث حذف مهارت نمی‌شود، اما متادیتا را خالی می‌کند. از Claude Code --debug برای دیدن خطاهای تجزیه و تراز کردن خطوط --- استفاده کنید.
• دسترسی‌ها: اگر در هر اجرا درخواست اجازه می‌کند، الگوی allowed-tools احتمالاً دقیقاً با پیشوند دستور تطبیق ندارد. پیشوند را دقیقاً تراز کنید (مثلاً Bash(git log *)).
• آرگومان‌ها: در مدل مهارت‌ها، آرگومان‌های ایندکس‌شده از صفر شروع می‌شوند ($0 اولی است، $1 دومی). از $ARGUMENTS برای دریافت کل متن تایپ شده استفاده کنید.
• سینتکس تزریق: مطمئن شوید دستور در یک بازه بک‌تیک با علامت ! در ابتدا قرار دارد. یک بلوک کد معمولی (Fenced block) به‌صورت متن ساده تلقی شده و اجرا نمی‌شود.

تکامل ساختار دستورات

در مستندات قدیمی‌تر ممکن است با فایل .claude/commands/prime.md (بدون پوشه) برخورد کنید. این ساختار قدیمی هنوز کار می‌کند و رفتار مشابهی دارد. با این حال، پوشه .claude/skills/ فرم توصیه شده فعلی است زیرا فضای رشد بیشتری دارد. یک پوشه می‌تواند اسکریپت‌های پشتیبان برای دستورات پیچیده را در خود جای دهد. همچنین مهارت‌ها می‌توانند توسط خودِ Claude فراخوانی شوند، مگر اینکه disable-model-invocation: true به Frontmatter اضافه شود تا دستور صرفاً دستی باقی بماند.

اثبات بارگذاری

برای تایید اینکه تزریق (Injection) عمل کرده است، /prime را اجرا کنید و ابتدای پاسخ را بخوانید. اگر مدل به پیام آخرین کامیت واقعی شما و فایل‌های واقعی‌تان اشاره می‌کند، دستورات اجرا شده و وضعیت واقعی است. اگر مدل توصیه‌های کلی می‌دهد که برای هر مخزنی صدق می‌کند، یعنی هیچ‌چیز تزریق نشده است؛ در این صورت خطوط ! یا @ را بررسی کنید. دستوری که فارغ از پروژه شما همیشه یک چیز ثابت چاپ می‌کند، صرفاً یک «جمله ذخیره شده» است، نه یک ابزار پویا.

این چرخش از پرامپت‌نویسی دستی به اتوماسیون رویه‌ای، نشان‌دهنده حرکت به سمت جریان‌های کاری «پایدار» (Durable) است. توسعه‌دهنده دیگر با مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — به‌مثابه یک چت ساده برخورد نمی‌کند، بلکه آن را محیطی می‌بیند که با API داخلی از دستورات قابل پیکربندی است. برای ایمن‌تر کردن این جریان‌ها، توسعه‌دهندگان باید به دنبال پیاده‌سازی حفاظ‌هایی باشند که مانع از ویرایش فایل‌های حساس توسط عامل‌ها شود تا بازیابی خودکار وضعیت منجر به خطاهای خودکار نشود.

گام بعدی شما

• دایرکتوری .claude/skills/ را بسازید و اولین دستور /prime خود را با تزریق git status تعریف کنید.
• یک فایل NOTES.md ساده برای ثبت وضعیت روزانه پروژه ایجاد کنید و آن را با @ به مهارت‌های خود متصل کنید.
• الگوهای allowed-tools را برای دستورات پرکاربرد git تعریف کنید تا سرعت گردش کارتان افزایش یابد.

اما برای امنیت بیشتر، باید حفاظ‌هایی تعریف کنید که مانع از ویرایش فایل‌های حساس توسط عامل‌ها شود — در تحلیل ما درباره‌ی Guardrails در سیستم‌های عامل‌محور بخوانید.