Loop Engineering: Aik Crash Course

15 Concepts · Agentic coding se self-prompting systems tak

Aap aik coding agent chalana seekh chuke hain. Aap usay aik instruction dete hain. Woh aap ki files parhta hai, edits karta hai, aur aap result check karte hain. Aik turn, phir agla, phir agla. Aap saara waqt tool ko thaame rakhte hain.

Ab tasawwur karein ke aap usay thaamna chhor dete hain. Is ke bajaye, aap aik chhota system banate hain. Har subah woh jaagta hai, dekhta hai raat bhar mein kya badla, decide karta hai kya cheez karne layeq hai, har kaam aik agent ko deta hai, result check karta hai, aur sirf un faislon ke liye aap ko bulata hai jin ke liye waqai aik insan chahiye. Aap ne usay aik baar banaya. Us ke baad, woh khud ko prompt karta hai.

Yeh hai loop engineering. Qeemti skill us prompt se jo aap likhte hain hat kar us loop par chali jati hai jo aap design karte hain. Yeh course aap ko sikhata hai ke loop kis cheez se banta hai, aur usay dono Claude Code aur OpenCode mein kaise banana hai — jo do bahut alag raaston se aik hi jagah pohanchte hain.

Prerequisite: Claude Code aur OpenCode: Aik Crash Course. Us course ne aap ko plan mode, context management, rules file, skills, subagents, aur MCP sikhaye. Yeh course in sab ko maan kar chalta hai. Agar yeh alfaaz aap ke liye naye hain, to pehle woh course karein. Loop engineering seedhi us ke oopar bani hai. Behtar yeh hai ke aap ne Spec-Driven Development bhi kar liya ho: aik loop ki stopping condition dar-asal aik spec hi hoti hai, aur usi course mein aap ne aik spec likhna seekha — us ke baghair bhi aap saath chal sakte hain, lekin aap ke loops sirf utne hi achhe honge jitni achhi conditions aap specify kar sakte hain.

Naye hain? Jo aap ko pehle se pata hona chahiye us ka 2-minute recap

• Plan mode — agent aap ki files parhta hai aur kuch badalne se pehle aik plan propose karta hai; aap pehle approve karte hain.
• Rules file (CLAUDE.md / AGENTS.md) — chhote, permanent project notes jo agent har session ke shuru mein parhta hai.
• Skills (SKILL.md) — aik saved, reusable instruction jo agent sirf tab load karta hai jab task us se match kare.
• Subagents — aik alag helper jis ki apni context window hoti hai jo aik kaam karta hai aur sirf result wapas deta hai.
• Connectors / MCP — aik agent ko bahar wale tools se jorne ka standard tareeqa: GitHub, Slack, aik database.
• Context management — conversation ko halka rakhein; jaise jaise yeh bharta hai model bigarta hai aur zyada mehenga parta hai.

Agar in mein se koi naye hain, to pehle agentic coding crash course karein — yeh seedha us ke oopar banta hai.

Yeh kahan se aaya

2026 ke darmiyan mein, jo log yeh tools banate hain unhon ne saaf kaha. Boris Cherny, jis ne Claude Code banaya, us ne yun kaha: "Main ab Claude ko prompt nahin karta. Mere paas loops chal rahe hain jo Claude ko prompt karte hain... mera kaam loops likhna hai." Peter Steinberger (OpenClaw) ne kaha "aap ko aise loops design karne chahiye jo aap ke agents ko prompt karein." Phir Addy Osmani ne is pattern ko naam diya aur is ki parts ginwayin. In mein se koi nahin kehta ke kaam asaan ho gaya. Woh kehte hain ke qeemti skill apni jagah badal gayi. Yahi woh idea hai jis par yeh poora course bana hai. (Is course ki har quote aur claim ki source aakhir mein Sources & further reading mein hai.)

The mindset shift, in one picture

Yeh course do tools ko saath saath cover karta hai, usi wajah se jis wajah se pichla: agar koi technique dono mein chalti hai, to woh aik asli skill hai, aik tool ka trick nahin. Lekin yahan dono tools waqai farq rakhte hain, aur woh farq khud aik sabaq hai. Claude Code ab loop ki parts product ke andar ship karta hai. OpenCode aap ko neeche wali layer deta hai — aik worker jise aap operating system se shuru karte hain. Aap dono dekhein ge. Aap yeh bhi dekhein ge ke loop ki shape wohi hai, chahe wiring na ho.

June 2026 tak current. Dono tools tezi se badalte hain, aur Claude Code ki kaeyi loop features research preview mein hain. Kisi bhi session se pehle, claude update ya opencode upgrade chalayein. Kisi limit ya flag par bharosa karne se pehle live docs (code.claude.com/docs, opencode.ai/docs) dekhein.

Pehle, aik sachhi baat ke loops kahan chal sakte hain

Aik asli loop un-attended hota hai — woh aap ke door hote hue khud ko prompt karta hai. Sada claude.ai chat box yeh nahin kar sakta: woh har turn aap ka intezaar karta hai, is liye chat mein aap hi schedule hain. Aik asli loop chalane ke liye aap ko aik aisa tool chahiye jo khud se fire kar sake: Claude Code, OpenCode, ya Cowork (Cowork crash course dekhein). Zyada tar paid hain, aur kaeyi aaj research previews hain. Aap aik loop ko kahin bhi seekh aur design kar sakte hain; usay chalane ke liye aap ko in tools mein se aik chahiye. Yeh course do coding wale dikhata hai.

"Lekin main ne poora Spec-Driven course claude.ai mein kiya — kya main wahan bhi loop chala sakta hun?"

Wajib sawaal hai, kyunke "claude.ai" dar-asal do cheezein hai. Chhota jawab: chat box loop nahin chala sakta, lekin Claude Code — jo usi claude.ai account mein rehta hai — chala sakta hai.

• Chat conversation har turn par aap ka intezaar karti hai aur us ke paas schedule ya event par fire hone ka koi tareeqa nahin. Aap usay haath se dobara prompt karte reh sakte hain, lekin phir aap hi heartbeat hain — wohi kaam jo aik loop khatam karta hai.
• Claude Code usi login se reach mein hai. Is ki cloud Routines (jo claude.ai/code/routines par banti hain) Anthropic ke servers par chalti hain chahe aap ka laptop band ho, baghair kuch local install kiye — to is maani mein aap "claude.ai se" aik asli, un-attended loop khara kar sakte hain. Is ke liye paid plan chahiye aur yeh aaj research preview hai.
• OpenCode wohi cheez aap ke apne scheduler (cron, GitHub Actions) ke saath karta hai.

To chat woh jagah hai jahan aap aik loop ko design aur rehearse karte hain — skill draft karein, reviewer prompt likhein, stopping condition pin karein, aik beat haath se chalayein — aur Claude Code ya OpenCode woh jagah hai jahan aap usay chalate hain. Woh hand-off Spec-Driven Development ke baad qudrati agla qadam hai.

Parhte hue try karein

Yahan se aage, takreeban har concept aisa hai jise aap aik asli session mein chala sakte hain, sirf parhne ke liye nahin. Is page ke saath aik terminal khula rakhein (claude ya opencode) aur har idea jab aap us tak pohanchein use try karein. Aik chhote, throwaway git repo se shuru karein taake koi loop us cheez ko nuqsaan na pohancha sake jis ki aap ko parwah hai.

What this course covers​

Part	Topic	Aap kya seekhte hain
1	The Shift	Aik loop kya hai, is ki chhe parts, aur usay banane ke do raaste
2	The Heartbeat	Kisi cheez ko khud se chalana: in-session, run-until-done, scheduled, event-driven
3	The Body	Isolation, knowledge, action, aur maker–checker split
4	The Spine	Woh state jo runs ke darmiyan zinda rehti hai — wohi hissa jise log bhool jate hain
5	A Loop, Twice	Aik poora morning-triage-to-PR loop, asli files ke saath, dono tools mein bana
6	Staying the Engineer	Token cost, kaam ka check, aur woh traps jo loops behtar hone ke saath barhte hain
Practice	Practice projects	Paanch loops, asaan se mushkil, jo aap khud banate hain

Karte hue seekhna chahte hain? Pehle Part 5 parhein taake aik poora loop shuru se aakhir tak dekhein, phir parts ke liye wapas aayein. Jab concepts samajh aa jayein, to Practice projects aap ko khud banane ke liye paanch loops dete hain.

Is poore ko parhne ke liye takreeban do ghante rakhein. Part 5 aur practice projects banane mein zyada waqt lagta hai — yahi point hai: aap loops bana rahe hain, un par sarsari nazar nahin daal rahe.

Kya rakhna hai, aur kya look up karna hai

Is course mein do layers chalti hain, aur woh bahut alag tareeqe se purani hoti hain. Pehli ko internalize karein; doosri ko look up karein.

• Durable layer. Aik loop ki shape (aik heartbeat, chaar working parts, aur aik spine), maker–checker split, aur do siray jo aik loop kabhi automate nahin kar sakta: intent (itni theek se yeh kehna ke aap kya chahte hain ke result check ho sake) aur accountability (jo ship hota hai us ka zimma lena). Yeh skill hai. Yeh neeche di gayi har command badal jane ke baad bhi sach rehti hai.
• Mechanical layer. Har flag, path, model ID, aur command name. Yeh tools weekly updates ship karte hain aur yahan kaeyi features research previews hain, to har specific command ko aik fact yaad karne ke bajaye live docs ki taraf aik pointer samjhein. Jahan yeh course aur current docs ikhtelaf karein, docs jeetti hain.

Chhe-hisson wali shape yaad rakhein aur har keystroke bhool jayein, to aap ne loop engineering seekh li. Keystrokes yaad kar lein aur shape miss kar dein, to aap ne is mahine ki CLI seekhi.

---

📚 Teaching Aid​

Open Full Slideshow

View Full Presentation — Loop Engineering: Aik Crash Course

---

Part 1: The Shift​

1. From prompting to looping​

Takreeban do saal tak, aik coding agent se kaam lene ka tareeqa sada tha. Aik achha prompt likhein. Usay kaafi context dein. Jo wapas aaye usay parhein. Agli cheez type karein. Agent aik tool tha, aur aap usay aik waqt mein aik turn istemaal karte thay.

Aik loop aap, operator, ki jagah aik system le aata hai. Yeh system kaam dhoondta hai, usay baant-ta hai, check karta hai, jo us ne kiya us ko likhta hai, aur decide karta hai ke agla kya hai. Yeh agent ko prompt karta hai, taake aap ko na karna pare.

To value kahan jati hai? Khatam nahin hoti. Yeh do siron par bant jati hai jo aik loop automate nahin kar sakta: intent — theek theek yeh kehna ke aap kya chahte hain, itni saaf ke result check ho sake — aur accountability — jo bahar aata hai us ke peechhe khare rehna. Loop darmiyan ko, steps ko, automate karta hai; siray aap ke rehte hain. Aap intent aur judgment ke liye paid hote hain, is ke liye nahin ke kaam kaise bana us se ankhein chura lein.

