کلاڈ کوڈ کا استعمال کرتے ہوئے سافٹ ویئر فیکٹری کیسے بنائیں: وائب کوڈنگ سے ایجنٹ کی ترقی تک

AI کوڈنگ ٹولز اب خودکار تکمیل سے زیادہ پیش کرتے ہیں۔ وہ کوڈبیس کا تجزیہ کر سکتے ہیں، متعدد فائلوں میں ترمیم کر سکتے ہیں، کمانڈ چلا سکتے ہیں، غلطیوں کی وضاحت کر سکتے ہیں، ٹیسٹ بنا سکتے ہیں، دستاویزات لکھ سکتے ہیں، اور پل کی درخواست کے خلاصے تیار کر سکتے ہیں۔ چھوٹی ملازمتوں کے لیے، یہ خصوصیات متاثر کن ہیں۔ کلاڈ کوڈ، کرسر، یا کوپائلٹ سے کسی خصوصیت کی وضاحت کرنے، اجزاء کو منظم کرنے، یوٹیلیٹی لکھنے، یا کسی واضح بگ کو ٹھیک کرنے کے لیے پوچھنا اکثر عمل کو ہموار محسوس کرتا ہے۔

لیکن اہم خصوصیات کو تیار کرنا دوسرے چیلنجوں کے ساتھ آتا ہے۔

مکمل فعالیت میں صرف کوڈ سے زیادہ شامل ہے۔ پروڈکٹ کے اصول، فن تعمیر کے فیصلے، ایج کیس ہینڈلنگ، ٹیسٹنگ، سیکیورٹی چیک، جائزہ کے معیارات، اور شپنگ کی رکاوٹیں درکار ہیں۔ جیسے جیسے فعالیت بڑھتی ہے، ایک ہی AI سیشن کو بڑھتی ہوئی پیچیدگی کا انتظام کرنا چاہیے۔

یہیں سے کام کا بہاؤ تناؤ شروع ہوتا ہے۔

مثال کے طور پر، آپ AI اسسٹنٹ سے اپنی SaaS بلنگ ایپلیکیشن میں انوائس کی اطلاعات شامل کرنے کے لیے کہہ سکتے ہیں۔ سب سے پہلے، یہ اچھی کارکردگی کا مظاہرہ کرتا ہے: انوائس ماڈلز کی جانچ کرنا، ای میل سروسز کی شناخت کرنا، پس منظر کے کارکنوں کو پہچاننا، منصوبے تجویز کرنا، اور تبدیلیوں کو نافذ کرنا۔ اگر آپ اجازتوں اور ترامیم کو منظور کرتے ہیں، تو ٹیسٹ چلے گا، کوئی بھی خامی دور ہو جائے گی، اور خلاصہ اپ ڈیٹ کر دیا جائے گا۔

سیشن کے بڑھنے کے ساتھ پیچیدگی بڑھ جاتی ہے۔

اب AI کو اصل کاروباری اصولوں، کرایہ داروں کی حدود، دوبارہ کوشش کرنے کے طرز عمل، فائلوں میں ترمیم، ٹیسٹوں میں اضافہ، رکاوٹوں میں ترمیم، اور کن چیزوں کو تبدیل نہیں کرنا ہے اس کی ہدایات پر نظر رکھنا ضروری ہے۔ پیش رفت پہلے سے زیادہ تیز رہے گی، لیکن آپ کا کام کا بہاؤ کم منظم ہوگا۔

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

AI صلاحیتوں کی کمی کی وجہ سے ناکام نہیں ہوتا ہے۔ ورک فلو کا سامنا ہے کیونکہ اس میں کافی ڈھانچہ نہیں ہے۔

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

AI کی مدد سے ترقی کو آگے بڑھانے کے لیے بہتر اشارے سے زیادہ کی ضرورت ہے۔ اس میں ماڈل کے ارد گرد زیادہ موثر نظاموں کو ڈیزائن کرنا شامل ہے۔

اگر یہ منظر آپ کو پسند کرتا ہے، تو اس کا مطلب یہ نہیں ہے کہ آپ کے پاس AI مہارتوں کی کمی ہے۔ اس کے بجائے، یہ اشارہ کرتا ہے کہ آپ کا ورک فلو ٹول کے لیے مناسب نہیں ہو سکتا۔

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

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

کیا سیکھنا ہے۔

• AI کی مدد سے ترقی کس طرح عملی طور پر تیار ہوئی ہے، اور اس کی تاریخ کی شکل ہمیں بتاتی ہے کہ یہ کہاں جا رہی ہے۔

• جیسے ہی آپ کا پروجیکٹ حقیقت بن جاتا ہے "Ask AI” کیوں کام کرنا بند کر دیتا ہے، اور اس کے بجائے آپ کو کیا کرنا چاہیے؟

• AI سے چلنے والے ورک فلو کی پانچ پرتیں: سیاق و سباق، علم، ایجنٹ، ورک فلو، اور ترسیل۔

• کلاڈ کوڈ کے بلڈنگ بلاکس کا استعمال کیسے کریں (CLAUDE.mdمہارتیں، ذیلی ایجنٹ، ہکس) اور کلاڈ کو خود ان میں سے بیشتر تخلیق کرنے دیں۔ (آپ کوئی بھی ٹول استعمال کر سکتے ہیں۔ تصور ایک ہی ہے۔ میں نے سادگی کے لیے ایک ٹول کا انتخاب کیا۔)

• سات خصوصی ایجنٹوں اور آرکیسٹریٹر کا ایک ورکنگ سیٹ کیسے بنایا جائے جو ان کو جوڑتا ہے۔

• یہ ایک ہینڈ آن سیٹ اپ ہے جسے آپ اس ہفتے کے آخر میں اپنے Next.js یا Node.js پروجیکٹ میں کاپی کر سکتے ہیں۔ ایک بار جب آپ تصورات کو سمجھ لیں، تو آپ انہیں کسی بھی پروجیکٹ پر لاگو کر سکتے ہیں۔

• جان بوجھ کر کیا چھوڑا گیا تھا اور مجھے آگے کہاں سیکھنا چاہئے؟

یہ کس کے لیے ہے؟

یہ گائیڈ ان ڈویلپرز کے لیے قابل رسائی ہے جو کلاڈ کوڈ یا کسی بھی AI ٹول میں نئے ہیں، لیکن یہ کافی جامع ہے کہ ایک سینئر انجینئر یا ٹیکنیکل لیڈ کو ورک فلو پیٹرن، آرکیسٹریٹر ڈیزائن، جائزہ چیک لسٹ، اور ڈیلیوری سیکشنز سے فائدہ ہوگا۔

مثالیں Next.js، Node.js، اور SaaS بلنگ ایپلی کیشنز کا حوالہ دیتی ہیں، لیکن تصورات ٹول-اگنوسٹک ہیں۔ وہی اصول لاگو ہوتے ہیں چاہے آپ کرسر، کلاڈ، ایڈر، ونڈ سرف، کلو، کلائن، یا مستقبل کا کوئی ٹول استعمال کریں۔

جو آپ آخر تک بنا سکتے ہیں۔

• کوئی راستہ نہیں CLAUDE.md اپنے پروجیکٹ کے حقائق اور معیارات کو حاصل کریں۔

• سات حسب ضرورت ذیلی ایجنٹ جو منفرد سیاق و سباق میں مرکوز کام انجام دیتے ہیں: محقق، اسٹوری رائٹر، اسپیک رائٹر، بیک اینڈ بلڈر، فرنٹ اینڈ بلڈر، ٹیسٹ ویلیڈیٹر، اور ویلیڈیٹر۔

• ایک آرکیسٹریٹر جو تمام سات ذیلی ایجنٹوں کو کام سونپتا ہے (پہلے ہنر اور پھر اختیاری طور پر ایجنٹوں کو)۔

• ایک دوبارہ قابل استعمال ٹیکنالوجی جو ورک فلو کو انکوڈ کرتی ہے جسے ٹیمیں بار بار انجام دیتی ہیں۔

• حفاظت کے لیے ایک پری کمٹ ہک۔

• ایک مختصر PR جائزہ چیک لسٹ اس بات کو یقینی بنانے کے لیے کہ آپ کی AI سے تیار کردہ پل کی درخواستوں کا ہر بار ایک ہی معیار کے مطابق جائزہ لیا جاتا ہے۔

"سافٹ ویئر فیکٹری” کا اصل مطلب یہی ہے۔ فیکٹری کو آپ کی ضروریات کے مطابق بڑھایا جاسکتا ہے۔ یہ ایک بڑا خود مختار نظام نہیں ہے، بلکہ ایک ذخیرہ میں فائلوں کا ایک چھوٹا سیٹ ہے جو ایک ڈویلپر اور ایک AI کو ایک مربوط ٹیم کے طور پر کام کرنے کی اجازت دیتا ہے۔

انڈیکس

حصہ 1: فیکٹری ری لوکیشن کی بنیادی باتیں

حصہ 2: ایجنٹ فیکٹری بنانا

حصہ 3: نتیجہ

حصہ 1: فیکٹری ری لوکیشن کی بنیادی باتیں

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

1. AI کی مدد سے ترقی کیسے ہوئی؟

کسی بھی چیز کو بنانے سے پہلے، یہ کوڈنگ میں AI کے ارتقا کو سمجھنے میں مدد کرتا ہے۔ یہ پیشرفت کئی مراحل میں ہوئی، ہر ایک نے ایک مخصوص مسئلہ حل کیا اور اگلے مرحلے کو ممکن بنایا۔

شکل 1: AI کوڈنگ کے پانچ مراحل جو آج کے سافٹ ویئر فیکٹری میں تبدیلی کا باعث بنتے ہیں۔

دستی کوڈنگ

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

ہوشیار ایڈیٹر

پھر ایڈیٹرز کام آئے۔ انٹیلی سینس، لینگویج سرور، ای ایس لینٹ، فریگمنٹ انجن، ری فیکٹرنگ ٹولز۔ ان میں سے کسی کو بھی آپ کو کوڈ لکھنے کی ضرورت نہیں ہے، لیکن وہ اس فائل کے اندر موجود رگڑ کو دور کرتے ہیں جس میں آپ پہلے سے ترمیم کر رہے ہیں۔ یہ پہلا قدم تھا جہاں ڈویلپرز نے ایڈیٹرز کو مدد کے لیے دیکھنا شروع کیا۔ معیارات بدل گئے ہیں۔

اسمارٹ خودکار تکمیل

Tabnine اور GitHub Copilot کے ابتدائی ورژن نے قریبی کوڈ کو دیکھا اور پیش گوئی کی کہ آگے کیا ہوگا۔ جب آپ فنکشن لکھنا شروع کرتے ہیں۔ calculateInvoiceTotal(items)ٹول نے اندازہ لگایا کہ ہم اشیاء کے ذریعے اعادہ کرنا چاہتے ہیں، مقدار کو قیمت سے ضرب دینا چاہتے ہیں، اور کل واپس کرنا چاہتے ہیں۔ ایڈیٹر مزید نحو کو مکمل نہیں کر سکتا۔ ارادہ پورا کرنا تھا۔ لیکن آپ اب بھی ڈیزائن کے مالک ہیں۔

AI چیٹ

پھر چیٹ پر مبنی AI آیا اور ورک فلو کو نصف میں تقسیم کر دیا۔ میں نے ChatGPT یا Claude کو دوسرے ٹیب میں کھولا اور لاگ ان پیج یا رجسٹریشن API کی درخواست کی۔ بوائلر پلیٹ کے لیے مفید ہے۔ یہ کسی بھی چیز کے لیے اچھا خیال نہیں ہے جو اصل فولڈر کے ڈھانچے، تصدیق کے بہاؤ، ڈیٹا بیس اسکیما، یا آپ کی ٹیم کے فیصلوں پر منحصر ہو۔ تیار کردہ کوڈ کو جب تنہائی میں دیکھا گیا تو درست نظر آیا، لیکن چسپاں کرنے پر ٹوٹ گیا۔ اس نے مجھے پہلے ٹائپ کیے بغیر مسودہ لکھنے میں مدد کی۔

IDE میں AI

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

یہ قوت سافٹ ویئر بنانے کے طریقے کو تبدیل کر رہی ہے، لیکن صنعت پہلے ہی ایک مختلف سمت میں آگے بڑھ رہی ہے۔ آئیے وائب کوڈنگ ماڈل کے ساتھ مسائل کو دیکھتے ہیں۔

2. وائب کوڈنگ کیوں ناکام ہوتی ہے۔

وائب کوڈنگ ایک ورک فلو ہے جس میں زیادہ تر ڈویلپر اپنے پہلے ہفتے کے دوران AI IDE استعمال کرتے ہیں۔ آپ نے ایک خصوصیت کی درخواست کی ہے۔ AI کوڈ لکھتا ہے۔ کچھ ٹوٹ گیا ہے۔ میں نے غلطی چسپاں کر دی۔ AI پیچ۔ کچھ اور ٹوٹ گیا ہے۔ آپ دوبارہ پوچھیں۔ گول گول۔

یہ پہلے دن تیز محسوس ہوتا ہے۔ آپ 15 منٹ سے بھی کم وقت میں لینڈنگ پیج بنا سکتے ہیں۔ آپ ایک پروٹوٹائپ کی خاکہ نگاری میں ایک دوپہر گزار سکتے ہیں۔ حقیقی ترقی۔

30 دن تک، لوپ دردناک ہو جاتا ہے. یہی منطق تین جگہوں پر نظر آتی ہے۔ AI ان اصولوں کو بھول گیا ہے جو آپ نے دو ہفتے پہلے مرتب کیے تھے۔ نئی خصوصیات موجودہ خصوصیات سے آگے ہیں۔ ٹیسٹ غائب ہیں یا کم ہیں۔ ایپ آج کام کرتی ہے، لیکن کل کام نہیں کرے گی، ایک پیغام کے ساتھ اس سیکیورٹی گارڈ کو ختم کردے گا جسے آپ بھول گئے ہیں۔ اب آپ خود کوڈ لکھنے میں صرف کرنے سے زیادہ وقت AI کی نگرانی میں صرف کرتے ہیں۔

اس کو بہتر بنانے کے لیے ٹیکنالوجی موجود ہے۔ بہتر اشارے لکھیں۔ اچھی دستاویزات کو برقرار رکھیں۔ سیاق و سباق کو سخت رکھیں۔ ہم نے اپنے پچھلے مضمون میں اس میں سے کچھ کا احاطہ کیا ہے کہ AI PR جائزہ کی رکاوٹوں کو کیسے غیر مسدود کیا جائے۔ یہ تکنیکیں مددگار ہوتی ہیں، لیکن جب ایک ہی بات چیت میں بہت سارے کام شامل کیے جاتے ہیں، تب بھی ایک ہی سیشن ختم ہو جاتا ہے، اور یہی وہ چیلنج ہے جسے ہم حل کرنے کی کوشش کر رہے ہیں۔

گہرا مسئلہ: ایک بات چیت میں بہت زیادہ کام

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

ایک AI سیشن کو "ایک خصوصیت بنانا” کے طور پر نامزد کرنا تمام کرداروں کو ایک ہی گفتگو میں سمٹ دیتا ہے۔ AI اسی گندے سیاق و سباق میں اپنے کام کا منصوبہ، ڈیزائن، کوڈ، ٹیسٹ اور جائزہ لیتا ہے۔ یہ خطرناک ہے کیونکہ غلطیاں امتزاج میں ہوتی ہیں۔ منصوبہ بندی میں غلط مفروضے خراب ڈیٹا بیس ماڈلز کا باعث بنتے ہیں۔ ایک خراب ڈیٹا بیس ماڈل خراب API کی طرف جاتا ہے۔ خراب API خراب UI کی طرف جاتا ہے۔ جب تک آپ نوٹس کریں گے، غلطی پوری خصوصیت میں پھیل چکی ہے۔

آپ شاید یہ سوچنا شروع کر رہے ہوں گے کہ AI کی مدد سے ترقی کا اگلا مرحلہ ایک بہتر اشارہ ہے۔ نہیں، ایسا نہیں ہوتا۔ یہ ایک بہتر نظام ہے۔

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

یہ ایک خیال ہر چیز کو آگے بڑھاتا ہے۔

3. AI سے چلنے والے ورک فلو کی پانچ پرتیں۔

تفصیلات میں جانے سے پہلے، اس مضمون میں ہم جو ذہنی ماڈل استعمال کرتے ہیں وہ درج ذیل ہے: عمل میں AI سے چلنے والے ورک فلو کی پانچ پرتیں ہیں۔ ہر ایک اس کے نیچے والے کی طرح کام کرتا ہے۔

شکل 2: پانچ پرتیں۔ ہر ایک اگلے کو کھلاتا ہے۔ پورا اسٹیک ایک سافٹ ویئر فیکٹری ہے۔

نچلے حصے میں سیاق و سباق کی پرت ہے، جو AI موجودہ پیغام میں دیکھتی ہے۔ اس کے اوپر علم کی پرت ہے، ایک مستقل پروجیکٹ میموری جو AI کو ہر سیشن کے آغاز میں وراثت میں ملتی ہے۔ یادداشت کا انتظام بذات خود ایک بڑا موضوع ہے جس کا میں مستقبل کے مضامین میں احاطہ کروں گا (مرکزی یادداشت، مشترکہ علم کے ذخیرے وغیرہ)۔ ابھی کے لیے، کلاڈ کی سیشن میموری پر بھروسہ کریں۔ ایجنٹ پرت اس علم کو اپنے ٹولز اور سیاق و سباق کی کھڑکیوں کا استعمال کرتے ہوئے توجہ مرکوز کارکنوں میں ترجمہ کرتی ہے۔ ورک فلو پرت ایک آرکیسٹریٹر کو ان ایجنٹوں کے اوپر رکھتی ہے اور انہیں توثیق کے دروازوں اور انسانی منظوری کے مقامات کے ذریعے اصل پائپ لائن سے جوڑتی ہے۔ ڈیلیوری پرت یہ ہے کہ ہر وہ چیز جو آپ کی پائپ لائن سے نکلتی ہے – درخواستیں، جائزہ چیک لسٹ، CI گیٹس – محفوظ طریقے سے پروڈکشن تک پہنچتی ہے۔

