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.
Aham alfaaz, seedhi zaban mein
Yeh alfaaz aap ko poore course mein milenge. Is list ko ab aik baar parhein, phir jab bhi koi term ghair wazeh lage to yahan wapas aayein.
| Term | Seedha matlab |
|---|---|
| Agent | AI system jo tools use kar ke qadam mukammal karta hai, sirf jawab nahin deta. |
| Prompt | Agent ko di gayi instruction. |
| Loop | System jo kaam shuru, check, record, aur zaroorat par repeat karta hai. |
| Beat | Loop ka aik mukammal run. |
| Heartbeat | Schedule, event, ya condition jo beat shuru kare. |
| Trigger / fire | Run shuru karna. |
| Unattended | Har qadam par insaan ke baghair chalna. |
| Stopping condition | Testable rule jo bataye kaam mukammal hai. |
| Maker-checker | Aik agent banata hai; doosra agent ya command check karta hai. |
| Worktree | Alag folder aur branch jo parallel agents ko aik files badalne se roke. |
| Skill | Save ki hui project instructions jo agent dobara use kare. |
| Connector / MCP | GitHub, Slack, ya database jaise bahar ke system ka connection. |
| State / memory | Model ke bahar save maloomaat jo baad ke run ko pehle ka haal bataye. |
| Spine | Runs ko jorne wali saved state ka is course ka naam. |
| Human gate | Risky action se pehle insaan ka review ya approval. |
| Routine | Claude Code ki cloud automation: saved prompt aur trigger se fresh session. |
Course kabhi kabhi body metaphors istemaal karta hai: heartbeat kaam shuru karta hai, body usay anjaam deti hai, aur spine runs ke darmiyan memory le jati hai. Har metaphor ko hamesha us ke technical matlab ke saath diya gaya hai.
2026 mein in tools ko banane walon ne baat saaf keh di. Boris Cherny ne Claude Code banaya. Unhon ne 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." OpenClaw banane wale Peter Steinberger ne kaha: "aap ko aise loops design karne chahiye jo aap ke agents ko prompt karein." Phir Addy Osmani ne pattern ko naam diya aur us ke parts ginwaye. In mein se koi nahin kehta ke kaam asaan ho gaya. Woh kehte hain ke aham skill ki jagah badal gayi. Yahi woh idea hai jis par poora course bana hai.
Kuch log loop design ko is waqt agent banane ki sab se aham skill kehte hain. Doosre kehte hain ke yeh us kaam ka sirf naya naam hai jo agent tools pehle se karte thay. Dono nazariyat kisi had tak durust hain. Parts naye nahin, lekin woh rozmarra istemaal ke liye ab kaafi saste aur bharose ke qabil ho gaye hain. Is liye asal kaam har agent turn ko guide karne ke bajaye loop design karna banta ja raha hai. Naam tab kaam ka hota hai jab practice aam kaam ban jaye. (Aham quotes, claims, aur technical details aakhir mein Sources aur mazeed mutala mein listed hain.)
Zehni tabdeeli, aik tasveer mein
Upar wali tasveer ko khud chala kar dekhein. Baen taraf har qadam khud shuru karein, phir daen taraf se muqabla karein jahan system har qadam khud shuru karta hai. Har replace hua stop aage dobara milega: Part 2 mein schedule, Concept 11 mein checker, aur Part 5 mein human gate.
Yeh course do tools ko saath sikhata hai. Jo method dono tools mein chalta hai woh transferable skill hai, kisi aik product ka trick nahin. Tools parts mukhtalif tareeqon se dete hain. Claude Code product ke andar loop ki bahut si features deta hai. OpenCode agent worker deta hai, jab ke har run shuru karne ke liye aap operating system ya CI istemaal karte hain. Commands farq hain, lekin loop ki shape aik hi hai.
Claude Code loop ki zyada features aap ko khud deta hai. OpenCode worker deta hai, aur scheduler aur doosre parts aap khud jorte hain.
July 2026 ke darmiyan tak durust. Dono tools tezi se badalte hain aur Claude Code ki kai loop features research preview hain. Har session se pehle
claude updateyaopencode upgradechalayein. Kisi limit ya flag par bharosa karne se pehle live docs, code.claude.com/docs aur opencode.ai/docs, check karein.
Loop kahan chal sakta hai?
Asal loop unattended hota hai. Woh aap ke door hote hue khud ko prompt karta hai. July 2026 se pehle web yeh bilkul nahin kar sakta tha. claude.ai aur chatgpt.com par chat box milta tha, aur chat box har turn par aap ka intezar karta hai: schedule aap thay. Asal loop ke liye browser chhor kar aisa tool use karna parta tha jo khud fire ho sake, yani Claude Code ya OpenCode.
July 2026 mein yeh badal gaya. Dono vendors ne agent products ko unhi web addresses mein mila diya. Claude Cowork ab claude.ai par chalta hai, Cowork crash course dekhein. Is ke remote sessions Anthropic ke servers par chalte hain, is liye scheduled loop us browser tab ke bohat der pehle band hone ke baad bhi fire hota hai. ChatGPT Work chatgpt.com par yahi karta hai. Is liye "web par loop nahin chala sakte" ab durust nahin. Durust jumla yeh hai: chat box mein loop nahin chala sakte, lekin us ke gird web pages chala sakte hain. In mein se zyada tar surfaces paid hain aur kai beta mein staged rollouts ke saath hain. Loop kahin bhi seekh aur design kar sakte hain. Usay chalane ke liye in surfaces mein se aik chahiye. Yeh course do coding surfaces dikhata hai. Achha sawal hai, aur jawab July 2026 mein badla, is liye pehle aur baad ko alag dekhein. July 2026 se pehle: claude.ai aur chatgpt.com chat boxes thay. Chat box har turn par aap ka intezar karta hai. Woh schedule ya event par khud shuru nahin ho sakta. Aap usay haath se dobara prompt kar sakte thay, lekin phir heartbeat aap thay, aur loop isi kaam ko khatam karta hai. Is liye web par loop nahin chalta tha. Aap wahan design karte, phir Claude Code ya OpenCode mein chalaate thay. July 2026 ke baad: dono vendors ne unhi web addresses mein agent products rakh diye. Chat box khud nahin badla. Woh ab bhi aap ka intezar karta hai. Jo badla woh us ke saath baithne wali surfaces hain: Do vendors, chand din ke faaslay se, loop ko browser mein le aaye. Yeh course ke central claim ka sab se mazboot saboot hai: skill tool nahin, shape hai. Kaam ki taqseem ab zyada wazeh hai. Chat box mein aap loop design aur practice karte hain: skill draft, reviewer prompt, stopping condition, aur aik beat haath se. Us ke saath agent surface, chahe Cowork, Routine, ChatGPT Work, ya OpenCode ho, usay chalati hai. Spec-Driven Development ke baad yahi qudrati agla qadam hai. July 2026 ke darmiyan tak durust. Cowork on web aur ChatGPT Work dono chand haftay purane hain, rollouts plan ke mutabiq staged hain, aur usage metered hai. Kisi limit ya feature par depend karne se pehle live product pages check karein."Lekin main ne poora Spec-Driven course claude.ai mein kiya. Kya main wahan bhi loop chala sakta hun?"
claude.ai/code/routines par banti hain, coding work ke liye pehle se yeh kaam karti hain: Anthropic ke servers par fresh cloud sessions, laptop band. Paid plan aur research preview.
Loop ko design aur practice karne ke liye chat box use karein. Unattended chalane ke liye aisi surface use karein jo khud fire hoti ho: Claude Code, OpenCode, Cowork, ya ChatGPT Work. July 2026 se is ke liye browser chhorna zaroori nahin. Cowork claude.ai par aur ChatGPT Work chatgpt.com par chalta hai.
Yahan se aage takreeban har concept aisa hai jise aap asli session mein chala sakte hain, sirf parh nahin sakte. Is page ke saath terminal khula rakhein, claude ya opencode, aur har idea tak pahunchte hi use try karein. Chhote throwaway git repo se shuru karein taake loop kisi aham cheez ko nuqsaan na pohnchaye.
Yeh course kya sikhata hai
| 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 |
| Live | Dogfooding: kitab ke apne loops | Production mein course ko chalane wale do loops aur un ke human gates |
| Practice | Practice projects | Aath loops, asaan se mushkil, jo aap khud banate hain |
| Appendix | Routines, shuru se aakhir tak | Form fields, triggers, secrets, failures, drills aur capstone |
Teen loops jo aaj chala sakte hain, sirf parh nahin sakte
Is course ka zyada hissa ideas hai. Yeh teen nahin. Chaar heartbeats mein se teen ke saath aik chhota project hai jise aap clone kar ke chand minutes mein fire kar sakte hain. Har project bil-kul us concept ke andar hai jo usay samjhata hai, taake jis lamhe us ka ma'ni banta hai usi lamhe aap us se milen.
| Project | Concept | Kya hota hai |
|---|---|---|
| Space Station dekhein | 4, in-session | Aik sada jumla dein, aur asal ISS har minute apni position batata hai jab aap kuch aur kar rahe hon. Terminal band karein to dekhna band ho jata hai, aur yehi concept hai. |
| Apna portfolio banayein | 5, conditional | Apna CV rakhein, /goal ko finish line dein, aur door chale jayen. Woh PDF parhta, page design karta, apna kaam check karta, aur pass hone tak dobara koshish karta hai. |
| Doorbell | 7, event-driven | Pull request kholein aur aisa review jise kisi ne nahin manga, aisi machine par nazar aata hai jo aapki nahin, chahe laptop khula ho ya band. |
Mushkil durust order mein barhti hai: pehla paanch minute leta aur kuch nahin mangta; doosra aik asal afternoon ka kaam hai; teesra bil-kul aap ke baghair chalta hai. Concept 6, schedules, ka abhi project nahin. Usay sabit karne mein aik raat lagti hai.
Teeno agentfactory-labs mein hain. Kam az kam pehla chalayen. Aik heartbeat ko fire hote dekhna, teen heartbeats ke baare mein parhne se zyada qeemti hai.
Karte hue seekhna chahte hain? Pehle Part 5 parhein taake poora loop shuru se aakhir tak dekhein. Phir parts ke liye wapas aayein. Ideas wazeh ho jayen to Practice projects aap ko khud banane ke liye aath loops dete hain.
Pehli baar? Core path lein: Parts 1 se 5 order mein parhein. Har woh note chhor dein jis par "Going deeper" likha hai. Woh notes asal hain, magar baad ki koi cheez un par depend nahin karti; woh doosri reading ke liye hain. Projects 1 se 3 karein, phir ruk jayen. Yeh path takreeban do ghante leta hai, ya ideas naye hon to teen. Is ke baad aap safe loop bana aur chala sakte hain.
Doosri reading, pehla loop waqai chalne ke baad: deeper notes, poora Part 6, Projects 4 se 8, aur jab real cloud Routine banana ho to teen drills wala Routines appendix. Course is tarah bana hai ke doosri reading zyada faida deti hai, kyunke ab aap ke paas sochne ke liye chalne wala loop hai.
Is course mein do layers saath chalti hain aur mukhtalif raftaar se purani hoti hain. Pehli ko andar bithayein; doosri ko look up karein.
- Durable layer. Loop ki shape, aik heartbeat, chaar working parts aur aik spine; maker-checker split; aur woh do cheezein jo loop kabhi aap ke liye nahin kar sakta: intent, jo chahte hain usay itna saaf kehna ke result check ho sake, aur accountability, jo ship ho us ka zimma lena. Yeh skill hai. Neeche ki har command badal jane ke baad bhi durust rahegi.
- Mechanical layer. Har flag, path, model name, aur command. Yeh tools har haftay update hote hain aur yahan kai features research preview hain. Har command ko yaad karne ke fact ke bajaye live docs ka pointer samjhein. Jahan course aur current docs ikhtilaf karein, docs durust hain.
Chhe-part shape yaad ho aur har keystroke bhool jayen to loop engineering seekh li. Keystrokes yaad hon aur shape miss ho to sirf is mahine ki CLI seekhi.
📚 Parhane mein madad
View Full Presentation — Loop Engineering: Aik Crash Course
Part 1: Tabdeeli
1. Prompting se looping tak
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.
Ikhtiyari technical tafseel; pehli reading mein chhor sakte hain.
"Loop engineering" do mukhtalif cheezon ke liye istemaal hota hai. Yeh course big loop sikhata hai, lekin aap small loop ka naam bhi sunenge. Dono ka matlab samajh lein taake uljhan na ho.
Small loop, yani inner loop. Har agent ke andar code ka chhota cycle hota hai: context model ko bhejo, model tools maange to unhein chalao, results context mein joro, aur repeat karo. Jab model tools maangna band kare to cycle khatam. Code mein yeh chand lines hain:
while True:
reply = model(context)
if not reply.tool_calls:
break # the model decided it is done
context += run_tools(reply.tool_calls)
break wali line par ghaur karein. Small loop tab rukta hai jab model khud faisla karta hai ke woh mukammal ho gaya. Koi cheez yeh check nahin karti ke model durust hai.
Yeh masla hai. Model apna kaam khud judge karta hai. Aam failure yeh hai: agent file badalta, yaqeen se "Done! Sab theek" likhta, aur ruk jata hai, lekin tests chalaye hi nahin. Turn khatam hua; task nahin.
Isi liye course outside stops sikhata hai. Outside stop model ki apni raye par depend nahin karta:
- Checked condition, yani asli test se kaam sabit karo.
- Limit, yani tries ki zyada se zyada tadaad.
- No-progress check, yani behtari na ho to ruk jao.
- Separate checker, yani doosra process jo kaam grade kare.
Sab aik hi wajah se hain: small loop ka apna akela stop model ki apne baare mein raye hai.
Big loop, yani outer loop aur yeh course. Small loop ko aik worker samjhein jo aik task karta hai. Big loop manager hai. Woh task choose, start ka waqt, result ka grade, aur kal ke liye memory decide karta hai. Small loop ka aik mukammal run big loop ki sirf aik beat hai.
Layers kaise fit hoti hain. Har layer pichhli ko wrap karti hai:
- Prompt engineering: woh alfaaz jo aap bhejte hain.
- Context engineering: aik turn mein model jo kuch dekhta hai.
- Harness engineering: model ke gird code jo tools chalata aur errors sambhalta hai. Small loop yahan rehta hai.
- Loop engineering: yeh course; outer cycle jo tay karta hai system kis par kaam kare, kab shuru ho, aur done kaise jane.
Isi liye prompt pehle se kam aham hai. Ab woh bohat bare system ka sirf aik input hai.
Har layer mukhtalif failure rokti hai, is liye koi aik layer baqi sab ka bojh nahin utha sakti. Mazboot context kamzor prompt ko bacha sakta hai, lekin koi prompt missing context, missing checker, ya aisa schedule nahin bacha sakta jo ab bhi aap hain. Build karte waqt poochein: in mein se kaunsi layer ab bhi main haath se kar raha hun?
Achhe stop conditions, saaf context, aur sahi tools se small loop ko mazboot banana asal engineering hai, lekin sab kuch aik beat ke andar hota hai. Jahan small loop big loop ke liye matter karega, course ishara karega: stopping conditions Concept 5 aur connector design Concept 10.
2. Loop kin hisson se banta hai
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.
- Heartbeat — aik schedule (ya aik event) jo loop shuru karta hai. Is ke baghair, aap ke paas aik single run hai, loop nahin. Abhi aik lafz seekh lein, kyunke yeh course usay har jagah use karta hai: loop ka har aik firing, yani us ke steps ka aik mukammal chakkar, beat kehlata hai. Heartbeat beats paida karti hai. Neeche ki har cheez aik beat ke andar hoti hai.
- Worktree — isolation, taake do agents jo aik saath kaam karte hain woh aik doosre ki files par na likhein.
- Skill — aap ka project knowledge aik baar likha gaya, taake har run sifr se shuru na ho.
- Sub-agents — maker–checker split: jo agent code likhta hai woh agent nahin jo usay grade karta hai.
- Connector (MCP) — taake loop aap ke asli tools mein act kar sake (PR kholna, ticket update karna), sirf mashwara na de.
Aur chhata, jo woh hai jise beginners chhor dete hain:
- 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.
Nahin. Is course ki misaalein code, repos, tests, aur PRs hain kyunke tools wahan sab se mazboot hain. Lekin loop ki shape ko kaam ka domain farq nahin parta. Kitab, report, course, ya newsletter repo ki files mein reh sakta hai aur loop ka har part wahan bhi map hota hai. Yeh kitab khud markdown files ka repo hai. Nightly link check, style sweep, aur purane model names flag karne wala pass, sab isi chapter ke loops hain.
Aik cheez badalti hai: checker. Code ke paas sab se imandar checkers hain, yani tests aur linters, aisi commands jo "done" sabit karti hain. Prose ka test suite nahin. Is liye writing loop do kamzor checks par tikta hai: jahan mumkin ho mechanical checks, jaise broken links, missing figures, banned words, aur heading levels; aur baqi sab ke liye written rubric wala reviewer agent. Mechanical rung built-in checks se bara hai. Sirf aap ke project ko maloom rules, jaise "memory files mein relative dates nahin" ya "har figure ka alt text 40 words se zyada ho", aik baar likhne par commands ban jate hain. Concept 11 ke baad interlude dikhata hai kaise, aur rubric se command tak neeche aane wala har rule claim ko proof bana deta hai. Rubric ko stopping condition banane ke liye score aur bar dein: "is draft ko rubric se grade karo; 95 se neeche na ruko." Is se soft judgment aisi cheez banti hai jis par loop action le sake. Magar model ka score ab bhi claim hai, proof nahin, aur passing test se kamzor hai. Checker jitna kamzor ho, utna zyada kaam human gate se guzarna chahiye.
Aik aur cheez nahin badalti: heartbeat menu. Domain heartbeat choose nahin karta; task ki shape karti hai. "Abhi karo, done tak" conditional loop hai. "Har raat karo" schedule hai. "Kuch aaye to react karo" event hai. Repo mein code ho ya chapters, menu wahi hai. Active writing ya coding ke dauran aam tor par koi loop nahin hota: heartbeat aap hote hain, aur loops bounded chunks aur maintenance sambhalte hain.
Agar aap ka kaam code ke bajaye documents hai to is course ko isi tarah parhein, phir non-coding tools ke saath inhi loops ke liye Cowork aur OpenWork crash course dekhein.
3. Loop banane ke do tareeqe: built-in tools ya khud connect kiye tools
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.
Sab se aham Routines hain: cloud automations jo Anthropic ke servers par aap ka laptop band hone ke bawajood chalti hain. Yeh schedule, API call, ya GitHub event se shuru ho sakti hain. Is ka badla har account ki daily run limit hai. Launch par yeh Pro mein roz 5 runs, Max mein 15, aur Team/Enterprise mein 25 thi. Cap ke baad extra usage khareedi ja sakti hai aur one-off scheduled runs count nahin hote. Magar docs ab fixed numbers nahin likhtin, is liye inhein launch-time misaalein samjhein, wada nahin. Routines research preview hain aur limits badal sakti hain. Sirf aap ka usage page (claude.ai/settings/usage) bharose-mand number deta hai.
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.
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.
Woh mukammal loop jo aap banayenge
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. Subagents (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.
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? 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.Show answer
Part 2: Loop Ko Kya Shuru Karta Hai (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.
Session khuli ho to yeh har interval par beat fire karta hai aur deploy pakar leta hai kyunke aap wahan rehte hain. Session band karein to nigrani ruk jati hai. Isi liye in-session loop aap ke sote hue nahin chal sakta; Concept 6 yahi hadd hataata hai.
Built-in /loop skill istemaal karein. Isay aik time interval aur prompt dein:
/loop 5m check if the deployment finished and tell me what happened
Claude interval ko schedule mein badalta, job ko ID deta, aur session khula rehne tak prompt har 5 minute chalata hai. Kaam khatam ho to ise cancel kar ke aage barhein.
/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 rokna ho 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.
Heartbeat ke baare mein parhna aur usay fire hotay dekhna aik baat nahin. Is concept ke liye aik chhota project sirf aik kaam karta hai: woh asal International Space Station ko Earth ke gird urtay dekhta hai.
git clone https://github.com/panaversity/agentfactory-labs.git
cd agentfactory-labs/crash-course/loop-eng/iss-loop
claude
Jab yeh poochhe ke folder par bharosa karte hain to yes kahein. Isi se project ke saath aane wali permission on hoti hai, is liye loop aap se poochhne ke liye nahin rukta. Phir aik seedha jumla type karein:
/loop show me the location of the ISS every minute
Bas itna hi type karna hai. Har minute nayi position aati hai aur aap doosra kaam karte rehte hain. Do cheezein gaur ke laiq hain, kyunke mil kar poora concept banti hain:
/loopne "har minute" ko heartbeat samjha. Aap ne schedule, script, ya URL nahin likha. Project folder yeh sab rakhta hai, isi liye prompt aik jumla tha.- Ab terminal band karein. Nigrani bhi band ho jati hai. Yeh bug nahin, in-session loop ki definition hai aur Concepts 6 aur 7 ki zaroorat ki wajah hai.
Mukammal instructions aur aazmane ke liye do mushkil prompts project ke README mein hain.
Ikhtiyari: session band hone par kya hota hai?
Saada session /loop jaan boojh kar aap ki session ke andar chalta hai. Terminal band ho ya laptop so jaye to woh rukta hai. Yeh safety feature hai. Do naye tabdeeliyan is hadd ko narm karti hain:
--resumeun tasks ko wapas laata hai jo expire nahin hue; recurring task saat din tak valid rehta hai.- Session ko background mein bhejna us ke
/looptasks bhi saath le jaata hai. Terminal band ho tab bhi woh fire hote hain, lekin machine sote waqt miss hue fires dobara nahin chalte.
Jo kaam har haal mein chalna ho us ke liye /loop par bharosa na karein; scheduled task ya Routine istemaal karein. Cloud session request khatam hote hi band hoti hai, is liye wahan /loop ke liye kuch zinda nahin rehta.
Darmiyani raasta: background sessions. Background session terminal band hone ke baad bhi aap ki machine par ek run zinda rakhti hai. Ise claude --bg se shuru karein. Akeli session ek kaam kar ke rukti hai; /loop shuru kar ke session background mein bhejein to loop saath chalta rehta hai. claude agents baad mein use dikhata hai; CLI ka --resume aur session ka /resume usay bg nishan ke saath kholta hai. Deploy ya lamba test dekhne ke liye yeh theek hai, magar machine jaagti rehni chahiye.
| Darja | Option | Terminal band hone ke baad fire? | Laptop off hone par fire? |
|---|---|---|---|
| Neeche | In-session /loop | Nahin | Nahin |
| Darmiyan | Background session (--bg) ke andar /loop | Haan | Nahin |
| Oopar | Scheduled task / Routine | Haan | Haan |
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"
Jab aap kaam dekh rahe hon to in-session loop use karein. Session ya machine rukay to yeh bhi rukta hai. Kaam ko aap ke baghair jari rehna ho to cloud Routine ya doosra unattended schedule use karein.
5. Conditional loop, ya run-until-done (ghari se nahin, check se rokein)
Loop koshish karta rehta hai aur alag checker "done" ka faisla karta hai. Goal sabit hote hi rukta hai, baghair timer aur baghair aap ke.
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 Unattended run mein koi insaan phanse hue retry ko rokne ke liye nahin hota, is liye hadd zaroori hai. Naam aur numbers mechanical layer hain, is liye live docs check karein. Mustaqil usool yeh hai ke unattended run ki limit jaan boojh kar chuni jaye./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.Ikhtiyari: Claude Code ki mojooda retry settings
CLAUDE_CODE_MAX_RETRIES), aur hadd pandrah tak barh sakti hai.CLAUDE_CODE_RETRY_WATCHDOG=1 set karein; yeh temporary errors ko zyada dair retry karta aur apna MAX_RETRIES set karne par pandrah wali hadd uthata hai.
npm test saaf stopping condition hai kyunke tests kisi ne pehle se likhe hote hain. Zyada tar kaam aisa nahin hota. Portfolio project mushkil sawaal poochta hai: insaan ke dekhne wale page ke liye "done" kya hai, aur kya aap usay itni wazahat se likh sakte hain ke loop wahan tak pahunch jaye?
Apni CV ya LinkedIn PDF folder mein rakhein, phir /goal ko finish line dein:
/goal Build my portfolio in site/ from my-cv.pdf, following spec.md. Done when `python3 check.py site` prints 20/20 and the reviewer agent replies PASS on all six judgment promises — show me both. Stop after 15 check attempts or 3 review rounds and write what is still failing to progress.md.
Phir chale jayein. Yeh PDF parhta, design chunta, alfaaz likhta, page banata, checker chalata, apni failures parhta, aur dobara koshish karta hai, jab tak woh jumla sach na ho.
Har clause is concept ke aik khayal ko asal kaam mein lagata hai. Command se sabit hone wali condition: check.py woh 20 checks chalata hai jin ka faisla machine kar sakti hai, jaise paanch sections ka mojood hona, contrast ratios, aur phone screen se kuch bahar na jana. Nazar aane wala saboot: show me both is liye hai ke /goal ka checker sirf transcript parhta hai aur jo result print na ho us ki tasdeeq nahin kar sakta. Cap: 15 attempts, kyunke /goal mein built-in give-up nahin aur na-mumkin condition ka peecha karne wala loop raat bhar peecha karega. Aur checker maker nahin: alag reviewer agent, jise spec lazmi banati hai.
Yahin project tutorial se aage nikalta hai. 20/20 done nahin. Reviewer ko woh chhe cheezein bhi pass karni hain jinhein command naap nahin sakti: kya writing aap ki CV se sachchi hai, kya page design hua hai ya sirf format, kya yeh bas PDF bhi ho sakta tha? Spec saaf kehti hai: "Part A is a morning's work. Part B is the job." Aap checker ladder mein yeh khayal dekh chuke hain; yahan isay mehsoos karte hain.
Project aik qaida kabhi nahin torta, aur yehi is ki sab se tez baat hai: pass karwane ke liye kabhi check.py edit na karein. Green ke liye optimize karta loop sab se pehle isi raste par jayega; is khwahish ko pehchanna hi sabaq 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.
OpenCode mein hard cap ke saath wohi shape:
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.
OpenCode agent config mein steps limit bhi leta hai; purana maxSteps naam deprecated hai. Shell cap beats ki tadaad bandhta hai aur steps aik beat ke andar agent ke turns. Dono limits set karein.
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.
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 (aap ke sote hue chalte hain)
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."
claude.ai par Routine set karein, laptop band karein, aur Anthropic ke servers ko schedule par usay chalate dekhein jab aap ka laptop band ho.
Pehle naam samajh lein. Scheduler aam cheez hai: koi bhi hamesha-on ghari jo waqt par naya run shuru kare (cron, GitHub Actions, ya cloud service). Routine Claude Code ka apna cloud-hosted scheduler hai, jahan ghari aur machine Anthropic deta hai, is liye aap ki koi cheez on rehna zaroori nahin. Har Routine scheduler hai. Har scheduler Routine nahin.
Is ki do qisamain hain, is bunyaad par ke laptop on chahiye ya nahin:
Cloud Routines (laptop band ho sakta hai). Yeh aaj ka default hai aur isay aahista samajhna faida-mand hai. Cloud Routine aik mustaqil hidayat hai jo aap ke computer par nahin, Anthropic ke servers par rehti hai. Aap hidayat aik baar likhte hain. Phir yeh tay kiye hue waqt par khud chalti hai, chahe laptop khula ho, so raha ho, ya bag mein band ho. Ise aise worker ki tarah samjhein jo aap ke nahin, Anthropic ke daftar mein baitha hai: aap likhi hui job description dete hain aur kaam ko khud host kiye baghair anjam milta hai.
Is poore section mein aik misaal zehan mein rakhein. Har subah aap wohi 30 minute ka triage karte hain: raat ko aane wale issues parhna, unhein label karna, crash jaisi cheez ko flag karna, aur team ke Slack mein summary post karna. Yeh aadha ghanta Routine ke liye bilkul munasib hai. Yeh dohrata hai, likhe ja sakne wale qawaid par chalta hai, aur isay aap ki zaroorat nahin. Isay aap ki hidayaat chahiye.
Har Routine ke chaar hisse. Aik Routine banane ka matlab chaar khaane bharna hai. Har khaana aik sawal ka jawab deta hai.
- Prompt: isay kya karna chahiye? Mustaqil hidayat, us spec ki tarah jo aap likhna seekh chuke hain: maqsad, qawaid, aur "done" kaisa nazar aata hai. Har run ko yehi prompt milta hai aur wazahat dene ke liye koi mojood nahin hota, is liye isay aap ki ghair-maujoodgi mein bhi kaam karna chahiye. Triage ki misaal mein:
Review all issues opened in the last 24 hours. Label each as bug,
feature-request, or question. If any issue describes a crash or data
loss, add the "urgent" label. Then post a summary to the #triage Slack
channel: total new issues, how many urgent, and one line per urgent
issue. If there are no new issues, post "No new issues overnight."
Do not close or comment on any issue.
Spec ki banawat dekhein: maqsad (triage aur summary), qawaid (in tareeqon se label karein aur urgent ka matlab crash ya data loss hai), had (kisi issue ko band ya comment na karein), aur khaali surat ke liye bhi wazeh "done".
-
Repos: yeh kin cheezon ko chhoo sakti hai? Aap un repositories ke naam dete hain jin mein yeh kaam kar sakti hai. Jo cheez list mein nahin, woh is ki pahunch se bahar hai. Sirf
yourteam/product-appdein. Billing code wale repo samet aap ke baqi repos is Routine ke liye mojood hi nahin. -
Connectors: yeh kahan tak pahunch sakti hai? Slack, email, calendars. Yeh repo se bahar Routine ke haath hain: isi tarah yeh bahar ki duniya parhti aur aap ko report karti hai. Sirf Slack connector jorein taake yeh #triage mein post kar sake. Connectors ijazatein hain, mashware nahin: email connector ke baghair yeh email nahin bhej sakti, chahe prompt isay kahe.
-
Trigger: yeh kab shuru hoti hai? Yehi heartbeat hai. Kaam ki teen shaklon ke liye teen qisamain hain. Schedule: ghari isay har weekday 8:30 par shuru karti hai, taake team ke baithne se pehle summary tayyar ho. API call: koi doosra program isay shuru karta hai, is liye deploy script release mukammal kar ke "release ka smoke-check karein aur report dein" run fire karti hai; Routine fixed ghari par nahin, check karne ki cheez aate hi chalti hai. GitHub event: repository ka event isay shuru karta hai, is liye "pull request opened" trigger khamosh din mein zero aur masroof din mein nau martaba chal sakta hai (Concept 7 isay cover karta hai).
Kya karna hai, kahan act kar sakti hai, kahan tak pahunch sakti hai, aur kab shuru hoti hai. Har Routine in chaar jawabon se banti hai. Issue-triage worker ab poori tarah bayan ho chuka hai: oopar wala prompt, aik repo, aik Slack connector, aur weekdays par 8:30.
Aik feature, teen darwaze. Aap claude.ai/code/routines par, Desktop app mein, ya CLI ke /schedule se Routine bana sakte hain. Yeh teen mukhtalif features nahin hain. Teenon tareeqe wohi cloud feature manage karte hain: kisi bhi darwaze se bani har Routine wohi cloud account mein save hoti aur teenon jagah nazar aati hai. Misaal ke taur par terminal mein /schedule se bana kar baad mein browser mein edit kar sakte hain.
Run mein kya hota hai. Monday ko 8:30 par Anthropic ke servers aik naya Claude session shuru karte, isay aap ka prompt dete, aur sirf woh repo aur connectors dete hain jo aap ne list kiye. Yeh weekend ke issues parhta, label karta, #triage mein post karta hai ("7 new issues, 1 urgent: login crash on Android (#412)"), phir band ho jata hai. Tuesday ka run bilkul taza shuru hota hai. Monday ka session ja chuka hota hai. Aap ki machine par kuch munhasir nahin, aur yehi isay aisa asal loop banata hai jise aap ko dekhna nahin parta. (Isi liye spine, Concept 12, repo mein rehni chahiye.) Bharosa karne se pehle do product rules check karein. Pehla qaida: daily cap hoti hai. Har account ko roz Routine runs ki muqarrar tadaad milti hai: launch par Pro mein 5, Max mein 15, aur Team aur Enterprise mein 25. Kisi aur ke servers par chalne wale unattended system ka budget hona chahiye. Yeh har cloud service mein sach hai, aur is tadaad ke gird design karna chahiye, na ke baad mein hairan hona. Pro plan par seedha hisaab: issue triage (1 run), shaam ka commit summary (1 run), aur 4 pull requests wale din PR-review Routine (4 runs) kul 6 runs hain, yani cap se aik zyada. Tarteeb se options yeh hain: dono daily reports ko aik Routine mein mila dein, masroof dinon mein PR reviewer ke liye extra usage khareedein, ya plan upgrade karein. Yeh hisaab loop ke paanchwein run par khamoshi se rukne se pehle karein. Teen baatein cap ko narm karti hain: yeh launch-time numbers hain, is liye Doosra qaida: default mein yeh sirf Yeh rukawat nahin, achhi baat hai. Yeh pehle din se unattended kaam ko mehfooz rakhti hai: Routine sara kaam kar sakti hai, lekin merge ka faisla ab bhi aap karte hain. Misaal dekhein. Aap flaky tests raat ko theek karne ke liye doosri Routine banate hain. 3 AM par yeh fix ko Baad mein, jab repo bohat se saaf runs ke baad aap ka bharosa kama le, to Allow unrestricted branch pushes setting se sirf us repo ke liye qaida band kar sakte hain. Ise jaan boojh kar, aik waqt mein aik repo par karein, bilkul kisi ko chaabi dene ki tarah.Ikhtiyari: mojooda Routine limits aur branch rules
claude.ai/settings/usage check karein; one-off scheduled runs count nahin hote; aur cap ke baad extra usage khareedi ja sakti hai.claude/ branches par push kar sakti hai. Nayi Routine main par nahin likh sakti. Har push ki jane wali branch claude/ se shuru honi chahiye.claude/ branch par push karti hai. Subah aap tabdeeli parhte, durust lagne ki tasdeeq karte, aur khud merge karte hain. Routine ne aap ke sote hue kaam kiya. Aap ne uth kar check kiya. Yehi faasla asal maqsad hai.
Routine kab sahi tool hai: jab kaam ko aap ki machine ki zaroorat na ho. Issue triage, stakeholders ke liye Friday ka "is hafte kya badla" digest, competitor ke changelog ki nigrani, ya mamooli support issues ke jawab ka draft. Agar aap sochte hain "yeh mere baghair har roz khud hona chahiye," to yehi tool hai. (Har form field, environment, aur secrets Routines appendix mein samjhaye gaye hain. Cloud aur cron ke darmiyan teesra native option bhi hai: Desktop scheduled tasks, jo Desktop app mein bante hain. Yeh aap ki asli files, hatta ke unsaved tabdeeliyon, par locally chalte hain aur khula session nahin chahiye, lekin machine on honi chahiye.) Aap terminal se seedhi zaban mein Routine ki poori zindagi manage kar sakte hain. Ise banayein, apni Routines ki list dekhein, aik ko abhi chalayein, ya timing badlein: Teen chhoti baatein: Agar CLI mein Ikhtiyari: terminal se Routine manage karein
/schedule every weekday at 9am, run the daily-triage skill # create it
/schedule list # see what you have
/schedule run the triage routine now # fire one run, to test it
/schedule update the triage routine to every two hours # change the timing
update aik cron expression bhi leta hai: waqt ko exact likhne wala chhota code. Misaal ke taur par 0 9 * * 1-5 ka matlab "Monday se Friday 9am" hai./schedule tomorrow at 9am, …. One-offs daily run limit mein count nahin hote, is liye prompt ko roz chalane se pehle aik baar aazmane ka muft tareeqa hain./schedule ghaayab lagay to Routines appendix batata hai ke kya check karna hai.
Apne cron se aik prompt chalayein (laptop on, Anthropic cloud nahin). claude -p aik prompt chala kar band ho jata hai. Isay seedha computer ke crontab mein rakh sakte hain:
# 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
Jab pehli real Routine banani ho to Routines appendix tamam fields, triggers, secrets aur aam masail qadam-ba-qadam dikhata hai.
Schedule woh heartbeat hai jise aap fire hotay nahin dekh sakte, kyunke midnight aata hai jab aap dekh nahin rahe hotay. Isi liye aik project raat bhar akela chhornay ke liye bana hai: Sky Watch. Har subah yeh NASA ka asteroid feed check kar ke aap ke liye note chhorta hai: aaj Earth ke paas se kya guzray ga aur kya woh khatarnak hai.
Clone kar ke pehle haath se sabit karein ke yeh chalta hai:
what asteroids are coming this week?
Aap ko seedhi zaban mein watch milti hai: "fikr ki koi baat nahin, sab se qareebi cheez Chand se 23 guna door guzarti hai, sab saaf hai." Phir aik line se isay loop banayein:
/schedule every day at midnight, run the sky-watch skill for today and write me the forecast
Laptop band karein. Subah watch intezar kar rahi hogi, aisi machine ne likhi jo aap ki kabhi thi hi nahin, aise waqt jab aap so rahe thay. Email connector jorein to yeh visual card ki surat mein inbox mein aa sakti hai, har pass proximity bar ki tarah bana hua. Ghaur karein ke prompt for today kehta hai, "week ahead" nahin: daily run ko us din ki report deni chahiye jab woh fire ho, warna woh har subah kal ki forecast dobara bhej dega. Window ko cadence se milayein.
Do cheezein isay Doorbell (Concept 7) nahin balkay schedule banati hain. Yeh peechay nahin, aagay dekhta hai: kal ke pass ki warning, na ke kal guzarne wale event ki report. Aur jab kuch nahin hota tab bhi yeh bolta hai. Aksar subah yeh sirf "all clear" kehta hai, aur watch ka maqsad yehi khamosh report hai. Event-driven loop pur-sukoon din mein khamosh rehta hai. Schedule phir bhi report deta hai. Midnight ka intezar kiye baghair pehle one-off fire karein (/schedule in 2 minutes, run the sky-watch skill), kyunke one-offs daily cap mein count nahin hote. Part 6 ka qaida yahan haqeeqat banta hai: slow aur unattended bharosay se pehle fast aur watched proof hasil karein.
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.Ikhtiyari: community scheduling plugins
opencode-scheduler jaise community plugins seedhi zaban ki request ko operating-system schedule mein badal sakte hain, overlapping runs rok sakte hain, aur insani jawaab ka intezar karne wale prompts reject kar sakte hain. Yeh third-party software hai, is liye bharosa karne se pehle dekh lein ke plugin active taur par maintained hai.
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-5 # 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.
Claude Code Routine Anthropic ke servers par chalti hai. OpenCode schedule operating system ya GitHub Actions se chalta hai. Dono chune hue waqt par fresh work shuru karte hain, is liye dono ko model ke bahar saved state chahiye.
OpenCode GitHub Action current official docs mein anomalyco/opencode/github@latest hai; purani guides ab bhi sst/opencode/github@latest dikhati hain. Dono aik hi project hain. Jo opencode github install generate kare woh istemaal karein. Models mein current Sonnet tier ka API ID claude-sonnet-5 hai. Adaptive thinking default on hai aur naya tokenizer wohi text taqreeban 30% zyada tokens mein likhta hai, is liye purane budgets seedhe transfer nahin hote. Purani 4.5 generation ka dated canonical ID claude-haiku-4-5-20251001 aur dateless claude-haiku-4-5 alias hai. Exact strings ke liye opencode models chalaayein.
7. Event-driven (kuch hone par jawab dein)
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.
Yeh baghair ghari aur baghair kisi nigran ke khamosh rehta hai. Phir kuch hota hai: PR, message, ya alert. Loop har aik ko us ke apne route par aate hi foran jawab deta hai, phir dobara khamosh ho jata hai.
Yeh section events ke bare mein hai. Event sirf kisi cheez ke hone ka naam hai. Har event ka aik catcher, yani us par react karne wala tool, hota hai, aur sab catchers aik jaise nahin. GitHub events aur "baqi har cheez" ke events Routine pakarti hai. Chat messages Channel pakarta hai. Is liye teen catchers mein se do Routines hain aur aik, Channel, Routine nahin. Channel ki aik kamzori, ke isay aapki machine on chahiye, neeche table mein saaf likhi hai.
Claude Code mein event kahan se aata hai yeh tay karta hai ke aap kaun sa tool use karein. Teen routes hain.
1. GitHub se aaye to Routine use karein. Routine ko ghari par chalna zaroori nahin. Is ka trigger GitHub event bhi ho sakta hai. Do qisam kaam karti hain: pull request ka badalna, yani khulna, update hona, ya merge hona; aur release ka publish hona. Misaal: "jab PR khule to review aur comment karein," ya "jab release publish ho to changelog ka draft banayein."
Aik banane se pehle teen tafseelaat aham hain:
- Setup. Claude GitHub App ko repository par install karna zaroori hai.
/web-setupclone access deta hai lekin App install nahin karta. Yeh farq bohat si pehli koshishon ko uljhata hai. - Pushes. Push trigger nahin hai. Lekin jab khule PR wali branch par naya commit push hota hai to GitHub isay PR update, yani
synchronizedevent, report karta hai aur Routine chalti hai. PR ke baghair branch par push se kuch nahin hota. - Filters. Aap un events ko mehdood kar sakte hain jin par Routine chalti hai: author, title, labels, base ya head branch, draft state, aur mazeed. Field-by-field tafseel, hourly event caps, aur aham edge cases Routines appendix ke A3 mein hain.
2. Chat app se aaye to Channel use karein. Channel bahar ki app se message seedha us session mein bhejta hai jo pehle se chal raha hai. Telegram, Discord, aur iMessage out of the box kaam karte hain. Kisi aur cheez ke liye webhook set karein. Yeh Part 2 ki doorbell hai: message aane tak kuch nahin hota, phir session foran jawab deta hai. Misaal ke taur par desk se door hon to Telegram se pooch sakte hain, "deploy khatam hua?" Maujooda session apni current context, skills, aur history ke saath check kar ke jawab deta hai. Loop usi Channel se reports wapas bhi bhej sakta hai.
- Live session zaroori hai. Session pehle se chal rahi ho, khula terminal ya background session. Machine band ho to Channel kaam nahin karta.
- Yeh khula darwaza hai. Jo shakhs connected source ko message bhej sakta hai woh session ko steer kar sakta hai, is liye sirf apne control wale sources connect karein.
Setup: code.claude.com/docs/en/channels.
3. Baqi kisi bhi jagah se aaye to API trigger wali Routine use karein. Kuch events na GitHub se aate hain na chat app se: monitoring tool alert fire karta hai, deploy khatam hota hai, ya form submit hota hai. Routine ko API trigger dein. Phir har woh system jo authenticated web request bhej sakta hai, yani aisi request jo apni pehchan sabit karti ho, laptop band hone par bhi Routine fire kar sakta hai. Request event ki details bhi la sakti hai: optional text field alert message ya failing log jaisi run-specific context saved prompt ke saath bhejta hai. Endpoint, token, aur retry warning Routines appendix ke A3 mein hain.
Chaaron mein intikhab:
| Event kahan se aata hai... | Istemaal karein | Kaam kahan chalta hai... | Laptop band? |
|---|---|---|---|
| GitHub (PR ya release) | Routine, GitHub trigger | Har event par naya cloud session | Kaam karta hai |
| GitHub, Routine ke baghair | Claude Code GitHub Action in CI | Har event par naya CI runner | Kaam karta hai |
| Chat message (Telegram, Discord, iMessage) | Channel | Woh session jo pehle se chal raha hai | Nahin, machine chahiye |
| Web request bhejne wala koi bhi system | Routine, API trigger | Har call par naya cloud session | Kaam karta hai |
Doosri row jitni nazar aati hai us se zyada aham hai. Laptop band rakh kar kaam jari rakhne ka sirf Routine hi raasta nahin. GitHub Actions workflow mein anthropics/claude-code-action@v1 wohi kaam karta hai, aur isay research-preview access ya daily run cap nahin chahiye. Pro ya Max plan kaafi hai: claude setup-token runner ke liye credential deta hai, is liye API key bhi nahin chahiye. Unattended kaam ka yeh sab se sasta darwaza hai.
Yeh chaaron rows ke neeche wale rule ki taraf ishara karta hai. Sawal kabhi yeh nahin ke "kya yeh Routine hai?" Sawal yeh hai ke "kaam kis ke computer par chalta hai?" Aapki machine band karne par mar jati hai. Anthropic ke servers aur GitHub runners nahin marte, kyunke woh kabhi aapke thay hi nahin. Isi liye un rows ko token chahiye aur /loop ko nahin: aapka laptop pehle se janta tha ke aap kaun hain, kiraye ka ajnabi nahin janta. Credentials ki zaroorat aur band lid ke baad zinda rehna aik hi fact ke do rukh hain.
Channel ke siwa har row ka pattern dekhein: har event fresh session shuru karta hai, is liye do events aik doosre ke bare mein kuch nahin jante. Aik PR par do pushes do alag sessions hain. Spine, Concept 12, unhein state share karwati hai.
Upar ka daawa tab tak sirf alfaaz hai jab tak aap use hota na dekhein. Is concept ka chhota project The Doorbell sirf aik kaam karta hai: woh aisi pull request review karta hai jis ka kisi ne us se kaha hi nahin.
Kit ko apne repo mein copy karein, claude setup-token se token banayein, usay aik secret ke taur par add karein, phir bug wali pull request kholein. Takreeban aik minute baad review nazar aata hai. Aap ne koi prompt type nahin kiya. Koi dekh nahin raha tha.
Phir woh kaam karein jo concept ko zehan mein bithata hai: laptop band karein aur kisi aur se PR khulwayein. Review phir bhi aata hai. Aik move mein Concept 4 se farq samne aa jata hai. ISS loop terminal band karne par mar gaya, kyunke woh aapki machine par chal raha tha. Yeh loop kabhi aapki machine par tha hi nahin. Doorbell bajti hai to GitHub computer kiraye par leta, kaam chalata, aur machine phenk deta hai.
Token ki wajah bhi yehi hai. Aapka laptop janta tha ke aap kaun hain. Kiraye ka ajnabi nahin janta. Har unattended loop yeh qeemat deta hai.
Aik baat pehle se jaan lein, kyunke is ne hamara aik ghanta liya: green checkmark ka matlab yeh nahin ke kaam hua. Aik setting miss ho to run success hota, review karta, magar kuch post nahin karta. Project ka README setting aur symptom dono batata hai. Yeh Routine ke bajaye Claude Code GitHub Action use karta hai: wohi doorbell, baghair preview access aur daily cap.
Aur ending oopar wale paragraph ka proof hai. Doosri baar push karein to naya review aapke pehle commits ke hashes durust cite karega, halanke woh aisi machine par chala jo pehle kabhi thi hi nahin aur kuch yaad nahin rakhti. Us ne yaad nahin rakha. Us ne repo parha. Yehi spine hai, jis se Part 4 mein theek se milenge.
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-5
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.
Schedule ghari ka intezar karta hai. Event-driven loop kisi cheez ke hone ka intezar karta hai. Event aate hi aik beat shuru hoti hai.
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? Run-until-done — Claude Code mein Show answer
/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.
Ab aap chaar heartbeats jante hain. Sab se bari ki taraf foran na jayen. Har loop do choices se define hota hai: isay kya shuru karta hai aur kya rokta hai. Is liye kuch banane se pehle task ke bare mein aik sawal poochein: kya yeh khatam hota hai, ya repeat hota hai?
- Task khatam hota hai aur command end sabit kar sakti hai: conditional loop; ab shuru karein aur done tak chalne dein.
- Task repeat hota hai: schedule ya event.
- Task aik martaba hota hai: loop bilkul nahin. Aam session, turn by turn, zyada tar kaam ke liye ab bhi sahi tool hai.
Aik aur rule: jab repeating loop naya ho, unattended bharosa karne se pehle us ki pehli chand asli runs dekhein. Part 6 isay rule banata hai: overnight istemaal se pehle loop sabit karein.
Naam par aakhri note. Log online yeh words dheele istemaal karte hain, is liye translation yaad rakhein. "Turn-based" aam session hai. "Goal-based" hamara conditional loop. "Time-based" hamari do mukhtalif qismein, in-session aur scheduled, ko mila deta hai. "Proactive" Part 5 jaisa fully composed loop hai. Labels mukhtalif, parts wohi.
Mashq: Heartbeat chunein, phir aik banayein
Ab aap chaaron heartbeats jante hain, aur inhein use karne ka behtareen waqt yehi hai jab chaaron tasveerein taza hain. Do qadam. Pehle sabit karein ke aap sahi heartbeat choose kar sakte hain. Phir aik shuru karein.
Pehla qadam: intikhab (2 minute, kuch install nahin). Har task ka heartbeat batayein. Aik task phanda hai.
- Har Friday team ke liye hafte ke merged pull requests ka khulasa draft karein.
- Failing build par tab tak kaam karein jab tak green na ho, phir ruk jayein.
- Koi pull request khole to us ka review ho.
- 40-minute migration chal rahi hai aur khatam hote hi pata chalna chahiye.
- Poore repo mein aik variable ka naam badlein.
Jawabat dekhein
- Scheduled. Ghari par dohrata hai aur wahan kisi ka hona zaroori nahin. Routine ya
cronline, Concept 6. - Conditional, yani run-until-done. Yeh khatam hota hai aur command end sabit karti hai.
/goalya capped shell loop, Concept 5. - Event-driven. Bahar ka action shuru karta hai, is liye khamosh din mein zero baar fire hota hai, Concept 7.
- In-session. Aap ab bhi dekh rahe hain aur session band karne par ruk sakta hai.
/loopyasleepwalawhileloop, Concept 4. - Loop bil-kul nahin. Task aik martaba hota hai, is liye aam session sahi tool hai. Agar yahan loop choose kiya to oopar wali tip dobara parhein. Aksar kaam ab bhi isi row mein rehta hai, aur course ke baad bhi rahega.
Doosra qadam: aik banayein. Har heartbeat ka project course ke aakhir mein intezar kar raha hai. Abhi sab chaar na banayein. Do tayyar hain, aur do jaan boojh kar un parts tak aage jate hain jinhein aap ne abhi nahin parha:
| Heartbeat | Concept | Kahan banayein | Abhi tayyar? |
|---|---|---|---|
| In-session | 4 | Project 1, watch loop | Haan |
| Conditional | 5 | Project 2, tests pass hon phir stop | Haan |
| Scheduled | 6 | Project 3, memory wala morning brief | Part 4 ke baad; spine chahiye |
| Event-driven | 7 | Project 6, doorbell loop | Part 3 ke baad; connectors chahiye |
Us aakhri column par aik lamha dena banta hai. Memory ke baghair schedule har subah wohi pehla qadam dohrata hai, aur PR na khol sakne wala event-driven loop sirf baat kar sakta hai. Is liye aap ke baghair chalne wali dono heartbeats bil-kul wohi hain jinhein pehle course ka baqi hissa chahiye. Yeh padding nahin; isi cheez ki shape hai.
Project 1 sab se sasta start hai: takreeban 15 minute, configure karne ko schedule nahin, aur aapke door hone par chalne wali koi cheez nahin. Part 3 se pehle sirf aik kaam karein to yehi karein.
Part 3: Har Run Mein Loop Kya Karta Hai (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. Alag rakhna: 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. Ilm: skills, taake koi run "pehla din" na ho
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 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 (loop sirf mashwara nahin, kaam karta hai)
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 ka serve subcommand aik baar shuru karein aur us se --attach karein, taake aap har beat par MCP start-up cost na dein.
Loop retry karta hai aur baghair nigrani tools choose karta hai. Is se achhe tool set ki shape badal jati hai:
- Kam, focused tools bohat se overlapping tools se behtar hain. Tool choose karna har beat par model ka faisla hai, aur koi dekh nahin raha hota. Aik sau overlapping tools dein to sahi tool ka pata kho jata hai. Practitioners ne dekha hai ke agent ke tools kam karne se success rate barhta hai. Anthropic ka rule of thumb: agar human engineer yaqeen se nahin keh sakta ke kaunsa tool fit hai, agent bhi nahin keh sakta. Haath se aik ghalat tool pick aik lamha leta hai. Loop mein har baar aik beat, hamesha ke liye. Is liye connector list ko sirf loop ki asal zaroorat tak trim karein. Routines appendix safety ke liye bhi yehi kehta hai; dono wajhein aik hi nateeja deti hain.
- Writes dobara chalne par safe hon. Failed step retry karne wala loop wohi write phir call karega. Dobara chalne wala "create customer" agar doosra customer bana de to duplicate records aur double billing chhor deta hai. Blind creates ke bajaye repeat-safe operations, jaise update-or-create ya har branch par aik PR, use karein.
- Errors agla qadam batayein. Loop mein error message hi aglay beat ka input hai. "Permission denied:
reposcope mangain" aglay try mein khud fix hota hai. "Error 403" aik beat zaya karta hai.
Haath se aap teenon masail baghair mehsoos kiye absorb kar lete hain. Sahi tool pick karte, duplicate rok dete, error search kar lete hain. Unattended halat mein yeh sab absorb karne wala koi nahin.
11. Maker-checker: subagents
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. Har agent par steps limit aur permission.task rules rakhein taake subagent mazeed subagents ko dairon mein na chalaye. 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.
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.
Interlude: Body ko codify karein, dynamic workflows ke saath
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.
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.
Aap ka loop aik hi waqt mein do agents chalata hai, aur aap us ki ghair mojoodgi mein hone wali commits par bhi bharosa chahte hain. Yeh do alag masle hain. Body ka kaunsa hissa har masla hal karta hai? Worktrees parallel kaam ka masla hal karte hain: har agent ko alag checkout milta hai, is liye edits takrati nahin. Maker-checker bharose ka masla hal karta hai: alag agent kaam check karta hai, is liye aap ke baghair bhi "done" ka ma'ni wazeh rehta hai. Isolation agents ko aik doosre ke raaste se door rakhti hai; checker bura kaam repo se door rakhta hai.Jawab dekhein
Interlude: Checker ko codify karein, verification skills ke saath
Pichhle interlude ne beat ke body ko codify kiya tha. Yeh interlude checker ko codify karta hai. July 2026 mein Anthropic ki Claude Code team ne isi pattern ko verification loop kaha: agent apna kaam check karta, ghalti theek karne ki koshish karta, aur check pass hone tak dohrata hai. Agentic coding course mein aap isay Attempt → Check → Fix → Repeat cycle ke taur par dekh chuke hain.
Naam ka aik farq yaad rakhein. Verification loop aik beat ke andar chalta hai. Is ka apna heartbeat aur spine nahin hota. Beat khatam to yeh bhi khatam. Is course ki zaban mein yeh small-loop machinery hai. Lekin jab heartbeat isi likhe hue check ko fire karta hai to woh big loop ka checker ban jata hai. Part 5 ka reviewer isi qisam ke likhe hue check ke mutabiq grade karta hai. Yani aap apne zehan ka check aik file mein rakh dete hain.
Kaun se checks likhein. Jo cheez agent ke kaam khatam karne ke baad aap har martaba haath se durust karte hain, usay check banana faidemand hai. Har frontend tabdeeli ke baad manual click-through, error logs se request body hatane ka jaiza, ya migration approve karne se pehle wohi sawalat. Procedure ko seedhi zaban mein aise likhein jaise naye teammate ko pehle din de rahe hon. Standard hissa model pehle janta hai; aapke project ke khaas farq asal qeemat hain.
Check sirf judgment call nahin hota. "Har us migration ko reject karein jo backfill step ke baghair column drop kare" aik fixed rule hai jise command sabit kar sakti hai, lekin aam linter mein yeh nahin milega kyunke yeh aapka rule hai. Checker ladder mein yeh built-in mechanical checks aur reviewer rubric ke darmiyan ki satah hai: mechanical checks jo sirf aap likh sakte hain. Rubric se is satah par aane wala har rule aik dawe ko proof bana deta hai.
Packaging aik skill hai. Concept 9 ka wohi SKILL.md container use hota hai. Farq sirf yeh hai ke andar procedure ki jagah check hota hai:
# .claude/skills/verify-log-hygiene/SKILL.md (or .opencode/skills/…)
---
name: verify-log-hygiene
description: Check that error logs include the request ID and never
include the request body. Use when the diff touches error handling
or logging.
allowed-tools: [Read, Edit, Grep]
---
Read the error-handling paths in the current diff.
For each log call on an error path, confirm it includes the request ID
and does not pass the request body, headers, or any user-supplied
payload.
Report each violation with file:line, then fix it: add the request ID
where it's missing and strip the payload from the log call.
allowed-tools is check ki pahunch ko read, edit, aur search tak mehdood karta hai. Yeh tools ke naam leta hai, individual commands nahin. Yeh Concept 14 ki standing permission hai. Kisi check ko khaas commands tak bandhna enforcement hai, jo Harness Engineering mein aata hai.
Check kahan chalta hai. Aik hi check ke chaar ghar ho sakte hain. Har ghar ka heartbeat mukhtalif hai.
- Standalone. Kaam maujood hone ke baad aap isay khud chalate hain. Yahan aap heartbeat hain. Yeh un checks ke liye sahi hai jo kai qisam ke kaam par lagu hon lekin har change par nahin: security scan, licence-header sweep, ya accessibility audit. Qeemat yeh hai ke har martaba yaad rakhna parta hai.
- Embedded. Check producing skill ke aakhir mein jor diya jata hai, is liye workflow baghair poochhe isay chalata hai. Fresh task par skill chala kar tasdeeq karein ke check waqai fire hota hai. Yeh sirf un skills par kaam karta hai jinhein aap edit kar sakte hain. Built-in aur plugin-managed skills update par overwrite hoti hain, is liye un ke liye chain use karein.
- Chained. Aik skill apne aakhir mein doosri skill bulati hai aur verified handoffs end to end chalte hain. Aisi skill ke liye jo aap badal nahin sakte, patli wrapper skill likhein: pehle asal skill, phir aapka check. Aadat, "main hamesha baad mein check chalata hun," contract ban jati hai: skill khatam hote hi check hamesha chalta hai. Lekin flexibility kam aur har run ke tokens zyada hote hain.
- Har PR par. Jab chain aapke apne changes par mazboot sabit ho jaye to Concept 7 ka event heartbeat wohi skills har pull request par chalata hai. Teammate ka change bhi wohi gates se guzarta hai. Yahan verification personal infrastructure se team infrastructure ban jati hai.
Anthropic ki apni chain roz /code-review se bugs dhoondti, /simplify se diff saaf karti, /verify se end-to-end rawayya confirm karti, aur UI changes ko /design se DESIGN.md ke khilaf check karti hai. Aik skill jo aap edit nahin kar sakte us ke liye wrapper pehle asal skill, phir yahi verification chain chalata hai.
Graduation rule. Ghar number chaar se shuru na karein. Jab aap khud ko har change ke baad check chalata dekhein, tab is ne permanent ghar kamaya hai: embed ya chain karein. Jab tak chain badal rahi ho usay team ke har PR ka gate na banayein, kyunke phir us mein har tabdeeli poori team ko mehsoos hoti hai. Pehle tez aur nazar ke saamne sabit karein, phir dheema aur unattended bharosa karein.
Late July 2026 tak teen shortcuts:
- Jo built in milta hai us se shuru karein.
/verifyskill application ko build, run, aur observe karti hai. Apna check likhne se pehle isay azmayein.CLAUDE.mdmein exact build aur test commands bhi likhein, taake har run unhein guess na kare. - Agent ko interview karne dein.
/skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.sawal pooch kar file banata hai. Haath se.claude/skills/mein likhna bhi wohi pattern hai. - Managed chautha ghar. Code Review research preview enabled repos ke PRs par managed multi-agent review chalata hai. Finding theek karke push karein, ya GitHub Action set ho to finding par
@claudecomment karein. Shape aapki hand-built chain jaisi hai; heartbeat aur reviewers Anthropic host karta hai.
Kuch naya install nahin karna. Oopar ka SKILL.md .opencode/skills/ se bhi chalta hai:
- Standalone:
opencode run "run the verify-log-hygiene skill on the current diff". - Embedded: apni producing skill ke body ke aakhir mein wohi aik line.
- Chained: Concept 5 ka script, jahan har skill ka exit state tay karta hai ke agla
opencode runchale ya nahin. - Har PR par: Concept 7 ki GitHub Action, jis ke prompt mein aapka verification skill ho.
Default no-prompt PR review Anthropic ke
/code-reviewka OpenCode parts wala mutabadil hai; apni verification skill ka prompt dein to standards aap ke ho jate hain.
Verification skill woh manual check hai jo aap pehle se kar rahe the, aik martaba likha hua taake agent usay chalaye aur milne wali ghalti theek kare. Pehle khud chalayein. Jab har martaba chalne lage to workflow se jorein. Jab chain aapke liye mazboot ho jaye to har PR par lagayein.
Do topics jaan boojh kar padosi courses ke liye hain. Check ko command-by-command sirf jaanch tak mehdood karna enforcement hai aur Harness Engineering mein aata hai. allowed-tools toolbox ko chhota karta hai, lekin asal locks us course mein hain. Rubric ke zariye judgment aur model ke score par bharosa grading hai aur Trusting the Checker mein aata hai. Claude Managed Agents ke Rubrics beta mein alag grader agent nateeje rubric se check karta hai aur fail kaam dobara bhejta hai. Mechanical layer badal sakti hai; live docs check karein.
Aap ne accessibility check do martaba haath se chalaya hai aur aaj hi poori team ke PRs par lagana chahte hain. Graduation rule kya kehta hai, aur kaun se do ghar chhoot rahe hain? Abhi nahin. Do manual runs ka matlab check abhi standalone ghar mein hai. Seedha har PR par jane se embedded aur chained ghar chhoot jate hain, jahan check pehle aapke kaam par khud ko sabit karta hai. Team ka gate banne ke baad har correction sab ko mutasir karegi. Wohi ladder: unattended se pehle watched, team se pehle personal.Jawab dekhein
Part 4: Runs Ke Darmiyan Memory (Spine)
12. Runs ke darmiyan bachne wali state
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, balkay wohi pehla step hamesha repeat hota hai. Fix saada aur powerful hai: state ko model ke bahar, disk par rakhein.
Save file ke baghair agent har run mein unhi spikes par marta hai. Phir woh save karta hai aur switch aap ke haath mein hai. On ho to file parh kar finish karta hai. Off ho to bhool kar dobara shuru karta hai.
Yeh game bil-kul isi concept ko dikhata hai. Agent runs ke darmiyan sab kuch bhool jata hai, is liye disk par save file rakhta hai, aur woh file spine hai. Start ke bajaye checkpoint par respawn hona aapki progress file (progress.md) hai: kya ho chuka aur kya abhi open hai, taake agla run sifr se shuru hone ke bajaye jari rahe. Us ka save kiya hua "spikes ahead" note aapki rules file (CLAUDE.md / AGENTS.md) hai: aik martaba seekha sabaq, taake wohi ghalti dobara na ho. Isi liye switch matter karta hai. Files ke saath loop run dar run build karta hai. Un ke baghair woh hamesha start line par ajnabi hai. Har run yeh files pehle parhta aur aakhir mein update karta hai, kyunke repo woh yaad rakhta hai jo model nahin rakh sakta.
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 koi zyada clever prompt nahin. Loop se sabaq rules file mein likhwayein, taake woh har future run ke liye rahe.
Agar state ki do layers abstract lagti hain to aik naye intern ka tasavvur karein. Aap usay workflow, ticket board, allowed tasks aur escalation ka tareeqa aik martaba samjhate hain, phir aik diary aur do hidayat dete hain. Pehli: feedback milay to sabaq diary ke shuru mein likho aur har subah dobara parho. Misal: "is design pattern ko mat use karo", "yeh team commits squash karti hai", ya "kuch dikhane se pehle linter chalao." Doosri: ghar jane se pehle diary ke aakhir mein likho ke kya mukammal hua aur kahan rukay, taake kal zero se nahin balkay aaj ke checkpoint se shuru ho. Diary ka shuru aap ki rules file hai: durable lessons jo har run parhe jate hain. Aakhir aap ki progress file hai: checkpoints jo har run update karta hai. Diary ke baghair intern roz wohi corrections dobara seekhta aur kal ka kaam phir karta hai. Loop bhi aisa hi karta hai, kyunke runs ke darmiyan model ki memory bilkul saaf ho jati hai. Diary optional cheez nahin; yahi employee aur roz anay wale ajnabi ka farq hai.
<!-- 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
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.
Spine par yaqeen tab aata hai jab aap loop ko bhooltay dekhein. Isi liye Paper Watch banaya gaya hai. Yeh har din aap ke chune hue topic ke naye research papers dikhata hai, magar sirf woh jo aap pehle nahin dekh chukay. Kuch install nahin karna aur key bhi nahin chahiye; Claude arXiv se khud papers lata hai.
Project clone karein, folder apne agent mein kholein aur poochein:
show me what's new on arXiv about "LLM agents"
Naye papers newest-first milte hain. Ab bilkul wohi sawal dobara karein aur jawab hota hai "nothing new since last run ✓". Loop ne yaad rakha: us ne dikhaya gaya har paper progress.md mein likha aur jawab se pehle file dobara parhi. Yeh file spine hai. Saboot ke liye memory mita kar phir poochein:
rm progress.md
show me what's new on arXiv about "LLM agents"
Har paper phir "new" ban jata hai. Aik command se loop sab bhool gaya: spine nahin to loop nahin. Isay asal watch banane ke liye Concept 6 wala daily heartbeat dein: /schedule every weekday at 9am, run the paper-watch skill and show me what's new. arXiv takreeban roz refresh hota hai, is liye daily run sahi rhythm hai.
Isay Concept 6 ke Sky Watch ke saath rakhein. Donon daily Routines hain. Sky Watch har run par aaj ke asteroids dobara dikhata hai aur usay memory nahin chahiye. Paper Watch sirf naya dikhata hai aur spine ke baghair chal hi nahin sakta. Heartbeat aik, memory ki zaroorat ulat; yahi batata hai ke loop ko spine kab chahiye.
Optional background; pehli reading mein chhorna theek hai.
Is course ki spine disk par sada markdown hai. Yeh beginners ke liye kamzor simplification nahin. Anthropic ki memory research bhi alternatives azmanay ke baad yahin pohanchi:
- Rules file (
CLAUDE.md) pehle ayi: har session ke shuru mein inject honay wali markdown file. Yeh ummeed se behtar chali, magar phoolti hai aur us ka har lafz har run par paid context banta hai. - In-session memory tools agla qadam thay: task ke darmiyan agent khud decide kare ke memory kab parhni ya likhni hai. Autonomy chali, tooling bohat opinionated thi.
- Skills ne growth ka masla hal kiya: agent sirf har skill ki chhoti description parhta hai aur full body zaroorat par load karta hai.
- Mojooda best practice sab se seedhi hai: memory ko plain file system samjhein. Folders mein markdown files rakhein aur agent ko special memory API ke bajaye
grepaur shell jaise aam tools se search karne dein. Store bara ho sakta hai, bas searchable rehna chahiye.
Yahi spine hai: repo ki files jo shuru mein parhi, aakhir mein update, aur normal tools se search hoti hain. Jab frontier lab ka production jawab aur beginner ka pehla loop aik design use karein, to woh training wheels nahin balkay load-bearing design hota hai.
Optional technical detail; pehli reading mein chhorna theek hai.
Jab loop kisi sabaq ko CLAUDE.md mein likhta hai taake future runs behtar hon, to aap haath se hill-climbing loop chala rahe hote hain. Is ka output kaam nahin; kaam karne wale system ki behtari hai.
Automatic version mein har run trace chhorta hai. Aik step traces parh kar dohrayi ghaltiyan dhoondta hai, phir prompt, tools ya checker rules mein tabdeeli propose karta hai. Yani loop khud ko edit karta hai.
LangChain chaar stacked loops bayan karta hai: agent ka tool cycle, checking loop, event-driven loop aur sab ke upar improvement loop. swyx in loops ko stack karne ko loopcraft kehta hai. Pehle teen isi course ke inner loop, maker-checker aur heartbeat hain. Industry baar baar isi shape par pohanchti hai; skill tool nahin, shape hai.
Aik farq saaf rakhein: model khud nahin seekh raha. Public model apne sessions se weights nahin badalta. Kal bhi wohi model chalega. Behtar prompt, rules file, skills aur checker rubric hotay hain. Kuch log pehle ko self-learning aur doosre ko self-improving kehte hain. Is course ke loops doosri qisam hain: sabaq disk par zinda rehta hai, model mein nahin. Beginner mayoos run ke baad kal naya prompt likh kar phir zero se shuru karta hai. Loop run karta, log likhta, sabaq nikalta, system mein save karta aur phir chalata hai. Memory jama hoti aur gains compound hotay hain.
Shuru karne ke liye special platform nahin chahiye. Aik haftay ki progress.md entries parhein aur poochein: "rules file kya kahe taake yeh ghalti dobara na ho?" Magar Part 6 wali warning yaad rakhein: improvement loop apne rules dobara likhta hai, is liye is par bhi human gate chahiye.
Optional technical detail; pehli reading mein chhorna theek hai.
Anthropic ki applied AI team is managed hill-climbing process ko dreaming kehti hai. Naam munasib hai: working agents ke rest ke waqt process chal kar un ke seekhay hue sabaq saaf karta hai.
Un ki vocabulary mein in-band memory live session ke andar likhi jati hai. Yeh kaam karti hai, magar agent ko current task aur future memory ke darmiyan tawajjo baantni parti hai. Woh sirf apna session dekh sakta hai, is liye das sessions ya das agents mein dohrayi ghalti nahin dekh pata.
Dreaming out-of-band jawab hai. Is ka apna heartbeat aur token budget hota hai. Har beat mein:
- Memory store, yani rules aur progress files, ko recent run transcripts aur tool calls ke saath ikattha karein.
- Orchestrator transcripts analyst subagents mein taqseem kare.
- Woh sessions ke paar dohray patterns dhoonde: wohi failing tool call, missing knowledge ya style mistake.
- Memory store mein tabdeeli evidence ke saath propose ho: kin transcripts mein pattern aya aur kitni baar.
- Har tabdeeli lagu honay se pehle insan accept ya reject kare.
Course ki zuban mein batch schedule heartbeat, memory store spine, analysts subagents, evidence wala proposal maker-checker, aur final faisla human gate hai. Dreaming nayi shape nahin; chhe-part loop hai jo code ke bajaye apni memory par kaam karta hai.
Do warnings seedhi aap ke loops par lagu hoti hain. Memories stale hoti hain: chhe mah pehla sabaq ab ghalat ho sakta hai, is liye dreaming ko prune bhi karna chahiye. Aur shared memory ko production guardrails chahiye, jo Concept 14 mein hain.
Pehle apne tools check karein, kyunke is ka version ship ho raha hai. Claude Code ka research-preview Auto Dream sessions ke darmiyan notes ko merge, duplicate aur purani baatein delete karta hai; woh memory files likh sakta hai, code nahin. /memory chala kar Auto-dream toggle dekhein. Manual pass ke liye "consolidate my memory files" kahein. OpenClaw mein opt-in /dreaming hai aur OpenCode ke community equivalents hain. Yeh mechanical layer hai; live docs check karein.
Cleaner nayi evidence ko purani notes par tarjeeh deta hai, is liye haath se likhi note bhi badal sakti hai. Jo rule kabhi auto-edit nahin hona chahiye woh CLAUDE.md mein rakhein. Auto-managed notes Claude ki notebook hain; CLAUDE.md aap ki.
Auto Dream hygiene karta hai; neeche wala loop improvement karta hai. Aik cleaner, aik coach. Coach aap khud in parts se bana sakte hain:
- Heartbeat: weekly. Patterns ke liye batch chahiye, is liye weekly cloud Routine,
cronya GitHub Actions sahi cadence hai. - Input: readable transcripts. Har working loop per beat dated
progress.mdentry aur run logs chhore. OpenCode meinopencode run --format jsonauropencode exportfull record dete hain. Logs nahin to dream karne ko kuch nahin. - Body: orchestrator aur analyst subagents. Har analyst poochta hai: kya fail hua aur kya woh aik se zyada baar hua? Aik ghalti noise, teen baar wohi ghalti missing lesson hai.
- Maker-checker do martaba. Analysts propose karte, orchestrator sirf evidence walay patterns rakhta hai. Phir loop rules file ya skill ko seedha edit nahin karta;
claude/branch par PR draft karta hai aur evidence attach karta hai. - Human gate.
CLAUDE.mdya skill ki tabdeeli har future run ko steer karti hai, is liye aap merge ya close karte hain. - Dreaming ki apni spine.
dreaming-state.mdmein aakhri reviewed batch ki date rakhein, taake agla run sirf naye logs parhe.
Store git mein ho to versioning aur rollback free milte hain; PRs permissions ko "sirf aap merge karein" tak samet dete hain. Dreaming ko deletions bhi propose karni chahiye, warna rules file har beat par mehngi aur har mah kam trustworthy hoti jati hai.
Yeh attack ko saaf libas pehna sakta hai. Transcripts mein issue bodies, PR descriptions aur fetched pages jaisi outsider text hoti hai. Memory poisoning mein aik run ki planted instruction memory ban kar tamam future runs ko steer karti hai. Is liye proposal cited runs ka evidence de aur human source parh kar hi rule approve kare.
Yeh apni memory ko ghisa sakta hai. Repeated rewriting mein brevity bias specifics gira deta hai aur context collapse har copy ko pichli se zyada vague banata hai. Bachao: chhotay diffs propose karein, full rewrites kabhi nahin. Git mein shrinking rules file diff mein nazar ayegi. Relative dates bhi na rakhein; "kal Redis chuna" chhe haftay baad be-maani hai, is liye absolute dates likhein.
Kam history wala loop dream ke liye material nahin deta. Asal mileage wale loops par dream karein aur nateeja is se check karein: kaam karta sabaq aglay haftay logs mein woh failure dobara anay se rokta hai.
Yeh loop har doosray loop ko steer karne wale rules badalta hai. Aap ke tamam loops mein se yahi woh aakhri loop hai jo gate ke baghair chalna chahiye.
Anthropic managed version ko Managed Agents memory tooling mein ship karta hai. Product detail ke liye live docs dekhein; lasting layer woh shape hai jo aap ne khud banayi.
Aik loop ko jo us ne ab tak kiya woh kahan rakhna chahiye, aur conversation mein kyun nahin? Disk par, aik progress file (plus rules file) ya Linear jaisay board mein. Model ki memory runs ke darmiyan mit jati hai, is liye zinda rehne wali cheez model ke bahar rehti hai. Repo yaad rakhta hai; model nahin.Show answer
Part 5: Aik mukammal loop, do martaba
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
mainpar 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):
- Heartbeat: har weekday 9am par.
- Skill: aik
daily-triageskill steps rakhti hai, taake prompt aik line rahe. - Spine: shuru mein
progress.mdparhein, aakhir mein usay update karein. - Worktree: har fix apne checkout mein draft hota hai.
- Maker–checker: aik implementer draft karta hai; aik alag reviewer PASS ya FAIL kehta hai.
- Connector: PASS ke liye aik PR kholein; FAIL ya kisi risky cheez ke liye, usay "needs a human" mein likhein aur ruk jayein.
Mushtarka 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.
Reviewer (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 aik imaandaar baat: yeh sirf tool ke naam leti hai, Read aur Bash, is liye reviewer ko sirf test, lint aur diff commands tak mehdood nahin kar sakti. Filhaal numbered instructions yeh hadd sambhalti hain. Agla course, Harness Engineering, woh rule add karta hai jo ise laagoo karta hai. Reviewer jin checks ke khilaf grade karta hai un ka us ke prompt mein hona zaroori nahin. Verification-skills interlude dikhata hai ke har check ko apni skill kaise banaya jaye, taake reviewer aur /goal checker aik hi file ke khilaf grade karein.
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.
Schedule par loop shuru karna
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, Routines appendix mein bayan ki gayi 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-5 # 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.
Aik asal subah kaisi nazar aati hai
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.
Upar wali run animation mein fire hoti, kaam dhoondti, har fix draft karti, aur alag reviewer har aik ko PASS ya FAIL grade karta hai. Safe do PRs ke taur par ship hoti hain aur risky wali refuse hoti hai. Phir human gate aap ke paas aata hai. Sirf woh aik faisla aap karte hain jis ke liye insaan chahiye.
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.
Morning-triage loop mein, kya cheez aik ghalat fix ko aap ke sone ke dauran merge hone se rokti hai? 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 Show answer
main ke bajaye aik "needs a human" note bhejti hai. Har run capped aur logged bhi hai.
Part 6: Insani Control Qaim Rakhna
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.
Aapka loop teen feedback cycles mein se aik 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. Asal had token cost hai, keybind nahin
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. Claude Code mein beat ka effort bhi match karein:
/effort, ya headless run ke liyeCLAUDE_CODE_EFFORT_LEVEL. Routine triage ko aam tor par default kaafi hai; har scheduled beat par maximum effort mechanical chore par frontier model chalane jaisi ghalti hai. - 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.
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.
Spine correctness feature hai, lekin achhi memory doosra faida bhi deti hai. Agent doosri martaba kaam behtar karta hai kyunke pehli koshish ka lesson disk par hai. Behtar first attempts ka matlab kam retries aur kam tokens. Dreaming pass par aik martaba kharch hone wale tokens har mustaqbil beat mein wapas milte hain jo retry ke bajaye pehli koshish mein kaamyaab ho.
14. Kaam check karna ab bhi aapka kaam hai
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.
Ikhtiyari technical tafseel; pehli reading mein chhor sakte hain.
Aik loop ke liye sikhayi gayi teen cheezein kai loops ke saath organization ke masail ban jati hain.
Pehla, jab koi nahin dekh raha to failure ki math. Model steps reliable hain, yaqini nahin. Paanch steps mein har aik 95% durust ho to takreeban chaar mein se sirf teen runs saaf khatam hoti hain. Unattended loop ki ghaltiyan spine mein jama hoti hain. Aaj raat progress.md ki ghalat line kal ka ghalat starting point hai. Maker-checker split aik bure qadam ko mustaqil banne se rokta hai.
Doosra, sirf review nahin, loop ki salahiyat bhi mehdood karein. Reviewer diff grade karta hai, lekin yeh sabit nahin karta ke loop ne aur kuch nahin kiya. Har part ko standing permission samjhein: schedule sote hue act karne ki permission, connector asli system ka access, aur subagent borrowed identity. Har loop ko sirf us ke kaam ki cheezein dein. claude/ prefix, chhoti connector list, aur read-only checker isi aik usool ki misaalein hain.
Teesra, counting ka sawal. Jab paanch saathi loop copy karein, koi poochega: kitne loops chal rahe hain, har aik kya chhoo sakta hai, kis ki identity istemaal karta hai, aur kis ne approve kiya? Yeh ab loop engineering nahin, workforce management hai. Human-Agent Teams aur Digital FTE ka material yahan se aage barhta hai. Akela trust kamane wala loop bhi team mein apni jagah kamata hai.
Ikhtiyari technical tafseel; pehli reading mein chhor sakte hain.
Apne progress.md mein likhne wale aik loop ko yeh sab nahin chahiye. Lekin kai loops aik shared memory store parhein aur likhein to naye failures aate hain: do agents aik file aik saath likhte hain, aik agent organization-wide rules "theek" karta hai, aur January ka durust lesson June mein ghalat ho jata hai. Production fleets chaar guardrails istemaal karti hain:
- Versioning. Har tabdeeli record ho: kya badla, kis run ne karwaya, aur kis ne ki. Buri update rollback ho sake.
- Write se pehle conflict checks. Commit se pehle check karein ke drafting ke dauran file badli to nahin. Badli ho to dobara parh kar retry karein, overwrite nahin.
- Level ke mutabiq permissions. Agent apne scratch space mein likh sakta hai. Organization-wide rules aam agents ke liye read-only hon aur tabdeeliyan review se guzrein.
- Portability. Curated memory plain, open format aur saaf interface ke peeche rakhein taake product badalne par saath ja sake.
Mushtarka baat yeh hai ke fleet ki memory production data hai aur production discipline chahti hai. Stale-memory problem ko Concept 12 ka dreaming pass sweep karta hai.
In, on, ya out of the loop: Gate ke industry naam
Is course ka lafz "human gate" hai. Wasee duniya, yani AI safety papers, EU AI Act, bank compliance teams, aur enterprise procurement, isi khayal ke liye teen purane naam use karti hai. Inhein aik baar seekh lein. Buyer ya regulator yehi lafz use karega, aur yeh bil-kul us cheez se map hote hain jo aap pehle hi bana chuke hain.
| Term | Matlab | Is course mein misaal |
|---|---|---|
| Human in the loop | Har action se pehle insan approval deta hai. Zyada control, kam raftaar. | Turn-by-turn prompting, plan mode, merge gate, do-Routine gate (A4). |
| Human on the loop | System khud action leta hai; insan dekh kar mudakhlat kar sakta hai. | Routine claude/ branch push karti hai aur aap subah review karte hain. |
| Human out of the loop | Koi nahin dekh raha aur rokne ka raasta nahin. | Is course mein kahin nahin; yeh option nahin, failure mode hai. |
Table se teen baatein nikalti hain.
Pehli, Concept 1 ke mindset shift ka ab naam hai. Prompting mein insan in the loop hai: aap heartbeat, checker, aur memory hain, aur aap ki turn ke baghair kuch nahin hota. Loop engineering aapko on the loop rakhti hai: system chalta hai aur aap ki tawajjoh gate par hoti hai. Industry ki zaban mein yahi is course ka poora shift hai.
Doosri, acha loop in dono mein se sirf aik nahin. Yeh har action ke liye tay kiya gaya mix hai. Morning-triage loop safe fixes ke liye on-the-loop chalta hai aur risky cheez, yani reviewer ka FAIL, public-behavior change, aur khud merge, par wapas in-the-loop aata hai. claude/ branch rule bil-kul yehi hai: unattended kaam, magar main se pehle lazmi in-the-loop qadam. Concept 2 ki checker ladder batati hai ke mix kaise set ho: checker jitna kamzor ho, utne actions on-the-loop se wapas in-the-loop jayen. Passing test autonomy kamata hai. Rubric score nahin.
Teesri, "out of the loop" woh jagah hai jahan AI gravity khenchti hai. Koi jaan boojh kar out-of-the-loop system design nahin karta; yeh drift se hota hai. Diffs parhna chhor dein, green checkmarks par bharosa karein, weekly shipped-work review chhor dein, aur on-the-loop design bil-kul baghair tabdeeli ke khamoshi se out-of-the-loop ban jata hai. Dogfooding rule bachao hai: insaan ko wahan rakhein jahan ghalat automatic move mehnga aur reverse karna mushkil ho, aur check karte rahein ke insaan waqai ab bhi wahan hai. Concept 15 ki weekly aadat yehi check hai.
Regulated vertical mein Digital FTE bechte hue yeh sawal inhi alfaaz mein aayega: "Is this human in the loop or on the loop?" Ab aap action by action durust jawab de sakte hain aur gate dikha sakte hain.
In: insan har action approve karta hai. On: system action leta hai aur insan dekh kar rok sakta hai. Out: koi nahin dekh raha, jo writes ke liye qabool nahin. Is course ke loops default mein on-the-loop aur risky qadam par in-the-loop hain.
Dogfooding section ka What's New loop bil-kul baghair approval ship karta hai. Kya yeh human in the loop, on the loop, ya out of the loop hai, aur wahan yeh kyun qabool hai? On the loop. Har run ko koi approve nahin karta, lekin output public, logged, aik revert se theek hone wala hai, aur team transcripts parhti hai. Yeh sirf tab out of the loop banega jab koi bhi us ke publish kiye hue kaam ko kabhi na parhe. Dial ghalat move ki qeemat se set hota hai, aur bhondi changelog line reverse karna sasta hai.Jawab dekhein
15. Apna project samajhna band na karein
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.
Jab unattended loop fail ho
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>, auropencode session listaap 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.
Loops ke baad: Graph engineering
Yeh course aik dhaaga jaan boojh kar khula chhorta hai. July 18, 2026 ko Peter Steinberger, jis ki awaaz course ke shuru mein "aise loops design karein jo aapke agents ko prompt karein" kehti hai, ne aadhi raat ke baad barah lafzon ka sawal post kiya: "Are we still talking loops or did we shift to graphs yet?" Logon ne ise slogan bana diya, "loop engineering is dead, long live graph engineering", magar shor ke peeche asal sawal hai jo yeh course akela hal nahin kar sakta. Aik se zyada loops chalne par unhein wiring chahiye: kaun kis ko kaam deta hai, kaun kis ko check karta hai, shared memory kahan rehti hai, aur kaunsi measurements aisi hain jin se koi loop behas nahin kar sakta.
Is sawal ka apna poora course hai, is series mein do qadam aage: Graph Engineering, Harness Engineering ke baad. Yeh phrase ke dono hisse cover karta hai: shared memory graphs, yani work ka commit DAG aur facts ka knowledge graph, Karpathy ke autoresearch aur Anthropic ke Knowledge Graph Cookbook ke zariye; aur woh governance graph jo kai loops ko imandar rakhta hai, Carlos E. Perez ke single-loop ke chaar failures ke zariye, jin mein yeh bhi ke slogan ghalat kyun hai. Filhal sirf imandar version yaad rakhein: graph, composed loops hai. Loops hata dein to graph khaali boxes hai. Har stopping condition, checker, spine, aur gate jo aap ne yahan banaya, graph engineering assume karti hai ke aap use banana jante hain. Pehla loop bil-kul is course ke mutabiq banayein. Doosra banate hi graph course aap ka intezar kar raha hai.
Late July 2026 ki surat-e-haal. Naam reh sakta ya badal sakta hai; pattern mustaqil hai.
Is kitab mein in loops ka istemaal (dogfooding)
Ab tak shape pehchani ja chuki hai. Loop woh system hai jo kaam dhoondta, karta, apna nateeja check karta, jo kiya woh likhta, aur agla qadam tay karta hai; heartbeat usay shuru karti aur spine jor kar rakhti hai. Aap ne kagaz par aik loop do martaba banaya. Ab yeh kagaz se bahar aata hai.
Kisi tool se trust mangne se pehle insaf ka sawal hai: kya usay banane wale khud usay chalate hain? Software mein isay dogfooding kehte hain: apna product production mein waqai istemaal karna, sirf demo mein nahin. Is liye seedhi baat: do loops har roz is kitab ko chalate hain, aur wohi loops hain jo is course ne abhi sikhaye. Kitab apne saath bil-kul wohi karti hai jo aap ko apne saath karna sikha rahi hai. Dono mukhtalif stacks par chalte hain, yani Concept 3 asal zindagi mein: loop aik martaba seekhein aur tools ke darmiyan saath chalta hai.
Loop 1: Feedback loop, jo kitab ko durust rakhta hai.
Har lesson ke neeche feedback box, is lesson samet, loop ka front door hai.
- Heartbeat: do cloud Routines. Aik haftay mein chand baar naya feedback triage karti hai, aur doosri haftawar fixes draft karti hai.
- Spine: har reader note ka live database aur un se khulne wale GitHub issues. Har run parhta hai ke pichhle runs kya kar chuke hain, is liye aik hi note par do baar kaam nahin hota.
- Aik beat: naya feedback parhein aur sort karein. Is ka zyada hissa, yani ratings, shukriya, duplicates, aur pehle se handled cheezein, khud band ho jati hain, is liye kisi insaan ko chhoona nahin padta. Baqi tracked issues bante hain, aur chhoti, safe cheezon ke liye loop asal fix wala pull request draft karta hai.
- Human gate: sirf lazmi chand cheezein insaan tak pohanchti hain: blocked reader, contribution offer, ya asal content error. Har drafted fix ko ship hone se pehle insaan approve bhi karta hai. Har chhoti cheez baghair kisi shakhs ke handle aur close hoti hai. Insaan wahan aate hain jahan zaroorat ho, five-star rating close karne ke liye nahin.
- Is ne kya kiya: pehle runs mein is ne hazaron aise notes ka backlog saaf kiya jinhein parhne ka kisi insaan ke paas waqt nahin tha, aur sirf woh chand cheezein escalate keen jinhein waqai faisla chahiye tha.
Loop 2: What's New loop, jo readers ko khabar deta hai. What's New page jise aap abhi khol sakte hain, haath se nahin balki loop likhta hai.
- Heartbeat: roz aik martaba GitHub Actions schedule. Is ka worker Claude Code nahin balki OpenCode hai, yani is course ka sikhaya hua doosra tool.
- Spine: chhoti state file aakhri likhi hui tabdeeli yaad rakhti hai, is liye entry na dohrati hai na koi miss karti hai.
- Aik beat: pichhli martaba ke baad kitab mein badli har cheez dekhe, tay kare reader ko waqai kis baat ki parwah hogi, har aik ke liye aik saada jumla likhe, apne links check kare taake koi na toote, aur publish kare.
- Human gate: koi nahin. Live jane se pehle koi approve nahin karta.
Ab us aik jagah ko dekhein jahan dono loops mukhtalif hain, kyunke yahi is page ki sab se mufeed baat hai. Feedback loop kuch ship hone se pehle insaan ke liye rukta hai. What's New loop kisi ke liye nahin rukta. Faisla-kun sabab yeh nahin ke kaunsa loop zyada aham hai. Woh ghalat move ki qeemat hai. Lesson ka ghalat edit mehnga aur undo karna mushkil hai. Bhondi changelog line aik revert se theek hoti hai. Apne loops tak le jane wala asool mukhtasar hai: insaan ko wahan rakhein jahan ghalat automatic move mehnga aur reverse karna mushkil ho, aur baqi har jagah insaan ko bahar rakhein. Yeh Concept 1 ka intent aur accountability aap ke rehte hain wala sabaq hai, jo har loop ke liye alag set hone wala dial ban gaya. Part 6 ki industry zaban mein: mehngi jagah in-the-loop, baqi jagah on-the-loop.
Aur imandar baat, kyunke pichhle pages engineer rehne ke bare mein thay: donon loops ko akela nahin chhora jata. Hum run transcripts parhte hain, kyunke green run correct run nahin, Appendix A5. Person ab bhi decide karta hai ke kaunsi feedback fix deserve karti hai. Loops tireless middle sambhalte hain; dono siray hamare rehte hain. Yeh koi limitation nahin jis par maafi mangi ja rahi ho. Yehi design hai.
Ab aap production mein chalta hua finished loop bahar se dekh chuke hain. Neeche projects mein aap apna pehla banayenge.
🚀 Projects
Loops ke baare mein parhna aik banane jaisa nahin. Yeh rahe aath 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 minWatch loopLoop se lamba task dekhwayein aur khatam hote hi aap ko batwayein.
Mushkil: asaan · Istemaal: 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 minTests pass karayein, phir rokeinTab tak loop karein jab tak agent nahin, command faisla kare ke kaam ho gaya.
Mushkil: asaan se darmiyani · Istemaal: 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 minMemory wala subah ka briefScheduled loop jis ka doosra run wazeh taur par pehle par build kare.
Mushkil: darmiyani · Istemaal: Concept 6 (unattended schedule), Concept 12 (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 hrsAsal checker wala fix loopImplementer draft kare, alag reviewer grade kare, aur sirf PASS PR khole.
Mushkil: darmiyani se mushkil · Istemaal: 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 51-1.5 hrsBody ko codify kareinProject 4 ki orchestration ko aik dobara chalne wali unit bana kar sabit karein ke woh loop nahin.
Mushkil: darmiyani se mushkil · dynamic-workflows interlude, Concepts 8 aur 11.
Banayein. Project 4 ke fix loop ka body codify karein. Claude Code mein seedhi zaban mein workflow se teen issues parallel worktrees mein draft aur reviewer se grade karne ko kahein. Run durust ho to /workflows view se use /command ke taur par save karein. OpenCode mein wohi shell script banaayein: candidates par for loop, fan-out ke liye &/wait, aur reviewer ka exit code checker. Do martaba chalaayein.
Done jab aik command poora draft-and-review body chalaaye aur taza session mein sabit ho ke workflow pichhli run ki kuch memory nahin rakhta. Phir woh do cheezein naam dein jo use loop banaati hain: heartbeat aur agents ki likhi progress file.
Project 645-60 minDoorbell loopPull request par baghair prompt type kiye react karne wala loop.
Mushkil: darmiyani · Concept 7 aur Concept 10.
Banayein. Throwaway repo ko apni pull requests review karwaayein. OpenCode mein opencode github install chala kar generated workflow qubool karein. Claude Code mein GitHub pull-request trigger wali Routine banaayein; filters appendix mein hain. Phir aik planted bug ke saath PR kholein.
Done jab baghair maange PR review aaye aur planted bug pakre. Miss ho to prompt sakht kar ke dobara push karein; synchronize event loop ko phir fire karega.
Project 745-60 minJaan boojh kar toreinApne loop ko sabotage kar ke sirf spine se diagnosis karein.
Mushkil: darmiyani · Observability, Concepts 13 aur 14.
Banayein. Project 3 ka aik beat naap kar monthly cost nikalein. Phir prompt ko ghaayab file dein ya na-mumkin success condition dein, magar limit ke saath. Schedule par fail hone dein aur sirf log line aur progress.md se masla dhoondein.
Done jab spine se bata sakein kya aur kab fail hua, loop "needs a human" note chhore, aur current cadence ki monthly cost maloom ho.
Project 82-4 hrsAap ka apna daily loopAsli chore par poora chhe-hissay ka loop, aik hafta unattended: capstone.
Mushkil: capstone · Istemaal: tamam chhe 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.)
Appendix: Routines, shuru se aakhir tak
Is appendix mein product settings, limits, authentication, aur failure cases hain. Jab asal cloud Routine configure karni ho tab parhein. Loop engineering samajhne ke liye isay yaad karna zaroori nahin.
Main course Routine ko heartbeat ki aik qisam keh kar aage barhta hai. Yeh appendix field guide hai: form ka har field, teenon triggers, secrets kahan jate hain, aur woh failure modes jo logon ke asal ghante zaya karte hain. Yeh course ka sab se mechanical section hai. Routines research preview hain, is liye tabdeeli ki tawaqqo rakhein aur har ikhtilaf mein official page ko sahi samjhein. Isay apni pehli asal Routine banane se foran pehle parhein, us se pehle nahin.
Aik jumle ki orientation: Routine saved Claude Code configuration hai, yani prompt, aik ya zyada repositories, cloud environment, aur connectors ka set jo aik martaba package ho kar Anthropic ke servers par automatic chalta hai. Yeh Concept 6 ki heartbeat hai jo product ban gayi. Loop design aap dete hain; scheduler, machine, aur plumbing platform deta hai.
Skim karne walon ke liye poora appendix neeche aik table mein hai. Har row ko baad ke sections samjhate hain:
| Default / rawayya | Khatra | Hal |
|---|---|---|
| New-routine dialog mein "Local" | Desktop task ko Routine samajh lena | Remote cloud Routine hai; Local Desktop scheduled task hai (A1) |
| Tamam connectors shamil, writes allowed | Unattended agent har linked tool mein action le sakta hai | Ghair-zaroori connector hata dein (A2) |
.env gitignored hai | Cloud clone ko credentials nahin milte | Environment-variables panel mein secrets rakhein (A4) |
| Har run fresh clone aur environment | Loop pehla qadam dohrata rehta hai | Committed context/progress file ya external board (A4) |
| Schedule kam az kam 1 hour | Design 15-minute fire samajhta hai | API trigger aur apna scheduler (A3) |
| API token aik martaba; deduplication nahin | Token gum ya retry par duplicate runs | Token foran save karein; prompt repeat-safe ho (A3) |
| GitHub event cap ke baad events drop | Masroof loop khamoshi se kaam chhor deta hai | Nightly reconciliation sweep (A3) |
matches regex poora field check karta hai | hotfix lambe title se match nahin | .*hotfix.* ya contains (A3) |
| Runs aapki identity se, mid-run approval nahin | Bahar ka action baghair review ship hota hai | Do-Routine gate (A4) |
| Green status sirf infra success | Failed task successful nazar aata hai | Har run ka transcript parhein (A5) |
Mojooda run cap ka bharose-mand number claude.ai/settings/usage par hai; launch-time numbers ko permanent wada na samjhein.
A1. Local session cloud Routine nahin
Desktop app ka New routine button Remote ya Local ka intikhab deta hai, aur in naamon ne internet ke aadhe tutorials ko uljha rakha hai. Remote cloud Routine banata hai, jis ke bare mein yeh appendix hai. Local Desktop scheduled task banata hai: yeh mukhtalif feature aap ki machine par aap ki asal files, unsaved changes samet, sirf machine on hone ke dauraan chalta hai. Asal rule Concept 6 wala hai. Local files chahiye hon to Desktop task use karein. Laptop band hone ki guarantee, connectors, ya API aur GitHub triggers chahiye hon to cloud Routine. Acha pehla qadam yeh hai ke prompt ko Desktop task ya one-off run mein sabit karein, phir durust behavior dikhane par scheduled cloud Routine mein le jayen.
A2. Creation form, field by field
Routine claude.ai/code/routines par, Desktop app mein Routines → New routine → Remote se, ya CLI mein seedhi zaban ke /schedule se banayein. Teenon aik hi account mein likhte hain, aur aik jagah bani Routine doosri jaghon par nazar aati hai. CLI sirf schedule-triggered Routines banata hai; API aur GitHub triggers baad mein web par jore jate hain. /schedule list, /schedule update, aur /schedule run maujooda Routines manage karte hain.
Naam aur prompt. Prompt poori job description hai aur use self-contained hona chahiye. Routine poore autonomous cloud session ke taur par chalti hai, baghair permission prompts aur beech mein poochne ke liye kisi shakhs ke. Is liye Claude ko jo kuch chahiye, yani kya parhna hai, kya karna hai, success kaisi dikhti hai, aur kis cheez ko nahin chhoona, prompt ya run ko dastiyab files mein hona chahiye. Yahan course ka mashwara jama hota hai: prompt ko repo mein committed skill ki taraf point karein (Concept 9) aur Routine ka apna text chand lines rakhein. Prompt box mein model selector hai. Routine har run mein wohi model use karti hai, is liye use kaam se match karein (Concept 13).
Repositories. Har add ki gayi repo default branch se shuru hote hue har run par fresh clone hoti hai. Default mein Claude sirf un branches par push kar sakta hai jin ke naam claude/ se shuru hon. Permissions ke neeche Allow unrestricted branch pushes toggle har repository ke liye yeh had hata deta hai. Unrestricted pushes off rakhein jab tak unhein allow karne ki koi khaas, reviewed wajah na ho. Bure run mein unattended agent ka main par push karna bil-kul woh cheez hai jise human gate rokne ke liye bana hai.
Environment. Har Routine cloud environment mein chalti hai jo teen cheezein control karta hai: network access, environment variables, aur dependencies install karne wala setup script. Setup ka nateeja cache hota hai, is liye woh har session dobara nahin chalta. Default environment ka Trusted network access package registries, cloud-provider APIs, container registries, aur aam development domains ki fixed allowlist deta hai. Koi aur host 403 aur x-deny-reason: host_not_allowed ke saath fail hota hai. Agar Routine ko aap ki apni service chahiye to environment Custom karein aur default list ke saath sirf woh aik domain allow karein. Full access bhi hai, magar zyada tar loops ki zaroorat se zyada deta hai. Use ehtiyat se wasee karein.
Connectors. Yahan woh default hai jo har baar badalna chahiye. Aap ke tamam connected claude.ai connectors default mein shamil hote hain. Claude un par har tool, writes samet, baghair pooche use kar sakta hai. Save se pehle har woh connector hata dein jis ki job ko zaroorat nahin. Do aur tafseelein. Connector traffic Anthropic ke servers se guzarta hai, is liye connectors baghair network-allowlist tabdeeli ke kaam karte hain. Locally claude mcp add se jore hue MCP servers aap ki machine par rehte hain, account par nahin, is liye Routine ko nazar nahin aate. Ya unhein claude.ai/customize/connectors par connectors ke taur par add karein, ya committed .mcp.json mein declare karein taake clone ke saath safar karein.
A3. Teen triggers
Schedule. Presets hourly, daily, weekdays, ya weekly hain. Waqt aap ke local timezone mein darj hota hai aur aap ke liye convert kiya jata hai. Jaan boojh kar diye gaye waqfe ki wajah se runs ghante ke kuch minute baad shuru ho sakte hain; kisi ek Routine ke liye yeh offset har baar wohi rehta hai. Aik ghanta kam az kam waqfa hai, aur is se zyada jaldi fire hone wali cron expressions rad kar di jati hain. Agar zyada frequency chahiye to API trigger ke saath apna scheduler laayein. Custom intervals, jaise har do ghante ya mahine ki pehli tareekh, ke liye qareeb tareen preset chunein aur phir CLI mein cron expression ke saath /schedule update chalayein. One-off schedule muqarrar waqt par aik baar fire ho kar khud band ho jata hai. One-off scheduled runs daily Routine cap mein count nahin hote, is liye prompt ko schedule par mustaqil karne se pehle rehearse karne ka sasta tareeqa hain. CLI unhein seedhi zaban mein leta hai: /schedule tomorrow at 9am, summarize yesterday's merged PRs.
API. API trigger Routine ko us ka apna /fire endpoint aur bearer token deta hai. Token generate karte waqt sirf aik baar dikhaya jata hai aur baad mein dobara hasil nahin kiya ja sakta, is liye foran apne alerting tool ke secret store mein rakhein. Usi window se aap use Regenerate ya Revoke kar sakte hain. Ab koi bhi system jo authenticated POST bhej sakta ho Routine ko fire kar sakta hai: alerting webhook, deploy pipeline, form handler, ya aap ki apni machine ka cron job. Request body optional text field leti hai jo run ke liye khaas context, jaise alert body ya failing log, deta hai. Yeh saved prompt ke saath Routine ko freeform, baghair parse kiya hua text ban kar milta hai. Response naye session ki ID aur URL deta hai, taake caller seedha run se link kar sake.
curl -X POST https://api.anthropic.com/v1/claude_code/routines/<routine-id>/fire \
-H "Authorization: Bearer <routine-token>" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'
Dated beta header lazmi hai aur preview ke badalne ke saath yeh bhi badlega. Docs wada karte hain ke do sab se haaliya pichhle versions chalte rahenge, taake callers ko migrate karne ka waqt mile.
/fire endpoint mein built-in deduplication nahin, aur webhook senders default mein retry karte hain. Is liye dobara bheja gaya alert duplicate run hai, aur ghalat configure hua alert jo saari raat retry kare woh aisa loop hai jo aap ne kabhi design nahin kiya. Maali pehlu nazar aane se zyada sakht hai. API-triggered runs daily Routine allowance mein count hote hain, is liye retry storm aap ke jaagne se pehle poore din ka cap istemaal kar sakta hai. Agar metered extra usage on ho to cap hadd nahin rehta, bill ban jata hai. Concept 13 ka asool sirf loops par nahin, triggers par bhi laagu hota hai. Sender par deduplicate ya rate-limit karein. Prompt ko bhi dobara chalne ke liye mehfooz likhein, masalan draft karne se pehle check kare ke fix branch pehle se maujood to nahin. Yehi baat Concept 10 ke connector rules ne sikhayi thi.
GitHub events. GitHub trigger connected repo par matching event aane par fresh session shuru karta hai. Do event qismein supported hain: pull request (opened, closed, labeled, synchronized waghera) aur release. Har qism kisi khaas action ya tamam actions par fire ho sakti hai. Repository par Claude GitHub App install hona zaroori hai. Yaad rakhein ke /web-setup clone access deta hai magar app install nahin karta, aur yeh farq bohat se pehle attempts ko uljha chuka hai. Filters tai karte hain ke kaunsi PRs Routine fire karein: author, title, body, base branch, head branch, labels, draft state, aur merged state. Operators mein contains, is one of, aur matches regex shamil hain. Aham baat: matches regex poore field ko test karta hai, us ke kisi hissay ko nahin. Is liye hotfix sirf aise title se match hota hai jo bil-kul hotfix ho. .*hotfix.* likhein, ya bas contains istemaal karein. Loop design ke liye do aur haqeeqatein aham hain. Pehli, preview ke dauraan GitHub events par per-Routine aur per-account hourly caps hain, aur cap ke baad events drop ho jate hain jab tak window reset na ho. Woh queue nahin hote. Is liye zyada events wale design ko reconciliation sweep chahiye: nightly scheduled run jo miss hue events pakar le. Doosri, har matching event apna alag session shuru karta hai. Aik PR par do pushes do sessions hain jo aik doosre ke bare mein kuch nahin jaante. Yeh GitHub ki surat mein Concept 12 ka spine lesson hai.
A4. Secrets, state, aur identity
Secrets environment-variables panel mein jate hain, kabhi .env file mein nahin. Wajah mechanical hai: .env gitignored hoti hai, gitignored files kabhi GitHub tak nahin jatin, is liye cloud clone mein woh hoti hi nahin. Routine fire hoti hai, use kuch nahin milta, aur woh fail hoti hai, ya is se bhi badtar, apni taraf se koi raasta nikaalti hai. Har key environment ke variables panel mein rakhein aur prompt mein aik wazeh line add karein: "credentials environment variables ke taur par dastiyab hain; .env file na dhoondein". Is line ke baghair Claude aadatan ab bhi .env ka raasta azma sakta hai.
Har run zero se shuru hota hai. Fresh clone, fresh environment, koi working tree nahin, koi cookies nahin, koi bachi hui cheez nahin. Routine ko jo bhi yaad rakhna ho use run khatam hone se pehle machine se bahar jana chahiye: repo mein push ho, connector ke zariye external system mein likha jaye, ya board ki API se bheja jaye. Yeh koi limitation nahin jis ka chakkar kaatna ho. Yeh Concept 12 ka spine rule hai, jo infrastructure laagu karta hai. Is ka mutabiq pattern naam dene ke qabil hai: repo mein context files. Repository mein committed clients.txt, progress.md, ya triage-rules.md har run par parhi ja sakti hai aur prompt ko chhuye baghair update hoti hai. Client list badle to aap file edit karte hain; Routine ka text apni jagah rehta hai.
Routines aap ke taur par kaam karti hain. Woh aap ke individual account se talluq rakhti hain, aap ke daily allowance mein count hoti hain, aur un ka har kaam, yani commits, PRs, Slack posts, Linear tickets, aur drafted emails, aap ki identity rakhta hai. Aik Routine jo clients ko jawab deti hai aap ki chhutti ke dauraan bhi aap hi ke taur par jawab deti rehti hai. Kisi bhi bahar nazar aane wale kaam ko schedule karne se pehle identity ke is pehlu par ghour karein.
Mid-run approval nahin hoti. Routine apna prompt shuru se aakhir tak chalati hai; woh ruk kar aap se pooch nahin sakti. Is liye jab kisi faisle ko waqai insaan chahiye, jaise payment, bahar bheji jane wali email, ya deploy, gate aik Routine ke andar nahin balki do Routines ke darmiyan banayein. Yeh teen qadmon mein kaam karta hai. Routine A kaam draft karke aisi jagah post karti hai jahan aap review kar sakein: claude/ branch, Slack message, ya draft email. Insaan use parh kar approve karta hai. Approval API trigger ke zariye Routine B ko fire karta hai, aur Routine B action leti hai. Yeh Part 5 ka human gate hai jo do Routines aur webhook ki surat mein likha gaya hai.
A5. Runs ko parhna
Har run Routine ke detail page par poora session ban kar nazar aata hai. Transcript har tool call, faisla, aur tabdeeli dikhata hai, aur aap guftagu ko haath se jari rakh sakte hain ya natije ko PR bana sakte hain. Docs ki wazeh warning, jis ki tajurba bhi tasdeeq karta hai: green status ka matlab session infrastructure error ke baghair khatam hua. Is ka matlab yeh nahin ke aap ka task kamyab hua. Blocked network requests, missing connector tools, aur seedhi task failures sab transcript mein hoti hain, status column mein nahin. Run khol kar parhein. Scheduler managed hone ke bawajood Concept 14 laagu hota hai.
Seedhi baat: green ka matlab platform ne session mukammal kiya. Yeh is baat ka saboot nahin ke manga gaya kaam kamyab hua.
Run now testing ke liye foran run shuru karta hai. Repeats section ka pause toggle configuration mitaye baghair schedule rok deta hai. Cost ke hawale se runs aap ki subscription usage se bhi nikalte hain aur daily Routine cap mein bhi count hote hain. Cap ke baad, agar aap ne extra usage on ki ho to metered rates par bill hota hai. Dono claude.ai/settings/usage par nazar aate hain. Agar /schedule CLI se gayab lage to aam wajah API-key ya cloud-provider authentication hoti hai, kyunke is ke liye claude.ai login chahiye; doosri wajah telemetry band karne wali environment variables ya purani CLI hain. Web UI har surat kaam karti hai.
Oopar ki har row ka GitHub Actions mein barabar maujood hai, kyunke OpenCode approach ne yeh masail pehle hi seedhe parts se hal kar diye the. Environment-variables panel ki jagah repository secrets (secrets.ANTHROPIC_API_KEY) hain. Connector list committed opencode.json ka mcp section hai. Schedule aur PR triggers on: schedule aur on: pull_request hain. Statelessness wohi hai, kyunke CI runners bhi har run mein fresh hote hain, is liye committed-context-file pattern baghair tabdeeli ke kaam karta hai. Identity ka jawab personal account ke bajaye GitHub App ya bot token deta hai. Branch guardrail woh branch protection rules hain jo aap khud set karte hain. Naam aur configuration mukhtalif hain, lekin bunyadi masail wohi. Yehi course ka markazi dalil hai.
A6. Checklist ka Routine version
Minimum safe loop checklist seedhi transfer hoti hai.
Success condition aur limit prompt mein rehte hain, kyunke platform din bhar ke runs ko cap karta hai, aik run ke nuqsan ko nahin. Isolation claude/ branch prefix hai, is liye use on rehne dein. Read-only checker cloned repo mein defined reviewer subagent hai. State file committed context file hai, kyunke clone har baar fresh hota hai. Human gate oopar wala do-Routine pattern hai, ya seedha asool: "sirf draft PRs, kabhi merge nahin." Log run transcript ke saath aisi jagah connector post hai jise aap waqai dekhte hain, aur yaad rahe green ka matlab done nahin.
Har baar yeh list aik minute mein check karein. Isi se farq padta hai ke aap ne sirf appendix parha hai ya aisa loop banaya hai jis par bharosa kiya ja sakta hai:
- Repositories: sirf sahi repo; unrestricted pushes off.
- Prompt: self-contained; success condition aur limit shamil.
- Connectors: ghair-zaroori sab remove.
- Environment: secrets panel mein,
.envmein nahin; network kam se kam. - Trigger: jaan boojh kar chuna, high-frequency ghalti nahin, retry-safe.
- State: pehle run se pehle context/progress file ya board.
- Human gate: direct merge, deploy, payment, ya client send nahin.
- Test run: one-off ya Run now, phir status rang nahin balki transcript parhein.
Mashq: Routine ke teen drills
Field guide parhna form mein khud click karne jaisa nahin. Yeh teen drills throwaway repository mein appendix ke sab se aham failures jaan boojh kar dobara paida karte hain, taake cost aur risk kam hon. Inhein daily run cap ko zehan mein rakh kar banaya gaya hai. Pehla drill one-off runs use karta hai jo cap mein bil-kul count nahin hote. Doosre do mila kar takreeban paanch runs lete hain, yani Pro cap ka aik din. Main projects ke do rules ab bhi lagu hain: throwaway repo use karein aur pehle limits lagayein.
Is section ke aakhir mein Project 12 drill nahin. Woh Projects 3 ya 8 par build karne wala doosra capstone hai aur weekly chalta hai, is liye us ki runs alag plan karein. Mushkil: asaan · Istemaal: A1, A3 (one-off schedules), A5 (runs parhna). Banayein. Throwaway repo mein aisi Routine banayein jis ka prompt aik chhota, checkable kaam kare, misaal ke taur par kal ke commits ka khulasa Done jab aap do green runs dekh chuke hon: aik jis ka transcript success dikhaye, aur aik jis ka transcript failure dikhaye. Aik jumle mein bata sakein ke status column donon mein farq kyun nahin bata saka. A5 ka sabaq: green ka matlab session infrastructure error ke baghair khatam hua, aur kuch nahin. Mushkil: asaan se darmiyani · Istemaal: A4 (secrets), A2 (environment). Banayein. Aisa prompt likhein jisay aik secret chahiye. Dummy token kaafi hai, kyunke drill is bare mein hai ke value kahan rehti hai, na ke kya unlock karti hai. Pehli run mein token gitignored Done jab doosri run environment se token parh le aur aap pehli run ki mechanical wajah samjha sakein: gitignored files GitHub tak nahin jatin, is liye fresh cloud clone mein kabhi nahin hotin. Mushkil: darmiyani se mushkil · Istemaal: A3 (API trigger), A4 (gate), A6 (checklist). Banayein. Routine A one-off schedule par koi reviewable cheez draft kare: Done jab teen baatein sach hon: B sirf aapke fire karne se chala; B ka transcript sabit kare ke action waqai hua; aur donon Routines par A6 checklist chali ho, connectors pruned, unrestricted pushes off, aur state file selected. Yeh Part 5 ka human gate hai jo ab aap ne asal parts se banaya. Mushkil: capstone · Istemaal: Concept 12 (spine aur improvement loop), Concept 11 (maker-checker), Concept 6 (schedule), Part 5 (human gate). Banayein. Aapko aisa loop chahiye jo aik hafta chal chuka ho aur Done jab teen baatein sach hon. PR ka proposed change plausible guess ke bajaye asal cited log entries se trace hota ho. Logs mein haath se dali hui repeated failure pakri ja kar proposal bane. Aur aapke merge ke baghair rules file mein kuch na badle. Evidence ke baghair changes aayen to prompt tight karein: guess karne wala improvement loop no improvement loop se badtar hai, kyunke us ke guesses har future run ko steer karte hain.Project 920-30 minRoutine muft rehearse kareinRepeating schedule se pehle one-off runs mein prompt sabit karein.
claude/summary branch par likhe. Ise repeating schedule par na rakhein. One-off run, /schedule tomorrow at 9am, … ya Run now, se fire karein aur status column ke bajaye poora transcript parhein. Phir prompt badlein taake task zaroor fail ho, yani us se aisi file parhwayein jo maujood nahin, aur aik baar phir fire karein.Project 1030-45 minSecrets drill.env wali failure jaan boojh kar aik martaba dekhein.
.env file mein rakhein aur Routine fire karein. Use value na milte dekhein aur transcript parh kar dekhein ke Claude ne badle mein kya koshish ki. Doosri run mein token environment-variables panel mein le jayen aur appendix ki recommended line prompt mein add karein: "credentials environment variables mein dastiyab hain; .env file na dhoondein."Project 111-2 hrsDo-Routine gate banayeinA draft karti hai, aap faisla karte hain, aur sirf approval B ko fire karta hai.
claude/ branch ya connector ke zariye chhota summary. Routine B ka API trigger ho aur woh aik chhota follow-up action kare. B ka bearer token dikhte hi save karein, kyunke sirf aik baar dikhaya jata hai. A ka draft khud review karein. Phir A3 wali curl call se B fire kar ke approve karein.Project 122-3 hrsDreaming loop banayeinWeekly loop jo logs parh kar rule change PR mein propose kare.
progress.md mein dated entries chhor chuka ho; Project 3 ya 8 deta hai. Ab us par doosra loop banayein. Weekly schedule par woh apni dreaming-state.md ki date ke baad ke tamam log entries parhe, aisi failure ya correction dhoonde jo aik se zyada baar aayi, aur sab se chhota rules-file ya skill change claude/ branch par PR mein draft kare, direct commit kabhi nahin. PR description evidence cite kare: kaunsi runs, kitni baar, aur yeh line failure ko kyun rokegi. Aik deletion bhi propose kare, yani woh rule jis ki kisi recent run ko zaroorat nahin pari. Aakhir mein dreaming-state.md update kare.
Ab kahan jayein
- Aik se zyada loops chala rahe hain? Jis lamhe do loops kaam exchange ya state share karte hain, wiring aur shared memory chahiye hoti hai. Is series mein do qadam aage Graph Engineering dono cover karta hai.
- Non-coding kaam ke liye loops bana rahe hain? Cowork aur OpenWork crash course professionals ke liye wahi heartbeat idea dikhata hai, cron ke bajaye scheduled tasks ke saath.
- Terminal ke bajaye API se loops chala rahe hain? Claude Platform ke Managed Agents ab scheduled deployments support karte hain, public beta mein. Agent ko cron schedule dein; har firing Anthropic ki infrastructure par fresh session shuru karti hai, baghair is ke ke aap scheduler banayein ya host karein. Yeh Routines ka idea platform primitive ke taur par hai aur shape wahi hai. Schedule heartbeat hai, prompt beat hai, aur spine ab bhi aap dete hain.
- Improvement loop aap ke liye managed chahiye? Usi Managed Agents platform mein memory aur dreaming tooling shamil hai, yani Concept 12 ke note wala out-of-band improvement pass product ke taur par. Shape nahin badalti: batch job heartbeat, memory store spine, aur approval step human gate hai.
- Checker bhi managed chahiye? Do research previews verification-skills interlude ko products mein badalti hain. Code Review enabled repos ki har PR par managed multi-agent review pass chalata hai, yani home four as a service. Rubrics in Claude Managed Agents, beta, Concept 2 ka rubric-with-a-bar platform primitive banata hai: alag grader agent outcomes verify karta aur failed work dobara attempt ke liye bhejta hai. Model ke grade par kitna bharosa karna hai, yeh Trusting the Checker course sikhata hai.
- Unattended runs ke retries tune kar rahe hain? Claude Code ka Error reference automatic-retry settings document karta hai, jin mein
CLAUDE_CODE_MAX_RETRIESaur CI-style unattended sessions ke liyeCLAUDE_CODE_RETRY_WATCHDOGmode shamil hain. - Clone-and-run starting points chahiye? Community repo cobusgreyling/loop-engineering, MIT license ke saath, production loop patterns ko readiness checklist wale starter kits mein jama karta hai: daily triage, PR monitor, CI checker, dependency checker, aur changelog drafter, kai agent CLIs ke liye mapped. Yeh third-party aur naya hai, is liye maintenance check karein. Lekin is ki primitives table doosre naamon mein isi course ke chhe parts hai, jo aik mufeed doosri tashreeh banti hai. Reading trail ke liye Hugging Face par community-curated awesome-loop-engineering primary articles aik jagah jama karta hai.
- Jo spec aap ne Spec-Driven Development mein likhi wahi loop ki stopping condition hai: acceptance criteria ke khilaf checker grade karta aur
/goalrukne se pehle sabit karta hai. Jab loop ko chalta chhorna ghair mehfooz lage, fix takreeban hamesha zyada wazeh spec hoti hai, zyada automation nahin.
Sources aur mazeed mutala
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/
- Avi Chawla, Loop Engineering, Clearly Explained — inner-loop anatomy, chaar nested engineering layers, doom-loop framing, aur loops ke tool-design rules. https://www.dailydoseofds.com/p/loop-engineering-clearly-explained/
- Data Science Dojo, The 4 Layers of AI Engineering — har layer ka aik failure mode aur "kaunsi layer ab bhi haath se kar rahe hain" self-check. https://www.facebook.com/share/p/1HCxfwo5aC/
- Rakesh Gohel, How to Actually Use Fable 5 — self-learning aur self-improving ka farq, aur prompt-harder-and-start-over ke muqablay mein run, log, distill, repeat. https://rakeshgohel.substack.com
- Sydney Runkle, LangChain, The Art of Loop Engineering — four-loop stack, trace-driven improvement loop, aur swyx ke "loopcraft" framing ka pointer. https://www.langchain.com/blog/the-art-of-loop-engineering
- Lamis, Anthropic Applied AI, Context Engineering: Memory and Dreaming — in-band aur out-of-band memory, dreaming consolidation, shared memory stores ke production guardrails, aur school/head-teacher analogy. https://www.youtube.com/watch?v=tQ41RxfZZVg
- Letta, Charles Packer, Sarah Wooders aur saathi, Sleep-time Compute — dreaming idea ka pehla productized version aur yeh caveat ke offline consolidation tab faida deta hai jab mustaqbil ke tasks maazi se milte hon. https://www.letta.com/blog/sleep-time-compute/
- Stanford, SambaNova, aur UC Berkeley, Agentic Context Engineering (ACE) — repeated memory rewriting ke do failure modes, brevity bias aur context collapse, aur monolithic rewrites ke bajaye incremental delta updates. https://arxiv.org/abs/2510.04618
- OWASP, Top 10 for Agentic Applications (2026) — Memory and Context Poisoning ko alag agentic threat ke taur par define karta hai, jahan injected content memory mein reh kar asal attack ke baad bhi behavior badalta hai.
- Simon Willison, Designing agentic loops — term se pehle ka saaf bayan ke skill agent chalana nahin, loop design karna hai. https://simonwillison.net/
- TrueFoundry, Loop Engineering at Enterprise Grade — failure-stacking math, loop parts ko standing permissions samajhna, aur team-scale inventory problem. https://www.truefoundry.com/blog/loop-engineering-enterprise-agent-runtime
- 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 CNBC interview se hai, jaisa Business Insider ne report kiya. Peter Steinberger ki "design loops that prompt your agents" line X par un ki post se hai.
- Andrew Ng — teen product-development loops, coding minutes mein, developer feedback hours mein, external feedback days mein, aur "taste" ko insaan ke context advantage ke taur par dobara frame karna. https://x.com/AndrewYNg/status/2071988145667928442
- Andrej Karpathy — "usay na batayein kya karna hai, success criteria dein aur chalte dekhein," aur AutoResearch project, jo training script badalta, result naapta, aur kaam karne wali tabdeeli rakhta hai.
Claude Code (official docs)
- Routines — cloud scheduled automations, triggers, run caps, aur per-plan daily limits wala launch announcement: https://code.claude.com/docs/en/routines aur https://claude.com/blog/introducing-routines-in-claude-code
- Channels — chalti hui session mein event-driven input: https://code.claude.com/docs/en/channels
- Scheduled tasks —
/loop, cron tools, Desktop tasks, aur background-session carryover rule: https://code.claude.com/docs/en/scheduled-tasks - Changelog — background sessions, retry watchdog,
ultracoderename, aur chapter ki doosri mechanical details sab se pehle yahan supersede hoti hain: https://code.claude.com/docs/en/changelog - Memory —
CLAUDE.md, auto memory, aur Auto Dream research preview ke peeche consolidation pass: https://code.claude.com/docs/en/memory - Delba de Oliveira, Anthropic Claude Code team, Building verification loops in Claude Code with skills — verification-skills interlude ka source: checks as skills, chaar deployment homes, graduation signals, wrapper-skill pattern, Anthropic ki
/code-review→/simplify→/verify→/designchain, aur/verify, Code Review, aur Managed Agents Rubrics ke pointers. https://claude.com/blog/building-verification-loops-in-claude-code-with-skills - Code Review aur Managed Agents Rubrics likhte waqt research preview ya beta hain. Availability ya behavior par bharosa karne se pehle live docs dekhein.
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 aur issue triggers, aur
opencode github install: https://opencode.ai/docs/github/
Model identifiers
- Anthropic, What's new in Claude Sonnet 5 —
claude-sonnet-5model string, Sonnet 4.6 se direct migration, adaptive-thinking default, aur naya tokenizer. https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5 - Anthropic, Model IDs and versioning — 4.6 generation se dateless IDs pinned snapshot hain, Sonnet 5 jaisi major releases minor segment chhorti hain, aur Haiku 4.5 jaise 4.5-generation models dated canonical ID
claude-haiku-4-5-20251001ke saath dateless alias bhi rakhte hain. https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions - Anthropic, Introducing Claude Fable 5 and Mythos 5 — Opus se upar flagship generation jo mid-2026 mein ship hui, aur yaad-dihani ke chapter ke model examples illustration hain, frontier nahin. https://www.anthropic.com/news/claude-fable-5-mythos-5
Saare links early July 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.
Aik line ka khulasa
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.