Farq "aik bara prompt" nahin hai. Yeh kaam ki aik alag shape hai:

Prompting (jo aap jaante hain)	Looping (jo yeh course add karta hai)
Aap har turn shuru karte hain	Aik schedule ya aik event har turn shuru karta hai
Aap output parh kar decide karte hain ke aage kya	Aik checker output check karta hai; loop decide karta hai ke aage kya
Jis lamhe aap type karna roken, ruk jata hai	Jab tak aap sote hain chalta rehta hai
Aik task, aik session, aap ki poori tawajjuh	Bahut si chhoti runs, zyada tar un-attended, aap ki tawajjuh sirf gate par

Yeh jaadu nahin hai, aur yeh "set it and forget it" bhi nahin. Aik loop jo khud se chalta hai woh aik loop bhi hai jo khud se ghaltiyan karta hai. Is course mein har cheez is liye hai ke aik aisa loop bane jise aap waqai bharosa kar sakein ke woh aap ke baghair chal sakta hai. Yeh prompting se mushkil hai, asaan nahin. Inaam leverage hai: aik achha loop aap ke liye baar baar kaam karta hai, woh kaam jo warna aap ko har baar haath se shuru karna parta.

2. What a loop is made of​

Aik loop jo waqai khud se chalta hai us ki paanch parts aur aik spine hoti hai. Aap paanch mein se chaar agentic coding course mein mil chuke hain. Yahan woh aik naya kaam le lete hain.

1. Heartbeat — aik schedule (ya aik event) jo loop shuru karta hai. Is ke baghair, aap ke paas aik single run hai, loop nahin.
2. Worktree — isolation, taake do agents jo aik saath kaam karte hain woh aik doosre ki files par na likhein.
3. Skill — aap ka project knowledge aik baar likha gaya, taake har run sifr se shuru na ho.
4. Sub-agents — maker–checker split: jo agent code likhta hai woh agent nahin jo usay grade karta hai.
5. Connector (MCP) — taake loop aap ke asli tools mein act kar sake (PR kholна, ticket update karna), sirf mashwara na de.

Aur chhata, jo woh hai jise beginners chhor dete hain:

6. State / Memory — spine. Disk par aik file (ya Linear jaisa aik board) jo rakhti hai ke kya ho gaya aur kya aage hai. Model har run ke darmiyan sab kuch bhool jata hai. Spine woh tareeqa hai jis se aaj ki run ko pata hota hai ke kal ki run ne kya kiya. No spine, no loop — bas wohi pehla step, hamesha ke liye repeat hota hua.

Course ka baqi hissa har part ke liye aik section hai, phir aik poora example jo un ko jorta hai.

3. Two roads: ships-the-parts vs the-layer-below

Yeh woh aik jagah hai jahan tools waqai farq rakhte hain, aur yeh us sab ko shape deta hai jo aage aata hai.

Claude Code loop ki parts product ke andar ship karta hai. Heartbeat (/loop, /schedule, cloud Routines), built-in checker ke saath run-until-done (/goal), isolation (--worktree), event intake (Channels) — yeh sab ab built-in commands hain. Aik saal pehle aap ne yeh paane ke liye shell scripts ka aik dher likha aur sambhala hota. Aaj aap zyada tar bas usay set up karte hain.

Main aik Routines hai: cloud automations jo Anthropic ke servers par chalti hain chahe aap ka laptop band ho, aik schedule, aik API call, ya aik GitHub event se shuru hoti hain. Is aasani ki qeemat per-account daily run caps hain (apni current limit Routines usage UI mein check karein, kisi fixed number par bharosa karne ke bajaye), saath hi yeh ke Routines aik research preview hain jo ab bhi badal sakti hain.

OpenCode aap ko neeche wali layer deta hai. Koi built-in cloud scheduler nahin. Is ke bajaye, OpenCode woh worker hai jise aap call karte hain, aur aap heartbeat laate hain — operating system se ya CI se.

Key command opencode run "<prompt>" hai. Yeh aik prompt ko bina chat screen ke chalata hai, result print karta hai, aur exit ho jata hai. Woh aik command aik loop ki aik beat hai. Aap usay aik loop banate hain usay kisi aisi cheez mein lapet kar jo timer par fire ho: cron ya launchd (macOS aur Linux), Task Scheduler (Windows), ya schedule trigger ke saath GitHub Actions. Yeh zyada wiring hai, lekin aap ko poora control milta hai, yeh un machines par chalta hai jo aap ke paas pehle se hain, aur isay kisi vendor cloud ki zaroorat nahin.

Skill loop hai, keybind nahin

Ghaur karein ke dono tabs wohi paanch parts bayan karte hain. Aik heartbeat aik heartbeat hai, chahe woh aik managed Routine ho ya cron mein aik line. Maker–checker split wohi idea hai, chahe /goal usay grade kare ya aik doosra opencode run. Loop ki shape aik baar seekh lein aur yeh transfer ho jati hai. Isi liye hum dono sikhate hain.

Where we are going (the whole loop, early)

Parts se pehle, yeh raha finish line. Woh loop jo aap Part 5 mein banayein ge woh chhe sade steps hai:

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

Yeh tasveer zehan mein rakhein. Parts 2–4 mein har concept is ki aik line hai.

Check yourself

Aik loop har subah chalta hai, lekin har run taza shuru hoti hai aur kabhi yaad nahin rakhti ke us ne kal kya kiya. Chhe parts mein se kaun si missing hai — aur yeh loop ko kyun torr deti hai?

Show answer

Spine (state / memory). Model har run ke darmiyan sab kuch bhool jata hai, to disk par koi state file na hone par loop kal ke kaam par build karne ke bajaye apna pehla step hamesha repeat karta rehta hai.

---

Part 2: The Heartbeat​

Heartbeat woh hai jo aik run ko aik loop bana deta hai. Chaar tarah ke hote hain, "is session mein rehta hai" se le kar "aap ke baghair bil-kul chalta hai" tak. Inhein tarteeb se seekhein — zyada tar asli loops aakhri do istemaal karte hain.

Aik idea in chaaron ke neeche hai: aik loop koi single action nahin. Yeh yeh karo, ruko, phir se karo hai, baar baar, is liye kisi cheez ko beats ke darmiyan jaagta rehna hota hai taake woh agli beat fire kar sake. Sirf sawaal yeh hai ke woh cheez kahan rehti hai.

• Aik in-session loop apna timer aap ki khuli session mein rakhta hai — woh process jo aap ka terminal khula rehne tak chalta rehta hai. Session band karein aur timer thaame hui cheez chali jati hai, to loop ruk jata hai.
• Aik scheduled task ya Routine (yeh aap Concept 6 mein banate hain) timer ko session ke bahar le jata hai, aik aise scheduler par jo kabhi nahin sota (aap ki apni machine par cron, ya cloud Routine ke liye Anthropic ke servers). Har tick par yeh aik bilkul naya, chhoti-umar wala run launch karta hai, usay khatam hone deta hai, aur band kar deta hai, phir agli baar aik taza launch karta hai. Wohi loop, lekin aap ki koi cheez khuli rehne ki zaroorat nahin.

Heartbeat	Timer kahan rehta hai	Beats ke darmiyan kya jaagta rehta hai
In-session /loop	session ke andar	aap ki khuli session (aap ki machine, terminal khula)
Scheduled task / Routine	bahar, aik scheduler mein	scheduler, jo har tick aik taza run launch karta hai

Yeh tasveer bhi zehan mein rakhein. Yeh aage aane wali har limit samjhati hai: aik in-session loop tab rukta hai jab is ki session rukti hai, aur aik loop jise band laptop se bacha rehna hai usay bahar wali qism chahiye (Concept 6).

4. In-session loops (repeat while you watch)

Sab se sada heartbeat: aik prompt ko timer par dobara chalana jab tak session khula hai. "Is ko khatam hone tak watch karein" ke liye achha — aik deploy, aik lamba test run, aik CI job.

Bundled /loop skill istemaal karein. Usay aik interval aur aik prompt dein:

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

Claude interval ko aik schedule mein badal deta hai, job ko aik ID deta hai, aur jab tak session khula rehta hai prompt ko har 5 minute chalata hai. Jab aap fareegh ho jayein, usay cancel karein aur aage barhein.

Aik limit jaanna chahiye: /loop jaan boojh kar session ke andar rehta hai. Terminal band karein, ya laptop ko sone dein, aur yeh ruk jata hai. Yeh aik safety feature hai, bug nahin — aik casual in-session loop ko session se zyada nahin jeena chahiye. Aisi cheez ke liye jo chalti rahe, aik scheduled task ya aik Routine istemaal karein (Concept 6).

OpenCode mein koi /loop command nahin. Aap timer khud shell se banate hain. Chunke opencode run aik prompt ke baad exit ho jata hai, sleep ke saath aik while loop wohi kaam karta hai:

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

Yeh /loop jaisa hi idea hai, aik layer neeche: shell heartbeat hai, aur opencode run beat hai. Har taza opencode run aik bhi cheez karne se pehle poore runtime ko pehle boot karta hai — config, model, plugins, aur koi bhi MCP servers. Har beat par yeh start-up cost na dene ke liye, aik server aik baar shuru karein aur us se attach karein:

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

/loop cancel karna. Har loop ek ID wala scheduled task hai, is liye aap use usi tarah rokte hain jis tarah shuru kiya tha: seedhi zaban mein.

show my running loops
cancel the deploy-check loop

Claude task dhoond kar cancel kar deta hai. Agar kai loops chal rahe hon to woh poochega ke kaunsa rokna hai, ya aap task ID seedha de sakte hain. Session band karna bhi aam session loop ko rok deta hai, lekin cancel karna saaf tareeqa hai: jis loop ko aap rokna chahte thay usay session band hone par depend nahin karna chahiye. Theek subcommands mechanical layer hain; agar seedhi zaban kaam na kare to code.claude.com/docs/en/scheduled-tasks par live docs dekhein.

اوپن کوڈ کے لیے، Ctrl-C کے ساتھ ایک پیش منظر کا لوپ بند کرو؛ اگر یہ پس منظر میں چلتا ہے، تو اس کے عمل کو ختم کر دیں۔ /گول کے لیے، علیحدہ چیکر صرف گفتگو پڑھ سکتا ہے: کلاڈ کو ٹیسٹ چلانا چاہیے اور آؤٹ پٹ دکھانا چاہیے، یا چیکر یہ ثابت نہیں کر سکتا کہ ہدف پورا ہو گیا ہے۔ ایک رالف لوپ ایک پرامپٹ کو دہراتا ہے اور ایک اسٹیٹ فائل کو اپ ڈیٹ کرتا ہے۔ کمانڈ کی تصدیق کے قابل کامیابی کی شرط کے بغیر، یہ اس وقت تک گھومتا رہتا ہے جب تک کہ اس کا ٹائم کیپ ختم نہ ہو جائے۔

5. Run-until-done (the loop decides when to stop)

