Solo to Team ٹیوٹوریل: تعاون کا اسکل پیکج انسٹال کریں اور ایک فرد سے متعدد AI معاونین کو منظم کریں

منصوبے کا تعارف

Solo to Team · ایک شخص، ایک ٹیم، جس کے ریپوزٹری نام solo-to-team-skills ہے، چینی زبان میں تعاون کے لیے تیار کردہ مہارتوں کا ایک پیکیج ہے، جو “ایک شخص کا مرکزی کنٹرول، متعدد طویل مدتی AI معاونین” کے منظرنامے کے لیے بنایا گیا ہے۔ یہ AI کو خودکار طور پر ٹیم بنانے کا ذمہ دار نہیں، بلکہ ایک ایسا قابلِ تکرار طریقہ فراہم کرتا ہے جس سے آپ کام سونپ سکیں، اس کی پیش رفت واپس لے سکیں، شواہد کی جانچ کر سکیں، اور آخر میں انسانی فیصلہ کر سکیں۔

منصوبے کی موجودہ حالت v0.9-draft ہے اور اس میں مزید ترمیم جاری رہے گی۔ اسے Codex، WorkBuddy، DeepSeek Harness، Cursor، CodeBuddy، Kimi Work، 千问办公 اور دیگر میزبانوں میں محدود دائرے میں عملی طور پر استعمال کر کے جانچا جا چکا ہے؛ Grok Bot کے لیے دستی ترتیب درکار ہے۔ Claude Code کے لیے پلگ اِن کا ڈھانچہ تیار ہے، لیکن اسے پہلے مرحلے کی معاونت میں شامل نہیں کیا گیا۔

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

یہ منصوبہ کون سا مسئلہ حل کرتا ہے

متعدد AI معاونین کے تعاون میں عموماً اصل بے قابو ہونے والا مسئلہ ماڈل کی صلاحیت نہیں بلکہ طریقۂ کار ہوتا ہے: کام بھیجنے کے بعد کوئی تصدیق نہیں کرتا، کام کرنے والا کہتا ہے “مکمل ہو گیا” مگر کوئی ثبوت نہیں ہوتا، قبولیت اور نتیجہ موصول ہونے کو ایک ہی چیز سمجھ لیا جاتا ہے، یا عملی ہدایات صرف انہیں سمجھ آتی ہیں جنہوں نے انہیں لکھا ہو۔

Solo to Team تعاون کے عمل کو ایک مرکزی سلسلے میں منظم کرتا ہے:

مقصد طے کریں → تقسیم کریں → حوالہ کریں → جانچیں → فیصلہ کریں

• مقصد طے کریں: واضح کریں کہ کیا کرنا ہے، نتیجہ کہاں رکھنا ہے، کب فراہم کرنا ہے، اور تکمیل کا معیار کیا ہوگا۔
• تقسیم کریں: کام سونپنے سے پہلے “وصول ہونا باقی” درج کریں، اور عمل کرنے والے، وصول کرنے والے اور مقررہ وقت پر جانچنے والے کو واضح لکھیں۔
• حوالہ کریں: “آرڈر قبول کیا” اور “نتیجہ موصول ہوا” الگ الگ درج کریں، تاکہ پیغام موصول ہونے کو تکمیل نہ سمجھ لیا جائے۔
• جانچیں: موجودہ ورژن سے متعلق مؤثر شواہد کی جانچ کریں؛ ترمیم شدہ یا ناکام حصوں کی دوبارہ تصدیق ضروری ہے۔
• فیصلہ کریں: انسان فیصلہ کرے کہ نتیجہ منظور کرنا ہے، واپس بھیجنا ہے یا سمت تبدیل کرنی ہے۔

چار بنیادی مہارتیں

dispatch-accept-verify

نمائشی نام “سونپا ہوا کام واپس وصول کریں” ہے، اور یہ تقسیم و حوالگی کی ذمہ داری سنبھالتی ہے۔ اس میں تقاضا ہے کہ کام بھیجنے سے پہلے “وصول ہونا باقی” درج کیا جائے، اور آرڈر قبول کرنے، نتیجہ موصول ہونے اور قبولیت مکمل ہونے کو الگ الگ ریکارڈ کیا جائے۔ کام کو نامکمل فہرست سے صرف قبولیت مکمل ہونے یا مجاز طور پر منسوخ کیے جانے کے بعد ہی ہٹایا جا سکتا ہے۔