اگر آپ صرف ایک پرت میں سرمایہ کاری کرتے ہیں تو باقی پرتیں کمزور رہیں گی۔ عظیم ایجنٹوں کے ساتھ ایک ٹیم لیکن اشتراک کرنے سے قاصر ہے۔ CLAUDE.md آپ متضاد کوڈ کے ساتھ ختم ہوتے ہیں۔ بہترین سیاق و سباق کے نظم و ضبط والی ٹیمیں لیکن توثیق کے دروازے کمزور خصوصیات کو جلدی فراہم نہیں کرتے ہیں۔ ماڈل کا نقطہ پانچوں کو بنانا ہے، چاہے ہر ایک چھوٹا شروع ہو۔ اپنی ٹیم میں بہتر اور زیادہ مستقل نتائج کے لیے وہی AI اور ٹولز استعمال کرنے کے لیے یہ ایک اور اہم ٹپ بھی ہے۔

فیکٹری بنانے سے پہلے بنیادی باتوں کو سمجھ لیں۔

اس مضمون کو جان بوجھ کر دو حصوں میں تقسیم کیا گیا ہے۔

حصہ 1 (سیکشن 4 اور 5) بنیادی باتوں کا احاطہ کرتا ہے۔ سیاق و سباق کا انتظام۔ CLAUDE.md. ٹیکنالوجی ہک یہ کوئی فیکٹری نہیں ہے۔ اپنی فیکٹری کے اس پر کھڑے ہونے سے پہلے آپ کو یہ سمجھنے کی ضرورت ہے: اگر آپ اسے چھوڑ کر سیدھے بلڈر کے پاس بھاگتے ہیں، تو فیکٹری ایک ہفتے تک متاثر کن نظر آئے گی اور پھر ٹوٹ جائے گی۔ ایجنٹوں کو ایک گندا سیاق و سباق وراثت میں ملتا ہے۔ آرکیسٹریٹر واضح اصولوں کے بغیر کاموں کو روٹ کرتا ہے۔ تصدیق کنندہ کے پاس تصدیق کرنے کے لیے کچھ نہیں ہے۔

حصہ 2 (سیکشن 6، 7، 8، اور 9) وہ جگہ ہے جہاں ہم دراصل فیکٹری بناتے ہیں۔ 7 خصوصی ایجنٹ۔ آرکیسٹریٹر جو سلسلہ چلاتا ہے۔ ڈیلیوری پرت جو پیداوار میں آؤٹ پٹ حاصل کرتی ہے۔ ہر چیز کو آپ کے اپنے ذخیرے سے جوڑنے کے لیے یہ ہینڈ آن سیکشن ہے۔

حصہ 1 پر نوٹس۔ آپ شاید سیکشن 4 اور 5 پڑھ رہے ہوں گے اور سوچ رہے ہوں گے، "میں ابھی بھی پرامپٹ ٹائپ کر رہا ہوں۔ یہ اضافی مراحل کے ساتھ Vibe کوڈنگ ہے۔” یہ سطح پر منصفانہ ہے، اور میں اسے براہ راست حل کرنا چاہوں گا۔ حصہ 1 میں متعارف کرائی گئی عادات فیکٹریاں نہیں ہیں۔ یہ نظم و ضبط ہے جو فیکٹری کو ممکن بناتا ہے۔ نیویگیشن ورک فلو جو ہم سیکشن 4 میں براہ راست انجام دیتے ہیں وہ ورک فلو سے مماثل ہے جسے Codebase ریسرچ ایجنٹ سیکشن 6 میں خودکار کرتا ہے۔ CLAUDE.md سیکشن 5 میں آپ جو لکھتے ہیں وہی ہر ایجنٹ ہر کام کے آغاز پر پڑھے گا۔ حصہ 1 تحریک سکھاتا ہے۔ حصہ 2 آپ کو سکھاتا ہے کہ مشینوں کو اسے آپ کے لیے کیسے بنانے دیا جائے۔

ہم پہلے ہی اچھے حالات کی حفظان صحت کی مشق کر رہے ہیں۔ CLAUDE.md اگر آپ کو مجھ پر بھروسہ ہے تو، حصہ 1 کو ختم کریں اور سیدھا سیکشن 6 پر جائیں۔ اگر نہیں، تو اپنا وقت نکالیں۔ ایک کارخانہ اتنا ہی اچھا ہے جتنا کہ وہ کھڑا ہے۔

4. سیاق و سباق کی تہہ: پری بلڈ ایکسپلوریشن

سیاق و سباق AI کی ورکنگ میموری ہے۔ یہ پرامپٹس، کھولی ہوئی فائلیں، پچھلے پیغامات، پروجیکٹ کے اصول، داخل کردہ دستاویزات، ٹرمینل آؤٹ پٹ اور غلطیاں ہیں۔ باقی سب کچھ جو آپ دیکھ سکتے ہیں جب کہ ماڈل آپ کی مدد کر رہا ہو۔

سینئر انجینئرز کے سر میں پروجیکٹ کا بہت زیادہ علم ہوتا ہے۔ وہ جانتے ہیں کہ فیصلے کیوں کیے جاتے ہیں، خطرناک فائلیں کہاں واقع ہیں، ٹیم کن نمونوں کی پیروی کرتی ہے، اور کن چیزوں کو چھوا نہیں جانا چاہیے۔ AI خود بخود اس میں سے کسی کو نہیں جانتا ہے۔ یہ صرف جانتا ہے کہ اس تناظر میں کیا ہے۔

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

عادت 1: تعمیر کرنے سے پہلے دریافت کریں۔

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

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

مخصوص مثال۔ فرنٹ اینڈ پر Next.js (ایپ روٹر) اور بیک اینڈ پر Node.js سروسز کا استعمال کرتے ہوئے بنایا گیا SaaS بلنگ پلیٹ فارم چلانے کا تصور کریں۔ ایپ میں صارفین، سبسکرپشنز، انوائسز، اور ادائیگی کی حیثیت کو اپ ڈیٹ کرنے اور ٹرانزیکشنل ای میلز کے لیے ری ڈائریکٹ انضمام کے لیے ویب ہک ہینڈلر ہیں۔ میں بلا معاوضہ رسیدوں کے لیے ایک اطلاعی ای میل شامل کرنا چاہوں گا۔

اگر آپ کلاڈ کوڈ کو "انوائس نوٹیفکیشن شامل کریں” کو کہتے ہیں، تو آپ جوا کھیل رہے ہیں۔ ایسا کرنا ایک معقول بات ہو سکتی ہے۔ آپ ایک نیا شیڈیولر بھی بنا سکتے ہیں اگر آپ کے پاس پہلے سے ہی ہے، ان صارفین کو یاددہانی بھیج سکتے ہیں جنہوں نے پہلے ہی ادائیگی کر دی ہے، ٹائم زون ہینڈلنگ کو نظر انداز کر سکتے ہیں، API پاتھ میں کاروباری قوانین کو ہارڈ کوڈ کر سکتے ہیں، یا آڈٹ لاگز کو مکمل طور پر چھوڑ سکتے ہیں۔ AI برا نہیں ہے۔ AI اندازہ لگا رہا ہے کیونکہ آپ نے پوچھا۔

یہاں ایک کنٹرول شدہ، مرحلہ وار ورژن ہے:

مرحلہ 1۔ پلاننگ موڈ میں کلاڈ کوڈ کھولیں اور صرف پڑھنے کے پرامپٹ سے شروع کریں۔ مقصد یہ ہے کہ کوئی بھی کوڈ لکھنے سے پہلے AI آپ کے کوڈ بیس کے متعلقہ حصوں کی وضاحت کرے۔

I want to add reminder emails for invoices that have been unpaid
for more than 7 days. Before suggesting anything, please:

1. Read the invoice, payment, and email-sending code in this repo.
2. Tell me how invoices are created and where their status is stored.
3. Tell me how transactional emails are sent today.
4. Tell me whether we already have a background job system or scheduler.
5. List the files that would most likely change if we added reminders.

Do not write any code yet. I want a clear map first.

مندرجہ بالا پرامپٹ کو کئی طریقوں سے لکھا جا سکتا ہے۔ اگر CLAUDE.md میں واضح میپنگ نہیں ہے یا آپ بہتر نتائج کے لیے AI کو مزید سیاق و سباق فراہم کرنا چاہتے ہیں، تو آپ docs فولڈر سے بھی رجوع کر سکتے ہیں۔ مقصد شکل دکھانا ہے۔ عمل کرنے سے پہلے سمجھ حاصل کریں۔

مرحلہ 2۔ برائے مہربانی جواب کو غور سے پڑھیں۔ یہ وہ لمحہ ہے جب غلط مفروضوں کو تلاش کیا جا سکتا ہے جبکہ درست کرنا سستا ہے۔ اگر آپ کا AI کہتا ہے کہ "میں cron استعمال کروں گا” لیکن آپ کے پاس واقعی BullMQ کارکن چل رہا ہے، تو اسے ابھی ٹھیک کریں۔ اس کی وجہ یہ ہے کہ کوڈ بیس کو تلاش کرتے وقت آپ کو کوئی BullMQ کوڈ نہیں ملا اور یہ معلومات آپ کے دماغ میں ہونے کا امکان ہے۔

مرحلہ 3۔ اگر نقشہ درست ہے، تو براہ کرم اختیارات طلب کریں، کوڈ نہیں۔ آپ ایک چھوٹا سا موازنہ چاہتے ہیں، حل نہیں.

Based on what you just found, suggest 3 ways we could implement
invoice reminders.

For each option, explain:

- how it would work end-to-end
- which existing parts of the system it reuses
- which new files or DB changes it needs
- the main risks (timezone, multi-tenant, retries, deduplication)
- Which option would you recommend and why

Do not edit any files yet.

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

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

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

مرحلہ 7۔ اسے بنائیں، پھر کلاڈ سے دوبارہ وضاحت کرنے کو کہیں۔ عمل درآمد کے بعد، آنکھیں بند کرکے ارتکاب نہ کریں۔ AI سے اہم فیصلوں کی رہنمائی کرنے، اضافی ٹیسٹوں کی فہرست بنانے، اور آپ کے آپریٹرز کو جاننے کے لیے درکار ہر چیز کے ساتھ دستاویزات کو اپ ڈیٹ کرنے کو کہیں۔ بھروسہ کریں، لیکن تصدیق کریں۔

یہ ورک فلو اس طرح لگتا ہے:

inspect → compare options → pick approach → write brief → start clean → plan → review → build → explain back

اس کا موازنہ وائب کوڈنگ کیسا لگتا ہے۔ prompt → generate → run → paste error → repeat. سب سے پہلے ترقی کو کنٹرول کرنا ہے۔ دوسرا ایک بے ترتیب ترقی ہے جو پیمانہ نہیں ہے۔

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

عادت 2: سیاق و سباق کے بہاؤ سے بچو

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

شکل 3: مبہم پیغامات کس طرح نقصان پہنچاتے ہیں اور اس سے نکلنے کا واحد قابل اعتماد طریقہ ہے۔

حقیقی مثال۔ کلاڈ کو درج ذیل پیغام بھیجیں:

اپنے SaaS میں سبسکرپشن مینجمنٹ شامل کریں۔ صارفین کو سبسکرپشنز بنانے اور بعد میں منسوخ کرنے کے قابل ہونا چاہیے۔

پرامپٹ بہت وسیع ہے۔ AI ملکیت کا اندازہ لگاتا ہے اور کچھ اس طرح پیدا کرتا ہے:

User
└── Subscription
      ├── planName
      ├── status
      └── renewalDate

سطح پر یہ اچھا لگتا ہے۔ پھر ہمیں اصل کاروباری اصول یاد آتے ہیں۔ کمپنی کے اکاؤنٹ میں بہت سے صارفین ہوتے ہیں اور سبسکرپشن کمپنی سے تعلق رکھتی ہے انفرادی صارفین کی نہیں۔ فرق بہت بڑا ہے اور AI پہلے ہی غلط مالک کے ارد گرد ڈیزائن کر چکا ہے۔

بس کہیں "نہیں، سبسکرپشن کمپنی کی ہے” اور کلاڈ اسے پیچ کرنے کی کوشش کرے گا۔ آپ دونوں کے ساتھ ختم user.subscriptionId اور company.subscriptionId ادھر ادھر ادھر ادھر چیزیں چل رہی ہیں، دفاعی تبصرے جو موجود نہیں ہونے چاہئیں، کوڈ کا نام تبدیل کر دیا گیا ہے جو اب بھی پرانے ڈیزائن کی طرح برتاؤ کرتا ہے، وغیرہ۔

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

ایک صاف ستھرا عمل یہ ہوگا کہ چیٹ کو حذف کریں، اصل پرامپٹ میں ترمیم کریں، اور لاگو قوانین کے ساتھ دوبارہ آغاز کریں۔

We need subscription management for our SaaS.

Important business rules:
- Subscriptions belong to a company account, not an individual user.
- A company can have many users.
- Only company admins can change the subscription.
- Billing history is visible to admins only.
- Cancelled subscriptions remain active until the end of the billing period.

Before writing code, inspect our existing account, user, and billing models.
Then suggest an implementation plan. Do not edit files yet.

AI اب صحیح ذہنی ماڈل کے ساتھ شروع ہوتا ہے۔ پہلا ورژن ایک اندازہ ہے۔ دوسرا ورژن ڈیزائن ہے۔

عادت 3: AI کو انسٹال شدہ ورژن پر چسپاں کریں۔

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

بہتر اشارے AI کو خود کو اصل انسٹال شدہ ورژن پر مبنی کرنے پر مجبور کرتے ہیں۔

Before writing code, inspect this project's structure and package.json.

This project uses Next.js App Router. Use the authentication library
version that is actually installed. Look up the current docs for that
specific version. Then explain the recommended file structure before
editing anything.

Tailwind ورژنز، Stripe SDK ورژنز، Prisma migrations، React 18 اور 19 کے درمیان فرق کے بارے میں ایک ہی خیال۔ جہاں بھی حقیقی ورژن-پیٹرن پر انحصار ہو، AI کو تربیتی میموری کی بجائے انسٹال شدہ ورژنز اور موجودہ دستاویزات کی بنیاد پر بنائیں۔ اس کے بغیر، ماڈل اوسط انٹرنیٹ کوڈ تیار کرے گا، غلطیوں کو درست کرتا رہے گا، اور تھوڑی دیر بعد صحیح معلومات پر پہنچ جائے گا۔ یہ ماڈل کو آپ کے پروجیکٹ کے مطابق کوڈ بنانے کی اجازت دیتا ہے۔

یہاں کچھ مفید اوزار شامل ہیں: سیاق و سباق 7۔ ایک پلگ ان جو ہر لائبریری کے عین نصب شدہ ورژن کے لیے موجودہ دستاویزات کو بازیافت کرتا ہے۔ آپ اسے Claude Code میں انسٹال کر سکتے ہیں اور اپنے پرامپٹس یا نالج فائلز میں اس کا حوالہ دے سکتے ہیں، لہذا آپ کے ماڈل کو ہمیشہ کوڈ لکھنے سے پہلے تازہ ترین دستاویزات مل جاتی ہیں۔ میں اسے باقاعدگی سے استعمال کرتا ہوں۔

5. علم کی تہہ: CLAUDE.md، مہارت اور ہکس

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

کلاڈ کوڈ اس پرت کے لیے چار اجزاء فراہم کرتا ہے: صحیح قسم کے علم کے لیے صحیح بلاکس کا انتخاب نصف مہارت ہے۔

شکل 4: چار بلڈنگ بلاکس۔ ہر ایک کلاڈ کوڈ سیشن کو مختلف انداز میں پیش کرتا ہے۔

CLAUDE.md: مستقل حقائق

CLAUDE.md آپ کے ذخیرے کی جڑ میں واقع ایک مارک ڈاؤن فائل (یا پر: ~/.claude/CLAUDE.md انفرادی سطح کی رہنمائی کے لیے)۔ جب بھی آپ اس پروجیکٹ پر کلاڈ کوڈ سیشن کھولتے ہیں تو یہ خود بخود لوڈ ہوجاتا ہے، اور یہ ایک زندہ، مستقل حقیقت ہے۔ اگر آپ کے پاس ایک ذخیرے میں متعدد پروجیکٹس ہیں تو، آپ کے پاس ہر پروجیکٹ کے لیے ایک ہوسکتا ہے۔

کام کرنا CLAUDE.md Next.js + Node.js SaaS بلنگ ایپ کے لیے:

# Project Instructions

This is a SaaS billing application.

## Stack

- Next.js 14 (App Router) with TypeScript
- Node.js services for billing and email
- Prisma + PostgreSQL
- Auth.js for authentication
- Resend for transactional email
- BullMQ for background jobs

## Commands

- npm run dev - start the dev server
- npm test - run unit tests
- npm run typecheck - type-check the project
- npm run lint - lint the project
- npx prisma migrate dev - run migrations locally

## Architecture

- Business logic lives in services or domain modules.
- API routes stay thin and call into services.
- Use the existing email template system; do not add a new one.
- The BullMQ worker handles all scheduled jobs. Do not add cron.
- Tenant isolation is enforced at the service layer, not the route.

## Documentation

For deeper context, consult these before guessing:

- `docs/architecture.md` — service boundaries, request flow, tenant isolation model
- `docs/billing.md` — Stripe webhook handling, invoice lifecycle, proration rules
- `docs/email.md` — template system, Resend setup, list of available templates
- `docs/jobs.md` — BullMQ queue names, job patterns, retry/backoff policy
- `docs/db.md` — schema conventions, tenant isolation patterns, soft-delete rules
- `docs/runbooks/` — production incident runbooks
- `prisma/schema.prisma` — source of truth for the data model
- ADRs in `docs/adr/` — past architecture decisions; read before contradicting one

For Next.js, Prisma, Auth.js, BullMQ, or Resend specifics, check the official docs rather than guessing.

## Testing

- Every feature has success, validation failure, and not-found tests.
- Use test data builders, not inline setup objects.
- Do not mock the database unless existing tests do.

## Don't do

- Do not log raw payment payloads.
- Do not return database errors directly to the client.
- Do not edit migrations after they have been merged.

