🤖 مقدمه‌ای بر Skills، مهارت‌آموزی AI برای توسعه نرم‌افزار

با فراگیر شدن GenAI، تبِ چیزی که بعدتر وایب‌کدینگ اسم گرفت هم روز به روز داغ‌تر شد. لزوم ساختار دادن به تعامل توسعه‌دهنده و مدل زبانی، برای همین به تدریج فایل‌های prompts.md و بعدتر instructions.md و پشتیبانی از tools و MCPها به گیت‌هاب کوپالوت اومدن (قبلا در مورد همه این‌ها توی کانال نوشته‌ام). ولی همون‌طور که مدل‌ها پیشرفت کردن، ابزارها و ساختارهایی که کمک می‌کردن تا مدل‌ها رو بهتر به خدمتِ ساختاردهی توسعه دربیاریم هم پیشرفت کردن. مثلا فایلهای prompts.md با وجود کاربردی بودنشون، خیلی زود محدودیت‌هاشون رو نشون دادن، پس پشتیبانی از instructions.md و tools هم اضافه شد. ولی جای چند تا چیز خالی بود:

- دانش دائمی، به خصوص، و تکرارشونده
- پشتیبانی از ورژن
- فقط فایل markdown نباشه، بشه بهش مثال و منبع و... هم معرفی کرد. عین دوره آموزشی؛ ولی خیلی ساده‌تر و سرراست‌تر از RAG ساختن

پس برای همین skills به وجود اومد، ساختاری که مهارت به خصوص، مثل دانش مرور کدها برای عدم تخطی از اصول امنیتی مورد توافق تیم/سازمان. یا حتی مهارت ایجاد تغییرات لازم برای استفاده از ORM جدید به جای ORM فعلی یا... ولی اینبار:
- باید یک فولدر باشه
- حتماً فایل SKILL.md داشته باشه
- می‌تونه همراهش اسکریپت، مثال، الگو، منابع آموزشی، و تعریف workflow داشته باشه
- هدفش اینه که دانش تکرارشونده و procedural رو در قالبی قابل اشتراک و بارگذاری تعریف کنه
- این یعنی Skills از نظر قابلیت‌های عملیاتی و قابل استفاده مجدد خیلی جلوتر از فایل‌های markdown ساده هست

.github\skills
.agents\skills
.claude\skills
 

ولی Skills یک استاندارد متن‌باز و جامعه‌محوره که با مجوز Apache 2.0 توسط agentskills.io در دسترس عموم قرار داده شده؛ و چه Claude Code چه خانواده GitHub Copilot (plugin, CLI, SDK) و... ازش پشتیبانی می‌کنن و marketplaceهای به اشتراک‌گذاری skillها که زیاد شدن. به بیان خیلی ساده، Skill همون چیزیه که ما دوباره و دوباره می‌خوایم هوش مصنوعی انجام بده، ولی این بار در قالب یک بسته تعریف‌شده، نه پرامپت دستی.

🔧 ترکیب قابلیت‌ها: می‌تونین چند Skill رو با هم ترکیب کنین تا workflowهای پیچیده‌تر رو پوشش بدین.

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

🧠 مثال کاربردی:

فرض کنید هر بار که یک Pull Request در گیت‌هاب ایجاد می‌کنین، باید این کارها رو انجام بدید:
- اول چک کنه تیکت مرتبط با PR هر چی خواسته، توی تغییرات اومده و Acceptance criteria ها جا نیوفتاده از دست توسعه‌دهنده
- چک‌لیست امنیتی رو اجرا کنه
- تست‌های یکپارچه‌سازی رو بررسی کنه
- معیارهای کیفی رو حساب کنه
- خروجی رو گزارش بده