evidence-before-done

نمائشی نام “کام دینے سے پہلے ثبوت موجود ہو” ہے، اور یہ جانچ کی ذمہ داری سنبھالتی ہے۔ اس میں زور دیا جاتا ہے کہ تکمیل کا نتیجہ موجودہ ورژن سے متعلق شواہد پر مبنی ہو، مثلاً نتیجہ کھول کر جانچنا، دوبارہ حساب کرنا، کمانڈ چلانا، یا اصل مراحل کے مطابق عمل کو دوبارہ دہرانا۔

beginner-ops-writing

نمائشی نام “ابتدائی صارف کے لیے عملی ہدایات” ہے، اور اسے ایسی ہدایات لکھنے کے لیے استعمال کیا جاتا ہے جن پر پس منظر سے ناواقف شخص بھی عمل کر سکے۔ بنیادی اصولوں میں ایک وقت میں ایک قدم لکھنا، ہر چیز کا واضح اور منفرد حوالہ دینا، اور یہ بتانا شامل ہے کہ تکمیل کے بعد کیا نظر آنا چاہیے۔ لاگ اِن، ادائیگی، حذف کرنا، باضابطہ بھیجنا اور دیگر ایسے اقدامات جو خود متعلقہ شخص کو کرنے چاہییں، ان کے لیے صرف “براہِ کرم متعلقہ شخص خود کرے” لکھا جائے؛ کسی اور کے ذریعے کرنے کا طریقہ وضع نہ کیا جائے۔

ops-case-notes

نمائشی نام “شناخت چھپائی گئی عملی ریکارڈنگ” ہے۔ اس میں حقیقی کارروائی سے لیے گئے دو ایسے کیس شامل ہیں جن سے شناختی معلومات ہٹا دی گئی ہیں، اور ان میں اصل مسئلہ، تبدیلی کا طریقہ، نتیجہ اور اب بھی موجود پابندیاں درج ہیں۔ یہ عمل میں خامی سامنے آنے کے بعد جائزے کے لیے موزوں ہے۔

شروع کرنے سے پہلے تیاری

سب سے پہلے ریپوزٹری ڈاؤن لوڈ یا کلون کریں اور یقینی بنائیں کہ مقامی طور پر skills/ ڈائریکٹری موجود ہے۔ اس ڈائریکٹری میں مہارتوں کی چار ذیلی ڈائریکٹریاں ہونی چاہییں، اور ہر ڈائریکٹری میں ایک SKILL.md موجود ہو۔

git clone YOUR_REPOSITORY_URL
cd solo-to-team-skills

کلون کا پتہ منصوبے کے باضابطہ طور پر عوامی ہونے کے بعد کے اصل ریپوزٹری پتے سے تبدیل کیا جائے۔ اگر منصوبہ کمپریس شدہ پیکیج کے ذریعے حاصل کیا گیا ہو تو اسے براہِ راست بھی ان زِپ کر کے استعمال کیا جا سکتا ہے۔

تنصیب کے وقت درج ذیل اصولوں پر عمل کریں:

• پورا skills/مہارت-کا-نام/ فولڈر نقل کریں، صرف SKILL.md نقل نہ کریں۔
• dispatch-accept-verify اسی ڈائریکٹری میں موجود ٹیمپلیٹس پر بھی منحصر ہے؛ صرف متن نقل کرنے سے اندراجی سطر کا ٹیمپلیٹ ضائع ہو جائے گا۔
• dispatch-accept-verify اور evidence-before-done کو بیک وقت نصب کرنے کی سفارش کی جاتی ہے۔
• evidence-before-done کو الگ سے بھی استعمال کیا جا سکتا ہے۔
• beginner-ops-writing اور ops-case-notes اختیاری اضافی مہارتیں ہیں؛ انہیں نصب نہ کرنے سے بنیادی سپردگی اور وصولی کے عمل پر اثر نہیں پڑے گا۔

میزبان منتخب کریں اور نصب کریں

Codex

Codex میں تصدیق شدہ طریقہ ریپوزٹری کے ساتھ موجود .agents/plugins/marketplace.json استعمال کرتا ہے۔ پہلے Codex CLI نصب کر کے لاگ اِن کریں، پھر منصوبے کی جڑ میں یہ کمانڈز چلائیں:

