// سطح: helix-primary · سفارش 5

HelixSkills betaاجازه‌نامه: Apache-2.0

ShellGit submodulesModel Context ProtocolClaude Code pluginsReusable engines (continuum, token_optimizer)

منبع

HelixConstitution universal rules (submodule) HelixSkills mounts + cascades 7 Constitution skills 4 draft skills Reusable engines continuum · token_optimizer MCP tool servers Claude Code plugins HelixSkills — governance inheritance Rules cascade ↓ Skill catalog Universal rules reach every registered skill + consuming agent
// معماری

سامانه مهارت‌های مبتنی بر حاکمیت و قانون اساسی برای عامل‌های CLI AI

HelixSkills سامانه مهارت‌هایی برای عامل‌های CLI AI است که زیرمجموعه Helix Constitution را به ارث می‌برد، بنابراین تمامی قوانین حاکمیتی جهانی بدون قید و شرط اعمال می‌شوند. این سامانه مهارت‌های قابل نصب عامل‌ها، سرورهای ابزار MCP، افزونه‌های کد Claude و موتورهای قابل استفاده مجدد را در قالب یک کاتالوگ ثبت‌پذیر و مستند ارائه می‌دهد.

HelixSkills سامانه مهارت‌هایی برای عامل‌های CLI AI است. این سامانه Helix Constitution را به عنوان زیرمجموعه‌ای در خود جای داده تا تمامی قوانین جهانی اعمال شوند، سپس مهارت‌های ثبت‌پذیر (پیشوند عمل، اعتبارسنج رسانه، چندمسیره، همگام‌سازی جلسه، چرخه حیات آیتم قابل انجام و موارد دیگر)، دو سرور ابزار MCP، دو افزونه کد Claude و موتورهای قابل استفاده مجدد را ارائه می‌دهد.

HelixSkills (مخزن skills، پروانه آپاچی ۲.۰) سامانه مهارت‌هایی برای عامل‌های CLI AI است که با وارونه‌سازی عمدی ترتیب معمول آغاز می‌شود: حاکمیت در اولویت است و قابلیت‌ها در درجه دوم. این سامانه Helix Constitution را به عنوان زیرمجموعه constitution/ به ارث می‌برد، بنابراین تمامی قوانین جهانی موجود در constitution/CLAUDE.md و constitution/Constitution.md بدون قید و شرط اعمال می‌شوند — نه به عنوان عرفی که عاملی ممکن است به آن پایبند باشد، بلکه به عنوان مجموعه قوانینی که به صورت فیزیکی در ساختار پروژه گنجانده شده‌اند. عاملی که HelixSkills را به کار گیرد نمی‌تواند از قانون اساسی چشم‌پوشی کند؛ قوانین همراه با کد منتقل می‌شوند.

در حالی که بیشتر «چارچوب‌های مهارتی» بر مفاهیم انتزاعی تکیه دارند، HelixSkills فهرستی ملموس و ثبت‌پذیر ارائه می‌دهد که می‌توان به آن اشاره کرد و آن را نصب نمود. هفت مهارت قانون اساسی از طریق register.sh نصب می‌شوند: action-prefix-system، media-validator، multitrack، reporting-workable-items، scheduled-work-queue، session-sync و workable-item-lifecycle — طیف گسترده‌ای از مهارت‌های متوسط تا پیشرفته که از نام‌گذاری منظم اعمال گرفته تا اعتبارسنجی رسانه و چرخه کامل حیات یک واحد کاری را پوشش می‌دهد. مهارت‌های پیش‌نویس اضافی (مروری بر اندروید، زبان جاوا/Kotlin، سیستم‌عامل لینوکس) نیز از پیش فهرست‌بندی و آماده فعال‌سازی شده‌اند. دو سرور ابزار MCP (media-validator و scheduled-work) این مهارت‌ها را از طریق Model Context Protocol در اختیار عامل‌ها قرار می‌دهند، در حالی که دو افزونه کد Claude (helix و scheduled-work) همان قابلیت‌ها را مستقیماً در زمان اجرای عامل پیاده‌سازی می‌کنند — مجموعه‌ای واحد از مهارت‌ها که از طریق هر سطحی که عامل با آن تعامل دارد، قابل دسترسی است.