Fixed-timer loop ghari ke mutabiq baar baar chalta hai jab tak aap use cancel na karein ya session khatam na ho. Har run koi result check kar sakta hai, lekin us result ko parh kar loop rokne wala kuch nahin hota. Run-until-done conditional loop tab rukta hai jab koi independent check sabit kar de ke kaam mukammal hai. Farq runs ki tadaad ka nahin: pehla nahin janta ke kaam kab mukammal hua, doosra kaam mukammal hone ki wajah se rukta hai.

Aik fixed-timer loop jaan boojh kar sada hai — yeh N baar fire hota hai chahe kuch bhi ho. Aksar jo aap waqai chahte hain woh hai "jab tak yeh sach na ho jaye chalte raho." Yahan maker–checker idea pehli baar zahir hota hai: loop ko us agent ko decide nahin karne dena chahiye ke kaam ho gaya jis ne kaam kiya.

/goal istemaal karein. Aap usay aik stopping condition dete hain jise Claude apne hi output mein sabit kar sake — aisi cheez jo woh aik command chala kar aur result surface kar ke dikhata hai, jaise "test/auth mein saare tests pass karein." Yeh turns ke aar-paar kaam karta rehta hai jab tak woh condition poori na ho. Ahem hissa: har turn ke baad aik alag, chhota model (default mein Haiku) transcript parhta hai aur decide karta hai "kya hum ho gaye?" To jis agent ne code likha woh agent nahin jo usay grade karta hai. Aik subtlety jaanne layeq: woh checker khud commands nahin chalata — woh us cheez ko judge karta hai jo Claude pehle hi surface kar chuka hai — to condition aisi honi chahiye jo Claude ka apna output dikha sake, na ke aik private fact jo sirf aik command zahir karti.

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

Yeh edit karega, tests chalayega, failures parhega, dobara try karega, aur sirf tab ruke ga jab checker confirm kar de ke condition waqai poori ho gayi — ya jab aap khud usay /goal clear se roken. Koi built-in "N tries ke baad chhor do" nahin: agar aap aik ceiling chahte hain, to usay condition mein likhein (…or stop after 20 turns). Aisi conditions likhein jo aik command sabit kar sake — "tests pass aur lint clean hai," na ke "auth code achha hai." Yahan Spec-Driven Development ki spec faida deti hai: is ke acceptance criteria pehle se aisi conditions hain jo aik command sabit kar sakti hai, to aik achhi spec aap ko muft mein stopping condition de deti hai.

OpenCode mein koi /goal nahin, to aap wohi maker–checker stop shell aur exit codes se banate hain. Pattern: agent kaam karta hai, phir aik asli command (agent nahin) decide karti hai ke rukna hai ya nahin.

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

Yahan test runner aur linter checker hain — sab se honest checker jo hai, kyunke aik command khud ko qaeel nahin kar sakti ke kaam theek hai. Aik smarter check ke liye, aik dedicated review agent (Concept 11) ke saath aik doosra opencode run chalayein aur us se PASS ya FAIL print karwayein. Hamesha tries cap karein; aik loop jo bina limit retry karta hai wohi tareeqa hai jis se token bills control se bahar barhti hain.

Aik loop ko hamesha rukne ka raasta dein

Har loop ko teen stops chahiye. Har aik kisi ek makhsoos tareeqe se fail hone se bachata hai:

Stop	Yeh kya hai	Ise chhor dein, to…
Success condition	loop kaise jaanta hai ke kaam ho gaya	"done" ki koi tareef nahin, to loop na jaan boojh kar ruk sakta hai na grade ho sakta hai
Limit	aik had (ceiling): max tries, max minutes, ya max spend	aik aisa goal jise woh nahin pohanch sakta aap ka saara token budget jala deta hai
No-progress check	pakrein jab agent wohi action wohi arguments ke saath dohraye (woh atak gaya hai; dobara try karne se theek nahin hoga)	woh saari limit aik hi ghalti dohrate hue kharch kar deta hai

Aik naam jo aap ko online milega: Ralph loop. Sab se sada mash'hoor run-until-done loop: yeh wohi prompt baar baar chalata hai, har run aik state file parhte aur update karte hue. Yeh teen mein se sirf do stops rakhta hai (aik success condition aur aik time cap), koi stuck-check nahin, koi skill nahin, aur koi alag checker nahin. Yehi saadgi wajah hai ke yeh sabaq itni saaf sikhata hai. Aik Ralph loop jis ki condition dhundli ho woh time cap khatam hone tak bhatakta rehta hai; wohi loop aik aisi condition ke saath jise aik command sabit kar sake achha kaam karta hai.

Loop utna hi achha hai jitni is ki stopping condition.

Lambe runs waqt ke saath bigarte hain

Aik run-until-done loop jo kai turns tak chalta hai woh apni hi context ko koore se bhar deta hai: purana tool output, band raaste, aur baasi reasoning. Jaise jaise yeh dher barhta hai, model ke jawab bigarte jate hain. Community is nateeje ko doom loop kehti hai: gandi context aik bure faisle ki taraf le jati hai, jo aur gandagi barhata hai, jo agle faisle ko aur bhi bura bana deta hai. Bachao wohi context aadaat hain jo agentic coding course se hain:

• Lambe runs ko compact karein: thori thori der baad, kachche baat-cheet ko us cheez ke aik chhote summary se badal dein jo hui, taake context chhoti rahe.
• Bare outputs ko files mein le jayein: bare nataaij (logs, data, generate kiya gaya text) ko aik file mein likhein aur context mein sirf aik pointer rakhein, poori cheez paste karne ke bajaye.
• Gande subtasks aik subagent ko dein: aik helper ko apni hi context mein gandi khoj-been karne dein aur sirf saaf jawab wapas dilwayein.

Teenon ke peechhe aik idea: context ko aik budget samjhein jo aap jaan boojh kar kharch karte hain, na ke aik balti jis mein aap dalte rehte hain. Aik chhoti, saaf context hi aik lambe run ke faislon ko tez rakhti hai.

6. Unattended schedules (runs while you sleep)​

Yeh woh heartbeat hai jo loop engineering ko maani deta hai: aik task jo chalta hai chahe aap computer par hon ya na hon. "Har weekday 9am par, raat bhar ki CI failures chhantein." "Har Monday, dependencies check karein aur safe fixes ke saath aik PR kholein."

کلاؤڈ کو شیڈول پر چلانے کے تین طریقے ہیں۔ ان کے درمیان ایک سوال پیدا ہوتا ہے: کام کہاں چلتا ہے؟ اینتھروپک کے سرورز پر، ڈیسک ٹاپ ایپ کے ذریعے آپ کی مشین پر، یا آپ کے اپنے شیڈولر کے ذریعے آپ کی مشین پر۔ انہیں اس ترتیب میں لے لو - پہلا وہ ہے جسے زیادہ تر لوگوں کو اچھی طرح سے سیکھنا چاہئے۔

1. کلاؤڈ روٹینز — لیپ ٹاپ بند ہو سکتا ہے۔

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

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

ہر روٹین کے چار حصے

جب آپ روٹین بناتے ہیں، تو آپ چار خالی جگہیں بھر رہے ہوتے ہیں۔ ہر ایک ایک سوال کا جواب دیتا ہے - وہ یہاں ہیں، ہماری صبح کی آزمائش کی مثال کے ساتھ:

1. پرامپٹ — اسے کیا کرنا چاہیے؟ کھڑی ہدایت خود، جس طرح سے آپ نے مخصوص اسباق میں سیکھا ہے لکھا ہے: مقصد، اصول، "کیا" کیسا لگتا ہے۔ یہ ہر رن پر ایک ہی اشارہ ہے، لہذا یہ آپ کی غیر موجودگی سے بچنا چاہیے - آپ واضح کرنے کے لیے وہاں نہیں ہوں گے۔

   مثال کا اشارہ: "پچھلے 24 گھنٹوں میں کھولے گئے تمام ایشوز کا جائزہ لیں۔ ہر ایک کو bug، feature-request، یا question کے بطور لیبل کریں۔ اگر کوئی مسئلہ کریش یا ڈیٹا کے نقصان کی وضاحت کرتا ہے، تو urgent لیبل شامل کریں۔ پھر #triage Slack پر ایک خلاصہ پوسٹ کریں، اگر فی چینل کتنے نئے مسائل ہیں، تو کل کتنے مسائل ہیں۔ کوئی نیا مسئلہ نہیں، پوسٹ 'راتوں رات کوئی نیا مسئلہ نہیں'۔ کسی بھی مسئلے پر بند یا تبصرہ نہ کریں۔"

   کام پر مخصوص اناٹومی پر غور کریں: ایک مقصد (ٹریج اور خلاصہ)، قواعد (ان طریقوں کو لیبل کریں، فوری مطلب کریش/ڈیٹا نقصان)، ایک باؤنڈری (بند نہ کریں یا تبصرہ نہ کریں)، اور خالی کیس کے لیے بھی ایک متعین "ہو گیا"۔

2. ریپوز — یہ کس چیز کو چھو سکتا ہے؟ آپ ان ریپوزٹریوں کا نام دیتے ہیں جن میں روٹین کو کام کرنے کی اجازت ہے۔ جو کچھ بھی آپ فہرست میں نہیں لاتے وہ آپ کی پہنچ سے باہر ہے۔

   مثال: آپ yourteam/product-app عطا کرتے ہیں — اور صرف اتنا۔ آپ کے دیگر پانچ ریپوز، بشمول بلنگ کوڈ کے ساتھ، جہاں تک اس روٹین کا تعلق ہے، صرف موجود نہیں ہے۔

3. کنیکٹر — یہ کس چیز تک پہنچ سکتا ہے؟ سلیک، ای میل، کیلنڈرز — روٹین کے ہاتھ ریپو سے آگے: یہ باہر کی دنیا کو کیسے پڑھتا ہے اور آپ کو کیسے رپورٹ کرتا ہے۔

   مثال: آپ Slack کنیکٹر کو منسلک کرتے ہیں تاکہ یہ #triage پر پوسٹ کر سکے۔ کوئی ای میل کنیکٹر منسلک نہیں ہے - لہذا یہ ای میل نہیں بھیج سکتا ہے چاہے پرامپٹ نے اسے کہا ہو۔ کنیکٹر اجازتیں ہیں، تجاویز نہیں۔