cd /path/to/solo-to-team-skills
codex plugin marketplace add "$(pwd)"
codex plugin add solo-to-team-skills@solo-to-team-skills

اگر کمانڈ غیر صفر اسٹیٹس واپس کرے تو رک جائیں اور تصدیق کریں کہ موجودہ ڈائریکٹری وہ پیکیج روٹ ہے جس میں .agents/plugins/marketplace.json موجود ہے۔ تنصیب کے بعد نیا سیشن کھولیں، یا مہارت استعمال کرنے کے لیے codex exec چلائیں۔

codex exec -s workspace-write --skip-git-repo-check -C "$(pwd)" 'براہِ کرم dispatch-accept-verify مہارت استعمال کرتے ہوئے T044_dispatch_line.md میں وصول ہونا باقی کا ایک اندراج لکھیں'

تنصیب واپس لینے کے لیے یہ کمانڈز چلائیں:

codex plugin remove solo-to-team-skills@solo-to-team-skills
codex plugin marketplace remove solo-to-team-skills

Cursor

مطلوبہ مہارت کی ڈائریکٹری مکمل طور پر صارف کی مہارتوں والی ڈائریکٹری میں نقل کریں:

mkdir -p ~/.cursor/skills/
cp -R skills/dispatch-accept-verify ~/.cursor/skills/
cp -R skills/evidence-before-done ~/.cursor/skills/

اس کے بعد Cursor Agent میں مہارت کے نام سے اسے استعمال کریں۔ cursor agent --print کی CLI شکل بھی استعمال کی جا سکتی ہے۔ نئے ورک اسپیس میں غیر تعاملی عمل کے دوران میزبان --trust استعمال کرنے کا تقاضا کر سکتا ہے؛ یہ پیرامیٹر ورک اسپیس پر اعتماد ظاہر کرتا ہے، حفاظتی طریقۂ کار بند نہیں کرتا۔

WorkBuddy اور CodeBuddy

ان دونوں مصنوعات کے نام ملتے جلتے ہیں، لیکن یہ ایک ہی میزبان نہیں ہیں؛ تنصیب کی ڈائریکٹریاں باہم استعمال نہیں کی جا سکتیں۔

• WorkBuddy: ~/.workbuddy/skills/ یا منصوبے کے اندر .workbuddy/skills/ میں نقل کریں، یا انٹرفیس میں SKILL.md پر مشتمل مہارت کی ڈائریکٹری یا zip اپ لوڈ کریں۔
• CodeBuddy: ~/.codebuddy/skills/ یا منصوبے کے اندر .codebuddy/skills/ میں نقل کریں، پھر انٹرفیس یا CLI میں نام کے ذریعے استعمال کریں۔

متعلقہ سرکاری ہدایات کے لیے WorkBuddy Skills دستاویزات اور CodeBuddy Skills دستاویزات دیکھیں۔

DeepSeek Harness

مہارت کو مکمل طور پر منصوبے کی .dsh/skills/، صارف کی ~/.dsh/skills/، یا .agents/skills/ ڈائریکٹری میں نقل کریں، پھر Harness دوبارہ کھولیں یا ریفریش کریں۔ منصوبے میں واضح کیا گیا ہے کہ dsh plugin add ان مہارتوں کے متن کو نصب کرنے کا طریقہ نہیں ہے۔

استعمال سے پہلے DeepSeek اکاؤنٹ یا API خود تیار کریں؛ یہ منصوبہ کلید فراہم نہیں کرتا۔ تفصیلی طریقۂ کار کے لیے DeepSeek Harness Skills دستاویزات دیکھیں۔

Kimi Work

README میں عملی طور پر Kimi Work ڈیسک ٹاپ ورژن کی تصدیق کی گئی ہے، Kimi Code CLI کی نہیں۔ macOS کے تصدیقی ماحول میں مہارتوں کی ڈائریکٹری یہ ہے:

~/Library/Application Support/kimi-desktop/daimon-share/daimon/skills/

نقل مکمل ہونے کے بعد Kimi Work کے انٹرفیس میں / درج کر کے مہارت منتخب کریں۔ یہ راستہ کمیونٹی کے عملی تجربے سے حاصل ہوا ہے؛ سرکاری طور پر zip، Markdown، لنک یا اسٹور کے ذریعے تنصیب کے طریقے بھی فراہم کیے جا سکتے ہیں، اس لیے موجودہ ہدایات کے لیے Kimi Skills کے سرکاری صفحے کو ترجیح دیں۔

