Claude Code اور OpenCode: 90 منٹ کا مختصر عملی کورس
15 تصورات، حقیقی استعمال کا 80 فیصد
تصور کریں کہ آپ اپنے کمپیوٹر سے کہہ سکیں: "میرے مضمون کا مسودہ دیکھو، گرامر کی غلطیاں درست کرو، پیراگراف اس طرح ترتیب دو کہ دلیل بہتر بہے، اور نیا نسخہ محفوظ کر دو۔" اور وہ واقعی یہ کر دکھائے۔ صرف یہ مشورہ نہ دے کہ آپ خود کیا تبدیلیاں کریں، بلکہ آپ کی فائلیں کھولے، تبدیلیاں کرے، اور نتیجہ آپ کے سامنے محفوظ کر دے۔
یہی کام Claude Code اور OpenCode کرتے ہیں۔ یہ اے آئی ٹولز ہیں جو سیدھے آپ کے کمپیوٹر پر کام کرتے ہیں۔ آپ بتاتے ہیں کہ آپ کیا چاہتے ہیں، وہ کام کرتے ہیں، اور آپ نتیجہ جانچتے ہیں۔
یہ مختصر عملی کورس آپ کو 15 تصورات سکھاتا ہے جو روزمرہ استعمال کا تقریباً 80 فیصد احاطہ کرتے ہیں۔ اختتام تک آپ کو معلوم ہوگا کہ ہر ٹول کیا کر سکتا ہے، کب کون سی خصوصیت استعمال کرنی ہے، اور عام غلطیوں سے کیسے بچنا ہے۔
ایک خیال جو ہر چیز کو سمجھنا آسان بنا دیتا ہے: ان ٹولز کی زیادہ تر "اعلیٰ" تکنیکیں ایک ہی بات پر آ کر رُک جاتی ہیں: اے آئی کو صحیح معلومات صحیح وقت پر دینا، اور غیر متعلق معلومات کو باہر رکھنا۔ اس کورس کا ہر حصہ اسی خیال سے جا کر جڑتا ہے۔
پیشگی شرط: AI Prompting in 2026۔ اس کورس نے آپ کو سکھایا کہ اے آئی سے بات کیسے کی جائے: سیاق دینا، صاف انداز میں پوچھنا، اے آئی کے کام کو جانچنا۔ یہ کورس سکھاتا ہے کہ کیا ہوتا ہے جب اے آئی واقعی آپ کی فائلوں کو چھو سکے اور آپ کے کمپیوٹر پر کمانڈز چلا سکے۔
دو ٹولز، ایک ہی مہارتوں کا مجموعہ
یہ کورس دو ٹولز کو ساتھ ساتھ بیان کرتا ہے: Claude Code (Anthropic کا بنایا ہوا) اور OpenCode (اوپن سورس، کسی بھی اے آئی ماڈل کے ساتھ کام کرتا ہے)۔ ہم دونوں اس عملی وجہ سے پڑھاتے ہیں: اگر کوئی تکنیک دونوں ٹولز میں کام کرتی ہے، تو وہ ایک حقیقی مہارت ہے، کسی ایک ٹول کا مخصوص حربہ نہیں۔ جو مہارتیں آپ سیکھتے ہیں وہ ان دونوں کے درمیان منتقل ہو جاتی ہیں۔
| Claude Code | OpenCode | |
|---|---|---|
| بنانے والا | Anthropic | اوپن سورس کمیونٹی |
| اے آئی ماڈلز | صرف Claude | Claude، GPT، Gemini، DeepSeek، مقامی ماڈلز |
| کس کے لیے بہترین | شروع سے ہی Claude کی بہترین کارکردگی | لچک، لاگت پر قابو، مفت ماڈلز |
| قیمت | سبسکرپشن یا API | مفت ماڈلز دستیاب، یا اپنی API کلید لائیں |
جو آپ کی صورتحال پر ٹھیک بیٹھے وہ چن لیں۔ اس کورس کی ہر چیز دونوں میں کام کرتی ہے۔
مئی 2026 تک تازہ۔ دونوں ٹولز اکثر اپ ڈیٹ ہوتے ہیں۔ کوئی بھی سیشن شروع کرنے سے پہلے
claude updateیاopencode upgradeچلائیں تاکہ آپ کے پاس تازہ ترین نسخہ موجود ہو۔ اگر آپ نے ابھی تک کوئی بھی ٹول انسٹال نہیں کیا، تو انسٹالیشن نیچے حصہ 1 میں بیان کی گئی ہے۔
اس پورے صفحے پر، جو حصے Claude Code اور OpenCode کے درمیان مختلف ہیں ان پر ایک سوئچر ہے۔ ایک چن لیں اور صفحے کے سارے سوئچرز آپ کے انتخاب کی پیروی کریں گے۔
یہ ایک مختصر عملی کورس ہے: ایک ہی نشست میں حقیقی استعمال کا 80 فیصد۔ نیچے دیے گئے ہر موضوع کے مکمل احاطے کے لیے، دیکھیں باب 14: عام اور کوڈنگ ایجنٹس کے ساتھ کام اور باب 17: ٹیموں، CI/CD، اور اعلیٰ ترتیب کے لیے Claude Code۔
یہ کورس کیا احاطہ کرتا ہے
| حصہ | موضوع | آپ کیا سیکھتے ہیں |
|---|---|---|
| 1 | بنیادیں | یہ ٹولز کیا ہیں، plan mode، اجازتیں، اپنا ماڈل چننا |
| 2 | سیاق کا انتظام | گفتگو وقت کے ساتھ کیوں بگڑتی ہے اور اسے کیسے ٹھیک کریں |
| 3 | قواعد کی فائل | اپنے پروجیکٹ کے لیے مستقل ہدایات ترتیب دینا |
| 4 | اپنے ٹول کو ذاتی بنانا | کمانڈز اور skills، hooks/plugins، subagents |
| 5 | دنیا سے جڑنا | اے آئی کو بیرونی خدمات سے جوڑنا (MCP) |
| 6 | مکمل عملی مثال | ایک مکمل کام، شروع سے آخر تک، دونوں ٹولز میں |
| 7 | کہاں چلائیں | ٹرمینل، IDE، ویب، ڈیسک ٹاپ |
| 8 | دونوں ٹولز اکٹھے | ایک ہی پروجیکٹ پر دونوں ٹولز استعمال کرنا |
کرکے سیکھنا چاہتے ہیں؟ پہلے حصہ 6 پر جائیں مکمل عملی مثال کے لیے، پھر واپس آ جائیں۔
📚 تدریسی معاون
مکمل پریزنٹیشن دیکھیں ، ایجنٹک کوڈنگ کا مختصر کورس
Part 1: بنیادیں
یہ چار تصورات وہ بنیاد ہیں جس پر باقی سب کچھ کھڑا ہے۔
1. یہ ٹولز اصل میں کیا ہیں
زیادہ تر لوگ سمجھتے ہیں کہ یہ چیٹ بوٹس ہیں جنہیں کوڈ کا علم ہے۔ یہ ایسے نہیں ہیں۔ ایک چیٹ بوٹ سوالوں کا جواب دیتا ہے۔ Claude Code اور OpenCode عمل کرتے ہیں۔ یہ آپ کی فائلیں پڑھتے ہیں، انہیں تبدیل کرتے ہیں، آپ کے کمپیوٹر پر کمانڈز چلاتے ہیں، اور کام مکمل ہونے تک چلتے رہتے ہیں۔ آپ بتاتے ہیں کہ آپ کیا چاہتے ہیں، وہ کام کرتے ہیں، آپ نتیجہ جانچتے ہیں۔
سب سے بڑی ذہنی تبدیلی: سوال پوچھنا بند کریں، ہدایت دینا شروع کریں۔
| سوال پوچھنا (کمزور) | ہدایت دینا (مضبوط) |
|---|---|
| "میں اپنے نوٹس کیسے ترتیب دوں؟" | "notes/ فولڈر کی ہر فائل پڑھو۔ ایک خلاصہ فائل بناؤ جس کا نام weekly-summary.md ہو، جس میں ہر کام والی شے درج ہو، شخص کے حساب سے گروپ کی ہوئی۔ جو کچھ [private] نشان زدہ ہے اسے چھوڑ دو۔" |
پہلا پرامپٹ آپ کو ایک وضاحت دیتا ہے جس پر آپ کو خود عمل کرنا پڑتا ہے۔ دوسرا پرامپٹ کام آپ کے لیے کر دیتا ہے۔ یہی فرق ہے۔ (یہ وہی خیال ہے جو AI Prompting کے تصور 1 میں ہے، مگر یہاں داؤ زیادہ ہے کیونکہ اے آئی واقعی آپ کی فائلیں بدل رہا ہے۔)
کیا آپ نے ابھی تک کوئی بھی ٹول انسٹال نہیں کیا؟ آگے پڑھنے سے پہلے ابھی ایک انسٹال کر لیں۔ اس کے بعد ہر چیز یہ فرض کرتی ہے کہ آپ ٹرمینل کھول کر چیزیں آزما سکتے ہیں۔
# macOS / Linux / WSL ، تجویز کردہ (خودکار اپ ڈیٹ)
curl -fsSL https://claude.ai/install.sh | bash
# Windows PowerShell
irm https://claude.ai/install.ps1 | iex
# macOS Homebrew (خودکار اپ ڈیٹ نہیں ، وقتاً فوقتاً `brew upgrade claude-code` چلائیں)
brew install --cask claude-code
# npm متبادل
npm install -g @anthropic-ai/claude-code
مکمل حوالہ: code.claude.com/docs۔
# تمام پلیٹ فارمز ، تجویز کردہ
curl -fsSL https://opencode.ai/install | bash
# macOS Homebrew
brew install opencode
# npm / bun / pnpm / yarn
npm install -g opencode-ai
مکمل حوالہ: opencode.ai/docs۔
انسٹال ہو جانے کے بعد، جس فولڈر میں آپ کام کرنا چاہتے ہیں اس میں ٹرمینل کھولیں اور claude (یا opencode) ٹائپ کریں۔ یہ آپ کو آپ کے پہلے سیشن میں لے جاتا ہے۔
فوری جانچ: آپ کس ماڈل پر ہیں؟ گہرائی میں جانے سے پہلے، تصدیق کر لیں کہ آپ اصل میں کس ماڈل سے بات کر رہے ہیں ، تاکہ آپ خاموشی سے سادہ کام پر مہنگا ماڈل ضائع نہ کر رہے ہوں، یا حیران نہ ہوں کہ سستا ماڈل کیوں جدوجہد کر رہا ہے۔
/status ٹائپ کریں اپنا موجودہ ماڈل دیکھنے کے لیے، اپنے پلان، ورکنگ ڈائریکٹری، اور سیاق کے استعمال کے ساتھ۔ مکمل فہرست دیکھنے اور بدلنے کے لیے، /model ٹائپ کریں اور مینو سے چنیں ، تبدیلی فوراً اثر کرتی ہے، کسی ری اسٹارٹ کے بغیر۔
/models ٹائپ کریں اپنے جڑے ہوئے سب فراہم کنندگان کے ہر ماڈل کو دیکھنے اور ان کے درمیان بدلنے کے لیے؛ فعال ماڈل TUI میں بھی دکھایا جاتا ہے۔ (کمانڈ لائن سے، opencode models دستیاب provider/model نام چھاپتا ہے ، جب آپ اپنی config میں ڈیفالٹ مقرر کر رہے ہوں تو یہ کارآمد ہے۔)
جب آپ /models چلاتے ہیں، تو چند مفت اختیارات پوشیدہ ماڈلز (stealth models) ہوتے ہیں ، کسی خفیہ نام کے تحت جاری کیے گئے جن کا بنانے والا ظاہر نہیں ہوتا (مثلاً، لکھنے کے وقت OpenCode Zen کا Big Pickle)۔ ان کے بارے میں جاننا فائدہ مند ہے، دو احتیاطوں کے ساتھ:
- یہ عارضی اور بغیر اعلان کے ہیں۔ ایک پوشیدہ ماڈل کسی فروش کا خاموشی سے کسی چیز کی آزمائش ہوتا ہے، اسے ظاہر کرنے سے پہلے۔ یہ اپنا رویہ بدل سکتا ہے، اس کا نام بدل سکتا ہے، یا بغیر کسی اطلاع کے غائب ہو سکتا ہے ، اس لیے اپنی عادتیں، ڈیفالٹس، یا کورس/پروجیکٹ کی ترتیبیں اس کے گرد نہ بنائیں۔
- "مفت" کا مطلب ہو سکتا ہے آپ ہی مصنوع ہیں۔ کسی ماڈل کی مفت آزمائشی مدت کے دوران، آپ کے پرامپٹس اور کوڈ اسے تربیت دینے اور بہتر بنانے کے لیے استعمال ہو سکتے ہیں۔ کسی پوشیدہ ماڈل کو کبھی کسی خفیہ چیز کی طرف نہ موڑیں ، کلائنٹ کا کام، نجی ریپوز، NDA کے تحت کوئی بھی چیز۔
یہ پھینکنے والے تجربات اور ورک فلو آزمانے کے لیے ٹھیک ہیں۔ جس چیز پر آپ انحصار کرتے ہیں اس کے لیے، کوئی مستحکم، نجی طور پر بل ہونے والا ماڈل ترجیح دیں (نیچے DeepSeek V4 کا نوٹ دیکھیں) جہاں فراہم کنندہ، قیمت، اور ڈیٹا پالیسی سب معلوم ہیں اور آپ کے نیچے سے بدلنے والے نہیں۔
یہاں سے آگے، اس صفحے پر ہر تصور ایسی چیز ہے جسے آپ اس سیشن میں آزما سکتے ہیں، صرف اس کے بارے میں پڑھ نہیں سکتے۔ اس صفحے کے ساتھ ایک ٹرمینل کھلا رکھیں اور ہر خیال کو اسی وقت چلائیں جب آپ اس تک پہنچیں۔
2026 تک تازہ۔ دونوں ٹولز اکثر اپ ڈیٹ ہوتے ہیں۔ کوئی بھی سیشن شروع کرنے سے پہلے
claude updateیاopencode upgradeچلائیں تاکہ آپ کے پاس تازہ ترین نسخہ موجود ہو۔
چونکہ OpenCode ماڈل سے آزاد ہے، آپ اسے جس بھی چیز پر موڑ سکتے ہیں جو بہترین لاگت-سے-معیار کا تناسب دے۔ میزبان ماڈلز میں، 2026 کے وسط تک سب سے مضبوط قدر DeepSeek V4 ہے، جو دو درجوں میں آتا ہے:
deepseek-v4-flash، کفایتی ڈیفالٹ۔ تقریباً $0.14 فی 1M ان پٹ ٹوکن (کیش ہٹ پر $0.0028 تک کم) اور $0.28 فی 1M آؤٹ پٹ ٹوکن، ایک 1M-ٹوکن سیاق کی کھڑکی اور tool-call سپورٹ کے ساتھ۔ طلبہ اور بڑے حجم کے کام کے لیے اسی درجے کو معیار بنائیں۔deepseek-v4-pro، اگلا درجہ جب آپ کو مضبوط استدلال درکار ہو۔ زیادہ قابل، پھر بھی frontier قیمت کا ایک حصہ۔
اسے ترتیب دیں (تقریباً 1 منٹ): opencode چلائیں ← /connect ٹائپ کریں ← deepseek درج کریں ← اپنی API کلید پیسٹ کریں (کلید وہاں بنائیں، اور تھوڑا پیشگی ادا شدہ بیلنس شامل کریں ، DeepSeek ادائیگی-بمطابق-استعمال ہے، اس لیے اکاؤنٹ میں کریڈٹ ہونے تک کلید کام نہیں کرے گی) ← ماڈل چنیں۔ DeepSeek کی اپنی رہنمائی ڈیفالٹ کے طور پر V4-Pro چنتی ہے، اس لیے اگر آپ سب سے سستا اختیار چاہتے ہیں تو deepseek-v4-flash چنیں۔
قیمتیں اور درجے اکثر بدلتے ہیں ، بجٹ بنانے سے پہلے لائیو صفحہ دیکھ لیں۔
📘 DeepSeek + OpenCode انضمام رہنمائی · 💰 DeepSeek ماڈلز اور قیمتیں
یہ قدرتی طور پر Plan / Execute تقسیم کے ساتھ جوڑ کھاتا ہے: کسی frontier ماڈل سے منصوبہ بنائیں، پھر کسی سستے DeepSeek پر مبنی OpenCode سیشن کو عمل درآمد کرنے دیں۔
Claude Code ڈیفالٹ کے طور پر Anthropic کے ماڈلز سے بات کرتا ہے، مگر آپ اسے اس کے بجائے DeepSeek V4 پر موڑ سکتے ہیں۔ دو راستے:
- سادہ مقامی راستہ۔ DeepSeek ایک Anthropic-مطابق endpoint پیش کرتا ہے، اس لیے آپ
claudeچلانے سے پہلےANTHROPIC_BASE_URL=https://api.deepseek.com/anthropicاور اپنی DeepSeek کلید کو auth token کے طور پر مقرر کر کے Claude Code کو سیدھا اس کے خلاف چلا سکتے ہیں۔ کوئی اضافی ٹولنگ نہیں۔ - راؤٹر راستہ ، claude-code-router۔ ایک کمیونٹی پراکسی جو Claude Code کے سامنے بیٹھتی ہے اور آپ کو درخواستیں DeepSeek (اور دیگر فراہم کنندگان) کی طرف موڑنے دیتی ہے، بشمول ہر کام کے لیے مختلف ماڈلز ، مثلاً منصوبہ بندی کے لیے ایک frontier ماڈل، عمل درآمد کے لیے
deepseek-v4-flash۔ آپclaudeکے بجائےccr codeسے شروع کرتے ہیں۔ ترتیب اور config کے لیے ریپو دیکھیں۔
دو سچی احتیاطیں: دونوں فریقِ ثالث / غیر سرکاری ترتیبیں ہیں، اس لیے یہ Claude Code کے اپ ڈیٹ ہونے پر ٹوٹ سکتی ہیں، اور آپ وہ "شروع سے Claude کی بہترین کارکردگی" کھو دیتے ہیں جس کے لیے Claude Code ٹیون شدہ ہے۔ اگر آپ کا اصل مقصد سستی DeepSeek پر مبنی کوڈنگ ہے، تو OpenCode زیادہ آسان راستہ ہے (یہ ساخت میں ماڈل سے آزاد ہے) ، یہ راستے تب کے لیے ہیں جب آپ خاص طور پر Claude Code کا انٹرفیس اور DeepSeek کی قیمت دونوں چاہتے ہوں۔
2. Plan mode (سب سے کم استعمال ہونے والی خصوصیت)
عام طور پر، جب آپ ان ٹولز کو کوئی ہدایت دیتے ہیں، تو وہ فوراً کام شروع کر دیتے ہیں: فائلیں پڑھنا، کوڈ بدلنا، کمانڈز چلانا۔ Plan mode یہ بدل دیتا ہے۔ یہ اے آئی کو "دیکھو مگر چھوؤ نہیں" والی حالت میں ڈال دیتا ہے۔ اے آئی آپ کی فائلیں پڑھ سکتا ہے اور کام کے بارے میں سوچ سکتا ہے، مگر کچھ بدل نہیں سکتا۔ کام کرنے کے بجائے، وہ مرحلہ وار منصوبہ لکھ دیتا ہے کہ وہ کیا کرے گا۔ آپ منصوبہ پڑھتے ہیں، تبدیلیاں تجویز کرتے ہیں، اور تب جا کر اسے اصل کام شروع کرنے دیتے ہیں۔
دونوں ٹولز اس کی سہولت دیتے ہیں۔ اسے آن کرنے کا طریقہ تھوڑا مختلف ہے، مگر خیال ایک ہی ہے۔
اجازت کے طریقوں میں سے گزرنے کے لیے Shift+Tab دبائیں۔ پہلی دفعہ دبانے سے آپ auto-accept میں آ جاتے ہیں؛ دوسری دفعہ آپ plan mode میں آ جاتے ہیں۔ Plan mode میں، ماڈل پڑھ سکتا ہے مگر لکھ نہیں سکتا: کوئی فائل تبدیلی نہیں، کوئی shell کمانڈ نہیں۔
Build mode (اے آئی سب کچھ کر سکتا ہے) اور Plan mode (اے آئی صرف پڑھ سکتا ہے، کچھ بدل نہیں سکتا) کے درمیان بدلنے کے لیے Tab دبائیں۔ Plan mode میں، اگر آپ اس سے کچھ لکھنے یا بدلنے کو کہیں، تو وہ بتائے گا کہ وہ ایسا نہیں کر سکتا اور آپ کے دوبارہ Build پر آنے کا انتظار کرے گا۔ وہی خیال جو Claude Code کا ہے: پہلے دیکھو، پھر عمل کرو۔
عملی طور پر یہ کیسا لگتا ہے۔ آپ plan mode میں داخل ہوتے ہیں، پھر ایک عام ہدایت ٹائپ کرتے ہیں:
میری ماں کے بارے میں ایک نظم لکھو اور اسے
for-mom.mdکے نام سے محفوظ کرو۔
اسے لکھنے کے بجائے، اے آئی پہلے ایک منصوبے کے ساتھ آتا ہے:
منصوبہ
- کلاسیکی سونیٹ کے انداز میں 5 بندوں کی نظم لکھنا۔
- رسمی، قدیم طرز کی زبان استعمال کرنا۔
- ایک شاندار، ڈرامائی اختتام کی طرف بڑھنا۔
for-mom.mdکے نام سے محفوظ کرنا۔ابھی کچھ نہیں لکھا گیا۔ آگے بڑھنے کے لیے منظوری دیں، یا بتائیں کہ کیا تبدیل کرنا ہے۔
یہ وہ نہیں جو آپ کے ذہن میں تھا ، آپ کچھ مختصر، گرم جوش، اور سادہ چاہتے تھے، رسمی سونیٹ نہیں۔ تو آپ مزاحمت کرتے ہیں:
اسے مختصر اور گرم جوش رکھو ، چار سطریں، روزمرہ زبان، کچھ بھی شاندار نہیں۔ ایسی چیز جو میں سالگرہ کے کارڈ پر لکھ سکوں۔
اے آئی منصوبہ اپ ڈیٹ کرتا ہے۔ اب آپ منظوری دیتے ہیں، اور وہ وہی نظم لکھتا ہے جو آپ کا اصل مطلب تھا ، اس رسمی سونیٹ کے بجائے جس سے آپ کو صفائی دے کر جان چھڑانی پڑتی۔
منصوبے کی زحمت کیوں؟ دو وجوہات:
- آپ غلطیاں ہونے سے پہلے پکڑ لیتے ہیں۔ اوپر بالکل یہی ہوا ، غلط مفروضہ منصوبے میں سامنے آ گیا، کسی مکمل مسودے میں نہیں جس سے آپ کو بحث کر کے جان چھڑانی پڑتی۔ چار سطر کی نظم پر یہ معمولی بچت ہے؛ مگر جب اے آئی 10 فائلیں بدلنے والا ہو، تو یہ ایک فوری تصحیح اور ایک طویل صفائی کے درمیان فرق ہے۔
- اے آئی پہلے منصوبہ بنانے پر بہتر کام کرتا ہے۔ منصوبہ لکھنا اے آئی کو کام شروع کرنے سے پہلے اس پر سوچنے پر مجبور کرتا ہے۔ منصوبے کے بغیر، وہ ایک ہی وقت میں سوچنے اور لکھنے کی کوشش کرتا ہے، اور نتیجہ عموماً بدتر ہوتا ہے۔
عام اصول: اگر کام میں 10 منٹ سے زیادہ لگیں گے، تو پہلے plan mode استعمال کریں۔ بڑے کاموں کے لیے، اے آئی سے کہیں کہ منصوبہ کسی فائل میں محفوظ کرے (جیسے docs/plans/my-plan.md) تاکہ آپ بعد میں واپس آ سکیں یا اسے کسی تازہ سیشن کے ساتھ بانٹ سکیں۔
اسے ایسے سمجھیں جیسے مضمون سے پہلے خاکہ لکھنا۔ آپ اپنی ساخت جانے بغیر 10 صفحے کا مقالہ لکھنا شروع نہیں کریں گے۔ یہاں وہی خیال ہے: پہلے منصوبہ، پھر تعمیر۔
3. اجازتوں کا ضبط
ہر بار جب یہ ٹولز کچھ کرنا چاہتے ہیں (فائل بدلنا، کمانڈ چلانا)، وہ پہلے آپ سے اجازت مانگتے ہیں۔ آپ اسے چھوڑ سکتے ہیں اور انہیں بغیر پوچھے سب کچھ کرنے دے سکتے ہیں، مگر جب آپ شروعات کر رہے ہوں تو ایسا نہ کریں۔ آپ یہ دیکھنا چاہتے ہیں کہ اے آئی کیا کر رہا ہے اس سے پہلے کہ وہ کرے۔
چند سیشنوں کے بعد، آپ غور کریں گے کہ کچھ کام ہمیشہ محفوظ ہوتے ہیں (جیسے فائلیں پڑھنا یا ٹیسٹ چلانا)۔ آپ ٹول کو بتا سکتے ہیں کہ ان مخصوص کاموں کے بارے میں پوچھنا بند کر دے اور انہیں خودکار طور پر منظور کرے۔ یہ ہے طریقہ:
آپ کو ہر سطر سمجھنے کی ضرورت نہیں۔ ہر کوڈ بلاک کے بعد کی وضاحت آپ کو بتاتی ہے کہ یہ کیا کرتا ہے۔ جیسے جیسے آپ ٹول استعمال کریں گے، یہ سیٹنگز قدرتی طور پر سمجھ آنے لگیں گی۔
.claude/settings.json:
{
"permissions": {
"allow": [
"Read",
"Edit",
"Write",
"Bash(npm test)",
"Bash(npm run lint)",
"Bash(npm run build)",
"Bash(git status)",
"Bash(git diff *)",
"Bash(git log *)"
],
"deny": ["Bash(rm -rf *)", "Bash(npm publish *)", "Bash(git push *)"]
}
}
opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"permission": {
"*": "ask",
"read": "allow",
"edit": "allow",
"bash": {
"*": "ask",
"npm test": "allow",
"npm run lint": "allow",
"npm run build": "allow",
"git status*": "allow",
"git diff*": "allow",
"git log*": "allow",
"rm -rf*": "deny",
"npm publish*": "deny",
"git push*": "deny"
}
}
}
OpenCode آپ کو اجازتوں پر زیادہ قابو دیتا ہے۔ آپ ہر قسم کے کام کے لیے الگ الگ قواعد مقرر کر سکتے ہیں (پڑھنا، بدلنا، کمانڈز چلانا)۔ اس میں ایک خودکار حفاظتی خصوصیت بھی ہے: اگر اے آئی ایک ہی کام لگاتار تین بار بغیر کسی پیش رفت کے آزمائے، تو وہ خود بخود رک جاتا ہے۔
تجویز: اطلاعات ترتیب دیں۔ یہ ٹولز طویل کاموں پر کام کر سکتے ہیں جبکہ آپ دوسری چیزیں کرتے ہیں۔ وہ حربہ جو اسے کارآمد بناتا ہے وہ ہے ایک اطلاع پانا جب اے آئی مکمل کر لے یا آپ کا ان پٹ درکار ہو۔ اس طرح آپ ایک کام شروع کر سکتے ہیں، دوسرے کام پر جا سکتے ہیں، اور جب آپ کی ضرورت ہو تب واپس آ سکتے ہیں۔
- Claude Code: کمیونٹی ٹولز جیسے
cc-notifyآپ کو ڈیسک ٹاپ اطلاعات بھیج سکتے ہیں۔ - OpenCode: ڈیسک ٹاپ ایپ خود بخود اطلاعات بھیجتی ہے۔ ٹرمینل نسخے کے لیے، آپ ایک plugin شامل کر سکتے ہیں جو آپ کو اطلاع دے۔
4. ماڈل کو کام سے ملائیں
دونوں ٹولز آپ کو چننے دیتے ہیں کہ کون سا اے آئی ماڈل کام کرے ، اور بدلنے میں ایک کمانڈ لگتی ہے۔ زیادہ تر نوآموز اس سیٹنگ کو کبھی نہیں چھوتے، جو دونوں سمتوں میں غلطی ہے: یا تو وہ معمولی کاموں پر مہنگا ماڈل ضائع کرتے ہیں، یا کسی مشکل مسئلے پر کمزور ماڈل سے لڑتے ہیں اور خراب نتائج کا الزام خود کو دیتے ہیں۔
اس انتخاب کے پیچھے ایک سادہ سودا ہے۔ سب سے قابل ماڈل بہترین سوچنے والے ہیں ، وہ منصوبہ بناتے ہیں، پیچیدہ کوڈ پر استدلال کرتے ہیں، اور ابہام سنبھالتے ہیں ، مگر ان کی قیمت سب سے زیادہ ہے اور آپ کی حدیں سب سے تیزی سے ختم کرتے ہیں۔ سستے (اور مفت) ماڈلز کسی واضح منصوبے کی پیروی میں بالکل اچھے ہیں: فائلیں بدلنا، ٹیسٹ چلانا، دوبارہ ترتیب دینا، بار بار کی تبدیلیاں۔ مہارت یہ ہے کہ ہر قسم کا کام صحیح ماڈل کو بھیجا جائے۔
| کام | کس کی طرف جائیں |
|---|---|
| منصوبہ بندی، آرکیٹیکچر، "یہ کیسے کرنا ہے یہ سمجھنا"، کسی الجھن والی چیز کی ڈیبگنگ | جو سب سے قابل ماڈل آپ کے پاس ہے |
| پہلے سے منظور کردہ منصوبے کی پیروی ، معمول کی تبدیلیاں، فارمیٹنگ، ٹیسٹ چلانا، بوائلر پلیٹ | کوئی سستا یا مفت ماڈل |
| ایک فوری سوال یا ایک سطر کی درستی | جو پہلے سے لوڈ ہے؛ زیادہ نہ سوچیں |
آپ پہلے ہی سیکھ چکے ہیں کہ تصور 1 میں اپنا ماڈل کیسے دیکھنا اور بدلنا ہے۔ اسے سوچ سمجھ کر چننا ہی عادت ہے:
ایک زیادہ قابل Claude (مشکل سوچ کے لیے) اور ایک تیز، سستے (معمول کے کام کے لیے) کے درمیان بدلنے کے لیے /model ٹائپ کریں؛ تبدیلی فوراً اثر کرتی ہے، کسی ری اسٹارٹ کے بغیر۔ ایک عام ترتیب یہ ہے کہ مضبوط ماڈل کو plan mode سنبھالنے دیا جائے اور ایک تیز ماڈل عمل درآمد کرے ، تاکہ مہنگی سوچ ایک بار، شروع میں ہو جائے۔
چونکہ OpenCode ماڈل سے آزاد ہے، آپ کا انتخاب وسیع تر ہے: /models ٹائپ کریں ہر اس فراہم کنندہ میں بدلنے کے لیے جس سے آپ جڑے ہیں ، منصوبہ بندی کے لیے ایک frontier ماڈل، عمل درآمد کے لیے ایک سستا میزبان ماڈل جیسے deepseek-v4-flash (تصور 1 میں DeepSeek V4 کی تجویز دیکھیں) یا حتیٰ کہ ایک مفت/مقامی ماڈل۔ آپ opencode.json میں ایک ڈیفالٹ بھی مقرر کر سکتے ہیں، اور subagents کو ان کا اپنا سستا ماڈل دے سکتے ہیں۔
یہ سیدھا plan mode (تصور 2) کے ساتھ جوڑ کھاتا ہے۔ کسی بھی کام کا مہنگا حصہ سوچ ہے ، پروجیکٹ پڑھنا، انداز طے کرنا، یہ تاڑنا کہ کیا غلط ہو سکتا ہے۔ ایک بار یہ ایک تحریری منصوبہ بن جائے، تو باقی "بس یہ مراحل کرو" رہ جاتا ہے، جو ایک سستا ماڈل ٹھیک کر دیتا ہے۔ تو: مضبوط ماڈل سے منصوبہ بنائیں، سستے سے عمل کریں۔ یہی واحد چال ہے جہاں سے زیادہ تر لاگت کی بچت آتی ہے، معیار کے نقصان کے بغیر ، اور یہی حصہ 8 میں Plan / Execute تقسیم کی ریڑھ کی ہڈی ہے۔
دو سچی احتیاطیں۔ پہلی، سستے ماڈلز کو زیادہ واضح ہدایات درکار ہوتی ہیں ، وہ ایک اچھے منصوبے کی اچھی پیروی کرتے ہیں مگر بُری طرح اپنی طرف سے چیزیں بناتے ہیں، اس لیے جتنا کمزور ماڈل، اتنا ہی منصوبے کو زیادہ تفصیل سے بتانا پڑتا ہے۔ دوسری، حد سے زیادہ بہتری نہ کریں: ہر چند منٹ بعد ماڈل بدلنا پیسے بچانے کے لیے آپ کی توجہ خرچ کر دیتا ہے۔ ڈیفالٹ کے طور پر مضبوط ماڈل رکھیں، واضح معمولی کاموں کے لیے سستے پر آئیں، اور اسے وہیں رہنے دیں۔
عام اصول: کیا کرنا ہے یہ طے کرنے کے لیے ایک مضبوط ماڈل، اور اسے کرنے کے لیے ایک سستا ماڈل۔ جب کوئی سستا ماڈل دائروں میں گھومنے لگے، تو یہ آپ کا اشارہ ہے کہ کام کو مضبوط ماڈل کی ضرورت تھی ، اوپر بدلیں، بار بار کوشش نہ کرتے رہیں۔
Part 2: سیاق کا انتظام
یہ رہا اس کورس کا سب سے اہم خیال: کسی بھی لمحے، ماڈل صرف اسی چیز پر عمل کر سکتا ہے جو فی الحال اس کے سامنے ہے ، اس کا سیاق (context)۔ اور وہ سیاق کوئی ایک بڑی بالٹی نہیں جس میں آپ چیزیں پھینکتے رہیں۔ یہ تہوں کا ایک ڈھیر ہے، اور آپ ہر باری پر ہر تہہ کی قیمت ادا کرتے ہیں۔
اصل بات پانچ ناموں میں نہیں ہے ، بلکہ بائیں طرف کی تقسیم میں ہے۔ اوپری تہیں مقررہ ہیں: سسٹم پرامپٹ اور آپ کی قواعد کی فائل لوڈ ہوتی ہیں چاہے آپ چاہیں یا نہ چاہیں۔ نیچے سب کچھ آپ کے سنبھالنے کا ہے ، گفتگو بڑھتی رہتی ہے جب تک آپ اسے /compact یا /clear نہ کریں، فائلیں صرف تب لوڈ ہوتی ہیں جب آپ ان کی طرف اشارہ کریں، skills صرف تب لوڈ ہوتی ہیں جب انہیں بلایا جائے، اور ایک subagent اپنی بھاری پڑھائی ایک الگ کھڑکی میں کرتا ہے اور صرف ایک خلاصہ واپس کر دیتا ہے۔
یہی پورا کھیل ہے۔ اچھا سیاق کا انتظام کوئی حربہ نہیں؛ یہ اس ڈھیر کو ہلکا رکھنے کی عادت ہے ، جو کام کو درکار ہے وہ لوڈ کرنا، اور جو نہیں چاہیے اسے صاف کرنا۔ پھولا ہوا ڈھیر زیادہ ٹوکن خرچ کرتا ہے، مگر اس سے بھی بُری بات: وہ اس حصے کو دبا دیتا ہے جو اہم ہے۔ کھڑکی میں جتنا زیادہ کوڑا، اتنا ہی ماڈل کو سگنل ڈھونڈنے کے لیے زیادہ محنت کرنی پڑتی ہے، اور اتنے ہی اس کے جواب بھٹکتے ہیں۔
AI Prompting کورس میں آپ نے سیکھا کہ آپ اے آئی کو جو دیتے ہیں وہ اس سے زیادہ اہم ہے کہ آپ کیسے پوچھتے ہیں۔ یہاں داؤ زیادہ ہے: کسی چیٹ میں، خراب سیاق آپ کو خراب جواب دیتا ہے؛ ان ٹولز کے ساتھ، خراب سیاق کا مطلب ہے کہ اے آئی سیدھے آپ کے پروجیکٹ میں خراب کوڈ لکھ دیتا ہے۔ اسی لیے باقی Part 2 کی ہر چیز انہی تہوں میں سے کسی ایک پر قابو پانے کا ایک خاص طریقہ ہے ، اور اسی لیے، اگر آپ اس مختصر کورس کا ایک حصہ یاد رکھیں، تو یہ وہی ہونا چاہیے۔ یہ دونوں ٹولز میں ایک ہی طرح کام کرتا ہے۔
5. سیاق کی خرابی (context rot) حقیقی ہے
اے آئی ایک وقت میں صرف محدود مقدار میں معلومات رکھ سکتا ہے۔ اسے سیاق کی کھڑکی (context window) کہتے ہیں۔ اسے ایک گروپ چیٹ کی طرح سمجھیں: اے آئی صرف اسی چیٹ کے پیغام دیکھ سکتا ہے۔ اگر آپ نے چیٹ میں پہلے کچھ کہا تھا، تو اے آئی اوپر اسکرول کر کے دیکھ سکتا ہے۔ اگر آپ نے کبھی کہا ہی نہیں، تو اے آئی کو اس کا علم نہیں۔ جدید اے آئی ایک بہت لمبی چیٹ سنبھال سکتا ہے (لاکھوں الفاظ)، مگر پھر بھی اس کی حدیں ہیں۔
یہ کیوں اہم ہے:
مسئلہ 1: چیٹ آپ کے سوچنے سے زیادہ تیزی سے لمبی ہو جاتی ہے۔
آپ کا بھیجا ہر پیغام، ہر فائل جو آپ اے آئی سے پڑھواتے ہیں، ہر جواب جو اے آئی دیتا ہے، یہ سب چیٹ کی تاریخ میں جُڑتا جاتا ہے۔ 20-30 پیغاموں کے تبادلے کے بعد، اور چند فائلیں جو آپ نے اسے دیکھنے کو کہیں، چیٹ پہلے ہی بہت لمبی ہو چکی ہوتی ہے۔
مشکل بات: کوئی انتباہ نہیں جو آپ کو بتائے "یہ گفتگو بہت لمبی ہوتی جا رہی ہے۔" یہ بس پسِ منظر میں خاموشی سے بڑھتی رہتی ہے۔
مسئلہ 2: گفتگو بڑھنے کے ساتھ اے آئی چیزیں یاد رکھنے میں کمزور ہوتا جاتا ہے۔
یہ رہا حیران کن حصہ۔ حد تک پہنچنے سے پہلے ہی، اے آئی جدوجہد شروع کر دیتا ہے۔ جب گفتگو بہت لمبی ہو، تو اے آئی کو اہم حصے ڈھونڈنے میں زیادہ مشکل ہوتی ہے۔ آپ غور کر سکتے ہیں:
- اے آئی کسی ایسی چیز کو نظر انداز کر دیتا ہے جو آپ نے 20 پیغام پہلے بتائی تھی (آپ نے کہا تھا، مگر وہ اتنا پہلے تھا کہ اے آئی نشان کھو دیتا ہے)
- اے آئی وہ کام دوبارہ کرتا ہے جو وہ پہلے ہی مکمل کر چکا (وہ بھول گیا کہ پہلے ہی کر چکا ہے)
- اے آئی ناموں یا تفصیلات کے بارے میں الجھ جاتا ہے جو پہلے درست تھیں
اسے سیاق کی خرابی (context rot) کہتے ہیں۔ گفتگو تو چل رہی ہے، مگر اے آئی کے کام کا معیار آہستہ آہستہ بگڑ رہا ہے کیونکہ بہت زیادہ پرانی معلومات جمع ہو گئی ہیں۔
مسئلہ 3: لمبی گفتگوؤں پر زیادہ پیسے لگتے ہیں۔
ہر بار جب آپ پیغام بھیجتے ہیں، اے آئی صرف آپ کا نیا پیغام نہیں پڑھتا۔ وہ پوری گفتگو پہلے پیغام سے دوبارہ پڑھتا ہے۔ تو اگر آپ کے 30 پیغاموں کا تبادلہ ہو چکا ہے، تو اے آئی ہر بار جب آپ 31واں پیغام بھیجتے ہیں، تینوں 30 پیغام دوبارہ پڑھتا ہے۔
اگر آپ فی استعمال ادائیگی کر رہے ہیں (جیسے زیادہ تر OpenCode ترتیبیں)، تو اس کا مطلب ہے کہ لمبی گفتگوؤں پر کہیں زیادہ پیسے لگتے ہیں۔ اگر آپ سبسکرپشن پلان پر ہیں (جیسے Claude Code Pro)، تو آپ اپنی روزانہ استعمال کی حدوں تک تیزی سے پہنچ جاتے ہیں۔ دونوں صورتوں میں، ایک لمبی، الجھی ہوئی گفتگو آپ کا بجٹ نچوڑ لیتی ہے۔
خلاصہ: اپنی گفتگوؤں کو مختصر اور مرکوز رکھیں۔ اے آئی کو صرف وہی معلومات دیں جو موجودہ کام کے لیے درکار ہیں، وہ سب کچھ نہیں جو آپ کے پاس ہے۔ ایک صاف، مرکوز گفتگو ایک لمبی، بھری ہوئی گفتگو سے کہیں بہتر کام کرتی ہے۔
دیکھیں کہ آپ کا سیاق کتنا بھرا ہے۔ آپ ڈھیر کو ہلکا نہیں رکھ سکتے اگر آپ اسے دیکھ ہی نہ سکیں۔ دونوں ٹولز آپ کو اپنا موجودہ استعمال پڑھنے دیتے ہیں ، بس وہ اسے مختلف طریقے سے دکھاتے ہیں۔
/context ٹائپ کریں مکمل تفصیل کے لیے: کھڑکی میں سے کل استعمال شدہ ٹوکن (مثلاً 25.6k/1m tokens (3%))، زمرے کے حساب سے بٹا ہوا ، سسٹم پرامپٹ، tools، memory/قواعد کی فائل، skills، اور آپ کی گفتگو۔ یہ یہ تک نشان زد کرتا ہے کہ کیا تراشنے کے قابل ہے۔ آپ کو ان پٹ کے قریب ایک چلتا ہوا فیصد بھی ملتا ہے جیسے جیسے آپ کام کرتے ہیں، تاکہ آپ کو بار بار پوچھنا نہ پڑے۔
OpenCode آپ کا استعمال اپنے انٹرفیس میں براہ راست دکھاتا ہے (پوری اسکرین والا ٹرمینل منظر) ، فعال ماڈل، استعمال شدہ ٹوکن، اور کھڑکی کا فیصد۔ یہ اسکرین پر کہاں بیٹھتا ہے یہ نسخے اور ٹرمینل کی چوڑائی کے ساتھ بدلتا ہے، اس لیے بس چلتا ہوا ٹوکن/فیصد والا گیج ڈھونڈیں۔ ابھی تک کوئی بلٹ ان /context طرز کی تفصیل والی کمانڈ نہیں، اس لیے آپ وہ گیج انٹرفیس سے پڑھتے ہیں بجائے اسے بلانے کے۔ (کمیونٹی plugins ایک /context کمانڈ شامل کر سکتے ہیں مکمل تفصیل کے ساتھ اگر آپ چاہیں۔)
آپ جس بھی ٹول میں ہوں، حرکت ایک ہی ہے: گیج پر ایک نظر ڈالیں، اس کے بھرنے کا انتظار نہ کریں۔ معیار عام طور پر کھڑکی کے تکنیکی طور پر بھرنے سے کہیں پہلے پھسلنے لگتا ہے ، ایک بار جب کوئی سیشن اپنی کھڑکی کے تقریباً آدھے سے گزر جائے، تو یہ آپ کا اشارہ ہے کہ /compact یا /clear (اگلا) کریں، نہ کہ جب یہ 100 فیصد کو چھوئے۔
6. /clear اور /compact
جب چیٹ بہت لمبی ہو جائے، تو آپ کے پاس دو اختیار ہیں۔ یقینی بنائیں کہ آپ درست چنیں:
اختیار 1: بالکل نئی چیٹ شروع کریں۔ اسے تب استعمال کریں جب آپ ایک کام مکمل کر چکے ہوں اور بالکل مختلف چیز شروع کرنا چاہتے ہوں۔ پرانی چیٹ مٹ جاتی ہے۔
- Claude Code:
/clearٹائپ کریں - OpenCode:
/new(یا/clear) ٹائپ کریں
اختیار 2: موجودہ چیٹ سکڑائیں۔ اسے تب استعمال کریں جب آپ ابھی اسی کام پر ہوں مگر چیٹ بہت لمبی ہو گئی ہو۔ اے آئی پوری گفتگو پڑھتا ہے، ایک مختصر خلاصہ لکھتا ہے، اور باقی سب کچھ پھینک دیتا ہے۔ آپ خلاصے سے کام جاری رکھتے ہیں۔
- دونوں ٹولز:
/compactٹائپ کریں
آپ اسے بتا سکتے ہیں کہ کیا رکھنا ہے: /compact keep the file names and the decisions we made۔
انہیں آپس میں نہ ملائیں۔ /clear سب کچھ مٹا کر نئے سرے سے شروع کرتا ہے۔ /compact اہم حصے رکھتا ہے اور باقی ہٹا دیتا ہے۔ اگر آپ کسی کام کے درمیان /clear استعمال کریں، تو آپ اپنی ساری پیش رفت کھو دیتے ہیں۔ اگر آپ /compact تب استعمال کریں جب آپ کو نئے سرے سے شروع کرنا چاہیے تھا، تو آپ پرانا کوڑا ایک نئے کام میں لے جاتے ہیں۔
7. سیشن دوبارہ شروع کریں
آپ کی ہر گفتگو خود بخود محفوظ ہو جاتی ہے۔ آپ ٹول بند کر سکتے ہیں، اپنا کمپیوٹر بند کر سکتے ہیں، اور بعد میں واپس آ کر بالکل وہیں سے جاری رکھ سکتے ہیں جہاں آپ نے چھوڑا تھا۔
- Claude Code: اپنے ٹرمینل میں
claude --resumeچلائیں۔ آپ کو اپنی پچھلی گفتگوؤں کی فہرست نظر آئے گی۔ ایک چنیں اور جاری رکھیں۔ - OpenCode: اپنی محفوظ گفتگوئیں دیکھنے کے لیے ٹول کے اندر
/sessions(یا/resume) ٹائپ کریں۔
یہ کیوں کارآمد ہے:
- کل جاری رکھیں۔ بڑے کام اکثر ایک سے زیادہ نشست میں مکمل ہوتے ہیں۔ نئے سرے سے شروع کرنے کے بجائے، بس وہیں سے جاری رکھیں جہاں آپ رکے تھے۔
- کئی چیزوں پر کام کریں۔ آپ کے پاس ایک گفتگو ایک کام پر اور دوسری گفتگو کسی مختلف کام پر چل سکتی ہے۔ جب چاہیں ان کے درمیان بدلتے رہیں۔
تجویز: اگر آپ نے پہلے کوئی منصوبہ فائل محفوظ کی تھی (جیسے docs/plans/my-plan.md)، تو آپ ایک تازہ گفتگو شروع کر کے اسے بھی بتا سکتے ہیں: "docs/plans/my-plan.md پڑھو اور مرحلہ 4 سے جاری رکھو۔" منصوبہ فائل ایک بیک اپ کا کام دیتی ہے اگر آپ پرانی گفتگو دوبارہ شروع نہ کر سکیں۔ (مزید تفصیل کے لیے، دیکھیں باب 17 § سیشن کا انتظام۔)
اگر اے آئی نے غلطی کر دی؟ آپ اسے واپس کر سکتے ہیں۔
کبھی کبھی اے آئی غلط فائل بدل دیتا ہے، خراب کوڈ لکھ دیتا ہے، یا آپ کی بات غلط سمجھ لیتا ہے۔ گھبرائیں نہیں ، دونوں ٹولز آپ کو واپس لوٹنے دیتے ہیں، تھوڑے مختلف طریقوں سے:
- Claude Code:
Escدو بار دبائیں (جب ان پٹ باکس خالی ہو)، یا/rewindٹائپ کریں۔ آپ کو سیشن کے ہر پرامپٹ کا مینو ملتا ہے؛ ایک چنیں اور منتخب کریں کہ کیا بحال کرنا ہے ، کوڈ، گفتگو، یا دونوں۔ غور کریں کہ یہ اے آئی کی اپنی فائل تبدیلیاں واپس کرتا ہے، وہ چیزیں نہیں جو اس نے shell کمانڈز چلا کر کیں (اس طرح کوئی حذف یا منتقل کی گئی فائل واپس نہیں آئے گی)۔ کوئی "ری ڈو" نہیں ، rewind آپ کو کسی چنے ہوئے مقام پر لے جاتا ہے بجائے آگے پیچھے قدم رکھنے کے، اس لیے سوچ سمجھ کر rewind کریں۔ - OpenCode: اے آئی کی آخری تبدیلی پلٹنے کے لیے
/undoٹائپ کریں، اور اگر آپ کا ارادہ بدل جائے تو/redo۔ یہ پسِ پردہ git استعمال کر کے کام کرتا ہے، اس لیے آپ کے پروجیکٹ کا ایک git repository ہونا ضروری ہے۔
دونوں صورتوں میں، اسے تجربات کے لیے ایک حفاظتی جال سمجھیں، git کا متبادل نہیں۔ جو کچھ آپ رکھنا چاہتے ہیں اس کے لیے، اسے commit کریں ، چیک پوائنٹس اور undo سیشن کی سطح کی سہولتیں ہیں، مستقل تاریخ نہیں۔
Claude Code کا undo فائل تبدیلیوں کا احاطہ کرتا ہے مگر ٹرمینل کمانڈز کا نہیں۔ مثلاً، اگر اے آئی نے کوئی کمانڈ چلائی جس نے ایک فائل حذف کر دی، تو undo اسے واپس نہیں لائے گا۔ OpenCode کا undo ہر چیز کا احاطہ کرتا ہے (فائل تبدیلیاں اور ٹرمینل کمانڈز) کیونکہ یہ ساری تبدیلیاں ٹریک کرنے کے لیے git استعمال کرتا ہے۔
ان تینوں کمانڈز کے لیے ایک فوری فیصلہ اصول:
تشخیص: جب سیاق خراب ہو جائے
آپ کیسے جانیں کہ چیٹ بہت لمبی ہو گئی ہے؟ ان علامات کا خیال رکھیں:
- اے آئی بار بار معذرت کرتا ہے مگر واقعی کچھ ٹھیک نہیں کرتا۔
- اے آئی کوڈ کے ایک ہی ٹکڑے کو بار بار بدلتا ہے بغیر اسے بہتر کیے۔
- اے آئی ایسی فائلوں یا ناموں کا ذکر کرتا ہے جو آپ کے پروجیکٹ میں موجود ہی نہیں۔
- اے آئی کوئی اصول بھول جاتا ہے جو آپ نے اسی گفتگو میں پہلے بتایا تھا۔
- اے آئی کے جواب زیادہ مددگار ہونے کے بجائے زیادہ لمبے اور مبہم ہوتے جاتے ہیں۔
جب آپ ان میں سے کوئی دیکھیں، پیغام بھیجنا بند کریں۔ آپ کی پہلی جبلت ہوگی کہ مسئلہ ایک بار پھر سمجھائیں۔ ایسا نہ کریں۔ پہلے سے زیادہ بھری ہوئی گفتگو میں مزید پیغام بھیجنا اسے صرف بدتر کرتا ہے۔
اس کے بجائے، ری سیٹ کریں:
/compactاستعمال کریں اگر آپ اسی کام پر کام جاری رکھنا چاہتے ہیں (یہ اہم حصے بچا کر باقی صاف کر دیتا ہے)۔/clear(یا OpenCode میں/new) استعمال کریں اگر آپ بالکل نئے سرے سے شروع کرنا چاہتے ہیں۔
ری سیٹ کرنے کے پانچ منٹ، ایک ایسے اے آئی سے ایک گھنٹہ لڑنے سے بہتر ہیں جو اب گفتگو کا نشان نہیں رکھ سکتا۔
تشخیص: جب سیاق کی لاگت اچانک بڑھ جائے
یاد رکھیں: ایک لمبی، الجھی ہوئی گفتگو نہ صرف اے آئی کو اپنے کام میں کمزور کرتی ہے ، بلکہ آپ کو زیادہ پیسے بھی لگواتی ہے۔ جیسے جیسے گفتگو بڑھتی ہے، اے آئی کو ہر پیغام پر کارروائی کے لیے زیادہ متن ملتا ہے۔
ایک اہم باریکی: کیشنگ۔ آپ فرض کر سکتے ہیں کہ آپ ہر ایک پیغام پر پوری گفتگو دوبارہ پڑھنے کی پوری قیمت ادا کرتے ہیں۔ عام طور پر آپ نہیں کرتے ، مگر یہ رعایت ماڈل کے فراہم کنندہ کی طرف سے آتی ہے، ٹول کی طرف سے نہیں۔ زیادہ تر بڑے ماڈل APIs (Anthropic، DeepSeek، اور دیگر) prompt caching کی سہولت دیتے ہیں: وہ آپ کے سیاق کا مستحکم اگلا حصہ ، سسٹم پرامپٹ، آپ کی قواعد کی فائل، پہلے کی باریاں ، محفوظ رکھتے ہیں اور اسے ایک بھاری رعایت پر دوبارہ استعمال کرتے ہیں (اکثر عام قیمت کے تقریباً دسویں حصے پر، کبھی اس سے کہیں کم)، اس لیے آپ پوری قیمت صرف اسی کی ادا کرتے ہیں جو آپ کے آخری پیغام کے بعد نیا ہے۔ Claude Code اور OpenCode اس اگلے حصے کو مستحکم رکھنے کے لیے بنائے گئے ہیں تاکہ کیش کام کرتا رہے ، مگر کیشنگ خود فراہم کنندہ کی سہولت ہے، اور اس کے بغیر کوئی ماڈل کوئی رعایت نہیں دیتا۔ پیچ: رعایت صرف تب تک رہتی ہے جب تک سیاق کا اگلا حصہ بدلے بغیر رہے۔ اپنی قواعد کی فائل بدلیں، یا اپنی تاریخ میں اِدھر اُدھر چھلانگیں لگائیں، تو کیش اسی نقطے سے ری سیٹ ہو جاتا ہے اور آپ پھر پوری قیمت ادا کرتے ہیں۔ (کیش کسی سیشن کے کچھ دیر بے کار بیٹھنے کے بعد بھی ختم ہو جاتے ہیں۔) یہی وجہ ہے کہ نیچے دیے گئے اچانک اضافے اسی طرح ہوتے ہیں جیسے ہوتے ہیں۔
| آپ کیا محسوس کرتے ہیں | یہ کیوں ہو رہا ہے | اسے کیسے ٹھیک کریں |
|---|---|---|
| آپ کا استعمال گفتگو کے درمیان اچانک بڑھ گیا | آپ نے اپنی سیٹنگ فائل (CLAUDE.md یا AGENTS.md) بدلی، جو کیش کی رعایت ری سیٹ کر دیتی ہے اور اے آئی کو سب کچھ نئے سرے سے دوبارہ پڑھنے پر مجبور کرتی ہے | سیٹنگ فائل واپس بدل دیں، یا ایک بار کے اضافے کو قبول کر لیں |
| ہر پیغام پچھلے سے زیادہ مہنگا ہے | گفتگو بڑھتی جا رہی ہے۔ اے آئی پرانی فائلیں صاف کیے بغیر زیادہ سے زیادہ فائلیں پڑھ رہا ہے | گفتگو سکڑانے کے لیے /compact استعمال کریں۔ اسے بتائیں کہ کیا رکھنا ہے: /compact keep the file names and decisions |
| اے آئی نہایت لمبے جواب لکھ رہا ہے | آپ نے ایک سادہ سوال پوچھا مگر اے آئی حد سے زیادہ وضاحت کر رہا ہے۔ یا اے آئی کا سوچنے کا انداز کام کے لیے بہت بلند مقرر ہے | "صرف کوڈ، کوئی وضاحت نہیں" مانگیں۔ یا سیٹنگز میں استدلال کی محنت کم کریں |
| آپ کا ماہانہ بل توقع سے کہیں زیادہ ہے | آپ ہر کام کے لیے سب سے طاقتور (اور مہنگا) اے آئی ماڈل استعمال کر رہے ہیں، حتیٰ کہ سادہ کاموں کے لیے بھی | مہنگا ماڈل منصوبہ بندی اور مشکل مسائل کے لیے استعمال کریں۔ سادہ کاموں جیسے فارمیٹنگ یا ٹیسٹ چلانے کے لیے سستا ماڈل استعمال کریں (تصور 4) |
ان سب کے پیچھے ایک ہی اصول ہے: مختصر، مرکوز، مستحکم گفتگوئیں لمبی، الجھی ہوئی گفتگوؤں سے کم لاگت لیتی ہیں اور بہتر کام کرتی ہیں۔
Part 3: قواعد کی فائل
8. CLAUDE.md / AGENTS.md، اچھے طریقے سے
دونوں ٹولز آپ کو ایک خاص فائل بنانے دیتے ہیں جسے اے آئی ہر گفتگو کے آغاز پر پڑھتا ہے۔ اسے اپنے پروجیکٹ کے لیے مستقل ہدایات کا ایک مجموعہ سمجھیں۔ ہر بار جب آپ کوئی نیا سیشن شروع کرتے ہیں، اے آئی یہ فائل پہلے پڑھتا ہے تاکہ اسے قواعد معلوم ہوں۔
- Claude Code اس فائل کو
CLAUDE.mdکہتا ہے - OpenCode اس فائل کو
AGENTS.mdکہتا ہے
آپ کو یہ فائل خود لکھنے کی ضرورت نہیں۔ کسی بھی ٹول میں /init چلائیں اور اے آئی آپ کے پروجیکٹ فولڈر کو اسکین کر کے فائل آپ کے لیے بنا دے گا۔ اس کے بعد، آپ کا کام ہے ان حصوں کو حذف کرنا جن کی آپ کو ضرورت نہیں۔ اے آئی ایک بہت لمبی فائل بنانے کا رجحان رکھتا ہے۔ اس کا زیادہ تر حصہ غیر ضروری ہوتا ہے۔
(مکمل تفصیلی رہنمائی کے لیے، دیکھیں باب 14 § CLAUDE.md اور AGENTS.md۔ اعلیٰ ٹیم ترتیبوں کے لیے، دیکھیں باب 17 § CLAUDE.md کی ترتیب کا درجہ بندی نظام۔)
اگر آپ کے پاس پہلے سے CLAUDE.md ہے اور آپ OpenCode پر بدلتے ہیں، تو آپ کو اسے دوبارہ لکھنے کی ضرورت نہیں۔ جب کوئی AGENTS.md موجود نہ ہو تو OpenCode خود بخود CLAUDE.md پڑھ لیتا ہے۔ اگر دونوں فائلیں موجود ہوں، تو OpenCode AGENTS.md استعمال کرتا ہے اور CLAUDE.md کو نظر انداز کر دیتا ہے۔
سب سے بڑی غلطی جو لوگ کرتے ہیں: وہ اس فائل کو ایک مکمل دستی کی طرح سمجھتے ہیں، اس میں پروجیکٹ کے بارے میں سب کچھ ڈال دیتے ہیں: آرکیٹیکچر، کوڈنگ کے قواعد، نام رکھنے کے ضابطے، ٹیم کی ترجیحات۔ مسئلہ؟ اے آئی یہ فائل ہر ایک پیغام پر پڑھتا ہے۔ ایک بہت بڑی قواعد کی فائل اے آئی کو سست کر دیتی ہے اور آپ کی گفتگو کی جگہ استعمال کر لیتی ہے، حتیٰ کہ تب بھی جب زیادہ تر معلومات موجودہ کام سے غیر متعلق ہوں۔
اسے مختصر رکھیں۔ صرف وہی لکھیں جو اے آئی آپ کی فائلیں دیکھ کر خود نہیں سمجھ سکتا۔ اسے ایک فہرستِ مضامین سمجھیں، نہ کہ ایک انسائیکلوپیڈیا۔ تفصیلات کے لیے دوسری فائلوں کی طرف اشارہ کریں، اور اے آئی کو وہ صرف تب لوڈ کرنے دیں جب اسے ضرورت ہو:
CLAUDE.md۔ @filename کا نحو حوالہ دی گئی فائلوں کو متعلقہ ہونے پر خود بخود لوڈ کرتا ہے:
# Project: my-app
## Stack
Next.js 14, TypeScript, Postgres, Drizzle ORM.
## Commands
- `npm run dev`: start local server
- `npm test`: run vitest
- `npm run db:migrate`: apply migrations
## Critical rules
- Never edit files in `src/generated/`. They're rebuilt by codegen.
- All API routes use the auth middleware in `src/lib/auth.ts`.
- See @docs/conventions.md for naming and folder rules.
- See @docs/db-schema.md for table structure.
AGENTS.md۔ وہی ساخت۔ ایک فرق: Claude Code میں، @docs/conventions.md لکھنے سے وہ فائل ضرورت پر خود بخود لوڈ ہو جاتی ہے۔ OpenCode میں، یہ خود بخود کام نہیں کرتا۔ آپ کے پاس دو اختیار ہیں: یا تو اپنی AGENTS.md میں لکھیں "load docs/conventions.md when relevant،" یا فائلیں opencode.json میں درج کریں:
# Project: my-app
## Stack
Next.js 14, TypeScript, Postgres, Drizzle ORM.
## Commands
- `npm run dev`: start local server
- `npm test`: run vitest
- `npm run db:migrate`: apply migrations
## Critical rules
- Never edit files in `src/generated/`. They're rebuilt by codegen.
- All API routes use the auth middleware in `src/lib/auth.ts`.
## External references
When you encounter @docs/conventions.md or @docs/db-schema.md, load them
on a need-to-know basis with the read tool. Do not preemptively load all
references; only load what's relevant to the current task.
یا، زیادہ صاف طریقہ، انہیں opencode.json میں درج کریں:
{
"$schema": "https://opencode.ai/config.json",
"instructions": ["docs/conventions.md", "docs/db-schema.md"]
}
یہ صرف کوڈ پروجیکٹس کے لیے نہیں۔ آپ یہی قواعد کی فائل کسی بھی قسم کے کام کے لیے استعمال کر سکتے ہیں: مضامین لکھنا، تحقیق منظم کرنا، بلاگ سنبھالنا، تقریبات کی منصوبہ بندی۔ یہ ایک تحریری پروجیکٹ کی مثال ہے:
# Project: blog-and-newsletter
## What this is
A folder of drafts, research, and published posts. I write a weekly newsletter and occasional long-form posts.
## Where things live
- `drafts/`: in-progress posts, one per file
- `research/`: source notes and clippings, organized by topic
- `published/`: shipped posts (do not edit)
## Critical rules
- Never edit anything in `published/`. Fixes go in a new draft with a correction note.
- Footnotes go in `[brackets]` inline; we resolve them to numbered footnotes only at publish time.
- Tone: conversational, no bullet lists in body copy.
اوپر دی گئی کوڈ مثال جیسا ہی خیال: اسے مختصر رکھیں، اور صرف وہی شامل کریں جو اے آئی خود نہیں سمجھ سکتا۔
ہر سطر کے لیے ایک سادہ آزمائش جو آپ شامل کرتے ہیں: اپنے آپ سے پوچھیں، "اگر میں یہ سطر ہٹا دوں، تو کیا اے آئی غلطی کرے گا؟" اگر جواب نہیں ہے، تو اسے حذف کر دیں۔ مثلاً، آپ کو اے آئی کو یہ بتانے کی ضرورت نہیں کہ آپ کا پروجیکٹ Python استعمال کرتا ہے اگر ساری فائلیں .py پر ختم ہوتی ہیں۔ اے آئی یہ دیکھ سکتا ہے۔ مگر آپ کو اے آئی کو یہ ضرور بتانا ہے کہ "published/ فولڈر میں کبھی فائلیں نہ بدلو،" کیونکہ اے آئی کے پاس صرف دیکھ کر یہ جاننے کا کوئی طریقہ نہیں۔
قواعد تب شامل کریں جب کچھ غلط ہو، اس سے پہلے نہیں۔ اگر اے آئی کوئی ایسی غلطی کرے جسے آپ کی قواعد کی فائل روک سکتی تھی، تو وہ اصول شامل کریں۔ پہلے سے ہر ممکن غلطی کا اندازہ لگانے کی کوشش نہ کریں۔ وقت کے ساتھ، آپ کی قواعد کی فائل قدرتی طور پر کسی کارآمد چیز میں بڑھ جائے گی۔
Part 4: اپنے ٹول کو ذاتی بنانا
دونوں ٹولز آپ کو چند قسم کی اپنی مرضی کی خصوصیتیں شامل کرنے دیتے ہیں۔ ہر ایک ایک مختلف مسئلہ حل کرتی ہے:
| قسم | یہ کیا کرتی ہے | کب استعمال کریں |
|---|---|---|
| Command / Skill | ایک فائل میں محفوظ، دوبارہ قابل استعمال پرامپٹ۔ آپ اسے /name ٹائپ کر کے بلاتے ہیں، یا ماڈل اسے خود بخود بلا لیتا ہے جب کام اس کی تفصیل سے ملتا ہو۔ | آپ خود کو ایک ہی ہدایات بار بار ٹائپ کرتے پاتے ہیں، یا آپ چاہتے ہیں کہ ماڈل صحیح ہدایات لاگو کرے بغیر آپ کے یاد دلانے کے۔ |
| Hook / Plugin | ایک اصول جو ہر بار خود بخود چلتا ہے، چاہے کچھ بھی ہو | کوئی چیز ہمیشہ ہونی چاہیے (جیسے "یہ فولڈر کبھی حذف نہ کرو") |
| Subagent | ایک الگ اے آئی مددگار جو اپنے طور پر کام کرتا ہے اور صرف جواب واپس بھیجتا ہے | آپ کو اے آئی سے کوئی بڑی تلاش یا تحقیق کا کام کروانا ہو بغیر اپنی اصل گفتگو کو بھرے |
یہ سب آپ کی گفتگوؤں کو صاف اور آپ کے اے آئی کو مرکوز رکھنے کے طریقے ہیں۔ اگلے حصے ہر ایک کی وضاحت کرتے ہیں۔
9. کمانڈز اور skills
یہ ایک ہی خیال کے دو نام ہیں: ایک محفوظ، دوبارہ قابل استعمال ہدایت جو کسی فائل میں رہتی ہے تاکہ آپ اسے دوبارہ ٹائپ نہ کریں۔ صرف ایک چیز بدلتی ہے: اسے کیسے بلایا جاتا ہے۔
- آپ اسے بلاتے ہیں۔
/reviewٹائپ کریں اور یہ چل جاتا ہے ، آپ طے کرتے ہیں کب۔ - ماڈل اسے بلاتا ہے۔ فائل کو ایک
descriptionدیں، اور ماڈل اسے خود چلا لیتا ہے جب آپ کا کام ملتا ہو، تاکہ آپ کو یاد رکھنے کی ضرورت نہ ہو کہ یہ موجود ہے۔
اس طرح کی فائل معاون مواد بھی اپنے ساتھ لے جا سکتی ہے ، سانچوں، انداز کی رہنماؤں، یا حوالہ دستاویزات کا ایک فولڈر جو صرف تب لوڈ ہوتا ہے جب پرامپٹ واقعی چلے ، اور چند سطریں frontmatter جو اس کا نام، یہ کب فعال ہوتا ہے، اور کون سے tools استعمال کر سکتا ہے، یہ مقرر کرتی ہیں۔
"اگر ماڈل یہ پہلے ہی جانتا ہے کہ یہ کیسے کرنا ہے، تو ایک skill کیوں لکھیں؟" یہی سوال زیادہ تر لوگوں کو زحمت کرنے سے روک دیتا ہے ، اور اس کا ایک واضح جواب ہے۔ ماڈل تربیت سے بہت بڑی مقدار میں عمومی علم اپنے ساتھ لاتا ہے، مگر عمومی علم میں تین خلا ہیں جنہیں ایک skill بھر دیتی ہے:
- یہ آپ کی مخصوص باتیں نہیں جانتا۔ ماڈل جانتا ہے کہ عام طور پر commit پیغام کیسے کام کرتے ہیں؛ یہ آپ کی ٹیم کا فارمیٹ، آپ کے پروجیکٹ کی خاصیتیں، آپ کے اندرونی ٹول کے درست جھنڈے، یا کوئی بھی چیز نہیں جانتا جو اس کی تربیت کے اختتام کے بعد آئی۔ skill وہ حصہ فراہم کرتی ہے جو کبھی اس کی تربیت میں تھا ہی نہیں۔
- جاننا، اسے ہر بار ایک ہی طرح کرنے جیسا نہیں۔ ماڈل سے "اس ٹرانسکرپٹ کو صاف کرو" پانچ بار کہیں اور آپ کو پانچ تھوڑے مختلف طریقے ملیں گے۔ ایک skill درست مراحل کیل دیتی ہے، تو آپ کو ہر بار ایک ہی طریقہ کار ملتا ہے، نئی اپنی طرف سے بنائی گئی چیز کے بجائے۔
- یہ خود سے صحیح انداز کی طرف نہیں جائے گا۔ تربیتی علم صرف تب سامنے آتا ہے جب آپ کا پرامپٹ اتفاقاً اسے چھیڑے۔ کسی skill کی
descriptionوہی چھیڑ ہے ، یہ صحیح طریقہ کار ماڈل کے سامنے اسی لمحے رکھ دیتی ہے جب کام ملتا ہو، تاکہ آپ کو مانگنا یاد نہ رکھنا پڑے۔
اور یہ سب کچھ آپ کی گفتگو کو پھلائے بغیر کرتی ہے: صرف مختصر تفصیل شروع میں سیاق میں بیٹھتی ہے؛ مکمل ہدایات اور کوئی بھی حوالہ فائلیں صرف تب لوڈ ہوتی ہیں جب skill واقعی چلے ، وہی سیاق کا ضبط جو Part 2 سے ہے۔ ایک سطر میں: ماڈل عمومی علم لاتا ہے؛ skill آپ کی مخصوص باتیں، ایک مستقل انداز، اور صحیح وقت پر صحیح ہدایات لاتی ہے۔ (ایک ذہین نئے ملازم کا سوچیں جو پورا میدان جانتا ہے مگر پھر بھی اسے آپ کی ہینڈ بک، ایک چیک لسٹ، اور صحیح صفحہ صحیح وقت پر تھمائے جانے کی ضرورت ہے۔)
LLMs احتمالی ہیں: ماڈل ہر اگلا لفظ اختیارات کے ایک دائرے سے چنتا ہے، اس لیے ایک ہی پرامپٹ مختلف الفاظ میں واپس آ سکتا ہے، اور ایک ہی skill بھی۔ ایک skill اسے بند نہیں کرتی۔ جو وہ کرتی ہے وہ ممکنہ نتائج کے دائرے کو تنگ کرنا ہے ، یہ "ماڈل نے اس بار ایک مختلف انداز ایجاد کیا" والی قسم کی تبدیلی ہٹا دیتی ہے، لفظ کی سطح والی نہیں۔ آپ پانچ مختلف طریقہ کار سے ایک ہی طریقہ کار، ہر بار تھوڑا مختلف انداز میں پر چلے جاتے ہیں۔ یہ انداز کی مستقل مزاجی ہے، یکساں نتیجہ نہیں۔
جب کسی مرحلے کی ضمانت ہونی چاہیے ، ایک ہی نتیجہ، ہر بار، کوئی استثنا نہیں ، تو ماڈل سے یادداشت سے کرنے کو نہ کہیں۔ اسے کوڈ میں دھکیلیں: skill سے کوئی script، formatter، یا test چلوائیں، یا اسے کسی hook/plugin (اگلا حصہ) سے نافذ کریں، جو عام کوڈ ہے اور اس لیے قطعی ہے۔ عام اصول: skills انداز کو قابلِ اعتماد بناتی ہیں؛ scripts اور hooks نتیجہ کی ضمانت دیتے ہیں۔
Claude Code میں، ایک کمانڈ اور ایک skill ایک ہی چیز ہیں۔ اپنی پرامپٹ فائلیں .claude/skills/ میں رکھیں: ایک فولڈر جس کے اندر ایک SKILL.md ہو۔ فولڈر کا نام کمانڈ کا نام بن جاتا ہے، تو .claude/skills/review/SKILL.md آپ کو /review دیتا ہے۔
سب سے سادہ صورت ، ایک پرامپٹ جو آپ خود بلاتے ہیں۔ کسی description کے بغیر، ماڈل اسے خود نہیں چلائے گا؛ آپ اسے /review سے چھیڑتے ہیں:
Review the current diff for:
1. Bugs and edge cases
2. Test coverage gaps
3. Naming and readability
4. Adherence to @docs/conventions.md
Be specific. Quote the lines you're commenting on.
ایک description شامل کریں اور ماڈل اسے کسی کام کے ملنے پر خود بھی اپنا سکتا ہے:
---
name: extract-transcript
description: Extract a clean transcript from a YouTube video URL. Use when the user provides a YouTube link and asks for the transcript, captions, or text of the video.
---
# Extract YouTube transcript
1. Take the URL from the user's message.
2. Run `yt-dlp --skip-download --write-auto-sub --sub-format vtt "$URL"`.
3. Convert the VTT to plain text: strip timestamps, deduplicate overlapping captions.
4. Save to `transcripts/{video-id}.txt`.
For formatting conventions (paragraph breaks, speaker labels), see `references/style.md`.
وہ references/style.md "زیادہ ساتھ لے جانا" والا حصہ ہے: ماڈل اسے صرف تب پڑھتا ہے جب یہ skill چلے، اس لیے باقی وقت یہ آپ کو کچھ خرچ نہیں کراتی۔ غور کریں سادہ نسبتی راستہ ، کسی skill کے اندر آپ اپنی قواعد کی فائل (Part 3) والا @ خودکار-import نحو نہیں استعمال کرتے۔ @ کسی فائل کو سیاق میں اسی لمحے زبردستی لوڈ کر دیتا ہے جب قواعد کی فائل لوڈ ہو؛ ایک skill کا حوالہ اس وقت تک بے لوڈ رہنے کے لیے ہوتا ہے جب تک ماڈل کو واقعی اس کی ضرورت نہ ہو اور وہ اسے خود پڑھ لے۔ ایک سادہ راستہ (یا ایک نسبتی markdown link جیسے [style](references/style.md)) بالکل وہی ہے جو اس سست لوڈنگ کو کام کرتا رکھتا ہے۔
OpenCode کمانڈز اور skills کو دو الگ چیزیں رکھتا ہے ، اس نے انہیں اس طرح یکجا نہیں کیا جیسے Claude Code نے کیا ہے:
- ایک skill ہدایات کا ایک
SKILL.mdفولڈر ہے جسے ایجنٹ کسی کام کے اس کی تفصیل سے ملنے پر خود لوڈ کرتا ہے۔ فارمیٹ Claude Code جیسا ہی ہے، اور OpenCode.opencode/skills/،~/.config/opencode/skills/، اور Claude Code کے.claude/skills/میں دیکھتا ہے ، تو کسی بھی ٹول کے لیے لکھی گئی skill دونوں میں، بغیر تبدیلی کے، کام کرتی ہے۔ - ایک کمانڈ ایک محفوظ پرامپٹ ہے جسے آپ
/nameٹائپ کر کے خود چھیڑتے ہیں، جو.opencode/commands/(پروجیکٹ) یا~/.config/opencode/commands/(ذاتی) میں ایک markdown فائل کے طور پر محفوظ ہوتا ہے۔
OpenCode ہر skill کو slash مینو میں ایک قابلِ بلاوا کمانڈ کے طور پر بھی درج کرتا ہے (:skill لاحقے کے ساتھ دکھایا گیا)، تو آپ کسی skill کو دستی طور پر بھی چلا سکتے ہیں ، مگر دونوں نیچے سے الگ رہتے ہیں: ایک کمانڈ ایک پرامپٹ ہے جو آپ بھیجتے ہیں، ایک skill وہ علم ہے جسے ایجنٹ متعلقہ ہونے پر اندر لاتا ہے۔
ایک پرامپٹ جو آپ خود بلاتے ہیں ، .opencode/commands/review.md (frontmatter اختیاری ہے؛ یہ description، agent، model، اور subtask کی سہولت دیتا ہے):
---
description: Review the current diff
agent: plan
subtask: true
---
Review the current diff for:
1. Bugs and edge cases
2. Test coverage gaps
3. Naming and readability
4. Adherence to docs/conventions.md
Be specific. Quote the lines you're commenting on.
ایک skill جسے ایجنٹ خود بلا سکتا ہے ، .opencode/skills/extract-transcript/SKILL.md (اوپر دی گئی Claude Code skill جیسی ہی؛ یہ slash مینو میں /extract-transcript:skill کے طور پر بھی ظاہر ہوتی ہے):
---
name: extract-transcript
description: Extract a clean transcript from a YouTube video URL. Use when the user provides a YouTube link and asks for the transcript, captions, or text of the video.
---
# Extract YouTube transcript
1. Take the URL from the user's message.
2. Run `yt-dlp --skip-download --write-auto-sub --sub-format vtt "$URL"`.
3. Convert the VTT to plain text: strip timestamps, deduplicate overlapping captions.
4. Save to `transcripts/{video-id}.txt`.
For formatting conventions (paragraph breaks, speaker labels), see `references/style.md`.
ایک کمانڈ یا skill جو آپ کسی موجودہ فولڈر (.claude/skills/، ~/.claude/skills/، یا OpenCode کے متبادلات) کے اندر شامل یا بدلتے ہیں وہ فوراً اثر کرتی ہے ، کسی ری اسٹارٹ کے بغیر۔ صرف ایک صورت جس میں ابھی بھی ری اسٹارٹ درکار ہے وہ ہے ایک بالکل نئی اعلیٰ-سطح skills ڈائریکٹری بنانا جو سیشن شروع ہونے پر موجود نہ تھی، کیونکہ ٹول صرف وہی فولڈر دیکھ سکتا ہے جنہیں وہ آغاز پر جانتا تھا۔
اسے ہر بار ٹائپ کرنے کے بجائے محفوظ کیوں کریں۔ ایک کمزور review پرامپٹ ، "میرے کام کا جائزہ لو" ، تقریباً ہمیشہ ایک خوش گوار "بہت اچھا لگ رہا ہے!" ملتا ہے، کیونکہ ماڈل آپ سے اتفاق کرنے کا رجحان رکھتا ہے (خوشامد، AI Prompting کورس سے)۔ جو کام کرتا ہے وہ ایک چیک لسٹ ہے جو اسے مخصوص چیزیں ایک ایک کر کے جانچنے پر مجبور کرتی ہے، تاکہ وہ "اچھا لگ رہا ہے" کے پیچھے چھپ نہ سکے۔ مگر چیک لسٹ دوبارہ ٹائپ کرنا تھکا دینے والا ہے ، تو کسی مصروف دن آپ نہیں کریں گے، اور آپ بالکل اسی وقت سست نسخے پر واپس آ جائیں گے جب آپ کو سختی کی سب سے زیادہ ضرورت ہے۔ اسے /review کے طور پر محفوظ کرنا وہ رکاوٹ ہٹا دیتا ہے: آپ سخت پرامپٹ ایک بار لکھتے ہیں، اور اس کے بعد سے ایک کلید پر ہر بار پوری چیک لسٹ چل جاتی ہے۔ یہی محفوظ کرنے کا اصل فائدہ ہے ، کوئی بہتر پرامپٹ نہیں (وہ آپ ہاتھ سے بھی ٹائپ کر سکتے تھے)، بلکہ ایک بہتر پرامپٹ جو محنت طلب چیز کے بجائے بے محنت ڈیفالٹ بن جاتا ہے۔
یہ غیر-کوڈنگ کاموں کے لیے بھی کام کرتا ہے۔ ایک /standup جو آپ کے نوٹس سے ایک روزانہ خلاصہ لکھتا ہے ، اسے ایک skill (Claude Code) یا ایک کمانڈ (OpenCode) کے طور پر اس متن کے ساتھ محفوظ کریں:
Read yesterday's note in `journal/`. Produce a 4-line standup:
1. What I shipped yesterday (1 line)
2. What I'm working on today (1 line)
3. Blockers (1 line, "none" if clear)
4. One thing I learned (1 line)
Tone: telegraphic. No filler.
/review جیسی ہی شکل، مختلف میدان۔ وہی چال /digest (ای میلوں کے ایک فولڈر کو کام والی اشیا میں بدلنا)، /draft-reply (اس راستے پر موجود ای میل کا ایک مہذب جواب لکھنا)، یا کسی بھی کام کے لیے کام کرتی ہے جو آپ بار بار ٹائپ کرتے ہیں۔ آزمائش: اگر آپ ایک ہی ہدایات دو بار سے زیادہ ٹائپ کریں، تو انہیں محفوظ کریں۔ خود چلانا چاہتے ہیں؟ اسے /name سے بلائیں۔ چاہتے ہیں کہ ماڈل اسے خود اپنائے؟ اسے ایک description دیں۔
چند اصول جو انہیں قابلِ اعتماد بناتے ہیں:
- تفصیل سب سے اہم سطر ہے۔ ماڈل اسے یہ طے کرنے کے لیے پڑھتا ہے کہ skill چلائے یا نہیں۔ مبہم ("ویڈیوز میں مدد کرتی ہے") بہت زیادہ فعال ہوتی ہے؛ مخصوص ("Use when the user provides a YouTube link and asks for the transcript") صرف تب فعال ہوتی ہے جب ہونی چاہیے۔
SKILL.mdکو مختصر رکھیں۔ اصل ہدایاتSKILL.mdمیں رکھیں اور اضافی تفصیل (انداز کی رہنمائیں، سانچے، حوالہ مواد) اسی فولڈر میں الگ فائلوں میں منتقل کریں۔ یہ صرف ضرورت پر لوڈ ہوتی ہیں۔- چھوٹی skills بنائیں، بڑی نہیں۔ تحقیق، مسودہ، فارمیٹ، اور جائزہ لینے کے لیے، ایک دیو ہیکل skill نہ بنائیں ، چار بنائیں (
research،draft،format،review) جو ہر ایک ایک کام کرے اور فائلوں کے ذریعے آگے پہنچائے۔ ہر ایک کو صرف اپنے مرحلے کا سیاق درکار ہوتا ہے، جو گفتگو کو صاف رکھتا ہے۔
آپ کو انہیں نئے سرے سے لکھنے کی ضرورت نہیں۔ Claude Code ایک skill جنریٹر کے ساتھ آتا ہے جو نئی skills قدم بہ قدم بناتا ہے؛ OpenCode کا ایک ملتا جلتا ایجنٹ بنانے کا طریقہ ہے۔ (درست کمانڈ کے لیے اپنے ٹول کے موجودہ docs دیکھیں ، ان کا نام اکثر بدلتا ہے۔) گہرائی والا نسخہ (فولڈر کی ساخت، frontmatter، دلیل پاس کرنا، کئی مرحلوں والی skill کی ساخت بنانا) باب 14 § Claude کو اپنا انداز سکھائیں اور باب 14 § اپنی skills بنانا میں ہے۔
10. Hooks (Claude Code) / Plugins (OpenCode)
کمانڈز اور skills کا انحصار اس پر ہے کہ ماڈل انہیں استعمال کرنے کا فیصلہ کرے۔ مگر کبھی کبھی آپ کو ایک ایسا اصول درکار ہوتا ہے جو ہر ایک بار، چاہے کچھ بھی ہو، ماڈل کے اسے یاد رکھنے پر انحصار کیے بغیر چلے۔ hooks (Claude Code میں) اور plugins (OpenCode میں) اسی کے لیے ہیں۔
مثلاً: "اے آئی کو کبھی ایسی کمانڈ نہ چلانے دو جو ساری فائلیں حذف کر دے۔" آپ نہیں چاہتے کہ اے آئی فیصلہ کرے کہ اس اصول کی پیروی کرے یا نہیں۔ آپ چاہتے ہیں کہ یہ خود بخود نافذ ہو، ہر بار، کوئی استثنا نہیں۔
دونوں ٹولز اس کی سہولت دیتے ہیں، مگر اسے ترتیب دینے کا طریقہ ہر ایک میں مختلف ہے۔ یہی وہ حصہ ہے جہاں دونوں ٹولز سب سے زیادہ مختلف ہیں۔
Claude Code ان خودکار اصولوں کے لیے لفظ "hook" استعمال کرتا ہے۔ OpenCode لفظ "plugin" استعمال کرتا ہے۔ یہ ایک ہی کام کرتے ہیں، بس مختلف ناموں سے۔ (Claude Code میں "plugins" نام کی ایک الگ خصوصیت بھی ہے جس کا مطلب بالکل کچھ اور ہے۔ ابھی اسے نظر انداز کریں۔)
Hooks خودکار اصول ہیں جنہیں آپ .claude/settings.json میں شامل کرتے ہیں۔ یہ مخصوص لمحوں پر چلتے ہیں: جب کوئی سیشن شروع ہو، جب آپ کوئی پیغام بھیجیں، یا عین اس سے پہلے کہ اے آئی کوئی کمانڈ چلائے ، یہ تینوں محض مثالیں ہیں؛ Claude Code تقریباً 30 lifecycle واقعات پر hooks چلا سکتا ہے، سیشن کے آغاز اور پرامپٹ جمع کرانے سے لے کر pre/post tool use، compaction، اور سیشن کے اختتام تک۔ ایک hook کے دو حصے ہوتے ہیں: ایک matcher جو چنتا ہے کہ کون سا tool دیکھنا ہے (نام کے حساب سے، جیسے "Bash" یا "Edit|Write")، اور ایک command (ایک shell کمانڈ یا script) جو طے کرتا ہے کہ کام کی اجازت دینی ہے یا نہیں۔ اگر وہ کمانڈ code 2 کے ساتھ ختم ہو، تو اے آئی کو وہ کام کرنے سے روک دیا جاتا ہے۔
یہ ایک مثال ہے جو اے آئی کو rm -rf (ایک خطرناک کمانڈ جو سب کچھ حذف کر دیتی ہے) چلانے سے کبھی روکتی ہے:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "jq -r '.tool_input.command' | grep -q 'rm -rf' && { echo 'Blocked dangerous command' >&2; exit 2; } || exit 0"
}
]
}
]
}
}
یہ کیسے کام کرتا ہے: matcher ("Bash") کا مطلب ہے کہ یہ hook صرف Bash کمانڈز سے پہلے چلتا ہے۔ جب اے آئی کوئی چلانے والا ہو، Claude Code کمانڈ کی تفصیلات آپ کے script کو JSON کے طور پر standard input پر دیتا ہے۔ script jq سے اصل کمانڈ متن نکالتا ہے، اسے grep سے rm -rf کے لیے جانچتا ہے، اور ، اگر ملے ، تو stderr پر ایک پیغام چھاپتا ہے اور code 2 کے ساتھ ختم ہو جاتا ہے۔ Exit code 2 وہ مخصوص سگنل ہے جو Claude Code کو بتاتا ہے "اس کام کو روکو"؛ کوئی بھی دوسرا exit code اسے گزرنے دیتا ہے، اسی لیے محفوظ صورت exit 0 پر ختم ہوتی ہے۔ کلیدی خیال: matcher tool چنتا ہے، script طے کرتا ہے کہ روکنا ہے یا نہیں۔ ابھی کے لیے بس اتنا ہی جاننا کافی ہے۔ نیچے Part 6 میں ایک زیادہ تفصیلی مثال ہے۔
دو چھوٹی چیزیں جو hooks کے ساتھ گزارہ آسان بناتی ہیں۔ پہلی، Claude Code کے حالیہ نسخے ایک if فیلڈ شامل کرتے ہیں جو ایک hook کو tool اور دلائل کے حساب سے پہلے سے چھانتا ہے، اجازت کے قواعد جیسے نحو کا استعمال کرتے ہوئے ، تو "if": "Bash(rm -rf *)" hook کو صرف ملتی ہوئی کمانڈز پر چلاتا ہے، اور آپ script کے اندر والا grep چھوڑ سکتے ہیں۔ (پرانے نسخے if کو نظر انداز کر کے hook ہر بار چلاتے ہیں، اسی لیے اوپر والا grep نسخہ ہر جگہ کام کرتا ہے۔) دوسری، hooks ~/.claude/settings.json میں رہ سکتے ہیں تاکہ آپ کے سب پروجیکٹس پر لاگو ہوں، نہ کہ صرف ایک کے لیے .claude/settings.json میں؛ اگر کوئی hook نہ چل رہا ہو تو /hooks ٹائپ کر کے تصدیق کریں کہ وہ رجسٹرڈ ہے۔
Plugins چھوٹی JavaScript (یا TypeScript) فائلیں ہیں جنہیں آپ اپنے OpenCode plugins فولڈر میں رکھتے ہیں ، ایک پروجیکٹ کے لیے .opencode/plugins/، یا ہر جگہ لاگو کرنے کے لیے ~/.config/opencode/plugins/۔ یہ وہی کام کرتی ہیں جو Claude Code hooks کرتے ہیں (کاموں کو خود بخود روکنا یا بدلنا)، مگر آپ انہیں JSON کے بجائے کوڈ میں لکھتے ہیں۔ یہ وہی "block rm -rf" مثال ہے:
// .opencode/plugins/block-dangerous.js
export const BlockDangerousPlugin = async () => {
return {
"tool.execute.before": async (input, output) => {
if (input.tool === "bash" && output.args.command?.includes("rm -rf")) {
throw new Error("Blocked dangerous command");
}
},
};
};
OpenCode plugins صرف کام روکنے سے زیادہ کر سکتے ہیں۔ یہ کئی مختلف واقعات پر ردِعمل دے سکتے ہیں: جب کوئی سیشن شروع ہو، جب اے آئی کام مکمل کرے، جب کوئی فائل بدلے، اور مزید۔ یہ آپ کو اطلاعات بھی بھیج سکتے ہیں، اپنی مرضی کے tools شامل کر سکتے ہیں، اور یہ نئی شکل دے سکتے ہیں کہ compact ہونے پر گفتگو کا خلاصہ کیسے بنے۔ آپ کو یہ سب فوراً سیکھنے کی ضرورت نہیں۔ بس یہ جان لیں کہ plugins زیادہ طاقتور اختیار ہیں اگر آپ کو بعد میں ضرورت ہو۔
غور کریں فولڈر جمع کا ہے ،
plugins/، نہ کہplugin/۔ ایک plugin جو خاموشی سے کبھی نہیں چلتا اکثر غلط ڈائریکٹری میں ہوتا ہے؛ لوڈر صرف.opencode/plugins/(پروجیکٹ) اور~/.config/opencode/plugins/(عالمی) دیکھتا ہے۔ OpenCode تیزی سے بدلتا ہے، اس لیے اگر کوئی چیز غیر متوقع طور پر برتاؤ کرے تو موجودہ docs پر ایک نظر ڈالیں۔
ایک عملی مثال: فرض کریں آپ کبھی کبھی اپنے مسودوں میں [TODO] نشان چھوڑ دیتے ہیں اور شائع کرنے سے پہلے انہیں ہٹانا بھول جاتے ہیں۔ آپ ایک hook (Claude Code) یا plugin (OpenCode) ترتیب دے سکتے ہیں جو اے آئی کو کسی بھی فائل کو published/ فولڈر میں محفوظ کرنے سے خود بخود روک دے اگر اس میں ابھی بھی کوئی [TODO] نشان ہو۔ آپ کو کبھی جانچنا یاد نہیں رکھنا پڑتا؛ ٹول یہ آپ کے لیے کر دیتا ہے۔
آپ کو کون سا استعمال کرنا چاہیے؟
| Claude Code hooks | OpenCode plugins | |
|---|---|---|
| آپ انہیں کیسے لکھتے ہیں | کسی سیٹنگ فائل میں چند سطر JSON، جو کسی shell کمانڈ یا script کی طرف اشارہ کرے | ایک چھوٹی JavaScript فائل |
| کس کے لیے آسان | سادہ قواعد جیسے "اس کمانڈ کو روکو" | پیچیدہ قواعد جنہیں کئی چیزیں جانچنی ہوں |
| آپ کو کیا جاننا ہے | بنیادی ٹرمینل کمانڈز (اور مواد جانچنے کے لیے تھوڑا jq/grep) | بنیادی JavaScript |
ایک اچھی عادت: commit کے وقت جانچیں، ہر تبدیلی پر نہیں۔ ایک hook کو ہر فائل تبدیلی پر چلانا پرکشش لگتا ہے، مگر اے آئی کو کام کے درمیان روکنا اسے الجھا دیتا ہے ، وہ ایک سوچ کے بیچ میں رک جاتا ہے۔ اس کے بجائے، اسے کام مکمل کرنے دیں، اور اپنی جانچ commit پر رکھیں (وہ لمحہ جب وہ git commit سے ایک چیک پوائنٹ محفوظ کرنے کی کوشش کرے)۔ اس مقام پر، اپنے ٹیسٹ اور formatter چلائیں۔ اگر وہ پاس ہوں، تو commit ہو جاتا ہے۔ اگر ناکام ہوں، تو آپ کا hook commit کو روک دیتا ہے اور خرابی اے آئی کو واپس تھما دیتا ہے ، جو اسے پڑھتا ہے اور دوبارہ کوشش کرنے سے پہلے خود مسئلہ ٹھیک کر لیتا ہے۔ آپ کچھ نہیں کرتے؛ ناکام جانچ ہی ہدایت ہے۔ (Part 6، Step 6 بالکل یہی عمل میں دکھاتا ہے۔)
hooks/plugins ان چیزوں کے لیے استعمال کریں جنہیں آپ 100 فیصد وقت سچ رکھنا چاہتے ہیں۔ skills ان چیزوں کے لیے استعمال کریں جنہیں آپ چاہتے ہیں کہ ماڈل زیادہ تر وقت یاد رکھے۔
11. Subagents
ایک subagent ایک الگ تھلگ ایجنٹ نمونہ ہے اپنی سیاق کی کھڑکی کے ساتھ۔ آپ اسے ایک کام سونپتے ہیں؛ یہ نجی طور پر کام کرتا ہے؛ یہ ایک خلاصہ واپس کرتا ہے۔ اس کی فائل تلاشیں، log کے ڈھیر، اور کھوجی پڑھائیاں کبھی آپ کے اصل دھاگے کو چھوتی ہی نہیں۔
یہ سیاق کے انتظام کی اصطلاحات میں کیوں اہم ہے: سب سے زیادہ سیاق-زہریلی چیز جو آپ کر سکتے ہیں وہ ہے "کوڈ بیس میں کھوج کر یہ ڈھونڈنا کہ X کہاں ہوتا ہے۔" اس طرح کا کام درجنوں فائلیں سیاق میں کھینچ لیتا ہے، جن میں سے زیادہ تر کی آپ کو ضرورت نہیں۔ اسے کسی subagent میں کرنے کا مطلب ہے کہ آپ کا اصل سیشن صرف نتیجہ دیکھتا ہے ("X یہاں ہوتا ہے src/services/billing.ts:142")، تلاش نہیں۔
دو قسمیں ہیں، اور انہیں الگ رکھنا فائدہ مند ہے: وہ subagents جن کے ساتھ آپ کا ٹول آتا ہے (آپ یہ نہیں لکھتے ، یہ بس موجود ہیں اور خود بخود چل جاتے ہیں)، اور وہ اپنی مرضی کے جو آپ خود لکھتے ہیں۔
بلٹ ان subagents ، یہ آپ کے پاس پہلے سے ہیں۔ کوئی ترتیب نہیں؛ ٹول کسی کام کے ٹھیک بیٹھنے پر ان کی طرف جاتا ہے۔
- Claude Code
Explore(صرف-پڑھنے والی کوڈ بیس تلاش، ایک تیز، سستے ماڈل پر چلتی ہے)،Plan(plan mode کے دوران استعمال ہونے والی صرف-پڑھنے والی تحقیق)، اور کئی مرحلوں والے کام کے لیے ایک عام مقصد ایجنٹ بھی لاتا ہے جسے تبدیلیاں بھی کرنی ہوں۔ - OpenCode
Explore(صرف-پڑھنے والی تلاش)،General(وسیع تر سونپا گیا کام)، اورScout(صرف-پڑھنے والی بیرونی-docs اور انحصار کی تحقیق) لاتا ہے۔
Claude Code میں، plan mode خود بخود اپنی کوڈ بیس تحقیق ایک صرف-پڑھنے والے subagent کو سونپ دیتا ہے، تو آپ زیادہ تر انہیں بغیر سوچے استعمال کریں گے ، ماڈل پوچھے جانے پر خود بھی plan mode میں جا سکتا ہے۔ OpenCode میں، Plan ایجنٹ (ایک بنیادی ایجنٹ جس پر آپ Tab سے بدلتے ہیں) اسی طرح subagents کو خود بخود بلاتا ہے، یا آپ کسی کو @explore سے واضح طور پر بلا سکتے ہیں۔
اپنی مرضی کے subagents ، یہ آپ لکھتے ہیں جب آپ بار بار ایک ہی قسم کا کارکن ایک ہی ہدایات کے ساتھ پیدا کرتے رہیں۔ ایک اپنی مرضی کا subagent ایک markdown فائل ہے تھوڑے frontmatter (اس کا نام، کب استعمال کرنا ہے، کون سے tools چھو سکتا ہے) اور ایک سسٹم پرامپٹ کے ساتھ۔ (خبردار: OpenCode کا بلٹ ان Scout پہلے ہی بیرونی-docs تحقیق کرتا ہے، تو نیچے والا doc-fetcher وہاں بنانے کی ضرورت سے زیادہ ایک سکھانے کی مثال ہے۔)
.claude/agents/doc-fetcher.md:
---
name: doc-fetcher
description: Fetches and summarizes external library documentation. Use when the user references a library and we need to understand its current API.
tools: WebFetch, Read, Write
---
You are a documentation researcher. Given a library name and a topic, fetch the official docs, extract only the API surface relevant to the topic, and write a focused summary to `tmp/docs-{library}.md`. Don't paste full pages: extract the patterns and signatures we need.
.opencode/agents/doc-fetcher.md:
---
description: Fetches and summarizes external library documentation. Use when the user references a library and we need to understand its current API.
mode: subagent
permission:
edit: ask
bash: deny
webfetch: allow
---
You are a documentation researcher. Given a library name and a topic, fetch the official docs, extract only the API surface relevant to the topic, and write a focused summary to `tmp/docs-{library}.md`. Don't paste full pages: extract the patterns and signatures we need.
انہیں کہاں رکھیں، اور ایک بنانے کا آسان طریقہ۔ فائل اپنے پروجیکٹ فولڈر میں محفوظ کریں تاکہ پوری ٹیم کو مل جائے، یا اپنے ذاتی فولڈر میں تاکہ ہر پروجیکٹ میں استعمال کریں:
- Claude Code:
.claude/agents/(پروجیکٹ) یا~/.claude/agents/(ذاتی)۔ فائل ہاتھ سے لکھنے کے بجائے، ایک رہنمائی والے پرامپٹ کے ذریعے ایک بنانے کے لیے/agentsچلائیں۔ ایک پیچ: ڈسک پر آپ کی شامل یا بدلی گئی فائل صرف اگلے سیشن کے آغاز پر لوڈ ہوتی ہے، جبکہ/agentsکے ذریعے بنائے گئے ایجنٹس فوراً کام کرتے ہیں۔ - OpenCode:
.opencode/agents/(پروجیکٹ) یا~/.config/opencode/agents/(ذاتی) ، فائل کا نام ایجنٹ کا نام بن جاتا ہے۔ یا ایک سہاروں والا بنانے کے لیےopencode agent createچلائیں۔ (اگر آپ الگ فائل کے بجائے config ترجیح دیں تو آپ ایجنٹس کوopencode.jsonمیں inline بھی بیان کر سکتے ہیں۔)
دو چیزیں جاننے کے قابل۔ آپ کسی subagent کو اس کا اپنا سستا، تیز ماڈل دے سکتے ہیں ، وہی ماڈل-ملانے کا خیال جو تصور 4 سے ہے، اور وہی وجہ کہ Claude Code کا Explore ڈیفالٹ کے طور پر ایک تیز کفایتی ماڈل پر چلتا ہے۔ اور Claude Code میں ایک subagent مزید subagents پیدا نہیں کر سکتا (کوئی لامحدود گھونسلا نہیں)؛ کئی مرحلوں والی سونپ کے لیے، انہیں اپنے اصل سیشن سے زنجیر کریں یا متحرک ورک فلوز (نیچے) کی طرف جائیں۔
اپنی مرضی کے subagents غیر-کوڈنگ کاموں کے لیے بھی کام کرتے ہیں۔ مثلاً، تصور کریں آپ کے پاس ایک لمبی PDF ہے (کتاب کا باب، تحقیقی مقالہ، یا معاہدہ) اور آپ ایک خلاصہ چاہتے ہیں۔ پوری دستاویز اپنی گفتگو میں پیسٹ کرنے کے بجائے (جو آپ کی چیٹ تیزی سے بھر دے گی)، آپ ایک subagent بھیج سکتے ہیں کہ اسے پڑھے اور صرف خلاصہ واپس لائے:
---
name: pdf-summarizer
description: Reads a long PDF and writes a focused summary. Use when the user references a PDF and wants the key points without dumping the whole document into the conversation.
tools: Read, Write
---
You are a research summarizer. Given a PDF path and a question, read the document, extract only the passages relevant to the question, and write a focused summary to `tmp/summary-{pdf-name}.md`. Do not paste full pages: pull out the patterns, claims, and quotes the user actually needs.
subagent پوری PDF خود پڑھتا ہے۔ آپ کی اصل گفتگو وہ 200 صفحے کبھی نہیں دیکھتی۔ اسے صرف آخر میں مختصر خلاصہ ملتا ہے۔ یہی پورا مقصد ہے: بھاری پڑھائی الگ رکھیں تاکہ آپ کی اصل گفتگو صاف رہے۔
subagents استعمال کیسے ہوتے ہیں؟ دو طریقے، بلٹ ان اور اپنی مرضی کے دونوں کے لیے ایک جیسے، دونوں ٹولز میں:
- خود بخود۔ اگر آپ نے اپنے subagent کے لیے ایک اچھی تفصیل لکھی، تو اے آئی اسے کسی کام کے ملنے پر خود استعمال کرے گا۔ آپ subagents کو زیادہ تر اسی طرح استعمال کریں گے۔
- دستی طور پر۔ اپنے پیغام میں
@subagent-nameٹائپ کر کے اے آئی کو بالکل بتائیں کہ کون سا subagent استعمال کرنا ہے۔ یہ تب کریں جب آپ یقینی بنانا چاہتے ہوں کہ کوئی مخصوص چلے۔
سادہ اصول: اگر کسی کام کے لیے بہت زیادہ معلومات پڑھنا درکار ہو جس کی آپ کی اصل گفتگو کو ضرورت نہیں، تو ایک subagent بھیجیں کہ یہ کرے۔ (باب 14 § Subagents اور Orchestration میں پوری رہنمائی ہے۔)
Skill یا subagent؟ انہیں آپس میں الجھانا آسان ہے۔ دونوں دوبارہ قابل استعمال ہیں، دونوں کسی description سے خود بخود چل سکتے ہیں، اور دونوں Part 4 میں سامنے آئے۔ فرق اس پر آ کر رُکتا ہے کہ کام کہاں چلتا ہے:
| Skill (تصور 9) | Subagent | |
|---|---|---|
| کہاں چلتا ہے | آپ کی موجودہ گفتگو ، وہی کھڑکی، وہی ماڈل، وہی tools | اپنی الگ تھلگ کھڑکی |
| یہ کیا ہے | ایک طریقہ کار یا مہارت جس کی آپ کا ایجنٹ پیروی کرتا ہے | ایک الگ کارکن جو آپ کے لیے کام کا ایک حصہ کرتا ہے |
| کیا واپس آتا ہے | نتیجہ گفتگو کے حصے کے طور پر، جاری چیٹ کا حصہ | صرف ایک خلاصہ؛ لمبا درمیانی حصہ (تلاشیں، فائل کے ڈھیر، بند راستے) کبھی آپ کے سیاق میں نہیں آتا |
| ماڈل اور tools | جو سیشن استعمال کر رہا ہے | ایک سستا/تیز ماڈل اور محدود، sandbox شدہ tools چلا سکتا ہے |
| لاگت اور تاخیر | سستا اور فوری ، یہ بس متن لوڈ کرتا ہے | آغاز کا اضافی بوجھ (یہ اندھا شروع ہوتا ہے اور اپنا سیاق خود جمع کرتا ہے)، مگر آپ کی کھڑکی صاف رکھتا ہے |
| کس کے لیے بہترین | ایک مستقل انداز فی الفور لاگو کرنا، آگے پیچھے گنجائش کے ساتھ | زیادہ حجم کا کام (کھوج، لمبی دستاویزات، log کی چھان بین) الگ کرنا یا tools کو sandbox کرنا |
ایک سطر میں: ایک skill بدلتی ہے کہ آپ کا موجودہ ایجنٹ کیسے کام کرتا ہے؛ ایک subagent کام کسی الگ کو سونپ دیتا ہے جو واپس رپورٹ کرتا ہے۔ ایک skill کھیل کا منصوبہ ہے؛ ایک subagent ایک ساتھی ہے جسے آپ سونپتے ہیں۔
اور یہ مقابلے کے بجائے ساتھ کام کرتے ہیں: ایک subagent skills استعمال کر سکتا ہے۔ Claude Code میں آپ یا تو انہیں پہلے سے لوڈ کرتے ہیں ، subagent کے frontmatter میں skills: [api-conventions, error-handling] درج کریں اور وہ مواد پہلی باری سے اس کے سیاق میں ہوتا ہے ، یا اسے runtime پر خود skills کی طرف جانے دیں (اس کے tools سے Skill صرف تب ہٹائیں جب آپ یہ منع کرنا چاہیں)۔ OpenCode بھی ایسا ہی ہے: ایک subagent skills استعمال کرتا ہے جب تک اس کی skill اجازت مسترد نہ کی گئی ہو۔ تو انتخاب کبھی skill یا subagent نہیں ہوتا؛ اکثر یہ ایک subagent ہوتا ہے جو صحیح skill تھامے ہوئے ہے۔
بڑا جانا (صرف Claude Code): بہت بڑے کاموں کے لیے، Claude Code دسیوں سے سینکڑوں subagents متوازی چلا سکتا ہے اور ان کا کام جانچ سکتا ہے ، اسے متحرک ورک فلوز (dynamic workflows) کہتے ہیں۔ یہ صرف Claude Code میں ہے اور کہیں زیادہ ٹوکن استعمال کرتا ہے، اس لیے یہ لاگت-قابلِ-رسائی ڈیفالٹ ڈھیر سے باہر بیٹھتا ہے۔
Part 5: دنیا سے جڑنا
12. MCP، ایمانداری سے
MCP کا مطلب ہے Model Context Protocol۔ یہ اے آئی کو ان دیگر ایپس اور خدمات سے جوڑنے کا ایک طریقہ ہے جو آپ پہلے سے استعمال کرتے ہیں: Slack، Google Docs، Notion، GitHub، ڈیٹابیسز، اور مزید۔ ایک بار جڑ جانے کے بعد، اے آئی سیدھے ان خدمات سے پڑھ اور ان میں لکھ سکتا ہے۔
"کیا یہ بس ایک API نہیں؟" تقریباً ، اور کچھ جوڑنے سے پہلے یہ واضح کرنا فائدہ مند ہے۔ MCP APIs اور دیگر tools کے گرد ایک معیاری لپیٹ ہے، ان کا متبادل نہیں۔ ایک خام API کو ہر بار کسی کے جوڑنے کی ضرورت ہوتی ہے (auth سنبھالنا، درخواستوں کی شکل بنانا، اور ماڈل کو بتانا کہ اسے کیسے بلانا ہے)؛ ایک MCP server یہ پہلے ہی کر چکا ہوتا ہے اور اپنے tools کی تشہیر کرتا ہے، تو ایجنٹ انہیں بغیر کسی انضمام کوڈ کے دریافت اور استعمال کر سکتا ہے۔ تو اصل سوال کبھی "MCP یا API" نہیں ، یہ ہے "کیا یہ ایک کھڑے کنکشن کے قابل ہے، یا ایجنٹ بس اس چیز کو سیدھا بلا سکتا ہے؟" نیچے دیے گئے استعمال/چھوڑنے کے قواعد بالکل یہی جواب دیتے ہیں۔
Claude Code اور OpenCode دونوں MCP کی سہولت دیتے ہیں۔ چونکہ MCP ایک کھلا معیار ہے، وہی server کسی بھی ٹول کے ساتھ کام کرتا ہے ، مگر ترتیب منتقل نہیں ہوتی، اس لیے آپ اسے ہر ایک میں الگ سے شامل کرتے ہیں (وہ اپنے کنکشن مختلف فائلوں میں رکھتے ہیں)۔
یہ ہے کہ آپ ہر ٹول میں ایک MCP کنکشن کیسے شامل کرتے ہیں:
servers کو CLI سے شامل کریں ، claude mcp add --transport http <name> <url> ، جو ڈیفالٹ کے طور پر ~/.claude.json (ذاتی) میں لکھتا ہے۔ اس کے بجائے اپنے پروجیکٹ کی جڑ میں ایک قابلِ اشتراک .mcp.json لکھنے کے لیے --scope project شامل کریں۔ پھر Claude Code کے اندر /mcp چلائیں حالت جانچنے اور کسی بھی server میں لاگ ان کرنے کے لیے جسے OAuth درکار ہو۔ (غور کریں: یہ .claude/settings.json نہیں ہے، جو اجازتوں اور hooks کے لیے ہے۔)
opencode.json میں اعلان کیا جاتا ہے۔ کسی میزبان server (ایک url کے ساتھ) کے لیے "type": "remote" استعمال کریں یا کسی ایسے کے لیے جو مقامی عمل کے طور پر چلے (ایک command جیسے ["npx", "-y", "some-mcp"] کے ساتھ) "type": "local":
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"sentry": {
"type": "remote",
"url": "https://mcp.sentry.dev/mcp",
"oauth": {}
},
"context7": {
"type": "remote",
"url": "https://mcp.context7.com/mcp"
}
}
}
ان servers کے لیے جنہیں لاگ اِن درکار ہو، OAuth کا عمل کرنے کے لیے opencode mcp auth <name> چلائیں؛ opencode mcp list ہر server کی حالت دکھاتا ہے۔
یہ کیوں کارآمد ہے: MCP کے بغیر، اے آئی صرف آپ کے کمپیوٹر کی فائلوں کے ساتھ کام کر سکتا ہے۔ MCP کے ساتھ، اے آئی آپ کے کمپیوٹر سے باہر پہنچ کر آن لائن خدمات سے تعامل کر سکتا ہے۔ مثلاً: آپ اے آئی سے پوچھ سکتے ہیں "آج میری ٹیم سے کوئی پیغام آیا تو میرا Slack دیکھو" یا "اس بگ کے لیے GitHub پر ایک نیا issue بناؤ،" اور اے آئی واقعی یہ کر دے گا، بجائے آپ کو بتانے کے کہ خود کیسے کریں۔
زیادہ سنجیدہ استعمال: اپنا نظامِ ریکارڈ جوڑنا۔ ایک نظامِ ریکارڈ (system of record) کسی مخصوص قسم کے ڈیٹا کا مستند گھر ہے ، وہ واحد نسخہ جسے ہر کوئی سچ مانتا ہے: آپ کا ڈیٹابیس، آپ کا CRM، آپ کا ٹکٹنگ سسٹم، کمپنی کا علمی ذخیرہ۔ MCP وہ طریقہ ہے جس سے آپ ایجنٹ کو کسی ایک کی طرف موڑتے ہیں تاکہ وہ کسی پرانے نسخے سے یا تربیت کی نصف یاد رکھی ہوئی حقیقت کے بجائے، زندہ، مستند ڈیٹا سے جواب دے۔ پوچھیں "آرڈر 4471 کی موجودہ حالت کیا ہے؟" اور ایجنٹ MCP کے ذریعے اصل ڈیٹابیس سے سوال کرتا ہے بجائے اندازہ لگانے کے۔ یہی وہ طریقہ بھی ہے جس سے علم کا ایک ذخیرہ ، ایک کتاب، ایک دستاویزی مجموعہ، ایک اندرونی wiki ، قابلِ سوال بنتا ہے: اس کے سامنے ایک MCP server کھڑا کریں، اور کوئی بھی ٹول اس سے سوال کر کے ماخذ پر مبنی جواب پا سکتا ہے۔ ہر اے آئی ورکر بھی MCP استعمال کر کے ایک نظامِ ریکارڈ کے خلاف چلتا ہے۔
مگر محتاط رہیں: ہر چیز نہ جوڑیں۔ ہر MCP کنکشن آپ کی گفتگو میں جگہ لے سکتا ہے، حتیٰ کہ تب بھی جب آپ اسے استعمال نہ کر رہے ہوں۔ OpenCode کی اپنی دستاویزات خبردار کرتی ہیں: "کچھ MCP servers، جیسے GitHub MCP server، بہت سے ٹوکن شامل کرنے کا رجحان رکھتے ہیں اور آسانی سے سیاق کی حد سے تجاوز کر سکتے ہیں۔" جاننے کے قابل ایک فرق: Claude Code اب ڈیفالٹ کے طور پر MCP tool تعریفیں مؤخر کر دیتا ہے (یہ کسی tool کی پوری تفصیل صرف تب لوڈ کرتا ہے جب وہ اسے استعمال کرنے والا ہو)، اس لیے اضافی servers وہاں کم سیاق خرچ کرتے ہیں۔ OpenCode انہیں شروع میں لوڈ کرتا ہے، اس لیے اس طرف خاص طور پر چنندہ رہیں۔ دونوں صورتوں میں، عادت ایک ہی ہے: صرف وہی جوڑیں جس کی آپ کو واقعی ضرورت ہو۔ یہی اس فکر کا اصل جواب بھی ہے کہ MCP سیاق کو پھلا دیتا ہے ، حل تہہ بندی ہے (tools کو سستی سے لوڈ کریں، سادہ کاموں کے لیے CLI پر بھروسا کریں، اور بھاری MCP کام تصور 11 کے کسی subagent میں دھکیلیں)، نہ کہ MCP چھوڑ دینا۔
MCP کب استعمال کریں اور کب چھوڑیں:
- MCP استعمال کریں جب خدمت کو اے آئی سے لاگ اِن یا جڑے رہنے کی ضرورت ہو۔ مثلاً: آپ کا Google Calendar پڑھنا، کسی ویب سائٹ کو دیکھنا، یا ایسے ڈیٹابیس سے سوال کرنا جسے پاس ورڈ درکار ہو۔
- MCP چھوڑیں جب اے آئی وہی نتیجہ ایک سادہ ٹرمینل کمانڈ چلا کر پا سکتا ہو۔ مثلاً: GitHub سے MCP کے ذریعے جڑنے کے بجائے، اے آئی بس ٹرمینل میں
gh issue listچلا کر آپ کے issues دیکھ سکتا ہے۔ کوئی لاگ اِن نہیں، کوئی کنکشن نہیں، کوئی اضافی ترتیب نہیں۔
ایک یا دو کنکشن سے شروع کریں جن کی آپ کو واقعی ضرورت ہو۔ دس صرف اس لیے انسٹال نہ کریں کہ وہ دستیاب ہیں۔
Part 6: ایک مکمل عملی مثال، دو بار
یہاں سب کچھ اکٹھا ہوتا ہے۔ آپ ایک مکمل کام شروع سے آخر تک کریں گے، ان تصورات کا استعمال کرتے ہوئے جو آپ نے اوپر سیکھے۔ یہ کام دو بار کیا جاتا ہے: ایک بار Claude Code میں اور ایک بار OpenCode میں، تاکہ آپ دیکھ سکیں کہ مراحل تقریباً ایک جیسے ہیں۔
کوڈنگ درکار نہیں۔ یہ مثال میٹنگ کے نوٹس استعمال کرتی ہے، مگر اس کے ساتھ چلنے کے لیے آپ کا پروگرامر ہونا ضروری نہیں۔ اگر آپ نے کبھی کسی میٹنگ، کلاس، یا گروپ پروجیکٹ میں نوٹس لیے ہیں، تو آپ یہ کام پہلے ہی سمجھتے ہیں۔
آپ کا کام
آپ کے پاس notes/ نام کا ایک فولڈر ہے جس میں پانچ میٹنگ نوٹس فائلیں ہیں۔ مسئلہ: یہ بے ترتیب ہیں۔ ہر میٹنگ نے اپنی کام والی اشیا مختلف انداز میں لکھیں۔ کچھ "Action Items" عنوان استعمال کرتی ہیں۔ کچھ "Todos"۔ ایک چھوٹے حروف میں "todo" استعمال کرتی ہے۔ کچھ کام والی اشیا دوسرے حصوں کے اندر دفن ہیں جہاں آپ دیکھنے کا سوچیں گے بھی نہیں۔ اور کچھ اشیا [private] یا [HR] نشان زدہ ہیں، یعنی انہیں کبھی عوامی طور پر شیئر نہیں ہونا چاہیے۔
آپ کا مقصد: weekly-actions.md نام کی ایک صاف فائل بنائیں جو:
- پانچوں میٹنگوں کی ہر کام والی شے درج کرے
- انہیں ذمہ دار شخص کے حساب سے گروپ کرے
- دکھائے کہ ہر شے کس میٹنگ سے آئی
- جو کچھ
[private]یا[HR]نشان زدہ ہے اسے چھوڑ دے - ایک بھی شے نہ چھوڑے
- اگر کوئی آخری تاریخ کسی عوامی تعطیل پر آئے تو آپ کو خبردار کرے
📁 پہلے پانچ ابتدائی فائلیں حاصل کریں (پھیلانے کے لیے کلک کریں)
شروع کرنے سے پہلے انہیں ایک notes/ فولڈر میں کاپی کریں۔ مثال انہی کے گرد بنائی گئی ہے: ہر فائل ایک مخصوص کردار ادا کرتی ہے، تو اگر آپ کوئی ایک چھوڑ دیں، تو نیچے کا کوئی ایک مرحلہ کام کرنا بند کر دیتا ہے۔ (فولڈر کی ترتیب چھوڑنا چاہتے ہیں؟ پانچوں فائلیں سیدھے اپنے ٹول کی چیٹ میں پیسٹ کریں اور اس سے کہیں کہ انہیں notes/ کا مواد سمجھے۔)
notes/2026-12-07-monday-team-meeting.md
# Monday Team Meeting - 2026-12-07
Attendees: @sara, @diego, @priya, @marcus
## Discussion
Reviewed last month's customer satisfaction scores. Renewals are down slightly in the small-business segment.
## Action Items
- @sara: draft a revised welcome email by Dec 18
- @diego: check spam-folder reports with our email vendor by Dec 16
- @marcus: pull renewal numbers for the last two quarters and share with the team
- @sara: finalize offer terms for the new account manager [HR]
notes/2026-12-08-customer-feedback.md
# Customer Feedback Review - 2026-12-08
Attendees: @sara, @amara, @marcus
## Summary
Read through the top twenty customer comments from last week. Three themes came up: pricing page is confusing, the call-back service is slow, and the FAQ on the website is out of date.
## Todos
- rewrite the pricing page in plain language
- @marcus: log a complaint with the call center vendor about response times
- look into why the FAQ has not been updated in six months
- @amara: draft a customer note explaining the upcoming changes
- review all printed brochures for outdated photos and pricing
notes/2026-12-08-q1-planning.md
# Q1 2027 Planning - 2026-12-08
Attendees: @sara, @diego, @amara, @lukas
## Initiatives
We walked through the four candidate initiatives for Q1.
### Year-end promotional campaign
Time-bound: wraps before the holiday break.
#### Action Items
- @amara: finalize the year-end promotional brochure by Dec 25
- @lukas: confirm placement with paid media partners by Dec 20
### Onboarding overhaul
Top priority next quarter.
## todo
- @diego: write the project brief by Jan 15
- @sara: own messaging and visual direction
notes/2026-12-09-all-hands-prep.md
# All-Hands Prep - 2026-12-09
Attendees: @sara, @marcus
## Agenda
Walked through the December all-hands agenda. Most slides are in good shape; a couple still need owners.
## Next Steps
- @marcus: set up the video call and record a practice run
- @sara: finalize the Q4 numbers slide
- @sara: prepare the bonus and compensation talking points [private]
- @marcus: book the venue for the team holiday dinner
notes/2026-12-11-vendor-review.md
# Vendor Review - 2026-12-11
Attendees: @sara, @amara, external partner
## Summary
Confidential contract negotiation with our printing and fulfillment vendor. Details under NDA.
## Action Items
- @sara: circulate the revised contract to the vendor [private]
- @amara: draft the internal announcement once terms are agreed [private]
- @sara: review the legal redlines on the new pricing schedule [private]
یہ رہنمائی کیسے ترتیب دی گئی ہے
نیچے آٹھ مراحل ہیں۔ ہر مرحلہ ایک ہی ساخت کی پیروی کرتا ہے:
- Claude Code میں کیا کرنا ہے (درست ہدایات)
- یہ مرحلہ کیوں اہم ہے (ایک مختصر وضاحت)
- OpenCode میں کیا مختلف ہے (اگر کچھ بدلتا ہے، تو یہاں بتایا گیا ہے۔ اگر یہ کہے "ایک جیسا،" تو اس مرحلے کے لیے دونوں ٹولز ایک ہی طرح کام کرتے ہیں)
Step 1: اپنی قواعد کی فائل ترتیب دیں
Claude Code میں: اپنے پروجیکٹ فولڈر میں Claude Code کھولیں۔ /init چلائیں۔ اے آئی آپ کے فولڈر کو اسکین کر کے CLAUDE.md نام کی ایک فائل بنائے گا۔ یہ بہت لمبی ہوگی۔ اس کا زیادہ تر حصہ حذف کر دیں اور صرف یہ رکھیں:
# weekly-rollup
## Layout
- `notes/`: meeting notes, one file per meeting
- `weekly-actions.md`: the rollup we are creating
- `plans/weekly-rollup-plan.md`: the plan we will save and reuse
## Critical rules
- Action items can appear under `## Action Items`, `## Todos`, `## Next Steps`, or `## todo` (one meeting uses lowercase). Look at all heading levels, not just the top.
- Owners are written as `@name`. Items with no owner go to an "Unassigned" section.
- Never include any bullet tagged `[private]` or `[HR]`.
یہ کیوں اہم ہے: اے آئی یہ فائل ہر ایک پیغام کے آغاز پر پڑھتا ہے۔ ایک لمبی فائل چیزوں کو سست کرتی ہے اور جگہ ضائع کرتی ہے۔ تو آپ صرف وہی رکھتے ہیں جو اے آئی فولڈر کو خود دیکھ کر نہیں سمجھ سکتا۔ رازداری کا اصول خاص طور پر اہم ہے کیونکہ اے آئی کے پاس یہ جاننے کا کوئی طریقہ نہیں کہ [private] اشیا کو چھپانا چاہیے۔
OpenCode میں: وہی چیز، مگر فائل کا نام CLAUDE.md کے بجائے AGENTS.md ہے۔ اگر آپ کے پاس پہلے سے CLAUDE.md ہے، تو OpenCode اسے بھی پڑھ لے گا۔
کچھ بعد کے مراحل آپ کا کام git commit سے محفوظ کرتے ہیں (اور OpenCode کا undo بھی git پر انحصار کرتا ہے)۔ اگر یہ فولڈر ابھی تک repository نہیں، تو ابھی ایک بار git init چلائیں تاکہ وہ مراحل کام کریں۔ اسی موقع پر، Claude Code پر Step 6 کی حفاظتی جانچ jq نام کا ایک چھوٹا ٹول استعمال کرتی ہے ، زیادہ تر سسٹمز میں یہ موجود ہوتا ہے، مگر اگر Step 6 میں "jq: command not found" کی خرابی آئے، تو اسے انسٹال کریں (brew install jq، یا Linux پر apt install jq)۔
Step 2: کچھ بھی کرنے سے پہلے ایک منصوبہ بنائیں
Claude Code میں: plan mode آن کرنے کے لیے Shift+Tab دو بار دبائیں (اے آئی پڑھ سکتا ہے مگر کچھ بدل نہیں سکتا)۔ پھر ٹائپ کریں:
Read every file in notes/. Produce weekly-actions.md grouped by
owner. For each item include the action, the source filename, and
the meeting date. Skip anything tagged [private] or [HR]. Do not
lose any action items.
اے آئی ایک منٹ سوچتا ہے اور اپنے کام کا ایک تحریری منصوبہ لے کر آتا ہے۔
یہ کیوں اہم ہے: ایک منصوبہ پڑھنے میں 30 سیکنڈ لگتے ہیں۔ ایک غلطی واپس کرنے میں کہیں زیادہ۔ ہمیشہ پہلے منصوبہ بنائیں۔
OpenCode میں: Plan mode پر بدلنے کے لیے Tab دبائیں۔ باقی سب کچھ ایک جیسا ہے۔
Step 3: منصوبہ جانچیں اور غلطیاں ٹھیک کریں
Claude Code میں: منصوبہ غور سے پڑھیں۔ اس میں دو چیزیں شاید غلط ہوں گی۔
پہلی: یہ صرف اوپری سطح کے عنوانات (## Action Items، ## Todos) کا ذکر کرے گا۔ مگر آپ کی ایک میٹنگ فائل (Q1 منصوبہ بندی کے نوٹس) کام والی اشیا ### Year-end promotional campaign کے اندر چھپاتی ہے، جس کے نیچے ایک #### Action Items ہے۔ منصوبہ انہیں چھوڑ دے گا۔
دوسری: یہ نہیں بتائے گا کہ ان کام والی اشیا کے ساتھ کیا کرنا ہے جن کا کوئی مالک نہیں (ان کے ساتھ کوئی @name نہیں، جیسے customer-feedback فائل کا "rewrite the pricing page in plain language")۔ وہ خاموشی سے غائب ہو جائیں گی۔
آپ مزاحمت کرتے ہیں:
Two changes. (1) Look at all heading levels, not just the top.
Some action items live under sub-headings. (2) Items without an
owner go to an "Unassigned" section at the bottom; never drop
them.
اے آئی منصوبہ اپ ڈیٹ کرتا ہے۔ اس سے کہیں کہ حتمی منصوبہ plans/weekly-rollup-plan.md میں محفوظ کرے تاکہ آپ اسے اگلے ہفتے دوبارہ استعمال کر سکیں۔
یہ کیوں اہم ہے: کسی منصوبے کو ٹھیک کرنا مکمل ہوئے کام کو ٹھیک کرنے سے کہیں آسان ہے۔ مسائل ابھی پکڑیں، جب اس کی کوئی قیمت نہیں۔
OpenCode میں: وہی مراحل، کچھ مختلف نہیں۔
Step 4: اے آئی کو کام کرنے دیں
Claude Code میں: plan mode سے نکلنے کے لیے Shift+Tab دبائیں۔ اے آئی کو آگے بڑھنے کو کہیں۔
اے آئی پانچوں میٹنگ فائلیں پڑھتا ہے، weekly-actions.md بناتا ہے، اشیا کو مالک کے حساب سے گروپ کرتا ہے، [private] اور [HR] اشیا ہٹاتا ہے، اور بغیر مالک والی اشیا ایک "Unassigned" حصے میں ڈالتا ہے۔ آپ یہ ہوتا دیکھتے ہیں۔
یہ کیوں اہم ہے: کیونکہ آپ نے پہلے منصوبہ بنایا، نتیجہ پہلی ہی کوشش میں زیادہ تر درست ہوتا ہے۔
weekly-actions.md آپ کے اصل پروجیکٹ فولڈر میں ہونی چاہیے، notes/ فولڈر کے ساتھ، اس کے اندر نہیں۔ اگر اے آئی نے اسے غلط جگہ رکھا، تو شاید Step 1 کی آپ کی قواعد کی فائل میں Layout حصہ غائب ہو۔
OpenCode میں: اے آئی ہر فائل لکھنے سے پہلے آپ کی منظوری مانگے گا۔ آپ ہاں کہہ سکتے ہیں، یا مستقبل کے چلاؤ کے لیے opencode.json میں خودکار-منظوری ترتیب دے سکتے ہیں۔
Step 5: گفتگو صاف کریں
Claude Code میں: گفتگو اب لمبی ہو چکی ہے۔ اے آئی نے ہر میٹنگ نوٹ پڑھ لیا ہے، اور وہ سارا متن ابھی بھی جگہ لے رہا ہے، بشمول وہ نجی اشیا جو اس نے چھوڑیں۔ آپ کو اب اس میں سے کسی کی ضرورت نہیں۔ ٹائپ کریں:
/compact keep the heading rules, the owner list, and the
private/HR exclusion rule
اے آئی گفتگو کا خلاصہ بناتا ہے اور باقی سب کچھ پھینک دیتا ہے۔ صرف وہ حصے باقی رہتے ہیں جنہیں رکھنے کو آپ نے کہا۔
یہ کیوں اہم ہے: ایک لمبی، بھری ہوئی گفتگو اے آئی کو بہتر نہیں، بدتر کرتی ہے۔ یہ زیادہ مہنگی بھی پڑتی ہے۔ جس کی آپ کو اب ضرورت نہیں اسے صاف کر دیں، خاص طور پر نجی مواد جو یادداشت میں نہیں رہنا چاہیے۔
OpenCode میں: وہی کمانڈ، وہی نتیجہ۔
Step 6: ایک خودکار حفاظتی جانچ شامل کریں
Claude Code میں: اپنا کام محفوظ کرنے سے پہلے، آپ یقینی بنانا چاہتے ہیں کہ کوئی میٹنگ غلطی سے چھوٹ نہ جائے۔ آپ ایک hook شامل کریں گے: ایک خودکار جانچ جو ہر بار چلتی ہے جب اے آئی آپ کا کام محفوظ (commit) کرنے کی کوشش کرے۔ (یہاں "محفوظ" کا مطلب git commit چیک پوائنٹ ہے ، وہ لمحہ جب آپ git میں ایک snapshot ریکارڈ کرتے ہیں ، نہ کہ صرف weekly-actions.md فائل لکھنا۔)
تعارف نے کوڈنگ نہ ہونے کا وعدہ کیا تھا، اور وہ اب بھی قائم ہے: آپ یہاں ایک بلاک پیسٹ کریں گے، لکھیں گے نہیں، اور آپ کو کوڈ سمجھنے کی ضرورت نہیں۔ اس کے فوراً بعد کی سادہ-زبان وضاحت بس وہی ہے جو آپ کو چاہیے۔ (یہ اس بات پر بھی انحصار کرتا ہے کہ یہ فولڈر ایک git repo ہو ، Step 1 کی ترتیب کی تجویز دیکھیں۔)
یہ باب کی واحد جگہ ہے جہاں آپ خود ایک config بلاک پیسٹ کرتے ہیں بجائے ماڈل سے لکھوانے کے۔ دو وجوہات ہیں، دونوں مشکل سے سیکھی گئیں۔
(1) "Hook" مبہم ہے۔ اگر آپ ماڈل سے کہیں "ایک hook بناؤ،" تو Claude Code ایک Claude Code hook (.claude/settings.json میں ایک اندراج) کے بجائے ایک git hook (.git/hooks/ میں ایک فائل) کی طرف جا سکتا ہے۔ یہ مختلف چیزیں ہیں؛ آپ کو دوسری چاہیے۔
(2) اے آئی غلطی سے حفاظتی جانچ توڑ دے گا۔ آپ کی قواعد کی فائل کہتی ہے کہ [private] اشیا چھوڑ دو۔ اگر آپ اے آئی سے hook لکھنے کو کہیں، تو وہ اس اصول کو پڑھے گا اور "مدد کرتے ہوئے" وہی چھوڑنے والی منطق hook میں شامل کر دے گا۔ اس کا مطلب ہے کہ vendor-review میٹنگ (جہاں ہر شے [private] ہے) hook کی طرف سے خاموشی سے نظر انداز ہو جاتی ہے، اور کبھی کوئی انتباہ نہیں اٹھتا۔ مگر hook کا پورا مقصد بالکل یہی صورت پکڑنا ہے: ایک میٹنگ جو ایسے لگے جیسے چھوٹ گئی۔ آپ اے آئی سے اس کے اپنے قواعد کے خلاف حفاظتی جانچ بنانے کو نہیں کہہ سکتے۔ وہ ہمیشہ "مددگار" ہونے اور جانچ کو شکست دینے کا کوئی راستہ نکال لے گا۔
محفوظ حرکت بس config پیسٹ کرنا ہے۔
.claude/settings.json کھولیں (اگر فائل موجود نہ ہو تو بنا لیں) اور یہ بالکل ویسے ہی پیسٹ کریں:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "jq -r '.tool_input.command' | grep -q '^git commit' || exit 0; for f in notes/*.md; do grep -q \"$(basename $f)\" weekly-actions.md || { echo \"Missing: $f\" >&2; exit 2; }; done"
}
]
}
]
}
}
یہ سادہ زبان میں کیا کرتا ہے: ہر بار جب اے آئی آپ کا کام محفوظ (commit) کرنے کی کوشش کرتا ہے، یہ hook ایک سادہ بات جانچتا ہے: کیا notes/ کی ہر میٹنگ فائل weekly-actions.md میں کہیں نہ کہیں موجود ہے؟ اگر کوئی فائل نام غائب ہو، تو یہ محفوظ کرنے کو روک دیتا ہے۔ یہ مواد نہیں جانچتا، [private] نشانات نہیں دیکھتا، کوئی استثنا نہیں دیتا۔ یہ صرف فائل ناموں کو جانچتا ہے۔ یہی پورا مقصد ہے۔
دیکھیں کیا ہوتا ہے۔ اے آئی کو commit کرنے کو کہیں۔ حفاظتی جانچ چلتی ہے: Missing: notes/2026-12-11-vendor-review.md۔ کیوں؟ کیونکہ اس میٹنگ کی ہر کام والی شے [private] نشان زدہ تھی، اور Step 1 کے آپ کے قواعد کہتے ہیں نجی اشیا چھوڑ دو۔ تو جب اے آئی نے خلاصہ بنایا، اس کے پاس اس فائل سے لکھنے کو کچھ نہیں تھا، اور فائل نام کبھی ظاہر نہیں ہوا۔ hook کو اس میں سے کچھ معلوم نہیں۔ یہ بس ایک غائب فائل نام دیکھتا ہے اور محفوظ کرنے کو روک دیتا ہے۔
ماڈل خرابی پڑھتا ہے اور rollup کو ایک placeholder اندراج سے درست کرتا ہے جو فائل کا واضح نام لیتا ہے، مثلاً:
## From 2026-12-11-vendor-review.md
- All items confidential ، see meeting owner.
فائل نام اب weekly-actions.md میں موجود ہے، hook کا grep اسے پا لیتا ہے، commit ہو جاتا ہے۔ کوئی نجی چیز rollup میں نہیں رِسی؛ آڈٹ کا نشان برقرار ہے۔
آپ نے اس عمل کے دوران کچھ نہیں کیا۔ حفاظتی جال نے غلطی پکڑی اور ماڈل نے خود کو ٹھیک کر لیا۔
کیوں۔ وہ چیزیں جنہیں آپ ہر ایک بار سچ رکھنا چاہتے ہیں ان کا انحصار ماڈل کے یاد رکھنے پر نہیں ہونا چاہیے۔ انہیں خود بخود جانچا جانا چاہیے۔ اور جانچ کو وہاں رہنا چاہیے جہاں ماڈل اسے خود کو خوش کرنے کے لیے خاموشی سے دوبارہ نہ لکھ سکے: اسی لیے یہ والی ایک پیسٹ ہے، پرامپٹ نہیں۔
OpenCode میں کیا بدلتا ہے۔ OpenCode انہیں hooks کے بجائے plugins کہتا ہے، اور یہ ایک چھوٹی JavaScript فائل کے طور پر لکھے جاتے ہیں۔ وہی خیال، وہی نتیجہ، وہی پیسٹ-کرو-نہ-کہ-پرامپٹ منطق۔ .opencode/plugins/check-rollup-complete.js بنائیں (فولڈر شاید ابھی موجود نہ ہو) اور یہ پیسٹ کریں:
// .opencode/plugins/check-rollup-complete.js
import { readdirSync, readFileSync } from "fs";
export const CheckRollupCompletePlugin = async ({ $ }) => {
return {
"tool.execute.before": async (input, output) => {
if (
input.tool === "bash" &&
output.args.command?.startsWith("git commit")
) {
const rollup = readFileSync("weekly-actions.md", "utf8");
const missing = readdirSync("notes")
.filter((f) => f.endsWith(".md"))
.filter((f) => !rollup.includes(f));
if (missing.length) {
throw new Error(`Missing from rollup: ${missing.join(", ")}`);
}
}
},
};
};
وہی شکل: notes/ کی ہر فائل درج کرو، جانچو کہ ہر basename rollup میں ہے، اگر کوئی غائب ہو تو throw کرو۔ اندر کوئی [private] چھان نہیں۔ رویہ Claude Code نسخے جیسا ہی ہے: غائب فائل، commit روکا گیا، ماڈل خود کو ٹھیک کرتا ہے۔
hook/plugin مواد گہرائی میں (exit codes، matcher نحو، مکمل واقعات کی فہرست) باب 14 § Hooks اور Extensibility میں ہے (اور OpenCode کی طرف کے لیے Plugins: سب کچھ اکٹھا کرنا)۔
Step 7: ایک ضمنی کام کسی مددگار کو بھیجیں
Claude Code میں: کچھ کام والی اشیا کی آخری تاریخیں ہیں جیسے "by Dec 25" یا "before year-end"۔ آپ جانچنا چاہتے ہیں کہ کیا ان میں سے کوئی تاریخ کسی عوامی تعطیل پر آتی ہے۔ ٹائپ کریں:
Use a research helper to look up the 2026 international public
holidays list and write the dates to tmp/holidays-2026.md.
ایک مددگار (subagent) ویب پر جاتا ہے، تعطیل کی تاریخیں ڈھونڈتا ہے، اور انہیں ایک چھوٹی فائل میں محفوظ کرتا ہے۔ آپ کی اصل گفتگو کبھی پورا ویب صفحہ نہیں دیکھتی۔ وہ صرف تاریخوں والی چھوٹی فائل دیکھتی ہے۔
یہ تصور 11 کے subagent جیسا ہی طریقہ ہے ، ایک ویب-قابل مددگار جو صرف ایک خلاصہ واپس کرتا ہے۔ وہاں والے کا نام doc-fetcher تھا اور اسے تنگ انداز میں library docs کے لیے بیان کیا گیا تھا، تو اس طرح کی عام تلاش کے لیے، یا تو اس مددگار کو ایک وسیع تر تفصیل دیں (مثلاً "fetch and summarize external references and lookups") یا WebFetch اور Write tools کے ساتھ ایک چھوٹا researcher ایجنٹ بنائیں۔ اس مرحلے کا نکتہ سونپنا ہے، نہ کہ بالکل کون سا ایجنٹ۔
اے آئی پھر آپ کے خلاصے کی آخری تاریخوں کا تعطیل کی تاریخوں سے موازنہ کرتا ہے اور کسی بھی آخری تاریخ کے ساتھ جو کسی تعطیل پر آئے، ایک انتباہ شامل کرتا ہے جیسے ⚠ falls on Christmas Day۔
یہ کیوں اہم ہے: اگر اے آئی نے ویب صفحہ سیدھا لایا ہوتا، تو وہ آپ کی گفتگو میں بہت زیادہ متن انڈیل دیتا۔ ایک مددگار بھیجنا آپ کی گفتگو کو صاف رکھتا ہے۔
OpenCode میں: اپنے تحقیقی مددگار کو سیدھا نام سے بلائیں ، مثلاً @researcher۔ وہی نتیجہ۔
Step 8: اسے اگلی بار کے لیے ایک skill کے طور پر محفوظ کریں
Claude Code میں: آپ یہ کام ہر ہفتے کریں گے۔ اگلے جمعہ یہ سب مراحل یاد رکھنے کے بجائے، اے آئی سے کہیں کہ سب کچھ ایک skill کے طور پر محفوظ کرے:
Create a skill at ~/.claude/skills/weekly-meeting-rollup/SKILL.md
based on what we just did. Include: the four heading variants,
the all-headings rule, the private/HR exclusion, the Unassigned
section, the missing-file check, and the holiday cross-reference.
اگلے جمعہ، بس "do the weekly rollup" ٹائپ کریں اور اے آئی یہ skill خود بخود استعمال کرے گا۔ جو سارے قواعد آپ نے آج ترتیب دیے (عنوان کی اقسام، رازداری کا فلٹر، unassigned حصہ، تعطیل کی جانچ) ہر بار لاگو ہوتے ہیں بغیر آپ کے کچھ یاد رکھے۔
یہ کیوں اہم ہے: جو کام آپ نے آج کیا وہ صرف آج کے لیے نہیں تھا۔ آپ نے اے آئی کو سکھایا کہ یہ کام اب سے کیسے کرنا ہے۔
OpenCode میں: skill ایک تھوڑے مختلف فولڈر میں محفوظ ہوتی ہے، مگر فائل خود ایک جیسی ہے۔ آپ اسے دونوں ٹولز کے درمیان کاپی کر سکتے ہیں اور یہ دونوں میں کام کرتی ہے۔
ابھی کیا ہوا
ان آٹھ مراحل پر دوبارہ نظر ڈالیں۔ ان میں سے کسی کے لیے بھی آپ کو کوڈ لکھنے کی ضرورت نہیں تھی۔ ان میں سے کسی کے لیے یہ جاننے کی ضرورت نہیں تھی کہ API کیا ہے۔ آپ نے اصل میں جو کیا وہ ماڈل کی توجہ سنبھالنے کے آٹھ چھوٹے عمل تھے: اسے بتانا کہ کس چیز کو دیکھے، کب منصوبہ بنائے، کب بھول جائے، کب سونپے، کب خود پر بھروسا کرنا بند کرے، اور کب یاد رکھے۔
یہی پورا باب ہے۔
اور دیکھیں دونوں ٹولز کے درمیان کتنا کم مختلف تھا:
- قواعد کی فائل کے لیے ایک مختلف فائل نام (
CLAUDE.mdبمقابلہAGENTS.md) - plan mode میں داخل ہونے کے لیے ایک مختلف کی اسٹروک (
Shift+TabبمقابلہTab) - حفاظتی-جال فائل کے لیے ایک مختلف زبان (JSON بمقابلہ JavaScript)
- آخر میں skill کے لیے ایک مختلف فولڈر (مگر وہی فائل)
بس اتنا ہی۔
سوچ ہی ٹول ہے۔ configs سجاوٹ ہیں۔ اس طرح سوچنا سیکھ لیں اور آپ کی مہارتیں زندہ رہتی ہیں چاہے کوئی بھی ٹول جیتے۔
13. ٹرمینل، IDE، یا ڈیسک ٹاپ؟
دونوں ٹولز کئی جگہوں پر چلتے ہیں۔
Claude Code: ٹرمینل (CLI)، VS Code / JetBrains plugins، ایک ڈیسک ٹاپ ایپ (macOS اور Windows پر ایک Code workspace ، Linux پر نہیں ، جو کئی سیشن متوازی چلانے کے لیے بنایا گیا، ہر ایک اپنے git worktree میں)، ویب (claude.com)، ایک موبائل ایپ، اور cloud پر میزبان سیشن غیر ہم وقت کام کے لیے جنہیں آپ ان میں سے کسی سے بھی دیکھ سکتے ہیں۔
OpenCode: ٹرمینل (TUI سب سے نمایاں ہے)، ایک ڈیسک ٹاپ ایپ (beta، macOS / Windows / Linux پر)، ایک VS Code extension اور Zed جیسے دیگر ایڈیٹرز اپنے ACP server کے ذریعے، SDK کے ذریعے ایک ویب انٹرفیس، اور انضمام جیسے ایک GitHub ایجنٹ اور ایک Slack bot۔
جو آپ کر رہے ہیں اس پر جو ٹھیک بیٹھے وہ چنیں۔ اگر آپ کوڈ لکھ رہے ہیں، تو VS Code یا JetBrains plugin بہترین ہے کیونکہ آپ اے آئی کو اپنی فائلیں حقیقی وقت میں بدلتا دیکھ سکتے ہیں۔ اگر آپ لمبے کام چلا رہے ہیں اور انتظار کے دوران دوسری چیزیں کرنا چاہتے ہیں، تو ٹرمینل اچھا کام کرتا ہے۔ غیر-کوڈنگ کام کے لیے، سب سے آسان اختیار ویب ایپس ہیں یا ، Claude کی طرف ، ڈیسک ٹاپ ایپ کا Cowork ٹیب، علمی-کام والا حالت جو اسی ایپ میں Code ٹیب (جو Claude Code ہے) کے ساتھ بیٹھتا ہے۔
مضبوط تجویز، کسی بھی ٹول میں: ٹرمینل یا کسی IDE plugin میں شروع کریں۔ ایک بار جب آپ سمجھ لیں کہ نیچے کیا ہو رہا ہے (ماڈل کون سی فائلیں پڑھتا ہے، کون سی کمانڈز چلاتا ہے، کون سے فیصلے کرتا ہے)، تو ہر دوسرا انٹرفیس ایک پتلی لپیٹ بن جاتا ہے جس کے آر پار آپ دیکھ سکتے ہیں۔ اگر آپ کسی بھاری مجرد UI میں شروع کریں، تو جب چیزیں بگڑیں گی تو آپ ڈیبگ کرنے میں جدوجہد کریں گے، کیونکہ آپ کو معلوم ہی نہیں ہوگا کہ کیا بگڑ سکتا ہے۔
14. ایک ذاتی سیاق لائبریری بنائیں، آہستہ آہستہ
ایک بار جب آپ کے چند پروجیکٹ کسی بھی ٹول کو استعمال کر رہے ہوں، تو آپ غور کریں گے کہ آپ ہر قواعد کی فائل میں ملتی جلتی چیزیں لکھ رہے ہیں: آپ کا کوڈ انداز، آپ کے commit ضابطے، آپ کا ٹیسٹنگ فلسفہ۔ کاپی پیسٹ کرنا بند کریں۔
مشترکہ حصے اپنی home config میں رکھیں اور انہیں ہر پروجیکٹ کی قواعد کی فائل سے حوالہ دیں:
~/.claude/CLAUDE.md (ہر پروجیکٹ میں لوڈ):
# CLAUDE.md
@~/.claude/style/typescript.md
@~/.claude/style/commits.md
پھر ہر پروجیکٹ کی اپنی CLAUDE.md اس کے لیے رکھیں جو اس پروجیکٹ کے لیے مخصوص ہے ، اوپر والی عالمی فائل (اور وہ انداز جو یہ import کرتی ہے) ہر جگہ خود بخود کھینچ لی جاتی ہے۔
~/.config/opencode/:
// ~/.config/opencode/opencode.json
{
"$schema": "https://opencode.ai/config.json",
"instructions": ["style/typescript.md", "style/commits.md"]
}
اس کے علاوہ ایک پروجیکٹ-مخصوص AGENTS.md اس کے لیے جو اس پروجیکٹ کے لیے مخصوص ہے۔
یہی خیال skills کے لیے کام کرتا ہے۔ ~/.claude/skills/ (جسے OpenCode بھی پڑھتا ہے) یا ~/.config/opencode/skills/ میں ایک commit-message skill یا code-review skill ہر جگہ خود بخود دستیاب ہوتی ہے۔
یہ سب ایک ہی بار بنانے کی کوشش نہ کریں۔ ایک ہفتے کے آخر میں مکمل ذاتی لائبریری ترتیب دینے میں صرف کرنا پرکشش ہے۔ ایسا نہ کریں۔ اس کے بجائے، چیزیں ایک ایک کر کے شامل کریں، صرف تب جب آپ کو واقعی ضرورت ہو۔ اے آئی کے غلط انداز میں کوڈ لکھنے کے بعد ایک انداز کی رہنمائی شامل کریں۔ ایک ہی commit ہدایات تیسری بار ٹائپ کرنے کے بعد ایک commit skill شامل کریں۔ حقیقی مسائل سے بنی لائبریری چھوٹی اور کارآمد رہتی ہے۔ پہلے سے ڈیزائن کی گئی لائبریری بڑی اور نظر انداز شدہ بن جاتی ہے۔
15. بنیادی باتوں سے آگے یادداشت
زیادہ تر لوگوں کے لیے، پرانی گفتگوئیں دوبارہ شروع کرنا اور ایک اچھی قواعد کی فائل رکھنا کافی ہے۔ مگر اگر آپ چاہتے ہیں کہ اے آئی نئی گفتگو شروع کرنے کے بعد بھی چیزیں یاد رکھے، تو یہ آپ کے اختیار ہیں:
- آپ کے پروجیکٹ میں ایک
notes/فولڈر۔ کوئی کام مکمل کرنے کے بعد، اے آئی سے کہیں کہ اس نے کیا کیا اور کیا فیصلے ہوئے، اس کا ایک مختصر خلاصہ لکھے۔ اسے ایکnotes/فولڈر میں محفوظ کریں۔ اگلی بار، اے آئی وہ نوٹس پڑھ کر سمجھ بوجھ حاصل کر سکتا ہے۔ سادہ، کوئی ترتیب درکار نہیں، دونوں ٹولز میں کام کرتا ہے۔ - ایک memory MCP server۔ یہ اے آئی کو گفتگوؤں کے آر پار معلومات محفوظ اور یاد کرنے کا ایک طریقہ دیتے ہیں۔ کئی مفت موجود ہیں اور دونوں ٹولز میں کام کرتے ہیں۔
- پرانی گفتگوؤں میں تلاش۔ کچھ ترتیبیں آپ کو اپنی گزشتہ گفتگوئیں تلاش کرنے دیتی ہیں تاکہ یہ پتا چلے کہ "کیا میں نے یہ پہلے حل کیا تھا؟" دیکھنے کے لیے اپنے ٹول کے docs دیکھیں کہ کیا دستیاب ہے۔
ٹولز سادہ نسخہ آپ کے لیے کرنا شروع کر رہے ہیں۔ Claude Code میں اب ایک بلٹ ان خودکار یادداشت ہے: جیسے جیسے آپ کام کرتے ہیں، یہ آپ کی تصحیحات اور ترجیحات کے بارے میں اپنے مختصر نوٹس لکھتا ہے اور انہیں ہر سیشن کے آغاز پر دوبارہ لوڈ کرتا ہے ، notes/ فولڈر کا خیال، خودکار۔ (یہ Claude Pro اور Max پلانز پر چلتا ہے اور ابھی پھیل رہا ہے، اس لیے ہر جگہ اس پر بھروسا نہ کریں؛ دستی notes/ فولڈر وہ طریقہ ہے جو کسی بھی ٹول میں، کسی بھی ماڈل پر کام کرتا ہے۔) دونوں صورتوں میں، یہ صرف نیچے دیے گئے اصول کو ہی مضبوط کرتا ہے۔
اس بنیاد پر چنیں کہ آپ کو واقعی کیا چاہیے۔ اگر آپ صرف ایک پروجیکٹ کے بارے میں فیصلے یاد رکھنا چاہتے ہیں، تو ایک notes/ فولڈر کافی ہے۔ اگر آپ چاہتے ہیں کہ اے آئی آپ کے سب پروجیکٹس میں سب کچھ یاد رکھے، تو آپ کو کچھ زیادہ اعلیٰ چاہیے۔ کوئی حقیقی مسئلہ حل کرنے سے پہلے پیچیدہ ٹولز ترتیب نہ دیں۔
Part 8: Claude Code اور OpenCode کو ملانا
اب تک، اس کورس نے Claude Code اور OpenCode کو دو اختیارات کی طرح برتا ہے: ایک چنیں اور اسے سیکھیں۔ مگر ایک بار جب آپ بنیادی باتوں میں مطمئن ہو جائیں، تو آپ واقعی دونوں ٹولز ایک ہی پروجیکٹ پر اکٹھے استعمال کر سکتے ہیں۔ یہ صرف ایک بیک اپ منصوبہ نہیں۔ ہر ٹول میں وہ طاقتیں ہیں جو دوسرے میں نہیں، اور انہیں ملانا کسی ایک کو اکیلے استعمال کرنے سے زیادہ مؤثر ہو سکتا ہے۔
اسے محفوظ رکھنا: git worktrees
ساخت دیکھنے سے پہلے، ایک حفاظتی مسئلہ پہلے حل کرنا ہے۔
اگر آپ ایک ہی پروجیکٹ پر ایک ہی وقت میں دو اے آئی سیشن چلائیں، اور دونوں ایک ہی فائل بدلنے کی کوشش کریں، تو ایک دوسرے کی تبدیلیاں اوپر لکھ دے گا۔ یہ ایک گڑبڑ ہے۔
اس کا حل git worktrees کہلاتا ہے۔ اسے اپنے پروجیکٹ فولڈر کی ایک کاپی بنانے کی طرح سمجھیں، مگر زیادہ سمجھدار۔ ہر کاپی (جسے "worktree" کہتے ہیں) اپنا الگ workspace ہے جہاں اے آئی آزادانہ کام کر سکتا ہے۔ ایک worktree میں تبدیلیاں دوسرے کو متاثر نہیں کرتیں۔ جب دونوں مکمل ہو جائیں، تو آپ git استعمال کر کے نتائج اکٹھے merge کر دیتے ہیں۔
اسے ترتیب دینے کا طریقہ یہ ہے:
یہ قدم بہ قدم کیسے کام کرتا ہے:
# Step 1: Go to your project folder
cd myproject
# Step 2: Create two worktrees (two separate copies, each on a NEW branch)
# The -b flag creates the branch; without it, git expects the branch to already exist.
git worktree add -b my-branch-1 ../myproject-copy1
git worktree add -b my-branch-2 ../myproject-copy2
اب آپ کے پاس دو الگ فولڈر ہیں (myproject-copy1 اور myproject-copy2)، ہر ایک میں آپ کے پروجیکٹ کی اپنی کاپی ایک مختلف branch پر۔
# Step 3: Open Claude Code in one copy
cd ../myproject-copy1
claude
# Step 4: Open OpenCode in the other copy (in a separate terminal window)
cd ../myproject-copy2
opencode
دونوں اے آئی ٹولز اب ایک ہی وقت میں مختلف کاپیوں پر کام کر رہے ہیں۔ وہ ایک دوسرے کی فائلیں اوپر نہیں لکھ سکتے۔
# Step 5: When you're happy with the work, go back to the main folder and
# merge each branch into your main branch (it may be called main or master).
# Because the two sessions worked in different files (see the rule below),
# these merges should apply cleanly.
cd ../myproject
git merge my-branch-1
git merge my-branch-2
# Step 6: Clean up the copies (this removes the worktrees; your merged
# commits are safe in the main branch)
git worktree remove ../myproject-copy1
git worktree remove ../myproject-copy2
فائل-تبدیلی کا اصول، تین درجوں میں:
| ساخت | فیصلہ |
|---|---|
| دو سیشن بیک وقت ایک ہی فائل بدلتے ہوئے | بُرا: آخری لکھائی جیتتی ہے، دوسرے سیشن کی تبدیلیاں ضائع ہو جاتی ہیں |
| دو سیشن مختلف ڈائریکٹریوں کو بدلتے ہوئے | اچھا: کوئی ٹکراؤ نہیں، متوازی تیزی حقیقی ہے |
| ایک سیشن بدلتا ہے، commit کرتا ہے، دوسرے کو سونپتا ہے | قابلِ قبول: commit ہی سونپنے کی شے ہے |
عام اصول: ہر کام کے لیے ایک سیشن سے شروع کریں۔ دوسرا صرف تب شامل کریں جب آپ واضح طور پر اشارہ کر سکیں کہ ہر سیشن کے پاس کون سی فائلیں ہیں۔ دو ایجنٹک سیشنوں کے درمیان سیاق بدلنے کی ذہنی قیمت حقیقی ہے؛ یہ صرف تب جیت ہے جب کام واقعی بٹ جائے۔
وہ مشترکہ تہہ جو ان میں سے کسی کو کام کراتی ہے وہ پروجیکٹ کے قواعد اور skills ہیں۔ دونوں ٹولز وہی CLAUDE.md اور وہی .claude/skills/ ڈائریکٹری پڑھتے ہیں (تصورات 8 اور 9 اس کا احاطہ کرتے ہیں)۔ پروجیکٹ کے ضابطوں کے لیے سچ کا ایک ماخذ؛ دو ٹولز اسے استعمال کرتے ہوئے۔
Pattern 1: Plan / Execute تقسیم
کسی بھی کام کا مشکل حصہ یہ سمجھنا ہے کہ کیا کرنا ہے: پروجیکٹ پڑھنا، انداز طے کرنا، یہ سوچنا کہ کیا غلط ہو سکتا ہے۔ آسان حصہ یہ ہے کہ ایک بار واضح منصوبہ ہو تو اسے کرنا۔ اے آئی ماڈلز یہی عکاسی کرتے ہیں: سب سے طاقتور (اور مہنگے) ماڈلز سوچنے اور منصوبہ بندی والے حصے میں بہترین ہیں۔ سستے ماڈلز سیدھے سادے "بس یہ ہدایات کرو" والے حصے کو بالکل ٹھیک سنبھال لیتے ہیں۔
یہ عملی طور پر کیسے کریں:
- Claude Code کو plan mode میں کھولیں۔ بیان کریں کہ آپ کیا چاہتے ہیں۔ اسے ایک تفصیلی منصوبہ بنانے دیں۔
- منصوبہ ایک فائل میں محفوظ کریں (جیسے
docs/plans/my-feature.md)۔ - OpenCode کو ایک الگ worktree میں، ایک سستا اے آئی ماڈل استعمال کرتے ہوئے کھولیں۔ اسے بتائیں:
read docs/plans/my-feature.md and implement it۔ - OpenCode منصوبے کی پیروی کرتا ہے: فائلیں بدلتا ہے، ٹیسٹ چلاتا ہے، فارمیٹنگ ٹھیک کرتا ہے۔
- (اختیاری) تبدیلیوں کو merge کرنے سے پہلے ان کا جائزہ لینے کے لیے Claude Code پر واپس جائیں۔
منصوبہ فائل معاہدہ ہے۔ یہ سیشن کے ضائع ہونے سے بچ جاتی ہے، آرکیٹیکچرل فیصلے سمیٹتی ہے، اور سستے سیشن کو مہنگی سوچ دوبارہ کیے بغیر کام کرنے دیتی ہے۔ یہی طریقہ اکثر زیادہ تر لاگت کی بچت دے دیتا ہے جس کی ٹیمیں "سستے ماڈل پر بدلنے" سے امید رکھتی ہیں، frontier-ماڈل منصوبہ بندی کا معیار کھوئے بغیر۔
Pattern 2: ماڈلوں کے آر پار جائزہ
AI Prompting کورس میں، آپ نے سیکھا کہ ایک دوسرے اے آئی سے پہلے اے آئی کے کام کی جانچ کرانا زیادہ غلطیاں پکڑتا ہے۔ یہاں، ہم کوڈنگ ٹولز کے ساتھ یہی کرتے ہیں۔
یہ کیوں کام کرتا ہے: جس اے آئی نے کوڈ لکھا وہ اس کا جائزہ لینے کے لیے سب سے بدتر ہے۔ اس میں وہی اندھے دھبے ہیں جنہوں نے سب سے پہلے غلطیاں پیدا کیں۔ ایک مختلف اے آئی ماڈل (کسی مختلف کمپنی کا، مختلف ڈیٹا پر تربیت یافتہ) وہ چیزیں دیکھے گا جو پہلے نے چھوڑ دیں۔
یہ کیسے کریں:
- ٹول A (کوئی بھی ماڈل) اپنے worktree میں کوڈ لکھتا ہے۔
- ٹول B (ایک مختلف اے آئی ماڈل) تبدیلیاں پڑھتا ہے اور
docs/reviews/my-feature.mdپر ایک جائزہ لکھتا ہے۔ یہ کوئی کوڈ نہیں بدلتا؛ یہ صرف رائے لکھتا ہے۔ - ٹول A جائزہ پڑھتا ہے اور طے کرتا ہے کہ کون سی تجاویز پر عمل کرنا ہے۔
یہ جتنا لگتا ہے اس سے زیادہ کارآمد ہے۔ ایک سستا اے آئی ماڈل بھی جائزہ کار کے طور پر حقیقی مسائل پکڑتا ہے: چھوٹی ہوئی کنارے والی صورتیں، سیکیورٹی کے مسائل، الجھے ہوئے نام، غیر استعمال شدہ کوڈ۔ ایک جائزہ چلانے کی قیمت کم ہے؛ شائع کرنے کے بعد کوئی بگ ڈھونڈنے کی قیمت کہیں زیادہ۔
بہترین نتائج اے آئی فراہم کنندگان کو ملانے سے آتے ہیں۔ Claude کا اپنے ہی کوڈ کا جائزہ لینا وہی چیزیں چھوڑ دے گا۔ مگر GPT کا Claude کے کوڈ کا جائزہ لینا (یا اس کے برعکس) مختلف اقسام کی غلطیاں پکڑتا ہے۔ لکھنے اور جائزے دونوں کے لیے ایک ہی اے آئی استعمال کرنا کسی جائزے کے نہ ہونے سے بہتر ہے، مگر مختلف اے آئی استعمال کرنا کہیں بہتر ہے۔
کیا ایک ہی ٹول پر رہتا ہے
آپ کو ہمیشہ دو ٹولز کی ضرورت نہیں۔ دونوں کو اکٹھے استعمال کرنے میں اضافی ترتیب لگتی ہے: دو ترتیبیں، دو اجازت کی فہرستیں، دو اطلاع کی ترتیبیں۔ چھوٹے کاموں کے لیے (ایک بگ ٹھیک کرنا، ایک فنکشن لکھنا، ایک فائل صاف کرنا)، ایک سیشن میں ایک ٹول تیز اور سادہ ہے۔
دو ٹولز اکٹھے کب استعمال کریں:
- کام اتنا بڑا ہو کہ منصوبہ بندی اور تعمیر واضح طور پر الگ مراحل ہوں
- آپ تعمیر والے حصے کے لیے ایک سستا ماڈل استعمال کر کے پیسے بچانا چاہتے ہوں
- آپ merge کرنے سے پہلے کسی مختلف اے آئی سے ایک آزاد جائزہ چاہتے ہوں
باقی ہر چیز کے لیے، ایک ٹول کافی ہے۔ جو مہارتیں آپ نے Parts 1-7 میں سیکھیں وہی آپ زیادہ تر وقت استعمال کریں گے۔
اس میں واقعی اچھا کیسے بنیں
یہ مختصر کورس پڑھنا آپ کو ان ٹولز میں اچھا نہیں بناتا۔ انہیں واقعی استعمال کرنا بناتا ہے۔ سیکھنے کا عمل ایسا دکھتا ہے:
آپ ہر چیز دستی طور پر کرنے سے شروع کریں گے۔ آپ مسائل سے ٹکرائیں گے۔ وہی مسائل سیکھنے کا طریقہ ہیں۔ ہر مسئلہ اس کورس کے پندرہ تصورات میں سے کسی ایک کی طرف واپس اشارہ کرتا ہے:
| جو مسئلہ آپ کو پیش آیا | کیا ٹھیک کرنا ہے |
|---|---|
| "اے آئی میرے پروجیکٹ کے قواعد بار بار کیوں بھولتا ہے؟" | آپ کی قواعد کی فائل غائب یا بہت لمبی ہے (تصور 8) |
| "اے آئی نے ابھی ایک اہم فولڈر کیوں حذف کر دیا؟" | آپ کی اجازتیں کافی سخت نہیں (تصور 3) |
| "ایک گھنٹہ چیٹ کے بعد اے آئی بدتر کیوں ہو رہا ہے؟" | گفتگو بہت لمبی ہے؛ /compact استعمال کریں (تصور 6) |
| "سادہ کام پر میرا بل (یا استعمال کی حد) کیوں پھٹ رہا ہے؟" | آپ ہر چیز پر ایک مہنگا ماڈل چلا رہے ہیں؛ ماڈل کو کام سے ملائیں (تصور 4) |
| "میں ہر ہفتے ایک ہی ہدایات کیوں ٹائپ کر رہا ہوں؟" | ان ہدایات کو ایک skill میں بدلیں (تصور 9) |
| "جب اے آئی نے محفوظ کرنے کی کوشش کی تو سب کچھ کیوں ٹوٹ گیا؟" | آپ کو اسے پکڑنے کے لیے ایک hook یا plugin چاہیے (تصور 10) |
| "فائلوں میں تلاش میری گفتگو کیوں بھر دیتی ہے؟" | تلاش الگ کرنے کے لیے ایک subagent استعمال کریں (تصور 11) |
ہر مسئلہ تب ٹھیک کریں جب آپ کو پیش آئے، اس سے پہلے نہیں۔ ایک چھوٹی قواعد کی فائل سے شروع کریں۔ جب کچھ غلط ہو تو ایک سطر شامل کریں۔ جب آپ غور کریں کہ آپ خود کو دہرا رہے ہیں تو اپنی پہلی skill بنائیں۔ جب کوئی ایسی چیز ٹوٹے جو خود بخود پکڑی جانی چاہیے تھی تو ایک hook شامل کریں۔ اپنی ترتیب کو حقیقی تجربے سے قدرتی طور پر بڑھنے دیں۔
اصل مہارت پندرہ تصورات یاد کرنا نہیں۔ یہ پہچاننا ہے کہ جب کوئی مسئلہ ظاہر ہو تو کون سا تصور استعمال کرنا ہے۔ یہ صرف مشق سے آتا ہے۔
آپ کی مہارتیں ٹولز کے درمیان منتقل ہوتی ہیں۔ ایک بار جب آپ ایک ٹول میں اس طرح سوچنا سیکھ لیں، تو دوسرے پر بدلنا آسان ہے۔ بٹن اور سیٹنگز مختلف ہیں، مگر سوچ ایک ہی ہے۔ ایک ٹول چنیں، ایک پروجیکٹ سے شروع کریں، plan mode استعمال کریں، اور اپنی گفتگوئیں مختصر رکھیں۔ باقی سب کچھ یہیں سے بنتا ہے۔
فوری حوالہ
15 تصورات، ہر ایک ایک سطر میں
- یہ ٹولز کام کرتے ہیں، صرف سوالوں کا جواب نہیں دیتے۔ (یہ کیا ہیں) ہدایات دیں، سوال نہیں۔
- Plan mode۔ (خصوصیت) اے آئی سے اس کا منصوبہ دکھوائیں اس سے پہلے کہ وہ کچھ بدلے۔ (
Shift+TabClaude Code میں،TabOpenCode میں۔) - اجازتیں۔ (سیٹنگز) اے آئی ہر کام سے پہلے پوچھتا ہے۔ دستی طور پر منظوری دینے سے شروع کریں۔ محفوظ کاموں کو بعد میں خودکار-منظور کریں۔
- ماڈل کو کام سے ملائیں۔ (ماڈل کا انتخاب) منصوبہ بندی اور استدلال کے لیے مضبوط ماڈل؛ عمل درآمد کے لیے سستا یا مفت ماڈل۔
/model(Claude Code) یا/models(OpenCode) سے بدلیں۔ - گفتگوئیں لمبی ہونے کے ساتھ بدتر ہوتی ہیں۔ (سیاق) اے آئی تفصیلات کا نشان کھوتا ہے اور زیادہ لاگت لیتا ہے۔ گفتگوئیں مرکوز رکھیں۔
/clear= نئے سرے سے شروع۔/compact= وہی کام، کم کوڑا۔ (کمانڈز) انہیں آپس میں نہ ملائیں۔- پرانی گفتگوئیں دوبارہ شروع کریں۔ (کمانڈز) کل واپس آئیں اور وہیں سے جاری رکھیں جہاں آپ رکے۔ منصوبے بیک اپ کے طور پر فائلوں میں محفوظ کریں۔
- قواعد کی فائل۔ (
CLAUDE.md/AGENTS.md) اسے مختصر رکھیں۔ صرف وہی لکھیں جو اے آئی آپ کی فائلیں دیکھ کر نہیں سمجھ سکتا۔ - کمانڈز اور skills۔ (
.claude/skills/) ایک محفوظ-پرامپٹ نظام: آپ اسے/nameسے بلاتے ہیں، یا ماڈل اسے اس کی تفصیل سے خود بخود بلاتا ہے۔ - Hooks / Plugins۔ (
settings.json/.opencode/plugins/) قواعد جو ہر بار چلتے ہیں، چاہے کچھ بھی ہو۔ اے آئی انہیں چھوڑ نہیں سکتا۔ - Subagents۔ (
.claude/agents/) ایک مددگار بھیجیں کہ بھاری پڑھائی کرے تاکہ آپ کی اصل گفتگو صاف رہے۔ - MCP۔ (بیرونی کنکشن) اے آئی کو آن لائن خدمات (Slack، GitHub، ڈیٹابیسز) سے جوڑتا ہے۔ صرف وہی شامل کریں جس کی آپ کو واقعی ضرورت ہو۔
- کہاں چلائیں۔ (ٹرمینل / IDE / ویب) ٹرمینل یا کسی IDE plugin میں شروع کریں تاکہ آپ دیکھ سکیں کہ اے آئی کیا کر رہا ہے۔
- ذاتی لائبریری۔ (
~/.claude//~/.config/opencode/) اپنے قواعد اور skills پروجیکٹس کے درمیان بانٹیں۔ اسے حقیقی مسائل سے آہستہ آہستہ بنائیں۔ - یادداشت۔ (
notes/فولڈر) زیادہ تر لوگوں کے لیے گفتگوئیں دوبارہ شروع کرنا اور ایک اچھی قواعد کی فائل کافی ہے۔ مزید چاہیے تو ایکnotes/فولڈر شامل کریں۔
کمانڈ فوری-حوالہ
| چاہتے ہیں... | Claude Code | OpenCode |
|---|---|---|
| پروجیکٹ قواعد کی فائل شروع کرنا | /init | /init |
| Plan mode میں داخل ہونا | Shift+Tab (دو بار) | Tab (Plan ایجنٹ تک گھومیں) |
| ماڈل بدلنا | /model | /models |
| گفتگو مٹا کر نئے سرے سے شروع کرنا | /clear | /new (یا /clear) |
| خلاصہ بنا کر جاری رکھنا | /compact | /compact (یا /summarize) |
| محفوظ سیشن دوبارہ شروع کرنا | claude --resume | /sessions (یا /resume) |
| کسی پچھلے پیغام پر واپس جانا | Esc Esc (یا /rewind) | /undo |
| ماڈل کی فائل تبدیلیاں واپس کرنا | Esc Esc (چیک پوائنٹنگ) | /undo (git درکار) |
| bash-کمانڈ کی فائل تبدیلیاں واپس کرنا | (ٹریک نہیں ہوتیں) | /undo (پورے-ٹری کا diff) |
دوبارہ کرنا (آخری /undo پلٹنا) | (بنڈل نہیں) | /redo |
| گفتگو برآمد یا شیئر کرنا | /export (ٹرانسکرپٹ محفوظ کرتا ہے) | /share (عوامی link) یا /export |
فائل کے مقام کا فوری-حوالہ
| کیا | Claude Code | OpenCode |
|---|---|---|
| پروجیکٹ قواعد | CLAUDE.md | AGENTS.md (CLAUDE.md کو متبادل کے طور پر بھی پڑھتا ہے) |
| پروجیکٹ اجازتیں | .claude/settings.json | opencode.json |
| پروجیکٹ کمانڈز | .claude/commands/*.md | .opencode/commands/*.md |
| پروجیکٹ skills | .claude/skills/<name>/SKILL.md | .opencode/skills/<name>/SKILL.md (.claude/skills/ بھی پڑھتا ہے) |
| پروجیکٹ hooks/plugins | .claude/settings.json (hooks بلاک) | .opencode/plugins/*.{js,ts} |
| پروجیکٹ subagents | .claude/agents/*.md | .opencode/agents/*.md |
| ذاتی/عالمی قواعد | ~/.claude/CLAUDE.md | ~/.config/opencode/AGENTS.md |
| ذاتی کمانڈز/skills/agents | ~/.claude/{commands,skills,agents}/ | ~/.config/opencode/{commands,skills,agents}/ |
| MCP servers | .mcp.json (پروجیکٹ) / ~/.claude.json (ذاتی) | opencode.json (mcp بلاک) |
Extension قسم کا فیصلہ درخت
Need to do the same thing repeatedly, manually?
→ Slash command (CC) / Custom command (OC)
Want the model to apply expertise automatically when a task matches?
→ Skill
Need something to happen every single time, no model judgment?
→ Hook (CC) / Plugin (OC)
Need a chunk of work done in isolation so it doesn't pollute main context?
→ Subagent
جب کچھ غلط لگے
Model apologizing without progress, rewriting the same code,
hallucinating variables, contradicting earlier constraints?
→ Context is poisoned. Stop typing. Run /compact or /clear.
Don't try to fix it with another prompt.
فلیش کارڈ مطالعہ معاون
مختصر امتحان: 15 تصورات پر 52 سوالات
جو آپ نے سیکھا اسے آزمائیں۔ ہر نشست 18 سوالات کا ایک تازہ مجموعہ دکھاتی ہے، تو ہر بار دوبارہ لینے پر آپ کو نئے سوالات ملتے ہیں۔