4. متحرک - یہ کب بیدار ہوتا ہے؟ دل کی دھڑکن۔ تین قسمیں، اور ہر ایک کام کی مختلف شکل کے مطابق ہے:

   • ایک شیڈول — گھڑی اسے جگاتی ہے۔ ہماری مثال: ہر ہفتے کے دن صبح 8:30 بجے، لہذا ٹیم کے بیٹھنے سے پہلے سمری سلیک میں انتظار کر رہی ہے۔
   • ایک API کال — ایک اور پروگرام اسے جگاتا ہے۔ مثال: آپ کی تعیناتی کا اسکرپٹ ایک ریلیز کو ختم کرتا ہے، پھر روٹین کے API اینڈ پوائنٹ کو کال کرتا ہے تاکہ "اسموک چیک دی ریلیز اور رپورٹ" رن کو متحرک کیا جا سکے — روٹین بالکل اسی وقت چلتی ہے جب چیک کرنے کے لیے کچھ ہوتا ہے، نہ کہ گونگے ٹائمر پر۔
   • ایک GitHub ایونٹ — ریپو اسے جگاتا ہے۔ مثال: ایک روٹین جو "پل کی درخواست کھولی گئی" سے شروع ہوتی ہے جو آپ کی ٹیم کی چیک لسٹ کے خلاف ہر نئے PR کا جائزہ لیتی ہے اور ایک منظم تبصرہ چھوڑتی ہے — یہ خاموش دن میں صفر بار اور مصروف دن میں نو بار چلتا ہے۔

پرامپٹ، ریپوز، کنیکٹر، ٹرگر۔ کیا کرنا ہے، یہ کہاں کام کر سکتا ہے، یہ کس تک پہنچ سکتا ہے، جب یہ جاگتا ہے۔ ہر روٹین کے وہ چار جواب ہوتے ہیں — اور ہمارے صبح کی آزمائشی کارکن کو اب مکمل طور پر بیان کر دیا گیا ہے: اوپر پرامپٹ، ایک ریپو، ایک سلیک کنیکٹر، ہفتے کے دن 8:30 بجے۔

ایک خصوصیت، تین دروازے

آپ تین جگہوں پر روٹین بنا سکتے ہیں: براؤزر میں claude.ai/code/routines پر، ڈیسک ٹاپ ایپ میں، یا CLI میں /schedule کمانڈ کے ساتھ۔ یہ تین مختلف خصوصیات نہیں ہیں — تینوں دروازے ایک ہی کمرے میں کھلتے ہیں۔ آپ کی ہر روٹین، کسی بھی دروازے سے، ایک ہی کلاؤڈ اکاؤنٹ میں محفوظ کی جاتی ہے اور تینوں جگہوں پر ظاہر ہوتی ہے۔

اس کی اہمیت کیوں ہے اس کی مثال: آپ منگل کو اپنے ٹرمینل میں /schedule کے ساتھ ٹرائیج روٹین کا خاکہ بناتے ہیں، پھر جمعرات کو — اپنے فون کے براؤزر پر، بس میں — آپ claude.ai/code/routines کھولتے ہیں، وہی روٹین دیکھیں، اور اس کے پرامپٹ میں ترمیم کریں۔ ایک ہی کمرہ، مختلف دروازے۔

رن پر اصل میں کیا ہوتا ہے۔

پیر کو 8:30 بجے، Anthropic کے سرورز ایک تازہ کلاڈ سیشن شروع کرتے ہیں، اسے اپنا پرامپٹ دیتے ہیں، اور اسے آپ کے درج کردہ ریپو اور سلیک کنیکٹر تک رسائی فراہم کرتے ہیں۔ یہ ویک اینڈ کے ایشوز کو پڑھتا ہے، ان پر لیبل لگاتا ہے، #triage پر پوسٹ کرتا ہے — کہئے: "7 نئے مسائل، 1 فوری: اینڈرائیڈ پر لاگ ان کریش (#412)" — اور بند ہو جاتا ہے۔ منگل کو 8:30 پر، مکمل طور پر تازہ دوڑ شروع ہوتی ہے۔ پیر کا سیشن ختم ہو گیا ہے۔ آپ کی مشین پر کسی چیز کا انحصار نہیں ہے — یہ وہ خاصیت ہے جو روٹین کو ایک حقیقی لوپ بناتی ہے بجائے اس کے کہ آپ کو بیبی سیٹ کرنا پڑے۔

اس پر بھروسہ کرنے سے پہلے جاننے کے لیے دو اصول

ایک اصول: روزانہ کیپ ہوتی ہے۔ ہر اکاؤنٹ کو روزانہ ایک مقررہ تعداد میں روٹین رنز ملتے ہیں — لانچ کے وقت، پرو پر 5، میکس پر 15، ٹیم اور انٹرپرائز پر 25۔ ٹوپی کیوں؟ کیونکہ کسی اور کے سرورز پر چلنے والے ایک غیر حاضر نظام کا بجٹ ہونا ضروری ہے۔ یہ ہر کلاؤڈ سروس کے بارے میں سچ ہے، اور یہ ایک ایسا نمبر ہے جس کے ارد گرد آپ ڈیزائن کرتے ہیں، یہ کوئی تعجب نہیں کہ آپ کو دریافت ہوتا ہے۔

پرو اکاؤنٹ پر بجٹ کی مثال (5 رنز فی دن): صبح کا ٹرائیج (1 رن) + ایک شام "آج کی کمٹ کا خلاصہ کریں" رپورٹ (1 رن) + 4 پل درخواستوں (4 رنز) = 6 رنز کے ساتھ ایک دن میں PR-جائزہ کا معمول۔ آپ ایک اوور ہیں۔ آپ کے اختیارات، ترجیح کے لحاظ سے: روزانہ کی دو رپورٹس کو ایک روٹین میں ضم کریں (ایک رن بچاتا ہے)، PR جائزہ لینے والے کو وہ چیز بننے دیں جو آپ مصروف دنوں میں اضافی استعمال خریدتے ہیں، یا پلان کو اپ گریڈ کریں۔ نقطہ یہ ہے کہ آپ نے یہ ریاضی اس سے پہلے کیا کہ لوپ خاموشی سے رن فائیو پر رک گیا۔

تین تفصیلات ٹوپی کو نرم کرتی ہیں: وہ لانچ کے وقت کے نمبر ہیں، لہذا موجودہ نمبروں کے لیے claude.ai/settings/usage چیک کریں۔ یک طرفہ طے شدہ رنز شمار نہیں ہوتے؛ اور آپ اس کے بعد اضافی استعمال کی ادائیگی کر سکتے ہیں۔

قاعدہ دو: یہ صرف claude/ برانچوں کو ہی آگے بڑھا سکتا ہے — بذریعہ ڈیفالٹ۔ ایک تازہ روٹین main کو نہیں لکھ سکتی۔ ہر شاخ جو اسے آگے بڑھاتی ہے اسے claude/ کے سابقہ ​​سے شروع ہونا چاہئے۔ یہ کام کرنے کی کوئی حد نہیں ہے۔ یہ وہ گارڈریل ہے جو پہلے دن بغیر دیکھے جانے والے آپریشن کو محفوظ بناتا ہے: روٹین وہ تمام کام کر سکتی ہے جو وہ چاہتا ہے، لیکن انسان پھر بھی فیصلہ کرتا ہے کہ کیا ضم ہوتا ہے۔

مثال: آپ ایک دوسری روٹین شامل کرتے ہیں جو راتوں رات پائے جانے والے فلکی ٹیسٹوں کو ٹھیک کرتا ہے۔ یہ اپنا کام کرتا ہے اور claude/fix-flaky-login-test کی طرف دھکیلتا ہے۔ پیر کی صبح، آپ کافی پر فرق کھولیں، دیکھیں کہ یہ درست ہے، اور اسے خود ضم کر لیں۔ روٹین صبح 3 بجے کام کرتی تھی۔ فیصلہ 9 بجے ہوا - یہ تقسیم مکمل حفاظتی ماڈل ہے۔ مہینوں بعد، جب اس روٹین نے لگاتار پچاس کلین ڈِفس تیار کیے ہیں، تو ہو سکتا ہے کہ آپ اصول اس ایک ریپو کے لیے غیر محدود برانچ پُشز سیٹنگ کے ساتھ اٹھا سکتے ہیں — فی ریپوزٹری، جان بوجھ کر، جیسے ایک چابی دینا۔

جب کلاؤڈ روٹین صحیح انتخاب ہے۔

جب بھی کام کو آپ کی مشین کی ضرورت نہیں ہوتی ہے: صبح کا ٹرائیج (ہماری مثال)، اسٹیک ہولڈرز کے لیے جمعہ "اس ہفتے کیا بدلا" ڈائجسٹ، ایک مدمقابل کے چینج لاگ کی نگرانی، معمول کے معاون مسائل کے جوابات کا مسودہ تیار کرنا۔ اگر آپ خود کو یہ سوچتے ہوئے پاتے ہیں کہ "یہ میرے بغیر ہر روز ہونا چاہیے"، تو یہ ٹول ہے۔

2. ڈیسک ٹاپ کے طے شدہ کام — لیپ ٹاپ آن ہونا چاہیے۔

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

مثال کے طور پر جہاں یہ صحیح ٹول ہے: ہر شام 6 بجے، "ہر چیز کو دیکھیں جس پر میں نے آج اپنے مقامی پروجیکٹس پر کام کیا ہے — بشمول وہ فائلیں جن کا میں نے ارتکاب نہیں کیا ہے — اور ~/journal/ پر ایک ورک جرنل اندراج لکھیں۔" کلاؤڈ روٹین یہ کام کسی بھی قیمت پر نہیں کر سکتی: آپ کی غیر متعین دوپہر صرف آپ کی مشین پر موجود ہے۔ مقامی رسائی اس اختیار کے موجود ہونے کی پوری وجہ ہے۔ تجارت یہ ہے کہ آپ کا لیپ ٹاپ شام 6 بجے آن ہونا چاہیے۔

3. آپ کا اپنا کرون — آپ کی مشین، آپ کا شیڈولر، کوئی اینتھروپک کلاؤڈ نہیں۔

cron ایک شیڈولر ہے جو کئی دہائیوں سے ہر میک اور لینکس مشین کے ساتھ بھیج رہا ہے۔ یہ بالکل ایک کام کرتا ہے: یہ وہ کمانڈ چلاتا ہے جسے آپ دیتے ہیں، بعض اوقات آپ منتخب کرتے ہیں۔ اور claude -p (-p پرامپٹ کے لیے ہے) ایک پرامپٹ چلاتا ہے اور باہر نکلتا ہے — کوئی سیشن نہیں، کوئی چیٹ ونڈو نہیں۔ دونوں کو ایک ساتھ رکھیں اور آپ کے پاس پہلے سے موجود حصوں سے ایک لوپ بنایا گیا ہے۔

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

OpenCode ka un-attended heartbeat hamesha OS ya CI hota hai — yahi OpenCode ka raasta hai. opencode run ko bina chat screen ke istemaal karein, aur scheduler ko usay fire karne dein.

Aap ki apni machine, cron ke saath:

# 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 ke saath (aap ki kisi machine ka on hona zaroori nahin). Neeche di gayi model string sirf misaal ke liye hai — apne install ke exact IDs ke liye opencode models chalayein:

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 ke liye prompt zaroori hai (usay parhne ke liye koi comment nahin hota), aur agar loop ko branches ya PRs kholni hon to aap ko contents: write / pull-requests: write dena hoga.

Oopar di gayi action aur model names par aik note

