لوپ انجینئرنگ: ایک فوری کورس

15 تصورات · ایجنٹک کوڈنگ سے لے کر خود کو prompt کرنے والے سسٹمز تک

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

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

یہی لوپ انجینئرنگ ہے۔ قیمتی مہارت اس prompt سے جو آپ لکھتے ہیں، اس لوپ کی طرف منتقل ہو جاتی ہے جو آپ ڈیزائن کرتے ہیں۔ یہ کورس آپ کو سکھاتا ہے کہ لوپ کن چیزوں سے بنتا ہے، اور اسے Claude Code اور OpenCode دونوں میں کیسے بنائیں — جو ایک ہی منزل تک دو بالکل مختلف راستوں سے پہنچتے ہیں۔

پیشگی شرط: Claude Code اور OpenCode: ایک فوری کورس۔ اس کورس نے آپ کو plan mode، context management، rules file، skills، subagents، اور MCP سکھائے۔ یہ کورس ان سب کو فرض کرتا ہے۔ اگر یہ الفاظ آپ کے لیے نئے ہیں، تو پہلے وہ کورس کریں۔ لوپ انجینئرنگ بالکل اسی کے اوپر بنی ہے۔ بہتر یہ ہے کہ آپ نے Spec-Driven Development بھی کر رکھی ہو: کسی لوپ کی رکنے کی شرط دراصل ایک spec ہی ہے، اور وہی کورس ہے جہاں آپ نے اسے لکھنا سیکھا — اس کے بغیر بھی آپ ساتھ چل سکتے ہیں، مگر آپ کے لوپ صرف اتنے ہی اچھے ہوں گے جتنی اچھی شرطیں آپ بیان کر سکتے ہیں۔

یہاں نئے ہیں؟ جو آپ کو پہلے سے معلوم ہونا چاہیے اس کا 2 منٹ کا خلاصہ

• Plan mode — ایجنٹ آپ کی فائلیں پڑھتا ہے اور کچھ بھی بدلنے سے پہلے ایک منصوبہ پیش کرتا ہے؛ آپ پہلے منظوری دیتے ہیں۔
• Rules file (CLAUDE.md / AGENTS.md) — مختصر، مستقل پروجیکٹ نوٹس جو ایجنٹ ہر سیشن کے آغاز میں پڑھتا ہے۔
• Skills (SKILL.md) — ایک محفوظ شدہ، دوبارہ قابلِ استعمال ہدایت جو ایجنٹ صرف اسی وقت لوڈ کرتا ہے جب کام اس سے میل کھائے۔
• Subagents — اپنی الگ context window والا ایک علیحدہ مددگار جو کوئی کام کرتا ہے اور صرف نتیجہ واپس کرتا ہے۔
• Connectors / MCP — کسی ایجنٹ کو باہر کے ٹولز سے جوڑنے کا معیاری طریقہ: GitHub، Slack، کوئی database۔
• Context management — گفتگو کو ہلکا رکھیں؛ جیسے جیسے یہ بھرتی ہے، ماڈل کمزور ہوتا ہے اور لاگت بڑھتی ہے۔

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

یہ کہاں سے آیا

2026 کے وسط میں، انہی لوگوں نے جو یہ ٹولز بناتے ہیں، صاف صاف کہہ دیا۔ Boris Cherny، جنہوں نے Claude Code بنایا، اس نے یوں کہا: "میں اب Claude کو prompt نہیں کرتا۔ میرے پاس لوپ چل رہے ہیں جو Claude کو prompt کرتے ہیں... میرا کام لوپ لکھنا ہے۔" Peter Steinberger (OpenClaw) نے کہا "آپ کو ایسے لوپ ڈیزائن کرنے چاہئیں جو آپ کے ایجنٹس کو prompt کریں۔" پھر Addy Osmani نے اس pattern کو نام دیا اور اس کے حصے گنوائے۔ ان میں سے کوئی بھی یہ نہیں کہتا کہ کام آسان ہو گیا۔ وہ کہتے ہیں کہ قیمتی مہارت منتقل ہو گئی۔ یہی وہ خیال ہے جس پر یہ پورا کورس بنا ہے۔ (اس کورس کے ہر اقتباس اور دعوے کا حوالہ آخر میں Sources & further reading میں موجود ہے۔)

ذہنی تبدیلی، ایک تصویر میں​

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

جون 2026 تک کی صورتحال۔ دونوں ٹولز تیزی سے بدلتے ہیں، اور Claude Code کی کئی لوپ خصوصیات research preview میں ہیں۔ کسی بھی سیشن سے پہلے claude update یا opencode upgrade چلائیں۔ کسی حد یا flag پر بھروسہ کرنے سے پہلے live docs (code.claude.com/docs، opencode.ai/docs) دیکھ لیں۔

پہلے، لوپ کہاں چل سکتے ہیں اس بارے میں ایک ایماندارانہ بات

ایک حقیقی لوپ بے توجہی سے چلتا ہے: یہ خود سے، اپنے طور پر، آپ کی غیر موجودگی میں خود کو prompt کرتا ہے۔ یہ سادہ claude.ai chat box میں نہیں ہو سکتا، جو ہمیشہ آپ کا انتظار کرتا ہے — chat میں آپ ہی schedule ہیں۔ ایک سچا لوپ چلانے کے لیے آپ کو ایسا ٹول چاہیے جو خود ہی timer پر عمل کر سکے: Claude Code، OpenCode، یا Cowork (دیکھیں Cowork فوری کورس)۔ ان میں سے زیادہ تر paid خصوصیات ہیں، اور کئی آج research previews ہیں۔ آپ کسی بھی جگہ لوپ سیکھ اور ڈیزائن کر سکتے ہیں۔ بے توجہی سے کوئی لوپ چلانے کے لیے آپ کو ان میں سے کوئی ایک ٹول چاہیے۔ یہ کورس دونوں کوڈنگ والے ٹولز دکھاتا ہے۔

"مگر میں نے پوری Spec-Driven course claude.ai میں کی — کیا میں وہاں لوپ بھی چلا سکتا ہوں؟"

اچھا سوال ہے، کیونکہ "claude.ai" دراصل دو چیزیں ہیں۔ مختصر جواب: chat box لوپ نہیں چلا سکتا، مگر Claude Code — جو اسی claude.ai اکاؤنٹ میں رہتا ہے — چلا سکتا ہے۔

• Chat گفتگو ہر turn پر آپ کا انتظار کرتی ہے اور اس کے پاس کسی schedule یا event پر فائر ہونے کا کوئی طریقہ نہیں۔ آپ اسے بار بار ہاتھ سے re-prompt کر سکتے ہیں، مگر تب آپ ہی دھڑکن ہیں — وہی کام جو لوپ ختم کر دیتا ہے۔
• Claude Code اسی login سے قابلِ رسائی ہے۔ اس کے cloud Routines (جو claude.ai/code/routines پر بنتے ہیں) Anthropic کے servers پر چلتے ہیں، چاہے آپ کا laptop بند ہو، اور مقامی طور پر کچھ بھی install کیے بغیر — تو اس معنی میں آپ "claude.ai سے" ایک حقیقی، بے توجہی سے چلنے والا لوپ کھڑا کر سکتے ہیں۔ اس کے لیے paid plan درکار ہے اور یہ آج research preview ہے۔
• OpenCode یہی کام آپ کے اپنے scheduler (cron، GitHub Actions) کے ساتھ کرتا ہے۔

تو chat وہ جگہ ہے جہاں آپ لوپ ڈیزائن اور مشق کرتے ہیں — skill کا مسودہ بناتے ہیں، reviewer prompt لکھتے ہیں، رکنے کی شرط طے کرتے ہیں، ایک beat ہاتھ سے چلاتے ہیں — اور Claude Code یا OpenCode وہ جگہ ہے جہاں آپ اسے چلاتے ہیں۔ یہ منتقلی Spec-Driven Development کے بعد قدرتی اگلا قدم ہے۔

پڑھتے ہوئے آزمائیں

یہاں سے آگے، تقریباً ہر تصور وہ ہے جسے آپ کسی حقیقی سیشن میں چلا سکتے ہیں، صرف پڑھ نہیں سکتے۔ اس صفحے کے ساتھ ایک terminal کھلا رکھیں (claude یا opencode) اور جیسے جیسے ہر خیال تک پہنچیں اسے آزمائیں۔ کسی چھوٹے، پھینک دینے والے git repo سے شروع کریں تاکہ کوئی لوپ آپ کی پسندیدہ کسی چیز کو نقصان نہ پہنچا سکے۔

یہ کورس کیا کیا سکھاتا ہے​

حصہ	موضوع	آپ کیا سیکھتے ہیں
1	تبدیلی	لوپ کیا ہے، اس کے چھ حصے، اور اسے بنانے کے دو راستے
2	دھڑکن	کسی چیز کو خود سے چلانا: in-session، run-until-done، scheduled، event-driven
3	جسم	علیحدگی، علم، عمل، اور maker–checker تقسیم
4	ریڑھ کی ہڈی	وہ state جو runs کے درمیان زندہ رہتی ہے — وہ ایک حصہ جسے لوگ بھول جاتے ہیں
5	ایک لوپ، دو بار	ایک مکمل morning-triage-to-PR لوپ، حقیقی فائلوں کے ساتھ، دونوں ٹولز میں بنایا گیا
6	انجینئر بنے رہنا	token لاگت، کام جانچنا، اور وہ جال جو لوپ بہتر ہونے پر بڑھتے ہیں
مشق	مشقی projects	پانچ لوپ، آسان سے مشکل، جو آپ خود بناتے ہیں

کر کے سیکھتے ہیں؟ پہلے حصہ 5 پڑھیں تاکہ ایک پورا لوپ شروع سے آخر تک دیکھ لیں، پھر حصوں کے لیے واپس آئیں۔ ایک بار تصورات سمجھ میں آ جائیں، تو مشقی projects آپ کو پانچ لوپ دیتے ہیں جنہیں آپ خود بناتے ہیں۔

اسے پورا پڑھنے کے لیے تقریباً دو گھنٹے رکھیں۔ حصہ 5 اور مشقی projects بنانے میں زیادہ وقت لگتا ہے — اور یہی مقصد ہے: آپ لوپ بنا رہے ہیں، انہیں سرسری پڑھ نہیں رہے۔

کیا یاد رکھیں، اور کیا دیکھ لیں

اس کورس میں دو پرتیں چلتی ہیں، اور وہ بہت مختلف انداز میں پرانی ہوتی ہیں۔ پہلی کو ذہن میں بٹھائیں؛ دوسری کو دیکھ لیں۔