برقرار رکھنا CLAUDE.md ٹھوس 100 سے 300 لائنیں صحت مند ہیں۔ اگر ایک سیکشن ایک کثیر مرحلہ طریقہ کار میں بڑھتا ہے، تو وہ طریقہ کار تکنیک سے تعلق رکھتا ہے، تکنیک سے نہیں۔ CLAUDE.md. CLAUDE.md یہ حقائق اور قواعد کے لیے ہے۔ ورک فلو مندرجہ ذیل اجزاء پر مشتمل ہے:

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

ٹیکنالوجی: ورک فلوز جو بار بار ٹائپ کرتے ہیں۔

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

یکساں ہدایات کو اپنی چیٹ میں چسپاں کرتے رہنے کے لیے اپنی مہارتیں استعمال کریں: کمٹ فارمیٹ، تعیناتی چیک لسٹ، تعمیراتی عمل، PR کا جائزہ لینے کا نمونہ وغیرہ۔ CLAUDE.md حقائق کے لیے۔ طریقہ کار کے لیے اپنی صلاحیتوں کا استعمال کریں۔

صاف چال یہ ہے کہ آپ کو مہارت خود لکھنے کی ضرورت نہیں ہے۔ کلاڈ یہ آپ کے لیے لکھے گا۔ اپنے پروجیکٹ میں کلاڈ کوڈ کھولیں اور درج ذیل سوالات پوچھیں:

I want to create a Claude Code skill that captures how I build a production feature on this project. The skill should cover:

1. How to read CLAUDE.md and the technical brief before writing code.

2. How to look at 2-3 existing similar features and match their
   patterns.

3. How to write unit tests alongside the production code as normal good engineering (not as a strict TDD red-green loop).

4. How to run typecheck, lint, and the test suite at the end.

5. The conventions our codebase already follows: naming, error handling, where business logic lives, how tests are structured.

Create the skill at .claude/skills/build-with-tests/SKILL.md.
Use the recommended Claude Code skill format with proper YAML
frontmatter (name, description). Make the description specific
enough that the skill triggers automatically when I ask to
build, implement, or extend a feature.

Show me the file before writing it.

کلاڈ موجودہ کوڈ کو پڑھتا ہے، پیٹرن کا اندازہ لگاتا ہے، اور مہارت کی فائلیں تجویز کرتا ہے۔ جائزہ لیں، کسی بھی چیز میں ترمیم کریں جو آپ کے ذائقہ کے مطابق نہ ہو، اور محفوظ کریں۔ ہنر اب ذخیرے کا حصہ ہے اور اسے مستقبل کے تمام سیشنز میں استعمال کیا جا سکتا ہے۔ آپ کلاڈ کے ہنر مند تخلیق کار کا استعمال کرتے ہوئے نئی مہارتوں کو بوٹسٹریپ بھی کر سکتے ہیں۔ /skill-creator create me a new skill....

کلاڈ جو فائلیں بنائے گا ان کی اقسام یہ ہیں:

---
name: build-with-tests
description: Use this skill when implementing a feature or extending existing behaviour. Reads CLAUDE.md and the technical brief first, matches existing patterns, writes production code with unit tests alongside it, and runs the project's typecheck and test commands at the end. Triggers on: "build", "implement", "add", "extend", "ship the feature".
---

Process:

1. Read CLAUDE.md so you know the project rules and stack.
2. Read the technical brief so you stay inside its scope.
3. Look at 2-3 similar features in the codebase. Note their file layout, naming, error handling, and test structure.
4. Implement the feature in the smallest coherent steps you can.
For each step:
   - Write the production code.
   - Write a unit test that covers the new behaviour.
   - Run the test and confirm it passes.
5. When the feature is complete, run the full typecheck, lint,
   and test commands from CLAUDE.md.
6. Return a short summary: files changed, patterns reused, any
   rule you would suggest adding to CLAUDE.md.

Conventions used in this project:

- File names follow the existing folder structure.
- Tests live next to the code they cover (or in tests/ if that
  is the existing pattern).
- Use builders from test/builders/ for any entity setup.
- Cover success, validation failure, and one edge case per
  behaviour.

Rules:

- Do not refactor unrelated code.
- Do not change files outside the agreed scope.
- Do not add new dependencies without explicit instruction.
- If you cannot make the tests pass without violating a rule,
  stop and report the conflict.

اگر آپ اس مہارت کو بچاتے ہیں، تو آپ کو ہر بار اس عمل کو پیسٹ کرنے کی ضرورت نہیں ہے۔ آپ اسے اس طرح لکھ سکتے ہیں:

Use the build-with-tests skill to implement the invoice reminder service.

مہارت کی سب سے عام غلطیاں۔ میگا سکلز سے بچیں۔ ایک واحد SKILL.md جو کمٹ، PRs، برانچ کا نام دینے، اور لاگ اپڈیٹس کو بیک وقت ہینڈل کرنے کی کوشش کرتا ہے کم قابل اعتماد ہو جاتا ہے اور جب دونوں حصوں میں متصادم ہوتا ہے تو ماڈل کو الجھا دیتا ہے۔ اسے تقسیم کریں۔ ایک اچھی مہارت ایک اسکرین پر فٹ بیٹھتی ہے۔

ہکس: خودکار گیٹس اور ورک فلو ٹرگرز

AI ورک فلو کے کچھ حصوں کو یاد رکھنے والے ماڈل پر انحصار نہیں کرنا چاہئے۔

آپ کو ایک پرامپٹ نظر آ سکتا ہے کہ "مکمل ہونے سے پہلے ٹیسٹ چلائیں۔” CLAUDE.md آپ کہہ سکتے ہیں، "خفیہ فائلوں میں ترمیم نہ کریں۔” تکنیک کے بارے میں کہا جا سکتا ہے کہ "PR کھولنے سے پہلے عمل درآمد کی توثیق کریں”۔ لیکن یہ اب بھی ایک رہنما خطوط ہے۔ آپ ماڈل کے بارے میں بھول سکتے ہیں. ماڈلز اسے چھوڑنے کا انتخاب کر سکتے ہیں۔

ہکس مختلف ہیں۔

ہکس خودکار کارروائیاں ہیں جو کلاڈ کوڈ سیشن لائف سائیکل میں مخصوص پوائنٹس پر چلتی ہیں۔ اس پر منحصر ہے کہ آپ اسے کس طرح ترتیب دیتے ہیں، آپ شیل کمانڈ چلا سکتے ہیں، HTTP اینڈ پوائنٹ پر کال کر سکتے ہیں، یا پرامپٹ یا ایجنٹ پر مبنی اسکین کو متحرک کر سکتے ہیں۔

تو ہکس دو مقاصد کے لیے مفید ہیں۔

1. گیٹس۔ اگر کچھ غیر محفوظ ہوتا ہے تو روکیں یا خبردار کریں۔

2. ورک فلو ٹرگر۔ جب کچھ اہم ہوتا ہے، تو یہ دوسرے سسٹمز کو مطلع کرتا ہے۔

سافٹ ویئر فیکٹری میں، ایجنٹ کام کرتے ہیں، لیکن ہکس ایجنٹوں پر قوانین نافذ کرتے ہیں۔

کلاڈ کوڈ ہکس درج ذیل لائف سائیکل واقعات پر چل سکتے ہیں:

• UserPromptSubmit: اس سے پہلے کہ کلاڈ پرامپٹ پر کارروائی کرے۔

• PreToolUse: اس سے پہلے کہ کلاڈ ٹول چلائے۔

• PostToolUse: ٹول کے کامیاب ہونے کے بعد

• Stop: جب کلاڈ نے جواب دینا ختم کر دیا ہے۔

• SubagentStart: جب سبجینٹ شروع ہوتا ہے۔

• SubagentStop: جب ذیلی ایجنٹ مکمل ہو جائے۔

ایک سادہ اور مفید ہک پری کمٹ گیٹ ہے، جو اسناد کی فائل کو کمٹمنٹ ہونے سے روکتا ہے۔ اس کو بطور محفوظ کریں۔ .claude/hooks/pre-commit.sh:

#!/usr/bin/env bash
# Block commits that would include sensitive files.

if git diff --cached --name-only 
   | grep -qE '.(env|key|pem)$|secrets.json|creds.md'; then
  echo "BLOCKED: attempt to commit sensitive files"
  exit 1
fi

کمٹ سے پہلے چلانے کے لیے کلاڈ کوڈ ہک کنفیگریشن سے جڑیں۔ کنفیگریشن نحو آفیشل کلاڈ کوڈ ہکس دستاویزات میں ہے، لیکن یہ JSON کی طرح لگتا ہے اور تقریباً اس طرح لگتا ہے:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/pre-commit.sh"
          }
        ]
      }
    ]
  }
}

یہ جان بوجھ کر کم سے کم ہے۔ ایک حقیقی پروجیکٹ میں آپ یہ بھی استعمال کرسکتے ہیں: PostToolUse ترمیم کرنے کے بعد، فارمیٹر کو چلائیں اور Stop کلاڈ اپنا جواب ختم کرنے سے پہلے قسم کے چیک اور ٹیسٹ چلاتا ہے۔ ایک بار منسلک ہونے کے بعد، ہک کو ہر بار پھانسی دی جائے گی، قطع نظر اس کے کہ ماڈل کیا سوچتا ہے۔

تیزی سے نتائج حاصل کرنے کے چند دوسرے طریقے:

• ترمیم کرتے وقت پوسٹ ٹول کا استعمال کریں۔: فارمیٹر چلائیں تاکہ تمام AI ترمیم شدہ مواد فارمیٹ ہو جائے۔

• روکنا: ٹائپ چیکنگ اور ٹیسٹ چلاتا ہے اور ناکام ہونے کی صورت میں رکنے سے انکار کرتا ہے۔

• Validator میں SubagentStop: ٹیم سلیک چینل کو خودکار طور پر تصدیق کنندہ کے نتائج پوسٹ کرتا ہے۔

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

چار بلاکس ایک ساتھ کیسے فٹ ہوتے ہیں۔

یاد رکھنے کا ایک آسان طریقہ کہ کن بلاکس تک پہنچنا ہے:

• CLAUDE.md میں جواب دیتا ہوں، "یہاں حقائق کیا ہیں؟” منصوبے کے حقائق اور قواعد۔

• ٹیکنالوجی جواب دیں، "یہ کیسے ہوتا ہے؟” دوبارہ قابل عمل عمل۔

• ذیلی ایجنٹ جواب، "یہ کس کو کرنا چاہیے؟” مرتکز کارکن (اگلا حصہ)۔

• ہک جواب دیں "کیا نافذ ہے؟” تعییناتی گیٹ۔

آپ چاروں کو استعمال کریں گے۔ CLAUDE.md یہ AI کو آپ کے کوڈ بیس کے اصول بتاتا ہے۔ ہنر AI کو دوبارہ قابل پلے بک فراہم کرتا ہے۔ ذیلی ایجنٹ توجہ مرکوز کارکن فراہم کرتے ہیں۔ ہک یقینی بناتا ہے کہ قاعدہ حقیقی ہے اور اختیاری نہیں۔

چار بلاکس بنیاد ہیں۔ سیکشن 6 ان کارکنوں کو منظم کرتا ہے جو حقیقت میں فیکٹری کا کام کرتے ہیں۔

حصہ 2: ایجنٹ فیکٹری بنانا

اب حصہ 1 میں جو وعدہ کیا گیا تھا وہ سب سچ ہو گیا ہے۔ ہم جانتے ہیں کہ AI کے سیاق و سباق کو کس طرح صاف رکھنا ہے۔ تم ہو CLAUDE.md آپ اس پر تکیہ کر سکتے ہیں۔ آپ تکنیک اور ہک کو سمجھتے ہیں۔ وہ پہلی منزل ہے۔

اگلے چار حصے خود فیکٹری ہیں۔

سیکشن 6 میں، ہم سات ماہر ایجنٹ بناتے ہیں۔ سیکشن 7 ایک آرکیسٹریٹر کو زنجیر کے اوپر رکھتا ہے تاکہ وہ خود چل سکے۔ سیکشن 8 اس بات کا احاطہ کرتا ہے کہ آپ کے پلانٹ کی پیداوار کو محفوظ طریقے سے کیسے حاصل کیا جائے۔ سیکشن 9 ہر چیز کو آپ کے اپنے ذخیرے میں بنانے کے لیے ایک مشق ہے۔

حصہ 2 کے اختتام تک، آپ کا مینوئل ورک فلو خود چل جائے گا۔ آپ ایک پرامپٹ درج کریں گے۔ آرکیسٹریٹر کام کو روٹ کرتا ہے۔ ایجنٹس مرکوز کام انجام دیتے ہیں۔ آپ منظوری کے تین نکات میں حصہ لیں گے جہاں آپ کا فیصلہ اہم ہے۔ وہ تبدیلی ہے۔

6. ایجنٹ کی پرت: 7 ایجنٹس مرکوز کام انجام دے رہے ہیں۔

اب ہم اس حصے کی طرف آتے ہیں جو فیکٹری کو فیکٹری بناتا ہے۔

اب تک، ہم AI کو بہتر ہدایات اور بہتر میموری دیتے رہے ہیں۔ لیکن اے آئی اب بھی صرف ایک کارکن ہے جو ایک ہی چیٹ میں یہ سب کر رہا ہے۔ چھوٹے کاموں کے لیے یہ ٹھیک ہے۔ یہ اصل فنکشنل کام کی پیمائش نہیں کرتا ہے۔

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

جب بنیادی سیشن ڈیلیگیشن ایک ذیلی ایجنٹ پر کام کرتا ہے، تو ذیلی ایجنٹ اپنے سیاق و سباق میں بہت زیادہ پڑھنا یا پروسیسنگ کرتا ہے۔ مرکزی دھاگے میں صرف ایک مختصر خلاصہ لوٹاتا ہے۔ لمبے لمبے حصے (فائل کی تلاش، لاگ ڈمپ، ملٹی سٹیپ نیویگیشن) کبھی بھی مرکزی ڈائیلاگ کو اوورلوڈ نہیں کرتے۔

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

ہر ایک کے پاس کچھ نہ کچھ ہوتا ہے جس میں وہ اچھے ہوتے ہیں۔ ان میں سے کوئی بھی یہ سب کرنے کی کوشش نہیں کر رہا ہے۔

کیوں ایک بڑا AI سیشن کافی نہیں ہے۔

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

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

کلاڈ سے ایجنٹ کی فائل لکھیں۔

اگر آپ چاہیں تو آپ subagent فائل خود لکھ سکتے ہیں (یہ صرف YAML دیباچے کے ساتھ مارک ڈاؤن ہے)، لیکن ایسا کرنے کی بہت کم وجہ ہے۔ ایک کلینر ورک فلو استعمال کرنا ہوگا: /agents سلیش کمانڈ کلاڈ کو تفصیل سے فائل کا مسودہ تیار کرنے کا سبب بنتی ہے۔

یہ ہے اینڈ ٹو اینڈ ورک فلو: اپنے پروجیکٹ میں کلاڈ کوڈ کھولیں اور ٹائپ کریں:

/agents

یہ ایجنٹ مینجمنٹ کا منظر کھولتا ہے۔ ایک نیا پروجیکٹ لیول ایجنٹ (میں) بنانے کا انتخاب کریں۔ .claude/agents/.md اپنے ذخیرے کو وقف کریں تاکہ آپ کی پوری ٹیم اسے استعمال کر سکے اور کلاڈ سے اسے آپ کے لیے تخلیق کرنے کو کہے۔ کلاڈ پوچھتا ہے کہ ایجنٹ کو کیا کرنا چاہیے، اس کے پاس کون سے اوزار ہونے چاہئیں، اور اسے کس ماڈل کے تحت چلنا چاہیے۔

کلیدی خیال یہ ہے: اپنے مطلوبہ کردار کی وضاحت کریں۔ کلاڈ ایک فائل لکھتا ہے۔ جائزہ لیں، ترمیم کریں، محفوظ کریں اور کمٹ کریں۔ اپنی ٹیم کے لیے درکار تمام ایجنٹس کے لیے دہرائیں۔

ٹول تک رسائی اور ماڈل کا انتخاب ڈیزائن کا حصہ ہیں۔

اس سے پہلے کہ ہم سات ایجنٹوں کو دیکھیں، ہر ایجنٹ پر دو ڈیزائن انتخاب لاگو ہوتے ہیں۔

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

ماڈل منتخب کریں۔ معائنہ اور جائزہ کے لیے ٹاپ ماڈل کی ضرورت نہیں ہے۔ چھوٹے، تیز، سستے ماڈل (ہائیکو) کی طرف روٹ کرنا سب ایجنٹس کی موجودگی کی اصل وجوہات میں سے ایک ہے۔ تصریح لکھنے والے، بلڈر، ٹیسٹ ویریفائر، تصدیق کنندہ، وغیرہ کے لیے جس کے لیے آپ کو ضرورت ہے، ٹاپ لیول ماڈل (Sonnet یا Opus اگر آپ فیصلہ کرتے ہیں کہ کوالٹی اہم ہے) کو محفوظ کریں۔

اچھے ایجنٹ کی تعریف کا تجزیہ

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

جب ابتدائی افراد اپنا پہلا ایجنٹ ڈیزائن کرتے ہیں، تو وہ تقریباً ہمیشہ دو چیزوں سے محروم رہتے ہیں: پہلی حد. آپ ایجنٹ کو بتاتے ہیں کہ کیا کرنا ہے، لیکن آپ اسے نہیں بتاتے کہ کیا نہیں کرنا ہے، اور ایجنٹ دونوں کو ختم کر دیتا ہے۔ دوسرا ہے۔ آؤٹ پٹ فارمیٹ. یہ ایجنٹ کو بتاتا ہے کہ کیا سوچنا ہے، لیکن نتیجہ واپس کرنے کا طریقہ نہیں، اس لیے ہر کال ایک قدرے مختلف شکل پیدا کرتی ہے، اور سلسلہ میں اگلا ایجنٹ اس پر بھروسہ نہیں کر سکتا۔ دونوں ذیل کے سانچے میں ہیں۔

ذیل میں ایک ٹیمپلیٹ اس طرح لکھا گیا ہے جیسے آپ کسی نئے ایجنٹ کو اس کے پہلے دن بریفنگ دے رہے ہوں۔

Subagent name:
  

Purpose:
  One sentence on why this agent exists and what it is for.

Main responsibility:
  One sentence on the single job this agent owns.

