مرکزی مواد پر جائیں
اے آئی ٹیوٹوریلز

MuseAI-Skills پڑھنے کا رہنما: Muse AI کی مہارتوں، اجازتوں اور Agent ورک فلو کا تجزیہ

یہ رہنما MuseAI-Skills حاصل کرنے اور انہیں محفوظ طریقے سے پڑھنے، مہارتوں کی تعریف، کنیکٹر کی اجازتوں، جائزے کے منظرناموں اور رن ٹائم ماحول کی اسکرپٹس کو سمجھنے کا طریقہ بتاتا ہے۔ Gmail جیسی مہارتوں کی مثال سے دوبارہ قابلِ استعمال Agent ورک فلو کے تجزیے کا طریقہ بھی سکھایا گیا ہے۔

تقریباً 34 منٹ کا مطالعہ
MuseAI-Skills پڑھنے کا رہنما: Muse AI کی مہارتوں، اجازتوں اور Agent ورک فلو کا تجزیہ

پروجیکٹ کیا ہے

MuseAI-Skills، muse.ai سے متعلق Muse / Hatch ذاتی AI Agent ماحول کا ایک snapshot ہے۔ اس repository میں مصنوعات کی وضاحتیں، skill definitions، connector permissions کی فہرستیں، رویّوں کی evaluation scenarios، Linux runtime scripts، اور package کے ساتھ فراہم کیے گئے کچھ پروگرام اور dependencies محفوظ ہیں۔

اہم حد: یہ مکمل source code repository نہیں ہے اور نہ ہی one-click deployment package ہے۔ بنیادی پروگرام زیادہ تر Linux x86-64 ELF binaries کی صورت میں فراہم کیے گئے ہیں، جبکہ build source، مکمل host configuration، rootfs اور runtime resources کا کچھ حصہ شامل نہیں ہے۔

لہٰذا یہ repository static reading، Agent workflow research، permission model analysis اور instruction design کے حوالے کے طور پر زیادہ موزوں ہے، نہ کہ Muse AI service کو براہِ راست install کرنے کے لیے۔ repository کے مواد میں Muse، Hatch اور Jarvis جیسے نام استعمال ہوئے ہیں، لیکن archive خود کسی official release، endorsement یا source authentication کی نمائندگی نہیں کرتا۔

آپ repository سے کیا سیکھ سکتے ہیں

Skill workflow کی مکمل ساخت

repository میں SKILL.md کے 72 paths شامل ہیں، جن میں 68 منفرد skill files اور 4 symbolic-link aliases ہیں۔ skills میں Agent workflows، document artifacts، travel booking، office tools، social platforms، health data، media generation، device control اور Muse products کے operations جیسے شعبے شامل ہیں۔

یہ skill documents عموماً آپ کو درج ذیل سوالات کا مطالعہ کرنے میں مدد دیتے ہیں:

  • کون سی user request کو skill trigger کرنا چاہیے۔
  • کسی task کو coordinator، worker یا external connector میں سے کون handle کرے۔
  • execution سے پہلے کن account connections، OAuth scopes یا user authorizations کی ضرورت ہے۔
  • tool failure، نامکمل input یا ناکافی permissions کی صورت میں کس طرح fallback کیا جائے۔
  • output format کیسے متعین کیا جائے اور آخری deliverable کی verification کیسے کی جائے۔

Permissions اور evaluation materials

repository میں مزید 40 manifest paths اور 12 eval YAML files موجود ہیں۔ manifest.yaml connector metadata، default permissions، scope requirements اور command mappings کو سمجھنے کے لیے استعمال کیا جا سکتا ہے؛ جبکہ eval/scenarios.yaml behavioral evaluation scenarios، user goals اور expected behavior کو ریکارڈ کرتا ہے۔

نوٹ: manifest کا موجود ہونا اس بات کی علامت نہیں کہ account پہلے ہی connected ہے، اور evaluation scenarios کا موجود ہونا اس بات کی علامت نہیں کہ evaluation چلائی یا پاس کی جا چکی ہے۔

Runtime environment کے static clues

