Tutorial 4 Prompting and Reviewing ur

ٹیوٹوریل ۴ · پرامپٹنگ اور جائزہ

🌎 زبان: اردو — تمام ۳۳ زبانیں دیکھیں

مقصد: میٹا-مہارت۔ اب آپ کسی ایجنٹ کے ساتھ ایک فیچر بنا سکتے ہیں — یہ باب اسے سلاست اور بار بار کرنے کے بارے میں ہے: ایسے پرامپٹ لکھنا جو پہلی بار ہی کام کریں، diffs کا مؤثر جائزہ لینا، جب چیزیں بگڑ جائیں تو دہرانا، اور سیشنز کے دوران رفتار برقرار رکھنا۔

← پچھلا: ٹیوٹوریل ۳ آپ کا پہلا ایجنٹ ٹاسک · اگلا: ٹیوٹوریل ۵ لوکلائزیشن

---

ایک لیڈ کی طرح پرامپٹ کریں، سرچ باکس کی طرح نہیں

ایجنٹ ایک تیز، لفظی، پُرجوش جونیئر انجینئر ہے۔ اس کی رہنمائی ویسے کریں جیسے آپ کسی اچھے جونیئر کی کرتے:

• مقصد اور پابندیاں بتائیں۔ "endorse شامل کرو" کمزور ہے۔ "connect نمونے کی پیروی کرتے ہوئے endorse شامل کرو، صرف سیڈ شدہ RNG، ٹیسٹ کے ساتھ، گیٹ سبز رہے" مضبوط ہے۔ پابندیاں وہ طریقہ ہیں جس سے آپ ایسا کوڈ حاصل کرتے ہیں جو فٹ ہو۔
• مثالوں کی طرف اشارہ کریں۔ "renderConnect کے استعمال کردہ نمونے کی پیروی کرو" ایک پیراگراف کی تفصیل سے بہتر ہے۔ موجودہ کوڈ بہترین اسپیک ہے۔
• کسی بھی غیر معمولی چیز پر ایڈٹ سے پہلے منصوبہ مانگیں۔ منصوبے کو موڑنا سستا ہے؛ دس ایڈٹ شدہ فائلوں کو کھولنا مہنگا ہے۔
• فی پرامپٹ ایک کام۔ "endorse شامل کرو، ساتھ RNG کو ری فیکٹر کرو، ساتھ README اپ ڈیٹ کرو" کو جمع کرنا ایک الجھا ہوا diff پیدا کرتا ہے جس کا جائزہ لینا مشکل ہے۔
• اسے ٹیسٹ گیٹ دیں۔ "npm test چلاؤ اور اسے مکمل مت سمجھو جب تک یہ سبز نہ ہو" ایجنٹ کو ایسی چیز میں بدل دیتا ہے جو اپنے کام کو خود چیک کرتی ہے۔

ہر بار diff کا جائزہ لیں

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

1. دائرہ کار: کیا اس نے صرف وہی بدلا جو اسے بدلنا چاہیے تھا؟ غیر متعلقہ ہلی ہوئی لائنیں ایک بو ہیں۔
2. نمونے: کیا یہ ارد گرد کے کوڈ سے میل کھاتا ہے، بغیر کسی نئے انحصار کے اور src/ کے اندر کوئی I/O نہیں؟
3. پروجیکٹ کے اصول: اس ریپو کے لیے، یہ ہیں صرف سیڈ شدہ RNG (diff میں Math.random تلاش کریں)، صارف کو نظر آنے والا متن زبان بنڈلز میں (ہارڈ کوڈڈ نہیں)، اور کارڈ لائنیں کبھی اس چوڑائی سے تجاوز نہ کریں جس تک لے آؤٹ پیڈ کرتا ہے۔
4. رسائی: کیا نیا آؤٹ پٹ --accessible میں بچ جاتا ہے؟ lockedin --accessible <your command> چلائیں اور چیک کریں کہ یہ صاف ستھرے سادہ متن کے طور پر پڑھا جاتا ہے — کوئی نئی آرائشی گلائف a11yFilter سے چھپ کر نہ گزر رہی ہو۔
5. ٹیسٹ: کیا کوئی نیا ٹیسٹ ہے، اور اگر فیچر ٹوٹ جائے تو کیا وہ واقعی ناکام ہو گا؟ پوچھیں: "اس نئے ٹیسٹ کو ناکام بنانے کے لیے میں کون سی لائن بدلوں گا؟"
6. اسے چلائیں: npm test، پھر کمانڈ چلائیں اور آؤٹ پٹ کو دیکھیں۔

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