千问办公 QwenWork

مہارت کی ڈائریکٹری یہاں نقل کریں:

~/.qwenworkcn/skills/

اس کے بعد ڈیسک ٹاپ ورژن میں / کے ذریعے مہارت منتخب کریں، یا گفتگو میں براہِ راست اس کا نام لیں۔ 千问办公 اور 通义灵码 ایک ہی مصنوع نہیں ہیں، اس لیے ایک ہی تنصیب کی ڈائریکٹری استعمال نہ کریں۔ QwenWork Skills دستاویزات سے رجوع کیا جا سکتا ہے۔

Grok Bot

Grok Bot مقامی ڈائریکٹری کے ذریعے نصب نہیں ہوتا۔ کسی مہارت کی SKILL.md کھولیں، گفتگو میں کہیں کہ متن کو نجی مہارت کے طور پر محفوظ کیا جائے، اور فائل کے آغاز میں موجود name اور description استعمال کریں۔ چاروں مہارتوں کو الگ الگ محفوظ کرنا ہوگا۔

dispatch-accept-verify محفوظ کرتے وقت اس کا اندراجی سطر کا ٹیمپلیٹ بھی نجی مہارت میں شامل کریں۔ یہ طریقہ صرف ایسے Grok Bot کے لیے ہے جس میں نجی مہارت محفوظ کرنے کی صلاحیت ہو؛ اس کا مطلب یہ نہیں کہ دیگر Grok مصنوعات میں بھی یہی ترتیب استعمال کی جا سکتی ہے۔

Claude Code

ریپوزٹری میں .claude-plugin/plugin.json اور marketplace کا ڈھانچہ پہلے سے موجود ہے، لیکن فی الحال حالت “ڈھانچہ تیار، مکمل عملی تصدیق باقی” ہے، اس لیے اسے پہلے مرحلے کی معاونت نہ سمجھیں۔ اگر خود آزمانا ہو تو موجودہ تنصیب کے طریقے کے لیے Claude Code کی سرکاری پلگ اِن دستاویزات کو بنیاد بنائیں۔

پہلی بار چلانا: چھوٹے کام سے آغاز کریں

شروع ہی میں پیچیدہ منصوبہ متعدد معاونین کو نہ سونپیں۔ پہلے ایسا چھوٹا کام منتخب کریں جس کے نتیجے کی جانچ آسان ہو، مثلاً فراہم کردہ ان پٹ کے مطابق میٹنگ کے نوٹس مرتب کرنا۔ منصوبے میں examples/ کی مرکزی مثال اور examples/walkthrough-meeting-notes/ کا مکمل رہنمائی مواد موجود ہے، جس سے “فراہم کردہ ان پٹ، نتیجہ تیار کرنا، شواہد کی جانچ، انسانی قبولیت، واپس بھیج کر ترمیم” کی مشق کی جا سکتی ہے۔

مرحلہ ایک: مقصد واضح لکھیں

معاون کو کام کا متن، نتیجے کی جگہ، فراہمی کا وقت اور تکمیل کا معیار بتائیں۔ اشارہ درج ذیل ساخت اختیار کر سکتا ہے:

براہِ کرم اس کام کو منظم کرنے کے لیے dispatch-accept-verify استعمال کریں۔
کام: فراہم کردہ ان پٹ کے مطابق میٹنگ کے نوٹس مرتب کریں۔
نتیجے کی جگہ: مخصوص ورک اسپیس فائل۔
فراہمی کا وقت: طے شدہ وقت۔
تکمیل کا معیار: مواد ان پٹ کے مطابق ہو، ضروری شعبے مکمل ہوں، اور میں اسے کھول کر جانچ سکوں۔
براہِ کرم پہلے “وصول ہونا باقی” کا ایک اندراج تیار کریں۔

مرحلہ دو: “وصول ہونا باقی” درج کریں

کام سونپنے سے پہلے اندراجی سطر بنائیں، جس میں کم از کم کام کی حالت، عمل کرنے والا، وصولی کا ذمہ دار، مقررہ وقت پر جانچنے والا، نتیجے کی جگہ اور فراہمی کا وقت واضح ہو۔ بہتر ہے کہ ریپوزٹری میں موجود templates/task-register-line.md براہِ راست نقل کریں، مکمل شعبوں کا اندازہ خود سے نہ لگائیں۔