opt/hatch/runtime-cell/ میں موجود scripts runtime environment کے lifecycle کے کچھ حصے دکھاتی ہیں، جن میں rootfs path resolution، startup preparation، kernel module checks، systemd-nspawn container startup، اور skills اور binaries کے overlays کی assembly شامل ہیں۔ تاہم مکمل host units، nspawn configuration اور اصل rootfs repository میں موجود نہیں ہیں۔

Directory structure کا جائزہ

  • README.md: چینی entry point، skill directory اور حدود کی وضاحت۔
  • README.en.md: انگریزی entry point۔
  • PROJECT_ANALYSIS.md: architecture assessment، missing components، risks اور evidence index۔
  • SHA256SUMS: عام files کے content checksums کی فہرست، لیکن source signature نہیں۔
  • home/hatch/docs/: product، connector، privacy، scheduling، files، devices اور media وغیرہ کی وضاحتیں۔
  • home/hatch/config/: Agent اور skill state سے متعلق configuration۔
  • opt/hatch/skills/: skill entry points، permission manifests، evaluation scenarios اور reference materials۔
  • opt/hatch/runtime-cell/: runtime environment lifecycle scripts اور configuration templates۔
  • opt/hatch/bin/: Hatch سے متعلق programs۔
  • opt/hatch-image/: image-side tools، npm، Bun اور package کے ساتھ فراہم کیے گئے دیگر components۔

repository کی root directory صرف archive کی root directory ہے، یہ چل رہے Linux system کی root directory نہیں۔ archive میں موجود home/hatch/ اصل environment کے /home/hatch سے مطابقت رکھتا ہے، جبکہ documents میں موجود /run، /var/lib اور /etc عموماً ان runtime filesystems کی طرف اشارہ کرتے ہیں جو موجود نہیں ہیں۔

Repository حاصل کرنا اور تیار کرنا

طریقہ اول: صرف skills اور documents کا مطالعہ

اگر مقصد Markdown، YAML اور Shell scripts کا analysis ہے تو بڑی Git LFS binaries کو download کیے بغیر کام کیا جا سکتا ہے۔ یہ reading کے لیے سب سے زیادہ تجویز کردہ طریقہ ہے۔

GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/win4r/MuseAI-Skills.git
cd MuseAI-Skills

اس طریقے میں package کے ساتھ فراہم کیے گئے programs چلانے کی ضرورت نہیں۔ repository میں داخل ہونے کے بعد پہلے PROJECT_ANALYSIS.md اور opt/hatch/skills/ کھولیں۔

طریقہ دوم: مکمل archive objects دیکھنا

Git LFS میں موجود ELF programs یا دیگر بڑی files کی جانچ کی حقیقی ضرورت ہو تو ہی Git LFS install کرکے متعلقہ objects حاصل کریں۔ binaries download کرنے سے missing source code، rootfs، credentials یا host configuration مکمل نہیں ہوتی، اور repository deployable system میں تبدیل نہیں ہوتی۔

git clone https://github.com/win4r/MuseAI-Skills.git
cd MuseAI-Skills
git lfs pull

جن binaries کے source کی آزادانہ تصدیق نہیں ہوئی، ان کے لیے پہلے offline static inspection کریں؛ انہیں production machine یا حساس credentials والے environment میں براہِ راست نہ چلائیں۔

عام files کی verification

متعلقہ files مکمل طور پر حاصل کرنے کے بعد content integrity کی جانچ کے لیے repository کی فراہم کردہ SHA256SUMS استعمال کی جا سکتی ہے:

sha256sum -c SHA256SUMS

checksum list خود list file اور symbolic links کو cover نہیں کرتی، اور نہ ہی یہ publisher identity یا source authenticity کی cryptographic signature ہے۔ یہ صرف یہ جانچنے میں مدد دیتی ہے کہ مقامی عام files کے digests فہرست میں درج digests سے مطابقت رکھتے ہیں یا نہیں۔

بنیادی استعمال: Skill reading workflow قائم کرنا

پہلا قدم: ایک skill entry point منتخب کریں

