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.
2026 ke darmiyan mein, jo log yeh tools banate hain unhon ne saaf kaha. Boris Cherny, jis ne Claude Code banaya, us ne yun kaha: "Main ab Claude ko prompt nahin karta. Mere paas loops chal rahe hain jo Claude ko prompt karte hain... mera kaam loops likhna hai." Peter Steinberger (OpenClaw) ne kaha "aap ko aise loops design karne chahiye jo aap ke agents ko prompt karein." Phir Addy Osmani ne is pattern ko naam diya aur is ki parts ginwayin. In mein se koi nahin kehta ke kaam asaan ho gaya. Woh kehte hain ke qeemti skill apni jagah badal gayi. Yahi woh idea hai jis par yeh poora course bana hai. (Is course ki har quote aur claim ki source aakhir mein Sources & further reading mein hai.)
The mindset shift, in one picture
Yeh course do tools ko saath saath cover karta hai, usi wajah se jis wajah se pichla: agar koi technique dono mein chalti hai, to woh aik asli skill hai, aik tool ka trick nahin. Lekin yahan dono tools waqai farq rakhte hain, aur woh farq khud aik sabaq hai. Claude Code ab loop ki parts product ke andar ship karta hai. OpenCode aap ko neeche wali layer deta hai — aik worker jise aap operating system se shuru karte hain. Aap dono dekhein ge. Aap yeh bhi dekhein ge ke loop ki shape wohi hai, chahe wiring na ho.
June 2026 tak current. Dono tools tezi se badalte hain, aur Claude Code ki kaeyi loop features research preview mein hain. Kisi bhi session se pehle,
claude updateyaopencode upgradechalayein. Kisi limit ya flag par bharosa karne se pehle live docs (code.claude.com/docs, opencode.ai/docs) dekhein.
Aik asli loop un-attended hota hai: woh khud ko, apne aap, tab prompt karta hai jab aap door hote hain. Yeh sada claude.ai chat box mein nahin ho sakta, jo hamesha aap ka intezaar karta hai — chat mein, aap hi schedule hain. Aik sachcha loop chalane ke liye aap ko aik aisa tool chahiye jo timer par khud act kar sake: Claude Code, OpenCode, ya Cowork (Cowork crash course dekhein). In mein se zyada tar paid features hain, aur kaeyi aaj research previews hain. Aap aik loop ko kahin bhi seekh aur design kar sakte hain. Usay un-attended chalane ke liye, aap ko in tools mein se aik chahiye. Yeh course do coding wale dikhata hai. Wajib sawaal hai, kyunke "claude.ai" dar-asal do cheezein hai. Chhota jawab: chat box loop nahin chala sakta, lekin Claude Code — jo usi claude.ai account mein rehta hai — chala sakta hai. To chat woh jagah hai jahan aap aik loop ko design aur rehearse karte hain — skill draft karein, reviewer prompt likhein, stopping condition pin karein, aik beat haath se chalayein — aur Claude Code ya OpenCode woh jagah hai jahan aap usay chalate hain. Woh hand-off Spec-Driven Development ke baad qudrati agla qadam hai."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) Anthropic ke servers par chalti hain chahe aap ka laptop band ho, baghair kuch local install kiye — to is maani mein aap "claude.ai se" aik asli, un-attended loop khara kar sakte hain. Is ke liye paid plan chahiye aur yeh aaj research preview hai.
Yahan se aage, takreeban har concept aisa hai jise aap aik asli session mein chala sakte hain, sirf parhne ke liye nahin. Is page ke saath aik terminal khula rakhein (claude ya opencode) aur har idea jab aap us tak pohanchein use try karein. Aik chhote, throwaway git repo se shuru karein taake koi loop us cheez ko nuqsaan na pohancha sake jis ki aap ko parwah hai.
What this course covers
| Part | Topic | Aap kya seekhte hain |
|---|---|---|
| 1 | The Shift | Aik loop kya hai, is ki chhe parts, aur usay banane ke do raaste |
| 2 | The Heartbeat | Kisi cheez ko khud se chalana: in-session, run-until-done, scheduled, event-driven |
| 3 | The Body | Isolation, knowledge, action, aur maker–checker split |
| 4 | The Spine | Woh state jo runs ke darmiyan zinda rehti hai — wohi hissa jise log bhool jate hain |
| 5 | A Loop, Twice | Aik poora morning-triage-to-PR loop, asli files ke saath, dono tools mein bana |
| 6 | Staying the Engineer | Token cost, kaam ka check, aur woh traps jo loops behtar hone ke saath barhte hain |
| Practice | Practice projects | Paanch loops, asaan se mushkil, jo aap khud banate hain |
Karte hue seekhna chahte hain? Pehle Part 5 parhein taake aik poora loop shuru se aakhir tak dekhein, phir parts ke liye wapas aayein. Jab concepts samajh aa jayein, to Practice projects aap ko khud banane ke liye paanch loops dete hain.
Is poore ko parhne ke liye takreeban do ghante rakhein. Part 5 aur practice projects banane mein zyada waqt lagta hai — yahi point hai: aap loops bana rahe hain, un par sarsari nazar nahin daal rahe.
Is course mein do layers chalti hain, aur woh bahut alag tareeqe se purani hoti hain. Pehli ko internalize karein; doosri ko look up karein.
- Durable layer. Aik loop ki shape (aik heartbeat, chaar working parts, aur aik spine), maker–checker split, aur do siray jo aik loop kabhi automate nahin kar sakta: intent (itni theek se yeh kehna ke aap kya chahte hain ke result check ho sake) aur accountability (jo ship hota hai us ka zimma lena). Yeh skill hai. Yeh neeche di gayi har command badal jane ke baad bhi sach rehti hai.
- Mechanical layer. Har flag, path, model ID, aur command name. Yeh tools weekly updates ship karte hain aur yahan kaeyi features research previews hain, to har specific command ko aik fact yaad karne ke bajaye live docs ki taraf aik pointer samjhein. Jahan yeh course aur current docs ikhtelaf karein, docs jeetti hain.
Chhe-hisson wali shape yaad rakhein aur har keystroke bhool jayein, to aap ne loop engineering seekh li. Keystrokes yaad kar lein aur shape miss kar dein, to aap ne is mahine ki CLI seekhi.
📚 Teaching Aid
View Full Presentation — Loop Engineering: Aik Crash Course
Part 1: The Shift
1. From prompting to looping
Takreeban do saal tak, aik coding agent se kaam lene ka tareeqa sada tha. Aik achha prompt likhein. Usay kaafi context dein. Jo wapas aaye usay parhein. Agli cheez type karein. Agent aik tool tha, aur aap usay aik waqt mein aik turn istemaal karte thay.
Aik loop aap, operator, ki jagah aik system le aata hai. Yeh system kaam dhoondta hai, usay baant-ta hai, check karta hai, jo us ne kiya us ko likhta hai, aur decide karta hai ke agla kya hai. Yeh agent ko prompt karta hai, taake aap ko na karna pare.
To value kahan jati hai? Khatam nahin hoti. Yeh do siron par bant jati hai jo aik loop automate nahin kar sakta: intent — theek theek yeh kehna ke aap kya chahte hain, itni saaf ke result check ho sake — aur accountability — jo bahar aata hai us ke peechhe khare rehna. Loop darmiyan ko, steps ko, automate karta hai; siray aap ke rehte hain. Aap intent aur judgment ke liye paid hote hain, is ke liye nahin ke kaam kaise bana us se ankhein chura lein.
Farq "aik bara prompt" nahin hai. Yeh kaam ki aik alag shape hai:
| Prompting (jo aap jaante hain) | Looping (jo yeh course add karta hai) |
|---|---|
| Aap har turn shuru karte hain | Aik schedule ya aik event har turn shuru karta hai |
| Aap output parh kar decide karte hain ke aage kya | Aik checker output check karta hai; loop decide karta hai ke aage kya |
| Jis lamhe aap type karna roken, ruk jata hai | Jab tak aap sote hain chalta rehta hai |
| Aik task, aik session, aap ki poori tawajjuh | Bahut si chhoti runs, zyada tar un-attended, aap ki tawajjuh sirf gate par |
Yeh jaadu nahin hai, aur yeh "set it and forget it" bhi nahin. Aik loop jo khud se chalta hai woh aik loop bhi hai jo khud se ghaltiyan karta hai. Is course mein har cheez is liye hai ke aik aisa loop bane jise aap waqai bharosa kar sakein ke woh aap ke baghair chal sakta hai. Yeh prompting se mushkil hai, asaan nahin. Inaam leverage hai: aik achha loop aap ke liye baar baar kaam karta hai, woh kaam jo warna aap ko har baar haath se shuru karna parta.
2. What a loop is made of
Aik loop jo waqai khud se chalta hai us ki paanch parts aur aik spine hoti hai. Aap paanch mein se chaar agentic coding course mein mil chuke hain. Yahan woh aik naya kaam le lete hain.
- Heartbeat — aik schedule (ya aik event) jo loop shuru karta hai. Is ke baghair, aap ke paas aik single run hai, loop nahin.
- 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 kholна, 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.
3. Two roads: ships-the-parts vs the-layer-below
Yeh woh aik jagah hai jahan tools waqai farq rakhte hain, aur yeh us sab ko shape deta hai jo aage aata hai.
Claude Code loop ki parts product ke andar ship karta hai. Heartbeat (/loop, /schedule, cloud Routines), built-in checker ke saath run-until-done (/goal), isolation (--worktree), event intake (Channels) — yeh sab ab built-in commands hain. Aik saal pehle aap ne yeh paane ke liye shell scripts ka aik dher likha aur sambhala hota. Aaj aap zyada tar bas usay set up karte hain.
Main aik Routines hai: cloud automations jo Anthropic ke servers par chalti hain chahe aap ka laptop band ho, aik schedule, aik API call, ya aik GitHub event se shuru hoti hain. Is aasani ki qeemat per-account daily run caps hain (apni current limit Routines usage UI mein check karein, kisi fixed number par bharosa karne ke bajaye), saath hi yeh ke Routines aik research preview hain jo ab bhi badal sakti hain.
OpenCode aap ko neeche wali layer deta hai. Koi built-in cloud scheduler nahin. Is ke bajaye, OpenCode woh worker hai jise aap call karte hain, aur aap heartbeat laate hain — operating system se ya CI se.
Key command opencode run "<prompt>" hai. Yeh aik prompt ko bina chat screen ke chalata hai, result print karta hai, aur exit ho jata hai. Woh aik command aik loop ki aik beat hai. Aap usay aik loop banate hain usay kisi aisi cheez mein lapet kar jo timer par fire ho: cron ya launchd (macOS aur Linux), Task Scheduler (Windows), ya schedule trigger ke saath GitHub Actions. Yeh zyada wiring hai, lekin aap ko poora control milta hai, yeh un machines par chalta hai jo aap ke paas pehle se hain, aur isay kisi vendor cloud ki zaroorat nahin.
Ghaur karein ke dono tabs wohi paanch parts bayan karte hain. Aik heartbeat aik heartbeat hai, chahe woh aik managed Routine ho ya cron mein aik line. Maker–checker split wohi idea hai, chahe /goal usay grade kare ya aik doosra opencode run. Loop ki shape aik baar seekh lein aur yeh transfer ho jati hai. Isi liye hum dono sikhate hain.
Where we are going (the whole loop, early)
Parts se pehle, yeh raha finish line. Woh loop jo aap Part 5 mein banayein ge woh chhe sade steps hai:
every weekday at 9am: # 1. Heartbeat
read progress.md # 6. Spine (memory)
find overnight CI failures + issues # what to work on
for each one:
draft a fix in its own checkout # 2. Worktree
using the project's triage skill # 3. Skill
have a separate reviewer grade it # 4. Sub-agents (maker/checker)
if PASS: open a PR via GitHub # 5. Connector (MCP)
if risky: write it to progress.md and leave it for a human
update progress.md # 6. Spine again
Yeh tasveer zehan mein rakhein. Parts 2–4 mein har concept is ki aik line hai.
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: The Heartbeat
Heartbeat woh hai jo aik run ko aik loop bana deta hai. Chaar tarah ke hote hain, "is session mein rehta hai" se le kar "aap ke baghair bil-kul chalta hai" tak. Inhein tarteeb se seekhein — zyada tar asli loops aakhri do istemaal karte hain.
4. In-session loops (repeat while you watch)
Sab se sada heartbeat: aik prompt ko timer par dobara chalana jab tak session khula hai. "Is ko khatam hone tak watch karein" ke liye achha — aik deploy, aik lamba test run, aik CI job.
Bundled /loop skill istemaal karein. Usay aik interval aur aik prompt dein:
/loop 5m check if the deployment finished and tell me what happened
Claude interval ko aik schedule mein badal deta hai, job ko aik ID deta hai, aur jab tak session khula rehta hai prompt ko har 5 minute chalata hai. Jab aap fareegh ho jayein, usay cancel karein aur aage barhein.
Aik limit jaanna chahiye: /loop jaan boojh kar session ke andar rehta hai. Terminal band karein, ya laptop ko sone dein, aur yeh ruk jata hai. Yeh aik safety feature hai, bug nahin — aik casual in-session loop ko session se zyada nahin jeena chahiye. Aisi cheez ke liye jo chalti rahe, aik scheduled task ya aik Routine istemaal karein (Concept 6).
OpenCode mein koi /loop command nahin. Aap timer khud shell se banate hain. Chunke opencode run aik prompt ke baad exit ho jata hai, sleep ke saath aik while loop wohi kaam karta hai:
while true; do
opencode run "check if the deployment finished; if it did, say DONE"
sleep 300 # 5 minutes
done
Yeh /loop jaisa hi idea hai, aik layer neeche: shell heartbeat hai, aur opencode run beat hai. Har taza opencode run aik bhi cheez karne se pehle poore runtime ko pehle boot karta hai — config, model, plugins, aur koi bhi MCP servers. Har beat par yeh start-up cost na dene ke liye, aik server aik baar shuru karein aur us se attach karein:
opencode serve --port 4096 &
# then, each beat:
opencode run --attach http://localhost:4096 "check the deploy status"
5. Run-until-done (the loop decides when to stop)
Aik fixed-timer loop jaan boojh kar sada hai — yeh N baar fire hota hai chahe kuch bhi ho. Aksar jo aap waqai chahte hain woh hai "jab tak yeh sach na ho jaye chalte raho." Yahan maker–checker idea pehli baar zahir hota hai: loop ko us agent ko decide nahin karne dena chahiye ke kaam ho gaya jis ne kaam kiya.
/goal istemaal karein. Aap usay aik stopping condition dete hain jise Claude apne hi output mein sabit kar sake — aisi cheez jo woh aik command chala kar aur result surface kar ke dikhata hai, jaise "test/auth mein saare tests pass karein." Yeh turns ke aar-paar kaam karta rehta hai jab tak woh condition poori na ho. Ahem hissa: har turn ke baad aik alag, chhota model (default mein Haiku) transcript parhta hai aur decide karta hai "kya hum ho gaye?" To jis agent ne code likha woh agent nahin jo usay grade karta hai. Aik subtlety jaanne layeq: woh checker khud commands nahin chalata — woh us cheez ko judge karta hai jo Claude pehle hi surface kar chuka hai — to condition aisi honi chahiye jo Claude ka apna output dikha sake, na ke aik private fact jo sirf aik command zahir karti.
/goal All tests in test/auth pass and `npm run lint` is clean.
Yeh edit karega, tests chalayega, failures parhega, dobara try karega, aur sirf tab ruke ga jab checker confirm kar de ke condition waqai poori ho gayi — ya jab aap khud usay /goal clear se roken. Koi built-in "N tries ke baad chhor do" nahin: agar aap aik ceiling chahte hain, to usay condition mein likhein (…or stop after 20 turns). Aisi conditions likhein jo aik command sabit kar sake — "tests pass aur lint clean hai," na ke "auth code achha hai." Yahan Spec-Driven Development ki spec faida deti hai: is ke acceptance criteria pehle se aisi conditions hain jo aik command sabit kar sakti hai, to aik achhi spec aap ko muft mein stopping condition de deti hai.
OpenCode mein koi /goal nahin, to aap wohi maker–checker stop shell aur exit codes se banate hain. Pattern: agent kaam karta hai, phir aik asli command (agent nahin) decide karti hai ke rukna hai ya nahin.
for i in $(seq 1 8); do # cap the tries — never loop forever
opencode run "Make the tests in test/auth pass and fix any lint errors."
if npm test -- test/auth && npm run lint; then
echo "Condition met on try $i"; break
fi
done
Yahan test runner aur linter checker hain — sab se honest checker jo hai, kyunke aik command khud ko qaeel nahin kar sakti ke kaam theek hai. Aik smarter check ke liye, aik dedicated review agent (Concept 11) ke saath aik doosra opencode run chalayein aur us se PASS ya FAIL print karwayein. Hamesha tries cap karein; aik loop jo bina limit retry karta hai wohi tareeqa hai jis se token bills control se bahar barhti hain.
Do stops, hamesha: aik success condition (cheez ho gayi) aur aik ceiling (max tries, max minutes, ya max spend). Aik loop jis ke paas success condition ho lekin ceiling na ho woh aap ka saara token budget aik aisa goal poora karne ki koshish mein kharch kar dega jise woh kabhi poora nahin kar sakta.
6. Unattended schedules (runs while you sleep)
Yeh woh heartbeat hai jo loop engineering ko maani deta hai: aik task jo chalta hai chahe aap computer par hon ya na hon. "Har weekday 9am par, raat bhar ki CI failures chhantein." "Har Monday, dependencies check karein aur safe fixes ke saath aik PR kholein."
Do tarah ke, is hisab se ke aap ko apna laptop on chahiye ya nahin:
Cloud Routines (laptop band ho sakta hai). Modern default. Aik claude.ai/code/routines par, Desktop app mein, ya CLI mein /schedule ke saath banayein — teeno usi cloud account mein likhte hain. Aik routine aik prompt, woh repos jo usay chhune ki ijazat hai, is ke connectors, aur aik trigger (schedule, API, ya GitHub event) ko bundle karti hai, phir Anthropic ke servers par chalti hai. Per-account daily run caps ko note karein, aur yeh ke default mein aik routine sirf un branches par push kar sakti hai jo claude/ se shuru hoti hain — aik jaan boojh kar bana guardrail jise aap Allow unrestricted branch pushes setting ke saath per-repository hata sakte hain.
Apne cron mein headless one-shot (laptop on, koi Anthropic cloud nahin). claude -p aik prompt chalata hai aur exit ho jata hai — usay seedha crontab mein dalein:
# 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
Poore treatment ke liye, book ka Scheduled Tasks: The Loop Skill and Cron Tools dekhein.
OpenCode ka un-attended heartbeat hamesha OS ya CI hota hai — yahi OpenCode ka raasta hai. opencode run ko bina chat screen ke istemaal karein, aur scheduler ko usay fire karne dein.
Aap ki apni machine, cron ke saath:
# every weekday at 9am: sort through CI and summarize failures
0 9 * * 1-5 cd /path/to/repo && opencode run "check the CI dashboard and summarize any failures" >> ~/opencode-cron.log 2>&1
Cloud, GitHub Actions ke saath (aap ki kisi machine ka on hona zaroori nahin). Neeche di gayi model string sirf misaal ke liye hai — apne install ke exact IDs ke liye opencode models chalayein:
name: Scheduled OpenCode Task
on:
schedule:
- cron: "0 9 * * 1-5" # weekdays at 9am UTC
jobs:
opencode:
runs-on: ubuntu-latest
permissions: { contents: write, pull-requests: write, issues: write }
steps:
- uses: actions/checkout@v6
with: { persist-credentials: false }
- uses: anomalyco/opencode/github@latest
env: { ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} }
with:
model: anthropic/claude-sonnet-4-6 # confirm with `opencode models`
prompt: |
Review the codebase for TODO comments and summarize them.
If any are worth acting on, open an issue to track them.
Scheduled events ke liye prompt zaroori hai (usay parhne ke liye koi comment nahin hota), aur agar loop ko branches ya PRs kholni hon to aap ko contents: write / pull-requests: write dena hoga.
OpenCode GitHub Action ko current official docs mein anomalyco/opencode/github@latest ke taur par refer kiya gaya hai; kuch puri guides ab bhi sst/opencode/github@latest dikhati hain. Dono usi project ki taraf ishara karte hain — woh istemaal karein jo aap ka opencode github install generate karta hai. Models ke liye, anthropic/claude-sonnet-4-6 current Sonnet ID hai. Dateless IDs 4.6 generation ke saath aaye, jahan dateless string hi pinned snapshot hai; puri 4.5-generation models jaise Haiku 4.5 aik dated canonical ID (claude-haiku-4-5-20251001) plus aik dateless claude-haiku-4-5 alias rakhti hain jo latest snapshot ki taraf ishara karta hai. Neeche di gayi examples reproducibility ke liye dated Haiku ID pin karti hain. Apne install ke exact strings dekhne ke liye opencode models chalayein.
7. Event-driven (react when something happens)
Aik schedule poochta hai "har ghante check karo." Aik event poochta hai "jis lamhe X ho us par react karo." Aik PR khulta hai, aik issue file hota hai, aik message aata hai — aur loop us ke jawab mein chalta hai.
Do raaste. Routines aik GitHub webhook trigger qubool karti hain, to aik routine aik push ya aik naye PR par chal sakti hai, sirf clock par nahin. Chat-style events ke liye, Channels bahar wale sources se messages (Telegram, Discord, aur iMessage built in hain; aik webhook receiver woh hai jise aap khud wire karte hain) seedha aik chalti hui session mein push karte hain — scheduling ka event-driven partner. code.claude.com/docs/en/channels dekhein.
GitHub agent ko aik baar opencode github install se install karein, jo .github/workflows/opencode.yml add karta hai. Us ke baad, OpenCode repository events par react karta hai — pull_request, issues, aur /oc ya /opencode comments — aap ke GitHub Actions runners ke andar chalte hue:
name: opencode-review
on:
pull_request:
types: [opened, synchronize, reopened, ready_for_review]
jobs:
review:
runs-on: ubuntu-latest
permissions: { contents: read, pull-requests: read }
steps:
- uses: actions/checkout@v6
with: { persist-credentials: false }
- uses: anomalyco/opencode/github@latest
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
model: anthropic/claude-sonnet-4-6
use_github_token: true
prompt: |
Review this pull request for bugs, quality issues, and security risks.
Bina prompt ke aik pull_request event ke liye, OpenCode default mein PR review karta hai.
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.
Part 3: The Body
Heartbeat loop shuru karta hai. Yeh chaar parts woh hain jo loop har beat par karta hai. Aap inhein agentic coding course mein handy extras ke taur par mil chuke hain. Aik loop mein yeh waqai matter karte hain, kyunke koi insan har step nahin dekh raha.
8. Isolation: worktrees
Jis lamhe aik loop aik se zyada agent aik saath chalata hai, woh aik doosre ki files overwrite karna shuru kar dete hain — bil-kul jaise do log aik hi lines edit kar rahe hon baghair aik doosre ko bataye. Aik git worktree is ko theek karta hai: aik alag working folder, apni branch par, jo wohi repo history share karta hai. Aik agent ki edits doosre ke checkout ko chhu nahin sakti.
Built in. --worktree flag istemaal karein taake aik session apne checkout mein khulle, ya aik subagent par isolation: worktree set karein taake har helper ko aik taza checkout mile jo baad mein khud saaf ho jata hai. Aik scheduled task per run worktree isolation on kar sakta hai, taake parallel runs kabhi aap ke apne manual kaam se na takrayein.
Koi single flag nahin. Aap git ki apni worktrees istemaal karte hain aur har aik par aik run point karte hain. Wohi isolation, saaf zahir:
git worktree add ../wt-feature-a feature-a
git worktree add ../wt-feature-b feature-b
( cd ../wt-feature-a && opencode run "implement feature A" ) &
( cd ../wt-feature-b && opencode run "implement feature B" ) &
wait
Community runners (OpenCode ke gird bane worktree managers) aap ke liye bookkeeping sambhal sakte hain agar aap yeh aksar karte hain.
9. Knowledge: skills, so no run is "day one"
Aik loop har baar cold chalta hai — aik taza session jis ko aap ke project ki aadat ki koi memory nahin. Bina madad ke, woh har beat par aap ka poora setup samajhta (ya guess karta) hai, tokens zaaya karta hai aur ghaltiyon ko dawat deta hai. Aik skill woh knowledge hai jo aik baar likha gaya, aik SKILL.md file mein, jahan agent usay har run par parhta hai.
Yeh dono tools mein aik jaisa kaam karta hai: aik folder jis mein instructions aur metadata ka aik SKILL.md ho, plus optional scripts aur references. Aik loop mein, rule sada hai: jo cheez aap warna har run par dobara samjhate, woh aik skill mein hai. Triage steps, project ki aadatein, "hum is tarah nahin karte us aik incident ki wajah se" — yeh sab skill mein rehta hai, taake loop dobara shuru hone ke bajaye khud par build kare. (Poora treatment Skills & Connectors crash course mein.)
Aik schedule mein instructions ki diwaar paste karne ke bajaye jise koi update nahin rakhega, aap ka scheduled prompt aik line ban jata hai — "daily-triage skill chalao" — aur skill detail rakhti hai. Chhota loop prompt, asaan-to-update logic, har beat par kam token cost.
10. Action: connectors (the loop acts, not just suggests)
Aik loop jo sirf aap ki files parh sakta hai woh aik loop hai jo sirf baat kar sakta hai. Connectors — MCP par bane — usay karne dete hain: aik PR kholna, aik Linear ticket update karna, Slack par post karna, aik database query karna, aik staging API call karna. Yeh us loop mein farq hai jo kehta hai "yeh raha fix" aur us mein jo PR kholta hai, ticket link karta hai, aur CI green hone par channel mein post karta hai.
Dono tools MCP bolte hain, to protocol un ke darmiyan transfer hota hai — lekin packaging aur authentication (local vs hosted, OAuth, permissions) ko aksar tool-specific wiring chahiye.
Apne config mein MCP servers add karein aur unhein aik routine ki connector list mein shaamil karein, taake un-attended run un tak pohanch sake. Wohi connectors jo aap haath se istemaal karte hain woh scheduled aur cloud runs ke liye mojood hote hain.
opencode.json ke mcp section mein servers declare karein — local servers aik subprocess shuru karte hain, remote servers automatic OAuth ke saath aik HTTPS endpoint tak pohanchte hain. Aik scheduled opencode run mein, opencode serve aik baar shuru karein aur us se --attach karein, taake aap har beat par MCP start-up cost na dein.
11. Maker–checker: sub-agents
Aik loop mein sab se ahem choice: jo agent kaam likhta hai woh agent nahin hona chahiye jo usay approve karta hai. Aik model jo apne hi output ko grade karta hai woh apne saath bahut narmi barat-ta hai. Aik doosra agent — alag instructions, aksar aik alag (kabhi zyada strong) model — woh pakar leta hai jo pehle ne miss kiya kyunke woh yaqeen se theek tha. Yahi woh wahid wajah hai jis se aap aik chalte hue loop ko akela chhor sakte hain.
Subagents ko .claude/agents/ mein define karein, aur unhein agent teams ke taur par jorein: aik explore karta hai, aik implement karta hai, aik spec aur tests ke khilaf check karta hai. "Spec" woh hai jo aap ne Spec-Driven Development mein likhna seekha: is ke acceptance criteria bil-kul wohi hain jin ke khilaf aik bharose-mand checker grade karta hai — aik vague spec aap ko aik vague verdict deti hai. Yeh wohi cheez hai jo /goal andar karti hai: aik taza model decide karta hai ke loop ho gaya, us ke bajaye ke worker khud ko grade kare.
OpenCode built-in primary agents (Build, Plan) aur aik built-in general subagent ship karta hai (plus explore, aur current versions mein scout aik experimental flag ke peechhe). Aap apne khud ke opencode.json mein ya apne agents folder mein markdown files ke taur par define kar sakte hain. Checker ko us ka apna (aksar sasta, read-only) model dein, aur maker se usay aik @ mention ya Task tool ke saath call karwayein. Aik aam split: aik strong model explore aur implement karta hai, aik focused model check karta hai.
---
mode: subagent
model: anthropic/claude-haiku-4-5-20251001
description: Reviews a diff against the spec and tests. Replies PASS or FAIL with reasons.
---
You are a strict code reviewer. You do not make changes.
Check the diff against the spec and the test results, then reply PASS or FAIL with the reasons.
Har sub-agent apna model aur tools chalata hai, to maker–checker split waqai zyada tokens cost karta hai. Yeh aik aise checker ki qeemat hai jis par aap bharosa kar sakein. Usay wahan kharch karein jahan aik doosri raye matter kare (koi bhi cheez jo loop aap ke door hone par commit karega); usay throwaway, read-only chores ke liye chhor dein.
11b. Codify the body: dynamic workflows
Ab tak, aik beat ka body — kaam dhoondna, har fix usay apne checkout mein draft karna, aik alag agent se usay grade karwana — aisi cheez hai jise agent turn-ba-turn assemble karta hai. Claude Code ab aap ko us poori orchestration ko aik rerunnable script ke taur par codify karne deta hai, jise aik dynamic workflow kehte hain: aap task bayan karte hain, Claude aik aisa script likhta hai jo kaam ko bahut se sub-agents mein faila deta hai, aur aik runtime usay background mein execute karta hai jab ke aap ki session free rehti hai. Yeh maker–checker split (Concept 11) aur worktree split (Concept 8) aik repeatable unit mein packaged hai — aur yeh aik asli quality pattern apply kar sakta hai, sirf zyada agents chalana nahin: mukhtalif reviewers aik doosre ki findings ko adversarially check kar sakte hain is se pehle ke kuch report ho.
Aik ke liye sade alfaaz mein poochein ("use a workflow to…"), usay ultracode keyword se trigger karein, ya bundled /deep-research chalayein. Jab koi run woh kare jo aap chahte hain, /workflows view mein s dabayein taake us ka script aik /command ke taur par save ho jo aap har branch par dobara chala sakein. Do limits isay imandar rakhti hain: agents capped hain (aik saath takreeban 16, fi run 1000) taake aik runaway script spiral na kar sake, aur aik run ki memory sirf us run ke andar rehti hai — aap usay usi session ke andar resume kar sakte hain, lekin aik taza session usay dobara shuru kar deti hai.
Koi /workflows command nahin. Jo script aap pehle hi likhte hain wohi workflow hai: Concept 5 ka capped for loop aur Concept 8 ka &/wait fan-out usi idea ka hand-rolled version hain — aap ka shell plan rakhta hai, opencode run har agent hai, aur exit codes checker hain. Aap ko poora control aur koi agent cap nahin milta, is qeemat par ke aap orchestration khud likhte aur sambhalte hain.
Yeh sab se asaan ghalti hai jo workflows ke powerful lagne lagne par hoti hai. Aik dynamic workflow aik baar chalta hai, jab aap (ya ultracode setting) usay shuru karte hain, aur khatam hote hi sab kuch bhool jata hai. Is ka koi heartbeat nahin aur koi spine nahin. To yeh aik single beat ka body hai, loop nahin. Loop composition hai: aik heartbeat (aik Routine, /loop, ya cron) beat fire karta hai, workflow woh body hai jo us par chalta hai, aur aik progress file jise is ke agents likhte hain woh spine hai jise agla firing parhta hai. Workflow engine hai; Routine woh hai jo chaabi ghumati hai, aur progress.md woh fuel hai jo trips ke darmiyan bacha rehta hai.
Part 4: The Spine
12. State that survives between runs
Yeh raha woh hissa jise beginners chhor dete hain, aur yahi woh hai jo aik loop ko loop banata hai. Model har run ke darmiyan sab kuch bhool jata hai. Agar har beat sifr se shuru hoti hai, to aap ke paas loop nahin — aap ke paas wohi pehla step hai, hamesha ke liye repeat hota hua. Fix dull aur powerful hai: state ko model ke bahar, disk par rakhein.
State ki do layers, aik saath kaam karti hui:
- Rules file (
CLAUDE.md/AGENTS.md) — woh steady aadatein jo loop har run par parhta hai. (Isay chhota rakhein; aap ne pichle course mein kyun seekha. Aik bloated rules file har aik beat par adaa ki jati hai.) - Aik progress file — aik sada markdown file (ya MCP ke zariye aik Linear board) jo record karti hai kya try kiya gaya, kya pass hua, kya abhi khula hai. Yeh asli spine hai. Kal ki 9am run isay kholti hai aur wahan se uthati hai jahan aaj ki run ruki.
Aadat: har run shuru mein progress file parhti hai aur aakhir mein usay update karti hai. Jab loop wohi ghalti baar baar karta hai, to fix aik clever prompt nahin — yeh hai ke loop se sabaq rules file mein likhwana, taake fix har future run ke liye rahe.
<!-- progress.md — the loop's memory between runs -->
## Done
- 2026-06-22: fixed flaky test in test/auth (retry on token refresh)
## In progress
- Dependency audit: 3 of 7 advisories patched; lodash bump blocked by an API change
## Open / needs a human
- CVE-2026-xxxx in image lib — the fix changes the output format, escalating to a maintainer
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.
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 jaisa aik board. Model ki memory runs ke darmiyan miti jati hai, to jo cheez zinda rehni chahiye woh model ke bahar rehti hai. Repo yaad rakhta hai; model nahin.Show answer
Part 5: A Complete Loop, Twice
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.
The shared skill
Yeh aik file dono tools mein chalti hai. Isay .claude/skills/daily-triage/SKILL.md (Claude Code) ya .opencode/skills/daily-triage/SKILL.md (OpenCode) ke taur par save karein.
---
name: daily-triage
description: >-
Runs the morning maintenance pass. Reads the progress file, gathers overnight
CI failures, open issues, and new audit advisories, drafts safe fixes (each
one checked by a separate reviewer agent), opens pull requests for what passes,
and writes anything risky to the progress file for a human. Use this for the
scheduled morning maintenance loop.
---
# Daily triage
You are the morning maintenance loop. Work through these steps in order.
Do not skip the progress file. It is your only memory between runs.
## 1. Read your memory first
- Open `progress.md`. Read the "In progress" and "Open / needs a human" sections.
- Do not redo anything already listed under "Done".
## 2. Find the work
Gather candidates in this order, and stop once you have at most 5:
1. CI runs that failed since the last entry in `progress.md`.
2. Open issues labelled `bug` or `maintenance`.
3. New advisories from `npm audit` (or this project's audit command).
## 3. Work each candidate
- Create an isolated checkout: a git worktree, or a fresh branch named
`claude/<short-slug>`.
- Draft the smallest fix that solves the one problem. Do not bundle changes.
- Send the diff to the reviewer agent. Wait for its verdict before going on.
## 4. Decide from the verdict
- PASS, and the change is low risk (no public API change, no data migration,
no file deletion): open a pull request. Title it `fix: <one short line>` and
link the issue.
- FAIL, or the change touches anything risky: do NOT open a pull request. Add a
short entry to the "Open / needs a human" section of `progress.md`. Say what
you tried and why you stopped.
## 5. Update your memory last
- Move finished items to "Done" with today's date.
- Save `progress.md`. This is the file tomorrow's run will read.
## Rules
- Never open more than 5 pull requests in one run.
- Never change `main` directly. Only `claude/*` branches.
- When in doubt, escalate. A flagged item a human checks is always safer than a
wrong fix shipped while no one was watching.
The reviewer (the checker)
Reviewer amal mein maker–checker split hai. Aap ko dono files chahiye — yeh aik ya doosre wali tool choice nahin. Format har tool ke hisab se thora farq rakhta hai, to har aik neeche poora dikhayi gayi hai.
Claude Code — .claude/agents/reviewer.md ke taur par save karein:
---
name: reviewer
description: Reviews a diff against the spec and the test results. Replies PASS or FAIL with reasons. Makes no changes.
tools: Read, Bash(npm test*), Bash(npm run lint*), Bash(git diff*)
model: claude-haiku-4-5-20251001
---
You are a strict, read-only code reviewer. You never edit files.
1. Run the tests and the linter. Read the output yourself. Do not trust a claim
that they pass.
2. Check the change against the project conventions in `CLAUDE.md` and the
relevant spec.
3. Look for bugs, missing edge cases, security risks, and any change to public
behaviour.
Then reply with exactly one of:
- `PASS` — followed by one line saying what you verified.
- `FAIL` — followed by the specific reasons, one per line.
A change that only "looks fine" is not a PASS. The tests must actually pass, and
the change must do only what was asked.
OpenCode — .opencode/agents/reviewer.md ke taur par save karein:
---
mode: subagent
model: anthropic/claude-haiku-4-5-20251001
description: Reviews a diff against the spec and tests. Replies PASS or FAIL with reasons. Read-only.
permission:
edit: deny
bash:
"*": deny
"npm test*": allow
"npm run lint*": allow
"git diff*": allow
---
You are a strict, read-only code reviewer. You never edit files.
1. Run the tests and the linter. Read the output yourself. Do not trust a claim
that they pass.
2. Check the change against the project conventions in `AGENTS.md` and the
relevant spec.
3. Look for bugs, missing edge cases, security risks, and any change to public
behaviour.
Reply with exactly one of:
- PASS — followed by one line saying what you verified.
- FAIL — followed by the specific reasons, one per line.
A change that only "looks fine" is not a PASS. The tests must actually pass, and
the change must do only what was asked.
Wiring the heartbeat
claude.ai/code/routines par aik Routine banayein jis mein weekday-9am schedule, aap ka repo, aur aap ke GitHub + Slack connectors hon. Is ke prompt ko skill ki taraf point karein, taake routine definition chhoti rahe:
Run the daily-triage skill.
Start by reading progress.md; finish by updating it.
For each fix: draft it in an isolated worktree, have the reviewer subagent grade it,
open a PR only on PASS, and append anything risky to the "needs a human" section.
Skill steps rakhti hai. .claude/agents/reviewer.md checker hai. isolation: worktree parallel fixes ko alag rakhti hai. GitHub connector PRs kholta hai. Chunke yeh aik cloud Routine hai, yeh 9am par chalta hai chahe aap ka laptop khula ho ya na ho — aap ke plan ki daily run cap ke andar.
Isay aik GitHub Actions workflow ke taur par banayein, taake yeh cloud mein chale baghair aap ki kisi machine ke jaage. Action heartbeat hai; opencode run worker hai; aap ka repo skill, agents, aur progress.md rakhta hai.
name: morning-maintenance
on:
schedule:
- cron: "0 9 * * 1-5"
jobs:
triage:
runs-on: ubuntu-latest
permissions: { contents: write, pull-requests: write, issues: write }
steps:
- uses: actions/checkout@v6
with: { persist-credentials: false }
- uses: anomalyco/opencode/github@latest
env: { ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} }
with:
model: anthropic/claude-sonnet-4-6 # confirm with `opencode models`
prompt: |
Run the daily-triage skill.
Read progress.md first; update it last.
For each candidate fix: draft it on a new branch, then invoke the
@reviewer subagent to grade it. Open a PR only when the reviewer
replies PASS. Append anything risky to the "needs a human" section
of progress.md and leave it for the maintainer.
reviewer agent (aik saste read-only model par) checker hai. Nayi branches CI mein worktree isolation ka kaam karti hain. OpenCode GitHub app PRs kholta hai. Isay GitHub ki bajaye apni machine par chahte hain? Bil-kul wohi prompt aik cron line se chalta hai jo opencode run ko call karti hai — sirf heartbeat badalta hai.
What one real morning looks like
Aap ne yeh sab aik baar design kiya. Yeh raha aik single run, jis tarah aap jaag kar dekhte (neeche di gayi run shape ki aik misaal hai, recording nahin):
[09:00] daily-triage fires
→ reads progress.md: 1 item still "in progress" (lodash bump), nothing new flagged
→ finds: 2 CI failures overnight, 1 new npm-audit advisory
→ CI failure #1 (flaky auth test):
drafts fix on branch claude/fix-auth-retry
reviewer → PASS (tests green; retries on token refresh; no API change)
→ opens PR #142, links the issue
→ CI failure #2 (type error in report.ts):
drafts fix on branch claude/fix-report-types
reviewer → PASS → opens PR #143
→ advisory (image library):
the safe fix changes the output format
reviewer → FAIL (public behaviour change)
→ writes it to "Open / needs a human" in progress.md, opens no PR
→ updates progress.md, exits
[you, 09:30] two PRs to review, one flagged item to decide on. You typed nothing.
Dekhein kya hua. Loop ne kaam dhoonda, usay draft kiya, check kiya, safe hissa ship kiya, aur aap ko sirf woh aik faisla diya jis ke liye aik insan chahiye tha. Yeh amal mein loop engineering hai. Aur ghaur karein: dono tools ke darmiyan wahid asli farq heartbeat aur woh jagah thi jahan run hua. Darmiyan mein har cheez — skill, spine, worktree, maker–checker, connector — wohi design thi.
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: Staying the Engineer
Aik loop kaam badalta hai; yeh aap ko us se bahar nahin nikalta. Teen masle aap ke loops behtar hone ke saath bare hote hain, chhote nahin. Yeh hissa course mein sab se ahem hai.
13. Token cost is the real limit, not the keybind
Yeh, kaafi door tak, loops ke ghalat hone ka sab se aam tareeqa hai. Aik loop baar baar chalta hai, aksar sub-agents shuru karta hai, aur har sub-agent apna model aur tools chalata hai. Cost takreeban har kisi ki tawaqqo se zyada tezi se barhti hai. Fixes sade hain:
- Har loop cap karein — max tries, max minutes, ya max spend. Hamesha (Concept 5).
- Model ko kaam se match karein — plan aur check ke liye aik strong model, kaam karne ke liye aik sasta. Yeh sab se bara saving hai, aur aap ne pichle course mein yeh pehle hi seekha.
- Loop prompt aur rules file chhoti rakhein — aap har beat par un ke liye adaa karte hain. Detail un skills mein dhakelein jo sirf istemaal hone par load hoti hain.
- Isay kam baar chalayein — har paanch minute ke bajaye ghante mein aik baar aam tor par kaafi hai, aur takreeban barah guna sasta.
Numbers ki aik jaldi se samajh (misaal ke liye). Maan lein aik beat — maker plus checker — takreeban 40k tokens parhta hai aur takreeban 6k likhta hai. Sonnet 4.6 ke $3 / $15 fi million par, yeh takreeban $0.20 fi beat hai. Aik 20-din ke mahine mein din mein paanch beats takreeban $20 hain — sasta. Wohi loop har paanch minute fire hota hua sau guna se zyada beats hai — aaram se $1,000 fi mahina se aage — bina kisi extra value ke. Cadence, keybind nahin, woh jagah hai jahan paisa jata hai.
Model aik doosra lever hai — OpenCode ke raaste par. Woh numbers Sonnet 4.6 maan kar chalte hain. Claude Code ki loop commands Claude chalati hain, lekin OpenCode aap ko model chunne deta hai, aur aik sasta per-beat cost ko bahut door le jata hai: DeepSeek V4 Flash (takreeban $0.14 / $0.28 fi million) wohi beat takreeban $0.007 — takreeban 30× sasta par chalata hai — $20-fi-mahina wale loop ko aik dollar se kaafi neeche le aata hai. Do imandar caveats. Pehla, sasta maker, bharose-mand checker: aik weaker model bure fixes likhta hai, to woh zyada beats jala sakta hai ya zyada baar review fail kar sakta hai, aur retries saving kha jate hain — sasta model aik clear spec par mechanical maker ke liye istemaal karein, aur aik checker rakhein jis par aap bharosa karein (test runner aur linter sab se sasta, sab se imandar checker hain jo hain). Doosra, cadence ab bhi ghalib hai: aik 30×-sasta model har paanch minute fire hota hua ab bhi Sonnet ke ghante mein chalne se zyada cost kar sakta hai. Model bill ko neeche scale karta hai; yeh ke kitni baar chalta hai aur retry karta hai woh ab bhi usay set karta hai.
Aam failure hamesha aik jaisi hai: aik loop jo khud se chalta hai, aik aisi stopping condition ke saath jise woh kabhi poora nahin kar sakta, raat bhar retry karta hua. Shuru karne se pehle aik ceiling set karein. Pehli chand asli runs dekhein. Phir usay khud se chalne dein.
14. Checking the work is still your job
Aik loop jo khud se chalta hai woh aik loop hai jo khud se ghaltiyan karta hai. Maker–checker split loop ke "it's done" ko kuch maani deta hai — lekin "done" ab bhi aik claim hai, aik proof nahin. Aap ka kaam ghaaib nahin hua; yeh apni jagah badal gaya. Aap ab har step type nahin karte, lekin aap ab bhi woh hain jo confirm karta hai ke loop ne aisa code ship kiya jo waqai chalta hai. Woh diffs parhein jo loop ne kholi. Loop par kaam karne ke liye bharosa karein; counting se pehle kaam check karein.
15. Don't stop understanding your own project
Jitni tezi se aik loop aisa code ship karta hai jo aap ne nahin likha, utna hi wide gap aap ke project mein jo hai aur jo aap waqai samajhte hain us ke darmiyan hota hai. Woh gap aik asli cost hai, aur aik smooth loop usay khamoshi se barhata hai. Ilaaj aur trap wohi aik amal hain. Loop design karna aap ko engaged rakhta hai jab aap usay ghaur se karte hain — aur aap ko sochna chhornay deta hai jab aap usay kaam se bachne ke liye karte hain. Wohi amal, opposite result. Loop farq nahin bata sakta. Aap bata sakte hain.
Do log bil-kul wohi loop bana sakte hain aur opposite results pa sakte hain. Aik usay un kaam par tezi se barhne ke liye istemaal karta hai jise woh gehrai se samajhta hai. Doosra usay kaam ko bil-kul samajhne se bachne ke liye istemaal karta hai. Loop banayein. Lekin usay aise banayein jaise koi jo engineer rehne ka irada rakhta ho — na sirf woh shakhs jo go dabata hai.
Aur yeh poore course ka through-line hai. Har saal tools loop ki machinery ka aur hissa apne andar le lete hain: orchestration, checker, aur schedule ab built-in hain (dynamic workflows, /goal, Routines) jahan aik saal pehle yeh aap ki apni shell scripts thin. Jo tools absorb nahin kar sakte woh do siray hain jo aap Concept 1 mein mile — intent, itni theek se specify kiya gaya ke check ho sake, aur jo ship hota hai us ki accountability. Isi liye yeh engineering hai aur button-pushing nahin, aur yeh skill ka woh hissa hai jo sarta nahin. Tools ko strong hone dein aur un par jhukein; bas un dono siron ko apne haathon mein rakhein.
When a loop fails while you're asleep
Aik un-attended loop un-attended fail bhi hota hai. Is se pehle ke aap usay raat bhar bharosa karein, usay observable banayein:
- Output wahan bhejein jahan aap dekhein ge — aik log file, aik Slack ya Discord message (Claude Code Channels), ya Triage inbox. Woh terminal nahin jo aap pehle hi band kar chuke.
- Har run aik line likhein, failure par bhi — har beat
progress.md(ya aik log) mein aik timestamped note add karta hai: us ne kya try kiya, kya pass hua, kya tuta. Aik khamosh failure sab se buri tarah ki hai. - Runs ko replayable rakhein — OpenCode mein,
opencode run --format json,opencode export <id>, 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.
🚀 Projects
Loops ke baare mein parhna aik banane jaisa nahin. Yeh rahe paanch projects, asaan se mushkil. Inhein kisi bhi tool mein karein — loop ki shape wohi hai, to matching concept ki command ki taraf jayein (Claude Code mein /loop aur /goal; OpenCode mein aik shell timer ke saath opencode run).
Shuru karne se pehle do rules, har baar:
- Aik throwaway git repo istemaal karein. Aik loop khud files edit karta hai. Apne pehle loops us kaam ki taraf point na karein jis ki aap ko parwah hai.
- Pehle aik ceiling set karein. Max tries, max minutes, ya max spend — is se pehle ke aap kisi cheez ko khud se chalne dein (Concept 13).
Project 115-30 minA watch loopMake a loop watch a long task and tell you the moment it finishes.
Difficulty: easy · Uses: Concept 4 (in-session loop).
Build. Apne repo mein aik lamba task shuru karein (misaal ke taur par, aik script jo thori der sota hai aur phir aik file likhti hai). Aik in-session loop set up karein jo har minute check kare ke task khatam hua ya nahin, aur aap ko us lamhe bataye jab woh ho jaye.
Done when loop ko pata chal jaye ke task khatam hua, aik baar woh keh de, aur aap usay saaf tareeqe se rok sakein — aur aap kabhi terminal dekhte hue na baithein.
Project 230-45 minMake the tests pass, then stopLoop until a command — not the agent — decides the work is done.
Difficulty: easy–medium · Uses: Concept 5 (run-until-done), Concept 11 (maker–checker).
Build. Apne repo mein 2–3 chhote failing tests dalein. Aik loop banayein jo tab tak kaam karta rahe jab tak tests pass na hon — lekin aik command (test runner) ko, agent ko nahin, decide karne dein ke kab ho gaya. Isay, maslan, 6 tries par cap karein.
Done when loop is liye ruke ke tests waqai pass ho gaye, na ke is liye ke woh cap par pohancha. Agar yeh cap par pohanchta rehta hai, to aap ki stop condition ya aap ke prompt par kaam chahiye — yahi sabaq hai.
Project 345-60 minThe morning brief with a memoryA scheduled loop whose second run clearly builds on its first.
Difficulty: medium · Uses: Concept 6 (unattended schedule), Concept 12 (the spine).
Build. Aik scheduled loop banayein jo aik baar chale, aik progress.md parhe, repo se kuch sada ikatha kare (khule TODO comments, ya pichle din ke commits), aik chhota summary likhe, aur progress.md ko us cheez se update kare jo us ne paya aur date ke saath.
Done when aap usay do baar chalayein aur doosri run saaf tor par pehli par build kare — woh us cheez ko repeat na kare jo woh pehle hi record kar chuki. Yeh sabit karta hai ke aap ki spine kaam karti hai. Agar doosri run sifr se shuru hoti hai, to aap ke loop ki abhi koi memory nahin.
Project 41-2 hrsA fix loop with a real checkerAn implementer drafts, a separate reviewer grades, and only PASS opens a PR.
Difficulty: medium–hard · Uses: Concept 8 (worktree), Concept 9 (skill), Concept 11 (maker–checker).
Build. Part 5 ke loop ka aik chhota version. Apne fix steps ke saath aik chhoti skill likhein, aur aik reviewer agent jo PASS ya FAIL jawab de. Aik asli bug lein, implementer se usay apne checkout (worktree ya branch) mein draft karwayein, aur reviewer se usay grade karwayein. Aik PR sirf PASS par kholein.
Done when do cheezein dono sach hon: aik achhe fix ko PASS aur aik PR mile, aur aik jaan boojh kar bura fix jo aap dalein usay wajah ke saath FAIL mile. Agar reviewer bure fix ko pass kar deta hai, to aap ka checker bahut narm hai — usay tight karein. Aik checker jo har cheez approve karta hai woh koi checker nahin.
Project 52-4 hrsYour own daily loopThe full six-part loop on a real chore, run unattended for a week — the capstone.
Difficulty: capstone · Uses: all six parts.
Build. Aik asli, boring, recurring chore chunein jis project par aap waqai kaam karte hain — aik dependency audit, aik docs-freshness check, aik changelog draft, aik lint sweep. Poora loop banayein: heartbeat, worktree, skill, maker–checker, connector, aur spine. Budget guards add karein. Usay chalne dein.
Done when yeh aik hafte un-attended chal chuka ho aur aap jo woh ship karta hai us par bharosa karein is liye ke aap ne usay parha — na ke is liye ke aap ne parhna chhor diya. Phir Concept 15 ka imandari se jawab dein: kya project ki aap ki samajh us cheez ke saath qadam milati rahi jo loop ne badla? Agar nahin, to loop ko tab tak slow karein jab tak woh aisa na kare. (Jab yeh raat bhar fail ho — aur hoga — model ko qusoor dene se pehle When a loop fails while you're asleep mein se guzrein.)
Where to go next
- Bas schedule ki details chahiye? Reference page Scheduled Tasks: The Loop Skill and Cron Tools
/loop,claude -p,opencode run, aur OS schedulers ko gehrai mein cover karta hai. - Non-coding kaam ke liye loops bana rahe hain? Cowork & OpenWork crash course professionals ke liye wohi heartbeat idea dikhata hai, cron ke bajaye scheduled tasks ke saath.
- Woh spec jo aap ne Spec-Driven Development mein likhi hi aap ke loop ki stopping condition hai: is ke acceptance criteria woh hain jin ke khilaf checker grade karta hai aur jo
/goalrukne se pehle sabit karta hai. Jab aik loop chalta chhornay ke liye un-safe lage, to fix takreeban hamesha aik sharper spec hota hai — zyada automation nahin.
Sources & further reading
Yeh course primary sources ke aik chhote set par tika hai. Framing aur quotes in se aate hain; technical details official docs se aate hain.
"Loop engineering" ki ibtida
- Addy Osmani, Loop Engineering — woh essay jis ne pattern ko naam diya aur five-parts-plus-spine model bayan kiya. https://addyosmani.com/blog/loop-engineering/
- The New Stack, "The Anthropic leader who built Claude Code says he ditched prompting — now he just writes loops." https://thenewstack.io/loop-engineering/
- Boris Cherny ka "my job is to write loops" remark aik CNBC interview se hai, jaisa Business Insider ne report kiya. Peter Steinberger ki "design loops that prompt your agents" line us ki X par post se hai.
Claude Code (official docs)
- Routines — cloud scheduled automations, triggers, aur run caps: https://code.claude.com/docs/en/routines
- Channels — aik chalti hui session mein event-driven input: https://code.claude.com/docs/en/channels
- Is book ka apna reference page, Scheduled Tasks: The Loop Skill and Cron Tools,
/loop,/goal, aurclaude -ppar gehrai mein jata hai.
OpenCode (official docs)
- CLI —
opencode run,serve, aur--attach: https://opencode.ai/docs/cli/ - Agents aur subagents — primary agents, subagents, aur per-agent models: https://opencode.ai/docs/agents/
- GitHub integration — Action, schedule/PR/issue triggers, aur
opencode github install: https://opencode.ai/docs/github/
Model identifiers
- Anthropic, Introducing Claude Sonnet 4.6 —
claude-sonnet-4-6model string ki source: https://www.anthropic.com/news/claude-sonnet-4-6 - Anthropic, Model IDs and versioning — kyun dateless IDs (
claude-sonnet-4-6) 4.6 generation se aage pinned snapshot hain, jab ke 4.5-generation models jaise Haiku 4.5 aik dated canonical ID (claude-haiku-4-5-20251001) plus aik dateless alias rakhti hain: https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions
Saare links June 2026 tak current hain. Yeh tools aksar update hote hain, to kisi specific limit, flag, ya model string par bharosa karne se pehle usay live docs ke khilaf confirm karein.
The one-line summary
Apne agent ko turn-ba-turn prompt karna chhor dein. Woh loop design karein jo aap ke liye usay prompt karta hai — aik heartbeat, chaar working parts, aur aik spine jo yaad rakhti hai — aur woh engineer rahein jo parhta hai ke yeh kya ship karta hai.