MuseAI-Skills পড়ার টিউটোরিয়াল: Muse AI দক্ষতা, অনুমতি ও Agent ওয়ার্কফ্লো বিশ্লেষণ

প্রকল্পটি কী

MuseAI-Skills হলো muse.ai-সম্পর্কিত Muse / Hatch ব্যক্তিগত AI Agent পরিবেশের একটি স্ন্যাপশট। রিপোজিটরিতে পণ্যের বিবরণ, দক্ষতার সংজ্ঞা, কানেক্টর অনুমতির তালিকা, আচরণগত মূল্যায়ন পরিস্থিতি, Linux রানটাইম স্ক্রিপ্ট এবং কিছু বান্ডেল করা প্রোগ্রাম ও নির্ভরতা সংরক্ষিত আছে।

গুরুত্বপূর্ণ সীমারেখা: এটি সম্পূর্ণ সোর্স কোড রিপোজিটরি নয় এবং এক ক্লিকে স্থাপনযোগ্য ইনস্টলেশন প্যাকেজও নয়। মূল প্রোগ্রামগুলো প্রধানত Linux x86-64 ELF বাইনারি হিসেবে দেওয়া হয়েছে, কিন্তু বিল্ড সোর্স, সম্পূর্ণ হোস্ট কনফিগারেশন, rootfs এবং কিছু রানটাইম রিসোর্স অন্তর্ভুক্ত নেই।

তাই এই রিপোজিটরিটি স্ট্যাটিক পাঠ, Agent ওয়ার্কফ্লো গবেষণা, অনুমতি মডেল বিশ্লেষণ এবং নির্দেশনা নকশার রেফারেন্স হিসেবে সবচেয়ে উপযোগী; Muse AI পরিষেবা সরাসরি ইনস্টল করার জন্য নয়। রিপোজিটরির উপকরণে Muse, Hatch এবং Jarvis নাম ব্যবহার করা হয়েছে, তবে এই আর্কাইভ নিজে কোনো অফিসিয়াল প্রকাশনা, অনুমোদন বা উৎস-প্রমাণীকরণ নির্দেশ করে না।

রিপোজিটরি থেকে কী শিখতে পারবেন

দক্ষতা-ভিত্তিক ওয়ার্কফ্লোর পূর্ণ কাঠামো

রিপোজিটরিতে 72টি SKILL.md পাথ রয়েছে, যার মধ্যে 68টি স্বতন্ত্র দক্ষতা ফাইল এবং 4টি সিম্বলিক-লিঙ্ক alias। দক্ষতাগুলো Agent ওয়ার্কফ্লো, ডকুমেন্ট আউটপুট, ভ্রমণ বুকিং, অফিস টুল, সামাজিক প্ল্যাটফর্ম, স্বাস্থ্য ডেটা, মিডিয়া তৈরি, ডিভাইস নিয়ন্ত্রণ এবং Muse পণ্য পরিচালনাসহ বিভিন্ন ক্ষেত্রকে অন্তর্ভুক্ত করে।

এই দক্ষতার নথিগুলো সাধারণত আপনাকে নিচের প্রশ্নগুলো গবেষণা করতে সহায়তা করে:

• কোন ব্যবহারকারীর অনুরোধে দক্ষতাটি সক্রিয় হওয়া উচিত।
• কাজটি coordinator, worker নাকি বাহ্যিক connector দ্বারা সম্পন্ন হওয়া উচিত।
• সম্পাদনের আগে কোন অ্যাকাউন্ট সংযোগ, OAuth scope বা ব্যবহারকারীর অনুমোদন প্রয়োজন।
• টুল ব্যর্থ হলে, ইনপুট অসম্পূর্ণ হলে বা অনুমতি অপর্যাপ্ত হলে কীভাবে বিকল্প ব্যবস্থা নিতে হবে।
• কীভাবে আউটপুট ফরম্যাট নির্ধারণ এবং চূড়ান্ত ডেলিভারেবল যাচাই করতে হবে।

অনুমতি ও মূল্যায়ন উপকরণ

রিপোজিটরিতে আরও 40টি manifest পাথ এবং 12টি eval YAML রয়েছে। manifest.yaml কানেক্টর মেটাডেটা, ডিফল্ট অনুমতি, scope-এর প্রয়োজনীয়তা এবং কমান্ড ম্যাপিং বোঝার জন্য ব্যবহার করা যায়; eval/scenarios.yaml-এ আচরণগত মূল্যায়নের পরিস্থিতি, ব্যবহারকারীর লক্ষ্য এবং প্রত্যাশিত আচরণ নথিভুক্ত করা হয়েছে।