OpenCode GitHub Action ko current official docs mein anomalyco/opencode/github@latest ke taur par refer kiya gaya hai; kuch puri guides ab bhi sst/opencode/github@latest dikhati hain. Dono usi project ki taraf ishara karte hain — woh istemaal karein jo aap ka opencode github install generate karta hai. Models ke liye, anthropic/claude-sonnet-4-6 current Sonnet ID hai. Dateless IDs 4.6 generation ke saath aaye, jahan dateless string hi pinned snapshot hai; puri 4.5-generation models jaise Haiku 4.5 aik dated canonical ID (claude-haiku-4-5-20251001) plus aik dateless claude-haiku-4-5 alias rakhti hain jo latest snapshot ki taraf ishara karta hai. Neeche di gayi examples reproducibility ke liye dated Haiku ID pin karti hain. Apne install ke exact strings dekhne ke liye opencode models chalayein.

7. Event-driven (react when something happens)​

Aik schedule poochta hai "har ghante check karo." Aik event poochta hai "jis lamhe X ho us par react karo." Aik PR khulta hai, aik issue file hota hai, aik message aata hai — aur loop us ke jawab mein chalta hai.

Claude Code کے پاس ایونٹ کے دو ٹولز ہیں، ایک ہر قسم کے ایونٹ کے لیے — نیز ہر چیز کے لیے ایک تیسرا راستہ، آخر میں۔

کوڈ ایونٹس روٹینز پر جاتے ہیں۔ روٹین کو گھڑی پر چلنے کی ضرورت نہیں ہے۔ اس کا محرک اس کی بجائے GitHub ایونٹ ہوسکتا ہے۔ ایونٹ کی دو قسمیں معاون ہیں: پل ریکوسٹ ایونٹس (ایک PR کھلتا ہے، اپ ڈیٹ ہوتا ہے، یا انضمام) اور ریلیز ایونٹس (ریلیز شائع ہوتا ہے)۔ عام استعمالات: "جب PR کھلتا ہے، اس کا جائزہ لیں اور تبصرہ کریں،" یا "جب کوئی ریلیز شائع ہو تو چینج لاگ کا مسودہ تیار کریں۔"

ایک بنانے سے پہلے تین تفصیلات اہم ہیں:

• سیٹ اپ۔ Claude GitHub App کو ریپوزٹری پر انسٹال کرنا ضروری ہے۔ نوٹ کریں کہ /web-setup کلون تک رسائی فراہم کرتا ہے لیکن ایپ کو ** انسٹال نہیں کرتا — یہ بہت سی پہلی کوششوں کو الجھا دیتا ہے۔
• پشز۔ کوئی پش ٹرگر نہیں ہے۔ لیکن جب کوئی نئی کمٹ کو کسی ایسی برانچ میں دھکیلتا ہے جس میں کھلی PR ہوتی ہے، تو GitHub رپورٹ کرتا ہے کہ PR - synchronized ایونٹ کی اپ ڈیٹ کے طور پر - تو معمول کے مطابق آگ لگ جاتی ہے۔ بغیر PR والی شاخ کی طرف دھکیلنے سے کچھ نہیں ہوتا۔
• فلٹرز۔ آپ اس بات کو محدود کر سکتے ہیں کہ کون سے واقعات معمول کے مطابق ہوتے ہیں: مصنف، عنوان، لیبلز، بنیاد یا ہیڈ برانچ، مسودہ کی حالت، اور بہت کچھ۔ فیلڈ بہ فیلڈ تفصیل، گھنٹہ وار ایونٹ کیپس، اور تیز کنارے سبھی Routines appendix (A3) میں ہیں۔

پیغام کے واقعات چینلز پر جاتے ہیں۔ ایک چینل باہر کی ایپ سے ایک پیغام کو سیدھا سیشن میں دھکیلتا ہے جو پہلے سے چل رہا ہے۔ ٹیلیگرام، ڈسکارڈ، اور iMessage بلٹ ان ہیں۔ کسی اور چیز کے لیے، آپ ویب ہک ریسیور سیٹ کر سکتے ہیں۔ یہ حصہ 2 کی دروازے کی گھنٹی ہے: پیغام کے آنے تک کچھ نہیں ہوتا، پھر سیشن ایک ہی وقت میں رد عمل ظاہر کرتا ہے۔ چونکہ پیغام موجودہ سیشن میں آتا ہے، اس سیشن کا سیاق و سباق، مہارت اور تاریخ سبھی جواب دینے کے لیے دستیاب ہیں — کچھ بھی ٹھنڈا شروع نہیں ہوتا ہے۔ سیشن کا موجود ہونا ضروری ہے، اگرچہ: آپ نے جو ٹرمینل کھولا ہے، یا آپ کی مشین پر پس منظر کا سیشن۔ code.claude.com/docs/en/channels دیکھیں۔

باقی سب کچھ API ٹرگر پر جاتا ہے۔ کچھ واقعات نہ تو GitHub اور نہ ہی کسی چیٹ ایپ سے آتے ہیں: آپ کے مانیٹرنگ ٹول میں ایک الرٹ فائر ہوتا ہے، ایک تعیناتی ختم ہوتی ہے، ایک فارم جمع کرایا جاتا ہے۔ ان کے لیے، روٹین کو ایک API ٹرگر دیں — پھر کوئی بھی سسٹم جو تصدیق شدہ ویب کی درخواست بھیج سکتا ہے، آپ کے لیپ ٹاپ کے بند ہونے پر اسے فائر کر سکتا ہے۔ اختتامی نقطہ، ٹوکن، اور دوبارہ کوشش کی وارننگ Routines appendix (A3) میں ہیں۔

تینوں میں سے انتخاب:

واقعہ سے آتا ہے ...	استعمال کریں	کام چلتا ہے…
GitHub (ایک PR، ایک ریلیز)	ایک روٹین، GitHub ٹرگر	ایک تازہ کلاؤڈ سیشن، فی ایونٹ
ایک چیٹ پیغام (ٹیلیگرام، ڈسکارڈ، iMessage)	ایک چینل	جو سیشن آپ پہلے ہی چلا رہے ہیں
کوئی بھی چیز جو ویب درخواست بھیج سکتی ہے	ایک روٹین، API ٹرگر	ایک تازہ کلاؤڈ سیشن، فی کال

پہلی اور تیسری قطار میں پیٹرن کو نوٹ کریں: ہر ایونٹ کا ایک تازہ سیشن شروع ہوتا ہے، لہذا دو واقعات ایک دوسرے کے بارے میں کچھ نہیں جانتے ہیں۔ ایک PR پر دو دھکے دو الگ الگ سیشن ہیں۔ ریڑھ کی ہڈی (تصور 12) یہ ہے کہ وہ کس طرح ریاست کو بانٹتے ہیں۔

GitHub agent ko aik baar opencode github install se install karein, jo .github/workflows/opencode.yml add karta hai. Us ke baad, OpenCode repository events par react karta hai — pull_request, issues, aur /oc ya /opencode comments — aap ke GitHub Actions runners ke andar chalte hue:

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.

Bina prompt ke aik pull_request event ke liye, OpenCode default mein PR review karta hai.

Check yourself

Aap chahte hain ke aik loop aik failing test ko tab tak fix karta rahe jab tak woh pass na ho, phir khud ruk jaye. Kaun se heartbeat ki taraf aap jate hain, aur "done" kaun decide karta hai?

Show answer

Run-until-done — Claude Code mein /goal, ya OpenCode mein aik capped shell loop. Aik command (test runner) "done" decide karti hai, kabhi woh agent nahin jis ne fix likha — aur usay phir bhi aik ceiling chahiye taake woh hamesha retry na karta rahe.

---

Part 3: The Body​

Heartbeat loop shuru karta hai. Yeh chaar parts woh hain jo loop har beat par karta hai. Aap inhein agentic coding course mein handy extras ke taur par mil chuke hain. Aik loop mein yeh waqai matter karte hain, kyunke koi insan har step nahin dekh raha.

8. Isolation: worktrees​

Jis lamhe aik loop aik se zyada agent aik saath chalata hai, woh aik doosre ki files overwrite karna shuru kar dete hain — bil-kul jaise do log aik hi lines edit kar rahe hon baghair aik doosre ko bataye. Aik git worktree is ko theek karta hai: aik alag working folder, apni branch par, jo wohi repo history share karta hai. Aik agent ki edits doosre ke checkout ko chhu nahin sakti.

Built in. --worktree flag istemaal karein taake aik session apne checkout mein khulle, ya aik subagent par isolation: worktree set karein taake har helper ko aik taza checkout mile jo baad mein khud saaf ho jata hai. Aik scheduled task per run worktree isolation on kar sakta hai, taake parallel runs kabhi aap ke apne manual kaam se na takrayein.

Koi single flag nahin. Aap git ki apni worktrees istemaal karte hain aur har aik par aik run point karte hain. Wohi isolation, saaf zahir:

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 ke gird bane worktree managers) aap ke liye bookkeeping sambhal sakte hain agar aap yeh aksar karte hain.

9. Knowledge: skills, so no run is "day one"​

Aik loop har baar cold chalta hai — aik taza session jis ko aap ke project ki aadat ki koi memory nahin. Bina madad ke, woh har beat par aap ka poora setup samajhta (ya guess karta) hai, tokens zaaya karta hai aur ghaltiyon ko dawat deta hai. Aik skill woh knowledge hai jo aik baar likha gaya, aik SKILL.md file mein, jahan agent usay har run par parhta hai.

Yeh dono tools mein aik jaisa kaam karta hai: aik folder jis mein instructions aur metadata ka aik SKILL.md ho, plus optional scripts aur references. Aik loop mein, rule sada hai: jo cheez aap warna har run par dobara samjhate, woh aik skill mein hai. Triage steps, project ki aadatein, "hum is tarah nahin karte us aik incident ki wajah se" — yeh sab skill mein rehta hai, taake loop dobara shuru hone ke bajaye khud par build kare. (Poora treatment Skills & Connectors crash course mein.)

Aik skill loop prompts ko chhota rakhti hai

Aik schedule mein instructions ki diwaar paste karne ke bajaye jise koi update nahin rakhega, aap ka scheduled prompt aik line ban jata hai — "daily-triage skill chalao" — aur skill detail rakhti hai. Chhota loop prompt, asaan-to-update logic, har beat par kam token cost.

10. Action: connectors (the loop acts, not just suggests)​

Aik loop jo sirf aap ki files parh sakta hai woh aik loop hai jo sirf baat kar sakta hai. Connectors — MCP par bane — usay karne dete hain: aik PR kholna, aik Linear ticket update karna, Slack par post karna, aik database query karna, aik staging API call karna. Yeh us loop mein farq hai jo kehta hai "yeh raha fix" aur us mein jo PR kholta hai, ticket link karta hai, aur CI green hone par channel mein post karta hai.

Dono tools MCP bolte hain, to protocol un ke darmiyan transfer hota hai — lekin packaging aur authentication (local vs hosted, OAuth, permissions) ko aksar tool-specific wiring chahiye.

