Loop Engineering: एक Crash Course

15 Concepts · agentic coding से लेकर self-prompting systems तक

आप एक coding agent चलाना सीख चुके हैं। आप इसे एक instruction देते हैं। यह आपकी files पढ़ता है, edits करता है, और आप result जाँचते हैं। एक turn, फिर अगला, फिर अगला। पूरे समय tool आपके हाथ में रहता है।

अब कल्पना करें कि आप इसे पकड़ना छोड़ देते हैं। इसके बजाय, आप एक छोटा सा system बनाते हैं। हर सुबह यह जागता है, देखता है कि रात भर में क्या बदला, तय करता है कि क्या करना ज़रूरी है, हर काम किसी agent को देता है, result जाँचता है, और सिर्फ़ उन्हीं decisions के लिए आपको बुलाता है जिनके लिए वाकई किसी इंसान की ज़रूरत है। आपने इसे एक बार बनाया। उसके बाद, यह खुद को prompt करता है।

यही है loop engineering। कीमती skill उस prompt से जो आप लिखते हैं, उस loop की ओर shift हो जाती है जो आप design करते हैं। यह course आपको सिखाता है कि एक loop किन चीज़ों से बना है, और इसे Claude Code और OpenCode दोनों में कैसे बनाएँ — जो एक ही मंज़िल तक दो बहुत अलग रास्तों से पहुँचते हैं।

Prerequisite: Claude Code और OpenCode: एक Crash Course। उस course ने आपको plan mode, context management, rules file, skills, subagents, और MCP सिखाया। यह course उन सब को मानकर चलता है। अगर ये शब्द आपके लिए नए हैं, तो पहले वह course करें। Loop engineering सीधे उसी के ऊपर बनी है। बेहतर हो अगर आपने Spec-Driven Development भी कर रखी हो: एक loop की रुकने की condition दरअसल एक spec ही है, और वही course है जहाँ आपने इसे लिखना सीखा — इसके बिना भी आप साथ चल सकते हैं, लेकिन आपके loops सिर्फ़ उतने ही अच्छे होंगे जितनी अच्छी conditions आप specify कर सकते हैं।

यहाँ नए हैं? जो आपको पहले से पता होना चाहिए, उसका 2-मिनट का recap

• Plan mode — agent आपकी files पढ़ता है और कुछ भी बदलने से पहले एक plan propose करता है; आप पहले approve करते हैं।
• Rules file (CLAUDE.md / AGENTS.md) — छोटे, स्थायी project notes जो agent हर session की शुरुआत में पढ़ता है।
• Skills (SKILL.md) — एक saved, reusable instruction जिसे agent सिर्फ़ तभी load करता है जब काम उससे match करे।
• Subagents — अपनी अलग context window वाला एक अलग helper जो एक काम करता है और सिर्फ़ result वापस सौंप देता है।
• Connectors / MCP — किसी agent को बाहरी tools से जोड़ने का standard तरीका: GitHub, Slack, एक database।
• Context management — conversation को हल्का रखें; जैसे-जैसे यह भरती है, model कमज़ोर होता है और cost बढ़ती है।

अगर इनमें से कोई भी नया है, तो पहले agentic coding crash course करें — यह सीधे उसी के ऊपर बना है।

यह कहाँ से आया

2026 के मध्य में जो लोग ये tools बनाते हैं, उन्होंने इसे साफ़-साफ़ कह दिया। Boris Cherny, जिन्होंने Claude Code बनाया, ने इसे यूँ कहा: "मैं अब Claude को prompt नहीं करता। मेरे पास loops चल रहे हैं जो Claude को prompt करते हैं... मेरा काम loops लिखना है।" Peter Steinberger (OpenClaw) ने कहा "आपको ऐसे loops design करने चाहिए जो आपके agents को prompt करें।" फिर Addy Osmani ने इस pattern को नाम दिया और इसके हिस्से गिनाए। इनमें से कोई यह नहीं कहता कि काम आसान हो गया। वे कहते हैं कि कीमती skill shift हो गई। यही वह idea है जिस पर यह पूरा course बना है। (इस course के हर quote और claim का स्रोत आख़िर में Sources & further reading में दिया गया है।)

Mindset shift, एक तस्वीर में

यह course दो tools को साथ-साथ दिखाता है, ठीक उसी वजह से जैसे पिछला वाला: अगर कोई technique दोनों में काम करती है, तो यह एक असली skill है, किसी एक tool का trick नहीं। लेकिन यहाँ दोनों tools वाकई में अलग हैं, और यह अंतर खुद एक सबक है। Claude Code अब loop के हिस्सों को product के अंदर ship करता है। OpenCode आपको नीचे वाली layer देता है — एक worker जिसे आप operating system से start करते हैं। आप दोनों देखेंगे। आप यह भी देखेंगे कि loop का आकार एक ही है, भले ही wiring अलग हो।

June 2026 तक का हाल। दोनों tools तेज़ी से बदलते हैं, और Claude Code की कई loop features research preview में हैं। किसी भी session से पहले claude update या opencode upgrade चलाएँ। किसी limit या flag पर भरोसा करने से पहले live docs (code.claude.com/docs, opencode.ai/docs) देख लें।

पहले, एक ईमानदार बात — loops कहाँ चल सकते हैं

एक असली loop unattended होता है: यह खुद को, अपने आप, तब prompt करता है जब आप दूर होते हैं। यह सादे claude.ai chat box में नहीं हो सकता, जो हमेशा आपका इंतज़ार करता है — chat में, आप ही schedule होते हैं। एक सच्चा loop चलाने के लिए आपको एक ऐसा tool चाहिए जो timer पर खुद act कर सके: Claude Code, OpenCode, या Cowork (Cowork crash course देखें)। इनमें से ज़्यादातर paid features हैं, और कई आज research previews हैं। आप एक loop को कहीं भी सीख और design कर सकते हैं। इसे unattended चलाने के लिए, आपको उन tools में से एक चाहिए। यह course उन दो coding वाले tools को दिखाता है।

"लेकिन मैंने पूरा Spec-Driven course claude.ai में किया — क्या मैं वहाँ भी loop चला सकता हूँ?"

जायज़ सवाल, क्योंकि "claude.ai" दरअसल दो चीज़ें हैं। छोटा जवाब: chat box एक loop नहीं चला सकता, लेकिन Claude Code — जो उसी claude.ai account में रहता है — चला सकता है।

• Chat conversation हर turn आपका इंतज़ार करती है और इसके पास किसी schedule या event पर fire करने का कोई तरीका नहीं है। आप इसे हाथ से बार-बार re-prompt कर सकते हैं, लेकिन तब आप ही heartbeat हैं — ठीक वही काम जो एक loop हटा देता है।
• Claude Code उसी login से पहुँच में है। इसके cloud Routines (claude.ai/code/routines पर बनाए जाते हैं) Anthropic के servers पर चलते हैं, भले आपका laptop बंद हो, locally कुछ भी install किए बिना — तो उस मायने में आप claude.ai से एक असली, unattended loop खड़ा कर सकते हैं। इसके लिए एक paid plan चाहिए और यह आज एक research preview है।
• OpenCode यही काम आपके अपने scheduler (cron, GitHub Actions) के साथ करता है।

तो chat वह जगह है जहाँ आप एक loop को design और rehearse करते हैं — skill draft करें, reviewer prompt लिखें, stopping condition pin करें, एक beat हाथ से चलाएँ — और Claude Code या OpenCode वह जगह है जहाँ आप इसे चलाते हैं। वह hand-off Spec-Driven Development के बाद का स्वाभाविक अगला कदम है।

पढ़ते-पढ़ते try करें