মনে রাখুন: manifest থাকা মানে অ্যাকাউন্ট ইতিমধ্যে সংযুক্ত—এমন নয়; মূল্যায়ন পরিস্থিতি থাকা মানে মূল্যায়ন চালানো বা উত্তীর্ণ হওয়া—এমনও নয়।

রানটাইম পরিবেশের স্ট্যাটিক সূত্র

opt/hatch/runtime-cell/-এর স্ক্রিপ্টগুলো রানটাইম পরিবেশের জীবনচক্রের কিছু অংশ দেখায়, যার মধ্যে rootfs পাথ বিশ্লেষণ, চালুর আগের প্রস্তুতি, কার্নেল মডিউল পরীক্ষা, systemd-nspawn কনটেইনার চালু করা এবং দক্ষতা ও বাইনারি overlay একত্র করা অন্তর্ভুক্ত। তবে সম্পূর্ণ হোস্ট unit, nspawn কনফিগারেশন এবং প্রকৃত rootfs রিপোজিটরিতে নেই।

ডিরেক্টরি কাঠামোর সংক্ষিপ্ত পরিচয়

• README.md: চীনা প্রবেশিকা, দক্ষতার ডিরেক্টরি এবং সীমারেখার বিবরণ।
• README.en.md: ইংরেজি প্রবেশিকা।
• PROJECT_ANALYSIS.md: আর্কিটেকচার বিশ্লেষণ, অনুপস্থিত উপাদান, ঝুঁকি এবং প্রমাণের সূচি।
• SHA256SUMS: সাধারণ ফাইলের কনটেন্ট checksum তালিকা, তবে এটি উৎসের স্বাক্ষর নয়।
• home/hatch/docs/: পণ্য, কানেক্টর, গোপনীয়তা, শিডিউলিং, ফাইল, ডিভাইস এবং মিডিয়াসংক্রান্ত বিবরণ।
• home/hatch/config/: Agent এবং দক্ষতার অবস্থাসংক্রান্ত কনফিগারেশন।
• opt/hatch/skills/: দক্ষতার প্রবেশিকা, অনুমতি manifest, মূল্যায়ন পরিস্থিতি এবং রেফারেন্স উপকরণ।
• opt/hatch/runtime-cell/: রানটাইম পরিবেশের জীবনচক্রের স্ক্রিপ্ট ও কনফিগারেশন টেমপ্লেট।
• opt/hatch/bin/: Hatch-সম্পর্কিত প্রোগ্রাম।
• opt/hatch-image/: ইমেজ-সাইড টুল, npm, Bun এবং অন্যান্য বান্ডেল করা উপাদান।

রিপোজিটরির root directory শুধু আর্কাইভের root directory; এটি চালু থাকা Linux root directory নয়। আর্কাইভের home/hatch/ মূল পরিবেশের /home/hatch-এর সমতুল্য, আর নথিতে থাকা /run, /var/lib এবং /etc সাধারণত অনুপস্থিত রানটাইম ফাইল সিস্টেমকে নির্দেশ করে।

রিপোজিটরি সংগ্রহ ও প্রস্তুত করা

পদ্ধতি এক: শুধু দক্ষতা ও নথি গবেষণা

লক্ষ্য যদি Markdown, YAML এবং Shell স্ক্রিপ্ট বিশ্লেষণ করা হয়, তাহলে আকারে বড় Git LFS বাইনারিগুলো বাদ দিতে পারেন। পাঠের জন্য এটিই সবচেয়ে সুপারিশযোগ্য পদ্ধতি।

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

এই পদ্ধতিতে বান্ডেল করা কোনো প্রোগ্রাম চালানোর প্রয়োজন নেই। রিপোজিটরিতে ঢোকার পর প্রথমে PROJECT_ANALYSIS.md এবং opt/hatch/skills/ খুলুন।

পদ্ধতি দুই: সম্পূর্ণ আর্কাইভ অবজেক্ট দেখা