• پائیدار پرت۔ لوپ کی ساخت (ایک دھڑکن، چار کام کرنے والے حصے، اور ایک ریڑھ کی ہڈی)، maker–checker تقسیم، اور وہ دو سرے جنہیں لوپ کبھی خودکار نہیں کر سکتا: ارادہ (یہ اتنی درستی سے بتانا کہ آپ کیا چاہتے ہیں کہ نتیجہ جانچا جا سکے) اور جوابدہی (جو شِپ ہوتا ہے اس کی ذمہ داری اٹھانا)۔ یہی مہارت ہے۔ نیچے دی گئی ہر کمانڈ بدل جانے کے بعد بھی یہ درست رہتی ہے۔
• مشینی پرت۔ ہر flag، path، model ID، اور command کا نام۔ یہ ٹولز ہر ہفتے updates شِپ کرتے ہیں اور یہاں کئی خصوصیات research previews ہیں، تو ہر مخصوص کمانڈ کو live docs کی طرف اشارہ سمجھیں، یاد رکھنے والی حقیقت نہیں۔ جہاں یہ کورس اور موجودہ docs اختلاف کریں، docs جیتتے ہیں۔

چھ حصوں والی ساخت یاد رکھیں اور ہر keystroke بھول جائیں، تو آپ نے لوپ انجینئرنگ سیکھ لی۔ keystrokes رٹ لیں اور ساخت سے چُوک جائیں، تو آپ نے اس مہینے کی CLI سیکھ لی۔

---

📚 تدریسی معاون​

پوری Slideshow کھولیں

پوری Presentation دیکھیں — لوپ انجینئرنگ: ایک فوری کورس

---

حصہ 1: تبدیلی​

1. prompt کرنے سے لوپ کرنے تک​

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

ایک لوپ آپ، یعنی operator کی جگہ ایک سسٹم لے آتا ہے۔ سسٹم کام ڈھونڈتا ہے، اسے بانٹتا ہے، جانچتا ہے، لکھ لیتا ہے کہ اس نے کیا کیا، اور فیصلہ کرتا ہے کہ آگے کیا ہے۔ یہ ایجنٹ کو prompt کرتا ہے، تاکہ آپ کو نہ کرنا پڑے۔

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

فرق "ایک بڑا prompt" نہیں ہے۔ یہ کام کی ایک مختلف ساخت ہے:

prompt کرنا (جو آپ جانتے ہیں)	لوپ کرنا (جو یہ کورس بڑھاتا ہے)
ہر turn آپ شروع کرتے ہیں	ہر turn کوئی schedule یا event شروع کرتا ہے
آپ output پڑھتے ہیں اور طے کرتے ہیں آگے کیا ہے	ایک checker output جانچتا ہے؛ لوپ طے کرتا ہے آگے کیا ہے
جیسے ہی آپ ٹائپ کرنا چھوڑیں، رک جاتا ہے	آپ کے سونے کے دوران بھی چلتا رہتا ہے
ایک کام، ایک سیشن، آپ کی پوری توجہ	کئی چھوٹے runs، زیادہ تر بے توجہ، آپ کی توجہ صرف gate پر

یہ جادو نہیں ہے، اور یہ "لگا کر بھول جاؤ" بھی نہیں ہے۔ خود سے چلنے والا لوپ، خود سے غلطیاں کرنے والا لوپ بھی ہے۔ اس کورس کی ہر چیز اسی لیے موجود ہے تاکہ آپ ایسا لوپ بنا سکیں جس پر آپ واقعی بھروسہ کر کے اسے اپنے بغیر چلا سکیں۔ یہ prompt کرنے سے مشکل تر ہے، آسان نہیں۔ انعام ہے leverage: ایک اچھا لوپ آپ کے لیے یہ کام بار بار کرتا ہے، وہ کام جو ورنہ آپ کو ہر بار ہاتھ سے شروع کرنا پڑتا۔

2. لوپ کن چیزوں سے بنتا ہے​

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

1. Heartbeat — ایک schedule (یا event) جو لوپ شروع کرتا ہے۔ اس کے بغیر آپ کے پاس ایک ہی run ہے، لوپ نہیں۔
2. Worktree — علیحدگی، تاکہ بیک وقت کام کرتے ہوئے دو ایجنٹس ایک دوسرے کی فائلوں پر نہ لکھیں۔
3. Skill — آپ کا پروجیکٹ علم ایک بار لکھا گیا، تاکہ ہر run صفر سے شروع نہ ہو۔
4. Sub-agents — maker–checker تقسیم: جو ایجنٹ کوڈ لکھتا ہے وہ اسے جانچنے والا ایجنٹ نہیں ہوتا۔
5. Connector (MCP) — تاکہ لوپ آپ کے حقیقی ٹولز میں عمل کر سکے (کوئی PR کھولے، ticket اپڈیٹ کرے)، صرف تجویز نہ کرے۔

اور چھٹا، جسے نوآموز چھوڑ دیتے ہیں:

6. State / Memory — ریڑھ کی ہڈی۔ disk پر ایک فائل (یا Linear جیسا board) جو رکھتی ہے کہ کیا ہو چکا اور آگے کیا ہے۔ ماڈل runs کے درمیان سب کچھ بھول جاتا ہے۔ ریڑھ کی ہڈی وہ طریقہ ہے جس سے آج کا run جانتا ہے کہ کل کے run نے کیا کیا۔ کوئی ریڑھ کی ہڈی نہیں، تو کوئی لوپ نہیں — بس وہی پہلا قدم، ہمیشہ کے لیے دہراتا ہوا۔

اس کورس کا باقی حصہ فی حصہ ایک سیکشن ہے، پھر ایک مکمل مثال جو انہیں جوڑتی ہے۔

3. دو راستے: حصے-شامل-کرنے والا بمقابلہ نیچے-والی-پرت​

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

Claude Code لوپ کے حصے پروڈکٹ کے اندر شامل کر کے دیتا ہے۔ دھڑکن (/loop، /schedule، cloud Routines)، built-in checker کے ساتھ run-until-done (/goal)، علیحدگی (--worktree)، event کی آمد (Channels) — یہ سب اب built-in commands ہیں۔ ایک سال پہلے یہ سب حاصل کرنے کے لیے آپ کو shell scripts کا ایک ڈھیر لکھنا اور سنبھالنا پڑتا۔ آج آپ زیادہ تر بس اسے سیٹ کر دیتے ہیں۔

سب سے اہم ہے Routines: cloud automations جو Anthropic کے servers پر چلتی ہیں تب بھی جب آپ کا laptop بند ہو، اور انہیں کوئی schedule، API call، یا GitHub event شروع کرتا ہے۔ اس آسانی کی قیمت ہے فی اکاؤنٹ روزانہ run caps (اپنی موجودہ حد کسی طے شدہ نمبر پر بھروسہ کرنے کے بجائے Routines usage UI میں دیکھیں)، اور یہ کہ Routines ایک research preview ہیں جو ابھی بدل سکتی ہیں۔

OpenCode آپ کو نیچے والی پرت دیتا ہے۔ کوئی built-in cloud scheduler نہیں۔ اس کے بجائے OpenCode وہ worker ہے جسے آپ بلاتے ہیں، اور دھڑکن آپ لاتے ہیں — آپریٹنگ سسٹم سے یا CI سے۔

اہم کمانڈ ہے opencode run "<prompt>"۔ یہ chat screen کے بغیر ایک prompt چلاتی ہے، نتیجہ چھاپتی ہے، اور باہر نکل جاتی ہے۔ وہی ایک کمانڈ لوپ کی ایک دھڑکن ہے۔ آپ اسے لوپ میں اس وقت بدلتے ہیں جب اسے کسی ایسی چیز میں لپیٹتے ہیں جو timer پر فائر ہو: cron یا launchd (macOS اور Linux)، Task Scheduler (Windows)، یا schedule trigger کے ساتھ GitHub Actions۔ یہ زیادہ wiring ہے، مگر آپ کو پورا کنٹرول ملتا ہے، یہ انہی مشینوں پر چلتا ہے جو آپ کے پاس پہلے سے ہیں، اور اسے کسی vendor cloud کی ضرورت نہیں۔

مہارت لوپ ہے، keybind نہیں

غور کریں کہ دونوں tabs انہی پانچ حصوں کو بیان کرتے ہیں۔ دھڑکن دھڑکن ہی ہے، چاہے وہ کوئی managed Routine ہو یا cron میں ایک لائن۔ maker–checker تقسیم وہی خیال ہے، چاہے /goal اسے grade کرے یا دوسرا opencode run۔ لوپ کی ساخت ایک بار سیکھ لیں، یہ منتقل ہو جاتی ہے۔ اسی لیے ہم دونوں سکھاتے ہیں۔

ہم کہاں جا رہے ہیں (پورا لوپ، جلدی)​

حصوں سے پہلے، یہ رہی منزل۔ وہ لوپ جو آپ حصہ 5 میں بنائیں گے، چھ سادہ قدم ہیں:

every weekday at 9am:                 # 1. Heartbeat
  read progress.md                    # 6. Spine (memory)
  find overnight CI failures + issues # what to work on
  for each one:
    draft a fix in its own checkout   # 2. Worktree
    using the project's triage skill  # 3. Skill
    have a separate reviewer grade it # 4. Sub-agents (maker/checker)
    if PASS: open a PR via GitHub      # 5. Connector (MCP)
    if risky: write it to progress.md and leave it for a human
  update progress.md                  # 6. Spine again

یہ تصویر ذہن میں رکھیں۔ حصہ 2–4 کا ہر تصور اس کی ایک لائن ہے۔

خود کو جانچیں

ایک لوپ ہر صبح چلتا ہے، مگر ہر run نئے سرے سے شروع ہوتا ہے اور کبھی یاد نہیں رکھتا کہ کل اس نے کیا کیا۔ چھ حصوں میں سے کون سا غائب ہے — اور یہ لوپ کو کیوں توڑتا ہے؟

جواب دکھائیں

ریڑھ کی ہڈی (state / memory)۔ ماڈل runs کے درمیان سب کچھ بھول جاتا ہے، تو disk پر کسی state file کے بغیر لوپ بس اپنا پہلا قدم ہمیشہ دہراتا رہتا ہے، کل کے کام پر تعمیر کرنے کے بجائے۔

---

حصہ 2: دھڑکن​

دھڑکن وہ ہے جو ایک run کو لوپ بنا دیتی ہے۔ اس کی چار قسمیں ہیں، "اسی سیشن میں رہتی ہے" سے لے کر "آپ کے بالکل بغیر چلتی ہے" تک۔ انہیں ترتیب سے سیکھیں — زیادہ تر حقیقی لوپ آخری دو استعمال کرتے ہیں۔