यहाँ से आगे, लगभग हर concept कुछ ऐसा है जिसे आप एक असली session में चला सकते हैं, सिर्फ़ पढ़ नहीं सकते। इस page के साथ एक terminal खुला रखें (claude या opencode) और हर idea तक पहुँचते ही उसे try करें। एक छोटे, throwaway git repo से शुरू करें ताकि एक loop किसी ऐसी चीज़ को नुकसान न पहुँचा सके जिसकी आपको परवाह है।

यह course क्या cover करता है​

Part	Topic	आप क्या सीखते हैं
1	The Shift	एक loop क्या है, इसके छह हिस्से, और इसे बनाने के दो रास्ते
2	The Heartbeat	किसी चीज़ को खुद चलाना: in-session, run-until-done, scheduled, event-driven
3	The Body	Isolation, knowledge, action, और maker–checker split
4	The Spine	वह state जो runs के बीच बची रहती है — वह एक हिस्सा जिसे लोग भूल जाते हैं
5	A Loop, Twice	एक पूरा morning-triage-to-PR loop, असली files के साथ, दोनों tools में बना
6	Staying the Engineer	Token cost, काम जाँचना, और वे traps जो loops के बेहतर होते ही बढ़ते हैं
Practice	Practice projects	पाँच loops, आसान से कठिन, जो आप खुद बनाते हैं

करके सीखें? पहले Part 5 पढ़ें ताकि एक पूरा loop शुरू से आख़िर तक देख सकें, फिर हिस्सों के लिए वापस आएँ। जब concepts समझ में आ जाएँ, तो Practice projects आपको पाँच loops देते हैं जो आप खुद बनाते हैं।

इसे पढ़ने के लिए लगभग दो घंटे रखें। Part 5 और practice projects बनाने में और समय लगता है — यही तो बात है: आप loops बना रहे हैं, उन्हें skim नहीं कर रहे।

क्या रखें, और क्या देखकर पता करें

इस course में दो layers चलती हैं, और वे बहुत अलग ढंग से पुरानी होती हैं। पहली को internalize करें; दूसरी को देखकर पता करें।

• Durable layer। एक loop का आकार (एक heartbeat, चार working parts, और एक spine), maker–checker split, और दो छोर जिन्हें एक loop कभी automate नहीं कर सकता: intent (इतनी सटीकता से कहना कि आप क्या चाहते हैं कि result जाँचा जा सके) और accountability (जो ship होता है उसका मालिक होना)। यही skill है। नीचे की हर command बदल जाने के बाद भी यह सच रहती है।
• Mechanical layer। हर flag, path, model ID, और command name। ये tools हर हफ़्ते updates ship करते हैं और यहाँ की कई features research previews हैं, इसलिए हर specific command को एक pointer मानें जो live docs की ओर इशारा करता है, याद रखने का fact नहीं। जहाँ यह course और मौजूदा docs आपस में असहमत हों, वहाँ docs जीतते हैं।

छह-हिस्सों वाला आकार याद रखें और हर keystroke भूल जाएँ, तो आपने loop engineering सीख ली। Keystrokes रट लें और आकार चूक जाएँ, तो आपने इस महीने की CLI सीखी।

---

📚 Teaching Aid​

Open Full Slideshow

View Full Presentation — Loop Engineering: A Crash Course

---

Part 1: The Shift​

1. Prompting से looping तक​

लगभग दो साल तक, किसी coding agent से काम लेने का तरीका सीधा था। एक अच्छा prompt लिखें। इसे पर्याप्त context दें। जो वापस आए उसे पढ़ें। अगली बात type करें। Agent एक tool था, और आप इसे एक-एक turn करके इस्तेमाल करते थे।

एक loop आपको, operator को, एक system से बदल देता है। यह system काम ढूँढता है, उसे बाँटता है, जाँचता है, लिख लेता है कि उसने क्या किया, और तय करता है कि आगे क्या है। यह agent को prompt करता है, ताकि आपको न करना पड़े।

तो value कहाँ जाती है? कहीं नहीं जाती। यह दो छोरों में बँट जाती है जिन्हें एक loop automate नहीं कर सकता: intent — सटीकता से कहना कि आप क्या चाहते हैं, इतनी साफ़ी से कि result जाँचा जा सके — और accountability — जो निकले उसके पीछे खड़े रहना। Loop बीच का हिस्सा, steps, automate करता है; छोर आपके पास रहते हैं। आपको intent और judgment के लिए पैसे मिलते हैं, इसके लिए नहीं कि काम कैसे बना यह नज़रअंदाज़ करें।

अंतर "एक बड़ा prompt" नहीं है। यह काम का एक अलग आकार है:

Prompting (जो आप जानते हैं)	Looping (यह course जो जोड़ता है)
हर turn आप शुरू करते हैं	हर turn एक schedule या event शुरू करता है
आप output पढ़कर तय करते हैं कि आगे क्या है	एक checker output जाँचता है; loop तय करता है कि आगे क्या है
जैसे ही आप type करना बंद करें, रुक जाता है	जब आप सोते हैं तब भी चलता रहता है
एक task, एक session, आपका पूरा ध्यान	कई छोटे runs, ज़्यादातर unattended, आपका ध्यान सिर्फ़ gate पर

यह जादू नहीं है, और यह "set it and forget it" भी नहीं है। एक loop जो खुद चलता है, वह एक ऐसा loop भी है जो खुद गलतियाँ करता है। इस course में सब कुछ एक ऐसा loop बनाने के लिए है जिस पर आप वाकई बिना अपने भरोसा कर सकें कि वह आपके बिना चले। यह prompting से कठिन है, आसान नहीं। इनाम है leverage: एक अच्छा loop आपके लिए वही काम बार-बार करता है, वह काम जो वरना आपको हर एक बार हाथ से शुरू करना पड़ता।

2. एक loop किन चीज़ों से बना है​

एक loop जो वाकई खुद चलता है, उसके पाँच हिस्से और एक spine होते हैं। पाँच में से चार से आप agentic coding course में मिल चुके हैं। यहाँ वे एक नया काम संभालते हैं।

1. Heartbeat — एक schedule (या एक event) जो loop को शुरू करता है। इसके बिना, आपके पास एक single run है, loop नहीं।
2. Worktree — isolation, ताकि एक साथ काम करते दो agents एक-दूसरे की files overwrite न करें।
3. Skill — आपका project knowledge एक बार लिख दिया गया, ताकि हर run शून्य से शुरू न हो।
4. Sub-agents — maker–checker split: जो agent code लिखता है वह वह agent नहीं है जो उसे grade करता है।
5. Connector (MCP) — ताकि loop आपके असली tools में act कर सके (एक PR खोले, एक ticket update करे), सिर्फ़ सुझाव न दे।

और छठा, जो beginners छोड़ देते हैं:

6. State / Memory — spine। Disk पर एक file (या Linear जैसा board) जो रखती है कि क्या हो चुका और क्या आगे है। Model runs के बीच सब कुछ भूल जाता है। Spine वह तरीका है जिससे आज का run जानता है कि कल के run ने क्या किया। No spine, no loop — बस वही पहला step, हमेशा के लिए दोहराता हुआ।

बाक़ी का course हर हिस्से के लिए एक section है, फिर एक पूरा example जो इन्हें जोड़ता है।

3. दो रास्ते: ships-the-parts बनाम the-layer-below

यही वह एक जगह है जहाँ tools वाकई अलग होते हैं, और यह आगे आने वाली हर चीज़ को आकार देता है।