Apne config mein MCP servers add karein aur unhein aik routine ki connector list mein shaamil karein, taake un-attended run un tak pohanch sake. Wohi connectors jo aap haath se istemaal karte hain woh scheduled aur cloud runs ke liye mojood hote hain.

opencode.json ke mcp section mein servers declare karein — local servers aik subprocess shuru karte hain, remote servers automatic OAuth ke saath aik HTTPS endpoint tak pohanchte hain. Aik scheduled opencode run mein, opencode serve aik baar shuru karein aur us se --attach karein, taake aap har beat par MCP start-up cost na dein.

11. Maker–checker: sub-agents​

Aik loop mein sab se ahem choice: jo agent kaam likhta hai woh agent nahin hona chahiye jo usay approve karta hai. Aik model jo apne hi output ko grade karta hai woh apne saath bahut narmi barat-ta hai. Aik doosra agent — alag instructions, aksar aik alag (kabhi zyada strong) model — woh pakar leta hai jo pehle ne miss kiya kyunke woh yaqeen se theek tha. Yahi woh wahid wajah hai jis se aap aik chalte hue loop ko akela chhor sakte hain.

Subagents ko .claude/agents/ mein define karein, aur unhein agent teams ke taur par jorein: aik explore karta hai, aik implement karta hai, aik spec aur tests ke khilaf check karta hai. "Spec" woh hai jo aap ne Spec-Driven Development mein likhna seekha: is ke acceptance criteria bil-kul wohi hain jin ke khilaf aik bharose-mand checker grade karta hai — aik vague spec aap ko aik vague verdict deti hai. Yeh wohi cheez hai jo /goal andar karti hai: aik taza model decide karta hai ke loop ho gaya, us ke bajaye ke worker khud ko grade kare.

OpenCode built-in primary agents (Build, Plan) aur aik built-in general subagent ship karta hai (plus explore, aur current versions mein scout aik experimental flag ke peechhe). Aap apne khud ke opencode.json mein ya apne agents folder mein markdown files ke taur par define kar sakte hain. Checker ko us ka apna (aksar sasta, read-only) model dein, aur maker se usay aik @ mention ya Task tool ke saath call karwayein. Aik aam split: aik strong model explore aur implement karta hai, aik focused model check karta hai.

---
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 zyada cost karte hain — unhein wahan kharch karein jahan matter kare

Har sub-agent apna model aur tools chalata hai, to maker–checker split waqai zyada tokens cost karta hai. Yeh aik aise checker ki qeemat hai jis par aap bharosa kar sakein. Usay wahan kharch karein jahan aik doosri raye matter kare (koi bhi cheez jo loop aap ke door hone par commit karega); usay throwaway, read-only chores ke liye chhor dein.

11b. Codify the body: dynamic workflows​

Ab tak, aik beat ka body — kaam dhoondna, har fix usay apne checkout mein draft karna, aik alag agent se usay grade karwana — aisi cheez hai jise agent turn-ba-turn assemble karta hai. Claude Code ab aap ko us poori orchestration ko aik rerunnable script ke taur par codify karne deta hai, jise aik dynamic workflow kehte hain: aap task bayan karte hain, Claude aik aisa script likhta hai jo kaam ko bahut se sub-agents mein faila deta hai, aur aik runtime usay background mein execute karta hai jab ke aap ki session free rehti hai. Yeh maker–checker split (Concept 11) aur worktree split (Concept 8) aik repeatable unit mein packaged hai — aur yeh aik asli quality pattern apply kar sakta hai, sirf zyada agents chalana nahin: mukhtalif reviewers aik doosre ki findings ko adversarially check kar sakte hain is se pehle ke kuch report ho.

Aik ke liye sade alfaaz mein poochein ("use a workflow to…"), usay ultracode keyword se trigger karein, ya bundled /deep-research chalayein. Jab koi run woh kare jo aap chahte hain, /workflows view mein s dabayein taake us ka script aik /command ke taur par save ho jo aap har branch par dobara chala sakein. Do limits isay imandar rakhti hain: agents capped hain (aik saath takreeban 16, fi run 1000) taake aik runaway script spiral na kar sake, aur aik run ki memory sirf us run ke andar rehti hai — aap usay usi session ke andar resume kar sakte hain, lekin aik taza session usay dobara shuru kar deti hai.

Koi /workflows command nahin. Jo script aap pehle hi likhte hain wohi workflow hai: Concept 5 ka capped for loop aur Concept 8 ka &/wait fan-out usi idea ka hand-rolled version hain — aap ka shell plan rakhta hai, opencode run har agent hai, aur exit codes checker hain. Aap ko poora control aur koi agent cap nahin milta, is qeemat par ke aap orchestration khud likhte aur sambhalte hain.

Aik workflow aik beat ka body hai — loop nahin

Yeh sab se asaan ghalti hai jo workflows ke powerful lagne lagne par hoti hai. Aik dynamic workflow aik baar chalta hai, jab aap (ya ultracode setting) usay shuru karte hain, aur khatam hote hi sab kuch bhool jata hai. Is ka koi heartbeat nahin aur koi spine nahin. To yeh aik single beat ka body hai, loop nahin. Loop composition hai: aik heartbeat (aik Routine, /loop, ya cron) beat fire karta hai, workflow woh body hai jo us par chalta hai, aur aik progress file jise is ke agents likhte hain woh spine hai jise agla firing parhta hai. Workflow engine hai; Routine woh hai jo chaabi ghumati hai, aur progress.md woh fuel hai jo trips ke darmiyan bacha rehta hai.

---

Part 4: The Spine​

12. State that survives between runs​

Yeh raha woh hissa jise beginners chhor dete hain, aur yahi woh hai jo aik loop ko loop banata hai. Model har run ke darmiyan sab kuch bhool jata hai. Agar har beat sifr se shuru hoti hai, to aap ke paas loop nahin — aap ke paas wohi pehla step hai, hamesha ke liye repeat hota hua. Fix dull aur powerful hai: state ko model ke bahar, disk par rakhein.

State ki do layers, aik saath kaam karti hui:

• Rules file (CLAUDE.md / AGENTS.md) — woh steady aadatein jo loop har run par parhta hai. (Isay chhota rakhein; aap ne pichle course mein kyun seekha. Aik bloated rules file har aik beat par adaa ki jati hai.)
• Aik progress file — aik sada markdown file (ya MCP ke zariye aik Linear board) jo record karti hai kya try kiya gaya, kya pass hua, kya abhi khula hai. Yeh asli spine hai. Kal ki 9am run isay kholti hai aur wahan se uthati hai jahan aaj ki run ruki.

Aadat: har run shuru mein progress file parhti hai aur aakhir mein usay update karti hai. Jab loop wohi ghalti baar baar karta hai, to fix aik clever prompt nahin — yeh hai ke loop se sabaq rules file mein likhwana, taake fix har future run ke liye rahe.

<!-- 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

Spine aap ka record bhi hai

Chunke progress file aap ke repo mein bas text hai, yeh us cheez ka record bhi banti hai jo loop ne aap ke door hone par kiya. Jab aap human gate par baithte hain, aap spine parhte hain — har run ka poora transcript nahin.

Check yourself

Aik loop ko jo us ne ab tak kiya woh kahan rakhna chahiye, aur conversation mein kyun nahin?

Show answer

Disk par — aik progress file (plus rules file), ya Linear jaisa aik board. Model ki memory runs ke darmiyan miti jati hai, to jo cheez zinda rehni chahiye woh model ke bahar rehti hai. Repo yaad rakhta hai; model nahin.

---

Part 5: A Complete Loop, Twice​

Minimum safe loop checklist

Is se pehle ke aap kisi loop ko khud se chalne dein, usay in saaton ki zaroorat hai. Woh loop jo aap abhi banane wale hain us mein har aik hai:

• Success condition — woh kaise jaanta hai ke kaam ho gaya (Concept 5).
• Ceiling — max tries, minutes, ya spend, taake woh hamesha na chale (Concept 13).
• Isolated branch ya worktree — taake parallel kaam na takraye (Concept 8).
• Read-only checker — aik alag agent jo grade karta hai lekin edit nahin kar sakta (Concept 11).
• State file — spine, taake woh runs ke darmiyan yaad rakhe (Concept 12).
• Human gate — risky ya failed kaam aik insan ke paas jata hai, kabhi seedha main par nahin (Part 5).
• Aik log ya notification — taake raat bhar ki aik failure nazar aaye, khamosh na rahe (Part 6).

Aik bhi miss karein aur loop un-safe, bhulakkar, ya invisible hai.

Ab parts ko jorein. Yeh raha aik loop — aik morning maintenance loop jo raat bhar ki CI failures chhanta hai, safe fixes draft karta hai, unhein check karwata hai, safe walon ke liye PRs kholta hai, aur baqi ko flag karta hai — har tool mein aik baar bana. Neeche di gayi files asli hain; aap unhein aik repo mein copy kar ke chala sakte hain.

Loop ki shape (dono mein wohi):

1. Heartbeat: har weekday 9am par.
2. Skill: aik daily-triage skill steps rakhti hai, taake prompt aik line rahe.
3. Spine: shuru mein progress.md parhein, aakhir mein usay update karein.
4. Worktree: har fix apne checkout mein draft hota hai.
5. Maker–checker: aik implementer draft karta hai; aik alag reviewer PASS ya FAIL kehta hai.
6. Connector: PASS ke liye aik PR kholein; FAIL ya kisi risky cheez ke liye, usay "needs a human" mein likhein aur ruk jayein.

The shared skill​

Yeh aik file dono tools mein chalti hai. Isay .claude/skills/daily-triage/SKILL.md (Claude Code) ya .opencode/skills/daily-triage/SKILL.md (OpenCode) ke taur par save karein.

---
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.

The reviewer (the checker)​

Reviewer amal mein maker–checker split hai. Aap ko dono files chahiye — yeh aik ya doosre wali tool choice nahin. Format har tool ke hisab se thora farq rakhta hai, to har aik neeche poora dikhayi gayi hai.

Claude Code — .claude/agents/reviewer.md ke taur par save karein:

---
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
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.

tools line ke baare mein ek imaandaar baat: yeh sirf tool ke naam leti hai (Read, Bash), is liye yeh reviewer ko sirf test, lint aur diff commands tak mehdood nahin kar sakti. Filhaal, is limit ko numbered instructions sambhalti hain. Agla course, Harness Engineering, woh rule add karta hai jo ise laagoo karta hai.

OpenCode — .opencode/agents/reviewer.md ke taur par save karein:

---
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 the heartbeat​

claude.ai/code/routines par aik Routine banayein jis mein weekday-9am schedule, aap ka repo, aur aap ke GitHub + Slack connectors hon. Is ke prompt ko skill ki taraf point karein, taake routine definition chhoti rahe:

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 steps rakhti hai. .claude/agents/reviewer.md checker hai. isolation: worktree parallel fixes ko alag rakhti hai. GitHub connector PRs kholta hai. Chunke yeh aik cloud Routine hai, yeh 9am par chalta hai chahe aap ka laptop khula ho ya na ho — aap ke plan ki daily run cap ke andar.