جب یہ سبز نہ ہو تو دہرائیں

سرخ گیٹ ایک معمول کا قدم ہے، ناکامی نہیں۔ حل درست رائے ہے:

"npm test اس کے ساتھ ناکام ہوتا ہے: [paste the exact error]۔ renderEndorse چوڑائی ٹیسٹ ہر کارڈ لائن ≤ ۶۰ دکھائی دینے والے کالم کی توقع کرتا ہے۔ ٹیسٹ کو کمزور کیے بغیر اسے ٹھیک کرو۔"

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

سیشنز کے دوران رفتار برقرار رکھیں

اصل کام ایک نشست سے زیادہ پھیلتا ہے۔ دو عادتیں ایجنٹ کو وقت کے ساتھ مؤثر رکھتی ہیں:

• میموری / اصول (کنونشنز)۔ اگر آپ کا ایجنٹ پائیدار میموری یا کسی پروجیکٹ ہدایت فائل کو سپورٹ کرتا ہے، تو یہاں وہ اصول درج کریں جن کی اسے ہمیشہ پیروی کرنی چاہیے (مثلاً "تمام بے ترتیبی کو pick/shuffle استعمال کرنا چاہیے"، "مکمل قرار دینے سے پہلے npm test چلاؤ")۔ آپ ایک اصول ایک بار بیان کرتے ہیں، ہر پرامپٹ میں نہیں۔
• ایک ہینڈ آف نوٹ۔ یہ ریپو ایک مختصر، صاف کردہ اسٹیٹس دستاویز docs/HANDOFF.md پر رکھتا ہے: پروجیکٹ کیا ہے، یہ کیسے بنا ہے، اسے کیسے آزمایا جاتا ہے، اور آگے کیا ہے۔ جب آپ واپس آتے ہیں (یا کسی ساتھی کو — یا کسی اور ایجنٹ کو — سونپتے ہیں)، وہ نوٹ سیکنڈوں میں سیاق دوبارہ بنا دیتا ہے۔ اپنے ایجنٹ سے کہیں کہ وہ کسی تبدیلی کے حصے کے طور پر اسے تازہ رکھے۔

قابلِ حفاظت حفاظتی حدود

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

---

✅ اپنے ایجنٹ کے ساتھ آزمائیں

1. ایک mentor کمانڈ ("غیر طلب شدہ مشورہ دیتی ہے") کے لیے ایک-پیراگراف اسپیک لکھیں، پابندیوں سمیت، اور ایجنٹ سے کہیں کہ اسے ٹیسٹ-پہلے بنائے — منصوبہ، ٹیسٹ، کوڈ، گیٹ — ہر قدم پر جائزہ لیتے ہوئے۔
2. ایجنٹ سے کہیں کہ وہ نئی کمانڈ کا ذکر کرنے کے لیے docs/HANDOFF.md اپ ڈیٹ کرے۔
3. جان بوجھ کر کچھ توڑیں (مثلاً کوئی پول اندراج حذف کریں)، npm test چلائیں، اور ایجنٹ کو ٹھیک کرنے کے لیے بالکل درست ناکامی فراہم کرنے کی مشق کریں۔

---

آگے کہاں جائیں

• src/lockedin.js میں اصل کوڈ پر سرسری نظر ڈالیں — اب آپ اس کی شکل جانتے ہیں۔
• پروجیکٹ کی اپنی اسٹیٹس اور آرکیٹیکچر نوٹس کے لیے docs/HANDOFF.md پڑھیں۔
• کمانڈ ریفرنس میں مذاق کا لطف اٹھائیں۔

یہ رہا ٹیوٹوریل۔ اب آپ ایک AI ایجنٹ کو ہدایت دے سکتے ہیں کہ وہ ایک ٹیسٹ گیٹ کے پیچھے حقیقی سافٹ ویئر بنائے اور بدلے — قابلِ تصور سب سے زیادہ حد سے زیادہ پُراعتماد مثال کے ساتھ۔ متفق؟ 👇