Claude Code loop के हिस्सों को product के अंदर ship करता है। Heartbeat (/loop, /schedule, cloud Routines), built-in checker के साथ run-until-done (/goal), isolation (--worktree), event intake (Channels) — ये अब सब built-in commands हैं। एक साल पहले आपको यह पाने के लिए shell scripts का ढेर लिखना और उसकी देखभाल करनी पड़ती। आज आप ज़्यादातर बस इसे set up करते हैं।

मुख्य वाला है Routines: cloud automations जो Anthropic के servers पर चलते हैं भले आपका laptop बंद हो, एक schedule, एक API call, या एक GitHub event से शुरू। उस आसानी की कीमत है per-account daily run caps (एक तय number पर भरोसा करने के बजाय अपनी मौजूदा limit Routines usage UI में देखें), साथ ही यह कि Routines एक research preview है जो अभी भी बदल सकती है।

OpenCode आपको नीचे वाली layer देता है। कोई built-in cloud scheduler नहीं है। इसके बजाय, OpenCode वह worker है जिसे आप call करते हैं, और आप heartbeat लाते हैं — operating system से या CI से।

मुख्य command है opencode run "<prompt>"। यह chat screen के बिना एक prompt चलाता है, result print करता है, और exit हो जाता है। वह एक command एक loop का एक beat है। आप इसे एक ऐसी चीज़ में लपेटकर loop बनाते हैं जो timer पर fire करे: cron या launchd (macOS और Linux), Task Scheduler (Windows), या schedule trigger के साथ GitHub Actions। यह ज़्यादा wiring है, लेकिन आपको पूरा control मिलता है, यह उन machines पर चलता है जो पहले से आपके पास हैं, और इसे किसी vendor cloud की ज़रूरत नहीं।

Skill loop है, keybind नहीं

ध्यान दें कि दोनों tabs एक ही पाँच हिस्सों का वर्णन करते हैं। Heartbeat heartbeat है, चाहे यह एक managed Routine हो या cron में एक line। Maker–checker split एक ही idea है, चाहे /goal इसे grade करे या एक दूसरा opencode run। Loop का आकार एक बार सीख लें और यह transfer हो जाता है। इसीलिए हम दोनों सिखाते हैं।

हम कहाँ जा रहे हैं (पूरा loop, जल्दी)

हिस्सों से पहले, यहाँ finish line है। जो loop आप Part 5 में बनाएँगे, वह छह सादे steps है:

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

इस तस्वीर को ध्यान में रखें। Parts 2–4 का हर concept इसकी एक line है।

खुद को जाँचें

एक loop हर सुबह चलता है, लेकिन हर run नए सिरे से शुरू होता है और कभी याद नहीं रखता कि उसने कल क्या किया। छह हिस्सों में से कौन सा गायब है — और यह loop को क्यों तोड़ता है?

जवाब दिखाएँ

Spine (state / memory)। Model runs के बीच सब कुछ भूल जाता है, इसलिए disk पर बिना किसी state file के loop बस अपना पहला step हमेशा के लिए दोहराता है, कल के काम पर आगे बढ़ने के बजाय।

---

Part 2: The Heartbeat​

Heartbeat वह है जो एक run को एक loop में बदलता है। चार किस्में हैं, "इसी session में रहती है" से लेकर "आपके बिना बिल्कुल चलती है" तक। इन्हें क्रम में सीखें — ज़्यादातर असली loops आख़िरी दो इस्तेमाल करते हैं।

4. In-session loops (जब तक आप देखें, दोहराएँ)

सबसे सरल heartbeat: एक prompt को timer पर जब तक session खुला है फिर से चलाएँ। "इसे खत्म होने तक देखो" के लिए अच्छा — एक deploy, एक लंबा test run, एक CI job।

bundled /loop skill इस्तेमाल करें। इसे एक interval और एक prompt दें:

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

Claude interval को एक schedule में बदल देता है, job को एक ID देता है, और जब तक session खुला रहता है हर 5 minute prompt चलाता है। जब आप कर लें, इसे cancel करें और आगे बढ़ें।

जानने लायक एक limit: /loop जानबूझकर session के अंदर रहता है। terminal बंद करें, या laptop को sleep होने दें, और यह रुक जाता है। यह एक safety feature है, bug नहीं — एक casual in-session loop को session से ज़्यादा जीना नहीं चाहिए। ऐसी किसी चीज़ के लिए जो चलती रहे, एक scheduled task या एक Routine इस्तेमाल करें (Concept 6)।

OpenCode में कोई /loop command नहीं है। आप timer खुद shell से बनाते हैं। चूँकि opencode run एक prompt के बाद exit हो जाता है, एक sleep वाला while loop वही काम करता है:

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

यह /loop जैसा ही idea है, एक layer नीचे: shell heartbeat है, और opencode run beat है। हर fresh opencode run पहले पूरा runtime boot करता है — config, model, plugins, और कोई भी MCP servers — कुछ भी करने से पहले। हर beat पर यह start-up cost चुकाने से बचने के लिए, एक बार एक server start करें और उससे attach करें:

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

5. Run-until-done (loop तय करता है कब रुकना है)

एक fixed-timer loop जानबूझकर सरल है — यह N बार fire करता है चाहे कुछ भी हो। अक्सर जो आप वाकई चाहते हैं वह है "जब तक यह सच न हो, चलते रहो।" यहीं maker–checker idea पहली बार सामने आता है: loop को उस agent को यह तय नहीं करने देना चाहिए कि काम हुआ या नहीं, जिसने काम किया।

/goal इस्तेमाल करें। आप इसे एक stopping condition देते हैं जिसे Claude अपने ही output में prove कर सके — कुछ ऐसा जो वह एक command चलाकर और result सामने लाकर दिखाता है, जैसे "test/auth के सारे tests pass हों।" यह उस condition के सच होने तक turns में काम करता रहता है। ज़रूरी बात: हर turn के बाद एक अलग, छोटा model (default रूप से Haiku) transcript पढ़ता है और तय करता है "क्या हम done हैं?" तो जिस agent ने code लिखा वह वह agent नहीं है जो उसे grade कर रहा है। जानने लायक एक बारीकी: वह checker खुद commands नहीं चलाता — यह उसी को judge करता है जो Claude पहले ही सामने ला चुका है — इसलिए condition कुछ ऐसी होनी चाहिए जो Claude का अपना output दिखा सके, कोई निजी fact नहीं जो सिर्फ़ एक command बता सके।

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

यह edit करेगा, tests चलाएगा, failures पढ़ेगा, फिर कोशिश करेगा, और तभी रुकेगा जब checker पुष्टि करे कि condition वाकई पूरी हुई — या जब आप इसे खुद /goal clear से रोकें। कोई built-in "N कोशिशों के बाद हार मानो" नहीं है: अगर आपको एक ceiling चाहिए, तो इसे condition में लिखें (…or stop after 20 turns)। ऐसी conditions लिखें जिन्हें एक command prove कर सके — "tests pass और lint clean," न कि "auth code अच्छा है।" यहीं Spec-Driven Development का spec काम आता है: इसके acceptance criteria पहले से ऐसी conditions हैं जिन्हें एक command prove कर सकता है, तो एक अच्छा spec आपको stopping condition मुफ़्त में दे देता है।

OpenCode में कोई /goal नहीं है, तो आप वही maker–checker stop shell और exit codes से बनाते हैं। Pattern: agent काम करता है, फिर एक असली command (agent नहीं) तय करती है कि रुकना है या नहीं।

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