Isay aik GitHub Actions workflow ke taur par banayein, taake yeh cloud mein chale baghair aap ki kisi machine ke jaage. Action heartbeat hai; opencode run worker hai; aap ka repo skill, agents, aur progress.md rakhta hai.

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 agent (aik saste read-only model par) checker hai. Nayi branches CI mein worktree isolation ka kaam karti hain. OpenCode GitHub app PRs kholta hai. Isay GitHub ki bajaye apni machine par chahte hain? Bil-kul wohi prompt aik cron line se chalta hai jo opencode run ko call karti hai — sirf heartbeat badalta hai.

What one real morning looks like​

Aap ne yeh sab aik baar design kiya. Yeh raha aik single run, jis tarah aap jaag kar dekhte (neeche di gayi run shape ki aik misaal hai, recording nahin):

[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.

Dekhein kya hua. Loop ne kaam dhoonda, usay draft kiya, check kiya, safe hissa ship kiya, aur aap ko sirf woh aik faisla diya jis ke liye aik insan chahiye tha. Yeh amal mein loop engineering hai. Aur ghaur karein: dono tools ke darmiyan wahid asli farq heartbeat aur woh jagah thi jahan run hua. Darmiyan mein har cheez — skill, spine, worktree, maker–checker, connector — wohi design thi.

Check yourself

Morning-triage loop mein, kya cheez aik ghalat fix ko aap ke sone ke dauran merge hone se rokti hai?

Show answer

Teen cheezein mil kar: reviewer subagent ko PASS return karna chahiye (maker–checker), sirf low-risk changes aik PR khol sakti hain, aur human gate kisi risky ya failing cheez ko main ke bajaye aik "needs a human" note bhejti hai. Har run capped aur logged bhi hai.

---

Part 6: Staying the Engineer​

Aik loop kaam badalta hai; yeh aap ko us se bahar nahin nikalta. Teen masle aap ke loops behtar hone ke saath bare hote hain, chhote nahin. Yeh hissa course mein sab se ahem hai.

Aap Ka Loop Teen ke Andar Kaise Fit Hota Hai

Aap ne abhi aik loop banaya. Is ke chhe hisse hain, aur aik baar shuru hone ke baad, yeh khud chalta hai: agent code likhta hai, usay test karta hai, fix karta hai, aur dobara koshish karta hai, aap ke baghair.

Yeh aik loop hai. Yeh sab se tez hai. Yeh minutes mein aik chakkar poora karta hai. Lekin yeh akela kaam nahin karta. Yeh teen loops mein sab se chhota hai, aur baqi do aap ne chalane hain.

Inhein dekhne ka sab se aasaan tareeqa aik misaal se hai. Farz karein aap aik agent se kehte hain ke woh aik bachche ke liye chhota sa typing game banaye.

• Coding loop minutes mein chakkar poora karta hai. Agent game likhta hai, usay test karta hai, aur bugs fix karta hai jab tak woh aap ki hidayaat se match na kar jaye. Yeh wohi loop hai jo aap ne abhi banaya.
• Feedback loop hours mein chakkar poora karta hai. Aap game kholte hain, usay try karte hain, aur faisla karte hain ke kya badalna hai: buttons bare karna, cat costumes add karna jo bachcha unlock kar sake, aik login add karna taake parent madad kar sake. Phir aap apni hidayaat update karte hain, aur agent dobara banata hai.
• Outside loop days mein chakkar poora karta hai. Real log game istemaal karte hain. Aik dost usay try karta hai. Aik bachcha us se khelta hai. Woh jo karte hain woh aap ko dikhata hai ke aage kya fix karna hai.

Loops aik doosre ke sath sath nahin baithte. Yeh aik doosre ke andar baithte hain. Bohat se coding loops chalte hain jab aap aik feedback loop chalate hain. Bohat se feedback loops chalte hain jab bahar ki duniya feedback ka aik round wapas bhejti hai. Tez loop khud chalta hai. Slow loops ko aap chahiye.

Do lafz jaanne wale. Aik spec aap ki likhi hui description hai ke kya banana hai. Evals tests ka aik chhota set hai jo check karta hai ke agent ne sahi kiya ya nahin. Yeh dono mil kar pehle do loops ke darmiyan baithte hain aur aap ke faisle code mein le jate hain.

Ab asal idea, Andrew Ng se. Agent teenon loops khud kyun nahin chala sakta? Kyunke aap woh cheezen jaante hain jo woh nahin jaanta: yeh kaun istemaal kare ga, unhein waqai kya chahiye, aur "acha" kaisa mehsoos hota hai. Jab tak aap koi aisi cheez jaante hain jo agent nahin jaanta, aap loop mein rehte hain taake usay bata sakein. Ng is ko aap ka context advantage kehte hain.

Yehi wohi sabaq hai jis par yeh course khatam hota hai. Machine tez loop chalati hai. Aap woh do cheezen rakhte hain jo woh kabhi nahin rakh sakti: kya banana hai, aur is ka jawabdeh kaun hai.

Chahe aap kabhi koi product na banayein, yeh map rakhein. Yeh dikhata hai ke kisi bhi agent ke kaam mein human kahan baithta hai. Woh spec jo pehle do loops ko jorti hai usay tez karne ke liye, Spec-Driven Development dekhein. Yeh dekhne ke liye ke aap ka role bahar wale loops mein kaise barhta hai, The Roles This Book Trains dekhein.

13. Token cost is the real limit, not the keybind​

Yeh, kaafi door tak, loops ke ghalat hone ka sab se aam tareeqa hai. Aik loop baar baar chalta hai, aksar sub-agents shuru karta hai, aur har sub-agent apna model aur tools chalata hai. Cost takreeban har kisi ki tawaqqo se zyada tezi se barhti hai. Fixes sade hain:

• Har loop cap karein — max tries, max minutes, ya max spend. Hamesha (Concept 5).
• Model ko kaam se match karein — plan aur check ke liye aik strong model, kaam karne ke liye aik sasta. Yeh sab se bara saving hai, aur aap ne pichle course mein yeh pehle hi seekha.
• Loop prompt aur rules file chhoti rakhein — aap har beat par un ke liye adaa karte hain. Detail un skills mein dhakelein jo sirf istemaal hone par load hoti hain.
• Isay kam baar chalayein — har paanch minute ke bajaye ghante mein aik baar aam tor par kaafi hai, aur takreeban barah guna sasta.

Numbers ki aik jaldi se samajh (misaal ke liye). Maan lein aik beat — maker plus checker — takreeban 40k tokens parhta hai aur takreeban 6k likhta hai. Sonnet 4.6 ke $3 / $15 fi million par, yeh takreeban $0.20 fi beat hai. Aik 20-din ke mahine mein din mein paanch beats takreeban $20 hain — sasta. Wohi loop har paanch minute fire hota hua sau guna se zyada beats hai — aaram se $1,000 fi mahina se aage — bina kisi extra value ke. Cadence, keybind nahin, woh jagah hai jahan paisa jata hai.

Model aik doosra lever hai — OpenCode ke raaste par. Woh numbers Sonnet 4.6 maan kar chalte hain. Claude Code ki loop commands Claude chalati hain, lekin OpenCode aap ko model chunne deta hai, aur aik sasta per-beat cost ko bahut door le jata hai: DeepSeek V4 Flash (takreeban $0.14 / $0.28 fi million) wohi beat takreeban $0.007 — takreeban 30× sasta par chalata hai — $20-fi-mahina wale loop ko aik dollar se kaafi neeche le aata hai. Do imandar caveats. Pehla, sasta maker, bharose-mand checker: aik weaker model bure fixes likhta hai, to woh zyada beats jala sakta hai ya zyada baar review fail kar sakta hai, aur retries saving kha jate hain — sasta model aik clear spec par mechanical maker ke liye istemaal karein, aur aik checker rakhein jis par aap bharosa karein (test runner aur linter sab se sasta, sab se imandar checker hain jo hain). Doosra, cadence ab bhi ghalib hai: aik 30×-sasta model har paanch minute fire hota hua ab bhi Sonnet ke ghante mein chalne se zyada cost kar sakta hai. Model bill ko neeche scale karta hai; yeh ke kitni baar chalta hai aur retry karta hai woh ab bhi usay set karta hai.

Bina spending limit wale loop ki bahut cost ho sakti hai

Aam failure hamesha aik jaisi hai: aik loop jo khud se chalta hai, aik aisi stopping condition ke saath jise woh kabhi poora nahin kar sakta, raat bhar retry karta hua. Shuru karne se pehle aik ceiling set karein. Pehli chand asli runs dekhein. Phir usay khud se chalne dein.

14. Checking the work is still your job​

Aik loop jo khud se chalta hai woh aik loop hai jo khud se ghaltiyan karta hai. Maker–checker split loop ke "it's done" ko kuch maani deta hai — lekin "done" ab bhi aik claim hai, aik proof nahin. Aap ka kaam ghaaib nahin hua; yeh apni jagah badal gaya. Aap ab har step type nahin karte, lekin aap ab bhi woh hain jo confirm karta hai ke loop ne aisa code ship kiya jo waqai chalta hai. Woh diffs parhein jo loop ne kholi. Loop par kaam karne ke liye bharosa karein; counting se pehle kaam check karein.

15. Don't stop understanding your own project​

Jitni tezi se aik loop aisa code ship karta hai jo aap ne nahin likha, utna hi wide gap aap ke project mein jo hai aur jo aap waqai samajhte hain us ke darmiyan hota hai. Woh gap aik asli cost hai, aur aik smooth loop usay khamoshi se barhata hai. Ilaaj aur trap wohi aik amal hain. Loop design karna aap ko engaged rakhta hai jab aap usay ghaur se karte hain — aur aap ko sochna chhornay deta hai jab aap usay kaam se bachne ke liye karte hain. Wohi amal, opposite result. Loop farq nahin bata sakta. Aap bata sakte hain.

Do log bil-kul wohi loop bana sakte hain aur opposite results pa sakte hain. Aik usay un kaam par tezi se barhne ke liye istemaal karta hai jise woh gehrai se samajhta hai. Doosra usay kaam ko bil-kul samajhne se bachne ke liye istemaal karta hai. Loop banayein. Lekin usay aise banayein jaise koi jo engineer rehne ka irada rakhta ho — na sirf woh shakhs jo go dabata hai.

Yeh dono log usi force ke neeche hain, aur us force ka naam hai. MIT Sloan ke Eric So isay AI gravity kehte hain: woh musalsal pull jo aap ko apni thinking ka aur zyada hissa AI ko dene ki taraf kheenchta hai. Loop wohi pull hai, bas heartbeat ke saath: yeh aap ke sotay waqt bhi chalta hai, is liye jo ship hota hai aur jo aap samajhte hain un ke darmiyan gap tab bhi barhta hai jab aap kuch touch nahin karte. Agar isay akela chhor diya jaye, gravity un do siron ko daba deti hai jinhein yeh course aap ka kehta hai: intent aik precise, checkable condition se patla ho kar "bas isay working rakho" ban jata hai, aur accountability diffs parhne se patli ho kar green checkmarks par bharosa ban jati hai. Loop dono halaton mein chalta rehta hai. Yeh nahin bata sakta ke aap ab bhi engineer hain ya nahin. Concept 15 ke sawal ka jawab dene wali weekly habit — kya ship hua parhna, aur check karna ke aap ki understanding saath chali — woh tareeqa hai jis se aap pull ke khilaf apna wazan banaye rakhte hain.

Aur yeh poore course ka through-line hai. Har saal tools loop ki machinery ka aur hissa apne andar le lete hain: orchestration, checker, aur schedule ab built-in hain (dynamic workflows, /goal, Routines) jahan aik saal pehle yeh aap ki apni shell scripts thin. Jo tools absorb nahin kar sakte woh do siray hain jo aap Concept 1 mein mile — intent, itni theek se specify kiya gaya ke check ho sake, aur jo ship hota hai us ki accountability. Isi liye yeh engineering hai aur button-pushing nahin, aur yeh skill ka woh hissa hai jo sarta nahin. Tools ko strong hone dein aur un par jhukein; bas un dono siron ko apne haathon mein rakhein.

When a loop fails while you're asleep

Aik un-attended loop un-attended fail bhi hota hai. Is se pehle ke aap usay raat bhar bharosa karein, usay observable banayein:

• Output wahan bhejein jahan aap dekhein ge — aik log file, aik Slack ya Discord message (Claude Code Channels), ya Triage inbox. Woh terminal nahin jo aap pehle hi band kar chuke.
• Har run aik line likhein, failure par bhi — har beat progress.md (ya aik log) mein aik timestamped note add karta hai: us ne kya try kiya, kya pass hua, kya tuta. Aik khamosh failure sab se buri tarah ki hai.
• Runs ko replayable rakhein — OpenCode mein, opencode run --format json, opencode export <id>, aur opencode session list aap ko poora record dete hain. Claude Code mein, aik Routine apni run history web UI mein rakhti hai.
• Ceiling par loud fail karein — jab loop apni cap par pohanche ya error de, usay aik saaf "needs a human" note chhorni chahiye, sirf rukna nahin.
• Nightly slot kamayein — usay raat bhar aur un-attended chalne dene se pehle chand din ghante mein aur dekh kar chalayein. Jab kuch ghalat lage, pehle spine parhein; yeh aap ko batati hai ke aakhri achhi run ne kya kiya.

Aik loop jise aap debug nahin kar sakte woh aik loop hai jise aap bharosa nahin kar sakte.

---

🚀 Projects

Loops ke baare mein parhna aik banane jaisa nahin. Yeh rahe paanch projects, asaan se mushkil. Inhein kisi bhi tool mein karein — loop ki shape wohi hai, to matching concept ki command ki taraf jayein (Claude Code mein /loop aur /goal; OpenCode mein aik shell timer ke saath opencode run).

Shuru karne se pehle do rules, har baar:

• Aik throwaway git repo istemaal karein. Aik loop khud files edit karta hai. Apne pehle loops us kaam ki taraf point na karein jis ki aap ko parwah hai.
• Pehle aik ceiling set karein. Max tries, max minutes, ya max spend — is se pehle ke aap kisi cheez ko khud se chalne dein (Concept 13).

👀Project 115-30 minA watch loopMake a loop watch a long task and tell you the moment it finishes.

Difficulty: easy · Uses: Concept 4 (in-session loop).

Build. Apne repo mein aik lamba task shuru karein (misaal ke taur par, aik script jo thori der sota hai aur phir aik file likhti hai). Aik in-session loop set up karein jo har minute check kare ke task khatam hua ya nahin, aur aap ko us lamhe bataye jab woh ho jaye.

Done when loop ko pata chal jaye ke task khatam hua, aik baar woh keh de, aur aap usay saaf tareeqe se rok sakein — aur aap kabhi terminal dekhte hue na baithein.

✅Project 230-45 minMake the tests pass, then stopLoop until a command — not the agent — decides the work is done.

Difficulty: easy–medium · Uses: Concept 5 (run-until-done), Concept 11 (maker–checker).

Build. Apne repo mein 2–3 chhote failing tests dalein. Aik loop banayein jo tab tak kaam karta rahe jab tak tests pass na hon — lekin aik command (test runner) ko, agent ko nahin, decide karne dein ke kab ho gaya. Isay, maslan, 6 tries par cap karein.

Done when loop is liye ruke ke tests waqai pass ho gaye, na ke is liye ke woh cap par pohancha. Agar yeh cap par pohanchta rehta hai, to aap ki stop condition ya aap ke prompt par kaam chahiye — yahi sabaq hai.

🧠Project 345-60 minThe morning brief with a memoryA scheduled loop whose second run clearly builds on its first.

Difficulty: medium · Uses: Concept 6 (unattended schedule), Concept 12 (the spine).

Build. Aik scheduled loop banayein jo aik baar chale, aik progress.md parhe, repo se kuch sada ikatha kare (khule TODO comments, ya pichle din ke commits), aik chhota summary likhe, aur progress.md ko us cheez se update kare jo us ne paya aur date ke saath.

Done when aap usay do baar chalayein aur doosri run saaf tor par pehli par build kare — woh us cheez ko repeat na kare jo woh pehle hi record kar chuki. Yeh sabit karta hai ke aap ki spine kaam karti hai. Agar doosri run sifr se shuru hoti hai, to aap ke loop ki abhi koi memory nahin.

🔍Project 41-2 hrsA fix loop with a real checkerAn implementer drafts, a separate reviewer grades, and only PASS opens a PR.

Difficulty: medium–hard · Uses: Concept 8 (worktree), Concept 9 (skill), Concept 11 (maker–checker).

Build. Part 5 ke loop ka aik chhota version. Apne fix steps ke saath aik chhoti skill likhein, aur aik reviewer agent jo PASS ya FAIL jawab de. Aik asli bug lein, implementer se usay apne checkout (worktree ya branch) mein draft karwayein, aur reviewer se usay grade karwayein. Aik PR sirf PASS par kholein.

Done when do cheezein dono sach hon: aik achhe fix ko PASS aur aik PR mile, aur aik jaan boojh kar bura fix jo aap dalein usay wajah ke saath FAIL mile. Agar reviewer bure fix ko pass kar deta hai, to aap ka checker bahut narm hai — usay tight karein. Aik checker jo har cheez approve karta hai woh koi checker nahin.

🔁Project 52-4 hrsYour own daily loopThe full six-part loop on a real chore, run unattended for a week — the capstone.

Difficulty: capstone · Uses: all six parts.

Build. Aik asli, boring, recurring chore chunein jis project par aap waqai kaam karte hain — aik dependency audit, aik docs-freshness check, aik changelog draft, aik lint sweep. Poora loop banayein: heartbeat, worktree, skill, maker–checker, connector, aur spine. Budget guards add karein. Usay chalne dein.

Done when yeh aik hafte un-attended chal chuka ho aur aap jo woh ship karta hai us par bharosa karein is liye ke aap ne usay parha — na ke is liye ke aap ne parhna chhor diya. Phir Concept 15 ka imandari se jawab dein: kya project ki aap ki samajh us cheez ke saath qadam milati rahi jo loop ne badla? Agar nahin, to loop ko tab tak slow karein jab tak woh aisa na kare. (Jab yeh raat bhar fail ho — aur hoga — model ko qusoor dene se pehle When a loop fails while you're asleep mein se guzrein.)

---

Where to go next​

• Non-coding kaam ke liye loops bana rahe hain? Cowork & OpenWork crash course professionals ke liye wohi heartbeat idea dikhata hai, cron ke bajaye scheduled tasks ke saath.
• Un-attended runs ke liye retries tune kar rahe hain? Claude Code ka Error reference automatic-retry settings ko document karta hai, jin mein CLAUDE_CODE_MAX_RETRIES aur CI-style un-attended sessions ke liye CLAUDE_CODE_RETRY_WATCHDOG mode shaamil hain.
• Woh spec jo aap ne Spec-Driven Development mein likhi hi aap ke loop ki stopping condition hai: is ke acceptance criteria woh hain jin ke khilaf checker grade karta hai aur jo /goal rukne se pehle sabit karta hai. Jab aik loop chalta chhornay ke liye un-safe lage, to fix takreeban hamesha aik sharper spec hota hai — zyada automation nahin.

Sources & further reading

Yeh course primary sources ke aik chhote set par tika hai. Framing aur quotes in se aate hain; technical details official docs se aate hain.

"Loop engineering" ki ibtida

• Addy Osmani, Loop Engineering — woh essay jis ne pattern ko naam diya aur five-parts-plus-spine model bayan kiya. 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 ka "my job is to write loops" remark aik CNBC interview se hai, jaisa Business Insider ne report kiya. Peter Steinberger ki "design loops that prompt your agents" line us ki X par post se hai.
• Andrew Ng — teen product-development loops (coding ~minutes, developer feedback ~hours, external feedback ~days) aur "taste" ko human ke context advantage ke taur par dobara frame karna. Us ki X par post se. https://x.com/AndrewYNg/status/2071988145667928442

Claude Code (official docs)

• Routines — cloud scheduled automations, triggers, aur run caps: https://code.claude.com/docs/en/routines
• Channels — aik chalti hui session mein event-driven input: https://code.claude.com/docs/en/channels

OpenCode (official docs)

• CLI — opencode run, serve, aur --attach: https://opencode.ai/docs/cli/
• Agents aur subagents — primary agents, subagents, aur per-agent models: https://opencode.ai/docs/agents/
• GitHub integration — Action, schedule/PR/issue triggers, aur opencode github install: https://opencode.ai/docs/github/

Model identifiers

• Anthropic, Introducing Claude Sonnet 4.6 — claude-sonnet-4-6 model string ki source: https://www.anthropic.com/news/claude-sonnet-4-6
• Anthropic, Model IDs and versioning — kyun dateless IDs (claude-sonnet-4-6) 4.6 generation se aage pinned snapshot hain, jab ke 4.5-generation models jaise Haiku 4.5 aik dated canonical ID (claude-haiku-4-5-20251001) plus aik dateless alias rakhti hain: https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions

Saare links June 2026 tak current hain. Yeh tools aksar update hote hain, to kisi specific limit, flag, ya model string par bharosa karne se pehle usay live docs ke khilaf confirm karein.

---

The one-line summary

Apne agent ko turn-ba-turn prompt karna chhor dein. Woh loop design karein jo aap ke liye usay prompt karta hai — aik heartbeat, chaar working parts, aur aik spine jo yaad rakhti hai — aur woh engineer rahein jo parhta hai ke yeh kya ship karta hai.

Flashcards Study Aid

---

Test Your Understanding

Checking access...