Superpowers، اپنی ملکیت کے Git ریپوزٹری میں بڑی تبدیلی کے دوران Claude Code کے صارف کو رہنمائی دے سکتا ہے: ڈیزائن پر اتفاق، کاموں کے منصوبے کی منظوری، ٹیسٹ کے ساتھ نفاذ، ہر کام کا جائزہ اور مکمل برانچ کی جانچ۔ یہ رہنما 20 اکتوبر 2026 کو دیکھے گئے سرکاری Superpowers 7.0.0 دستی ناموں پر مبنی ہے۔ BIG CHANGE نے دستاویزات کا جائزہ لیا؛ ہم نے پلگ ان نصب نہیں کیا یا اس سے کوئی منصوبہ نہیں چلایا۔

بڑی تبدیلی

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

شروع کرنے سے پہلے

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

آپ کو Git، تصدیق شدہ Claude Code تنصیب، پلگ ان نصب کرنے اور branch یا worktree بنانے کی اجازت اور Claude Code و اس کے ذیلی ایجنٹوں کے لیے کافی پلان یا API گنجائش چاہیے۔ ماخذ کوڈ تک رسائی اور پلگ ان کے استعمال سے متعلق ادارے کے قواعد دیکھیں۔ فعال کرنے سے پہلے پلگ ان کی چیزیں، مؤثر اجازتیں، فراہم کنندہ کی ڈیٹا شرائط اور خرچ کے کنٹرول جانچیں۔ Anthropic خبردار کرتا ہے کہ پلگ ان hooks اور server processes آپ کے صارف اختیارات کے ساتھ tool-call sandbox سے باہر چل سکتے ہیں؛ عام tool permission prompts ایسے تمام کوڈ کو نہیں ڈھانپتے۔ راز، dependencies، بیرونی writes، pushes اور releases اپنے حقیقی اختیار تک محدود رکھیں۔ Claude Code کی پلگ ان سکیورٹی دستاویزات یہ حد سمجھاتی ہیں۔

ذیل کا راستہ کئی کاموں والی تبدیلی کے لیے Superpowers کی subagent-driven-development مہارت استعمال کرتا ہے۔ دستی نامے ایک inline executing-plans راستہ بھی بتاتے اور چھوٹے کام کے لیے آسان ڈیزائن اتفاق کی اجازت دیتے ہیں۔ ہر منصوبے میں پورا سلسلہ ضروری سمجھنے کے بجائے نفاذ سے پہلے مالک کے ساتھ راستہ چنیں۔

1. پلگ ان نصب کریں اور فعال ورژن جانچیں

تعاملی Claude Code سیشن میں سرکاری marketplace کمانڈ درج کریں:

Text
/plugin install superpowers@claude-plugins-official

تنصیب سے پہلے Claude Code پلگ ان کی تفصیلات کا پینل کھولتا ہے۔ مواد دیکھیں اور مجاز scope منتخب کریں۔ Local scope اسے اس ریپوزٹری میں آپ کے لیے فعال کرتا ہے؛ project scope ساتھیوں کی ریپوزٹری ترتیبات پر اثر ڈالتا ہے۔ تنصیب کا خلاصہ اور Errors ٹیب پڑھیں۔ سیشن کی فعالیت کی ہدایات مانیں یا دوبارہ شروع کریں، پھر Installed ٹیب دیکھیں اور shell میں claude plugin list چلائیں۔ دکھائے گئے Version، Scope اور Status نوٹ کریں اور تصدیق کریں کہ فعال سیشن میں Superpowers مہارتیں دستیاب ہیں۔ marketplace کمانڈ اس رہنما کی تحقیق میں استعمال شدہ commit کو مقرر نہیں کرتی۔ نصب شدہ ورژن یا مہارت کا متن 7.0.0 سے مختلف ہو تو آگے بڑھنے سے پہلے طریقۂ کار کو اس ورژن سے ملائیں۔ ناکام یا غیر فعال تنصیب پر رکیں؛ وہ کام کا بہاؤ لوڈ ہونے کا ثبوت نہیں ہے۔ Claude Code کا تنصیب رہنما ان جانچوں کو دستاویزی شکل دیتا ہے۔