LFS-এ থাকা ELF প্রোগ্রাম বা অন্যান্য বড় ফাইল পরীক্ষা করা সত্যিই প্রয়োজন হলেই Git LFS ইনস্টল করে সংশ্লিষ্ট অবজেক্ট সংগ্রহ করা উচিত। বাইনারি ডাউনলোড করলেই অনুপস্থিত সোর্স, rootfs, credentials বা হোস্ট কনফিগারেশন পূরণ হবে না, আর রিপোজিটরিও স্থাপনযোগ্য সিস্টেমে পরিণত হবে না।

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

যেসব বাইনারির উৎস স্বাধীনভাবে প্রমাণীকৃত নয়, সেগুলো আগে অফলাইন স্ট্যাটিক পরীক্ষা করুন; উৎপাদন মেশিনে বা সংবেদনশীল credentials-যুক্ত পরিবেশে সরাসরি চালাবেন না।

সাধারণ ফাইল যাচাই

সংশ্লিষ্ট ফাইলগুলো সম্পূর্ণ সংগ্রহ করার পর রিপোজিটরির দেওয়া SHA256SUMS ব্যবহার করে কনটেন্টের অখণ্ডতা পরীক্ষা করতে পারেন:

sha256sum -c SHA256SUMS

এই checksum তালিকায় তালিকা ফাইলটি নিজে এবং সিম্বলিক লিঙ্ক অন্তর্ভুক্ত নয়; এটি প্রকাশকের পরিচয় বা উৎসের সত্যতার ক্রিপ্টোগ্রাফিক স্বাক্ষরও নয়। এটি শুধু স্থানীয় সাধারণ ফাইলের digest তালিকায় নথিভুক্ত digest-এর সঙ্গে মেলে কি না তা যাচাই করতে সহায়তা করে।

মৌলিক ব্যবহার: দক্ষতা পাঠের ওয়ার্কফ্লো তৈরি

প্রথম ধাপ: একটি দক্ষতার প্রবেশিকা বেছে নিন

প্রথমবার পড়ার সময় নিচের দক্ষতাগুলো দিয়ে শুরু করতে পারেন:

• wide-research: গবেষণা coordinator, worker, একীভূত আউটপুট চুক্তি এবং ব্যর্থতার কাভারেজ।
• skill-creator: দক্ষতা সক্রিয় করার বিবরণ, ডিরেক্টরি বিভাজন এবং প্রয়োজনমতো রেফারেন্স উপকরণ লোড করা।
• artifacts/testing: “সফলভাবে তৈরি” এবং “ডেলিভারেবল ব্যবহারযোগ্য”—এই দুই বিষয়ের পার্থক্য।
• goals: প্রথমবার লক্ষ্য নির্ধারণ এবং পরবর্তী অনুসরণের পার্থক্য।
• forget: কপি, derived state এবং সম্ভাব্য পুনরায় লেখা ডেটা পরিচালনা।
• travel-planning: ভ্রমণসূচি গবেষণা, রিয়েল-টাইম অনুসন্ধান এবং লেনদেন সম্পাদন আলাদা করা।
• gmail: দক্ষতার মূল লেখা, পদ্ধতি-স্তরের অনুমতি এবং মূল্যায়ন পরিস্থিতি মিলিয়ে কানেক্টর বিশ্লেষণ।

উদাহরণস্বরূপ, Gmail দক্ষতার প্রবেশিকা দেখুন:

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

দ্বিতীয় ধাপ: সক্রিয় করার শর্ত ও সীমারেখা বের করুন

SKILL.md পড়ার সময় শুধু “এটি কী করতে পারে” লিখে রাখবেন না; ধারাবাহিকভাবে নিচের প্রশ্নগুলোর উত্তর দিন:

1. কোন অনুরোধে এই দক্ষতাটি সক্রিয় হওয়া উচিত?
2. কোন অনুরূপ অনুরোধে এটি সক্রিয় হওয়া উচিত নয়?
3. শুধু-পাঠ এবং লেখার কাজ কীভাবে আলাদা করা হয়?
4. পাঠানো, মুছে ফেলা, কেনা বা বুকিংয়ের মতো উচ্চ-প্রভাবের কাজের জন্য কি নিশ্চিতকরণ প্রয়োজন?
5. অনুমতি অপর্যাপ্ত, লক্ষ্য অস্পষ্ট বা টুল ব্যর্থ হলে কীভাবে处理 করতে হবে?
6. চূড়ান্ত ফলে কোন কোন field বা প্রমাণ ফেরত দিতে হবে?