ابتدائی مطالعے کے لیے درج ذیل skills سے شروع کیا جا سکتا ہے:

  • wide-research: research coordinator، workers، unified output contract اور failure coverage۔
  • skill-creator: skill trigger descriptions، directory splitting اور on-demand reference loading۔
  • artifacts/testing: “generation successful” اور “deliverable usable” کے درمیان فرق۔
  • goals: پہلی بار goal قائم کرنے اور subsequent follow-up میں فرق۔
  • forget: copies، derived state اور ممکنہ طور پر واپس لکھے جانے والے data سے نمٹنا۔
  • travel-planning: itinerary research، real-time queries اور transaction execution کو الگ کرنا۔
  • gmail: connector کا analysis کرنے کے لیے skill body، method-level permissions اور evaluation scenarios کو یکجا کرنا۔

مثلاً Gmail skill entry point دیکھیں:

sed -n '1,240p' opt/hatch/skills/gmail/SKILL.md

دوسرا قدم: Trigger conditions اور boundaries اخذ کریں

SKILL.md پڑھتے وقت صرف یہ ریکارڈ نہ کریں کہ “یہ کیا کر سکتا ہے”، بلکہ ترتیب سے درج ذیل سوالات کے جواب بھی دیں:

  1. کن requests کو اس skill کو trigger کرنا چاہیے؟
  2. کن ملتی جلتی requests کو trigger نہیں کرنا چاہیے؟
  3. Read-only operations اور write operations میں فرق کیسے کیا جائے؟
  4. کیا send، delete، purchase یا booking جیسی high-impact operations کے لیے confirmation درکار ہے؟
  5. ناکافی permissions، مبہم target یا tool failure کی صورت میں کیا کرنا چاہیے؟
  6. حتمی نتیجے میں کن fields یا evidence کو واپس کرنا ضروری ہے؟

ان نکات کو “trigger، input، authorization، execution، failure، acceptance” کے چھ حصوں میں منظم کریں، تاکہ انہیں اپنے Agent design میں منتقل کرنا آسان ہو۔

تیسرا قدم: Permission manifest کے ساتھ موازنہ کریں

Connector skills کے لیے اسی directory میں موجود manifest.yaml بھی پڑھیں:

sed -n '1,260p' opt/hatch/skills/gmail/manifest.yaml

Skill body میں بیان کردہ operations کا manifest میں اعلان کردہ method permissions، group defaults، scopes اور command mappings کے ساتھ موازنہ کریں۔ Method-level settings group defaults کو override کر سکتی ہیں، اس لیے صرف top-level permission description دیکھنا کافی نہیں۔

کسی SKILL.md کو دوسرے Agent environment میں copy کرنے سے Gmail، Google Drive، Notion یا دیگر services تک access خود بخود حاصل نہیں ہو جاتا۔ حقیقی execution اب بھی متعلقہ CLI یا MCP، account connection، OAuth scopes اور runtime authorization پر منحصر ہے۔

چوتھا قدم: Evaluation scenarios پڑھیں

اگر skill کے ساتھ eval/scenarios.yaml موجود ہو تو دیکھیں کہ یہ rules کو testable behavior میں کس طرح تبدیل کرتا ہے:

sed -n '1,260p' opt/hatch/skills/gmail/eval/scenarios.yaml

Evaluation scenarios درج ذیل behaviors کی جانچ کے لیے موزوں ہیں:

  • کیا Agent نے درست skill منتخب کی۔
  • کیا اس نے read، draft، send اور delete جیسی مختلف risk levels میں فرق کیا۔
  • کیا ناکافی معلومات کی صورت میں recipient یا operation target کا اندازہ لگانے کے بجائے پہلے clarification طلب کی۔
  • کیا ضرورت پڑنے پر authorization یا confirmation طلب کی۔
  • کیا failure کے بعد نامکمل کاموں کی ایماندارانہ رپورٹ دی۔

Scenario file کو test pass report نہ سمجھیں۔ تاریخی مسائل کا اندازہ لگانے کے لیے opt/hatch/skills/flightaware/eval/findings.md جیسی findings records بھی دیکھی جا سکتی ہیں، اور ان کے version اور test environment کا خیال رکھیں۔

پانچواں قدم: متعلقہ reference materials دیکھیں

کچھ skills تفصیلی rules کو references/، guide/، creation/ یا guides/ میں تقسیم کرتی ہیں۔ یہ structure ایک اہم design principle کی عکاسی کرتا ہے: main skill file مختصر رہے اور زیادہ مخصوص reference materials صرف task کی ضرورت کے وقت load کیے جائیں۔