2. پہلے ڈیزائن، پھر منصوبہ منظور کریں

Claude Code کو حقیقی تبدیلی، قبولیت کی شرائط، ابتدائی نتیجہ اور ممنوع ترامیم بتائیں۔ مقصد، ڈیزائن کے انتخاب اور حدود طے کرنے کے لیے Superpowers کا brainstorming عمل استعمال کریں۔ اس کئی مرحلوں والی تبدیلی میں لکھا ہوا ڈیزائن اور builder-check کے نتائج دیکھیں، مالک کے فیصلے والے سوال حل کریں اور مکمل تفصیل منظور کریں۔ منظوری بتائے کہ کون سا رویہ بنانا ہے؛ ایجنٹ کی بات جاری رہنے سے منظوری اخذ نہ کریں۔ ڈیزائن کا دستی نامہ چھوٹے کام میں ہلکے اتفاق یا واضح opt-out کی اجازت دیتا ہے، اس لیے یہاں بڑے کام کے لیے پورا راستہ جان بوجھ کر چنا گیا ہے۔

اس کے بعد writing-plans عمل سے اس ڈیزائن کو کاموں میں بدلنے کو کہیں۔ منصوبے کی فائل حدود، interfaces، مجموعی پابندیاں، ٹیسٹ کمانڈ اور Review Focus دیکھیں۔ ہر کام جانچنے کے قابل چھوٹا ہو اور اس کا ٹیسٹ متفقہ رویہ ناپے۔ کوڈ بدلنے سے پہلے منصوبہ اور ذیلی ایجنٹوں کا طریقۂ نفاذ منظور کریں۔ منصوبہ بندی کا دستی نامہ حوالگی طے کرتا ہے۔ معقول منصوبے کو dependencies بڑھانے یا غیر متعلقہ فائلیں بدلنے کی اجازت نہ سمجھیں۔

نفاذ کے وقت using-git-worktrees موزوں موجودہ workspace دیکھتا یا ضروری رضامندی سے الگ workspace تیار کرتا ہے۔ حقیقی branch، base commit اور صاف ابتدائی حالت نوٹ کریں۔ جہاں دستیاب ہو Claude Code کی اپنی worktree سہولت استعمال کریں۔ workspace میں غیر متعلقہ ترامیم ہوں تو آگے بڑھنے سے پہلے ان کی ملکیت طے کریں۔ worktree کا دستی نامہ جانچ اور تخلیق کا راستہ بتاتا ہے۔

3. ہر ٹیسٹ اور کام کا جائزہ دیکھیں

منظور شدہ منصوبے کے ساتھ subagent-driven-development الگ جائزہ لینے کے قابل کاموں کے لیے استعمال کریں۔ موجودہ دستی نامہ ایک کام کو نافذ کرنے والا دیتا ہے، پھر نفاذ اور اس کا diff ایک کام کے جائزہ کار کو دیتا ہے۔ وہ دو فیصلے دیتا ہے: کیا کام تقاضوں سے میل کھاتا ہے اور کیا نفاذ کا معیار قابل قبول ہے۔ یہ ایک جائزے کے دو فیصلے ہیں، یکے بعد دیگرے دو جائزہ کار ایجنٹ نہیں۔ ایک جیسی نوعیت کے چھوٹے کام دستی نامے کے قواعد کے مطابق گروہ میں کیے جا سکتے ہیں۔ کام کا بہاؤ اور جائزہ کار کی ہدایت یہ ترتیب طے کرتے ہیں۔