What it should investigate / do:
  - Specific thing one
  - Specific thing two
  - Specific thing three
  (Be concrete. "Find similar features already implemented" is
   better than "understand the codebase".)

What it should NOT do:
  - The action it must never take (for example, edit files)
  - The decision it must never make (for example, invent rules)
  - The tool it must never use
  - The scope it must never widen
  (Boundaries are what make an agent's behaviour predictable.)

Tool access:
  Only the tools this agent actually needs.

Model:
  haiku for cheap inspection, sonnet for reasoning,
  opus when reasoning quality is critical.

Output format:
  1. Section one of the result (for example, "Relevant files")
  2. Section two (for example, "Existing patterns to follow")
  3. Section three (for example, "Risks or conflicts")
  (This is the contract with the next agent in the chain.
   A consistent output shape is what makes chaining reliable.)

Behaviour rules:
  - Short, specific rules the agent must follow every time
  - Limits on length, scope, or assumptions
  - When to ask a clarifying question instead of guessing

ایسا ہی لگتا ہے۔ آپ اسے کلاڈ کے حوالے کر دیں۔ /agents سلیش کمانڈ درج کریں اور کلاڈ سے ٹیمپلیٹ سے ایک ایجنٹ فائل تیار کرنے کو کہیں۔ کلاڈ نے اسے ایک مکمل میں بدل دیا۔ .claude/agents/.md درست YAML سابقے، فارمیٹ شدہ سسٹم پرامپٹس، اور ٹول پابندیاں استعمال کریں۔

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

7 ایجنٹ کا جائزہ

ہر آئٹم کو تفصیل سے دیکھنے سے پہلے پوری زنجیر ایک اسکرین پر ظاہر ہوتی ہے۔

نائب	مقصد	اہم پیداوار	سامان
codebase-researcher	کچھ بھی بنانے سے پہلے متعلقہ کوڈ کا نقشہ بنائیں۔	متعلقہ فائلیں، موجودہ پیٹرن، خطرات	پڑھیں، گریپ، گلوب
story-writer	کسی نہ کسی خصوصیت کے خیالات کو صارف کی کہانیوں میں تبدیل کریں۔	کہانیاں، قبولیت کے معیار، کنارے کے معاملات	پڑھیں
spec-writer	منظور شدہ کہانیوں کو تکنیکی بریف میں تبدیل کریں۔	ڈیٹا ماڈل، فلو، API، UI، ٹیسٹنگ، رسک	پڑھیں، گریپ، گلوب
backend-builder	پسدید کے آدھے حصے کی تعمیر	خدمات، APIs، آپریشنز، منتقلی، یونٹ ٹیسٹ	پڑھیں، ترمیم کریں، لکھیں، باش
frontend-builder	فرنٹ اینڈ کے آدھے حصے کی تعمیر	اجزاء، صفحات، ہکس، UI ٹیسٹنگ	پڑھیں، ترمیم کریں، لکھیں، باش
test-verifier	صارف کی کہانیوں کے لیے قبولیت کے ٹیسٹ شامل کریں۔	قبولیت کی جانچ اور کوریج رپورٹس	پڑھیں، ترمیم کریں، لکھیں، باش
implementation-validator	کہانی اور جائزہ بمقابلہ عمل درآمد	نتائج کو شدت کے لحاظ سے گروپ کیا گیا ہے۔	پڑھیں، گریپ، گلوب

یہ سات فیچر آئیڈیا سے PR کے لیے تیار عمودی ٹکڑے تک کے راستے کا احاطہ کرتے ہیں۔ وہ مکمل سیٹ نہیں ہیں۔ یہ ایک مضبوط نقطہ آغاز ہے۔ سیکشن 6 اس سے آگے بڑھتا ہے اور آپ کی لائبریری کو بڑھانے کے طریقوں پر ختم ہوتا ہے۔

اب 7 بناتے ہیں۔

ایجنٹ 1: کوڈ بیس ریسرچر

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

زمرہ /agents براہ کرم درج ذیل وضاحت کا استعمال کریں:

Create a project-level subagent named codebase-researcher.

Its job: inspect this codebase and explain how a specific area
works, without editing anything.

Inputs: a question about an area of the codebase (for example, "how does invoice creation work today?").

Outputs:
- a short list of the relevant files with paths
- a concise summary of the current architecture in that area
- the patterns and conventions in use
- risks or missing information the next agent should know about

Tool access: Read, Grep, Glob only. No Write. No Edit. No Bash.

Recommended model: haiku (this is cheap inspection work).
Recommended color: teal.

Behaviour rules:
- Never edit files.
- Never run commands that modify state.
- Keep the summary under 400 words.
- If a question is ambiguous, ask one clarifying question first.

Claude تفصیل پڑھتا ہے، معقول ڈیفالٹس کا انتخاب کرتا ہے، اور فائل لکھتا ہے۔ آپ کو اپنے ٹرمینل میں کچھ ایسا نظر آئے گا:

میں نے مندرجہ ذیل جگہ پر ایجنٹ بنایا: .claude/agents/codebase-researcher.md اگلے مواد تک۔ ایجنٹ صرف پڑھنے والے ٹولز (ریڈ، گریپ، گلوب) تک محدود ہیں، اس لیے وہ غلطی سے آپ کے کوڈ بیس میں ترمیم نہیں کر سکتے۔ معائنہ کے اخراجات کو کم رکھنے کے لیے، ہم نے ماڈل کو ہائیکو پر سیٹ کیا۔ نئے ایجنٹ کو لوڈ کرنے کے لیے اپنا کلاڈ کوڈ سیشن دوبارہ شروع کریں، پھر اسے استعمال کرتے ہوئے کال کریں: @codebase-researcher اس کے بعد کوڈ کا وہ علاقہ ہے جس کی آپ وضاحت کرنا چاہتے ہیں۔

آپ کو درج ذیل ایجنٹ فائل موصول ہوگی:

---
name: codebase-researcher
description: Read-only investigator that maps the relevant parts of the codebase before any code is written. Returns the files involved, the patterns in use, similar features that already exist, and risks the next agent should know about. Use as the first step of any feature.
tools: Read, Grep, Glob
model: haiku
color: teal
---

You are a read-only investigator for this project. Your only
job is to inspect the codebase and explain how a specific area
works so the next agent has a clear, accurate map to build on.

When invoked, expect a question about an area of the codebase,
for example: "how does invoice creation work today?" or "where
is the email-sending code?".

Produce, every time, in this exact order:

1. **Relevant files**
   File paths grouped by role (services, API routes, models,
   workers, tests). Cite paths exactly.

2. **Existing patterns to follow**
   Naming conventions, folder structure, how business logic is
   organised, how errors are handled, how tests are structured.

3. **Similar feature examples**
   Two or three existing features in the codebase that solve
   a similar shape of problem. Cite paths.

4. **Risks or conflicts**
   Places where the proposed change could break old features,
   tenant boundaries that need to be preserved, timezone
   handling that already exists, anything that smells fragile.

5. **Recommended implementation plan (high level)**
   A short bullet list of how the change should fit into the
   existing system. Do not write code. Do not commit to one
   approach over another if more than one is reasonable.

6. **Tests that should be updated or added**
   Existing test files that probably need updates, plus the
   new test cases you would expect.

7. **Open questions** (only if you have any)
   Things that are genuinely unclear from the codebase. Never
   guess. Ask instead.

Behaviour rules:

- Never edit files.
- Never run commands that modify state.
- Keep the whole summary under 400 words.
- If the user's question is ambiguous, ask one clarifying
  question before investigating.
- Cite every file path exactly.
- If the answer requires running code or seeing live data,
  say so. Do not guess from filenames alone.

آپ ذیل میں تمام ایجنٹوں کے لیے یہی بہاؤ دیکھیں گے۔ پیٹرن ہمیشہ ہے: /agents جب آپ سلیش کمانڈ استعمال کرتے ہیں، تو کلاڈ اصل فائل بناتا ہے، اس کا جائزہ لیتا ہے، اور اسے ریپوزٹری میں بھیج دیتا ہے۔ اگر آپ اسے چھوڑنا چاہتے ہیں۔ /agents آپ تیار کردہ فائلوں کو براہ راست پورے بہاؤ میں چسپاں کر سکتے ہیں۔ .claude/agents/.md اور وہ اسی طرح کام کریں گے۔

ایجنٹ 2: کہانی لکھنے والا

قبولیت کے معیار، ایج کیسز، اور دائرہ سے باہر آئٹمز کے ساتھ کسی نہ کسی خصوصیت کے خیالات کو صارف کی کہانیوں میں تبدیل کریں۔ یہ ایک ایسا ایجنٹ ہے جو کسی بھی کوڈ کے لکھے جانے سے پہلے چیزوں کو پکڑتا ہے۔

Create a project-level subagent named story-writer.

Its job: take a rough feature idea (from the user) plus
exploration findings (from codebase-researcher) and produce
a clear user story.

Inputs:
- a rough feature description
- exploration findings from codebase-researcher
- any product or business rules already known

Outputs:
1. One user story in the form:
   "As a , I want , so that ."
2.- Acceptance criteria that a test can verify directly. Cover the happy path, the obvious failure paths, and the rules from the brief.
3. A list of edge cases worth thinking about.
4. A list of explicitly out-of-scope items.

Tool access: Read only.
Recommended model: sonnet.
Recommended color: purple.

Behaviour rules:
- Use plain language. Avoid jargon.
- Do not invent product rules. If something is unclear, list
  it as an open question instead of guessing.
- Keep the story under one page.

کلاڈ جواب دیتا ہے:

میں نے مندرجہ ذیل جگہ پر ایجنٹ بنایا: .claude/agents/story-writer.md اگلے مواد تک۔ اسے حاصل کرنے کے لیے اپنا سیشن دوبارہ شروع کریں۔ آپ اسے کال کر سکتے ہیں @story-writer مثالی طور پر، یہ ایک خصوصیت کا آئیڈیا ہے جس میں ایک کوڈبیس محقق کے نتائج منسلک ہیں۔

---
name: story-writer
description: Turns a rough feature idea plus codebase exploration findings into a clear user story with acceptance criteria, edge cases, and out-of-scope items. Read-only. Use this after the codebase researcher has produced findings, before any technical brief is written.
tools: Read
model: sonnet
color: purple
---

You are the user story author for this project. Your job is to
turn a rough feature idea into a clear, testable user story
that the rest of the chain can build against.

When invoked, expect to receive:

- A rough feature description from the user.
- Exploration findings from the codebase-researcher agent.
- Optionally, any product or business rules already known.

Produce, every time, in this exact order:

1. **User story**
   One sentence in the form:
   "As a , I want , so that ."

2. **Acceptance criteria**
   Statements that a test can verify directly. Cover the happy
   path, the obvious failure paths, and the rules from the
   brief.

3. **Edge cases worth thinking about**
   Boundary conditions, retries, multi-tenant concerns,
   permission edges, anything that often goes wrong.

4. **Out of scope**
   Things this story explicitly does not cover, so the team
   knows what NOT to build.

5. **Open questions** (only if you have any)
   Things that are genuinely unclear from the input. Never
   invent answers. Always ask instead.

Behaviour rules:

- Use plain language. Avoid product or framework jargon.
- Never invent business rules. If a rule is missing, ask.
- Keep the whole story to one page or less.
- Do not write code or technical design. That is the spec
  writer's job.

ایجنٹ 3: اسپیک رائٹر

منظور شدہ صارف کی کہانیوں اور دریافت کے نتائج کو تکنیکی خلاصوں میں تبدیل کریں۔ ڈیٹا ماڈل میں تبدیلیاں، پس منظر کا بہاؤ، API تبدیلیاں، فرنٹ اینڈ تبدیلیاں، مطلوبہ جانچ، خطرات۔ یہ ایجنٹ صرف پڑھنے کے لیے ہے۔ کوڈ میں ترمیم نہیں کی جا سکتی۔

Create a project-level subagent named spec-writer.

Its job: take an approved user story and exploration findings,
and produce a technical brief that the backend builder, frontend
builder, and test verifier can follow.

Inputs:
- an approved user story
- exploration findings from codebase-researcher
- CLAUDE.md and any relevant project rules

Outputs (one short Markdown document):
- Data model changes
- Background flow / process flow
- API changes (if any)
- Frontend changes (if any)
- Tests required (success, failure, edge cases)
- Risks and open questions
- Files that will change

Tool access: Read, Grep, Glob.
Recommended model: sonnet.
Recommended color: indigo.

Behaviour rules:
- Read CLAUDE.md before writing the brief.
- Prefer reusing existing infrastructure. Call out any new
  scheduler, new database, or new third-party dependency.
- Highlight tenant isolation and timezone concerns explicitly.
- Never edit files.

کلاڈ جواب دیتا ہے:

میں نے مندرجہ ذیل جگہ پر ایجنٹ بنایا: .claude/agents/spec-writer.md اگلے مواد تک۔ ایجنٹ صرف پڑھنے کے لیے ہے اور اسے پڑھنے کے لیے ترتیب دیا گیا ہے۔ CLAUDE.md ہر بریف تیار کرنے سے پہلے، یقینی بنائیں کہ بریف پروجیکٹ کے آرکیٹیکچرل اصولوں کے مطابق ہے۔

---
name: spec-writer
description: Turns an approved user story plus exploration findings into a short technical brief that the build and verification agents can follow. Read-only. Always reads CLAUDE.md before writing. Use after the user story has been approved.
tools: Read, Grep, Glob
model: sonnet
color: indigo
---

You are the technical brief writer for this project. Your job
is to turn an approved user story plus the codebase researcher's findings into a short, actionable brief that downstream agents can follow without ambiguity.

Before writing:

1. Read CLAUDE.md for the project's stack, architecture rules,
   and "don't do" list.
2. Read the user story and the researcher's findings.
3. If something material is missing or unclear, list it as an
   open question. Do not guess.

Output a short Markdown document with these sections, in order:

**Data model changes**

- Which models change. What fields. What types.
- Any migration considerations.

**Background flow / process flow**

- Step-by-step description of how the behaviour runs.
- Which existing infrastructure it reuses.

**API changes**

- New or changed endpoints, with request and response shape.
- Auth and authorization requirements.

**Frontend changes**

- New or changed components, hooks, or pages.
- How they call the API and handle loading / error states.

**Tests required**

- Success cases.
- Failure cases.
- Edge cases (boundaries, retries, deduplication).
- Acceptance tests at the user-story level.

**Risks and open questions**

- Tenant isolation concerns. State them explicitly.
- Timezone concerns. State them explicitly.
- Anything else the team should decide before code is written.

**Files that will change**

- Bullet list of file paths, grouped by backend / frontend / tests.

Behaviour rules:

- Prefer reusing existing infrastructure. Any new scheduler,
  new database, or new third-party dependency must be called
  out explicitly with a justification.
- Tenant isolation and timezone handling must always be
  addressed, even if only to say "no tenant boundary applies"
  or "timezone is irrelevant for this feature."
- Never edit files.
- Keep the whole brief under one page where possible.

ایجنٹ 4: بیک اینڈ بلڈر

یہ بلڈ سائیڈ ایجنٹوں میں سے پہلا ہے۔ وہ کام فنکشن کا بیک اینڈ نصف ہے: API کے راستے، خدمات، ڈیٹا بیس تک رسائی، پس منظر کے کام، اور یونٹ ٹیسٹ جو آپ کے اپنے کوڈ کا احاطہ کرتے ہیں۔ یہ فرنٹ اینڈ فائلوں کو متاثر نہیں کرتا ہے۔

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

Create a project-level subagent named backend-builder.

Its job: implement the backend half of a feature described in
the technical brief. That means API routes, services, database
access, background jobs, and unit tests for the code it writes.

Inputs:
- the approved technical brief
- the codebase researcher's findings
- CLAUDE.md and any relevant project rules
- the build-with-tests skill (project skill)

Outputs:
- backend code that implements the brief
- unit tests that cover the new behaviour
- a short summary: files changed, patterns reused, any rule
  worth adding to CLAUDE.md

Tool access: Read, Edit, Write, Bash. Restricted to backend
folders (services, API routes, workers, migrations, server-side
helpers, and their tests).
Recommended model: sonnet.
Recommended color: green.

Behaviour rules:
- Use the build-with-tests skill for conventions.
- Read CLAUDE.md and the brief before editing anything.
- Only edit backend files. Do not touch React components, pages,
  or client-side hooks.
- Match existing patterns. Reuse existing helpers, services, and templates instead of writing new ones.
- Do not add new dependencies without explicit instruction.
- Run typecheck, lint, and the test suite at the end. Report
  pass/fail and any unexpected failures.
- If a project rule that would have helped is missing from
  CLAUDE.md, surface it as a suggested addition.

کلاڈ جواب دیتا ہے:

میں نے مندرجہ ذیل جگہ پر ایجنٹ بنایا: .claude/agents/backend-builder.md اگلے مواد تک۔ اس ایجنٹ کے پاس بیک اینڈ فولڈر میں مکمل ترمیم اور باش رسائی ہے۔ ہم ہمیشہ قواعد کے لیے بلٹ بائی ٹیسٹ تکنیک کا استعمال کرتے ہیں کیونکہ ہم نے فرنٹ اینڈ فائلوں کو چھوڑنے سے بچنے کے لیے واضح اصول شامل کیے ہیں۔

---
name: backend-builder
description: Implements the backend half of a feature: API routes, services, database access, background jobs, and unit tests. Reads CLAUDE.md, the technical brief, and matches existing patterns. Uses the build-with-tests skill. Restricted to backend folders.
tools: Read, Edit, Write, Bash
model: sonnet
color: green
---

You are the backend implementation worker for this project.
Your job is to implement the backend half of the feature
described in the approved technical brief.

Before you edit anything:

1. Read CLAUDE.md so you know the project rules and stack.
2. Read the technical brief so you stay inside its scope.
3. Load the build-with-tests skill for conventions.
4. Look at 2-3 similar backend features in the codebase and
   match their patterns.

Implementation rules:

- Only edit backend files: services, API routes, workers,
  migrations, server-side helpers, and their tests.
- Never edit React components, pages, or client-side hooks.
  That is the frontend-builder's job.
- Match existing patterns. If a helper, service, or template
  already does what you need, use it instead of writing a new
  one.
- Do not refactor unrelated code.
- Do not add new dependencies without explicit instruction.
- Write unit tests alongside the production code.

After you edit:

1. Run the project's typecheck, lint, and test commands (from
   CLAUDE.md).