مثلاً skill authoring method کے لیے درج ذیل file سے شروع کیا جا سکتا ہے:

sed -n '1,260p' opt/hatch/skills/skill-creator/references/authoring_guide.md

عملی مثال: Gmail skill کا analysis

Gmail skill کے design کو ریکارڈ کرنے کے لیے درج ذیل template استعمال کیا جا سکتا ہے، بغیر کسی mailbox کو connect یا operate کیے:

Skill entry point: opt/hatch/skills/gmail/SKILL.md
Permission definition: opt/hatch/skills/gmail/manifest.yaml
Evaluation scenarios: opt/hatch/skills/gmail/eval/scenarios.yaml

Analysis dimensions:
1. Emails retrieve اور read کرنے کی trigger conditions
2. Draft، send اور reply کی operation boundaries
3. Labels اور unsubscribe workflow
4. Method-level permissions اور OAuth scopes
5. Recipient، email thread یا operation intent مبہم ہونے کی صورت میں handling
6. Tool failure کے بعد reporting method
7. User کو آخر میں ملنے والا result اور verification information

مکمل ہونے کے بعد اس نتیجے کو اپنی Agent specification میں تبدیل کیا جا سکتا ہے:

  • Trigger rules: واضح کریں کہ کون سے language patterns mail skill میں داخل ہوں گے۔
  • Read-only priority: search اور read کو send، delete جیسی change operations سے الگ handle کریں۔
  • Authorization threshold: target runtime environment کے مطابق confirmation اور OAuth rules ازسرنو متعین کریں۔
  • Output contract: متعین کریں کہ success، partial success اور failure کی صورت میں بالترتیب کیا واپس کیا جائے۔
  • Acceptance scenarios: normal requests، ambiguous requests، insufficient permissions اور connector failures کے tests شامل کریں۔

Product اور system architecture کا مطالعہ

Product contract کو تیزی سے سمجھنا

درج ذیل ترتیب سے پڑھنے کی تجویز ہے:

  1. home/hatch/docs/muse.md: پروڈکٹ کا جائزہ۔
  2. home/hatch/docs/goals.md: اہداف، پیش رفت اور پسِ منظر کے کام کی حدود۔
  3. home/hatch/docs/scheduling-and-watching.md: پولنگ، شیڈولنگ، رن ہسٹری اور اطلاعات۔
  4. home/hatch/docs/self_improvement.md: پسِ منظر کی یادداشت، تحقیق، جائزہ اور شواہد کی پیروی۔
  5. home/hatch/docs/connectors.md: کنکشن کی حالت، OAuth، طریقۂ کار کی اجازتیں اور ناکامی سے نمٹنا۔
  6. home/hatch/docs/privacy-and-credentials.md: اسناد کے حوالہ جات، Vault، برآمد اور حذف کرنے کے قواعد۔

یہ فائلیں اسنیپ شاٹ میں موجود پروڈکٹ معاہدے کو بیان کرتی ہیں۔ اکاؤنٹ سے مخصوص صلاحیتوں اور تاریخی دستیابی کی وضاحت کو براہِ راست تمام موجودہ Muse اکاؤنٹس کے لیے درست نہیں سمجھنا چاہیے۔

تحقیقی رن ٹائم کا آغاز کرنے کا سلسلہ

اگر توجہ Linux کے الگ تھلگ ماحول پر ہو تو درج ذیل اسکرپٹس سے کال کا تعلق قائم کیا جا سکتا ہے:

opt/hatch/runtime-cell/pre-start.sh
opt/hatch/runtime-cell/ensure-rootfs.sh
opt/hatch/runtime-cell/resolve-rootfs-path.sh
opt/hatch/runtime-cell/require-modules.sh
opt/hatch/runtime-cell/launch-daemon.sh
opt/hatch/runtime-cell/post-start.sh