مرحلہ تین: آرڈر قبول کرنے اور نتیجے کو الگ الگ درج کریں

عملدرآمدی معاون کے کام قبول کرنے کی تصدیق کے بعد "کام قبول کر لیا گیا" درج کریں۔成果 فائل واقعی واپس آنے کے بعد "成果 موصول ہو گیا" درج کریں۔ دونوں حالتوں کو یکجا نہیں کیا جا سکتا، کیونکہ "کسی نے کام کرنے پر رضامندی ظاہر کی ہے" کا مطلب "成果 فراہم کر دیا گیا ہے" نہیں ہوتا۔

مرحلہ چار: شواہد کے ذریعے جانچ

evidence-before-done چلائیں اور معاون سے کہیں کہ تکمیل کے نتیجے کے لیے موجودہ ورژن سے مطابقت رکھنے والے شواہد فراہم کرے۔

براہِ کرم موجودہ成果 کو evidence-before-done کے ذریعے جانچیں۔
حتمی فائل کھولیں اور اصل تقاضوں کے مطابق ایک ایک نکتے کی جانچ کریں۔
اگر کسی حصے میں ترمیم کی گئی ہو یا ناکامی ہوئی ہو تو دوبارہ جانچ کریں۔
شواہد، نامکمل نکات اور تجویز کردہ نتیجہ درج کریں؛ میری طرف سے براہِ راست منظوری نہ دیں۔

شواہد فائل کھولنے کے بعد مواد کی جانچ، کمانڈ کے آؤٹ پٹ، دوبارہ کیے گئے حساب کے نتائج، یا اصل کارروائی کے مراحل کو دوبارہ انجام دینے سے حاصل ہو سکتے ہیں۔ اگر جانچ کے بعد成果 میں دوبارہ ترمیم کی جائے تو متاثرہ حصوں کو دوبارہ جانچنا چاہیے؛ جو حصے تبدیل نہیں ہوئے، ان کے لیے پچھلی جانچ کے نتائج دوبارہ استعمال کیے جا سکتے ہیں۔

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

شواہد کی بنیاد پر فیصلہ کریں کہ منظوری دینی ہے، واپس کرنا ہے یا سمت تبدیل کرنی ہے۔ صرف انسانی تصدیق کے بعد "قبولیت مکمل" درج کریں۔ اگر تقاضے پورے نہ ہوں تو واپسی کی وجہ واضح طور پر لکھیں، عملدرآمدی معاون سے ترمیم کروائیں، اور پھر دوبارہ شواہد حاصل کریں۔

"成果 موصول ہو گیا" کا مطلب "قبولیت مکمل ہو گئی" نہیں ہے۔ کام صرف اس وقت واقعی مکمل سمجھا جائے گا جب شواہد موجودہ成果 سے مطابقت رکھتے ہوں اور انسان منظوری کا فیصلہ کرے۔

ابتدائی سطح کے صارفین کے لیے تجویز کردہ سیکھنے کی ترتیب

1. پہلے examples/ میں موجود مرکزی مثال پڑھیں۔
2. examples/walkthrough-meeting-notes/ کی پیروی کرتے ہوئے واپسی اور ترمیم سمیت ایک چھوٹا کام مکمل کریں۔
3. صرف ایک ٹیمپلیٹ سیکھیں: templates/task-register-line.md۔
4. پہلے نوٹ پیڈ یا اسپریڈشیٹ کے ذریعے "وصولی زیرِ انتظار → کام قبول کر لیا گیا →成果 موصول ہو گیا → قبولیت مکمل" کی مشق کریں۔
5. طریقہ کار سے واقف ہونے کے بعد، کسی معاونت یافتہ Agent میزبان میں مہارت انسٹال کریں اور نام کے ذریعے چلائیں۔

یہ طریقہ خود پیچیدہ پروگرامنگ کی صلاحیت پر منحصر نہیں ہے۔ جب تک آپ کام واضح طور پر لکھ سکتے ہیں، عملدرآمد کرنے والے کو مقرر کر سکتے ہیں اور نتیجے کی جانچ کر سکتے ہیں، آپ مشترکہ ریکارڈ سے آغاز کر سکتے ہیں۔

اعلیٰ سطح کا استعمال

رجسٹریشن کے شعبوں کو موجودہ بورڈ سے جوڑنا