4. In-session loops (جب آپ دیکھتے رہیں تب دہرائیں)​

سب سے سادہ دھڑکن: ایک prompt کو timer پر دوبارہ چلائیں جب تک سیشن کھلا ہے۔ "اسے ختم ہونے تک دیکھتے رہو" کے لیے اچھا ہے — کوئی deploy، کوئی لمبا test run، کوئی CI job۔

bundled /loop skill استعمال کریں۔ اسے ایک interval اور ایک prompt دیں:

/loop 5m check if the deployment finished and tell me what happened

Claude interval کو ایک schedule میں بدلتا ہے، کام کو ایک ID دیتا ہے، اور جب تک سیشن کھلا رہے ہر 5 منٹ بعد prompt چلاتا ہے۔ جب آپ کا کام ہو جائے، اسے cancel کریں اور آگے بڑھیں۔

جاننے کے لیے ایک حد: /loop جان بوجھ کر سیشن کے اندر رہتا ہے۔ terminal بند کریں، یا laptop کو سونے دیں، تو یہ رک جاتا ہے۔ یہ ایک safety خصوصیت ہے، bug نہیں — ایک ہلکا پھلکا in-session لوپ سیشن سے زیادہ زندہ نہیں رہنا چاہیے۔ کسی ایسی چیز کے لیے جو چلتی رہے، scheduled task یا Routine استعمال کریں (تصور 6)۔

OpenCode میں کوئی /loop کمانڈ نہیں۔ آپ timer خود shell سے بناتے ہیں۔ چونکہ opencode run ایک prompt کے بعد باہر نکل جاتا ہے، اس لیے sleep والا ایک while لوپ وہی کام کرتا ہے:

while true; do
  opencode run "check if the deployment finished; if it did, say DONE"
  sleep 300   # 5 minutes
done

یہ /loop ہی کا خیال ہے، ایک پرت نیچے: shell دھڑکن ہے، اور opencode run دھڑکن کی ایک ضرب ہے۔ ہر تازہ opencode run کچھ بھی کرنے سے پہلے پورا runtime boot کرتا ہے — config، model، plugins، اور کوئی بھی MCP servers۔ ہر دھڑکن پر یہ آغاز کی لاگت ادا نہ کرنے کے لیے، ایک بار server شروع کریں اور اس سے attach ہوں:

opencode serve --port 4096 &
# then, each beat:
opencode run --attach http://localhost:4096 "check the deploy status"

5. Run-until-done (لوپ طے کرتا ہے کب رکنا ہے)​

طے شدہ timer والا لوپ جان بوجھ کر سادہ ہے — یہ N بار فائر ہوتا ہے، چاہے کچھ بھی ہو۔ اکثر آپ جو واقعی چاہتے ہیں وہ ہے "اس وقت تک چلتے رہو جب تک یہ سچ نہ ہو جائے۔" یہیں maker–checker خیال پہلی بار سامنے آتا ہے: لوپ کو اس ایجنٹ کو فیصلہ نہیں کرنے دینا چاہیے کہ کام مکمل ہوا یا نہیں، جس نے وہ کام کیا تھا۔

/goal استعمال کریں۔ آپ اسے ایک رکنے کی شرط دیتے ہیں جسے Claude اپنے ہی output میں ثابت کر سکے — کوئی ایسی چیز جو وہ کوئی کمانڈ چلا کر اور نتیجہ سامنے لا کر دکھاتا ہے، جیسے "test/auth کے سارے tests pass ہوں۔" یہ turns کے آر پار کام کرتا رہتا ہے جب تک وہ شرط پوری نہ ہو۔ اہم بات: ہر turn کے بعد ایک علیحدہ، چھوٹا ماڈل (default کے طور پر Haiku) transcript پڑھتا ہے اور فیصلہ کرتا ہے "کیا ہم مکمل کر چکے؟" تو جس ایجنٹ نے کوڈ لکھا وہ اسے grade کرنے والا ایجنٹ نہیں۔ ایک باریک نکتہ جاننے لائق: وہ checker خود commands نہیں چلاتا — وہ اسی کو پرکھتا ہے جو Claude پہلے ہی سامنے لا چکا — تو شرط ایسی ہونی چاہیے جسے Claude کا اپنا output دکھا سکے، نہ کہ کوئی ایسی پوشیدہ بات جو صرف کوئی کمانڈ ظاہر کرے۔

/goal All tests in test/auth pass and `npm run lint` is clean.

یہ edit کرے گا، tests چلائے گا، ناکامیاں پڑھے گا، دوبارہ کوشش کرے گا، اور صرف اسی وقت رکے گا جب checker تصدیق کر دے کہ شرط واقعی پوری ہو گئی — یا جب آپ خود اسے /goal clear سے روک دیں۔ کوئی built-in "N کوششوں کے بعد ہار مان لو" نہیں ہے: اگر آپ کو حد چاہیے، تو اسے شرط میں لکھ دیں (…or stop after 20 turns)۔ ایسی شرطیں لکھیں جنہیں کوئی کمانڈ ثابت کر سکے — "tests pass ہوں اور lint clean ہو،" نہ کہ "auth کوڈ اچھا ہے۔" یہیں Spec-Driven Development والا spec کام آتا ہے: اس کے acceptance criteria پہلے ہی ایسی شرطیں ہیں جنہیں کوئی کمانڈ ثابت کر سکتا ہے، تو ایک اچھا spec آپ کو رکنے کی شرط مفت میں دے دیتا ہے۔

OpenCode میں کوئی /goal نہیں، تو آپ وہی maker–checker stop خود shell اور exit codes سے بناتے ہیں۔ pattern یہ ہے: ایجنٹ کام کرتا ہے، پھر ایک حقیقی کمانڈ (ایجنٹ نہیں) فیصلہ کرتی ہے کہ رکنا ہے یا نہیں۔

for i in $(seq 1 8); do          # cap the tries — never loop forever
  opencode run "Make the tests in test/auth pass and fix any lint errors."
  if npm test -- test/auth && npm run lint; then
    echo "Condition met on try $i"; break
  fi
done

یہاں test runner اور linter ہی checker ہیں — سب سے ایماندار checker جو موجود ہے، کیونکہ کوئی کمانڈ خود کو یہ یقین نہیں دلا سکتی کہ کام ٹھیک ہے۔ زیادہ ذہین جانچ کے لیے، ایک وقف review agent کے ساتھ دوسرا opencode run چلائیں (تصور 11) اور اس سے PASS یا FAIL چھپوائیں۔ کوششیں ہمیشہ محدود رکھیں؛ بغیر حد کے دوبارہ کوشش کرنے والا لوپ ہی وہ طریقہ ہے جس سے token bills قابو سے باہر بڑھتے ہیں۔

لوپ کو ہمیشہ رکنے کا کوئی راستہ دیں

دو stops، ہمیشہ: ایک success condition (کام ہو گیا) اور ایک ceiling (زیادہ سے زیادہ کوششیں، منٹ، یا خرچ)۔ success condition تو ہو مگر ceiling نہ ہو والا لوپ آپ کا پورا token budget ایسا ہدف پانے کی کوشش میں خرچ کر دے گا جسے وہ کبھی پا ہی نہیں سکتا۔

6. بے توجہ schedules (آپ کے سونے کے دوران چلتے ہیں)​

یہ وہ دھڑکن ہے جو لوپ انجینئرنگ کو اہم بناتی ہے: ایک کام جو چاہے آپ کمپیوٹر پر ہوں یا نہ ہوں چلتا ہے۔ "ہر working day صبح 9 بجے، رات بھر کی CI failures چھانٹو۔" "ہر پیر، dependencies جانچو اور محفوظ fixes کے ساتھ ایک PR کھولو۔"

دو قسمیں، اس بنیاد پر کہ آپ کو laptop آن چاہیے یا نہیں:

Cloud Routines (laptop بند ہو سکتا ہے)۔ جدید default۔ ایک Routine claude.ai/code/routines پر، Desktop app میں، یا CLI میں /schedule سے بنائیں — تینوں ایک ہی cloud اکاؤنٹ میں لکھتے ہیں۔ ایک routine ایک prompt، وہ repos جنہیں یہ چھو سکتا ہے، اس کے connectors، اور ایک trigger (schedule، API، یا GitHub event) کو ایک جگہ جمع کرتا ہے، پھر Anthropic کے servers پر چلتا ہے۔ فی اکاؤنٹ روزانہ run caps کا خیال رکھیں، اور یہ کہ default کے طور پر کوئی routine صرف انہی branches پر push کر سکتا ہے جو claude/ سے شروع ہوں — ایک سوچا سمجھا guardrail جسے آپ Allow unrestricted branch pushes سیٹنگ سے فی repository ہٹا سکتے ہیں۔

اپنے ہی cron میں headless one-shot (laptop آن، کوئی Anthropic cloud نہیں)۔ claude -p ایک prompt چلا کر باہر نکل جاتا ہے — اسے سیدھا crontab میں ڈالیں:

# every weekday at 9am: sort through CI and summarize failures
0 9 * * 1-5 cd /path/to/repo && claude -p "check the CI dashboard and summarize any failures" >> ~/claude-cron.log 2>&1

مکمل تفصیل کے لیے، کتاب کا Scheduled Tasks: The Loop Skill and Cron Tools دیکھیں۔

OpenCode کی بے توجہ دھڑکن ہمیشہ OS یا CI ہوتی ہے — یہی OpenCode کا راستہ ہے۔ opencode run کو chat screen کے بغیر استعمال کریں، اور scheduler کو اسے فائر کرنے دیں۔

آپ کی اپنی مشین، cron کے ساتھ:

# every weekday at 9am: sort through CI and summarize failures
0 9 * * 1-5 cd /path/to/repo && opencode run "check the CI dashboard and summarize any failures" >> ~/opencode-cron.log 2>&1

cloud، GitHub Actions کے ساتھ (آپ کی کوئی مشین آن ہونے کی ضرورت نہیں)۔ نیچے دی گئی model string صرف مثال کے طور پر ہے — اپنے install کو معلوم درست IDs کے لیے opencode models چلائیں:

name: Scheduled OpenCode Task
on:
  schedule:
    - cron: "0 9 * * 1-5"   # weekdays at 9am UTC
jobs:
  opencode:
    runs-on: ubuntu-latest
    permissions: { contents: write, pull-requests: write, issues: write }
    steps:
      - uses: actions/checkout@v6
        with: { persist-credentials: false }
      - uses: anomalyco/opencode/github@latest
        env: { ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} }
        with:
          model: anthropic/claude-sonnet-4-6   # confirm with `opencode models`
          prompt: |
            Review the codebase for TODO comments and summarize them.
            If any are worth acting on, open an issue to track them.