ہر ایسے رویے کے لیے جس میں پہلے ٹیسٹ لکھنا مناسب ہے، نظر آنے والا red-green چکر لازم کریں: رویے کا ٹیسٹ شامل کریں، چلائیں اور متوقع ناکامی دیکھیں؛ کم سے کم نفاذ کریں، دوبارہ چلا کر کامیابی دیکھیں؛ پھر جانچیں کامیاب رکھتے ہوئے refactor کریں۔ import error یا ٹوٹا test harness متوقع red نتیجہ نہیں ہے۔ ہر کام کی کمانڈ، output اور متعلقہ commit یا diff محفوظ رکھیں۔ test-driven-development کا دستی نامہ انسانی اتفاق مانگنے والے استثنا بیان کرتا ہے؛ یہ رہنما عام test-first راستے کے موزوں کام کو فرض کرتا ہے۔

جائزہ کار کے دونوں فیصلے اور اصل diff پڑھیں۔ کام قبول کرنے سے پہلے “diff سے تصدیق ممکن نہیں” کے ہر نکتے کو منصوبے اور ریپوزٹری سے حل کریں۔ مرمت اور اس کے محدود دوبارہ جائزے کو دیکھیں؛ کامیابی کا نیا دعویٰ تازہ ٹیسٹ کا نتیجہ نہیں ہے۔ 7.0.0 کا عمل مرمت کے چکر کو محدود کرتا اور تحریری فیصلوں کے ساتھ مسائل بعد کے لیے رکھ سکتا ہے۔ انہیں اگلے جائزے کے لیے محفوظ رکھیں۔ کام complete نشان زد ہو تو بھی اس کا جائزہ لازماً بے مسئلہ نہیں ہوتا۔

کام پورے ہوں تو پوری برانچ کا الگ جائزہ دیکھیں۔ یہ کاموں کے باہمی اثرات اور ان مؤخر مسائل کو دوبارہ دیکھ سکتا ہے جو ایک diff سے کام کا جائزہ کار حل نہ کر سکا۔ ہر کھلے مسئلے کا ثبوت اور فیصلہ طلب کریں۔ پلگ ان کے عارضی workspace کی صفائی سے پہلے ڈیزائن، منصوبہ، ٹیسٹ output، جائزہ رپورٹیں اور مکمل diff رکھیں۔ متوقع مہارت فعال نہ ہو تو فعال پلگ ان کا status، version اور دستاویزی تشخیصی راستہ دیکھیں؛ صرف تنصیب کی بنیاد پر یہ نہ سمجھیں کہ بہاؤ نافذ ہوا تھا۔

4. برانچ جانچیں اور اس کا اگلا قدم چنیں

حتمی کوڈ پر اصل قبولیت کمانڈ اور منصوبے کا پورا test suite دوبارہ چلائیں۔ تازہ output، مکمل branch کا diff اور تمام باقی مسائل دیکھیں۔ Superpowers کا تصدیقی دستی نامہ تکمیل کے دعوے سے پہلے موجودہ حالت کا ثبوت مانگتا ہے۔ suite ناکام ہو تو عین ناکامی پہچان کر درست کریں یا branch جائزے کے لیے چھوڑیں؛ ناکام suite پر دستاویزی branch-finish menu تک نہیں پہنچا جاتا۔

نام والی branch پر finishing-a-development-branch local merge، push کر کے pull request بنانا یا branch جوں کی توں رکھنا پیش کرتا ہے۔ detached HEAD میں pull-request اور keep اختیارات ہیں۔ Discard صرف مالک کی واضح درخواست اور ٹائپ شدہ تصدیق کے بعد ہوتا ہے؛ یہ عام چوتھا اختیار نہیں ہے۔ برانچ ختم کرنے کا دستی نامہ یہ اختیارات بیان کرتا ہے۔ فیصلے سے پہلے مالک کو جانچیں، diff اور باقی نتائج دکھائیں۔ merge، push، deletion یا release کو اس کارروائی کا مناسب اختیار چاہیے۔

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

ماخذ اور مزید مطالعہ

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