resolve-rootfs-path.sh سے واپس ملنے والا /var/lib/hatch-runtime/rootfs اصل رن ٹائم ماحول کا راستہ ہے، ریپوزٹری میں شامل ڈائریکٹری نہیں۔ launch-daemon.sh systemd-nspawn کنٹینر شروع کرتا اور overlay تیار کرتا ہے؛ میزبان کی غائب کنفیگریشن اور rootfs کے بغیر یہ خود مکمل آغاز کا سبق نہیں بن سکتا۔

اعلیٰ سطحی تجزیاتی تکنیکیں

اسکلز، عرفی ناموں اور وسائل کی ڈائریکٹریوں میں فرق

ریپوزٹری میں 4 علامتی لنک عرفی نام ہیں: facebook، facebook-cli کی طرف اشارہ کرتا ہے؛ meta-threads، threads کی طرف؛ podcast، generate_podcast کی طرف؛ اور voice-calls، voice-selector کی طرف۔

لنکس کے حقیقی اہداف کی جانچ سے دوہری گنتی سے بچا جا سکتا ہے:

find opt/hatch/skills -type l -name SKILL.md -print -exec readlink {} \;

خاص طور پر voice-calls کے نام کی بنیاد پر یہ نتیجہ نہیں نکالنا چاہیے کہ اس میں Agent کی جانب سے فون کال کرنے کی صلاحیت ہے؛ یہ داخلی راستہ دراصل جامد صوتی ڈائریکٹری کی طرف اشارہ کرتا ہے۔ spaces میں رن ٹائم دستاویزات اور ٹیمپلیٹس موجود ہیں، لیکن اوپری سطح پر SKILL.md نہیں، اس لیے اسے الگ اسکل شمار نہیں کرنا چاہیے۔

اعلانات، اجازتوں اور قابلِ اجرا انحصارات کی بیک وقت تصدیق

کسی اسکل کا تجزیہ کرتے وقت تین سطحی جانچ کا طریقہ اپنایا جا سکتا ہے:

  1. رویّے کی سطح: SKILL.md میں بیان کردہ محرکات، حدود اور آؤٹ پٹ کی جانچ کریں۔
  2. اجازت کی سطح: manifest میں موجود طریقۂ کار، scope اور طے شدہ اجازتوں کی جانچ کریں۔
  3. عمل درآمد کی سطح: تصدیق کریں کہ مطلوبہ CLI، MCP، معاون پروگرام، اکاؤنٹ کنکشن اور رن ٹائم وسائل موجود ہیں۔

ریپوزٹری میں واضح طور پر کچھ اہم انحصارات موجود نہیں، جن میں Artifacts کی توثیقی اسکرپٹس، skill-creator کا کنیکٹر اسکیفولڈ، Magic Moment کا mm قابلِ اجرا پروگرام، اور Spaces کے لیے درکار بعض SDKs اور build وسائل شامل ہیں۔ لہٰذا، “دستاویز کا پڑھا جا سکنا” “عمل درآمد کا مکمل سلسلہ” ہونے کے برابر نہیں۔

آؤٹ پٹ کی تیاری اور آؤٹ پٹ کی منظوری کو الگ رکھیں

artifacts/testing کو عمومی Agent پیٹرن کے طور پر مطالعہ کرنا مفید ہے۔ یہ اس بات پر زور دیتا ہے کہ فائلیں تیار کرنے کے بعد انہیں آؤٹ پٹ کی قسم کے مطابق جانچا جائے، دوبارہ render کیا جائے، بصری منظوری دی جائے اور placeholder اسکین کیے جائیں۔ اپنے نظام میں منتقل کرتے وقت عمل کو یوں تقسیم کیا جا سکتا ہے:

  1. دستاویز، جدول، PDF یا پریزنٹیشن تیار کریں۔
  2. تیار شدہ نتیجے کو دوبارہ کھولیں یا render کریں۔
  3. ساخت، layout، فارمولوں، لنکس اور غائب وسائل کی جانچ کریں۔
  4. غیر تبدیل شدہ placeholders اور عارضی متن تلاش کریں۔
  5. فائل کو قابلِ فراہمی صرف منظوری کے بعد نشان زد کریں۔

کثیر Agent تعاون کا مطالعہ