scheduled events کے لیے prompt لازمی ہے (پڑھنے کے لیے کوئی comment نہیں ہوتا)، اور اگر لوپ کو branches یا PRs کھولنے ہوں تو آپ کو contents: write / pull-requests: write دینا ہوگا۔

اوپر دیے گئے action اور model ناموں پر ایک نوٹ

OpenCode GitHub Action کا حوالہ موجودہ سرکاری docs میں anomalyco/opencode/github@latest کے طور پر دیا جاتا ہے؛ کچھ پرانی guides اب بھی sst/opencode/github@latest دکھاتی ہیں۔ دونوں ایک ہی project کی طرف اشارہ کرتے ہیں — وہی استعمال کریں جو آپ کا opencode github install بناتا ہے۔ models کے لیے، anthropic/claude-sonnet-4-6 موجودہ Sonnet ID ہے۔ Dateless IDs 4.6 نسل کے ساتھ آئے، جہاں dateless string ہی pinned snapshot ہے؛ پرانی 4.5 نسل کے ماڈلز جیسے Haiku 4.5 ایک dated canonical ID (claude-haiku-4-5-20251001) کے ساتھ ساتھ ایک dateless claude-haiku-4-5 alias رکھتے ہیں جو تازہ ترین snapshot کی طرف اشارہ کرتا ہے۔ نیچے دی گئی مثالیں reproducibility کے لیے dated Haiku ID pin کرتی ہیں۔ اپنے install کو معلوم درست strings دیکھنے کے لیے opencode models چلائیں۔

7. Event-driven (جب کچھ ہو تو ردِعمل دیں)​

ایک schedule پوچھتا ہے "ہر گھنٹے جانچو۔" ایک event پوچھتا ہے "X ہوتے ہی فوراً ردِعمل دو۔" کوئی PR کھلتا ہے، کوئی issue دائر ہوتا ہے، کوئی message آتا ہے — اور لوپ جواب میں چلتا ہے۔

دو راستے۔ Routines ایک GitHub webhook trigger قبول کرتے ہیں، تو کوئی routine کسی push یا نئے PR پر چل سکتا ہے، صرف گھڑی پر نہیں۔ chat طرز کے events کے لیے، Channels باہر کے ذرائع (Telegram، Discord، اور iMessage built-in ہیں؛ webhook receiver وہ ہے جسے آپ خود wire کرتے ہیں) سے messages کو سیدھا کسی چلتے ہوئے سیشن میں دھکیلتے ہیں — scheduling کا event-driven ساتھی۔ code.claude.com/docs/en/channels دیکھیں۔

GitHub agent کو ایک بار opencode github install سے install کریں، جو .github/workflows/opencode.yml شامل کرتا ہے۔ اس کے بعد، OpenCode repository کے events پر ردِعمل دیتا ہے — pull_request، issues، اور /oc یا /opencode comments — آپ کے GitHub Actions runners کے اندر چلتے ہوئے:

name: opencode-review
on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions: { contents: read, pull-requests: read }
    steps:
      - uses: actions/checkout@v6
        with: { persist-credentials: false }
      - uses: anomalyco/opencode/github@latest
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          model: anthropic/claude-sonnet-4-6
          use_github_token: true
          prompt: |
            Review this pull request for bugs, quality issues, and security risks.

بغیر prompt والے pull_request event کے لیے، OpenCode default کے طور پر PR کا review کرتا ہے۔

خود کو جانچیں

آپ چاہتے ہیں کہ ایک لوپ کسی ناکام test کو pass ہونے تک ٹھیک کرتا رہے، پھر خود ہی رک جائے۔ آپ کون سی دھڑکن چنیں گے، اور "ہو گیا" کا فیصلہ کون کرے گا؟

جواب دکھائیں

Run-until-done — Claude Code میں /goal، یا OpenCode میں ایک capped shell لوپ۔ ایک کمانڈ (test runner) "ہو گیا" کا فیصلہ کرتی ہے، کبھی وہ ایجنٹ نہیں جس نے fix لکھا — اور پھر بھی اسے ایک ceiling چاہیے تاکہ یہ ہمیشہ کوشش نہ کرتا رہے۔

---

حصہ 3: جسم​

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

8. علیحدگی: worktrees​

جس لمحے کوئی لوپ بیک وقت ایک سے زیادہ ایجنٹ چلاتا ہے، وہ ایک دوسرے کی فائلوں پر لکھنا شروع کر دیتے ہیں — بالکل ویسے ہی جیسے دو لوگ ایک دوسرے کو بتائے بغیر ایک ہی لائنیں edit کریں۔ ایک git worktree اسے ٹھیک کرتا ہے: ایک علیحدہ working folder، اپنی الگ branch پر، جو وہی repo history شیئر کرتا ہے۔ ایک ایجنٹ کی edits دوسرے کے checkout کو چھو نہیں سکتیں۔

built-in۔ --worktree flag استعمال کریں تاکہ کوئی سیشن اپنے الگ checkout میں کھلے، یا کسی subagent پر isolation: worktree سیٹ کریں تاکہ ہر مددگار کو ایک تازہ checkout ملے جو بعد میں خود کو صاف کر لے۔ ایک scheduled task فی run worktree علیحدگی آن کر سکتا ہے، تو متوازی runs کبھی آپ کے اپنے دستی کام سے نہیں ٹکراتے۔

کوئی واحد flag نہیں۔ آپ git کے اپنے worktrees استعمال کرتے ہیں اور ہر ایک کی طرف ایک run کا رخ کرتے ہیں۔ وہی علیحدگی، صاف ظاہر کی گئی:

git worktree add ../wt-feature-a feature-a
git worktree add ../wt-feature-b feature-b
( cd ../wt-feature-a && opencode run "implement feature A" ) &
( cd ../wt-feature-b && opencode run "implement feature B" ) &
wait

Community runners (OpenCode کے گرد بنے worktree managers) آپ کے لیے یہ حساب کتاب سنبھال سکتے ہیں اگر آپ یہ اکثر کرتے ہیں۔

9. علم: skills، تاکہ کوئی run "پہلا دن" نہ ہو​

ایک لوپ ہر بار ٹھنڈا چلتا ہے — ایک تازہ سیشن جسے آپ کے پروجیکٹ کی عادتوں کی کوئی یاد نہیں۔ بغیر مدد کے، یہ ہر دھڑکن پر آپ کا پورا سیٹ اپ سمجھتا (یا اندازہ لگاتا) ہے، tokens ضائع کرتا اور غلطیوں کو دعوت دیتا ہے۔ ایک skill وہی علم ہے جو ایک بار، ایک SKILL.md فائل میں لکھا جاتا ہے، جہاں ایجنٹ اسے ہر run پر پڑھتا ہے۔

یہ دونوں ٹولز میں ایک جیسا کام کرتا ہے: ہدایات اور metadata والے ایک SKILL.md کے ساتھ ایک folder، جس میں اختیاری scripts اور references بھی ہوں۔ کسی لوپ میں قاعدہ سادہ ہے: جو کچھ بھی آپ کو ہر run پر دوبارہ سمجھانا پڑے، اس کا تعلق کسی skill سے ہے۔ triage کے قدم، پروجیکٹ کی عادتیں، "ہم ایسا اس لیے نہیں کرتے کیونکہ ایک بار وہ واقعہ ہوا تھا" — یہ سب skill میں رہتا ہے، تو لوپ نئے سرے سے شروع ہونے کے بجائے خود پر تعمیر کرتا ہے۔ (مکمل تفصیل Skills & Connectors فوری کورس میں۔)

ایک skill لوپ prompts کو چھوٹا رکھتا ہے

ہدایات کی ایک دیوار کسی ایسے schedule میں چپکانے کے بجائے جسے کوئی اپڈیٹ نہیں رکھے گا، آپ کا scheduled prompt ایک لائن بن جاتا ہے — "daily-triage skill چلاؤ" — اور تفصیل skill رکھتا ہے۔ مختصر لوپ prompt، آسانی سے اپڈیٹ ہونے والی logic، ہر دھڑکن پر کم token لاگت۔

10. عمل: connectors (لوپ عمل کرتا ہے، صرف تجویز نہیں)​

ایسا لوپ جو صرف آپ کی فائلیں پڑھ سکتا ہے، ایسا لوپ ہے جو صرف بات کر سکتا ہے۔ Connectors — MCP پر بنے — اسے کرنے دیتے ہیں: کوئی PR کھولنا، کوئی Linear ticket اپڈیٹ کرنا، Slack پر پوسٹ کرنا، کسی database سے query کرنا، کسی staging API کو call کرنا۔ یہی فرق ہے اس لوپ میں جو کہتا ہے "یہ رہا fix" اور اس لوپ میں جو PR کھولتا ہے، ticket جوڑتا ہے، اور CI green ہوتے ہی channel پر پوسٹ کرتا ہے۔

دونوں ٹولز MCP بولتے ہیں، تو protocol ان کے درمیان منتقل ہوتا ہے — مگر packaging اور authentication (local بمقابلہ hosted، OAuth، permissions) کو اکثر ٹول کے مطابق wiring چاہیے ہوتی ہے۔

MCP servers اپنی config میں شامل کریں اور انہیں کسی routine کی connector list میں رکھیں، تاکہ بے توجہ run ان تک پہنچ سکے۔ وہی connectors جو آپ ہاتھ سے استعمال کرتے ہیں، scheduled اور cloud runs کو دستیاب ہوتے ہیں۔

opencode.json کے mcp سیکشن میں servers declare کریں — local servers ایک subprocess شروع کرتے ہیں، remote servers خودکار OAuth کے ساتھ کسی HTTPS endpoint تک پہنچتے ہیں۔ کسی scheduled opencode run میں، ایک بار opencode serve شروع کریں اور اس سے --attach ہوں، تاکہ آپ ہر دھڑکن پر MCP آغاز کی لاگت ادا نہ کریں۔

11. Maker–checker: sub-agents​

کسی لوپ کا سب سے اہم فیصلہ: جو ایجنٹ کام لکھتا ہے وہ اسے منظور کرنے والا ایجنٹ نہیں ہونا چاہیے۔ اپنے ہی output کو grade کرنے والا ماڈل اپنے ساتھ کہیں زیادہ نرمی کرتا ہے۔ ایک دوسرا ایجنٹ — مختلف ہدایات، اکثر مختلف (کبھی کبھی زیادہ مضبوط) ماڈل — وہ پکڑ لیتا ہے جو پہلا چُوک گیا کیونکہ اسے یقین تھا کہ وہ ٹھیک ہے۔ یہی واحد وجہ ہے جس کی بنا پر آپ چلتا ہوا لوپ اکیلا چھوڑ سکتے ہیں۔