در زیر کاتالوگ، چهار موتور قابل استفاده مجدد با عمق یک قرار دارند — continuum (پیاده‌سازی شده)، به علاوه session_orchestrator، token_optimizer و clickup_sync (در حال طراحی) — که زیرساخت مشترک مورد نیاز مهارت‌ها را فراهم می‌کنند تا از اختراع مجدد همان لوله‌کشی جلوگیری شود. token_optimizer به تنهایی نمودار وابستگی صریحی را اعلام می‌کند که به بسته‌های اکوسیستم vasic-digital (TOON، Embeddings، VectorDB، Normalize، conversation) و LLMProvider متعلق به HelixDevelopment می‌رسد، بنابراین سیم‌کشی میان‌مخزنی آن قابل ممیزی است تا ضمناً تلویحی نباشد. در اطراف همه این‌ها مستندسازی منظمی وجود دارد: کاتالوگ مهارت‌ها، فهرست خودکار گراف مهارت‌ها، صفحات جزئیات هر مخزن و فهرست شفاف شکاف‌ها و ریسک‌ها که آنچه هنوز انجام نشده را مشخص می‌کند. کل این سامانه برای تاب‌آوری و دسترسی منطقه‌ای در GitHub، GitLab، GitFlic و GitVerse آینه‌سازی شده است.

محتوا

عامل‌های CLI و AI به قابلیت‌هایی نیاز دارند که یکپارچه، تحت نظارت و قابل استفاده مجدد باشند — نه اسکریپت‌های موقتی که هر بار قوانین را از نو ابداع کنند. HelixSkills برای این ساخته شد که به عامل‌ها مجموعه‌ای بسته‌بندی‌شده و قابل ثبت از مهارت‌ها بدهد که به یک قانون اساسی مشترک متصل است، تا رفتار در هر عامل و پروژه‌ای که آن را به کار می‌گیرد، یکسان و قابل ممیزی باقی بماند.

این سیستم قابلیت‌های عامل را از همان ابتدا قابل حمل و مطابق با قوانین می‌سازد، نه با تکیه بر انضباط فردی. هر مهارت یک واحد تحت نظارت، نسخه‌بندی‌شده و قابل نصب است که پشتوانه‌اش یک زیرمجموعه از قانون اساسی است — به این معنا که به محض ثبت یک مهارت توسط عامل، مجموعه قوانین استاندارد نیز به ارث می‌رسد، بدون هیچ فضایی برای انحراف. این امر چیزی را ممکن می‌سازد که پیش از این عملی نبود: انتقال یک قابلیت از یک عامل یا پروژه به دیگری با اطمینان از اینکه با همان چارچوب نظارتی وارد می‌شود، و از طریق سطوح استاندارد (سرورهای MCP و افزونه‌های کد Claude) در دسترس قرار می‌گیرد، نه انبوهی از اسکریپت‌های چسبنده سفارشی که هر بار قوانین را از نو تعریف می‌کنند.

  • Constitution به‌عنوان زیرمجموعه: قوانین نظارتی جهانی به ارث می‌رسند، نه کپی می‌شوند — در ساختار درختی سوار می‌شوند تا هر عامل مصرف‌کننده به همان مجموعه قوانین استاندارد متصل باشد، و به‌روزرسانی‌ها از یک منبع واحد جریان یابند، نه از ده‌ها کپی منسوخ.
  • مهارت‌ها به‌عنوان واحدهای خودثبت‌شونده (register.sh) و دوخته‌شده در فهرست گراف مهارت‌های خودکار: کاتالوگ همیشه قابل کشف باقی می‌ماند و هرگز با آنچه واقعاً نصب شده همگام نمی‌شود.
  • در معرض قرارگیری چندسطحی: مجموعه مهارت‌های یکسان از طریق سرورهای ابزار MCP و افزونه‌های کد Claude به عامل‌ها می‌رسد — یک بار بنویسید، با هر محیط اجرایی که عامل استفاده می‌کند ارتباط برقرار کنید.
  • موتورهای قابل استفاده مجدد سطح اول (continuum، token_optimizer، session_orchestrator، clickup_sync) که در سراسر اکوسیستم به اشتراک گذاشته می‌شوند، هر یک با اعلام وابستگی‌های صریح و قابل ممیزی بین مخازن، نه اتصال‌های پنهان.

  • حفظ رفتار یکسان و مطابق با قوانین عامل‌ها در میان مهارت‌ها و عامل‌های متعدد — پیاده‌سازی نظارت برای هر مهارت به مرور زمان باعث واگرایی می‌شود. راه‌حل این بود که Helix Constitution را به‌عنوان زیرمجموعه سوار کنیم تا قوانین موجود در constitution/CLAUDE.md و constitution/Constitution.md بدون قید و شرط اعمال شوند و از یک منبع بالادستی به‌روزرسانی شوند، نه اینکه کپی شوند و رها گردند.
  • قابل نصب و کشف‌پذیر کردن مجموعه‌ای رو به رشد از مهارت‌ها — کاتالوگی که کسی نتواند آنچه در آن است را پیدا یا نصب کند، بی‌ارزش است. راه‌حل ما ثبت هر مهارت با register.sh در زمان نصب بود، به علاوه یک گراف مهارت‌های خودکار INDEX و مستندات جزئیات هر مخزن، تا کشف‌پذیری همیشه با واقعیت همگام باشد.
  • دسترسی به عامل‌هایی که با محیط‌های اجرایی مختلف کار می‌کنند — نباید یک قابلیت برای هر میزبان از نو ساخته شود. راه‌حل این بود که یک مجموعه مهارت را هم در پشت تعریف‌های سرور ابزار MCP (در constitution/mcp/) و هم افزونه‌های کد Claude (در constitution/plugins/) بسته‌بندی کنیم، تا یک پیاده‌سازی واحد در سطوح مختلف در معرض دید قرار گیرد.