यहाँ test runner और linter checker हैं — सबसे ईमानदार checker जो हो सकता है, क्योंकि एक command खुद को यह यक़ीन नहीं दिला सकती कि काम ठीक है। एक smarter check के लिए, एक dedicated review agent (Concept 11) के साथ एक दूसरा opencode run चलाएँ और उससे PASS या FAIL print करवाएँ। हमेशा tries cap करें; बिना limit के retry करने वाला loop ही वह तरीका है जिससे token bills बेकाबू होती हैं।

एक loop को हमेशा रुकने का रास्ता दें

दो stops, हमेशा: एक success condition (काम हो गया) और एक ceiling (max tries, max minutes, या max spend)। एक loop जिसमें success condition है पर ceiling नहीं, वह आपका पूरा token budget एक ऐसा goal पाने में खर्च कर देगा जिसे यह कभी पूरा नहीं कर सकता।

6. Unattended schedules (जब आप सोते हैं तब चलता है)​

यही वह heartbeat है जो loop engineering को मायने देता है: एक task जो चलता है चाहे आप computer पर हों या नहीं। "हर weekday सुबह 9 बजे, रात भर की CI failures को छाँटो।" "हर सोमवार, dependencies जाँचो और safe fixes के साथ एक PR खोलो।"

दो किस्में, इस पर निर्भर कि आपका laptop on चाहिए या नहीं:

Cloud Routines (laptop off हो सकता है)। आधुनिक default। एक claude.ai/code/routines पर, Desktop app में, या CLI में /schedule से बनाएँ — तीनों एक ही cloud account में लिखते हैं। एक routine एक prompt, वे repos जिन्हें यह छू सकता है, इसके connectors, और एक trigger (schedule, API, या GitHub event) को bundle करता है, फिर Anthropic के servers पर चलता है। per-account daily run caps का ध्यान रखें, और यह कि default रूप से एक routine सिर्फ़ उन branches को push कर सकता है जो claude/ से शुरू होती हैं — एक जानबूझकर guardrail जिसे आप Allow unrestricted branch pushes setting से per-repository हटा सकते हैं।

अपने cron में headless one-shot (laptop on, कोई Anthropic cloud नहीं)। claude -p एक prompt चलाता है और exit हो जाता है — इसे सीधे crontab में डालें:

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

पूरे treatment के लिए, किताब का Scheduled Tasks: The Loop Skill and Cron Tools देखें।

OpenCode का unattended heartbeat हमेशा OS या CI होता है — यही OpenCode का रास्ता है। opencode run को chat screen के बिना इस्तेमाल करें, और scheduler को इसे fire करने दें।

आपकी अपनी machine, cron के साथ:

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

Cloud, GitHub Actions के साथ (आपकी कोई machine on होने की ज़रूरत नहीं)। नीचे की model string उदाहरण भर है — आपके install को पता exact IDs के लिए opencode models चलाएँ:

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

Scheduled events के लिए prompt ज़रूरी है (इसे पढ़ने के लिए कोई comment नहीं होता), और अगर loop को branches या PRs खोलने हैं तो आपको contents: write / pull-requests: write देना होगा।

ऊपर के action और model names पर एक नोट

OpenCode GitHub Action को मौजूदा official docs में anomalyco/opencode/github@latest के रूप में refer किया जाता है; कुछ पुराने guides अब भी sst/opencode/github@latest दिखाते हैं। दोनों एक ही project की ओर इशारा करते हैं — वही इस्तेमाल करें जो आपका opencode github install generate करता है। Models के लिए, anthropic/claude-sonnet-4-6 मौजूदा Sonnet ID है। Dateless IDs 4.6 generation के साथ आए, जहाँ dateless string ही pinned snapshot है; पुराने 4.5-generation models जैसे Haiku 4.5 एक dated canonical ID (claude-haiku-4-5-20251001) रखते हैं साथ ही एक dateless claude-haiku-4-5 alias जो latest snapshot की ओर इशारा करता है। नीचे के examples reproducibility के लिए dated Haiku ID pin करते हैं। अपने install को पता exact strings देखने के लिए opencode models चलाएँ।

7. Event-driven (कुछ होने पर react करें)​

एक schedule पूछता है "हर घंटे check करो।" एक event पूछता है "जिस पल X हो, react करो।" एक PR खुलता है, एक issue file होता है, एक message आता है — और loop जवाब में चलता है।

दो रास्ते। Routines एक GitHub webhook trigger स्वीकार करते हैं, तो एक routine एक push या एक नए PR पर चल सकता है, सिर्फ़ एक clock पर नहीं। Chat-style events के लिए, Channels बाहरी sources (Telegram, Discord, और iMessage built-in हैं; एक webhook receiver वह है जिसे आप खुद wire करते हैं) से messages सीधे एक चलते session में push करते हैं — scheduling का event-driven साथी। code.claude.com/docs/en/channels देखें।

GitHub agent को एक बार opencode github install से install करें, जो .github/workflows/opencode.yml जोड़ता है। उसके बाद, OpenCode repository events पर react करता है — pull_request, issues, और /oc या /opencode comments — आपके GitHub Actions runners के अंदर चलते हुए:

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

बिना prompt वाले एक pull_request event के लिए, OpenCode default रूप से PR review करता है।

खुद को जाँचें

आप चाहते हैं कि एक loop एक failing test को pass होने तक fix करता रहे, फिर खुद रुक जाए। आप कौन सा heartbeat चुनते हैं, और "done" कौन तय करता है?

जवाब दिखाएँ

Run-until-done — Claude Code में /goal, या OpenCode में एक capped shell loop। एक command (test runner) "done" तय करती है, कभी वह agent नहीं जिसने fix लिखा — और इसे फिर भी एक ceiling चाहिए ताकि यह हमेशा retry न करता रहे।

---

Part 3: The Body​

Heartbeat loop को शुरू करता है। ये चार हिस्से वह हैं जो loop हर beat पर करता है। आप इनसे agentic coding course में handy extras के रूप में मिले थे। एक loop में ये वाकई मायने रखते हैं, क्योंकि हर step को कोई इंसान नहीं देख रहा।

8. Isolation: worktrees​

जिस पल एक loop एक साथ एक से ज़्यादा agent चलाता है, वे एक-दूसरे की files overwrite करने लगते हैं — ठीक उन दो लोगों की तरह जो एक-दूसरे को बताए बिना एक ही lines edit कर रहे हों। एक git worktree इसे ठीक करता है: एक अलग working folder, अपनी branch पर, जो वही repo history share करता है। एक agent के edits दूसरे के checkout को छू नहीं सकते।

Built in। एक session को उसके अपने checkout में खोलने के लिए --worktree flag इस्तेमाल करें, या एक subagent पर isolation: worktree set करें ताकि हर helper को एक fresh checkout मिले जो बाद में खुद को clean कर ले। एक scheduled task per run worktree isolation on कर सकता है, ताकि parallel runs कभी आपके अपने manual काम से न टकराएँ।

कोई single flag नहीं। आप git के अपने worktrees इस्तेमाल करते हैं और हर एक पर एक run point करते हैं। वही isolation, साफ़-साफ़ बनाया गया:

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

Community runners (OpenCode के इर्द-गिर्द बने worktree managers) आपके लिए bookkeeping संभाल सकते हैं अगर आप यह अक्सर करते हैं।

9. Knowledge: skills, ताकि कोई run "day one" न हो​

एक loop हर बार cold चलता है — एक fresh session जिसे आपके project की आदतों की कोई memory नहीं। बिना किसी मदद के, यह हर beat पर आपका पूरा setup काम लगाकर निकालता (या अनुमान लगाता) है, tokens बर्बाद करता और गलतियों को न्योता देता हुआ। एक skill वही knowledge है जो एक बार लिख दिया गया, एक SKILL.md file में, जहाँ agent इसे हर run पढ़ता है।