subagents کو .claude/agents/ میں define کریں، اور انہیں agent teams کے طور پر یکجا کریں: ایک کھوج کرتا ہے، ایک implement کرتا ہے، ایک spec اور tests کے خلاف جانچتا ہے۔ "spec" وہی ہے جو آپ نے Spec-Driven Development میں لکھنا سیکھا: اس کے acceptance criteria بالکل وہی ہیں جن کے خلاف ایک قابلِ بھروسہ checker grade کرتا ہے — مبہم spec آپ کو مبہم فیصلہ دیتا ہے۔ یہی وہ کام ہے جو /goal اندر کرتا ہے: ایک تازہ ماڈل فیصلہ کرتا ہے کہ لوپ مکمل ہوا یا نہیں، worker کے خود کو grade کرنے کے بجائے۔

OpenCode built-in primary agents (Build، Plan) اور ایک built-in general subagent شِپ کرتا ہے (نیز موجودہ versions میں explore، اور ایک experimental flag کے پیچھے scout)۔ آپ اپنے agents opencode.json میں یا اپنے agents folder میں markdown فائلوں کے طور پر define کر سکتے ہیں۔ checker کو اس کا اپنا (اکثر سستا، read-only) ماڈل دیں، اور maker سے اسے @ mention یا Task tool کے ذریعے call کروائیں۔ ایک عام تقسیم: ایک مضبوط ماڈل کھوج اور implement کرتا ہے، ایک مرتکز ماڈل جانچتا ہے۔

---
mode: subagent
model: anthropic/claude-haiku-4-5-20251001
description: Reviews a diff against the spec and tests. Replies PASS or FAIL with reasons.
---

You are a strict code reviewer. You do not make changes.
Check the diff against the spec and the test results, then reply PASS or FAIL with the reasons.

Sub-agents زیادہ لاگت رکھتے ہیں — انہیں وہاں خرچ کریں جہاں اہمیت ہو

ہر sub-agent اپنا الگ ماڈل اور tools چلاتا ہے، تو maker–checker تقسیم واقعی زیادہ tokens خرچ کرتی ہے۔ یہی ایک ایسے checker کی قیمت ہے جس پر آپ بھروسہ کر سکیں۔ اسے وہاں خرچ کریں جہاں دوسری رائے اہم ہو (ہر وہ چیز جو لوپ آپ کی غیر موجودگی میں commit کرے گا)؛ پھینک دینے والے، read-only کاموں کے لیے اسے چھوڑ دیں۔

11b. جسم کو codify کریں: dynamic workflows​

اب تک، ایک دھڑکن کا جسم — کام ڈھونڈنا، ہر fix کو اپنے checkout میں draft کرنا، کسی علیحدہ ایجنٹ سے اسے grade کروانا — وہ ہے جسے ایجنٹ turn بہ turn جوڑتا ہے۔ Claude Code اب آپ کو اس پوری orchestration کو ایک دوبارہ چلائے جانے والے script کے طور پر codify کرنے دیتا ہے، جسے dynamic workflow کہتے ہیں: آپ کام بیان کرتے ہیں، Claude ایک script لکھتا ہے جو کام کو کئی sub-agents میں پھیلاتا ہے، اور ایک runtime اسے background میں چلاتا ہے جبکہ آپ کا سیشن آزاد رہتا ہے۔ یہ maker–checker تقسیم (تصور 11) اور worktree تقسیم (تصور 8) کو ایک دہرائے جانے والے unit میں packaged کر دیتا ہے — اور یہ ایک حقیقی quality pattern لاگو کر سکتا ہے، صرف زیادہ ایجنٹ چلانے سے زیادہ: آزاد reviewers کسی بھی چیز کی رپورٹ ہونے سے پہلے ایک دوسرے کے نتائج کو adversarially جانچ سکتے ہیں۔

سادہ الفاظ میں ایک مانگیں ("use a workflow to…")، اسے ultracode keyword سے trigger کریں، یا bundled /deep-research چلائیں۔ جب کوئی run وہ کرے جو آپ چاہتے ہیں، تو /workflows view میں s دبائیں تاکہ اس کا script ایک /command کے طور پر محفوظ ہو جائے جسے آپ ہر branch پر دوبارہ چلا سکیں۔ دو حدیں اسے ایماندار رکھتی ہیں: ایجنٹس capped ہیں (ایک وقت میں تقریباً 16، فی run 1000) تاکہ کوئی بے قابو script بے ہنگم نہ ہو جائے، اور کسی run کی memory صرف اسی run کے اندر رہتی ہے — آپ اسے اسی سیشن کے اندر resume کر سکتے ہیں، مگر ایک تازہ سیشن اسے نئے سرے سے شروع کرتا ہے۔

کوئی /workflows کمانڈ نہیں۔ جو script آپ پہلے ہی لکھتے ہیں وہی workflow ہے: تصور 5 والا capped for لوپ اور تصور 8 والا &/wait fan-out اسی خیال کا ہاتھ سے بنا ہوا نسخہ ہیں — آپ کا shell منصوبہ رکھتا ہے، opencode run ہر ایجنٹ ہے، اور exit codes checker ہیں۔ آپ کو پورا کنٹرول اور کوئی agent cap نہیں ملتا، اس قیمت پر کہ orchestration آپ خود لکھتے اور سنبھالتے ہیں۔

ایک workflow ایک دھڑکن کا جسم ہے — لوپ نہیں

جیسے ہی workflows طاقتور محسوس ہونے لگتے ہیں، یہی سب سے آسان غلطی ہے۔ ایک dynamic workflow ایک بار چلتا ہے، جب آپ (یا ultracode سیٹنگ) اسے شروع کریں، اور ختم ہوتے ہی سب کچھ بھول جاتا ہے۔ اس کی کوئی دھڑکن نہیں اور کوئی ریڑھ کی ہڈی نہیں۔ تو یہ ایک ہی دھڑکن کا جسم ہے، لوپ نہیں۔ لوپ ترکیب ہے: ایک دھڑکن (ایک Routine، /loop، یا cron) دھڑکن کو فائر کرتی ہے، workflow وہ جسم ہے جو اس پر چلتا ہے، اور ایک progress file جسے اس کے ایجنٹس لکھتے ہیں وہ ریڑھ کی ہڈی ہے جسے اگلی بار فائر ہونے پر پڑھا جاتا ہے۔ workflow engine ہے؛ Routine وہ ہے جو چابی گھماتی ہے، اور progress.md وہ ایندھن ہے جو سفروں کے درمیان زندہ رہتا ہے۔

---

حصہ 4: ریڑھ کی ہڈی​

12. وہ state جو runs کے درمیان زندہ رہتی ہے​

یہ رہا وہ حصہ جسے نوآموز چھوڑ دیتے ہیں، اور یہی وہ ہے جو لوپ کو لوپ بناتا ہے۔ ماڈل runs کے درمیان سب کچھ بھول جاتا ہے۔ اگر ہر دھڑکن صفر سے شروع ہو، تو آپ کے پاس لوپ نہیں — آپ کے پاس وہی پہلا قدم ہے، ہمیشہ کے لیے دہراتا ہوا۔ حل سادہ اور طاقتور ہے: state کو ماڈل سے باہر، disk پر رکھیں۔

state کی دو پرتیں، ساتھ مل کر کام کرتیں:

• Rules file (CLAUDE.md / AGENTS.md) — مستقل عادتیں جنہیں لوپ ہر run پر پڑھتا ہے۔ (اسے مختصر رکھیں؛ آپ نے پچھلے کورس میں وجہ سیکھ لی تھی۔ ایک پھولی ہوئی rules file کی قیمت ہر دھڑکن پر ادا ہوتی ہے۔)
• ایک progress file — ایک سادہ markdown فائل (یا MCP کے ذریعے کوئی Linear board) جو ریکارڈ رکھتی ہے کہ کیا آزمایا گیا، کیا pass ہوا، کیا اب بھی کھلا ہے۔ یہی اصل ریڑھ کی ہڈی ہے۔ کل کا صبح 9 بجے والا run اسے کھولتا ہے اور وہیں سے اٹھاتا ہے جہاں آج کا run رکا تھا۔

عادت: ہر run آغاز میں progress file پڑھتا ہے اور آخر میں اسے اپڈیٹ کرتا ہے۔ جب لوپ بار بار وہی غلطی کرے، تو حل کوئی زیادہ ذہین prompt نہیں — بلکہ یہ ہے کہ لوپ سے سبق rules file میں لکھوایا جائے، تاکہ fix ہر آنے والے run کے لیے قائم رہے۔

<!-- progress.md — the loop's memory between runs -->

## Done

- 2026-06-22: fixed flaky test in test/auth (retry on token refresh)

## In progress

- Dependency audit: 3 of 7 advisories patched; lodash bump blocked by an API change

## Open / needs a human

- CVE-2026-xxxx in image lib — the fix changes the output format, escalating to a maintainer

ریڑھ کی ہڈی آپ کا ریکارڈ بھی ہے

چونکہ progress file آپ کے repo میں محض text ہے، یہ اس کام کا ریکارڈ بھی بن جاتی ہے جو لوپ نے آپ کی غیر موجودگی میں کیا۔ جب آپ انسانی gate پر بیٹھتے ہیں، تو آپ ریڑھ کی ہڈی پڑھتے ہیں — ہر run کا پورا transcript نہیں۔

خود کو جانچیں

لوپ کو اب تک جو کیا اسے کہاں رکھنا چاہیے، اور گفتگو میں کیوں نہیں؟

جواب دکھائیں

disk پر — ایک progress file (نیز rules file)، یا Linear جیسا board۔ ماڈل کی memory runs کے درمیان مٹ جاتی ہے، تو جو کچھ زندہ رہنا ہو وہ ماڈل سے باہر رہتا ہے۔ repo یاد رکھتا ہے؛ ماڈل نہیں۔

---

حصہ 5: ایک مکمل لوپ، دو بار​

کم سے کم محفوظ لوپ کی چیک لسٹ

کسی بھی لوپ کو خود سے چلنے دینے سے پہلے، اسے ان ساتوں کی ضرورت ہے۔ وہ لوپ جو آپ ابھی بنانے والے ہیں ان میں سے ہر ایک رکھتا ہے:

• Success condition — یہ کیسے جانتا ہے کہ کام ہو گیا (تصور 5)۔
• Ceiling — زیادہ سے زیادہ کوششیں، منٹ، یا خرچ، تاکہ یہ ہمیشہ نہ چلتا رہے (تصور 13)۔
• علیحدہ branch یا worktree — تاکہ متوازی کام نہ ٹکرائے (تصور 8)۔
• Read-only checker — ایک علیحدہ ایجنٹ جو grade کرتا ہے مگر edit نہیں کر سکتا (تصور 11)۔
• State file — ریڑھ کی ہڈی، تاکہ یہ runs کے درمیان یاد رکھے (تصور 12)۔
• انسانی gate — خطرناک یا ناکام کام کسی شخص کے پاس جاتا ہے، کبھی سیدھا main پر نہیں (حصہ 5)۔
• ایک log یا notification — تاکہ رات بھر کی کوئی ناکامی نظر آئے، خاموش نہ رہے (حصہ 6)۔

ایک بھی چُوک جائے اور لوپ غیر محفوظ، بھلکڑ، یا غیر مرئی ہے۔

اب حصوں کو جوڑیں۔ یہ رہا ایک لوپ — ایک صبح کا maintenance لوپ جو رات بھر کی CI failures چھانٹتا ہے، محفوظ fixes draft کرتا ہے، انہیں جانچواتا ہے، محفوظ والوں کے لیے PRs کھولتا ہے، اور باقی کو flag کرتا ہے — ہر ٹول میں ایک بار بنایا گیا۔ نیچے دی گئی فائلیں حقیقی ہیں؛ آپ انہیں کسی repo میں copy کر کے چلا سکتے ہیں۔

لوپ کی ساخت (دونوں میں ایک جیسی):

1. Heartbeat: ہر working day صبح 9 بجے۔
2. Skill: ایک daily-triage skill قدم رکھتا ہے، تو prompt ایک لائن رہتا ہے۔
3. Spine: آغاز میں progress.md پڑھیں، آخر میں اسے اپڈیٹ کریں۔
4. Worktree: ہر fix اپنے checkout میں draft ہوتا ہے۔
5. Maker–checker: ایک implementer draft کرتا ہے؛ ایک علیحدہ reviewer PASS یا FAIL کہتا ہے۔
6. Connector: PASS کے لیے PR کھولیں؛ FAIL یا کسی بھی خطرناک چیز کے لیے، اسے "needs a human" میں لکھیں اور رک جائیں۔

مشترکہ skill​

یہ ایک فائل دونوں ٹولز میں کام کرتی ہے۔ اسے .claude/skills/daily-triage/SKILL.md (Claude Code) یا .opencode/skills/daily-triage/SKILL.md (OpenCode) کے طور پر محفوظ کریں۔

---
name: daily-triage
description: >-
  Runs the morning maintenance pass. Reads the progress file, gathers overnight
  CI failures, open issues, and new audit advisories, drafts safe fixes (each
  one checked by a separate reviewer agent), opens pull requests for what passes,
  and writes anything risky to the progress file for a human. Use this for the
  scheduled morning maintenance loop.
---

# Daily triage

You are the morning maintenance loop. Work through these steps in order.
Do not skip the progress file. It is your only memory between runs.

## 1. Read your memory first

- Open `progress.md`. Read the "In progress" and "Open / needs a human" sections.
- Do not redo anything already listed under "Done".

## 2. Find the work

Gather candidates in this order, and stop once you have at most 5:

1. CI runs that failed since the last entry in `progress.md`.
2. Open issues labelled `bug` or `maintenance`.
3. New advisories from `npm audit` (or this project's audit command).

## 3. Work each candidate

- Create an isolated checkout: a git worktree, or a fresh branch named
  `claude/<short-slug>`.
- Draft the smallest fix that solves the one problem. Do not bundle changes.
- Send the diff to the reviewer agent. Wait for its verdict before going on.

## 4. Decide from the verdict

- PASS, and the change is low risk (no public API change, no data migration,
  no file deletion): open a pull request. Title it `fix: <one short line>` and
  link the issue.
- FAIL, or the change touches anything risky: do NOT open a pull request. Add a
  short entry to the "Open / needs a human" section of `progress.md`. Say what
  you tried and why you stopped.

## 5. Update your memory last

- Move finished items to "Done" with today's date.
- Save `progress.md`. This is the file tomorrow's run will read.

## Rules

- Never open more than 5 pull requests in one run.
- Never change `main` directly. Only `claude/*` branches.
- When in doubt, escalate. A flagged item a human checks is always safer than a
  wrong fix shipped while no one was watching.

reviewer (checker)​

reviewer عملی طور پر maker–checker تقسیم ہے۔ آپ کو دونوں فائلیں چاہئیں — یہ کوئی "یا یہ یا وہ" ٹول کا انتخاب نہیں۔ format ہر ٹول میں ذرا مختلف ہے، تو ہر ایک نیچے مکمل دکھائی گئی ہے۔

Claude Code — .claude/agents/reviewer.md کے طور پر محفوظ کریں:

---
name: reviewer
description: Reviews a diff against the spec and the test results. Replies PASS or FAIL with reasons. Makes no changes.
tools: Read, Bash(npm test*), Bash(npm run lint*), Bash(git diff*)
model: claude-haiku-4-5-20251001
---

You are a strict, read-only code reviewer. You never edit files.

1. Run the tests and the linter. Read the output yourself. Do not trust a claim
   that they pass.
2. Check the change against the project conventions in `CLAUDE.md` and the
   relevant spec.
3. Look for bugs, missing edge cases, security risks, and any change to public
   behaviour.

Then reply with exactly one of:

- `PASS` — followed by one line saying what you verified.
- `FAIL` — followed by the specific reasons, one per line.

A change that only "looks fine" is not a PASS. The tests must actually pass, and
the change must do only what was asked.

OpenCode — .opencode/agents/reviewer.md کے طور پر محفوظ کریں:

---
mode: subagent
model: anthropic/claude-haiku-4-5-20251001
description: Reviews a diff against the spec and tests. Replies PASS or FAIL with reasons. Read-only.
permission:
  edit: deny
  bash:
    "*": deny
    "npm test*": allow
    "npm run lint*": allow
    "git diff*": allow
---

You are a strict, read-only code reviewer. You never edit files.

1. Run the tests and the linter. Read the output yourself. Do not trust a claim
   that they pass.
2. Check the change against the project conventions in `AGENTS.md` and the
   relevant spec.
3. Look for bugs, missing edge cases, security risks, and any change to public
   behaviour.

Reply with exactly one of:

- PASS — followed by one line saying what you verified.
- FAIL — followed by the specific reasons, one per line.

A change that only "looks fine" is not a PASS. The tests must actually pass, and
the change must do only what was asked.

دھڑکن کی wiring​

claude.ai/code/routines پر ایک Routine بنائیں جس میں working day صبح 9 بجے کا schedule، آپ کا repo، اور آپ کے GitHub + Slack connectors ہوں۔ اس کا prompt skill کی طرف موڑ دیں، تو routine کی تعریف چھوٹی رہتی ہے:

Run the daily-triage skill.
Start by reading progress.md; finish by updating it.
For each fix: draft it in an isolated worktree, have the reviewer subagent grade it,
open a PR only on PASS, and append anything risky to the "needs a human" section.

قدم skill رکھتا ہے۔ .claude/agents/reviewer.md checker ہے۔ isolation: worktree متوازی fixes کو الگ رکھتا ہے۔ GitHub connector PRs کھولتا ہے۔ چونکہ یہ ایک cloud Routine ہے، یہ صبح 9 بجے چلتا ہے چاہے آپ کا laptop کھلا ہو یا نہیں — آپ کے plan کی روزانہ run cap کے اندر۔

اسے ایک GitHub Actions workflow کے طور پر بنائیں، تو یہ cloud میں چلتا ہے، آپ کی کسی مشین کے جاگے بغیر۔ Action دھڑکن ہے؛ opencode run worker ہے؛ آپ کا repo skill، agents، اور progress.md رکھتا ہے۔

name: morning-maintenance
on:
  schedule:
    - cron: "0 9 * * 1-5"
jobs:
  triage:
    runs-on: ubuntu-latest
    permissions: { contents: write, pull-requests: write, issues: write }
    steps:
      - uses: actions/checkout@v6
        with: { persist-credentials: false }
      - uses: anomalyco/opencode/github@latest
        env: { ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} }
        with:
          model: anthropic/claude-sonnet-4-6   # confirm with `opencode models`
          prompt: |
            Run the daily-triage skill.
            Read progress.md first; update it last.
            For each candidate fix: draft it on a new branch, then invoke the
            @reviewer subagent to grade it. Open a PR only when the reviewer
            replies PASS. Append anything risky to the "needs a human" section
            of progress.md and leave it for the maintainer.

reviewer ایجنٹ (ایک سستے read-only ماڈل پر) checker ہے۔ CI میں نئی branches worktree علیحدگی کا کام کرتی ہیں۔ OpenCode GitHub app PRs کھولتا ہے۔ اسے GitHub کے بجائے اپنی ہی مشین پر چاہتے ہیں؟ بالکل وہی prompt ایک cron لائن سے چلتا ہے جو opencode run کو call کرتی ہے — صرف دھڑکن بدلتی ہے۔

ایک حقیقی صبح کیسی لگتی ہے​

آپ نے اوپر کی ہر چیز ایک بار ڈیزائن کی۔ یہ رہا ایک ہی run، اسی طرح کا جس کے ساتھ آپ جاگیں گے (نیچے دیا گیا run ساخت کی ایک مثال ہے، کوئی recording نہیں):

[09:00] daily-triage fires
  → reads progress.md: 1 item still "in progress" (lodash bump), nothing new flagged
  → finds: 2 CI failures overnight, 1 new npm-audit advisory
  → CI failure #1 (flaky auth test):
        drafts fix on branch claude/fix-auth-retry
        reviewer → PASS (tests green; retries on token refresh; no API change)
        → opens PR #142, links the issue
  → CI failure #2 (type error in report.ts):
        drafts fix on branch claude/fix-report-types
        reviewer → PASS → opens PR #143
  → advisory (image library):
        the safe fix changes the output format
        reviewer → FAIL (public behaviour change)
        → writes it to "Open / needs a human" in progress.md, opens no PR
  → updates progress.md, exits
[you, 09:30] two PRs to review, one flagged item to decide on. You typed nothing.

دیکھیں کیا ہوا۔ لوپ نے کام ڈھونڈا، اسے draft کیا، جانچا، محفوظ حصہ شِپ کیا، اور آپ کو صرف وہ ایک فیصلہ سونپا جس کے لیے کسی شخص کی ضرورت تھی۔ یہی عملی طور پر لوپ انجینئرنگ ہے۔ اور غور کریں: دونوں ٹولز کے درمیان واحد حقیقی فرق دھڑکن اور یہ تھا کہ run کہاں ہوا۔ بیچ کی ہر چیز — skill، ریڑھ کی ہڈی، worktree، maker–checker، connector — وہی ڈیزائن تھا۔