wide-research متعدد ان پٹ کے متوازی تحقیق میں اہم پابندیاں دکھاتا ہے: coordinator اور worker کی ذمہ داریوں کو محدود کرنا، آؤٹ پٹ کے شعبوں کو یکساں رکھنا، کوریج رپورٹ کرنا اور ناکام آئٹمز محفوظ رکھنا۔ منتقلی کے وقت اپنے orchestration framework کے مطابق ٹول کے نام اور workspace کے راستے تبدیل کریں، جبکہ یکساں آؤٹ پٹ معاہدہ اور ناکامی کی مرئیت برقرار رکھیں۔

ڈیٹا بیس تلاش کرنے کے بجائے اس کی وضاحت دیکھیں

opt/hatch/skills/muse_db/references/schema.md محدود SQL قواعد، identifiers اور متعدد schemas کے تحت تعلقات بیان کرتا ہے، اور ڈیٹا ماڈل اور جدولوں کے درمیان پیروی کا طریقہ سمجھنے کے لیے استعمال ہو سکتا ہے۔ یہ حقیقی ڈیٹا بیس یا migration source code نہیں، اس لیے اس کی بنیاد پر مکمل سروس بحال نہیں کی جا سکتی۔

ماخذ، لائسنس اور شواہد کی حدود برقرار رکھیں

ورک فلو کو دوسرے منصوبوں میں منتقل کرتے وقت ماخذ کا انتساب برقرار رکھیں اور قابلِ اطلاق لائسنس کی جانچ کریں۔ داخلی تجزیاتی ریکارڈ میں درج ذیل کے درمیان فرق رکھنے کی سفارش کی جاتی ہے:

  • وہ حقائق جو ریپوزٹری کی فائلوں میں براہِ راست بیان کیے گئے ہیں۔
  • ڈائریکٹریوں، اسکرپٹس یا manifest کی بنیاد پر اخذ کیے گئے تکنیکی نتائج۔
  • وہ پروڈکٹ دعوے جن کی ابھی تصدیق نہیں ہوئی۔
  • وہ رویّے جن کی تصدیق غائب رن ٹائم ماحول کی وجہ سے نہیں ہو سکتی۔

“آرکائیو میں نظر آنا” “سرکاری ماخذ سے تصدیق شدہ”، “آزادانہ طور پر چلنے کے قابل” یا “من مانے طریقے سے دوبارہ لائسنس کرنے کے قابل” ہونے کے برابر نہیں۔

تجویز کردہ تعلیمی راستہ

  1. ریپوزٹری کلون کرتے وقت LFS کو چھوڑ دیں تاکہ غیر ضروری بائنری ڈاؤن لوڈ نہ ہوں۔
  2. PROJECT_ANALYSIS.md پڑھیں تاکہ معماری کے فیصلوں اور غائب اجزا کو سمجھ سکیں۔
  3. ورک فلو کی ساخت سیکھنے کے لیے skill-creator یا wide-research منتخب کریں۔
  4. gmail منتخب کر کے اسکل کے متن، manifest اور eval کا مشترکہ تجزیہ کریں۔
  5. artifacts/testing پڑھیں اور deliverables کی منظوری کی سوچ پیدا کریں۔
  6. پروڈکٹ دستاویزات پڑھیں اور اسکل کے قواعد کو پروڈکٹ معاہدے سے الگ کریں۔
  7. آخر میں runtime-cell اسکرپٹس دیکھیں تاکہ رن ٹائم کے اشارے اور غائب انحصارات کو سمجھ سکیں۔

اختتامیہ

MuseAI-Skills کی بنیادی قدر براہِ راست deployment میں نہیں، بلکہ اس مظاہرے میں ہے کہ ایک ذاتی AI Agent اسکل کے محرکات، کام کی تقسیم، کنیکٹر کی اجازتوں، ناکامی سے نمٹنے اور نتائج کی منظوری کو کیسے منظم کر سکتا ہے۔ SKILL.md، manifest.yaml، evaluation scenarios اور رن ٹائم انحصارات کو ایک ساتھ پڑھ کر آپ اپنے Agent نظام کے لیے موزوں design patterns اخذ کر سکتے ہیں، اور ساتھ ہی اسنیپ شاٹ کو مکمل source code یا قابلِ اجرا پروڈکٹ سمجھنے سے بچ سکتے ہیں۔