এসব তথ্য “সক্রিয়করণ, ইনপুট, অনুমোদন, সম্পাদন, ব্যর্থতা, গ্রহণযোগ্যতা”—এই ছয়টি অংশে সাজালে নিজের Agent নকশায় স্থানান্তর করা সহজ হয়।

তৃতীয় ধাপ: অনুমতি manifest-এর সঙ্গে তুলনা করুন

কানেক্টর-ভিত্তিক দক্ষতার ক্ষেত্রে একই ডিরেক্টরির manifest.yaml পড়তে থাকুন:

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

দক্ষতার মূল লেখায় উল্লেখ করা কাজগুলো এবং manifest-এ ঘোষিত method permission, group default, scope ও command mapping-এর মধ্যে তুলনা করুন। method-স্তরের সেটিং group default-কে ওভাররাইড করতে পারে, তাই শুধু শীর্ষ-স্তরের অনুমতির বিবরণ দেখলেই চলবে না।

একটি SKILL.md অন্য Agent পরিবেশে কপি করলেই Gmail, Google Drive, Notion বা অন্যান্য পরিষেবায় প্রবেশাধিকার স্বয়ংক্রিয়ভাবে পাওয়া যাবে না। বাস্তবে কাজ সম্পাদনের জন্য সংশ্লিষ্ট CLI বা MCP, অ্যাকাউন্ট সংযোগ, OAuth scope এবং রানটাইম অনুমোদন এখনও প্রয়োজন।

চতুর্থ ধাপ: মূল্যায়ন পরিস্থিতি পড়ুন

দক্ষতার সঙ্গে eval/scenarios.yaml থাকলে নিয়মগুলোকে কীভাবে পরীক্ষাযোগ্য আচরণে রূপ দেওয়া হয়েছে তা দেখতে পারেন:

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

মূল্যায়ন পরিস্থিতি নিচের আচরণগুলো যাচাই করার জন্য উপযোগী:

• Agent সঠিক দক্ষতা বেছে নিয়েছে কি না।
• পড়া, draft তৈরি, পাঠানো এবং মুছে ফেলার মতো ভিন্ন ঝুঁকির স্তর আলাদা করেছে কি না।
• তথ্য অপর্যাপ্ত হলে প্রাপক বা কাজের লক্ষ্য অনুমান না করে আগে স্পষ্টীকরণ চেয়েছে কি না।
• প্রয়োজন হলে অনুমোদন বা নিশ্চিতকরণ চেয়েছে কি না।
• ব্যর্থতার পর অসম্পন্ন বিষয়গুলো সততার সঙ্গে জানিয়েছে কি না।

পরিস্থিতির ফাইলকে পরীক্ষায় উত্তীর্ণ হওয়ার প্রতিবেদন হিসেবে বিবেচনা করবেন না। অতীতের সমস্যা বোঝার জন্য opt/hatch/skills/flightaware/eval/findings.md-এর মতো discovery record-ও দেখতে পারেন, তবে এর version এবং test environment বিবেচনায় রাখুন।

পঞ্চম ধাপ: সহায়ক রেফারেন্স উপকরণ পরীক্ষা করুন

কিছু দক্ষতা বিস্তারিত নিয়ম references/, guide/, creation/ বা guides/-এ ভাগ করে রাখে। এই কাঠামো একটি গুরুত্বপূর্ণ নকশা নীতি প্রকাশ করে: মূল দক্ষতার ফাইল সংক্ষিপ্ত থাকবে এবং কাজের প্রয়োজন হলেই আরও নির্দিষ্ট রেফারেন্স উপকরণ লোড হবে।

উদাহরণস্বরূপ, দক্ষতা লেখার পদ্ধতি নিচের ফাইল দিয়ে শুরু করা যায়:

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

ব্যবহারিক উদাহরণ: Gmail দক্ষতা বিশ্লেষণ

ইমেইল অ্যাকাউন্টে বাস্তবে সংযোগ বা কাজ না করেই Gmail দক্ষতার নকশা নথিভুক্ত করতে নিচের টেমপ্লেট ব্যবহার করতে পারেন:

দক্ষতার প্রবেশিকা: opt/hatch/skills/gmail/SKILL.md
অনুমতির সংজ্ঞা: opt/hatch/skills/gmail/manifest.yaml
মূল্যায়ন পরিস্থিতি: opt/hatch/skills/gmail/eval/scenarios.yaml