خود کو جانچیں

صبح کے triage لوپ میں، آپ کے سونے کے دوران کوئی غلط fix merge ہونے سے کیا چیز روکتی ہے؟

جواب دکھائیں

تین چیزیں مل کر: reviewer subagent کو PASS واپس کرنا ہوتا ہے (maker–checker)، صرف کم خطرے والی تبدیلیاں ہی PR کھول سکتی ہیں، اور انسانی gate کسی بھی خطرناک یا ناکام چیز کو main کے بجائے "needs a human" نوٹ میں بھیجتا ہے۔ ہر run capped اور logged بھی ہوتا ہے۔

---

حصہ 6: انجینئر بنے رہنا​

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

13. اصل حد token لاگت ہے، keybind نہیں​

یہ، اب تک، لوپ کے بگڑنے کا سب سے عام طریقہ ہے۔ ایک لوپ بار بار چلتا ہے، اکثر sub-agents شروع کرتا ہے، اور ہر sub-agent اپنا الگ ماڈل اور tools چلاتا ہے۔ لاگت تقریباً ہر کسی کی توقع سے تیز بڑھتی ہے۔ حل سادہ ہیں:

• ہر لوپ کو cap کریں — زیادہ سے زیادہ کوششیں، منٹ، یا خرچ۔ ہمیشہ (تصور 5)۔
• ماڈل کو کام کے مطابق رکھیں — منصوبہ بنانے اور جانچنے کے لیے ایک مضبوط ماڈل، کام کرنے کے لیے ایک سستا۔ یہ سب سے بڑی بچت ہے، اور آپ یہ پچھلے کورس میں سیکھ چکے ہیں۔
• لوپ prompt اور rules file مختصر رکھیں — آپ ہر دھڑکن پر ان کی قیمت ادا کرتے ہیں۔ تفصیل ایسے skills میں دھکیلیں جو صرف استعمال ہونے پر لوڈ ہوں۔
• اسے کم بار چلائیں — ہر پانچ منٹ کے بجائے گھنٹے میں ایک بار عموماً کافی ہے، اور تقریباً بارہ گنا سستا۔

اعداد کا ایک فوری اندازہ (مثال کے طور پر)۔ فرض کریں ایک دھڑکن — maker اور checker — تقریباً 40k tokens پڑھتی ہے اور تقریباً 6k لکھتی ہے۔ Sonnet 4.6 کی فی million ‎$3 / $15 پر، یہ تقریباً $0.20 فی دھڑکن ہے۔ 20 دن کے مہینے میں روزانہ پانچ دھڑکنیں تقریباً $20 ہیں — سستا۔ وہی لوپ ہر پانچ منٹ، چوبیس گھنٹے فائر ہو، تو دھڑکنیں سو گنا سے زیادہ ہیں — آرام سے $1,000 ماہانہ سے اوپر، بغیر کسی اضافی قدر کے۔ پیسہ cadence میں جاتا ہے، keybind میں نہیں۔

ماڈل دوسرا lever ہے — OpenCode راستے پر۔ وہ اعداد Sonnet 4.6 فرض کرتے ہیں۔ Claude Code کے لوپ commands Claude چلاتے ہیں، مگر OpenCode آپ کو ماڈل چننے دیتا ہے، اور ایک سستا ماڈل فی دھڑکن لاگت کو کافی نیچے لے جاتا ہے: DeepSeek V4 Flash (تقریباً $0.14 / $0.28 فی million) وہی دھڑکن تقریباً $0.007 — تقریباً 30 گنا سستا — چلاتا ہے، جو $20 ماہانہ والے لوپ کو ایک ڈالر سے بھی کم میں بدل دیتا ہے۔ دو ایماندارانہ احتیاطیں۔ پہلی، سستا maker، قابلِ بھروسہ checker: ایک کمزور ماڈل بدتر fixes لکھتا ہے، تو یہ زیادہ دھڑکنیں جلا سکتا ہے یا زیادہ بار review میں ناکام ہو سکتا ہے، اور دوبارہ کوششیں بچت کھا جاتی ہیں — سستا ماڈل ایک واضح spec پر مشینی maker کے لیے استعمال کریں، اور ایک ایسا checker رکھیں جس پر آپ بھروسہ کریں (test runner اور linter سب سے سستے، سب سے ایماندار checker ہیں)۔ دوسری، cadence اب بھی غالب ہے: ہر پانچ منٹ فائر ہونے والا 30 گنا سستا ماڈل پھر بھی گھنٹہ وار چلنے والے Sonnet سے زیادہ لاگت لے سکتا ہے۔ ماڈل bill کو نیچے کرتا ہے؛ یہ کتنی بار چلتا اور دوبارہ کوشش کرتا ہے، وہ اب بھی اسے طے کرتا ہے۔

بغیر خرچ کی حد والا لوپ بہت مہنگا پڑ سکتا ہے

عام ناکامی ہمیشہ ایک جیسی ہے: ایک خود سے چلتا لوپ، ایسی رکنے کی شرط کے ساتھ جسے یہ کبھی پورا نہ کر سکے، پوری رات دوبارہ کوشش کرتا ہوا۔ اسے شروع کرنے سے پہلے ایک ceiling سیٹ کریں۔ پہلے چند حقیقی runs دیکھیں۔ پھر اسے خود سے چلنے دیں۔

14. کام جانچنا اب بھی آپ کا کام ہے​

خود سے چلتا لوپ، خود سے غلطیاں کرتا لوپ ہے۔ maker–checker تقسیم لوپ کے "ہو گیا" کو کوئی معنی دیتی ہے — مگر "ہو گیا" پھر بھی ایک دعویٰ ہے، ثبوت نہیں۔ آپ کا کام غائب نہیں ہوا؛ یہ منتقل ہو گیا۔ آپ اب ہر قدم ٹائپ نہیں کرتے، مگر آپ ہی وہ ہیں جو تصدیق کرتے ہیں کہ لوپ نے ایسا کوڈ شِپ کیا جو واقعی کام کرتا ہے۔ وہ diffs پڑھیں جو لوپ نے کھولے۔ لوپ پر کام کرنے کا بھروسہ کریں؛ کام شمار ہونے سے پہلے اسے جانچیں۔

15. اپنے ہی پروجیکٹ کو سمجھنا بند نہ کریں​

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

دو لوگ بالکل ایک جیسا لوپ بنا سکتے ہیں اور مخالف نتائج پا سکتے ہیں۔ ایک اسے ایسے کام پر تیز چلنے کے لیے استعمال کرتا ہے جسے وہ گہرائی سے سمجھتا ہے۔ دوسرا اسے اس کام کو سمجھنے سے بچنے کے لیے ہی استعمال کرتا ہے۔ لوپ بنائیں۔ مگر اسے ایسے بنائیں جیسے کوئی ایسا شخص جو انجینئر بنے رہنے کا ارادہ رکھتا ہے — صرف وہ نہیں جو go دباتا ہے۔

اور یہی پورے کورس کا مرکزی خیال ہے۔ ہر سال ٹولز لوپ کی مشینری کا زیادہ حصہ جذب کر لیتے ہیں: orchestration، checker، اور schedule اب built-in ہیں (dynamic workflows، /goal، Routines) جہاں ایک سال پہلے یہ آپ کی اپنی shell scripts تھیں۔ جو ٹولز جذب نہیں کر سکتے وہ ہیں وہ دو سرے جن سے آپ تصور 1 میں ملے — ارادہ، اتنی درستی سے بیان کیا گیا کہ جانچا جا سکے، اور جو شِپ ہوتا ہے اس کی جوابدہی۔ اسی لیے یہ انجینئرنگ ہے، button دبانا نہیں، اور یہی وہ حصہ ہے جو سڑتا نہیں۔ ٹولز کو مضبوط ہونے دیں اور ان پر ٹیک لگائیں؛ بس ان دونوں سروں کو اپنے ہاتھ میں رکھیں۔

جب آپ سو رہے ہوں اور کوئی لوپ ناکام ہو

ایک بے توجہ لوپ بے توجہی سے ہی ناکام بھی ہوتا ہے۔ کسی پر رات بھر بھروسہ کرنے سے پہلے، اسے قابلِ مشاہدہ بنائیں:

• output وہاں بھیجیں جہاں آپ دیکھیں گے — کوئی log file، کوئی Slack یا Discord message (Claude Code Channels)، یا Triage inbox۔ وہ terminal نہیں جسے آپ پہلے ہی بند کر چکے۔
• ہر run پر ایک لائن لکھیں، ناکامی پر بھی — ہر دھڑکن progress.md (یا کسی log) میں ایک timestamp والا نوٹ شامل کرتی ہے: اس نے کیا آزمایا، کیا pass ہوا، کیا ٹوٹا۔ خاموش ناکامی بدترین قسم ہے۔
• runs کو دوبارہ چلانے کے قابل رکھیں — OpenCode میں، opencode run --format json، opencode export <id>، اور opencode session list آپ کو پورا ریکارڈ دیتے ہیں۔ Claude Code میں، ایک Routine اپنی run history web UI میں رکھتا ہے۔
• ceiling پر اونچی آواز سے ناکام ہوں — جب لوپ اپنی cap سے ٹکرائے یا error دے، تو اسے ایک واضح "needs a human" نوٹ چھوڑنا چاہیے، بس رک نہیں جانا چاہیے۔
• رات کی جگہ کمائیں — اسے رات بھر بے توجہ چلنے دینے سے پہلے چند دن گھنٹہ وار اور دیکھتے ہوئے چلائیں۔ جب کچھ غلط لگے، پہلے ریڑھ کی ہڈی پڑھیں؛ یہ بتاتی ہے کہ آخری اچھے run نے کیا کیا۔

ایسا لوپ جسے آپ debug نہیں کر سکتے، ایسا لوپ ہے جس پر آپ بھروسہ نہیں کر سکتے۔

---

🚀 Projects

لوپ کے بارے میں پڑھنا ایک بنانے جیسا نہیں۔ یہ رہے پانچ projects، آسان سے مشکل۔ انہیں کسی بھی ٹول میں کریں — لوپ کی ساخت ایک ہی ہے، تو متعلقہ تصور سے کمانڈ تک پہنچیں (Claude Code میں /loop اور /goal؛ OpenCode میں ایک shell timer کے ساتھ opencode run)۔