2. Confirm all tests pass.
3. Return a short summary:
   - Files added / edited (backend only)
   - Patterns and helpers reused
   - Anything you noticed that would benefit from a CLAUDE.md
     rule

If you cannot complete the work without violating one of the
rules above, stop and report the conflict.

ایجنٹ 5: فرنٹ اینڈ بلڈر

یہ دوسرا بلڈ سائیڈ ایجنٹ ہے۔ اس کا کام اسی فعالیت کا سامنے والا نصف حصہ ہے: یونٹ/اجزاء ٹیسٹ جو اجزاء، صفحات، ہکس، کلائنٹ سائیڈ اسٹیٹ، اور آپ کے اپنے کوڈ کو ہینڈل کرتے ہیں۔ یہ پسدید فائلوں کو متاثر نہیں کرتا ہے۔ بیک اینڈ بلڈر کے ذریعہ پہلے سے تیار کردہ API معاہدہ استعمال کریں۔

Create a project-level subagent named frontend-builder.

Its job: implement the frontend half of a feature described in
the technical brief. That means React components, pages, hooks,
client-side state, and component tests for the code it writes.

Inputs:
- the approved technical brief
- the codebase researcher's findings
- the backend builder's summary (so it knows the API contract)
- CLAUDE.md and any relevant project rules
- the build-with-tests skill (project skill)

Outputs:
- frontend code that implements the brief
- component and unit tests that cover the new behaviour
- a short summary: files changed, patterns reused, any rule
  worth adding to CLAUDE.md

Tool access: Read, Edit, Write, Bash. Restricted to frontend
folders (components, pages, hooks, client-side helpers, and
their tests).
Recommended model: sonnet.
Recommended color: blue.

Behaviour rules:
- Use the build-with-tests skill for conventions.
- Read CLAUDE.md and the brief before editing anything.
- Only edit frontend files. Do not touch services, API routes,
  workers, or migrations.
- Consume the API exactly as the backend builder produced it.
  Do not invent endpoints or response shapes.
- Match existing component patterns: styling, accessibility,
  loading and error states.
- Do not add new dependencies without explicit instruction.
- Run typecheck, lint, and the test suite at the end. Report
  pass/fail and any unexpected failures.
- If a project rule that would have helped is missing from
  CLAUDE.md, surface it as a suggested addition.

کلاڈ جواب دیتا ہے:

میں نے مندرجہ ذیل جگہ پر ایجنٹ بنایا: .claude/agents/frontend-builder.md اگلے مواد تک۔ اس ایجنٹ کے پاس فرنٹ اینڈ فولڈر میں مکمل ترمیم اور باش رسائی ہے۔ اپنے اینڈ پوائنٹس ایجاد کرنے کے بجائے، آپ بیک اینڈ بلڈرز کے ذریعہ تیار کردہ API معاہدے استعمال کرتے ہیں۔

---
name: frontend-builder
description: Implements the frontend half of a feature: components, pages, hooks, client-side state, and component tests. Reads CLAUDE.md, the technical brief, the backend builder's summary, and matches existing component patterns. Uses the build-with-tests skill. Restricted to frontend folders.
tools: Read, Edit, Write, Bash
model: sonnet
color: blue
---

You are the frontend implementation worker for this project.
Your job is to implement the frontend half of the feature
described in the approved technical brief, consuming the API
that the backend builder has already produced.

Before you edit anything:

1. Read CLAUDE.md so you know the project rules and stack.
2. Read the technical brief so you stay inside its scope.
3. Read the backend builder's summary so you know exactly which
   endpoints exist and what they return.
4. Load the build-with-tests skill for conventions.
5. Look at 2-3 similar components or pages in the codebase and
   match their patterns.

Implementation rules:

- Only edit frontend files: components, pages, hooks, client-side helpers, and their tests.
- Never edit services, API routes, workers, or migrations. That
  is the backend-builder's job.
- Consume the API exactly as the backend builder produced it.
  If the shape is wrong for the UI, surface the mismatch as
  feedback instead of patching around it.
- Match existing component patterns. Styling, accessibility,
  loading states, and error handling should look like the rest
  of the codebase.
- Do not refactor unrelated code.
- Do not add new dependencies without explicit instruction.
- Write component or unit tests alongside the production code.

After you edit:

1. Run the project's typecheck, lint, and test commands (from
   CLAUDE.md).
2. Confirm all tests pass.
3. Return a short summary:
   - Files added / edited (frontend only)
   - Patterns and components reused
   - Anything you noticed that would benefit from a CLAUDE.md
     rule

If you cannot complete the work without violating one of the
rules above, stop and report the conflict.

ایجنٹ 6: ٹیسٹ تصدیق کنندہ

ایک بار جب کوئی خصوصیت شروع سے ختم ہونے تک بن جاتی ہے، تو جانچ کے تصدیق کنندگان قبولیت کے ٹیسٹ لکھتے ہیں جو براہ راست صارف کی کہانیاں چلاتے ہیں۔ یونٹ ٹیسٹ کوڈ کے ساتھ بیٹھتے ہیں (بلڈ ایجنٹ کے ذریعہ لکھا گیا)۔ قبولیت کی جانچ یہاں ہے۔ یہ ثابت کرنے کا سلسلہ کا طریقہ ہے کہ فنکشن دراصل وہی کرتا ہے جو کہانی میں کہتا ہے۔

Create a project-level subagent named test-verifier.

Its job: given the approved user story, the approved technical
brief, and a feature that has already been built end to end,
write acceptance tests that exercise the user story and confirm
each acceptance criterion holds.

Inputs:
- the approved user story (with acceptance criteria)
- the approved technical brief
- the backend builder's and frontend builder's summaries
- the build-with-tests skill (project skill)

Outputs:
- one acceptance test file (or one extension of an existing
  one) that covers every acceptance criterion in the story
- a short report of which criteria are covered and which are
  not (only if any are missing or untestable)

Tool access: Read, Edit, Write (test files only), Bash.
Recommended model: sonnet.
Recommended color: yellow.

Behaviour rules:
- Read the user story and the brief before writing.
- Use the build-with-tests skill for conventions.
- Cover every acceptance criterion, plus the edge cases listed
  in the story.
- Do not modify backend or frontend files outside the test
  folder.
- After writing, run the new tests once. Report pass/fail and
  any acceptance criterion that could not be covered cleanly.

کلاڈ جواب دیتا ہے:

میں نے مندرجہ ذیل جگہ پر ایجنٹ بنایا: .claude/agents/test-verifier.md اگلے مواد تک۔ ایجنٹ کا دائرہ صرف فائلوں کی جانچ کے لیے ہے۔ ہم اپنے قواعد کے لیے بلٹ بائی ٹیسٹ تکنیک کا استعمال کرتے ہیں اور دونوں بلڈ ایجنٹوں کے مکمل ہونے کے بعد انہیں چلاتے ہیں، اس لیے ہمارے پاس جانچ کے لیے کام کرنے کی فعالیت موجود ہے۔

---
name: test-verifier
description: Writes acceptance tests against the user story after the build agents have finished. Confirms every acceptance criterion holds against the built feature. Uses the build-with-tests skill. Run after backend-builder and frontend-builder.
tools: Read, Edit, Write, Bash
model: sonnet
color: yellow
---

You are the acceptance test author for this project. Your job is to verify, with tests, that the feature now built end to end
actually satisfies every acceptance criterion in the user story.
 
Before writing:

1. Read the approved user story so you know every criterion.
2. Read the approved technical brief so you know how the
   feature is wired together.
3. Read the backend builder's and frontend builder's summaries
   so you know which endpoints, components, and behaviours exist.
4. Load the build-with-tests skill for conventions.
5. Look at 2-3 existing acceptance tests in the codebase and
   match their style.

Writing rules:

- Cover every acceptance criterion in the user story.
- Cover the edge cases the story lists.
- Use the project's test data builders, not inline setup.
- Follow the project's existing acceptance-test layout.
- Edit only test files. Do not edit any code.

After writing:

1. Run the new tests.
2. If any fail, the feature does not satisfy the story. Report
   exactly which criterion failed and why. Do not patch the
   code. That is for the build agents to fix on the
   next loop.
3. If any criterion cannot be covered cleanly (for example, the
   brief did not name a way to observe it), report it. Do not
   invent a workaround.
4. Return a short summary: criteria covered, criteria failed,
   criteria that need clarification.

ایجنٹ 7: نفاذ کی تصدیق کنندہ

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

Create a project-level subagent named implementation-validator.

Its job: compare the current implementation against the approved user story and technical brief, and report gaps. It does not fix anything.

Inputs:
- the approved user story
- the approved technical brief
- the current state of the implementation (files on disk)
- the test verifier's report

Outputs, grouped by severity:
- critical (must fix before merge)
- important (should fix before merge)
- minor (nice to have)
- recommended next agent

Always check for:
- missing acceptance criteria
- missing tests for failure paths
- security issues (auth checks, tenant isolation, raw error
  exposure, secrets in logs)
- changes to files outside the agreed scope
- inconsistent project patterns (compared to CLAUDE.md and
  existing code)
- duplicate logic that should be reused
- timezone or multi-tenant concerns from the brief that the
  implementation may have missed

Tool access: Read, Grep, Glob.
Recommended model: sonnet (this needs careful reasoning).
Recommended color: red.

Behaviour rules:
- Never edit files.
- Never run destructive commands.
- Always cite the file and line number for each finding.
- If a finding is opinion-based rather than a real risk,
  mark it as such.

کلاڈ جواب دیتا ہے:

میں نے مندرجہ ذیل جگہ پر ایجنٹ بنایا: .claude/agents/implementation-validator.md اگلے مواد تک۔ اسے لوڈ کرنے کے لیے اپنا کلاڈ کوڈ سیشن دوبارہ شروع کریں۔ پھر آپ اسے اس طرح کال کرسکتے ہیں: @implementation-validator زنجیر کے بعد جائزہ لینے کے لیے ایک نفاذ بنایا گیا ہے۔

---
name: implementation-validator
description: Strict reviewer that compares the current implementation against the approved user story and technical brief and reports gaps grouped by severity. Never edits files. Use after the build and verification agents have finished, before opening a PR.
tools: Read, Grep, Glob
model: sonnet
color: red
---

You are an implementation validator for this project. Your only
job is to compare the code on disk against the approved user
story and technical brief, and report what is missing or wrong.
You do not fix anything.

Inputs you should expect:

- The approved user story.
- The approved technical brief.
- The current state of the implementation (files on disk).
- The test verifier's report.

What to check, every time:

- Acceptance criteria from the story that are not implemented.
- Failure paths from the brief that have no test coverage.
- Security issues: missing auth checks, tenant isolation gaps,
  raw error exposure, secrets in logs, missing rate limits on
  sensitive endpoints.
- Changes to files outside the agreed scope.
- Inconsistencies with project patterns documented in CLAUDE.md
  or visible in the existing codebase.
- Duplicate logic that should reuse existing helpers.
- Timezone or multi-tenant concerns called out in the brief
  that the implementation may have missed.

Output format, every time:

**Critical** (must fix before merge)

- 
- ...

**Important** (should fix before merge)

- 
- ...

**Minor** (nice to have)

- 
- ...

**Recommended next agent**

- 

Behaviour rules:

- Never edit files.
- Never run destructive commands.
- Cite the file and line number for every finding.
- Mark opinion-based findings clearly so reviewers can ignore
  them safely.
- If you find no critical or important issues, say so plainly.
  Do not invent issues to look thorough.

یہ 7 مثالیں ہیں اور مکمل سیٹ نہیں ہیں۔

عملی فعالیت فراہم کرنے کے لیے سات ایجنٹ کافی ہیں۔ یہ چھت نہیں ہے۔ پیٹرن کا نقطہ یہ ہے کہ ٹیمیں اس سیکشن میں پہلے سے اناٹومی ٹیمپلیٹ کا استعمال کرتے ہوئے ان ایجنٹوں کو تیار کرتی ہیں جن کی انہیں ضرورت ہے۔ آسمان کی حد ہے۔ جو چاہو تعمیر کرو۔

یہاں ایجنٹوں کی ایک مختصر فہرست ہے جسے آپ آگے شامل کر سکتے ہیں، اس بات پر منحصر ہے کہ آپ کی ٹیم کہاں رگڑ محسوس کرتی ہے۔

• رسائی کا جائزہ لینے والا: نیا UI کوڈ پڑھتا ہے اور پراجیکٹ کے معیارات کے خلاف لیبلز، کنٹراسٹ ایشوز، کی بورڈ ٹریپس اور دیگر مسائل کو جھنڈا لگاتا ہے۔

• سیکورٹی جائزہ لینے والا: توثیق کرنے والے کے سامنے چلتا ہے اور گمشدہ تصدیق، کرایہ داروں کی تنہائی کے فرق، غیر محفوظ ڈیسیریلائزیشن، اور انحصار کے خطرات کی جانچ کرتا ہے۔

• ہجرت مصنف: اپنی خاکہ میں اسکیما تبدیلیوں کو اپنے پروجیکٹ کے نام اور رول بیک کنونشنز کا استعمال کرتے ہوئے Prisma (یا ORM) منتقلی میں تبدیل کریں۔

• ڈیزائن سسٹم کا جائزہ لینے والا: شپنگ سے پہلے ڈیزائن ٹوکنز، وقفہ کے پیمانے، اور موجودہ اجزاء کی لائبریریوں کے خلاف نئے اجزاء کی توثیق کریں۔

• دستاویز اپڈیٹر: حتمی اختلافات کو پڑھیں اور README، فیچر دستاویزات، یا آپریٹر نوٹس کو یہاں اپ ڈیٹ کریں۔

• ریلیز نوٹس مصنف: حالیہ انضمام کو پڑھیں اور ایک تبدیلی کا خلاصہ تیار کریں جو صارفین کو ٹیم کے انداز میں پیش کیا جاتا ہے۔

• ادائیگی کا انضمام: اسٹرائپ ویب ہک کے قواعد کی مکمل معلومات ہر انجینئر کو ادائیگی کے ماہر کی ضرورت کے بغیر ادائیگی سے متعلق فعالیت فراہم کرنے کی اجازت دیتی ہے۔

ہر ایک کی ایک ہی شکل ہے: مرکزی کردار، محدود ٹولز، واضح ان پٹ/آؤٹ پٹ معاہدے، اور طرز عمل کے اصول۔ اناٹومی ٹیمپلیٹ کا استعمال کریں اور اسے کلاڈ کے حوالے کریں۔ /agentsفائل کا جائزہ لیں اور ارتکاب کریں۔ جیسے جیسے آپ کا کوڈ بیس بڑھتا ہے، اسی طرح آپ کی فیکٹری بھی بڑھتی ہے۔ وہ چیزیں جو آپ اپنے ہاتھوں سے کرتے ہیں شامل کرتے رہیں۔ ایسی چیزوں سے چھٹکارا حاصل کریں جن پر آپ کے پیسے خرچ نہیں ہوتے ہیں۔

اگر 7 بہت زیادہ محسوس ہوتا ہے تو، چھوٹا شروع کریں

اگر ہفتے کے آخر میں 7 ایجنٹوں کا ہونا بہت زیادہ بوجھ ہے، تو ایسا نہ کریں۔ اس پیٹرن کے تین سب سے مفید ورژن ہیں:

codebase-researcher → build-with-tests skill → implementation-validator

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

بلٹ ان سب ایجنٹس جو آپ کے پاس پہلے سے موجود ہیں۔

مندرجہ بالا سات میں سے کسی کو بنانے سے پہلے، Claude Code میں پہلے سے ہی کئی ذیلی ایجنٹ شامل ہیں جن کے بارے میں آپ کو معلوم ہونا چاہیے اور جب مناسب ہو استعمال کریں۔

• دریافت کریں یہ صرف پڑھنے کے لیے ہے اور آپ کے کوڈبیس کو تلاش کرنے اور سمجھنے کے لیے تیار کیا گیا ہے۔ یہ سستا اور تیز ہے۔ اگر آپ سخت آؤٹ پٹ فارمیٹ چاہتے ہیں، تو آپ اسے براہ راست استعمال کرسکتے ہیں یا اسے اپنے کوڈبیس ریسرچر میں لپیٹ سکتے ہیں۔

• منصوبہ منصوبہ بندی کے موڈ کے اندر، ہم سیاق و سباق جمع کرتے ہیں اور فائل میں تبدیلیاں ہونے سے پہلے ایک نفاذ کا منصوبہ تجویز کرتے ہیں۔

• عالمگیر ایسے کاموں کو سنبھالتا ہے جن میں نیویگیشن اور ترمیم دونوں کی ضرورت ہوتی ہے۔

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

ایک حقیقی فیکٹری چلانے کے لیے 7 ایجنٹ کافی ہیں۔ آٹھواں ٹکڑا جو ہمیں ایک ساتھ کام کرنے پر مجبور کرتا ہے اگلے حصے میں آرکیسٹریٹر ہے۔

7. ورک فلو پرت: کوآرڈینیٹر جو سلسلہ کو چلاتا ہے۔

اب آپ کے پاس سات ایجنٹ ہیں، ہر ایک ایک کام اچھی طرح کر رہا ہے۔ اگلا سوال یہ فیصلہ کر رہا ہے کہ کون کس ایجنٹ کو، کب، اور کس ترتیب میں بلائے گا۔

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

کارخانے کی بات یہ ہے کہ یہ سلسلہ خود ہی چلتا ہے۔ انسان فیصلہ سازی کے دائرے میں رہتے ہیں (کہانی کی منظوری، بریفنگ کی منظوری، PR کی منظوری)، لیکن ایجنٹوں کے درمیان روٹنگ خودکار ہے۔

ایک آرکیسٹریٹر بالکل یہی کرتا ہے۔

آرکیسٹریٹر کیا ہے؟

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

کلاڈ کوڈ میں اسے بنانے کے چند طریقے ہیں۔ میں آپ کو دو چیزیں دکھاتا ہوں۔