বিশ্লেষণের মাত্রা:
1. ইমেইল অনুসন্ধান ও পড়ার সক্রিয়করণ শর্ত
2. draft, পাঠানো ও reply-এর কাজের সীমারেখা
3. label ও unsubscribe প্রক্রিয়া
4. method-স্তরের অনুমতি ও OAuth scope
5. প্রাপক, ইমেইল thread বা কাজের উদ্দেশ্য অস্পষ্ট হলে করণীয়
6. টুল ব্যর্থতার পর প্রতিবেদন করার পদ্ধতি
7. ব্যবহারকারীর চূড়ান্তভাবে পাওয়া উচিত এমন ফলাফল ও যাচাই তথ্য

কাজ শেষ হলে ফলাফলকে নিজের Agent specification-এ রূপান্তর করতে পারেন:

• সক্রিয়করণ নিয়ম: কোন ভাষাগত pattern-এ mail skill সক্রিয় হবে তা স্পষ্ট করুন।
• শুধু-পাঠ অগ্রাধিকার: search ও read কাজকে send, delete ইত্যাদি পরিবর্তনমূলক কাজ থেকে আলাদা রাখুন।
• অনুমোদনের সীমা: লক্ষ্য রানটাইম পরিবেশ অনুযায়ী confirmation এবং OAuth নিয়ম নতুন করে নির্ধারণ করুন।
• আউটপুট চুক্তি: সফলতা, আংশিক সফলতা এবং ব্যর্থতার ক্ষেত্রে কী ফেরত দিতে হবে তা নির্ধারণ করুন।
• গ্রহণযোগ্যতার পরিস্থিতি: স্বাভাবিক অনুরোধ, অস্পষ্ট অনুরোধ, অপর্যাপ্ত অনুমতি এবং কানেক্টর ত্রুটির পরীক্ষা যোগ করুন।

পণ্য ও সিস্টেম আর্কিটেকচার পড়া

দ্রুত পণ্য চুক্তি বোঝা

নিচের ক্রমে পড়ার পরামর্শ দেওয়া হয়:

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 ছাড়া এটিকে স্বাধীনভাবে সম্পূর্ণ চালু করার টিউটোরিয়াল হিসেবে ব্যবহার করা যায় না।

উন্নত বিশ্লেষণ কৌশল

স্কিল, alias এবং resource directory আলাদা করা

রিপোজিটরিতে 4টি প্রতীকী লিংক alias রয়েছে: 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-এর connector scaffolding, Magic Moment-এর mm executable এবং Spaces-এর জন্য প্রয়োজনীয় কিছু SDK ও build resource। তাই “ডকুমেন্টেশন পাঠযোগ্য” হওয়া “সম্পাদন শৃঙ্খল সম্পূর্ণ” হওয়ার সমতুল্য নয়।

উৎপাদন ও গ্রহণযোগ্যতা যাচাই আলাদা রাখা

artifacts/testing একটি সাধারণ Agent প্যাটার্ন হিসেবে অধ্যয়নের উপযোগী। এটি জোর দেয় যে ফাইল তৈরি করার পরও artifact-এর ধরন অনুযায়ী পরীক্ষা, পুনরায় রেন্ডার, দৃশ্যমান যাচাই এবং placeholder স্ক্যান করা দরকার। নিজের সিস্টেমে স্থানান্তরের সময় প্রক্রিয়াটি এভাবে ভাগ করা যায়:

1. ডকুমেন্ট, স্প্রেডশিট, PDF বা প্রেজেন্টেশন তৈরি করুন।
2. তৈরি ফলাফল পুনরায় খুলুন বা রেন্ডার করুন।
3. গঠন, বিন্যাস, সূত্র, লিংক এবং অনুপস্থিত রিসোর্স পরীক্ষা করুন।
4. প্রতিস্থাপিত না হওয়া placeholder এবং অস্থায়ী লেখা খুঁজুন।
5. গ্রহণযোগ্যতা যাচাই পাস করার পরেই ফাইলটিকে deliverable হিসেবে চিহ্নিত করুন।

বহু-Agent সহযোগিতা গবেষণা