شروع کرنے سے پہلے دو قاعدے، ہر بار:

• ایک پھینک دینے والا git repo استعمال کریں۔ ایک لوپ خود سے فائلیں edit کرتا ہے۔ اپنے پہلے لوپ ایسے کام کی طرف نہ موڑیں جس کی آپ کو پروا ہو۔
• پہلے ایک ceiling سیٹ کریں۔ زیادہ سے زیادہ کوششیں، منٹ، یا خرچ — کسی چیز کو خود سے چلنے دینے سے پہلے (تصور 13)۔

👀Project 115-30 minایک watch لوپایک لوپ سے کسی لمبے کام کی نگرانی کروائیں اور ختم ہوتے ہی آپ کو بتانے دیں۔

دشواری: آسان · استعمال: تصور 4 (in-session لوپ)۔

بنائیں۔ اپنے repo میں ایک لمبا کام شروع کریں (مثلاً ایک script جو کچھ دیر sleep کرے اور پھر ایک فائل لکھے)۔ ایک in-session لوپ سیٹ کریں جو ہر منٹ جانچے کہ کام ختم ہوا یا نہیں، اور جیسے ہی ہو آپ کو بتا دے۔

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

✅Project 230-45 mintests کو pass کرائیں، پھر رکیںاس وقت تک لوپ کریں جب تک ایک کمانڈ — نہ کہ ایجنٹ — یہ طے کرے کہ کام ہو گیا۔

دشواری: آسان–درمیانی · استعمال: تصور 5 (run-until-done)، تصور 11 (maker–checker)۔

بنائیں۔ اپنے repo میں 2–3 چھوٹے ناکام tests ڈالیں۔ ایک ایسا لوپ بنائیں جو tests کے pass ہونے تک کام کرتا رہے — مگر "ہو گیا" کا فیصلہ کسی کمانڈ (test runner) کو کرنے دیں، ایجنٹ کو نہیں۔ اسے، مثلاً، 6 کوششوں پر cap کریں۔

مکمل جب لوپ اس لیے رکے کہ tests واقعی pass ہو گئے، اس لیے نہیں کہ یہ cap سے ٹکرا گیا۔ اگر یہ بار بار cap سے ٹکراتا ہے، تو آپ کی رکنے کی شرط یا آپ کے prompt میں کام درکار ہے — یہی سبق ہے۔

🧠Project 345-60 minmemory والا صبح کا خلاصہایک scheduled لوپ جس کا دوسرا run واضح طور پر اپنے پہلے پر تعمیر کرے۔

دشواری: درمیانی · استعمال: تصور 6 (بے توجہ schedule)، تصور 12 (ریڑھ کی ہڈی)۔

بنائیں۔ ایک scheduled لوپ بنائیں جو ایک بار چلے، ایک progress.md پڑھے، repo سے کوئی سادہ چیز جمع کرے (open TODO comments، یا پچھلے دن کے commits)، ایک مختصر خلاصہ لکھے، اور progress.md کو اس سے اپڈیٹ کرے جو اسے ملا اور تاریخ کے ساتھ۔

مکمل جب آپ اسے دو بار چلائیں اور دوسرا run واضح طور پر پہلے پر تعمیر کرے — یہ وہ نہ دہرائے جو پہلے ہی ریکارڈ کر چکا۔ یہ ثابت کرتا ہے کہ آپ کی ریڑھ کی ہڈی کام کرتی ہے۔ اگر دوسرا run صفر سے شروع ہو، تو آپ کے لوپ کی ابھی کوئی memory نہیں۔

🔍Project 41-2 hrsحقیقی checker والا ایک fix لوپایک implementer draft کرتا ہے، ایک علیحدہ reviewer grade کرتا ہے، اور صرف PASS ایک PR کھولتا ہے۔

دشواری: درمیانی–مشکل · استعمال: تصور 8 (worktree)، تصور 9 (skill)، تصور 11 (maker–checker)۔

بنائیں۔ حصہ 5 کے لوپ کا ایک چھوٹا نسخہ۔ اپنے fix قدموں کے ساتھ ایک مختصر skill لکھیں، اور ایک reviewer ایجنٹ جو PASS یا FAIL کہے۔ ایک حقیقی bug لیں، implementer سے اس کا fix اپنے checkout (worktree یا branch) میں draft کروائیں، اور reviewer سے اسے grade کروائیں۔ PR صرف PASS پر کھولیں۔

مکمل جب دو باتیں دونوں سچ ہوں: ایک اچھے fix کو PASS اور ایک PR ملے، اور ایک جان بوجھ کر لگائے گئے برے fix کو وجوہات کے ساتھ FAIL ملے۔ اگر reviewer برے fix کو pass کر دے، تو آپ کا checker بہت نرم ہے — اسے سخت کریں۔ ایسا checker جو ہر چیز منظور کرے، کوئی checker نہیں۔

🔁Project 52-4 hrsآپ کا اپنا روزانہ لوپایک حقیقی کام پر مکمل چھ حصوں والا لوپ، ایک ہفتے کے لیے بے توجہ چلایا گیا — capstone۔

دشواری: capstone · استعمال: تمام چھ حصے۔

بنائیں۔ کسی پروجیکٹ میں جس پر آپ واقعی کام کرتے ہیں، ایک حقیقی، بور کن، بار بار آنے والا کام چنیں — کوئی dependency audit، docs-freshness check، changelog draft، lint sweep۔ پورا لوپ بنائیں: heartbeat، worktree، skill، maker–checker، connector، اور ریڑھ کی ہڈی۔ budget guards شامل کریں۔ اسے چلنے دیں۔

مکمل جب یہ ایک ہفتے بے توجہ چل چکا ہو اور آپ جو یہ شِپ کرتا ہے اس پر بھروسہ کریں کیونکہ آپ نے اسے پڑھا — اس لیے نہیں کہ آپ نے پڑھنا چھوڑ دیا۔ پھر تصور 15 کا ایمانداری سے جواب دیں: کیا پروجیکٹ کی آپ کی سمجھ اس کے ساتھ چلتی رہی جو لوپ نے بدلا؟ اگر نہیں، تو لوپ کو اتنا سست کریں کہ چلتی رہے۔ (جب یہ رات بھر ناکام ہو — اور ہو گا — تو ماڈل کو الزام دینے سے پہلے جب آپ سو رہے ہوں اور کوئی لوپ ناکام ہو سے گزریں۔)

---

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

• بس schedule کی تفصیلات چاہئیں؟ reference صفحہ Scheduled Tasks: The Loop Skill and Cron Tools /loop، claude -p، opencode run، اور OS schedulers کو گہرائی سے بیان کرتا ہے۔
• غیر کوڈنگ کام کے لیے لوپ بنا رہے ہیں؟ Cowork & OpenWork فوری کورس پیشہ ور افراد کے لیے وہی دھڑکن کا خیال دکھاتا ہے، cron کے بجائے scheduled tasks کے ساتھ۔
• وہ spec جو آپ نے Spec-Driven Development میں لکھا ہی آپ کے لوپ کی رکنے کی شرط ہے: اس کے acceptance criteria وہی ہیں جن کے خلاف checker grade کرتا ہے اور جو /goal رکنے سے پہلے ثابت کرتا ہے۔ جب کوئی لوپ چھوڑ کر جانے کے لیے غیر محفوظ لگے، تو حل تقریباً ہمیشہ ایک تیز تر spec ہوتا ہے — زیادہ automation نہیں۔

Sources & further reading

یہ کورس بنیادی ذرائع کے ایک چھوٹے سیٹ پر ٹکا ہے۔ تشکیل اور اقتباسات انہی سے آتے ہیں؛ تکنیکی تفصیلات سرکاری docs سے آتی ہیں۔

"loop engineering" کی ابتدا

• Addy Osmani, Loop Engineering — وہ مضمون جس نے اس pattern کو نام دیا اور پانچ-حصے-جمع-ریڑھ کی ہڈی والا ماڈل پیش کیا۔ https://addyosmani.com/blog/loop-engineering/
• The New Stack, "The Anthropic leader who built Claude Code says he ditched prompting — now he just writes loops." https://thenewstack.io/loop-engineering/
• Boris Cherny کا "my job is to write loops" والا تبصرہ ایک CNBC interview سے ہے، جیسا Business Insider نے رپورٹ کیا۔ Peter Steinberger کی "design loops that prompt your agents" والی بات X پر ان کی ایک پوسٹ سے ہے۔

Claude Code (سرکاری docs)

• Routines — cloud scheduled automations، triggers، اور run caps: https://code.claude.com/docs/en/routines
• Channels — کسی چلتے ہوئے سیشن میں event-driven input: https://code.claude.com/docs/en/channels
• اس کتاب کا اپنا reference صفحہ، Scheduled Tasks: The Loop Skill and Cron Tools، /loop، /goal، اور claude -p پر گہرائی میں جاتا ہے۔

OpenCode (سرکاری docs)

• CLI — opencode run، serve، اور --attach: https://opencode.ai/docs/cli/
• Agents اور subagents — primary agents، subagents، اور فی ایجنٹ models: https://opencode.ai/docs/agents/
• GitHub integration — Action، schedule/PR/issue triggers، اور opencode github install: https://opencode.ai/docs/github/

Model identifiers

• Anthropic, Introducing Claude Sonnet 4.6 — claude-sonnet-4-6 model string کا ماخذ: https://www.anthropic.com/news/claude-sonnet-4-6
• Anthropic, Model IDs and versioning — کیوں dateless IDs (claude-sonnet-4-6) 4.6 نسل سے آگے pinned snapshot ہیں، جبکہ Haiku 4.5 جیسے 4.5 نسل کے ماڈلز ایک dated canonical ID (claude-haiku-4-5-20251001) کے ساتھ ساتھ ایک dateless alias رکھتے ہیں: https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions

تمام links جون 2026 تک موجودہ ہیں۔ یہ ٹولز اکثر اپڈیٹ ہوتے ہیں، تو کسی بھی مخصوص حد، flag، یا model string پر بھروسہ کرنے سے پہلے اسے live docs کے خلاف جانچ لیں۔

---

ایک لائن کا خلاصہ

اپنے ایجنٹ کو turn بہ turn prompt کرنا بند کریں۔ وہ لوپ ڈیزائن کریں جو آپ کی جگہ اسے prompt کرے — ایک دھڑکن، چار کام کرنے والے حصے، اور ایک ریڑھ کی ہڈی جو یاد رکھے — اور وہ انجینئر بنے رہیں جو پڑھتا ہے کہ یہ کیا شِپ کرتا ہے۔

Flashcards Study Aid

---

Test Your Understanding

Checking access...