यह दोनों tools में एक ही तरह काम करता है: instructions और metadata वाली एक SKILL.md के साथ एक folder, साथ ही optional scripts और references। एक loop में, नियम सीधा है: जो भी आपको हर run पर दोबारा समझाना पड़ता, वह एक skill में जाता है। Triage steps, project habits, "हम इसे इस तरह उस एक incident की वजह से नहीं करते" — यह सब skill में रहता है, ताकि loop नए सिरे से शुरू करने के बजाय खुद पर आगे बढ़े। (पूरा treatment Skills & Connectors crash course में।)

एक skill loop prompts को छोटा रखता है

एक schedule में instructions की दीवार paste करने के बजाय जिसे कोई update नहीं रखेगा, आपका scheduled prompt एक line बन जाता है — "daily-triage skill चलाओ" — और skill detail रखता है। छोटा loop prompt, update करने में आसान logic, हर beat पर कम token cost।

10. Action: connectors (loop act करता है, सिर्फ़ सुझाव नहीं देता)​

एक loop जो सिर्फ़ आपकी files पढ़ सकता है, वह एक ऐसा loop है जो सिर्फ़ बात कर सकता है। Connectors — MCP पर बने — इसे करने देते हैं: एक PR खोलना, एक Linear ticket update करना, Slack पर post करना, एक database query करना, एक staging API call करना। यही अंतर है एक ऐसे loop में जो कहता है "यह रहा fix" और एक ऐसे में जो PR खोलता है, ticket link करता है, और CI green होते ही channel पर post करता है।

दोनों tools MCP बोलते हैं, तो protocol उनके बीच transfer होता है — लेकिन packaging और authentication (local बनाम hosted, OAuth, permissions) को अक्सर tool-specific wiring की ज़रूरत होती है।

अपने config में MCP servers जोड़ें और उन्हें एक routine की connector list में शामिल करें, ताकि unattended run उन तक पहुँच सके। वही connectors जो आप हाथ से इस्तेमाल करते हैं, scheduled और cloud runs के लिए उपलब्ध हैं।

opencode.json के mcp section में servers declare करें — local servers एक subprocess start करते हैं, remote servers automatic OAuth के साथ एक HTTPS endpoint तक पहुँचते हैं। एक scheduled opencode run में, एक बार opencode serve start करें और इससे --attach करें, ताकि आप हर beat पर MCP start-up cost न चुकाएँ।

11. Maker–checker: sub-agents​

एक loop में सबसे ज़रूरी choice: जो agent काम लिखता है, वह वह agent नहीं होना चाहिए जो उसे approve करता है। एक model अपने ही output को grade करते हुए खुद पर बहुत आसान होता है। एक दूसरा agent — अलग instructions, अक्सर एक अलग (कभी-कभी ज़्यादा मज़बूत) model — वह पकड़ता है जो पहले से छूट गया क्योंकि वह यक़ीन में था कि वह सही है। यही एकमात्र वजह है जिससे आप एक चलते loop को अकेला छोड़ सकते हैं।

.claude/agents/ में subagents define करें, और उन्हें agent teams के रूप में जोड़ें: एक explore करता है, एक implement करता है, एक spec और tests के against check करता है। "Spec" वही है जिसे आपने Spec-Driven Development में लिखना सीखा: इसके acceptance criteria ठीक वही हैं जिनके against एक भरोसेमंद checker grade करता है — एक vague spec आपको एक vague verdict देता है। यही /goal अंदर भी करता है: एक fresh model तय करता है कि loop done है या नहीं, worker के खुद को grade करने के बजाय।

OpenCode built-in primary agents (Build, Plan) और एक built-in general subagent ship करता है (साथ ही explore, और मौजूदा versions में एक experimental flag के पीछे scout)। आप अपने खुद के opencode.json में या अपने agents folder में markdown files के रूप में define कर सकते हैं। Checker को उसका अपना (अक्सर सस्ता, read-only) model दें, और maker को इसे एक @ mention या Task tool से call करवाएँ। एक आम split: एक मज़बूत model explore और implement करता है, एक focused model check करता है।

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

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

Sub-agents की cost ज़्यादा है — इन्हें वहाँ खर्चें जहाँ मायने रखे

हर sub-agent अपना model और tools चलाता है, तो maker–checker split वाकई ज़्यादा tokens खर्च करता है। यही एक ऐसे checker की कीमत है जिस पर आप भरोसा कर सकें। इसे वहाँ खर्चें जहाँ एक दूसरी राय मायने रखे (जो भी loop आपके दूर रहते commit करेगा); throwaway, read-only कामों के लिए इसे छोड़ दें।

11b. Body को codify करें: dynamic workflows​

अब तक, एक beat का body — काम ढूँढना, हर fix को उसके अपने checkout में draft करना, एक अलग agent से उसे grade करवाना — कुछ ऐसा है जिसे agent turn-by-turn assemble करता है। Claude Code अब आपको उस पूरी orchestration को एक rerunnable script के रूप में codify करने देता है, जिसे dynamic workflow कहते हैं: आप task describe करते हैं, Claude एक script लिखता है जो काम को कई sub-agents में fan out करता है, और एक runtime इसे background में execute करता है जबकि आपका session free रहता है। यह maker–checker split (Concept 11) और worktree split (Concept 8) को एक repeatable unit में पैक करता है — और यह एक असली quality pattern लागू कर सकता है, सिर्फ़ ज़्यादा agents नहीं चला सकता: independent reviewers कुछ भी report होने से पहले एक-दूसरे की findings को adversarially check कर सकते हैं।

इसे सादे शब्दों में माँगें ("एक workflow इस्तेमाल करके…"), इसे ultracode keyword से trigger करें, या bundled /deep-research चलाएँ। जब एक run वह करे जो आप चाहते हैं, /workflows view में s दबाकर इसके script को एक /command के रूप में save करें जिसे आप हर branch पर rerun कर सकें। दो limits इसे ईमानदार रखती हैं: agents capped हैं (एक साथ लगभग 16, per run 1000) ताकि एक runaway script बेकाबू न हो, और एक run की memory सिर्फ़ उसी run के अंदर रहती है — आप इसे उसी session में resume कर सकते हैं, लेकिन एक fresh session इसे फिर से शुरू कर देता है।

कोई /workflows command नहीं है। जो script आप पहले से लिखते हैं वह ही workflow है: Concept 5 का capped for loop और Concept 8 का &/wait fan-out उसी idea का एक hand-rolled version हैं — आपका shell plan रखता है, opencode run हर agent है, और exit codes checker हैं। आपको पूरा control और कोई agent cap नहीं मिलता, इस कीमत पर कि orchestration आप खुद लिखें और maintain करें।

एक workflow एक beat का body है — loop नहीं

यह वह सबसे आसान गलती है जो workflows के powerful लगने लगते ही होती है। एक dynamic workflow एक बार चलता है, जब आप (या ultracode setting) इसे शुरू करते हैं, और खत्म होते ही सब कुछ भूल जाता है। इसके पास कोई heartbeat और कोई spine नहीं। तो यह एक single beat का body है, loop नहीं। Loop composition है: एक heartbeat (एक Routine, /loop, या cron) beat को fire करता है, workflow वह body है जो उस पर चलता है, और इसके agents जो एक progress file लिखते हैं वह spine है जिसे अगली firing पढ़ती है। Workflow engine है; Routine वह है जो चाबी घुमाता है, और progress.md वह fuel है जो trips के बीच बचा रहता है।

---

Part 4: The Spine​

12. वह state जो runs के बीच बची रहती है​

