AI سے چلنے والا ریویو استعمال کریں

یہ گائیڈ دکھاتی ہے کہ ریویوور ایجنٹس سے کوئی pull request کیسے ریویو کرایا جائے اور نتیجہ GitHub پر کیسے شائع کیا جائے۔

AI ریویو شروع کریں

PR کھولیں اور اس کا جائزہ ٹیب کھولیں
ایکشن قطار میں ⋯ اوور فلو مینو کھولیں اور AI سے پوچھیں چنیں

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

Control Center پہلے سے فراہم کردہ pr_review پائپ لائن شروع کرتا ہے اور PR کا ریویو ٹیب کھول دیتا ہے تاکہ آپ اسے دیکھ سکیں۔ پائپ لائن:

PR کا اپنا ریویو اسپیس کھولتی ہے، جس کے الگ تھلگ ورک ٹری میں PR اس کے head پر چیک آؤٹ ہوتا ہے
ورک اسپیس کی ریویو سطح کے مطابق ریویوورز پھیلا دیتی ہے — بطور ڈیفالٹ تین (پہلے سے فراہم کردہ qa، architect اور engineer ایجنٹس، متوازی طور پر)۔ کوئی زبان یا ڈومین کی شناخت نہیں ہوتی
لیڈ (CEO) ایجنٹ سے ان کے نتائج کو ایک واک تھرو میں یکجا کراتی ہے
فائنلائز کرتی ہے: نتائج کو اتفاقِ رائے کی بالٹیوں میں ترتیب دیتی ہے اور فیصلہ شمار کرتی ہے۔ جب ایسوسی ایشن awaiting approval تک پہنچ جاتی ہے تو ریویو ٹیب پر GitHub پر شائع کریں ظاہر ہوتا ہے

ریویو کتنا گہرا جائے، یہ ورک اسپیس کی ریویو سطح ہے — light (ایک ریویوور)، balanced (تین، ڈیفالٹ) یا thorough (پانچوں، بشمول سیکیورٹی اور پرفارمنس اسپیشلسٹ) — جو ترتیبات → ورک اسپیس → عام پر، ورک اسپیس پالیسی کارڈ میں سیٹ ہوتی ہے۔ ہلکی سطح بھی اتنے ہی نتائج درج کرتی ہے؛ وہ ان میں سے کم نتائج سامنے نمایاں کرتی ہے۔

تمام ریویوورز PR کے ایک ہی ریویو اسپیس میں پوسٹ کرتے ہیں، اور یہی چیز ان کے نتائج کو موازنہ کے قابل بناتی ہے۔ یہ اجزاء کیسے ایک ساتھ فٹ ہوتے ہیں، AI ریویو میں دیکھیں۔

pr_review صرف دستی ٹریگر کے ساتھ آتی ہے۔ ہر شائع شدہ PR پر اس کے خودکار چلنے کے لیے، خود ایک ٹریگر شامل کریں — ریویوور ایجنٹس بھیجیں دیکھیں۔ آپ اسے خود GitHub سے بھی شروع کر سکتے ہیں، کسی پائپ لائن ٹریگر کی ضرورت نہیں: PR پر سرور کے بوٹ کا ذکر کریں یا ai-review لیبل لگائیں — GitHub PR سے Control Center سے بات کریں دیکھیں۔

اگر کوئی ٹوسٹ بتائے کہ اس pull request کے لیے پہلے ہی ایک ریویو چل رہا ہے، تو ایک پہلے ہی جاری ہے؛ ریویو ٹیب پر رہیں یا اسے ڈھونڈنے کے لیے پائپ لائنز کھولیں۔

نتائج پڑھیں

ریویوورز ریویو اسپیس میں نتائج کو ریویو نوڈز کے طور پر درج کرتے ہیں۔ ہر نوڈ یہ رکھتا ہے:

فیلڈ	تفصیل
قسم	`bug`, `suggestion`, `recommendation`, `question` یا `ticket`
ترجیح	P0 (سنگین) → P3 (معمولی)
زمرہ	`security`, `stability`, `data_integrity`, `correctness`, `performance` یا `maintainability`
فائل اور لائن	نتیجہ جہاں اینکر ہے
اصل کوڈ	وہ کوڈ جس کے بارے میں نتیجہ ہے
تجویز کردہ کوڈ	تجویز کردہ فکس
اعتماد	ریویوور کو کتنا اعتماد ہے
اسٹیٹس	`open` → `consensus-ready` → `resolved` یا `dismissed`