اگر آپ پہلے ہی ٹاسک سسٹم، الیکٹرانک اسپریڈشیٹ یا پروجیکٹ بورڈ استعمال کرتے ہیں تو رجسٹریشن کی قطار کے شعبوں کو موجودہ ورک فلو سے جوڑ سکتے ہیں۔ اہم بات یہ نہیں کہ کون سا ٹول استعمال ہوتا ہے، بلکہ یہ ہے کہ زیرِ وصولی کام ایک نظر میں دکھائی دیں اور کام قبول کرنے،成果 موصول ہونے اور قبولیت مکمل ہونے کو الگ الگ حالتوں کے طور پر رکھا جائے۔

متعدد معاونین کی ذمہ داریاں واضح کرنا

اسکل پیک طریقہ کار اور تحریر فراہم کرتا ہے، جبکہ میزبان سیشن شروع کرنے، کمانڈ چلانے، فائلیں پڑھنے اور لکھنے، اور ممکنہ طور پر مقررہ یاد دہانی یا معاونین کے درمیان پیغامات بھیجنے کی صلاحیت فراہم کرتا ہے۔ انسان اہداف مقرر کرنے، ترجیحات طے کرنے، خطرناک کارروائیوں کی منظوری دینے اور حتمی فیصلہ کرنے کا ذمہ دار ہے۔

ورک فلو بناتے وقت درج ذیل نکات باری باری جانچیں:

• کیا میزبان بیک وقت متعدد سیشن یا ذیلی معاونین شروع کر سکتا ہے؟
• کیا میزبان معاونین کے درمیان پیغامات بھیج سکتا ہے؟
• کیا میزبان کے پاس مقررہ یاد دہانی یا جگانے کی صلاحیت ہے؟
• اگر خودکار یاد دہانی موجود نہ ہو تو وقت پر دستی جانچ کون کرے گا؟
• حتمی قبولیت اور خطرناک کارروائیوں کی ذاتی تصدیق کون کرے گا؟

صرف متاثرہ حصوں کی دوبارہ جانچ

成果 میں ترمیم کے بعد ضروری نہیں کہ تمام جانچیں بلاامتیاز دوبارہ کی جائیں۔ غیر تبدیل شدہ حصوں کے لیے پچھلے دور کے شواہد دوبارہ استعمال کیے جا سکتے ہیں، لیکن تمام ترمیم شدہ، ناکام یا ترمیم سے متاثرہ حصوں کی دوبارہ جانچ ضروری ہے۔ اس طرح قابلِ اعتماد رہتے ہوئے دہرے کام کو کم کیا جا سکتا ہے۔

دستی مراحل لکھنے کے لیے beginner-ops-writing استعمال کرنا

لاگ اِن، ادائیگی یا ذاتی تصدیق جیسے مراحل میں، جنہیں لازماً انسان انجام دے، beginner-ops-writing چلایا جا سکتا ہے تاکہ مراحل کو ایک وقت میں ایک کارروائی کے طور پر تقسیم کیا جائے اور کارروائی کے ہدف اور متوقع نتیجے کو واضح کیا جائے۔ خطرناک کارروائیوں کے معاملے میں صرف "براہِ کرم خود انجام دیں" کہیں؛ معاون سے انسانی اجازت کو نظرانداز کرنے کی کوشش نہ کروائیں۔

جائزے کے لیے ops-case-notes استعمال کرنا

اگر کام قبول کرنے، جانچنے میں کوتاہی یا بار بار ایک ہی غلطی کا سامنا ہو تو ops-case-notes سے رجوع کریں۔ جائزہ درج کرتے وقت طریقہ کار سے متعلق معلومات محفوظ رکھیں: اصل مسئلہ، اختیار کردہ اصلاح، عملی نتیجہ اور باقی رہ جانے والی پابندیاں۔ ساتھ ہی ذاتی رابطے کی معلومات، اسناد، اندرونی راستے اور مشین کی معلومات حذف کر دیں۔

خودکاری کی لازمی حدود

اس پیکج کی پلگ اِن فہرست میں hooks: {} کا مطلب ہے کہ یہ خودکار جگانے کی سہولت فراہم نہیں کرتا۔ اسکل انسٹال کرنے کا مطلب صرف یہ ہے کہ معاون اس طریقہ کار کے مطابق کام کر سکتا ہے؛ اس کا مطلب یہ نہیں کہ نظام خودکار طور پر کام تفویض کرے گا، مقررہ وقت پر یاد دہانی کرائے گا، سیشنز کے درمیان پیغام منتقل کرے گا یا خودکار رسید دے گا۔