محتوا

  • Shell (زبان اصلی) — انتخاب شده زیرا ابزارهای نصب و ثبت باید در هر جایی که عامل وجود دارد اجرا شوند، بدون نیاز به راه‌اندازی اولیه محیط زمان اجرا؛ این زبان اسکریپت‌های register.sh و install_upstreams را قدرت می‌بخشد و مسیر ورود را بدون وابستگی و قابل حمل نگه می‌دارد.
  • زیرماژول‌های گیت — انتخاب شده برای به ارث بردن حاکمیت بدون تکرار: Helix Constitution در مسیر constitution/ به عنوان مرجع زنده سوار می‌شود، بنابراین به‌روزرسانی‌های قوانین از طریق یک اشاره‌گر منتشر می‌شوند، نه با کپی‌پیست و فراموشی.
  • Model Context Protocol (MCP) — به عنوان رابط استاندارد و مستقل از محیط زمان اجرا برای عامل‌ها انتخاب شده است؛ دو سرور MCP (media-validator و scheduled-work) در مسیر constitution/mcp/ تعریف شده‌اند تا مهارت‌ها را به عنوان ابزارهای قابل فراخوانی در دسترس قرار دهند.
  • پلاگین‌های کد Claude — انتخاب شده برای پیاده‌سازی مستقیم مهارت‌ها در محیط زمان اجرای عامل بدون نیاز به کد چسبنده؛ دو پلاگین (helix و scheduled-work) در مسیر constitution/plugins/ عرضه می‌شوند که سطح MCP را برای میزبان دیگری بازتاب می‌دهند.
  • موتورهای قابل استفاده مجدد (continuum، token_optimizer، session_orchestrator، clickup_sync) — انتخاب شده برای استخراج ماشین‌آلات مشترک از مهارت‌های جداگانه به منظور استفادهٔ متقابل در پروژه‌ها؛ به عنوان مثال، token_optimizer به بسته‌های vasic-digital (TOON، Embeddings، VectorDB، Normalize، conversation) و HelixDevelopment's LLMProvider از طریق وابستگی‌های اعلام‌شده متصل می‌شود، نه با کد تکراری.
  • آینه‌سازی گیت چند میزبان (GitHub، GitLab، GitFlic، GitVerse) — انتخاب شده تا قطع دسترسی در اثر خرابی یک میزبان یا مسدودسازی منطقه‌ای غیرممکن شود؛ همان مخزن در چهار فورژ مختلف به صورت زنده نگهداری می‌شود تا تاب‌آوری و دسترسی تضمین شود.

  • وضعیت: بتا. هفت مهارت قانون اساسی، دو سرور MCP و دو پلاگین عرضه شده‌اند؛ مهارت‌های پیش‌نویس فهرست شده و در انتظار فعال‌سازی هستند و سه موتور از چهار موتور سطح اول (session_orchestrator، token_optimizer، clickup_sync) هنوز در مرحله طراحی قرار دارند.
  • فایل README این پروژه را با نام helix_skills معرفی می‌کند؛ مسیر استاندارد GitHub برابر با HelixDevelopment/skills است. شمارهٔ یافته‌های ثبت‌شده در README بر اساس گزارش خود پروژه است.

اولویت: Helix-اصلی.