به جای اینکه هر بار با پرامپت اینها را توضیح بدید، می‌تونید یک Skill بسازید با یک فولدر شامل: .github/skills/pr-review/SKILL.md و در ضمن فایل‌های مثال و توضیح رو هم توی همین پوشه قرار بدید و توی فایل SKILL.md بگید ازشون استفاده کنه برای یاد گرفتن.
مثلا بنویسید:
- چه زمانی این Skill باید فعال بشه
- چه مراحلی رو باید انجام بده
- چه منابع یا چک‌لیست‌هایی همراه داشته باشه

بعدش هر ابزاری که از Agent Skills پشتیبانی کنه، مثل GitHub Copilot CLI یا Copilot coding agent، وقتی prompt مرتبط رو ببینه، این Skill رو بارگذاری و اجرا می‌کنه، بدون اینکه شما دوباره توضیح بدید.

🚀 چه چیزهایی می‌تونن به Skill تبدیل بشن؟
هر چیزی که تکرارشونده یا قابل استانداردسازی باشه:

- الگوی نوشتن مستندات (RFC، Arch review، design doc)
- چک‌لیست‌های Code Review
- ایجاد template برای Issue و Task
- گام‌های یونیت تست، تست یکپارچه‌سازی یا تست امنیت
- متدهای اتوماسیون workflowهای سازمانی
یا مثال‌های اینجا یا اینجا یا اینجا

وقتی یک Skill تعریف می‌کنید، ابزارهای مختلفی که از استاندارد پشتیبانی می‌کنن می‌تونن ازش بهره‌مند بشن و این یعنی دانش تیمی یا سازمانی رو قابل استفاده مجدد می‌کنین. Agent Skills داره تبدیل به استاندارد رایج برای تعریف توانایی‌های هوش مصنوعی میشه. این یعنی دیگه نیاز نیست هر بار از صفر به هوش مصنوعی بگید چه کار کنه. شما می‌تونید مراحل، چک‌لیست‌ها، اسکریپت‌ها و دانش خودتون رو در قالب Skill تعریف کنین و ابزارهای مختلف مثل Copilot اون‌ها را به صورت قابل استفاده مجدد بارگذاری کنن. این کار باعث می‌شه خروجی‌های هوش مصنوعی قابل پیش‌بینی‌تر، استانداردتر و کمتر وابسته به پرامپت دستی باشه.

💬 استفاده کردید؟ یا برای استفاده ازش برنامه‌ریزی کردید؟

💡 فرهنگ و ساختار نسخه‌دهی در تیم‌های نرم‌افزاری

انتخاب Gitflow یا Trunk-Based Development؟
انتخاب Monorepo یا Multirepo؟
انتخاب GitHub Flow یا GitLab Flow؟

به نظرم سؤال اصلی این نیست که «کدوم بهتره؟»
سؤال بهتر اینه که «هر کدوم برای حل چه مسئله‌ای ساخته شده؟»

خیلی از تیم‌ها مدل‌هایی رو از شرکت‌های بزرگ کپی می‌کنن، بدون اینکه همون سطح از CI/CD، تست، ownership، feature flag، release management و tooling رو داشته باشن. نتیجه‌اش هم معمولاً شلختگی، merge conflict، releaseهای پراسترس و کیفیت ناپایداره.

طی این دو پست، که پاسخی به سوال یکی از دوستان کانال است؛ به فرهنگ و ساختار نسخه‌دهی رو از چند زاویه بررسی کردم:

ساختار repository: شامل Monorepo، Multirepo، Microrepo
مدل‌های branching: شامل: Gitflow، GitHub Flow، GitLab Flow، Trunk-Based Development

و بعد ترکیب این‌ها در سناریوهای واقعی: مثل monolith، microservice، تیم کوچیک، چند تیم، SemVer، CalVer و چک‌لیست تصمیم‌گیری.
هدفم نسخه پیچیدن نیست؛ بیشتر اینه که انتخاب‌مون از روی شناخت باشه، نه تقلید.

🔗 بخش اول
🔗 بخش دوم

3