۹ اصل نوشتن یک اسکیل حرفه‌ای برای Claude و Codex
بیشتر اسکیل‌ها یا هیچ‌وقت اجرا نمی‌شوند یا نتیجه‌ی ثابتی نمی‌دهند. این ۹ اصل، از راهنمای رسمی Anthropic و تجربه‌ی ساختن اسکیل‌های واقعی، اسکیل شما را قابل‌اعتماد می‌کند.
نوشتن یک اسکیل ساده است؛ یک پوشه و یک فایل متنی. نوشتن اسکیلی که هر بار درست کار کند، کار دیگری است. بیشتر اسکیل‌هایی که در مخزن‌های عمومی می‌بینید یکی از این دو مشکل را دارند: یا دستیار هیچ‌وقت سراغشان نمی‌رود، یا هر بار نتیجه‌ی متفاوتی می‌دهند.
این ۹ اصل را از راهنمای رسمی نوشتن اسکیل Anthropic و تجربه‌ی ساختن اسکیل‌هایی که خودم هر روز استفاده می‌کنم جمع کرده‌ام. اگر هنوز نمی‌دانید اسکیل چیست، اول راهنمای کامل اسکیل را بخوانید.
۱. توضیح را برای کشف شدن بنویسید
دستیار قبل از باز کردن هر اسکیل، فقط نام و توضیح آن را می‌بیند. پس توضیح در عمل تبلیغ اسکیل برای خود دستیار است. توضیح خوب دو چیز می‌گوید: اسکیل چه می‌کند و کی باید از آن استفاده شود. کلماتی که کاربر واقعاً به کار می‌برد هم باید در آن باشد.
دو نکته‌ی ظریف از راهنمای رسمی:
- توضیح را سوم‌شخص بنویسید («Processes Excel files…»)، نه «من کمک می‌کنم» یا «شما می‌توانید». این متن مستقیم وارد دستور سیستمی دستیار می‌شود و تغییر زاویه‌ی دید، کشف اسکیل را خراب می‌کند.
- اگر کاربرانتان فارسی حرف می‌زنند، کلمات فارسی را هم در توضیح بیاورید؛ مثلاً «نیم‌فاصله» یا «پوستر». دستیار درخواست فارسی را با همین کلمات به اسکیل وصل می‌کند.
۲. فقط چیزی را بنویسید که مدل نمی‌داند
راهنمای Anthropic این را صریح می‌گوید: فرض پیش‌فرض این است که مدل از قبل خیلی باهوش است. توضیح این‌که PDF چیست یا چرا کد تمیز مهم است، فقط حافظه‌ی گفتگو را هدر می‌دهد. هر پاراگراف را با یک سؤال بسنجید: «آیا مدل واقعاً به این نیاز دارد؟»
چیزی که مدل نمی‌داند دانش خاص شماست: قواعد دیزاین‌سیستمتان، اشتباه‌هایی که بارها دیده‌اید، استانداردی که تیم رویش توافق کرده و ترتیبی که کارها باید انجام شوند.
۳. آزادی را به‌اندازه‌ی شکنندگی کار بدهید
همه‌ی کارها یک‌جور دستورالعمل نمی‌خواهند. راهنمای رسمی تشبیه خوبی دارد: بعضی کارها دشت بازند و بعضی پل باریک با پرتگاه در دو طرف.
- آزادی زیاد برای کارهای خلاق، مثل بازبینی کد یا پیشنهاد ایده: چند اصل و معیار کافی است.
- آزادی متوسط برای کارهایی که الگوی مشخص دارند: یک قالب یا شبه‌کد بدهید.
- آزادی کم برای کارهای شکننده، مثل مهاجرت دیتابیس یا ساخت فایل نهایی: «دقیقاً همین اسکریپت را اجرا کن و پارامتری اضافه نکن.»
۴. SKILL.md کوتاه، جزئیات در فایل‌های جدا
متن اصلی SKILL.md را زیر ۵۰۰ خط نگه دارید. جزئیات را در پوشه‌ی references/ بگذارید و در متن اصلی بگویید کی هر فایل را بخواند:
برای جزئیات خطاهای API، references/api-errors.md را بخوان
(فقط اگر پاسخ API کد ۲۰۰ نبود).دو قاعده‌ی مهم این‌جا: ارجاع‌ها فقط یک سطح عمق داشته باشند (فایلی که به فایل دیگری ارجاع می‌دهد که به فایل سومی…) چون مدل ممکن است فایل‌های تودرتو را ناقص بخواند. و فایل‌های مرجع بلندتر از ۱۰۰ خط، یک فهرست مطالب در ابتدا داشته باشند.
۵. برای کارهای شکننده اسکریپت بنویسید، نه توضیح
اگر قرار است مدل هر بار یک SVG را از نظر شبکه و ضخامت خط بررسی کند، توضیح دادن قواعد کافی نیست؛ یک اسکریپت بررسی بنویسید. اسکریپت سه مزیت دارد: نتیجه‌ی ثابت می‌دهد، حافظه‌ی گفتگو را مصرف نمی‌کند (فقط خروجی‌اش خوانده می‌شود) و قابل‌تست است.
اسکریپت خوب مشکل را خودش حل می‌کند و به مدل پاس نمی‌دهد: خطای واضح برمی‌گرداند، حالت‌های مرزی را مدیریت می‌کند و هیچ عدد جادویی بی‌توضیح ندارد.
۶. یک پیش‌فرض بدهید، نه یک فهرست گزینه
«می‌توانی از کتابخانه‌ی الف، ب، ج یا د استفاده کنی» مدل را سردرگم می‌کند و نتیجه را غیرقابل‌پیش‌بینی. یک گزینه‌ی پیش‌فرض بدهید و فقط یک راه فرار: «از الف استفاده کن؛ اگر فایل اسکن‌شده بود، ب.»
یک استثنای مهم دارد: وقتی سلیقه‌ی کاربر تعیین‌کننده است، مثل سبک طراحی یک پوستر، اسکیل نباید به‌جای کاربر انتخاب کند. اسکیل پوستر ما برای همین قبل از کار نهایی سه مسیر طراحی متفاوت می‌سازد و از کاربر می‌پرسد کدام را ادامه بدهد.
۷. اول ارزیابی، بعد مستندات
این اصل از همه کمتر رعایت می‌شود و از همه مهم‌تر است. قبل از نوشتن دستورالعمل مفصل، دست‌کم سه سناریوی آزمون بنویسید: درخواست واقعی کاربر و این‌که خروجی درست چه ویژگی‌هایی دارد.
بعد کار را یک بار بدون اسکیل اجرا کنید و ببینید مدل کجا واقعاً اشتباه می‌کند. حالا فقط برای همان شکاف‌ها دستورالعمل بنویسید. این روش جلوی بزرگ‌ترین اشتباه را می‌گیرد: نوشتن صفحه‌ها توضیح برای چیزهایی که مدل از قبل بلد بود.
۸. با همه‌ی مدل‌هایی که استفاده می‌کنید تست کنید
اسکیلی که با یک مدل قوی عالی کار می‌کند، ممکن است با مدل سبک‌تر راهنمایی کم داشته باشد. راهنمای رسمی پیشنهاد می‌کند با هر سه سطح مدل تست کنید: آیا مدل سبک به‌اندازه‌ی کافی راهنمایی دارد؟ آیا مدل قوی با توضیح اضافه کند نمی‌شود؟
اگر اسکیلتان روی چند ابزار اجرا می‌شود، روی همه‌شان امتحانش کنید. قالب فایل مشترک است، ولی رفتار ابزارها در اجرای اسکریپت و دسترسی به شبکه فرق دارد.
۹. با استفاده‌ی واقعی بهترش کنید
بهترین اسکیل‌ها در چرخه ساخته می‌شوند: اسکیل را روی کار واقعی اجرا کنید، ببینید مدل کجا راه را اشتباه رفت، کدام فایل را نخواند یا کدام قاعده را نادیده گرفت، و همان نقطه را اصلاح کنید. راهنمای رسمی این را با دو نمونه از Claude توضیح می‌دهد: یکی اسکیل را می‌نویسد و اصلاح می‌کند، دیگری بدون اطلاع قبلی با آن کار می‌کند تا ضعف‌ها معلوم شود.
چک‌لیست نهایی
قبل از انتشار یک اسکیل، این‌ها را بررسی کنید:
- توضیح می‌گوید اسکیل چه می‌کند و کی استفاده شود، با کلمات کاربر و سوم‌شخص.
- متن اصلی زیر ۵۰۰ خط است و جزئیات در فایل‌های جدا با یک سطح ارجاع.
- کارهای شکننده اسکریپت دارند و اسکریپت‌ها خطای واضح برمی‌گردانند.
- دست‌کم سه سناریوی ارزیابی نوشته و اجرا شده است.
- مسیر فایل‌ها با
/نوشته شده، نه\؛ حتی روی ویندوز. - با مدل‌ها و ابزارهایی که استفاده می‌کنید تست شده است.
اگر می‌خواهید این فرایند را به خود دستیار بسپارید، اسکیل ساختن اسکیل دقیقاً همین قدم‌ها را با شما جلو می‌برد: از مصاحبه و نوشتن سناریو تا ساختن، ارزیابی و بهبود.
طراح محصول و سازنده‌ی دیزاین‌سیستم کاشی. سایت‌های زیادی را با هوش مصنوعی ساخته‌ام و چند سال اخیر روی ایجنتیک کردن فرایندهای هوش مصنوعی کار کرده‌ام. اسکیل‌های این سایت همان‌هایی‌اند که خودم هر روز با آن‌ها کار می‌کنم.
بیشتر درباره‌ی منچیزی که خواندید را همین امروز به دستیارتان بدهید
همه‌ی این اسکیل‌ها با لایسنس دائمی، به‌روزرسانی رایگان برای همیشه و راهنمای نصب برای همه‌ی ابزارها.
اسکیل‌ساز حرفه‌ای
اسکیلی برای ساختن اسکیل؛ از مصاحبه و eval تا نوشتن، اعتبارسنجی و بسته‌بندی، برای Claude، Codex، Cursor و Gemini.
طراحی پوستر و بنر شبکه‌های اجتماعی
پوستر تلگرام، پست و استوری اینستاگرام، تصویر لینک و بنر سایت با تایپوگرافی فارسی بی‌نقص؛ اول چند ایده، بعد طرح نهایی.