1. مہارت یا سلیش کمانڈ کے ساتھ۔ یہ سٹارٹر ورژن ہے۔ کسی بھی طرح SKILL.md پر فائل جمع کروائیں۔ .claude/skills/feature-factory/SKILL.md (خود بخود متحرک ہوجاتا ہے جب تفصیل آپ کی درخواست کردہ چیز سے میل کھاتی ہے) یا مارک ڈاؤن فائل .claude/commands/feature-factory.md (اگر آپ اسے ٹائپ کرتے ہیں تو یہ چل جائے گا۔ /feature-factory)۔ مواد ایک ہی ہے، لیکن فائرنگ کا طریقہ مختلف ہے۔ یہ آسان ہے، اس میں کوئی نیا تصور نہیں ہے، اور پڑھنا اور ترمیم کرنا آسان ہے۔

2. بطور سب ایجنٹ۔ یہ ایک اعلی درجے کی اپ گریڈ ہے۔ یہ اپنے سیاق و سباق کی ونڈو میں چلتا ہے اور Claude Code کی ذیلی ایجنٹ کالوں کا استعمال کرتے ہوئے سات دیگر ایجنٹوں کو تفویض کر سکتا ہے۔ یہ صاف ستھرا اور زیادہ طاقتور ہے، لیکن اس کے اوپر ایک اور تصور شامل کرتا ہے۔

پہلے مہارت/کمانڈ ورژن بنائیں۔ ایک ہفتہ اس کے ساتھ رہو۔ پھر، جب آپ چین کو اچھی طرح سمجھ لیں کہ آپ زیادہ طاقتور آٹومیشن چاہتے ہیں، تو ایجنٹ ورژن میں اپ گریڈ کریں۔

زنجیر خود

آرکیسٹریٹر جو سلسلہ چلاتا ہے وہ یہ ہے:

انسانی منظوری کے تین نکات ہیں:

1. کہانی کے بعد۔ کیا یہ صحیح مسئلہ ہے؟ کیا قبولیت کا معیار درست ہے؟

2. بریفنگ کے بعد۔ کیا ڈیزائن محفوظ ہے؟ کیا کوڈ لکھے جانے سے پہلے کوئی سرخ جھنڈے ہیں؟

3. تصدیق کے بعد۔ کیا یہ PR بھیجنے کے لیے تیار ہے؟

باقی سب کچھ ایجنٹوں کے درمیان آرکیسٹریٹر روٹنگ کا کام ہے۔

ورژن 1: آرکیسٹریٹر بطور ٹیکنالوجی

اس میں مہارت پیدا کریں: .claude/skills/feature-factory/SKILL.md. کلاڈ سے ایک تخلیق کرنے کو کہیں۔

Create a Claude Code skill at .claude/skills/feature-factory/SKILL.md that orchestrates a feature build using seven existing subagents: codebase-researcher, story-writer, spec-writer, backend-builder, frontend-builder, test-verifier, implementation-validator.

The skill should:
- Trigger when the user asks to build, ship, or implement a
  feature with phrases like "build a feature", "ship a
  feature", "feature factory", "run the full chain".
- Run the chain in the order described below.
- Pause for human approval after the story and after the brief.
  At each approval point, handle three outcomes: approved,
  changes requested, or rejected.
- Run backend-builder first, then frontend-builder, then
  test-verifier.
- Invoke implementation-validator at the end and report
  critical, important, and minor findings.
- If the validator reports critical gaps, loop back to the
  appropriate builder (backend or frontend), then re-run
  test-verifier and the validator.

Order:
1. codebase-researcher: map the area of code involved.
2. story-writer: produce a user story.
3. ASK HUMAN: approve the story.
   - Approved: continue.
   - Changes requested: re-invoke story-writer with the human's
     feedback. Repeat this step until approved or rejected.
   - Rejected: stop the chain. Summarise what was explored so
     the human can decide what to do next.
4. spec-writer: produce a technical brief.
5. ASK HUMAN: approve the brief.
   - Approved: continue.
   - Changes requested: re-invoke spec-writer with the human's
     feedback. Repeat this step until approved or rejected.
   - Rejected: stop the chain. Keep the approved story so the
     human can resume later with a different technical
     approach.
6. backend-builder: implement backend + unit tests.
7. frontend-builder: implement frontend + component tests.
8. test-verifier: write acceptance tests against the story.
9. implementation-validator: report findings.
10. If critical findings: route back to backend-builder or
    frontend-builder, then re-run test-verifier and the
    validator.
11. ASK HUMAN: final review before opening PR.

Show me the skill file before saving it.

کلاڈ کچھ اس طرح پیدا کرتا ہے:

---
name: feature-factory
description: Use this skill when the user asks to build, ship,
  or implement a feature end to end. Runs the full chain of
  seven subagents with human approval points after the story
  and the brief, runs the build agents in order (backend,
  frontend, test-verifier), then validates. Triggers on:
  "build a feature", "ship a feature", "run the factory",
  "feature factory".
---

Process:

1. Invoke the codebase-researcher subagent. Pass the feature
   idea and the relevant area of code. Wait for findings.

2. Invoke the story-writer subagent. Pass the feature idea
   and the researcher's findings. Wait for the user story.

3. Show the story to the user. Ask: "Does this match what
   you want? Reply 'approved' to continue, describe what
   to change, or reply 'reject' to stop the chain."
   - If approved, continue.
   - If changes requested, invoke story-writer again with
     the user's feedback. Repeat this step until approved
     or rejected.
   - If rejected, stop the chain. Summarise what was
     explored so the user can decide what to do next.

4. Invoke the spec-writer subagent. Pass the approved story
   and the researcher's findings. Wait for the technical brief.

5. Show the brief to the user. Ask: "Any design red flags?
   Reply 'approved' to continue, describe what to change,
   or reply 'reject' to stop the chain."
   - If approved, continue.
   - If changes requested, invoke spec-writer again with
     the user's feedback. Repeat this step until approved
     or rejected.
   - If rejected, stop the chain. Keep the approved story
     so the user can resume later with a different
     technical approach.

6. Invoke the backend-builder subagent. Pass the brief and the
   researcher's findings. Wait for the backend implementation
   and its summary.

7. Invoke the frontend-builder subagent. Pass the brief, the
   researcher's findings, and the backend builder's summary
   (so it knows the API contract). Wait for the frontend
   implementation and its summary.

8. Invoke the test-verifier subagent. Pass the approved story,
   the brief, and both builder summaries. Wait for the
   acceptance tests and the verifier's report.

9. Invoke the implementation-validator subagent. Pass the
   approved story, the approved brief, the test verifier's
   report, and the current implementation. Wait for findings.

10. If the validator reports critical findings, route them to
    the right build agent (backend-builder or frontend-builder)
    along with the relevant test from test-verifier. Then
    re-run test-verifier and the validator.

11. Show the validator findings to the user. Ask:
    "Ready to open the PR?"

Rules:

- Never skip the human approval points.
- Never invoke frontend-builder before backend-builder.
- Never invoke test-verifier before both builders have
  finished.
- Never invoke the validator before the chain has produced
  some implementation and the verifier has run.
- Each agent runs in its own subagent context. Pass only
  the inputs that agent needs.
- If any agent reports it cannot complete its task, stop
  and surface the reason to the user.

یہ مکمل آرکیسٹریٹر ہے۔ یہ ایک سنگل مارک ڈاؤن فائل ہے۔ یہ 7 مختلف مارک ڈاؤن فائلوں کو کال کرتا ہے۔ وہ ایک ساتھ مل کر ایک فیکٹری ہیں۔ اب، اگر آپ کو صرف بیک اینڈ اینڈ پوائنٹس بنانے کی ضرورت ہے نہ کہ فرنٹ اینڈ، یا اس کے برعکس؟ تو یہ مکمل طور پر آپ کی ضروریات پر منحصر ہے۔ اسے ایک خاص طریقہ بنائیں۔ مذکورہ بالا صرف ایک مثال ہے۔ آپ کو فیصلہ کرنے کی ضرورت ہے کہ آپ کیا بنانا چاہتے ہیں۔

زنجیروں سے بند عمل: ایک کومپیکٹ اینڈ ٹو اینڈ مثال

کلاڈ کوڈ کھولیں اور ٹائپ کریں:

/feature-factory

I want to add reminder emails for invoices that have been unpaid for more than 7 days.

یہاں اگلے اقدامات ہیں:

مرحلہ 1۔ آرکیسٹریٹر کے مندوبین: codebase-researcher. انوائس، ادائیگی، اور ای میل فائلوں اور ریٹرن کو پڑھنے کے لیے محقق اسے اپنے سیاق و سباق میں چلاتا ہے:

انوائس آگے بنائی جاتی ہے: services/invoices/create.ts. ریاست انوائس ماڈل میں محفوظ ہے۔ لین دین کی ای میلز گزرتی ہیں۔ services/email/send.ts دوبارہ ٹرانسمیشن ٹیمپلیٹ استعمال کریں۔ بل ایم کیو ورکر workers/ ایک کام جو پہلے سے طے شدہ ہے اس پر کارروائی کی جا رہی ہے۔ کوئی موجودہ اطلاع کی منطق نہیں ہے۔ انتظامی UI اس پر واقع ہے: app/(admin)/invoices/. فائلوں میں تبدیلی کا امکان ہے: انوائس ماڈل، نئی یاد دہانی سروس، ای میل ٹیمپلیٹ رجسٹری، مینوئل ٹرگرز کے لیے نیا ایڈمن پیج۔

مرحلہ 2۔ آرکیسٹریٹر کے مندوبین: story-writerفعال خیالات اور نتائج سے بات چیت کریں۔ واپسی:

اکاؤنٹ مینیجر کے طور پر، آپ چاہتے ہیں کہ ماضی کی واجب الادا انوائس کی اطلاعات خود بخود بھیجی جائیں تاکہ آپ کے صارفین کو بغیر دستی فالو اپ کے مطلع کیا جائے۔

منظوری کے معیار:

1. اگر آپ کا انوائس 7 دنوں سے زائد عرصے تک ادا نہیں ہوتا ہے تو آپ کو ایک اطلاع موصول ہوگی۔

2. آپ کو ادا شدہ رسیدوں کے بارے میں مطلع نہیں کیا جائے گا۔

3. ڈپلیکیٹ اطلاعات ایک ہی ونڈو پر نہیں بھیجی جاتی ہیں۔

4. ای میل کی ناکام کوششیں اطلاعات کو بھیجے گئے کے بطور نشان زد نہیں کرتی ہیں۔

5. منتظمین دیکھ سکتے ہیں کہ آخری اطلاع کب بھیجی گئی تھی۔

6. منتظمین مخصوص رسیدوں کے لیے دستی طور پر اطلاعات کو متحرک کر سکتے ہیں۔

انتہائی صورتیں: انوائسز بالکل 7 دن پرانے، دوبارہ کوشش کریں، کرایہ دار کی تنہائی، ٹائم زون۔ دائرہ کار سے باہر: SMS اطلاعات، کسٹمر کی طرف سے ترجیحات۔

مرحلہ 3۔ آرکیسٹریٹر روکتا ہے اور تین اختیارات پیش کرتا ہے: منظور کریں، تبدیلی کی درخواست کریں، یا مسترد کریں۔ آپ نے کہانی پڑھی ہے۔ میں اسے منظور کرتا ہوں کیونکہ یہ میری خواہش کے مطابق ہے۔

مرحلہ 4۔ آرکیسٹریٹر کے مندوبین: spec-writerمنظور شدہ کہانیوں اور محققین کے نتائج سے آگاہ کریں۔ سادہ ڈیٹا ماڈل تبدیلیاں (lastReminderSentAt)، BullMQ بہاؤ، مینوئل ٹرگرنگ کے لیے مینجمنٹ اینڈ پوائنٹس، مینجمنٹ UI ٹائل جو آخری ٹرانسفر کا وقت دکھاتا ہے، مطلوبہ ٹیسٹ، خطرات (ملٹی کرایہ دار، ٹائم زون)۔

مرحلہ 5۔ آپ نے خاکہ پڑھ لیا ہے۔ ایک پیغام دکھایا جائے گا: "ہم پروسیس شدہ انوائس ID کو میموری میں محفوظ کریں گے۔” ڈاکو آپ جواب دیں:

Change the deduplication approach. Do not use in-memory state.
Use the lastReminderSentAt column instead.

آرکیسٹریٹر دوبارہ کال کرتا ہے۔ spec-writerجب خلاصہ اپ ڈیٹ ہوجاتا ہے، تو آپ اسے منظور کرتے ہیں۔

مرحلہ 6۔ آرکیسٹریٹر کے مندوبین: backend-builderایک جائزہ اور محقق کے نتائج فراہم کرتا ہے۔ معمار کے ذریعہ شامل کیا گیا۔ lastReminderSentAt ہم انوائس ماڈل میں ایک نئی یاد دہانی سروس بنائیں گے، اسے موجودہ BullMQ ورکر سے جوڑیں گے، مینوئل ٹرگرز کے لیے مینجمنٹ اینڈ پوائنٹس شامل کریں گے، اور ہر ایک کے لیے یونٹ ٹیسٹ لکھیں گے۔ ٹائپ چیک، لنٹ اور ٹیسٹ سویٹس چلائیں۔ وہ سب سبز ہیں۔ خلاصہ لوٹاتا ہے۔

بیک اینڈ پر عمل درآمد مکمل ہو گیا ہے۔

فائلیں شامل کی گئیں:

• services/reminders/send-overdue.ts

• app/api/admin/invoices/[id]/remind/route.ts

• workers/reminders.worker.ts

ترمیم شدہ فائلیں:

• prisma/schema.prisma (شامل کیا گیا۔ lastReminderSentAt گرمی)

دوبارہ استعمال کریں: prisma، sendEmail، daysAgoموجودہ invoice-reminder ای میل ٹیمپلیٹس، کلاسک BullMQ redisConnection. کرایہ دار کی تنہائی میراث کے ذریعے مینوئل ٹرگر اینڈ پوائنٹس پر نافذ کی جاتی ہے۔ requireSameTenant مددگار

یونٹ ٹیسٹ شامل کیے گئے: 7. سبھی پاس ہو گئے۔ تجویز CLAUDE.md اصول: "یاد دہانی کا کالم ہے۔ lastSentAt پیٹرن۔”

مرحلہ 7۔ آرکیسٹریٹر کے مندوبین: frontend-builderیہ ایک جائزہ پیش کرتا ہے، محققین کے نتائج اور بیک اینڈ بلڈرز کا خلاصہ۔ فرنٹ اینڈ بلڈر خلاصہ سے API معاہدہ پڑھتا ہے، منظم انوائس ٹیبل میں "آخری اطلاع بھیجیں” کالم شامل کرتا ہے، ہر قطار میں "اطلاع بھیجیں” بٹن شامل کرتا ہے جو مینوئل ٹرگر اینڈ پوائنٹ پر پوسٹ ہوتا ہے، بوجھ اور خرابی کی حالتوں کو ہینڈل کرتا ہے، اور اجزاء کے ٹیسٹ لکھتا ہے۔ ٹائپ چیک، لنٹ اور ٹیسٹ سویٹس چلائیں۔ وہ سب سبز ہیں۔ خلاصہ لوٹاتا ہے۔

فرنٹ اینڈ پر عمل درآمد مکمل ہو گیا ہے۔

فائلیں شامل کی گئیں:

ترمیم شدہ فائلیں:

• app/(admin)/invoices/page.tsx (کالم اور بٹن شامل کریں)

دوبارہ استعمال کیا گیا: موجودہ منتظم DataTableموجودہ useMutation API کال کے لیے ہک، موجودہ Toast کامیابی/خرابی کی حیثیت۔ API کا استعمال بالکل اسی طرح کیا جاتا ہے جیسا کہ دستاویزی پسدید خلاصہ ہے۔

اجزاء کی جانچ شامل کی گئی۔ 5. سب پاس ہو گئے۔

مرحلہ 8۔ آرکیسٹریٹر کے مندوبین: test-verifierمنظور شدہ کہانی، خاکہ اور خلاصہ دونوں بلڈرز کو پہنچائیں۔ تصدیق کنندہ ایک قبولیت ٹیسٹ فائل لکھتا ہے جس میں تمام چھ قبولیت کے معیار اور استثنائی صورتیں ہوتی ہیں۔ ایک نیا ٹیسٹ چلائیں۔ رپورٹ:

تحریری قبولیت کے ٹیسٹ: 8 (1 فی قبولیت کا معیار + 2 انتہائی کیسز)۔

7 پاس کیا۔ 1 ناکام ہوا: "کرایہ داروں میں دستی ٹرگر مسترد کر دیا گیا” 403 کے بجائے 200 واپس کرتا ہے۔ ایسا معلوم ہوتا ہے کہ مینجمنٹ اینڈ پوائنٹ بھیجنے سے پہلے کرایہ دار کی تصدیق نہیں کر رہا ہے۔ ہم تصدیق کنندہ سے چیک کرنے کی تجویز کرتے ہیں۔

مرحلہ 9۔ آرکیسٹریٹر کے مندوبین: implementation-validator. تصدیق کنندہ واپس کرتا ہے:

تنقیدی: مینوئل ٹرگر اینڈ پوائنٹ اس بات کی تصدیق نہیں کرتا ہے کہ ایڈمنسٹریٹر کا تعلق اسی کرایہ دار سے ہے جس میں انوائس ہے۔ کمپنی اے ایڈمنسٹریٹر کمپنی بی انوائس کے لیے یاددہانی کو متحرک کر سکتا ہے۔ (app/api/admin/invoices/[id]/remind/route.tsلائن 14۔) requireSameTenant مددگار امپورٹ کیا گیا لیکن بلایا نہیں گیا۔

اہم: نہ ہی ٹیسٹ مندرجہ ذیل معاملات کا احاطہ کرتا ہے: lastReminderSentAt یہ ٹھیک 7 دن پہلے کی بات ہے۔ واضح کریں کہ قواعد کیا ہیں۔ > یا >=.

معمولی: نیا ReminderColumn آپ موجودہ چیزوں کو دوبارہ استعمال کر سکتے ہیں۔ RelativeTime اپنے فارمیٹر کو ان لائن کرنے کے بجائے، یہ ایک جزو ہے۔