• اگر میزبان میں مقررہ وقت کی صلاحیت ہو تو میزبان کی صلاحیت استعمال کرتے ہوئے وقت پر جانچ کی جا سکتی ہے۔
• اگر میزبان میں مقررہ وقت کی صلاحیت نہ ہو تو انسان کو وقت پر خود دیکھنا ہوگا۔
• معاونین کے درمیان اطلاع، گروپ چیٹ اور مشترکہ فائلوں کو پڑھنے لکھنے کا انحصار میزبان پر ہے۔
• رقم خرچ کرنا، لاگ اِن، ادائیگی کی تصدیق، باضابطہ ارسال اور حذف کرنا جیسی کارروائیوں کی منظوری انسان کو دینی ہوگی۔
• قبول کرنا، واپس کرنا یا سمت تبدیل کرنا، حتمی طور پر ہمیشہ انسان کا فیصلہ ہوگا۔

README میں مذکور تقریباً دس منٹ صرف ڈیزائن کے اہداف میں سے ایک ہے؛ اسے پہلے سے تصدیق شدہ ضمانت کے طور پر نہیں لکھا جا سکتا۔ موجودہ Cursor CLI کی پیمائش ایسے حالات میں کی گئی کہ میزبان پہلے ہی انسٹال اور لاگ اِن تھا، ریپوزٹری حاصل کی جا چکی تھی اور پرامپٹ پہلے سے تیار تھا؛ اس میں اسکل نقل کرنے سے رجسٹریشن کی قطار آؤٹ پٹ ہونے تک تقریباً 29.6 سیکنڈ لگے۔ یہ اس بات کی نمائندگی نہیں کرتا کہ کوئی نیا صارف میزبان کو صفر سے انسٹال کر کے پورا کام مکمل کرنے میں مجموعی طور پر کتنا وقت لے گا۔

تنصیب واقعی کامیاب ہوئی یا نہیں، کیسے جانچیں

پروجیکٹ نے دو قطعی معیار دیے ہیں:

1. انسٹال اور چلایا جا سکے: حاصل، تنصیب یا ترتیب مکمل ہو، اسکل نام کے ذریعے چلائی جا سکے، اور جانچ کے قابل رجسٹریشن کی قطار تیار ہو۔
2. ایک حقیقی چھوٹا کام مکمل کیا جا سکے: ہدف، ذمہ داریوں کی تقسیم اور حوالگی سے شواہد کی جانچ اور انسانی فیصلے تک سفر مکمل ہو، اور حقیقی成果، شواہد اور قبولیت کا نتیجہ موجود ہو۔

موجودہ آٹھ میزبانوں میں سے ہر ایک کے لیے محدود کام کی قبولیت کا ایک ریکارڈ موجود ہے، لیکن یہ استحکام کا ثبوت نہیں ہے اور نہ ہی یہ ثابت کرتا ہے کہ تمام کام مکمل کیے جا سکتے ہیں۔ پروجیکٹ نے ابھی تک تقابلی تجربے کے ذریعے یہ تصدیق نہیں کی کہ پوری ٹیم کی غلطیوں کی شرح کم ہوئی یا یاد دہانیوں کی تعداد گھٹی؛ اس لیے استعمال کے دوران انسانی نگرانی برقرار رکھنی چاہیے۔

اختتامیہ

Solo to Team کی قدر مکمل طور پر خودکار AI ٹیم بنانے میں نہیں، بلکہ ایک واضح، قابلِ جانچ اور قابلِ منتقلی تعاون کا طریقہ فراہم کرنے میں ہے۔ پہلے dispatch-accept-verify اور evidence-before-done انسٹال کریں، ایک چھوٹے کام کے ذریعے "وصولی زیرِ انتظار، کام قبول کرنا،成果 موصول ہونا، شواہد کی جانچ، انسانی قبولیت" کی مشق کریں، پھر بتدریج متعدد معاونین اور موجودہ بورڈز شامل کریں۔ آپ کوئی بھی میزبان استعمال کریں، اسی اصول پر قائم رہیں: معاون عملدرآمد اور شواہد فراہم کرنے کا ذمہ دار ہے، جبکہ انسان ہدف، اجازت اور حتمی فیصلے کا ذمہ دار ہے۔