यह रहा वह हिस्सा जिसे beginners छोड़ देते हैं, और यही वह है जो एक loop को loop बनाता है। Model runs के बीच सब कुछ भूल जाता है। अगर हर beat शून्य से शुरू होता है, तो आपके पास loop नहीं है — आपके पास वही पहला step है, हमेशा के लिए दोहराता हुआ। Fix उबाऊ और शक्तिशाली है: state को model के बाहर, disk पर रखें।

State की दो layers, साथ काम करती हुई:

• Rules file (CLAUDE.md / AGENTS.md) — वे steady आदतें जो loop हर run पढ़ता है। (इसे छोटा रखें; क्यों, यह आपने पिछले course में सीखा। एक भारी rules file की कीमत हर एक beat पर चुकाई जाती है।)
• एक progress file — एक plain markdown file (या MCP के ज़रिए एक Linear board) जो record करती है क्या try किया गया, क्या pass हुआ, क्या अभी open है। यही असली spine है। कल का 9am run इसे खोलता है और वहीं से उठा लेता है जहाँ आज का run रुका था।

आदत: हर run शुरुआत में progress file पढ़ता है और अंत में इसे update करता है। जब loop वही गलती बार-बार करता है, तो fix एक ज़्यादा clever prompt नहीं है — यह है loop से वह सबक rules file में लिखवाना, ताकि fix हर भविष्य के run के लिए बना रहे।

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

## Done

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

## In progress

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

## Open / needs a human

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

Spine आपका record भी है

चूँकि progress file आपके repo में सिर्फ़ text है, यह उसका record भी बन जाती है कि loop ने आपके दूर रहते क्या किया। जब आप human gate पर बैठते हैं, तो आप spine पढ़ते हैं — हर run का पूरा transcript नहीं।

खुद को जाँचें

एक loop को अब तक जो किया है वह कहाँ रखना चाहिए, और conversation में क्यों नहीं?

जवाब दिखाएँ

Disk पर — एक progress file (साथ ही rules file), या Linear जैसा board। Model की memory runs के बीच मिट जाती है, इसलिए जो भी बचा रहना चाहिए वह model के बाहर रहता है। Repo याद रखता है; model नहीं।

---

Part 5: A Complete Loop, Twice​

Minimum safe loop checklist

इससे पहले कि आप किसी loop को खुद चलने दें, इसे इन सातों की ज़रूरत है। जो loop आप बनाने वाले हैं उसमें हर एक है:

• Success condition — यह कैसे जानता है कि काम हो गया (Concept 5)।
• Ceiling — max tries, minutes, या spend, ताकि यह हमेशा न चले (Concept 13)।
• Isolated branch या worktree — ताकि parallel काम न टकराए (Concept 8)।
• Read-only checker — एक अलग agent जो grade करता है पर edit नहीं कर सकता (Concept 11)।
• State file — spine, ताकि यह runs के बीच याद रखे (Concept 12)।
• Human gate — जोखिम भरा या failed काम किसी इंसान के पास जाता है, कभी सीधे main पर नहीं (Part 5)।
• एक log या notification — ताकि रात भर की कोई failure दिखे, चुपचाप न रहे (Part 6)।

एक भी चूकें और loop unsafe, भुलक्कड़, या invisible है।

अब हिस्सों को जोड़ें। यह रहा एक loop — एक morning maintenance loop जो रात भर की CI failures को छाँटता है, safe fixes draft करता है, उन्हें check करवाता है, safe वालों के लिए PRs खोलता है, और बाक़ी को flag करता है — हर tool में एक बार बना। नीचे की files असली हैं; आप इन्हें एक repo में copy करके चला सकते हैं।

Loop का आकार (दोनों में एक ही):

1. Heartbeat: हर weekday सुबह 9 बजे।
2. Skill: एक daily-triage skill steps रखती है, ताकि prompt एक line रहे।
3. Spine: शुरुआत में progress.md पढ़ें, अंत में इसे update करें।
4. Worktree: हर fix उसके अपने checkout में draft किया जाता है।
5. Maker–checker: एक implementer draft करता है; एक अलग reviewer PASS या FAIL कहता है।
6. Connector: PASS के लिए एक PR खोलें; FAIL या किसी जोखिम भरी चीज़ के लिए, इसे "needs a human" में लिखें और रुक जाएँ।

Shared skill​

यह एक file दोनों tools में काम करती है। इसे .claude/skills/daily-triage/SKILL.md (Claude Code) या .opencode/skills/daily-triage/SKILL.md (OpenCode) के रूप में save करें।

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

# Daily triage

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

## 1. Read your memory first

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

## 2. Find the work

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

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

## 3. Work each candidate

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

## 4. Decide from the verdict

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

## 5. Update your memory last

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

## Rules

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

Reviewer (checker)​

Reviewer maker–checker split का practice में रूप है। आपको दोनों files चाहिए — यह कोई either/or tool choice नहीं है। Format हर tool में थोड़ा अलग है, तो हर एक नीचे पूरा दिखाया गया है।

Claude Code — .claude/agents/reviewer.md के रूप में save करें:

---
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 के रूप में save करें:

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

Heartbeat को wire करना​

claude.ai/code/routines पर एक weekday-9am schedule, अपने repo, और अपने GitHub + Slack connectors के साथ एक Routine बनाएँ। इसके prompt को skill पर point करें, ताकि routine definition छोटी रहे:

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 रखता है। .claude/agents/reviewer.md checker है। isolation: worktree parallel fixes को अलग रखता है। GitHub connector PRs खोलता है। चूँकि यह एक cloud Routine है, यह 9am पर चलता है चाहे आपका laptop खुला हो या नहीं — आपके plan की daily run cap के भीतर।

इसे एक GitHub Actions workflow के रूप में बनाएँ, ताकि यह cloud में चले बिना आपकी कोई machine जागे। Action heartbeat है; opencode run worker है; आपका repo skill, agents, और progress.md रखता है।

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

reviewer agent (एक सस्ते read-only model पर) checker है। नई branches CI में worktree isolation का काम करती हैं। OpenCode GitHub app PRs खोलता है। इसे GitHub की जगह अपनी machine पर चाहते हैं? ठीक वही prompt एक cron line से चलता है जो opencode run call करती है — सिर्फ़ heartbeat बदलता है।

एक असली सुबह कैसी दिखती है​

आपने ऊपर का सब कुछ एक बार design किया। यह रहा एक single run, जैसा आप उठकर देखते (नीचे का run आकार का एक उदाहरण है, recording नहीं):

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

देखें क्या हुआ। Loop ने काम ढूँढा, इसे draft किया, check किया, safe हिस्सा ship किया, और आपको सिर्फ़ वही एक decision सौंपा जिसके लिए एक इंसान चाहिए था। यही practice में loop engineering है। और ध्यान दें: दोनों tools के बीच एकमात्र असली अंतर था heartbeat और run कहाँ हुआ। बीच में सब कुछ — skill, spine, worktree, maker–checker, connector — वही design था।

खुद को जाँचें

Morning-triage loop में, क्या एक गलत fix को आपके सोते वक़्त merge होने से रोकता है?

जवाब दिखाएँ

तीन चीज़ें साथ में: reviewer subagent को PASS लौटाना होगा (maker–checker), सिर्फ़ low-risk changes एक PR खोल सकते हैं, और human gate किसी भी जोखिम भरी या failing चीज़ को main के बजाय एक "needs a human" note पर भेजता है। हर run capped और logged भी होता है।

---

Part 6: Staying the Engineer​

एक loop काम बदलता है; यह आपको काम से बाहर नहीं करता। तीन समस्याएँ आपके loops के बेहतर होने के साथ बड़ी होती हैं, छोटी नहीं। यह हिस्सा course में सबसे ज़रूरी है।