wide-research বহু ইনপুটের সমান্তরাল গবেষণায় গুরুত্বপূর্ণ সীমাবদ্ধতাগুলো দেখায়: coordinator ও worker-এর দায়িত্ব সীমিত করা, আউটপুট ফিল্ড একীভূত করা, coverage রিপোর্ট করা এবং ব্যর্থ আইটেম সংরক্ষণ করা। স্থানান্তরের সময় নিজের orchestration framework অনুযায়ী টুলের নাম ও workspace path বদলাতে হবে, তবে একীভূত output contract এবং ব্যর্থতার দৃশ্যমানতা বজায় রাখতে হবে।

ডেটাবেস খোঁজার বদলে ডেটাবেসের বিবরণ পরীক্ষা করা

opt/hatch/skills/muse_db/references/schema.md সীমিত SQL নিয়ম, identifier এবং একাধিক schema-র সম্পর্ক বর্ণনা করে। এটি ডেটা মডেল ও টেবিলের মধ্যে অনুসরণের পদ্ধতি বোঝার কাজে ব্যবহার করা যায়। এটি প্রকৃত ডেটাবেস নয় এবং migration source code-ও নয়; এর ভিত্তিতে সম্পূর্ণ service পুনরুদ্ধার করা সম্ভব নয়।

উৎস, লাইসেন্স এবং প্রমাণের সীমা সংরক্ষণ করা

কাজের প্রবাহ অন্য প্রকল্পে স্থানান্তরের সময় উৎসের attribution সংরক্ষণ এবং প্রযোজ্য লাইসেন্স পরীক্ষা করা উচিত। অভ্যন্তরীণ বিশ্লেষণ নথিতে নিচের বিষয়গুলো আলাদা করে রাখার পরামর্শ দেওয়া হয়:

• রিপোজিটরির ফাইল সরাসরি যে তথ্য বলেছে।
• ডিরেক্টরি, স্ক্রিপ্ট বা manifest থেকে করা প্রযুক্তিগত অনুমান।
• এখনও যাচাই না করা পণ্যের দাবি।
• রানটাইম পরিবেশ অনুপস্থিত থাকায় যে আচরণ নিশ্চিত করা যায়নি।

“আর্কাইভে দৃশ্যমান” হওয়া “আনুষ্ঠানিক উৎস দ্বারা প্রত্যয়িত”, “স্বাধীনভাবে চালানো সম্ভব” অথবা “ইচ্ছেমতো পুনরায় লাইসেন্স দেওয়া যায়”—এর সমতুল্য নয়।

প্রস্তাবিত শেখার পথ

1. রিপোজিটরি ক্লোন করার সময় LFS এড়িয়ে চলুন, যাতে অপ্রয়োজনীয়ভাবে বাইনারি ডাউনলোড না হয়।
2. আর্কিটেকচার-সংক্রান্ত সিদ্ধান্ত ও অনুপস্থিত বিষয়গুলো বোঝার জন্য PROJECT_ANALYSIS.md পড়ুন।
3. ওয়ার্কফ্লোর কাঠামো শেখার জন্য skill-creator অথবা wide-research বেছে নিন।
4. স্কিলের মূল লেখা, manifest এবং eval একসঙ্গে বিশ্লেষণ করতে gmail বেছে নিন।
5. ডেলিভারেবল গ্রহণযোগ্যতা যাচাইয়ের দৃষ্টিভঙ্গি তৈরি করতে artifacts/testing পড়ুন।
6. স্কিলের নিয়ম ও পণ্যের চুক্তি আলাদা করতে পণ্যের ডকুমেন্টেশন পড়ুন।
7. সবশেষে runtime-cell স্ক্রিপ্ট পরীক্ষা করুন, যাতে রানটাইমের সূত্র ও অনুপস্থিত নির্ভরতা বোঝা যায়।

উপসংহার

MuseAI-Skills-এর প্রধান মূল্য সরাসরি deployment-এ নয়, বরং একটি ব্যক্তিগত AI Agent কীভাবে স্কিল ট্রিগার, কাজের রাউটিং, connector-এর অনুমতি, ব্যর্থতা পরিচালনা এবং ফলাফল গ্রহণযোগ্যতা যাচাই সংগঠিত করে তা দেখানোতে। SKILL.md, manifest.yaml, evaluation scenario এবং runtime dependency একসঙ্গে পড়লে নিজের Agent সিস্টেমে প্রযোজ্য নকশা-প্যাটার্ন বের করা যায়। একই সঙ্গে snapshot-কে সম্পূর্ণ source code বা executable product হিসেবে ভুল বোঝার ঝুঁকিও এড়ানো যায়।