مرحلہ 10۔ اہم نتائج کا پتہ چلا ہے۔ آرکیسٹریٹر پیچھے ہٹ جاتا ہے۔ یہ تفویض کیا جاتا ہے: backend-builder تصدیق کنندہ کی دریافت اور توثیق کنندہ کے قبولیت کے ٹیسٹ میں ناکامی کی وجہ سے۔ ترمیم کریں اور بیک اینڈ بلڈر کو کال کریں۔ requireSameTenant دستی ٹرگر اینڈ پوائنٹ پر یونٹ ٹیسٹ دوبارہ چلائیں۔ آرکیسٹریٹر پھر دوڑتا ہے۔ test-verifier. تمام آٹھ قبولیت کے ٹیسٹ پاس کر لیے۔ پھر implementation-validator دوبارہ چلائیں۔ صاف

مرحلہ 11۔ آرکیسٹریٹر حتمی جائزے کے لیے توقف کرے گا اور آپ سے پوچھے گا کہ کیا آپ PR کھولنا چاہتے ہیں۔

یہ ایک کام کرنے والی فیکٹری ہے۔ ایک اشارہ شروع ہوا۔ سات ایجنٹوں نے گہرا کام کیا۔ آرکیسٹریٹر نے سلسلہ کو روٹ کیا اور تین پوائنٹس پر روک دیا جہاں فیصلہ ضروری تھا۔

ورژن 2: آرکیسٹریٹر بطور ذیلی ایجنٹ (جدید)

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

آرکیسٹریٹر کو ذیلی ایجنٹ میں ترقی دینا اسے الگ کر دیتا ہے۔ زمرہ /agents براہ کرم درج ذیل وضاحت کا استعمال کریں:

Create a project-level subagent named feature-orchestrator.

Its job: take a feature idea from the user and run the full
seven-agent chain (codebase-researcher, story-writer, spec-writer, backend-builder, frontend-builder, test-verifier,
implementation-validator), pausing for human approval after the
story and after the brief, running the build agents in order
(backend then frontend then verifier), then validating, then
looping back to the right build agent if the validator finds
critical gaps. Use the feature-factory skill for the exact step
order, including the approve, changes-requested, and rejected
paths at each human approval point.

Inputs:
- a rough feature idea from the user

Outputs:
- a finished implementation in the working directory
- a final summary of what was built, tests added, and any
  validator findings the human chose to waive at the final
  review

Tool access: Task (to invoke other subagents), Read, Bash.
Recommended model: sonnet (this needs reasoning for routing).
Recommended color: gray.

Behaviour rules:
- Use the feature-factory skill as the canonical step order.
- Always invoke other agents through subagent invocation, not
  by inlining their work.
- Always pause at the human approval points described in the
  skill. At each approval point, handle approved, changes
  requested, and rejected paths exactly as the skill defines.
- If any agent fails, surface the failure with the agent name
  and stop. Do not silently retry.
- Never edit code directly. Always go through the
  appropriate build agent.

تحریک مہارت ورژن کے لئے تقریبا ایک جیسی ہے. فرق صرف اتنا ہے کہ آرکیسٹریٹر اب اپنے تناظر میں چلاتا ہے۔ تم اسے کال کرو @feature-orchestrator اور فیچر آئیڈیاز۔ آرکیسٹریٹر کا سیاق و سباق پوری سلسلہ میں محفوظ ہے۔ پہلے سے طے شدہ سیشن صاف رہتا ہے۔

براہ کرم ایک ورژن منتخب کریں۔ آئیے اسے کچھ حقیقی دنیا کے افعال کو نافذ کرنے کے لیے استعمال کریں۔ فیکٹری ظاہر کرتی ہے کہ آپ کے کوڈ بیس کی بنیاد پر کہاں ایڈجسٹمنٹ کی ضرورت ہے۔

یہ کیوں کام کرتا ہے۔

ہر قدم مختلف قسم کے ابہام کو کم کرتا ہے۔ کہانیاں کاروباری ابہام کو کم کرتی ہیں۔ مختصر وضاحت تکنیکی ابہام کو کم کرتی ہے۔ بیک اینڈ بلڈر API کے ابہام کو کم کرتے ہیں۔ فرنٹ اینڈ بلڈرز UI ابہام کو کم کرتے ہیں۔ جانچ کی تصدیق کرنے والے ثابت کرتے ہیں کہ صارف کی کہانیاں اصل میں درست ہیں۔ توثیق کرنے والے پکڑتے ہیں کہ دوسرے کیا کھوتے ہیں۔ جب تک یہ سلسلہ تصدیق کنندگان تک نہیں پہنچتا، اس کی فعالیت ہر اس چیز سے محدود ہوتی ہے جو پہلے آئی تھی۔ تصدیق کنندہ کو صرف اس فرق کی جانچ پڑتال کرنے کی ضرورت ہوتی ہے کہ مختصر میں کیا مطالبہ کیا گیا ہے اور کوڈ کیا کرتا ہے۔

آرکیسٹریٹر اس سلسلہ کو "ورک فلو جو یاد رکھتا ہے کہ اسے چلانے کی ضرورت ہے” سے "ورک فلو جو اپنے طور پر چلتا ہے، لوپ میں صرف اس وقت شامل ہوتا ہے جب یہ ضروری ہو۔”

یہ موڈ کوڈنگ سے فیکٹری سوچ کی طرف ایک تبدیلی ہے، اور اس پورے مضمون میں ذہنیت کی سب سے بڑی تبدیلی ہے۔

سلسلہ کی توسیع

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

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

فیکٹری اسی طرح بڑھتی ہے جس طرح آپ کا اصل کوڈ بیس بڑھتا ہے۔ چھوٹی شروعات کریں۔ اپنے وہ کام شامل کریں جن پر آپ کی ٹیم کام کر رہی ہے۔ ایسی چیزوں سے چھٹکارا حاصل کریں جن پر آپ کے پیسے خرچ نہیں ہوتے ہیں۔

Execute پڑھنے کو متوازی اور ترتیب میں لکھتا ہے۔

ایک حتمی ڈیزائن کا اصول جو آپ کو بہت زیادہ تکلیف سے بچائے گا۔

صرف پڑھنے والے ایجنٹ متوازی طور پر چل سکتے ہیں۔ یہ ڈسک پر موجود کسی بھی فائل کو نہیں چھوتا، اس لیے ایک ہی وقت میں دو یا دو سے زیادہ فائلیں چلتی ہیں آپس میں متصادم نہیں ہو سکتیں۔ متوازی طور پر چلنا سب سے آسان رفتار ہے جو آپ اس مجموعی سیٹ اپ سے حاصل کر سکتے ہیں۔ مثال کے طور پر، فرض کریں کہ آپ چار سروسز کو برقرار رکھتے ہیں اور اپنے سہ ماہی جائزے سے پہلے ہر سروس کے لیے دستاویزات کو تازہ کرنے کی ضرورت ہے۔ آپ متوازی طور پر چار کوڈ بیس-ریسرچر سب ایجنٹس چلا سکتے ہیں، ایک فی سروس۔ ہر ایک اپنا کوڈ بیس پڑھتا ہے، تبدیلیوں کا خلاصہ کرتا ہے، اور آزادانہ طور پر نتائج دیتا ہے۔ پھر، چار دستاویز اپ ڈیٹ کرنے والے ایجنٹس، ایک فی سروس، نتائج حاصل کرتے ہیں اور ہر ایک README کو متوازی طور پر دوبارہ لکھتے ہیں۔ ہر دستاویز اپڈیٹر ایک مختلف ذخیرہ پر کام کرتا ہے، اس لیے وہ ایک ہی فائل پر تنازعہ نہیں کر سکتے۔ 4 متوازی پڑھنا، 4 متوازی لکھنا، اور گھسیٹنا اب تیزی سے مکمل ہو گیا ہے۔

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

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

انگوٹھے کا اصول: کوئی بھی چیز جس میں ہو۔ Read، Grepیا Glob صرف متوازی طور پر رسائی کو چلانا محفوظ ہے۔ جو بھی Edit، Writeیا Bash رسائی صرف اس لین میں ہونی چاہیے۔

متوقع ناکامی موڈ

اس طرح کی زنجیر چلانے والی کسی بھی ٹیم کو پہلے چند ہفتوں میں کچھ ایسے ہی چیلنجز کا سامنا کرنا پڑتا ہے۔ ان میں سے کوئی بھی فیکٹری کو تباہ نہیں کرتا۔ نوٹ کرنے کی چیزیں مندرجہ ذیل ہیں: یہاں ہر ایک کے لیے ایک فوری حل ہے:

• آرکیسٹریٹر انسانی منظوری کو چھوڑ دیتا ہے۔ مہارت یا ایجنٹ میں واضح طور پر منظوری کا مرحلہ بنائیں (ASK HUMAN: approve the story)۔

• ایجنٹ خود بخود کام کے حصوں کا خلاصہ کرتا ہے۔ اپنے آؤٹ پٹ فارمیٹ میں "What’s Covered/Skipped” چیک لسٹ شامل کریں۔

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

• سیشن میں سیاق و سباق کی مڈچین کی کمی ہے۔ برقرار رکھنا CLAUDE.md ہر اہم خصوصیت کے لیے ایک نیا مرکزی سیشن شروع کریں۔

• سلسلہ بالکل ٹھیک چلتا ہے، لیکن تفصیلات نے کاروباری قواعد کو غلط سمجھا ہے۔ یہی وجہ ہے کہ کہانی کی منظوری انسانوں کے لیے ایک مشکل چوکی ہے۔

• فرنٹ اینڈ بلڈر اینڈ پوائنٹ بناتا ہے جو بیک اینڈ بلڈر نہیں بناتا ہے۔ بیک اینڈ سمریز کو درست طریقے سے استعمال کرنے کے لیے فرنٹ اینڈ بلڈر کے قوانین کو بہتر بناتا ہے۔ سطح کی تضادات فیڈ بیک ہیں، پیچ نہیں۔

ایک اچھی فیکٹری غلطیوں کو تلاش کرنا آسان بناتی ہے، تلاش کرنا مشکل نہیں۔

8. ڈیلیوری پرت: PR، جائزے اور نئی SDLC

اب تک، یہ مضمون ایک کی بورڈ چیز سے زیادہ رہا ہے۔ آئیے زوم آؤٹ کریں۔

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

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

شکل 6: جب آرکیسٹریٹر کوڈنگ کی کوشش کو جذب کرتا ہے تو SDLC کو کس طرح دوبارہ منظم کیا جاتا ہے۔ ہینڈ آف ٹوٹ جاتا ہے۔ جائزہ اور فیصلہ انسان ہے۔

اب ایک انجینئر مکمل عمودی ٹکڑا مکمل کر سکتا ہے۔

جیسا کہ سلسلہ بھاری لفٹنگ کرتا ہے، SDLC کی شکل بدل جاتی ہے۔

اس سے پہلے، خصوصیات ماہرین کی قطار میں منتقل ہوتی تھیں۔ فرنٹ اینڈ انجینئرز جن کو نئے API اینڈ پوائنٹس کی ضرورت ہے وہ بیک اینڈ انجینئرز کا انتظار کر رہے ہیں۔ بیک اینڈ انجینئرز جنہیں UI کی ضرورت تھی وہ فرنٹ اینڈ انجینئرز کا انتظار کر رہے تھے۔ نئی خصوصیات جاری ہونے سے پہلے تین یا چار لوگوں کے کام سے گزرتی ہیں، اور زیادہ تر وقت، کام صرف کسی اور کے جائزے کی قطار میں بیٹھتا ہے۔

اب وہی انجینئر شروع ہوتا ہے۔ /feature-factoryسلسلہ آخر سے آخر تک چلتا ہے (بیک اینڈ، فرنٹ اینڈ، قبولیت کی جانچ، توثیق) اور ایک مکمل عمودی سلائس کو ایک PR کے طور پر نامزد کیا گیا ہے۔ سڑک پر ایک شخص۔ زیرو ہینڈ آف۔ سیکشن 11 میں، ہم اس مسئلے پر واپس آتے ہیں اور دریافت کرتے ہیں کہ ٹیموں اور وسیع تر صنعت کے لیے اس کا کیا مطلب ہے۔ اب اہم بات یہ ہے کہ کام کی اکائی بدل گئی ہے۔ اس کا مطلب یہ ہے کہ فعالیت ٹکڑے ٹکڑے کی بجائے پوری چین سے آتی ہے۔

اسٹیک خصوصیات، ایک خصوصیت کے اندر نہیں۔

ہینڈ آف کے بعد، اگلا سوال ہے، "جب میں آخری PR کا جائزہ لیتا ہوں تو مجھے کیا کرنا چاہیے؟” جواب دوسرا فعل ہے۔ اور تیسرا۔

اس سے میل کھاتا ہے کہ پیٹرن ہے جمع شدہ PRتاہم، اسٹیکنگ یونٹ فی فیچر ایک PR ہے، فی فیچر سلائس ایک PR نہیں۔ ہر PR ایک مکمل عمودی ٹکڑا ہے جسے ایک سلسلہ کے عمل سے بنایا گیا ہے۔