13. Token cost असली limit है, keybind नहीं​

यह, सबसे ज़्यादा, वह आम तरीका है जिससे loops गलत होते हैं। एक loop बार-बार चलता है, अक्सर sub-agents start करता है, और हर sub-agent अपना model और tools चलाता है। Cost लगभग किसी के अनुमान से तेज़ बढ़ती है। Fixes सरल हैं:

• हर loop को cap करें — max tries, max minutes, या max spend। हमेशा (Concept 5)।
• Model को काम से match करें — plan और check के लिए एक मज़बूत model, काम करने के लिए एक सस्ता। यह सबसे बड़ी एकल बचत है, और आप इसे पिछले course में सीख चुके हैं।
• Loop prompt और rules file छोटे रखें — आप इनके लिए हर beat पर भुगतान करते हैं। Detail को उन skills में धकेलें जो सिर्फ़ इस्तेमाल होने पर load होती हैं।
• इसे कम बार चलाएँ — हर पाँच minute के बजाय घंटे में एक बार आमतौर पर काफ़ी है, और लगभग बारह गुना सस्ता।

Numbers का एक त्वरित अंदाज़ा (उदाहरण भर)। मान लें एक beat — maker plus checker — लगभग 40k tokens पढ़ता और लगभग 6k लिखता है। Sonnet 4.6 के $3 / $15 प्रति million पर, यह मोटे तौर पर $0.20 प्रति beat है। एक 20-दिन के महीने में पाँच beats प्रति दिन लगभग $20 है — सस्ता। वही loop हर पाँच minute fire होते हुए सौ गुना से ज़्यादा beats है — आराम से $1,000 प्रति महीने के पार, बिना किसी अतिरिक्त value के। Cadence, keybind नहीं, वह जगह है जहाँ पैसा जाता है।

Model एक दूसरा lever है — OpenCode path पर। वे numbers Sonnet 4.6 मानते हैं। Claude Code के loop commands Claude चलाते हैं, लेकिन OpenCode आपको model चुनने देता है, और एक सस्ता model per-beat cost को बहुत दूर तक ले जाता है: DeepSeek V4 Flash (लगभग $0.14 / $0.28 प्रति million) उसी beat को मोटे तौर पर $0.007 — लगभग 30× सस्ता चलाता है — $20-प्रति-महीने वाले loop को एक डॉलर से काफ़ी कम में बदल देता है। दो ईमानदार caveats। पहला, सस्ता maker, भरोसेमंद checker: एक कमज़ोर model बदतर fixes लिखता है, तो यह ज़्यादा beats जला सकता है या review में ज़्यादा बार fail हो सकता है, और retries बचत खा जाती हैं — एक clear spec पर mechanical maker के लिए सस्ता model इस्तेमाल करें, और एक checker रखें जिस पर आप भरोसा करें (test runner और linter सबसे सस्ते, सबसे ईमानदार checker हैं)। दूसरा, cadence अब भी हावी है: एक 30×-सस्ता model हर पाँच minute fire होते हुए अब भी Sonnet के hourly चलने से ज़्यादा cost कर सकता है। Model bill को नीचे scale करता है; यह कितनी बार चलता और retry करता है, वह अब भी इसे तय करता है।

बिना spending limit वाला एक loop बहुत महँगा पड़ सकता है

आम failure हमेशा एक ही है: एक loop जो खुद चलता है, एक ऐसी stopping condition के साथ जिसे यह कभी पूरा नहीं कर सकता, पूरी रात retry करते हुए। इसे शुरू करने से पहले एक ceiling set करें। पहले कुछ असली runs देखें। फिर इसे खुद चलने दें।

14. काम जाँचना अब भी आपका काम है​

एक loop जो खुद चलता है, वह एक ऐसा loop है जो खुद गलतियाँ करता है। Maker–checker split loop के "हो गया" को कुछ मायने देता है — लेकिन "done" अब भी एक claim है, proof नहीं। आपका काम गायब नहीं हुआ; यह shift हुआ। आप अब हर step type नहीं करते, लेकिन आप अब भी वही हैं जो पुष्टि करता है कि loop ने ऐसा code ship किया जो वाकई काम करता है। उन diffs को पढ़ें जो loop ने खोले। काम करने के लिए loop पर भरोसा करें; काम के counted होने से पहले उसे जाँचें।

15. अपने खुद के project को समझना बंद न करें​

एक loop जितनी तेज़ी से ऐसा code ship करता है जो आपने नहीं लिखा, उतना ही चौड़ा वह gap होता है जो आपके project में है और जो आप वाकई समझते हैं, उसके बीच। वह gap एक असली cost है, और एक smooth loop इसे चुपचाप बढ़ाता है। इलाज और जाल एक ही काम हैं। Loop design करना आपको engaged रखता है जब आप इसे ध्यान से करते हैं — और आपको सोचना बंद करने देता है जब आप इसे काम से बचने के लिए करते हैं। एक ही काम, उल्टा नतीजा। Loop अंतर नहीं बता सकता। आप बता सकते हैं।

दो लोग बिल्कुल वही loop बना सकते हैं और उल्टे नतीजे पा सकते हैं। एक इसे उस काम पर तेज़ चलने के लिए इस्तेमाल करता है जिसे वह गहराई से समझता है। दूसरा इसे काम को बिल्कुल न समझने के लिए इस्तेमाल करता है। Loop बनाएँ। लेकिन इसे किसी ऐसे इंसान की तरह बनाएँ जो engineer बना रहने की योजना रखता है — सिर्फ़ वह इंसान नहीं जो go दबाता है।

और यही पूरे course की through-line है। हर साल tools loop की और ज़्यादा machinery सोख लेते हैं: orchestration, checker, और schedule अब built-in हैं (dynamic workflows, /goal, Routines) जहाँ एक साल पहले वे आपकी अपनी shell scripts थीं। Tools जो नहीं सोख सकते वे हैं दो छोर जिनसे आप Concept 1 में मिले — intent, इतनी सटीकता से specify किया गया कि जाँचा जा सके, और जो ship होता है उसके लिए accountability। इसीलिए यह engineering है, button-pushing नहीं, और यह skill का वह हिस्सा है जो सड़ता नहीं। Tools को मज़बूत होने दें और उन पर भरोसा करें; बस उन दोनों छोरों को अपने हाथ में रखें।

जब एक loop आपके सोते वक़्त fail होता है

एक unattended loop unattended ही fail भी होता है। इससे पहले कि आप किसी पर रात भर भरोसा करें, इसे observable बनाएँ:

• Output वहाँ भेजें जहाँ आप देखेंगे — एक log file, एक Slack या Discord message (Claude Code Channels), या Triage inbox। वह terminal नहीं जिसे आप पहले ही बंद कर चुके।
• हर run एक line लिखें, fail पर भी — हर beat progress.md (या एक log) में एक timestamped note append करता है: इसने क्या try किया, क्या pass हुआ, क्या टूटा। एक silent failure सबसे बुरी किस्म है।
• Runs को replayable रखें — OpenCode में, opencode run --format json, opencode export <id>, और opencode session list आपको पूरा record देते हैं। Claude Code में, एक Routine अपना run history web UI में रखता है।
• Ceiling पर ज़ोर से fail हों — जब loop अपनी cap पर पहुँचे या error करे, इसे एक साफ़ "needs a human" note छोड़ना चाहिए, बस रुकना नहीं।
• Nightly slot कमाएँ — इसे hourly और देखते हुए कुछ दिन चलाएँ इससे पहले कि आप इसे nightly और unattended चलने दें। जब कुछ गलत लगे, पहले spine पढ़ें; यह बताता है कि आख़िरी अच्छे run ने क्या किया।