کوئی نتیجہ consensus-ready تک صرف اسی وقت پہنچتا ہے جب کوئی ساتھی ریویوور اس کی تصدیق کرے۔ کوئی ایجنٹ اپنے ہی نتیجے کی تصدیق نہیں کر سکتا، چنانچہ ایک ہی ریویوور کی رائے کبھی اپنے طور پر ترقی نہیں پاتی۔

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

اختلافات کا پینل دیکھیں

جب دو ریویوورز نتائج کو ایک ہی فائل اور لائن پر اینکر کریں مگر انہیں بہت مختلف انداز میں پرکھیں — ترجیحات دو یا زیادہ درجوں کے فاصلے پر ہوں، یا ایک اسے bug کہے جبکہ دوسرا اسے suggestion کہے — تو نتائج کی فہرست کے اوپر ایک اختلاف پینل ظاہر ہوتا ہے۔ پہلے وہی پڑھیں: یہی وہ جگہ ہے جہاں ریویوورز کی رائے الگ ہوتی ہے اور آپ کا فیصلہ سب سے زیادہ قیمتی ہوتا ہے۔

فیصلہ پڑھیں

جب لیڈ ایجنٹ فائنلائز کرتا ہے، تو وہ ایک فیصلہ شمار کرتا ہے:

فیصلہ	مطلب
Ship	کوئی رکاوٹ نہیں ملی
Hold	ایسے مسائل جنہیں مرج سے پہلے حل کرنا چاہیے
Block	سنگین مسائل جنہیں لازماً ٹھیک کرنا ہے

فیصلے میں ایک مجموعی اعتماد کا اسکور اور فی ترجیح نتائج کی گنتی شامل ہوتی ہے۔

پھر ریویو محور اس میں شامل ہو جاتے ہیں، اور وہ اسے صرف زیادہ سخت ہی بنا سکتے ہیں۔ ناکام ہونے والا گیٹڈ محور Block نافذ کرتا ہے؛ جو گیٹڈ محور مکمل نہ ہو سکا (partial) یا بالکل چل ہی نہ سکا (unavailable)، وہ کم از کم Hold نافذ کرتا ہے۔ ثبوت کی عدم موجودگی کبھی کوئی گیٹ پاس نہیں کراتی۔

ریویو GitHub پر شائع کریں

اشاعت ایک الگ، جان بوجھ کر صارف کے گیٹ پر رکھا گیا قدم ہے۔ pr_review پائپ لائن ریویو کو Control Center میں رکھتی ہے؛ وہ GitHub پر پوسٹ نہیں کرتی۔

ریویو ٹیب پر اس وقت تک انتظار کریں جب تک GitHub پر شائع کریں ظاہر نہ ہو
GitHub پر شائع کریں دبائیں

Control Center ایک GitHub ریویو بھیجتا ہے۔ جو نتائج پہلے ہی حل یا برطرف ہو چکے ہوں، وہ چھوڑ دیے جاتے ہیں۔ بٹن ہر باقی ماندہ کھلے نتیجے کو شامل کرتا ہے اور، Ship کی صورت میں، APPROVE جمع کرتا ہے۔ (MCP ٹول publish_review_to_github اب بھی بطور ڈیفالٹ صرف ساتھی کی تصدیق شدہ نتائج لیتا ہے اور اس وقت تک منظوری نہیں دیتا جب تک آپ approve_on_ship نہ بھیجیں۔) جو نتائج فائل اور لائن اینکر رکھتے ہیں وہ اِن لائن تبصرے بن جاتے ہیں؛ باقی سب کچھ سمری باڈی میں شامل ہو جاتا ہے، اور ہر ایک “— Control Center AI review” فوٹر رکھتا ہے تاکہ ماخذ واضح رہے۔ Block فیصلہ REQUEST_CHANGES کے طور پر جمع ہوتا ہے؛ Hold بطور COMMENT؛ Ship اس بٹن سے بطور APPROVE۔ اس کے بعد ایک ٹوسٹ شائع شدہ پڑھا جاتا ہے۔ ریویو سرور کی ایپ شناخت کے تحت پوسٹ کیا جاتا ہے۔

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

دوسری بلٹ اِن پائپ لائنیں براہ راست GitHub پر پوسٹ کرتی ہیں: cross_review، pr_triage، ticket_to_pr اور pre_merge_gate میں سے ہر ایک ایک تبصرہ قدم پر ختم ہوتی ہے۔ صرف pr_review ہی اپنا آؤٹ پٹ آپ کے لیے روکے رکھتی ہے۔

خود ریویوورز بھیجیں

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