حقیقت میں یہ اس طرح ہے۔ مکمل فنکشن A. PR A کو اس میں کھولیں: feature-a کے خلاف main. A کے نظرثانی کے انتظار میں آپ نہیں رکتے۔ آپ شاخ ہیں feature-b اوپر feature-a (اوپر نہیں۔ main، شروع کریں۔ /feature-factory ہم مندرجہ ذیل خصوصیات کے لیے PR B بھیجتے ہیں: feature-a. شاخیں ختم ہو جاتی ہیں جبکہ A اور B دونوں زیر جائزہ ہیں۔ feature-c اوپر feature-b اور پھر ہم تیسرا شروع کرتے ہیں۔

آرڈر اہم ہے۔ پہلے ضم ہونا ضروری ہے۔ پھر بی main اور پھر انضمام۔ پھر C ہے۔ main اور پھر انضمام۔ ٹولز جیسے گریفائٹ، سیپلنگ، یا گٹ کے اپنے ٹولز git rebase --onto جب اپ اسٹریم PRs کو ضم کیا جاتا ہے تو خودکار طور پر ری بیس کو ہینڈل کرتا ہے۔ زیادہ تر وقت آپ کو اس کے بارے میں سوچنے کی ضرورت نہیں ہے۔

اسے محفوظ رکھنے کے لیے دو اصول ہیں:

سب سے پہلے زنجیر کا احترام کریں۔ اگر C کا انحصار B پر ہے تو B سے پہلے C کو ضم کرنے کی کوشش نہ کریں۔ برانچنگ گراف پہلے سے ہی اسے نافذ کر دے، لیکن یہ اونچی آواز میں کہنے کے قابل ہے کیونکہ اگر ابتدائی PR کا جائزہ لینے میں بہت زیادہ وقت لگتا ہے تو آگے جانے کا لالچ حقیقی ہے۔

دوسرا ایک فنکشن کو اسٹیک میں تقسیم نہ کریں۔ ایک خصوصیت ایک PR ہونی چاہیے۔ اگر آپ اپنی مائیگریشن کو PR 1 میں، آپ کے بیک اینڈ کو PR 2 میں، اور آپ کا UI PR 3 میں رکھنا چاہتے ہیں، تو اس کا عام طور پر مطلب ہے کہ آپ نے ایک ہی دوڑ میں بہت سی زنجیریں بنا لی ہیں۔ واپس جائیں اور کہانی کی سطح پر تقسیم کریں (سیکشن 7) اور اس کے بجائے دو چھوٹی زنجیریں چلائیں۔ ہر سلسلہ اب بھی ایک خصوصیت پیدا کرتا ہے، اور ہر خصوصیت اب بھی ایک PR کے ساتھ آتی ہے۔

فیکٹری کی بات یہ ہے کہ ایک انجینئر کسی کا انتظار کیے بغیر ایک فنکشن مکمل کر سکتا ہے۔ مجموعی PRs خود کو خود جائزہ کی قطار سے روکے بغیر متعدد خصوصیات کو آگے بڑھنے کا ایک طریقہ ہے۔

یہ وہ سمت ہے جس کی طرف سافٹ ویئر انڈسٹری جا رہی ہے۔ چھوٹی ٹیمیں، کم ہینڈ آف، اور تمام انجینئرز جو مکمل فعالیت فراہم کرتے ہیں۔ جو ٹیم پہلے وہاں پہنچتی ہے وہ بہترین AI ٹولز کے ساتھ نہیں ہوگی۔ وہ وہی ہوں گے جو ان کے پاس پہلے سے موجود AI ٹولز کے ارد گرد صاف ستھری فیکٹریاں بناتے ہیں۔

PR جائزہ لینے والا ایجنٹ شامل کریں۔

AI کا استعمال کرنے والی ٹیموں کو انسانی اور AI جائزہ لینے والوں دونوں کے لیے PR جائزہ کے مستقل نمونوں کی ضرورت ہوتی ہے۔ مستقل مزاجی کے لیے واحد سب سے مفید نمونہ تمام PRs کا جائزہ لینے کے لیے ایک مختصر، واضح چیک لسٹ ہے۔ اس کے بغیر، جائزے ساپیکش بن جاتے ہیں۔ یہ یقینی بناتا ہے کہ ہر کوئی ہر بار ایک ہی صفحے پر ہے۔

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

خاص طور پر فیکٹریوں کے لیے، چیک لسٹ لگانے کے لیے سب سے صاف جگہ دوسرے ایجنٹ کے اندر ہے۔ استعمال کریں /agents سلیش کمانڈ لکھیں اور pr-reviewer ہم ایجنٹوں کو اسی طرح استعمال کرتے ہیں جس طرح ہم نے سیکشن 6 میں 7 بنائے ہیں۔

Create a project-level subagent named pr-reviewer.

Its job: review a pull request against this project's review
checklist and report findings grouped by severity. It does
not edit files or merge PRs.

Inputs:
- a PR or a diff to review
- CLAUDE.md and any project-level rules

Outputs, grouped by severity:
- critical (must fix before merge)
- important (should fix before merge)
- minor (nice to have)

Always check for:
- Scope: one clear purpose, no unrelated refactoring,
  no unrelated files.
- Tests: unit tests cover the core behaviour, failure
  cases tested, existing tests still pass.
- Security and tenant safety: auth checks, tenant isolation
  preserved, no secrets in logs or error responses.
- Architecture: business logic out of UI and API route
  handlers, existing patterns from CLAUDE.md respected,
  no unjustified new dependencies.
- Documentation: README or feature docs updated for
  user-facing changes, technical debt acknowledged in
  the PR description.

Tool access: Read, Grep, Glob, Bash (for git commands only).
Recommended model: sonnet (this needs careful reasoning).
Recommended color: orange.

Behaviour rules:
- Never edit files.
- Never merge or close PRs.
- Cite file paths and line numbers for every finding.
- Mark opinion-based findings clearly so reviewers can
  ignore them safely.

جب کلاڈ ایک فائل بناتا ہے، اس کا جائزہ لیتا ہے، اور اس کا ارتکاب کرتا ہے، تو اس پروجیکٹ میں اب ایک مستقل جائزہ لینے والا ہوتا ہے جسے انسان اور AI اسی طرح کال کرتے ہیں۔ @pr-reviewer review this PR. آپ اسے اپنی CI پائپ لائن سے بھی جوڑ سکتے ہیں تاکہ جائزہ لینے والوں کے دیکھنے سے پہلے تمام ڈویلپر اپنے PR فیڈ بیک پر کارروائی کر سکیں۔ جائزہ لینے والوں پر بوجھ کم کرتا ہے۔

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

کلاؤڈ جائزہ لینے والے ایک خصوصیت ہیں، ساتھی نہیں۔

AI CI پائپ لائنوں کے اندر کام کرنا شروع کر رہا ہے، بشمول PR ریویو بوٹس، سیکورٹی سکینر، ریلیز نوٹ جنریٹرز، اور ایشو سورٹرز۔ واقعی مفید ہے۔ لیکن زبان اہم ہے۔

اگر آپ کہتے ہیں کہ "کلاڈ نے اس PR کو منظور کیا” تو آپ نے پہلے ہی ایک چھوٹی سی غلطی کی ہے۔ کلاؤڈ پر مبنی AI آپ کا ساتھی نہیں ہے۔ ڈویلپر نہیں۔ ہم آپ کے فیصلوں کے ذمہ دار نہیں ہیں۔ درست جملہ یہ ہے کہ "Claude نے پروجیکٹ کی جائزہ چیک لسٹ کے خلاف جائزہ ورک فلو کو چلایا اور نتائج کی اطلاع دی اور یہ طے کیا کہ PRs کو ضم کرنا انسانوں کے لیے محفوظ ہے۔” ذمہ داری انسانوں پر عائد ہوتی ہے۔

اس مشق کی ایک عملی وجہ ہے۔ کلاؤڈ جائزہ لینے والے ان چیزوں میں ماہر ہوتے ہیں جنہیں تلاش کرنے کے لیے انہیں بتایا جاتا ہے: گمشدہ ٹیسٹ، مماثل نام، ڈپلیکیٹ مددگار، اور بہت کچھ۔ وہ ایسی چیزیں یاد کرتے ہیں جو چیک لسٹ سے دور ہیں۔ اگر چیک لسٹ خاص طور پر جائزہ لینے والے کو انوائس ڈاؤن لوڈ اینڈ پوائنٹ پر کرایہ داروں کی تنہائی کو چیک کرنے کی ہدایت نہیں کرتی ہے، تو AI جائزہ لینے والا اب بھی ایک ایسے بگ کی اجازت دے سکتا ہے جو کمپنی A کے صارفین کو کمپنی B سے انوائسز ڈاؤن لوڈ کرنے کی اجازت دیتا ہے۔ یہی وجہ ہے کہ پروجیکٹ کے لیے مخصوص جائزہ چیک لسٹ ایک عام AI جائزہ لینے والے سے کہیں زیادہ قیمتی ہے۔

جہاں انسان جیتتے ہیں۔

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

وہ فیصلہ اب بھی انسانی چیز ہے۔ بہترین AI سے چلنے والی ٹیمیں وہ نہیں ہیں جو انسانوں کو ختم کر دیں۔ یہ وہی ہیں جو انسانوں کو وہاں ڈالتے ہیں جہاں ان کا فیصلہ سب سے زیادہ ہوتا ہے۔

9. پہلی کلاڈ پر مبنی سافٹ ویئر فیکٹری بنانا

نظریہ ختم ہو گیا ہے۔ یہاں آپ کے پروجیکٹ میں فیکٹری لگانے کے لیے ایک چیک لسٹ ہے: ہر قدم ایک ایسے حصے کی طرف اشارہ کرتا ہے جو اس کی وجہ بتاتا ہے۔

#	قدم	کہاں
1	آفیشل دستاویزات سے کلاڈ کوڈ انسٹال کریں۔	https://code.claude.com/docs/en/desktop
2	فولڈر کا ڈھانچہ بنائیں (.claude/agents، .claude/skills/feature-factory، .claude/skills/build-with-tests، .claude/hooks، CLAUDE.md)	سیکشن 5
3	لکھنا CLAUDE.md (100-300 لائنیں، منصوبے کے حقائق اور قواعد)	سیکشن 5
4	اس کے ساتھ 7 ذیلی ایجنٹ بنائیں: /agents	سیکشن 6
5	نسل feature-factory آرکیسٹریٹر کی مہارتیں۔	سیکشن 7
6	نسل build-with-tests فنکشن	سیکشن 5
7	پری کمٹ ہک شامل کریں اور اسے قابل عمل بنائیں۔	سیکشن 5
8	نسل pr-reviewer نائب	سیکشن 8
9	سلسلہ پر ایک حقیقی فنکشن کو انجام دیں۔	نیچے

کل وقت: پہلے ورژن کے لیے 2-3 گھنٹے۔

پہلا اصل فنکشن چلاتے وقت

چھوٹی چیز کا انتخاب کریں۔ مینجمنٹ ٹول، چھوٹے UI ٹائلز کے ساتھ ایک نیا API اینڈ پوائنٹ۔ بند کوڈ کھولیں:

/feature-factory

I want to .

سلسلہ چلتا ہے۔ براہ کرم کہانی کو منظور کریں۔ خاکہ کو منظور کریں۔ تصدیق کنندہ کی رپورٹ پڑھیں۔ PR کھولیں۔

پہلی بار کامل نہیں ہوگا۔ آگے بڑھتے وقت نوٹ کرنے کی چیزیں:

• کیا محققین کی پیداوار بہت کم ہے؟ اپنی وضاحت کو مضبوط کریں۔

• کیا کہانی لکھنے والے نے ایک ایج کیس یاد کیا؟ وضاحت میں قواعد شامل کریں۔

• کیا قیاس سے کوئی خطرہ چھوٹ گیا؟ قواعد شامل کریں۔ CLAUDE.md.

• کیا بیک اینڈ بلڈر نے فرنٹ اینڈ فائلوں کو چھو لیا؟ اپنے دائرہ کار کے قوانین کو سخت کریں۔

• فرنٹ اینڈ بلڈرز نے اختتامی نقطہ ایجاد کیا؟ اپنے API کے استعمال کے قوانین کو سخت کریں۔

• کیا تصدیق کنندہ سے کوئی ایسی چیز چھوٹ گئی جسے بعد میں انسانوں نے دریافت کیا؟ اصول میں تصدیق شامل کریں۔

• کیا ہک کو پہلے کچھ پکڑنا چاہئے تھا؟ اس میں شامل کریں۔

تین یا چار افعال انجام دینے کے بعد، پودا خود کو ایڈجسٹ کرتا ہے۔ آپ نگرانی میں کم وقت گزاریں گے اور یہ فیصلہ کرنے میں زیادہ وقت گزاریں گے کہ آگے کیا بنانا ہے۔

حصہ 3: نتیجہ

10. میں نے کیا احاطہ نہیں کیا (اور آگے کیا کروں گا)

AI کی مدد سے ترقی ایک بہت بڑے علاقے پر محیط ہے، اس لیے ایک مضمون میں ہر چیز کا احاطہ کرنا ناممکن ہے۔ مندرجہ ذیل موضوعات ہیں جنہیں میں نے جان بوجھ کر چھوڑ دیا ہے۔ یہ وہی ہے جو ہم آگے دیکھیں گے۔

سیشنوں میں مرکزی میموری کا انتظام

جب آپ متوازی طور پر متعدد سیشن چلانا شروع کرتے ہیں (ایک فی فنکشن، ایک فی برانچ، ایک فی ٹیم ممبر)، AI تمام سیشنز میں میموری کو شیئر کرنا چاہتا ہے۔ کلاڈ کی پروجیکٹ لیول میموری، MCP پر مبنی مشترکہ علمی ذخیرہ، اور ٹیم کے وسیع ویکٹر ریپوزٹری اس کے لیے مثالی ہیں۔ یہ ایک تیزی سے بدلتا ہوا علاقہ ہے اور جو کچھ توجہ مرکوز پڑھنے کے قابل ہے۔

متوازی طور پر ایجنٹوں کو چلائیں۔

کلاڈ کوڈ کے ذیلی ایجنٹ ایک ہی سیشن میں متوازی طور پر چل سکتے ہیں۔ آپ ایسے ٹولز بھی استعمال کر سکتے ہیں جو ٹاسک ٹری میں ایک سے زیادہ سیشن انجام دینے کے لیے کلاڈ کوڈ کو لپیٹتے ہیں (نمبالیسٹ ایک مثال ہے)۔ ایک بار جب پلانٹ مستحکم ہو جاتا ہے، متوازی پروسیسنگ نمایاں طور پر رفتار کو بہتر بناتی ہے۔ انضمام کے تنازعات اور CI اخراجات سے بچو۔

کلاؤڈ بیسڈ بغیر پائلٹ ایجنٹ

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

آپ کے کاروبار کے لیے کسٹم MCP سرور

ماڈل سیاق و سباق پروٹوکول (MCP) آپ کو اندرونی سسٹمز جیسے بلنگ ڈیٹا، کسٹمر سپورٹ ٹکٹس، اور ڈیزائن سسٹمز کو بطور ٹولز کلاڈ کے سامنے لانے کی اجازت دیتا ہے۔ ایک اچھی طرح سے بنایا ہوا MCP سرور کلاڈ کو کوڈنگ اسسٹنٹ سے کسی جونیئر ٹیم ممبر کے قریب سے تبدیل کرتا ہے جو آپ کے کاروبار کو جانتا ہے۔ ایک بار جب بنیادی پلانٹ اپنی جگہ پر آجائے، تو اسے قریب سے دیکھنے کے قابل ہے۔

پیمانے پر لاگت کی اصلاح

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

پروڈکٹ، ڈیزائن اور سپورٹ میں پھیلائیں۔

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

اگر آپ مزید جاننا چاہتے ہیں تو، آفیشل کلاڈ کوڈ دستاویزات سب ایجنٹس، ہنر، ہکس، اور MCP کے لیے سب سے تازہ ترین ذریعہ ہے۔ اینتھروپک ایک مفت سبجینٹ تعارفی کورس بھی شائع کرتا ہے جو اس مضمون کے ساتھ اچھا ہے۔

11. خیالات کو بند کرنا

یہ مضمون ایک خیال کے ساتھ شروع ہوا: انتشار کے کاموں کے بجائے ساختی کاموں کو خودکار بنانے کے لیے AI کا استعمال۔ درمیان میں 11 حصے وہی ہیں جیسے وہ اصل میں نظر آتے ہیں۔

لہذا خودکار کرنے سے پہلے اپنے سسٹم کی وضاحت کریں۔ قواعد لکھیں۔ CLAUDE.md. ایسی مہارتیں بنائیں جو آپ کی ٹیم بار بار لوٹتی ہے۔ ایسے ایجنٹ بنائیں جو گہرے کام انجام دیں۔ آرکیسٹریٹر کو جوڑیں۔ ایک گیٹ شامل کریں۔ اور انسانوں کو شامل رکھیں جہاں یہ فیصلہ ہے، نہ کہ جہاں ٹائپنگ اہم ہے۔

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

کام کرنے کا نیا طریقہ

سیکشن 8 نے یہ خیال متعارف کرایا کہ ایک انجینئر پورے عمودی ٹکڑے کو بھیج سکتا ہے۔ ایک لمحے کے لیے اپنے کی بورڈ سے دور رہیں اور غور کریں کہ اس کا مطلب صرف ایک ڈویلپر کے لیے نہیں، بلکہ آپ کی ٹیم کے لیے ہے۔

سافٹ ویئر ہمیشہ ہینڈ آف کے ذریعے منتقل ہوتا رہا ہے۔ پروڈکٹ کا مالک کہانی لکھتا ہے، سینئر ڈویلپر اس کا تصریحات میں ترجمہ کرتا ہے، بیک اینڈ انجینئر API بناتا ہے، فرنٹ اینڈ انجینئر UI بناتا ہے، اور ادائیگیوں کا ماہر انضمام کو سنبھالتا ہے۔ جب تک کوئی فیچر ریلیز ہوتا ہے، 4-5 لوگ اسے چھو چکے ہوتے ہیں اور ہر ایک پچھلے فیچر کے مکمل ہونے کا انتظار کر رہا ہوتا ہے۔ ہر ہینڈ آف ایک وقت تھا جب کام ساکت بیٹھا تھا۔

شکل 7: پچھلی شکل۔ تمام تیر ہینڈ آف ہیں۔ ہر ہینڈ آف ایک انتظار ہے۔

فیکٹریاں ان میں سے بہت سے ہینڈ آف کو ختم کرتی ہیں کیونکہ مہارت اب لوگوں کے اندر محدود نہیں ہے۔ یہ ایجنٹ کی شکل میں شیئر کیا جاتا ہے۔

یہاں تک کہ فرنٹ اینڈ انجینئرز جنہوں نے کبھی اسٹرائپ ویب ہک نہیں لکھا ہے وہ آپ کو مطلوبہ فعالیت فراہم کر سکتے ہیں۔ اس کی وجہ یہ ہے کہ ٹیم کے ادائیگیوں کے ماہرین نے پہلے ہی اسٹرائپ ویب ہکس کو بنایا اور ٹیون کر لیا ہے۔ payments-integration نائب یہاں تک کہ بیک اینڈ انجینئرز جنہوں نے کبھی ریچارٹس ڈیش بورڈ نہیں بنایا ہے وہ اب بھی اپنی ضرورت کی فعالیت فراہم کر سکتے ہیں۔ dashboard-component-builder نائب QA انجینئرز regression-suite-writer کوئی بھی ایجنٹ کو استعمال کر سکتا ہے۔ ڈی او اوپس انجینئرز ci-pipeline-updater کوئی بھی ایجنٹ کو استعمال کر سکتا ہے۔ سیکورٹی انجینئر auth-checker ایجنٹ ہر زنجیر کے حصے کے طور پر چلتے ہیں۔

نتیجے کے طور پر، ایک انجینئر اپنے طور پر ایک مکمل عمودی ٹکڑا مکمل کر سکتا ہے۔

شکل 8: نئی شکل۔ تمام انجینئرز ایک ہی ایجنٹ لائبریری سے کھینچتے ہیں۔ ماہرین اب بھی موجود ہیں، لیکن ان کی مہارت ان ایجنٹوں میں ہے جو وہ برقرار رکھتے ہیں، اس میں نہیں کہ وہ اسے فراہم کر سکتے ہیں۔

دیکھو کیا بدل گیا ہے۔ ماہرین اب بھی موجود ہیں۔ فرنٹ اینڈ لیڈرز اب بھی ڈیزائن سسٹم کے مالک ہیں۔ ادائیگیوں کا ماہر اب بھی اسٹرائپ انضمام کا مالک ہے۔ DevOps انجینئرز اب بھی CI پائپ لائن کے مالک ہیں۔ ان کے پاس اب بھی ذائقہ اور فیصلہ ہے جو ٹیم میں کسی اور کے پاس نہیں ہے۔ کیا تبدیلی آئی ہے کہ ان کی مہارت اب پورٹیبل ہے۔ یہ ایجنٹ کے اندر ہے جسے ٹیم کا کوئی بھی رکن کال کر سکتا ہے۔

یہ تبدیلیاں تین طریقوں سے مرکب ہیں۔

سائیکل کے اوقات کم ہوتے ہیں۔ ایک خصوصیت جو تین انجینئروں کا انتظار کرتی تھی اب کسی کا انتظار نہیں کرتی۔ سلسلہ ایک انجینئر کے لیے سرے سے آخر تک جڑا ہوا ہے۔ PRs ایک ہی دن ہوتے ہیں، ایک ہی ہفتے میں نہیں۔

ہمارے ماہرین اپنا بہترین کام کرتے ہیں۔ اس سے پہلے، ہمارے سینئر پیمنٹ انجینئر اپنے ہفتے کا نصف دوسرے انجینئرز کے اسٹرائپ انضمام کو غیر مسدود کرنے میں صرف کرتے تھے۔ اب وہ اس ہفتے کو بہتر بنانے میں گزارتے ہیں۔ payments-integration ایجنٹ خود۔ لیوریج بہت زیادہ ہے۔ ایجنٹ میں ایک بہتری اس وقت سے ٹیم کی پیش کردہ ہر چیز کو فائدہ دے گی۔

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

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

جو ٹیمیں سب سے پہلے اس کا پتہ لگاتی ہیں وہ سب سے بڑی تعداد یا AI بجٹ والی ٹیمیں نہیں ہوں گی۔ وہ اس بات کو یقینی بنانے والے ہوں گے کہ ایجنٹ لائبریری ٹیم کے اجتماعی ذوق کی عکاسی کرتی ہے، اسے تازہ ترین، چھوٹا اور مضبوط بنایا گیا ہے۔ ایجنٹ اثاثہ ہیں۔ ایک فیکٹری چیزوں کو انجام دینے کا ایک طریقہ ہے۔

مختصر نوٹ

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

اگر آپ کی ٹیم یہ ورژن بناتی ہے، تو میں یہ سننا پسند کروں گا کہ کیا کام ہوا اور کیا نہیں۔ اپنے ورک فلو کو بہتر بنانے کا تیز ترین طریقہ یہ ہے کہ دوسرے لوگوں کی ناکامی کے طریقوں کے بارے میں پڑھیں۔ آپ کی فیکٹری کی تعمیر کے ساتھ اچھی قسمت.

وسائل

کلاڈ کوڈ

دیگر AI IDEs (ایک ہی پیٹرن لاگو کیا گیا)

آرٹیکل میں ذکر کردہ ٹولز