एक loop जिसे आप debug नहीं कर सकते, वह एक loop है जिस पर आप भरोसा नहीं कर सकते।

---

🚀 Projects

Loops के बारे में पढ़ना एक बनाने जैसा नहीं है। यहाँ पाँच projects हैं, आसान से कठिन। इन्हें किसी भी tool में करें — loop का आकार एक ही है, तो matching concept की command तक पहुँचें (Claude Code में /loop और /goal; OpenCode में एक shell timer के साथ opencode run)।

शुरू करने से पहले दो नियम, हर बार:

• एक throwaway git repo इस्तेमाल करें। एक loop खुद files edit करता है। अपने पहले loops को किसी ऐसी चीज़ पर point न करें जिसकी आपको परवाह है।
• पहले एक ceiling set करें। Max tries, max minutes, या max spend — इससे पहले कि आप किसी चीज़ को खुद चलने दें (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. अपने repo में एक लंबा task शुरू करें (उदाहरण के लिए, एक script जो थोड़ी देर sleep करती है और फिर एक file लिखती है)। एक in-session loop set up करें जो हर minute check करे कि task खत्म हुआ या नहीं, और जिस पल हो उसी पल आपको बता दे।

Done when loop notice करे कि task खत्म हुआ, एक बार ऐसा कहे, और आप इसे साफ़-सुथरे ढंग से रोक सकें — और आप कभी terminal देखते हुए न बैठे हों।

✅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. अपने repo में 2–3 छोटे failing tests डालें। एक loop बनाएँ जो tests के pass होने तक काम करता रहे — लेकिन एक command (test runner) को, agent को नहीं, तय करने दें कि कब हो गया। इसे, मान लें, 6 tries पर cap करें।

Done when loop इसलिए रुके क्योंकि tests वाकई pass हुए, इसलिए नहीं कि यह cap पर पहुँच गया। अगर यह cap पर पहुँचता रहे, तो आपकी stop condition या आपके prompt को काम चाहिए — यही सबक है।

🧠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. एक scheduled loop बनाएँ जो एक बार चले, एक progress.md पढ़े, repo से कुछ सरल इकट्ठा करे (open TODO comments, या पिछले दिन के commits), एक छोटा summary लिखे, और progress.md को इस बात से update करे कि इसने क्या पाया और date।

Done when आप इसे दो बार चलाएँ और दूसरा run साफ़ तौर पर पहले पर आगे बढ़े — यह वह नहीं दोहराता जो इसने पहले record किया। यह साबित करता है कि आपका spine काम करता है। अगर दूसरा run शून्य से शुरू होता है, तो आपके loop के पास अभी memory नहीं है।

🔍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 loop का एक छोटा version। अपने fix steps के साथ एक छोटी skill लिखें, और एक reviewer agent जो PASS या FAIL जवाब दे। एक असली bug लें, implementer से उसके अपने checkout (worktree या branch) में एक fix draft करवाएँ, और reviewer से इसे grade करवाएँ। सिर्फ़ PASS पर एक PR खोलें।

Done when दो चीज़ें दोनों सच हों: एक अच्छे fix को एक PASS और एक PR मिले, और एक जानबूझकर बुरा fix जो आप plant करें उसे कारणों के साथ एक FAIL मिले। अगर reviewer बुरे fix को pass कर देता है, तो आपका checker बहुत नरम है — इसे कसें। एक checker जो हर चीज़ को approve करता है, वह कोई checker नहीं।

🔁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. किसी ऐसे project में एक असली, उबाऊ, बार-बार होने वाला chore चुनें जिस पर आप वाकई काम करते हैं — एक dependency audit, एक docs-freshness check, एक changelog draft, एक lint sweep। पूरा loop बनाएँ: heartbeat, worktree, skill, maker–checker, connector, और spine। Budget guards जोड़ें। इसे चलने दें।

Done when यह एक हफ़्ते unattended चल चुका हो और आप इस पर भरोसा करें कि यह क्या ship करता है क्योंकि आपने इसे पढ़ा — इसलिए नहीं कि आपने पढ़ना बंद कर दिया। फिर Concept 15 का ईमानदारी से जवाब दें: क्या project की आपकी समझ इस बात के साथ बनी रही जो loop ने बदला? अगर नहीं, तो loop को तब तक धीमा करें जब तक यह बनी न रहे। (जब यह रात भर में fail हो — और यह होगा — model को दोष देने से पहले जब एक loop आपके सोते वक़्त fail होता है से गुज़रें।)

---

आगे कहाँ जाएँ​

• बस schedule की details चाहिए? Reference page Scheduled Tasks: The Loop Skill and Cron Tools /loop, claude -p, opencode run, और OS schedulers को गहराई से cover करता है।
• Non-coding काम के लिए loops बना रहे हैं? Cowork & OpenWork crash course वही heartbeat idea professionals के लिए दिखाता है, cron की जगह scheduled tasks के साथ।
• जो spec आपने Spec-Driven Development में लिखा वह ही आपके loop की stopping condition है: इसके acceptance criteria वही हैं जिनके against checker grade करता है और जिन्हें /goal रुकने से पहले prove करता है। जब एक loop को चलने देना unsafe लगे, fix लगभग हमेशा एक तेज़ spec होता है — ज़्यादा automation नहीं।

Sources & further reading

यह course primary sources के एक छोटे set पर टिका है। Framing और quotes इन्हीं से आते हैं; technical details official docs से आती हैं।

"Loop engineering" की उत्पत्ति

• Addy Osmani, Loop Engineering — वह essay जिसने pattern को नाम दिया और five-parts-plus-spine model रखा। https://addyosmani.com/blog/loop-engineering/
• The New Stack, "The Anthropic leader who built Claude Code says he ditched prompting — now he just writes loops." https://thenewstack.io/loop-engineering/
• Boris Cherny की "my job is to write loops" टिप्पणी एक CNBC interview से है, जैसा Business Insider ने report किया। Peter Steinberger की "design loops that prompt your agents" line उनकी X पर एक post से है।

Claude Code (official docs)

• Routines — cloud scheduled automations, triggers, और run caps: https://code.claude.com/docs/en/routines
• Channels — एक चलते session में event-driven input: https://code.claude.com/docs/en/channels
• इस किताब का अपना reference page, Scheduled Tasks: The Loop Skill and Cron Tools, /loop, /goal, और claude -p पर गहराई से जाता है।

OpenCode (official docs)

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

Model identifiers

• Anthropic, Introducing Claude Sonnet 4.6 — claude-sonnet-4-6 model string का स्रोत: https://www.anthropic.com/news/claude-sonnet-4-6
• Anthropic, Model IDs and versioning — क्यों dateless IDs (claude-sonnet-4-6) 4.6 generation से आगे pinned snapshot हैं, जबकि Haiku 4.5 जैसे 4.5-generation models एक dated canonical ID (claude-haiku-4-5-20251001) साथ ही एक dateless alias रखते हैं: https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions

सारे links June 2026 तक मौजूद। ये tools अक्सर update होते हैं, तो किसी specific limit, flag, या model string पर भरोसा करने से पहले इसे live docs के against confirm करें।

---

एक-line summary

अपने agent को turn-by-turn prompt करना बंद करें। वह loop design करें जो इसे आपके लिए prompt करे — एक heartbeat, चार working parts, और एक spine जो याद रखता है — और वह engineer बने रहें जो पढ़ता है कि यह क्या ship करता है।

Flashcards Study Aid

---

Test Your Understanding

Checking access...