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 में दिया गया है।)

Key words, plain language में

Term	आसान अर्थ
agent	AI system जो tools use और steps complete कर सकता है, सिर्फ़ answers नहीं देता।
prompt	Agent को दी गई instruction.
loop	System जो work start करता, check करता, result record करता और ज़रूरत पर repeat करता है।
beat	Loop का एक complete run.
heartbeat	Schedule, event या condition जो beat शुरू करता है।
trigger / fire	Run शुरू करना, जैसे GitHub event Routine fire करे।
unattended	हर step पर human के देखे बिना चलना।
stop condition	Testable rule जो बताती है work कब done है।
maker-checker	एक agent work बनाता है; दूसरा agent या command check करता है।
worktree	अलग folder और branch जो parallel agents को same files बदलने से रोकता है।
skill	Saved project instructions जिन्हें agent reuse करता है।
connector / MCP	GitHub, Slack या database जैसे external system का connection.
state / memory	Model के बाहर saved information, ताकि later runs पहले का हाल जानें।
spine	Saved state जो एक beat को अगले से जोड़ता है।
human gate	Risky action से पहले human review या approval point.
Routine	Claude Code cloud automation जो saved prompt और trigger से नया session शुरू करती है।

Course body metaphor use करता है: heartbeat work शुरू करता है, body work करता है, और spine runs के बीच memory carry करती है।

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) देख लें।

Shift को play करें (30 seconds)

ऊपर की picture को चलती हुई सोचें: बाईं ओर हर step आप start करते हैं; दाईं ओर system हर step खुद start करता है। Part 2 में schedule, Concept 11 में checker और Part 5 में human gate फिर मिलेंगे।

Simple terms

Claude Code आपके लिए ज़्यादा loop features देता है। OpenCode worker देता है, और scheduler व दूसरे parts आप खुद connect करते हैं।

Loop कहाँ run हो सकता है?

असली loop unattended होता है। आपके दूर रहने पर वह खुद को prompt करता है। July 2026 तक web यह बिल्कुल नहीं कर सकता था। claude.ai और chatgpt.com पर chat box हर turn आपका इंतज़ार करता था: schedule आप थे। असली loop के लिए browser छोड़कर खुद fire होने वाले Claude Code या OpenCode पर जाना पड़ता था।

July 2026 में यह बदल गया। दोनों vendors ने agent products उन्हीं web addresses में integrate किए। Claude Cowork अब claude.ai पर चलता है (Cowork crash course देखें)। Remote sessions Anthropic के servers पर चलते हैं, इसलिए scheduled loop बंद browser tab से भी fire होता है। ChatGPT Work chatgpt.com पर यही करता है। इसलिए "web पर loop नहीं चल सकता" अब सच नहीं है। Precise बात है: chat box loop नहीं चला सकता, उसके चारों ओर web pages चला सकते हैं। अधिकतर surfaces paid हैं और कई staged rollouts के साथ beta में हैं। Loop कहीं भी सीख और design कर सकते हैं; उसे run करने के लिए इनमें से एक surface चाहिए। यह course coding वाली दो surfaces दिखाता है।

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

अच्छा प्रश्न है और उत्तर July 2026 में बदला, इसलिए before और after समझें।

July 2026 से पहले: claude.ai और chatgpt.com chat boxes थे। Chat box हर turn आपका इंतज़ार करता है और schedule या event पर शुरू नहीं हो सकता। Manually re-prompt करने पर heartbeat आप थे, ठीक वही job जिसे loop हटाता है। इसलिए web पर loop design होता था, run करने के लिए Claude Code या OpenCode पर जाना पड़ता था।

July 2026 के बाद: दोनों vendors ने agent products उन्हीं web addresses में रखे। Chat box अब भी आपका इंतज़ार करता है। उसके पास बैठी चीज़ बदली:

• claude.ai पर Cowork (beta, पहले Max plan, आगे और plans)। उसी browser tab में Cowork session Anthropic servers पर remote session की तरह चलता है। Scheduled tasks device online न होने पर भी fire होती हैं। Sessions और files account में save होते हैं, जिससे built-in spine मिलती है। केवल आपके decision वाला question phone पर आता है: product का human gate। Cowork Routine का non-coding twin है।
• उसी login के पीछे Claude Code Routines (claude.ai/code/routines पर बनी) coding work के लिए पहले से fresh cloud sessions देती हैं, laptop बंद। Paid plan, research preview।
• chatgpt.com पर ChatGPT Work (OpenAI, July 9, 2026): scheduled tasks, built-in Codex और cloud-synced sessions वाला agent, desktop और mobile पर web से। Scheduled tasks heartbeat, connected apps connectors, Codex Goal mode conditional loop और cloud-synced sessions devices के बीच state हैं।
• OpenCode अपने scheduler (cron, GitHub Actions) से, vendor cloud के बिना यही करता है।

कुछ days के अंतर पर दो vendors loop को browser में ले गए। यह central claim का strongest evidence है: skill shape है, tool नहीं।

Division of labor अब sharper है। Chat box में loop design और practice करें: skill draft, reviewer prompt, stopping condition, एक manual beat। Cowork, Routine, ChatGPT Work या OpenCode जैसी agent surface पर उसे run करें। Spec-Driven Development के बाद यही natural next step है।

Mid-July 2026 में सत्य। Cowork और ChatGPT Work weeks पुराने, rollouts plan के अनुसार staged और usage metered हैं। किसी limit या feature पर निर्भर होने से पहले live pages check करें।

सरल शब्दों में

Chat box में loop design और practice करें। Unattended run के लिए खुद fire होने वाली Claude Code, OpenCode, Cowork या ChatGPT Work surface use करें। July 2026 से browser छोड़ना आवश्यक नहीं: Cowork claude.ai और ChatGPT Work chatgpt.com पर चलता है।

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

अब लगभग हर concept real session में run कर सकते हैं। Page के साथ terminal (claude या opencode) खुला रखें और हर idea छोटे throwaway git repo में try करें, ताकि important चीज़ को नुकसान न हो।

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

Part	Topic	आप क्या सीखते हैं
1	The Shift	Loop, उसके छह parts और उसे बनाने के दो तरीके
2	Loop को क्या शुरू करता है	In-session, conditional, scheduled और event-driven self-start
3	Loop क्या करता है	Isolation, knowledge, action और maker-checker split
4	Runs के बीच memory	Runs के बीच बची state, वह part जिसे लोग भूलते हैं
5	A Loop, Twice	दोनों tools में real files वाला morning-triage-to-PR loop
6	Human control रखना	Token cost, work check करना और loops के साथ बढ़ते traps
Live	Book के अपने loops	Production में course चलाने वाले दो loops और human की जगह
Practice	Practice projects	आठ loops, easy से hard, जिन्हें आप बनाते हैं
Appendix	Routines, end to end	हर field, तीन triggers, secrets, common problems, तीन drills और capstone

तीन loops जिन्हें आज run कर सकते हैं, सिर्फ़ पढ़ें नहीं

Project	Concept	क्या होता है
Watch the Station	4, in-session	ISS हर minute location report करता है। Terminal बंद करें, watch चला जाता है।
Build Your Portfolio	5, conditional	Résumé drop करें, finish line /goal को दें; agent PDF पढ़ता, page design और check करता है, pass तक repeat करता है।
The Doorbell	7, event-driven	PR खोलें और review आपके computer से बाहर runner पर खुद आता है।

तीनों agentfactory-labs में हैं। कम-से-कम पहला करें। Heartbeat को fire होते देखना उसे तीन बार पढ़ने से ज़्यादा valuable है।

पहले Part 5 में complete loop देखें, फिर parts पर लौटें। Practice projects में आठ और loops हैं।

इस course को पढ़ने के दो तरीक़े

पहली बार: Parts 1–5 order में पढ़ें, "Going deeper" notes skip करें और Projects 1–3 करें। दूसरी बार: पहला loop सच में run होने के बाद deeper notes, Part 6, Projects 4–8 और Routines appendix पढ़ें।

क्या याद रखें, क्या lookup करें

Durable layer याद रखें: heartbeat, body के four parts, spine, maker-checker, intent और accountability. Mechanical layer lookup करें: flags, paths, model names और commands. वे weekly बदलते हैं; live docs authoritative हैं।

इस book में इन loops का dogfooding आगे concrete examples देता है।

📚 Teaching Aid

Open Full Slideshow

View Full Presentation — Loop Engineering: A Crash Course

---

Part 1: The Shift

1. Prompting से looping तक

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

Loop अलग है। यह operator के रूप में आपकी जगह एक system रखता है। System काम ढूँढता है। काम बाँटता है। Result जाँचता है। उसने क्या किया, यह लिखता है। फिर तय करता है कि आगे क्या करना है। यह आपकी ओर से agent को prompt करता है।

तो आपकी value कहाँ जाती है? वह गायब नहीं होती। वह उन दो चीज़ों में चली जाती है जो loop आपके लिए नहीं कर सकता। पहली है intent: साफ़-साफ़ बताना कि आप क्या चाहते हैं, इतनी स्पष्टता से कि result को check किया जा सके। दूसरी है accountability: result की ज़िम्मेदारी लेना। जो ship होता है, उसके owner आप हैं। बीच के steps loop संभालता है। दोनों छोर आपके पास रहते हैं। आपको अपने intent और judgment के लिए value मिलती है। इस बात से अनजान रहने के लिए नहीं कि काम कैसे बना।

यह बदलाव "एक लंबा prompt" नहीं है। यह काम का एक नया shape है:

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

दो loops का एक ही नाम

पहली reading में यह optional technical detail safely skip किया जा सकता है।

"Loop engineering" शब्द दो अलग चीज़ों के लिए use होता है। यह course बड़ा loop सिखाता है। लेकिन यही शब्द छोटे loop के लिए भी सुनने को मिलेगा। दोनों का अर्थ अभी साफ़ कर लें, ताकि आगे confusion न हो।

छोटा loop (inner loop)। हर agent के अंदर code का एक छोटा cycle चलता है। यह ऐसे काम करता है: context model को भेजें, model tools use करने को कहता है, tools run करें, results context में जोड़ें, और repeat करें। जब model tools माँगना बंद करता है, cycle खत्म हो जाता है। Code में यह सिर्फ़ कुछ lines है:

while True:
    reply = model(context)
    if not reply.tool_calls:
        break                     # the model decided it is done
    context += run_tools(reply.tool_calls)

break वाली line देखें। यह important है। छोटा loop तब रुकता है जब model खुद तय करता है कि वह finish हो गया। कोई यह check नहीं करता कि model सही है या नहीं।

यही problem है। Model अपने काम का judge खुद है। एक common failure देखें। Agent किसी file को बदलता है। वह confidence से लिखता है, "Done! All fixed." फिर रुक जाता है। लेकिन उसने tests कभी run ही नहीं किए। Turn खत्म हुआ। Task नहीं।

इसीलिए यह course outside stops सिखाता है। Outside stop model की अपनी राय पर depend नहीं करता:

• एक checked condition (किसी real test से काम prove करें)
• एक limit (tries की maximum संख्या)
• एक no-progress check (अगर कुछ बेहतर नहीं हो रहा तो रुकें)
• एक separate checker (एक दूसरा process जो काम को grade करे)

इन सबकी एक ही वजह है। छोटे loop के पास अपने-आप रुकने का एकमात्र आधार model की अपने बारे में राय है।

बड़ा loop (outer loop, यही course)। छोटे loop को एक worker समझें जो एक task करता है। बड़ा loop manager है। वह तय करता है कि worker को कौन-सा task देना है। कब शुरू करना है। Result को कैसे grade करना है। कल के लिए क्या याद रखना है। छोटे loop का एक पूरा run, बड़े loop का सिर्फ़ एक beat है।

Layers आपस में कैसे fit होती हैं। हर layer पिछली layer को wrap करती है। Industry का focus भी लगभग इसी order में, करीब एक-एक साल के अंतर से, आगे बढ़ा। इसीलिए हर layer को कुछ समय के लिए बहुत attention मिली:

1. Prompt engineering: वे words जो आप भेजते हैं।
2. Context engineering: एक turn में model जो कुछ देखता है।
3. Harness engineering: model के चारों ओर का code, जो tools run करता और errors handle करता है। छोटा loop यहीं रहता है।
4. Loop engineering: यही course। Outer cycle: पूरा system किस काम पर चलता है, कब शुरू होता है, और कैसे जानता है कि काम पूरा है।

इसीलिए आपका prompt पहले से कम important लगता है। अब वह एक बहुत बड़े system का सिर्फ़ एक input है।

हर layer अलग तरह की failure भी रोकती है। इसीलिए कोई एक layer बाकी सबका काम नहीं कर सकती। Strong context किसी weak prompt को बचा सकता है, लेकिन कोई prompt missing context, missing checker, या ऐसे schedule को नहीं बचा सकता जो अब भी आप हैं। इसलिए build करते समय एक useful self-check है: इनमें से कौन-सी layer मैं अब भी हाथ से कर रहा हूँ?

अच्छी stop conditions, clean context और सही tools के साथ छोटे loop को मज़बूत बनाना real work है। लेकिन यह सब एक beat के अंदर होता है। जब छोटा loop बड़े loop के लिए matter करेगा, यह course साफ़ बताएगा। Stopping conditions के लिए Concept 5 और connector design के लिए Concept 10 देखें।

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

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

एक loop जो सच में अपने-आप चलता है, उसके पाँच working parts और एक saved-memory layer होते हैं। यह course उस memory layer को spine कहता है। पाँच working parts में से चार से आप agentic coding course में मिल चुके हैं। यहाँ वे एक नया काम करते हैं।

1. Heartbeat: एक schedule (या event) जो loop शुरू करता है। इसके बिना आपके पास एक run है, loop नहीं। अभी एक शब्द सीखें, क्योंकि यह course उसे बार-बार use करता है: loop का हर single firing, यानी उसके steps से होकर एक पूरा pass, beat कहलाता है। Heartbeat beats बनाता है। नीचे की हर चीज़ एक beat के अंदर होती है।
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) जो record करती है कि क्या done है और आगे क्या करना है। Model runs के बीच सब कुछ भूल जाता है। Spine से आज का run जानता है कि कल के run ने क्या किया। No spine, no loop। इसके बिना loop हमेशा अपना पहला step ही दोहराता रहता है।

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

क्या यह सिर्फ़ code के लिए है?

नहीं। इस course के examples code, यानी repos, tests और PRs, के हैं क्योंकि tools वहाँ सबसे strong हैं। लेकिन loop के shape को इस बात से फ़र्क़ नहीं पड़ता कि काम क्या है। Book, report, course या newsletter, हर एक files से भरा repo हो सकता है, और loop का हर part उस पर map हो जाता है। यह book, उदाहरण के लिए, markdown files का repo है। Nightly link check, style sweep, stale model names flag करने वाला pass, हर एक इसी chapter का loop है।

एक चीज़ बदलती है: checker। Code के पास सबसे honest checkers हैं, tests और linters, यानी commands जो "done" prove करती हैं। Prose की test suite नहीं होती। इसलिए writing loop दो कमज़ोर checks पर निर्भर करता है: जहाँ possible हो mechanical checks (broken links, missing figures, banned words, heading levels), और बाकी के लिए written rubric वाला reviewer agent। Mechanical rung built-in checks से बड़ी है। सिर्फ़ आपके project को पता rules, जैसे "memory files में relative dates न हों" या "हर figure का alt text 40 words से लंबा हो", command बन जाते हैं जब आप उन्हें लिख देते हैं। Concept 11 के बाद का interlude दिखाता है कि कैसे, और rubric से command में लाई गई हर rule एक claim को proof में बदल देती है। Rubric को stopping condition बनाने की एक trick है: उसे score और bar दें। "इस draft को rubric पर grade करें। 95 से नीचे न रुकें" soft judgment को ऐसी चीज़ बनाता है जिस पर loop act कर सके। लेकिन model का score अब भी claim है, proof नहीं, और passing test से weaker है। Checker जितना weaker हो, उतना ज़्यादा काम human gate से गुजरना चाहिए।

एक और चीज़ नहीं बदलती: heartbeat menu। Domain heartbeat नहीं चुनता। Task का shape चुनता है। "यह अभी करें, done होने तक" conditional loop है और तुरंत शुरू होता है। "हर रात यह करें" schedule है और तय समय पर शुरू होता है। "कुछ आने पर react करें" event है। Repo में code हो या chapters, menu वही है। और जब आप actively लिख या code कर रहे हों, आम तौर पर कोई loop नहीं होता। Heartbeat आप हैं; loops bounded chunks और आसपास की maintenance उठाते हैं।

अगर आपका काम code के बजाय documents है, तो इस course को ऐसे ही पढ़ें, फिर non-coding tools वाले यही loops देखने के लिए Cowork & OpenWork crash course देखें।

3. Loop बनाने के दो रास्ते: built-in tools या खुद connect किए tools

यही वह एक जगह है जहाँ 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 से शुरू हो सकती हैं। Trade-off हर account की daily run limit है। Launch पर ये limits Pro के लिए 5 runs/day, Max के लिए 15, और Team/Enterprise के लिए 25 थीं। Cap के बाद extra usage खरीदी जा सकती है, और one-off scheduled runs count नहीं होते। लेकिन docs अब fixed numbers print नहीं करतीं, इसलिए इन्हें launch-time examples मानें, promise नहीं। Routines research preview हैं और limits बदल सकती हैं। भरोसे लायक एकमात्र number आपके usage page (claude.ai/settings/usage) पर है।

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. Subagents (maker/checker)
    if PASS: open a PR via GitHub      # 5. Connector (MCP)
    if risky: write it to progress.md and leave it for a human
  update progress.md                  # 6. Spine again

इस तस्वीर को ध्यान में रखें। 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 आख़िरी दो इस्तेमाल करते हैं।

एक idea चारों के नीचे बैठता है: एक loop कोई single action नहीं है। यह है यह करें, रुकें, फिर करें, बार-बार, इसलिए beats के बीच किसी चीज़ को जागते रहना पड़ता है ताकि वह अगली को fire कर सके। सवाल सिर्फ़ यह है कि वह चीज़ कहाँ रहती है।

• एक in-session loop अपना timer आपके खुले session में रखता है — वह process जो आपके terminal के खुले रहने तक चलती रहती है। session बंद करें और timer पकड़ने वाली चीज़ चली जाती है, इसलिए loop रुक जाता है।
• एक scheduled task या Routine (इन्हें आप Concept 6 में बनाते हैं) timer को session के बाहर ले जाता है, एक ऐसे scheduler पर जो कभी सोता नहीं (आपकी अपनी machine पर cron, या cloud Routine के लिए Anthropic के servers)। हर tick पर यह एक बिल्कुल नया short-lived run launch करता है, उसे खत्म होने देता है, और बंद कर देता है, फिर अगली बार एक fresh run launch करता है। वही loop, पर आपकी कोई चीज़ खुली नहीं रहनी पड़ती।

Heartbeat	Timer कहाँ रहता है	Beats के बीच क्या जागता रहता है
In-session /loop	session के अंदर	आपका खुला session (आपकी machine, terminal खुला)
Scheduled task / Routine	बाहर, एक scheduler में	scheduler, जो हर tick पर एक fresh run launch करता है

यह picture भी याद रखें। यह आगे की हर limit समझाती है: एक in-session loop तब रुकता है जब उसका session रुकता है, और एक ऐसा loop जिसे बंद laptop के बावजूद ज़िंदा रहना है, उसे बाहर वाली किस्म चाहिए (Concept 6)।

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

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

In-session loop को play करें (30 seconds)

Session open रहने तक यह हर interval पर beat fire करता है, और आपके देखते रहने के कारण deploy को पकड़ लेता है। Session बंद करते ही watch रुकती है। इसीलिए in-session loop आपके सोते समय नहीं चल सकता (Concept 6)।

Open ↗

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

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

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

/loop cancel करना। हर loop ID वाला scheduled task है, इसलिए उसे उसी तरह plain language में रोकें जिस तरह शुरू किया था:

show my running loops
cancel the deploy-check loop

Claude task ढूँढकर cancel कर देता है। अगर कई loops चल रहे हों, तो वह पूछता है कि कौन-सा रोकना है, या आप सीधे task ID दे सकते हैं। Session बंद करना भी plain-session loop रोकता है, लेकिन cancel करना साफ़ तरीका है। जिस loop को रोकना था, उसे session बंद होने पर depend नहीं रहना चाहिए। Exact subcommands mechanical layer हैं। Plain language कभी काम न करे तो code.claude.com/docs/en/scheduled-tasks पर live docs देखें।

अभी एक चलाएँ: पाँच minutes का real loop

Heartbeat के बारे में पढ़ना और उसे fire होते देखना एक बात नहीं है। इस concept का छोटा project सिर्फ़ यही करता है: real International Space Station को Earth के चारों ओर उड़ते हुए watch करता है।

git clone https://github.com/panaversity/agentfactory-labs.git
cd agentfactory-labs/crash-course/loop-eng/iss-loop
claude

Folder पर trust पूछे तो yes कहें। इससे project के साथ आने वाली permission on होती है, ताकि loop आपसे पूछने के लिए न रुके। फिर एक plain sentence type करें:

/loop show me the location of the ISS every minute

अब आख़िरी instruction दे चुके हैं। आप दूसरा काम करते रहें और हर minute नई position आती रहेगी। दो बातें notice करें, क्योंकि दोनों मिलकर पूरा concept हैं:

• /loop ने "every minute" को heartbeat की तरह पढ़ा। आपने schedule, script या URL नहीं लिखा। Project folder में यह सब मौजूद है। इसीलिए prompt एक sentence हो सका।
• अब terminal बंद करें। Watch उसके साथ खत्म हो जाती है। यह bug नहीं है। यही in-session loop की definition है और Concepts 6 तथा 7 की वजह भी।

Full instructions और दो मुश्किल prompts project के README में हैं।

Optional: session बंद होने पर क्या होता है?

एक limit जानें: plain-session /loop purpose के साथ आपके session के अंदर चलता है। Terminal बंद करें या laptop sleep होने दें, तो यह रुक जाता है। यह safety feature है, bug नहीं। Casual in-session loop को शुरू करने वाले session से ज़्यादा नहीं जीना चाहिए। दो recent changes इस rule को थोड़ा आसान बनाती हैं:

• --resume उन tasks को वापस लाता है जो expire नहीं हुए। Recurring task create होने के बाद सात days तक valid रहता है।
• Session को background में भेजना आपके /loop tasks को साथ ले जाता है, इसलिए terminal खुला न होने पर भी वे fire करते रहते हैं। लेकिन machine sleep में जिन fires को miss करती है, वे replay नहीं होते।

जो काम किसी भी हालत में चलता रहना चाहिए, उसके लिए /loop पर depend न करें। Scheduled task या Routine use करें (Concept 6)। Cloud session में recent releases /loop offer ही नहीं करतीं, क्योंकि request खत्म होते ही remote session shut down हो जाता है। अगला loop fire करने के लिए कुछ running नहीं बचता।

बीच का option: background sessions।

Background session in-session /loop और Routine के बीच की rung है। Terminal window बंद होने के बाद भी यह आपकी machine पर एक run alive रखती है। इसे claude --bg से शुरू करें।

अपने-आप यह एक job करके रुकती है, timer पर repeat नहीं करती। इसकी value loop carry करने से आती है। /loop शुरू करके session को background में भेजें और loop साथ चलता रहेगा। बाद में claude agents इसे list करता है और /resume इसे bg marker के साथ खोलता है।

Deploy या long test run watch करते समय terminal बंद करना हो तो इसे चुनें। बस "अपनी machine पर alive" रहने की cost याद रखें: computer को awake रहना होगा। जिस पल काम को बंद laptop के बावजूद चलना हो, आप scheduler territory में पहुँच गए और सही tool Routine है (Concept 6)।

तीनों rungs एक सवाल पर line up होती हैं: कितना कुछ awake रहना चाहिए?

Rung	Option	Terminal बंद करने के बाद fire होता है?	Laptop sleep या off होने पर fire होता है?
Bottom	In-session /loop	नहीं	नहीं
Middle	Background session (--bg) carrying a /loop	हाँ	नहीं (machine awake चाहिए)
Top	Scheduled task / Routine	हाँ	हाँ (cloud Routine Anthropic servers पर चलती है)

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 है, lower-level components से बना। Shell heartbeat है और opencode run beat। इसे रोकने के लिए Ctrl-C दबाएँ। Background में चलता हो तो उसका process kill करें। हर fresh opencode run पहले पूरा runtime start करता है, यानी 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"

Simple terms

जब आप काम देख रहे हों तब in-session loop use करें। काम आपके बिना जारी रहना हो तो cloud Routine या दूसरा unattended schedule use करें।

5. Conditional loop, यानी run-until-done (clock से नहीं, check करके रुकें)

Fixed-timer loop (Concept 4) चुने interval पर repeat करता है। हर run काम check कर सकता है, लेकिन result timer को नहीं रोकता। Loop तब तक चलता है जब तक आप उसे cancel न करें, session खत्म न हो, या task expire न हो।

Conditional loop, जिसे run-until-done भी कहते हैं, किसी specific condition के true होते ही रुकता है। इसे ऐसे सोचें: "Tests pass होने तक run करें," न कि "मेरे देखते रहने तक हर five minutes run करें।"

मुख्य फ़र्क़ सरल है: fixed-timer loop नहीं जानता कि काम कब complete हुआ। Conditional loop इसलिए रुकता है क्योंकि काम complete हुआ। कोई अलग command या checker इसका निर्णय करता है। काम करने वाले agent को अपना result approve नहीं करना चाहिए।

Run-until-done को play करें (30 seconds)

Loop कोशिश करता रहता है और एक अलग checker "done" तय करता है। Goal prove होते ही यह रुकता है, बिना timer और बिना आपके।

Open ↗

/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 मुफ़्त में दे देता है।

Optional: Claude Code की current retry settings

Unattended run का मतलब है loop को कोई नहीं देख रहा, जैसे overnight या keyboard से दूर रहते हुए। अटकने पर रोकने वाला कोई person नहीं होता। इसीलिए retries को यहाँ limit चाहिए।

Retry किसी failed step को फिर try करना है, जैसे timeout हुई API call। Cap न हो तो stuck loop आपके सोते समय हमेशा retry कर सकता है और time तथा tokens खर्च करता रह सकता है। इसलिए Claude Code अब cap set करता है:

• Default रूप से temporary errors 10 times तक retry होती हैं (CLAUDE_CODE_MAX_RETRIES), जिसे अधिकतम 15 तक बढ़ा सकते हैं।
• CI jobs जैसी unattended sessions के लिए CLAUDE_CODE_RETRY_WATCHDOG=1 set करें। यह temporary errors को काफ़ी अधिक देर, लिखते समय 300 times तक यानी करीब three hours backoff, retry करता है और अपना MAX_RETRIES set करने पर 15 cap हटा देता है।

Flag names और numbers mechanical layer हैं, इसलिए भरोसा करने से पहले live docs देखें। Lasting point यह है कि vendor भी मानता है: unattended run को purpose के साथ चुनी limit चाहिए।

इससे कुछ real बनाएँ: अपना portfolio

npm test साफ़ stopping condition है क्योंकि tests किसी ने पहले लिखे हैं। ज़्यादातर काम ऐसा नहीं होता। Portfolio project मुश्किल सवाल पूछता है: किसी person के देखने वाले page के लिए "done" का अर्थ क्या है, और क्या आप इसे इतनी precision से लिख सकते हैं कि loop वहाँ पहुँच सके?

अपनी CV या LinkedIn PDF folder में रखें, फिर /goal को finish line दें:

/goal Build my portfolio in site/ from my-cv.pdf, following spec.md. Done when `python3 check.py site` prints 20/20 and the reviewer agent replies PASS on all six judgment promises — show me both. Stop after 15 check attempts or 3 review rounds and write what is still failing to progress.md.

फिर दूर चले जाएँ। यह PDF पढ़ता है, design तय करता है, words लिखता है, page build करता है, checker run करता है, failures पढ़ता है और उस sentence के true होने तक फिर कोशिश करता है।

हर clause इसी concept का idea real काम कराता है। Command से prove होने वाली condition: check.py 20 checks run करता है जिन्हें machine settle कर सकती है, जैसे पाँच sections का मौजूद होना, contrast ratios और phone से बाहर कुछ न जाना। Visible evidence: show me both इसलिए है क्योंकि /goal checker सिर्फ़ transcript पढ़ता है और unprinted result confirm नहीं कर सकता। Cap: 15 attempts, क्योंकि /goal के पास built-in give-up नहीं और impossible condition का पीछा loop पूरी रात करेगा। Maker से अलग checker: separate reviewer agent, जिसे spec mandatory बनाती है।

यहीं project tutorial से आगे जाता है। 20/20 done नहीं है। Reviewer को छह ऐसी चीज़ें भी pass करनी हैं जिन्हें command measure नहीं कर सकती: क्या writing आपकी CV के प्रति true है, क्या page designed है न कि सिर्फ़ formatted, क्या यह बस PDF ही हो सकता था? Spec साफ़ कहती है: "Part A is a morning's work. Part B is the job." Checker ladder में Concept 2 पर यह idea मिला था। यहाँ आप इसे feel करते हैं।

Project एक rule पर कभी compromise नहीं करता: check.py को pass कराने के लिए edit न करें। Green के लिए optimize करने वाला loop इसी shortcut तक पहुँचेगा, और उस urge को पहचानना ही lesson है।

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 बेकाबू होती हैं।

OpenCode ने limit को agent में भी जोड़ना शुरू किया है। हर agent config में steps limit accept करता है; पुराना maxSteps नाम deprecated है। Limit hit करने वाला agent लगातार कोशिश करने के बजाय अपने किए काम और बाकी काम का summary देता है। दोनों limits अलग चीज़ बचाती हैं। Shell cap बताती है कि loop कितने beats fire करेगा। steps बताता है कि एक beat के अंदर agent कितने turns लेगा। दोनों set करें।

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

हर loop को तीन stops चाहिए। हर एक fail होने का एक ख़ास तरीका रोकता है:

Stop	यह क्या है	इसे छोड़ें, तो…
Success condition	loop कैसे जानता है कि task हो गया	कुछ भी "done" define नहीं करता, इसलिए loop न जानबूझकर रुक सकता है, न grade हो सकता है
Limit	एक ceiling: max tries, max minutes, या max spend	एक ऐसा goal जिसे यह पा नहीं सकता आपका पूरा token budget जला देता है
No-progress check	पकड़ें जब agent वही action वही arguments के साथ दोहराता है (यह अटका है; retry करने से ठीक नहीं होगा)	यह पूरी limit एक ही ग़लती दोहराने में खर्च कर देता है

एक नाम जो आपको online मिलेगा: Ralph loop। सबसे सरल well-known run-until-done loop: यह वही prompt बार-बार चलाता है, हर run एक state file पढ़ता और update करता है। यह तीन में से सिर्फ़ दो stops रखता है (एक success condition और एक time cap), न कोई stuck-check, न कोई skill, न कोई अलग checker। यही रूखापन बिल्कुल वही वजह है कि यह सबक इतनी साफ़ी से सिखाता है। एक vague condition वाला Ralph loop तब तक भटकता है जब तक time cap जल न जाए; वही loop एक ऐसी condition के साथ जिसे एक command prove कर सके, अच्छा काम करता है।

एक loop उतना ही अच्छा है जितनी उसकी stopping condition।

लंबे runs वक़्त के साथ बिगड़ते हैं

कई turns तक चलने वाला एक run-until-done loop अपने ही context को कचरे से भर देता है: पुराना tool output, dead ends, और बासी reasoning। जैसे-जैसे ढेर बढ़ता है, model के जवाब बिगड़ते जाते हैं। community इस नतीजे को doom loop कहती है: एक गंदा context एक बुरे फ़ैसले की ओर ले जाता है, जो और गंदगी जोड़ता है, जो अगले फ़ैसले को और बुरा बना देता है। बचाव वही context की आदतें हैं जो agentic coding course में हैं:

• लंबे runs को compact करें: समय-समय पर raw back-and-forth को जो हुआ उसके एक छोटे summary से बदल दें, ताकि context छोटा रहे।
• बड़े outputs को files में ले जाएँ: बड़े results (logs, data, generated text) को एक file में लिखें और context में सिर्फ़ एक pointer रखें, पूरी चीज़ paste करने के बजाय।
• गंदे subtasks एक subagent को सौंपें: एक helper को उसके अपने context में शोरगुल वाली खोजबीन करने दें और सिर्फ़ साफ़ जवाब लौटाने दें।

तीनों के पीछे एक ही idea: context को एक budget समझें जिसे आप सोच-समझकर खर्च करते हैं, न कि एक bucket जिसमें आप डालते ही रहते हैं। एक छोटा, साफ़ context ही एक लंबे run के फ़ैसलों को तेज़ रखता है।

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

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

एक Routine चलाकर देखें (40 seconds)

claude.ai पर Routine set करें, laptop बंद करें और देखें कि Anthropic के servers आपके laptop के बंद रहने पर भी उसे schedule के अनुसार चलाते रहते हैं।

खोलें ↗

पहले नाम समझें। Scheduler वह सामान्य व्यवस्था है: कोई भी हमेशा चालू रहने वाली clock जो तय समय पर नया run शुरू करती है (cron, GitHub Actions या कोई cloud service)। Routine, Claude Code का अपना cloud-hosted scheduler है, जहाँ Anthropic clock और machine दोनों देता है, इसलिए आपकी किसी चीज़ का चालू रहना ज़रूरी नहीं है। हर Routine scheduler है। हर scheduler Routine नहीं है।

यह इस बात पर निर्भर करते हुए दो तरह का होता है कि आपका laptop चालू रहना चाहिए या नहीं:

Cloud Routines (laptop बंद हो सकता है)। यह modern default है, इसलिए इसे ध्यान से समझना ज़रूरी है। Cloud Routine एक स्थायी instruction है जो आपके computer पर नहीं, Anthropic के servers पर रहती है। आप instruction एक बार लिखते हैं। फिर वह आपके तय समय पर अपने आप चलती है, चाहे laptop खुला हो, sleep में हो या bag में रखा हो। इसे ऐसे worker की तरह समझें जो आपके नहीं, Anthropic के office में बैठता है: आप लिखित job description देते हैं और hosting किए बिना काम हो जाता है।

इस section में एक example साथ रखें। हर सुबह आप वही triage करने में 30 minutes लगाते हैं: रात में आए issues पढ़ना, उन्हें label करना, crash जैसे दिखने वाले issue को flag करना और team के Slack पर summary post करना। वह आधा घंटा एक perfect Routine है। काम दोहराता है, लिखे जा सकने वाले rules मानता है और उसे आपकी ज़रूरत नहीं है। उसे आपके instructions चाहिए।

हर Routine के चार हिस्से। Routine बनाते समय आप चार blanks भरते हैं। हर blank एक सवाल का जवाब देता है।

1. Prompt: इसे क्या करना चाहिए? यह स्थायी instruction है, जिसे उसी spec की तरह लिखा जाता है जिसे लिखना आप सीख चुके हैं: goal, rules और "done" कैसा दिखता है। हर run में यही prompt जाता है और clarification देने वाला कोई नहीं होता, इसलिए इसे आपकी अनुपस्थिति में भी काम करना चाहिए। Triage example के लिए:

Review all issues opened in the last 24 hours. Label each as bug,
feature-request, or question. If any issue describes a crash or data
loss, add the "urgent" label. Then post a summary to the #triage Slack
channel: total new issues, how many urgent, and one line per urgent
issue. If there are no new issues, post "No new issues overnight."
Do not close or comment on any issue.

इसमें spec के हिस्से देखें: goal (triage और summary), rules (इन categories में label करना और crash या data loss को urgent मानना), boundary (किसी issue को close या comment न करना) और empty case के लिए भी साफ़ "done"।

2. Repos: यह किन चीज़ों को छू सकता है? आप उन repositories के नाम देते हैं जिनमें इसे काम करने की अनुमति है। जो list नहीं किया गया, वह इसकी पहुँच से बाहर है। सिर्फ़ yourteam/product-app दें। Billing code वाला repo समेत आपके दूसरे repos इस Routine के लिए मौजूद ही नहीं हैं।

3. Connectors: यह कहाँ तक पहुँच सकता है? Slack, email और calendars। Repo से बाहर ये Routine के हाथ हैं: इनसे वह बाहरी दुनिया पढ़ता है और आपको report देता है। सिर्फ़ Slack connector attach करें, ताकि वह #triage पर post कर सके। Connectors permissions हैं, suggestions नहीं: email connector न होने पर prompt माँगे तब भी वह email नहीं भेज सकता।

4. Trigger: यह कब शुरू होता है? यही heartbeat है। अलग तरह के काम के लिए तीन प्रकार हैं। Schedule: clock इसे हर weekday 8:30 पर शुरू करती है, ताकि team के बैठने से पहले summary तैयार हो। API call: दूसरा program इसे शुरू करता है। आपकी deploy script release पूरी करके "release को smoke-check करें और report दें" run fire कर सकती है। इस तरह Routine fixed clock पर नहीं, जाँचने के लिए कुछ होने पर ही चलती है। GitHub event: repository event इसे शुरू करता है। "Pull request opened" trigger शांत दिन में zero और busy दिन में nine times चल सकता है। Concept 7 इसे समझाता है।

क्या करना है, कहाँ काम कर सकता है, कहाँ पहुँच सकता है और कब शुरू होता है। हर Routine इन्हीं चार answers से बनती है। Issue-triage worker अब पूरी तरह specified है: ऊपर वाला prompt, एक repo, एक Slack connector और weekdays में 8:30।

एक feature, तीन दरवाज़े। आप Routine को claude.ai/code/routines पर, Desktop app में या CLI के /schedule से बना सकते हैं। ये तीन अलग features नहीं हैं। तीनों एक ही cloud feature manage करते हैं: किसी भी दरवाज़े से बनी हर Routine उसी cloud account में save होती है और तीनों जगह दिखती है। उदाहरण के लिए, terminal में /schedule से बनाकर बाद में browser में edit कर सकते हैं।

Run में क्या होता है। Monday 8:30 पर Anthropic के servers एक fresh Claude session शुरू करते हैं, उसे आपका prompt देते हैं और सिर्फ़ वही repo और connectors देते हैं जिन्हें आपने list किया था। वह weekend के issues पढ़ता है, label करता है, #triage पर post करता है ("7 new issues, 1 urgent: login crash on Android (#412)") और बंद हो जाता है। Tuesday का run बिलकुल fresh शुरू होता है। Monday का session जा चुका होता है। कुछ भी आपकी machine पर depend नहीं करता। इसी वजह से यह ऐसा सच्चा loop है, session नहीं जिसे आपको देखते रहना पड़े। इसी कारण spine, यानी Concept 12, को repo में रहना चाहिए।

Optional: मौजूदा Routine limits और branch rules

इस पर depend करने से पहले दो मौजूदा product rules check करें।

Rule one: daily cap है। हर account को प्रति दिन Routine runs की fixed संख्या मिलती है: launch के समय Pro पर 5, Max पर 15 और Team तथा Enterprise पर 25। किसी और के servers पर चलने वाले unattended system का budget होना ज़रूरी है। यह हर cloud service के लिए सच है और ऐसी संख्या है जिसके अनुसार design करना चाहिए, बाद में चौंककर पता नहीं लगाना चाहिए। Pro plan का quick हिसाब देखें: issue triage (1 run), evening commit summary (1 run) और 4 pull requests वाले दिन PR-review Routine (4 runs), कुल 6 runs। यह cap से एक अधिक है। क्रम से options हैं: दोनों daily reports को एक Routine में merge करें, busy days में PR reviewer के लिए extra usage खरीदें या plan upgrade करें। Loop के run five पर चुपचाप रुकने से पहले यह हिसाब करें। तीन बातें cap को आसान बनाती हैं: ये launch-time numbers हैं, इसलिए claude.ai/settings/usage check करें; one-off scheduled runs नहीं गिने जाते; और cap के बाद extra usage के लिए pay कर सकते हैं।

Rule two: default रूप से सिर्फ़ claude/ branches पर push कर सकती है। Fresh Routine main पर नहीं लिख सकती। जिस branch पर push करे, उसका नाम claude/ से शुरू होना चाहिए।

यह बाधा नहीं, अच्छी बात है। इससे unattended काम पहले दिन से safe रहता है: Routine जितना चाहे काम कर सकती है, लेकिन merge क्या होगा, यह आप तय करते हैं।

एक example देखें। Flaky tests को रात में fix करने के लिए दूसरी Routine set करते हैं। 3 AM पर वह fix को claude/ branch पर push करती है। सुबह आप change पढ़ते हैं, सही लगता है तो खुद merge करते हैं। Routine ने आपके सोते समय काम किया। आपने जागकर check किया। यही अंतर पूरी बात है।

बहुत से clean runs के बाद जब repo आपका trust कमा ले, तब सिर्फ़ उसी repo के लिए Allow unrestricted branch pushes setting से rule off कर सकते हैं। यह जानबूझकर, एक-एक repo के लिए करें, जैसे किसी को key सौंपते हैं।

Routine कब सही tool है: जब काम को आपकी machine की ज़रूरत नहीं हो। Issue triage, stakeholders के लिए Friday का "इस week क्या बदला" digest, competitor का changelog देखना या routine support issues के replies draft करना। जब सोचें, "यह मेरे बिना हर दिन अपने आप हो जाना चाहिए," तो यही tool है। हर form field, environment और secrets को Routines appendix में समझाया गया है। Cloud और cron के बीच तीसरा native option Desktop scheduled tasks है, जो Desktop app में बनता है। वे unsaved changes समेत आपकी असली files पर locally चलते हैं और open session की ज़रूरत नहीं होती, लेकिन आपकी machine चालू होनी चाहिए।

Optional: terminal से Routine manage करें

Terminal से plain English में Routine का पूरा lifecycle manage कर सकते हैं। इसे create करें, मौजूद Routines list करें, अभी run करें या timing बदलें:

/schedule every weekday at 9am, run the daily-triage skill   # create it
/schedule list                                               # see what you have
/schedule run the triage routine now                         # fire one run, to test it
/schedule update the triage routine to every two hours       # change the timing

तीन छोटी बातें:

• Custom timings। Ready-made options common cases cover करते हैं: every day, every hour और every weekday। Unusual schedule के लिए update cron expression भी लेता है: exact time बताने वाला short code। उदाहरण के लिए, 0 9 * * 1-5 का मतलब "9am, Monday से Friday" है।
• Free practice। One-off repeat होने के बजाय एक बार चलता है, जैसे /schedule tomorrow at 9am, …। One-offs daily run limit में count नहीं होते, इसलिए हर दिन चलाने से पहले prompt को एक बार आज़माकर verify करने का free तरीका हैं।
• सिर्फ़ clock-based। Terminal से केवल तय समय पर शुरू होने वाली Routines बना सकते हैं। किसी दूसरी चीज़ से शुरू करने के लिए, जैसे API call या नया pull request खुलने जैसा GitHub event, Routine का web page खोलकर trigger add करें।

अगर CLI में /schedule missing लगे, तो Routines appendix में check करने वाली चीज़ें दी गई हैं।

अपने cron से एक prompt चलाएँ (laptop चालू, Anthropic cloud नहीं)। claude -p एक prompt चलाकर exit करता है। इसे सीधे computer के 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

पहली real Routine बनाने के लिए, जिसमें हर form field, तीनों triggers, secrets और common problems शामिल हैं, course के अंत में Routines appendix step by step मदद करता है।

एक set करें, फिर सो जाएँ: Sky Watch

Schedule एक ऐसा heartbeat है जिसे fire होते नहीं देख सकते, क्योंकि midnight तब आती है जब आप देख नहीं रहे होते। इसलिए Sky Watch project को रात भर अकेला छोड़ने के लिए बनाया गया है। हर सुबह यह NASA की asteroid feed check करके note छोड़ता है: आज Earth के पास क्या गुजर रहा है और क्या उसमें से कुछ dangerous है।

इसे clone करें और पहले हाथ से साबित करें कि यह काम करता है:

what asteroids are coming this week?

आपको plain-English watch मिलता है: "चिंता की कोई बात नहीं, सबसे पास वाला asteroid Moon से 23× दूरी पर गुजरता है, सब clear है।" फिर एक line से इसे loop बनाएँ:

/schedule every day at midnight, run the sky-watch skill for today and write me the forecast

Laptop बंद कर दें। सुबह watch तैयार होगा, ऐसी machine ने लिखा होगा जो आपकी कभी थी ही नहीं, उस समय जब आप सो रहे थे। Email connector attach करने पर visual card inbox में आ सकता है, जिसमें हर pass proximity bar की तरह draw होगा। ध्यान दें कि prompt for today कहता है, "week ahead" नहीं: daily run को उसी दिन की report देनी चाहिए जिस दिन वह fire होता है, वरना हर सुबह कल का forecast दोबारा भेजेगा। Window को cadence से match करें।

दो बातें इसे schedule बनाती हैं, Concept 7 की doorbell नहीं। यह पीछे नहीं, आगे देखता है: कल के pass की warning देता है, बीते दिन की report नहीं। और कुछ न होने पर भी बोलता है। अधिकांश सुबह सिर्फ़ "all clear" कहेगा और watch के लिए वही quiet report मकसद है। Event-driven loop शांत दिन में चुप रहता है। Schedule फिर भी report करता है। Midnight की प्रतीक्षा किए बिना practice करने के लिए पहले one-off fire करें (/schedule in 2 minutes, run the sky-watch skill), क्योंकि one-offs daily cap में count नहीं होते। यह Part 6 का rule वास्तविक बनाता है: slow और unattended भरोसा करने से पहले fast और watched तरीके से साबित करें।

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

Optional: community scheduling plugins

opencode-scheduler जैसे community plugins plain-language request को operating-system schedule में बदल सकते हैं। वे overlapping runs रोक सकते हैं और human answer का इंतज़ार करने वाले prompts reject कर सकते हैं। ये third-party plugins हैं, इसलिए किसी पर depend करने से पहले check करें कि वह actively maintained है।

Cloud, GitHub Actions के साथ (आपकी कोई machine on होने की ज़रूरत नहीं)। नीचे की model string सिर्फ़ example है। आपके 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-5   # confirm with `opencode models`
          prompt: |
            Review the codebase for TODO comments and summarize them.
            If any are worth acting on, open an issue to track them.

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

आसान शब्दों में

Claude Code Routine Anthropic के servers पर चलती है। OpenCode schedule आपके operating system या GitHub Actions से चलता है। दोनों चुने हुए समय पर fresh work शुरू करते हैं, इसलिए दोनों को model के बाहर saved state चाहिए।

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

Optional technical detail है; पहली reading में छोड़ सकते हैं।

Current official docs में OpenCode GitHub Action anomalyco/opencode/github@latest लिखा है। कुछ पुराने guides अब भी sst/opencode/github@latest दिखाते हैं। दोनों उसी project की ओर जाते हैं। वही इस्तेमाल करें जो opencode github install generate करता है। Models में Claude Sonnet 5 अब current Sonnet tier है (API ID claude-sonnet-5, क्योंकि major-version releases minor number छोड़ देते हैं)। यह Sonnet 4.6 का direct replacement है, जिसका pinned ID अब भी valid है। Loop builder को दो बातें जाननी चाहिए: adaptive thinking default रूप से on है और नया tokenizer उसी text के लिए लगभग 30% अधिक tokens बनाता है, इसलिए 4.6 पर मापे token budgets बिना बदलाव के लागू नहीं होते। Dateless IDs 4.6 generation के साथ आए, जहाँ dateless string ही pinned snapshot है। पुराने 4.5-generation models, जैसे Haiku 4.5, का dated canonical ID (claude-haiku-4-5-20251001) और latest snapshot की ओर जाने वाला dateless claude-haiku-4-5 alias दोनों हैं। नीचे examples reproducibility के लिए dated Haiku ID pin करते हैं। Model generations इस किताब से तेज़ बदलती हैं। किसी exact string को pin करने से पहले opencode models चलाएँ और नए release के missing होने पर model list refresh करें।

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

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

Doorbell चलाकर देखें (30 seconds)

यह बिना clock और watcher के idle रहता है। फिर कुछ होता है: PR, message या alert। Loop आते ही react करता है, हर event अपने route पर जाता है और फिर loop दोबारा quiet हो जाता है।

खोलें ↗

इस section की बनावट

यह section events के बारे में है। Event का मतलब बस किसी चीज़ का होना है। हर तरह के event का एक catcher होता है, यानी उस पर react करने वाला tool, और सभी catchers एक जैसे नहीं हैं। GitHub events और "बाकी सभी" events को Routine पकड़ती है। Chat messages को Channel पकड़ता है। इसलिए तीन catchers में दो Routines हैं और एक Channel है। Channel की एक कमजोरी, कि उसे आपकी machine चालू चाहिए, नीचे table में साफ़ दिखाई गई है।

Claude Code में event कहाँ से आता है, इससे तय होता है कि कौन सा tool इस्तेमाल करें। तीन routes हैं:

1. GitHub से आने पर Routine इस्तेमाल करें। Routine को clock पर चलना ज़रूरी नहीं। उसका trigger GitHub event भी हो सकता है। दो तरह के events काम करते हैं: pull request में बदलाव, जब वह खुले, update हो या merge हो, और release publish होना। उदाहरण: "PR खुले तो review करके comment करें" या "release publish हो तो changelog draft करें।"

किसी एक को बनाने से पहले तीन विवरण मायने रखते हैं:

• Setup. Claude GitHub App repository पर install होनी चाहिए। /web-setup clone access देता है, App install नहीं करता। यह फ़र्क़ कई first attempts को confuse करता है।
• Pushes. अलग push trigger नहीं है। लेकिन open PR वाली branch पर नया commit push हो, तो GitHub उसे PR update, यानी synchronized event, report करता है और Routine fire होती है। PR के बिना branch पर push कुछ fire नहीं करता।
• Filters। Author, title, labels, branch, draft state और दूसरे fields के आधार पर तय कर सकते हैं कि कौन से events इसे fire करें। पूरी field list, hourly limits और मुश्किल details Routines appendix के A3 में हैं।

2. Chat app से आने पर Channel इस्तेमाल करें। Channel किसी बाहर की app का message सीधे ऐसे session में डालता है जो पहले से चल रहा है। Telegram, Discord और iMessage built-in काम करते हैं। किसी और source के लिए webhook setup करते हैं। यह Part 2 की doorbell है: message आने तक कुछ नहीं होता, फिर session तुरंत react करता है।

उदाहरण के लिए, desk से दूर रहते हुए Telegram पर पूछ सकते हैं, "Deploy पूरा हुआ?" मौजूदा session अपने current context, skills और history के साथ check करके reply करता है। Loop उसी Channel से reports वापस भी भेज सकता है।

दो सावधानियाँ:

• Live session चाहिए। Session पहले से चलना चाहिए, जैसे open terminal या background session, इसलिए machine बंद होने पर Channel काम नहीं करता।
• यह खुला दरवाज़ा है। उस source पर message भेज सकने वाला कोई भी व्यक्ति आपके session को steer कर सकता है, इसलिए सिर्फ़ अपने control वाले sources connect करें।

Setup: code.claude.com/docs/en/channels।

3. बाकी किसी source के लिए API trigger वाली Routine इस्तेमाल करें। कुछ events GitHub या chat app से नहीं आते: monitoring tool में alert fire होना, deploy पूरा होना या form submit होना। Routine को API trigger दें। फिर authenticated web request भेज सकने वाला कोई भी system laptop बंद होने पर इसे fire कर सकता है। Request event की details भी ला सकती है: optional text field saved prompt के साथ run-specific context, जैसे alert message या failing log, देता है। Endpoint, token और retry warning Routines appendix के A3 में हैं।

चारों में से चुनना:

Event कहाँ से आता है…	क्या इस्तेमाल करें	काम कहाँ चलता है…	Laptop बंद?
GitHub (PR या release)	GitHub trigger वाली Routine	हर event के लिए fresh cloud session	काम करता है
GitHub, Routine के बिना	CI में Claude Code GitHub Action	हर event के लिए fresh CI runner	काम करता है
Chat message (Telegram, Discord, iMessage)	Channel	आपका पहले से चलता session	नहीं, machine चाहिए
Web request भेज सकने वाली कोई भी चीज़	API trigger वाली Routine	हर call के लिए fresh cloud session	काम करता है

दूसरी row जितनी दिखती है, उससे अधिक important है। Laptop बंद रहने पर काम जारी रखने का Routine अकेला तरीका नहीं है। GitHub Actions workflow में anthropics/claude-code-action@v1 वही काम करता है और इसके लिए research-preview access या daily run cap नहीं चाहिए। Pro या Max plan काफ़ी है: claude setup-token ऐसा credential देता है जिसे runner इस्तेमाल कर सकता है, इसलिए API key भी नहीं चाहिए। Unattended work का यह सबसे सस्ता रास्ता है।

चारों rows के नीचे का rule यही है। सवाल कभी "क्या यह Routine है?" नहीं, बल्कि "काम किसके computer पर चलता है?" है। आपका computer बंद करने पर रुक जाता है। Anthropic के servers और GitHub runners नहीं रुकते, क्योंकि वे कभी आपके थे ही नहीं। इसी कारण इन rows को token चाहिए और /loop को नहीं: आपका laptop पहले से जानता था कि आप कौन हैं, rented stranger नहीं जानता। Credentials की ज़रूरत और बंद lid के बाद भी चलना एक ही fact के दो पहलू हैं।

Channel को छोड़कर हर row में pattern देखें: हर event fresh session शुरू करता है, इसलिए दो events एक-दूसरे के बारे में कुछ नहीं जानते। एक PR पर दो pushes दो अलग sessions हैं। Spine, यानी Concept 12, उन्हें state share कराता है।

खुद ring करें: Doorbell

ऊपर वाला paragraph ऐसी claim है जिसका कोई अर्थ नहीं, जब तक आप उसे होते न देखें। इस concept के लिए छोटा project The Doorbell है। यह सिर्फ़ एक काम करता है: ऐसे pull request को review करता है जिसे किसी ने review करने को नहीं कहा।

इसकी kit अपने repo में copy करें, claude setup-token से token बनाएँ, उसे एक secret के रूप में add करें और bug वाला pull request खोलें। लगभग एक minute बाद review दिखता है। आपने कोई prompt type नहीं किया। कोई देख नहीं रहा था।

फिर वह हिस्सा करें जिससे बात समझ आती है: laptop बंद करें और किसी और से PR खुलवाएँ। Review फिर भी दिखता है। यही एक action में Concept 4 का अंतर है। Terminal बंद करने पर ISS loop मर जाता है, क्योंकि वह आपकी machine पर चल रहा था। यह loop कभी आपकी machine पर था ही नहीं। Doorbell बजने पर GitHub computer rent करता है, वहाँ काम चलाता है और machine फेंक देता है।

इससे token भी समझ आता है। आपका laptop पहले से जानता था कि आप कौन हैं। Rented stranger नहीं जानता। हर unattended loop यह कीमत देता है।

एक बात expect करें, क्योंकि इसने हमारा एक hour लिया: green checkmark का मतलब यह नहीं कि काम हुआ। एक setting छूटे तो run success होता है, review करता है और कुछ भी post नहीं करता। Project README setting और symptom बताता है। यह Routine के बजाय Claude Code GitHub Action इस्तेमाल करता है: वही doorbell, preview access नहीं और daily cap नहीं।

और ending ऊपर के paragraph को prove करती है। दूसरी बार push करें। नया review आपके पहले commits को सही hash से cite करेगा, जबकि वह ऐसी machine पर चल रहा है जो पहले कभी थी ही नहीं और कुछ याद नहीं रखती। उसने याद नहीं रखा। उसने repo पढ़ा। यही spine है, जिसे Part 4 में ठीक से समझेंगे।

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-5
          use_github_token: true
          prompt: |
            Review this pull request for bugs, quality issues, and security risks.

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

आसान शब्दों में

समय काम शुरू करे तो schedule इस्तेमाल करें। Pull request खुलने या message आने जैसी outside action काम शुरू करे तो event इस्तेमाल करें।

खुद को जाँचें

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

जवाब दिखाएँ

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

सबसे हल्का loop चुनें जो काम के लिए काफ़ी हो

अब आप चार heartbeats जानते हैं। सबसे बड़े को default न मानें। हर loop दो choices से define होता है: उसे क्या शुरू करता है और क्या रोकता है। इसलिए कुछ बनाने से पहले task के बारे में एक सवाल पूछें: क्या यह खत्म होता है, या repeat होता है?

• Task खत्म होता है और command उसका अंत prove कर सकती है → conditional loop। अभी शुरू करें और done होने तक चलने दें।
• Task repeat होता है → schedule या event।
• Task एक बार होता है → loop की ज़रूरत नहीं। Ordinary session, एक turn at a time, सही tool है। अधिकांश काम के लिए यही अब भी सही है।

एक और rule: नया repeating loop unattended trust करने से पहले उसके पहले कुछ real runs देखें। Part 6 इसे rule बनाता है: overnight इस्तेमाल से पहले loop को prove करें।

Names पर आख़िरी note। Online लोग ये words loosely इस्तेमाल करते हैं। "Turn-based" ordinary session है। "Goal-based" हमारा conditional loop है। "Time-based" हमारे दो kinds, in-session और scheduled, को मिला देता है, जबकि अब आप जानते हैं कि वे अलग हैं। "Proactive" Part 5 जैसा fully composed loop है। Labels अलग हैं, parts वही हैं।

---

Practice: heartbeat चुनें, फिर एक बनाएँ

अब आप चारों heartbeats जानते हैं। चारों pictures fresh हैं, इसलिए किसी एक को इस्तेमाल करने का यही best moment है। दो steps हैं। पहले prove करें कि सही heartbeat चुन सकते हैं। फिर किसी एक को शुरू करें।

Step one: चुनें (2 minutes, कुछ install नहीं करना)। नीचे हर task के लिए heartbeat का नाम बताएँ। इनमें एक trap है।

1. हर Friday, team के लिए उस week के merged pull requests की summary draft करें।
2. इस failing build पर तब तक काम करते रहें जब तक वह green न हो जाए, फिर रुकें।
3. कोई pull request खोले और उसे review मिलना चाहिए।
4. 40-minute migration चल रही है और खत्म होते ही जानना चाहते हैं।
5. पूरे repo में एक variable rename करें।

Answers दिखाएँ

1. Scheduled। यह clock पर repeat होता है और किसी के मौजूद होने की ज़रूरत नहीं। Routine या cron line, Concept 6।
2. Conditional, यानी run-until-done। यह खत्म होता है और command उसका अंत prove कर सकती है। /goal या capped shell loop, Concept 5।
3. Event-driven। Outside action इसे शुरू करती है, इसलिए शांत दिन में zero times fire होता है, Concept 7।
4. In-session। आप अब भी देख रहे हैं और session बंद करने पर यह रुक सकता है। /loop या sleep वाला while loop, Concept 4।
5. कोई loop नहीं। Task एक बार होता है, इसलिए ordinary session सही tool है। अगर यहाँ loop चुना, तो ऊपर वाला tip दोबारा पढ़ें। Course के बाद भी अधिकांश काम इसी row में रहेगा।

Step two: एक बनाएँ। हर heartbeat के लिए course के अंत में project है। चारों अभी न करें। दो तैयार हैं और दो जानबूझकर आगे के उन parts तक जाते हैं जिन्हें आपने अभी नहीं पढ़ा:

Heartbeat	Concept	इसे कहाँ बनाएँ	अभी ready?
In-session	4	Project 1, watch loop	हाँ
Conditional	5	Project 2, tests pass कराएँ, फिर रुकें	हाँ
Scheduled	6	Project 3, memory वाली morning brief	Part 4 के बाद, इसे spine चाहिए
Event-driven	7	Project 6, doorbell loop	Part 3 के बाद, इसे connectors चाहिए

आख़िरी column पर ध्यान दें। Memory के बिना schedule हर सुबह वही first step दोहराता है और PR न खोल सकने वाला event-driven loop सिर्फ़ बात कर सकता है। इसलिए आपके बिना चलने वाले दोनों heartbeats को course के बाकी हिस्सों की सबसे अधिक ज़रूरत है। यह padding नहीं, system की बनावट है।

Project 1 सबसे सस्ता possible start है: लगभग 15 minutes, configure करने के लिए schedule नहीं और ऐसी कोई चीज़ नहीं जो आपके दूर होने पर चल सके। Part 3 से पहले सिर्फ़ एक काम करें, तो यही करें।

---

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 न चुकाएँ।

Loop में होने के कारण connector को तीन चीज़ें चाहिए

Loop retry करता है और unattended tools चुनता है। इससे अच्छे tool set की requirements बदल जाती हैं:

• बहुत से overlapping tools से कम, focused tools बेहतर हैं। Tool चुनना ऐसा decision है जिसे model हर beat पर लेता है, जबकि कोई देख नहीं रहा। सौ overlapping tools देने पर वह सही tool खो देता है। Practitioners ने पाया कि available tools कम करने से success rate बढ़ती है। Anthropic का rule of thumb: human engineer confidently न बता सके कि कौन सा tool fit है, तो agent भी नहीं बता सकता। हाथ से गलत tool pick एक moment खर्च करता है। Loop में हर बार एक पूरा beat खर्च होता है। Connector list को सिर्फ़ loop की ज़रूरत तक trim करें। Routines appendix safety के लिए यही कहता है; दोनों reasons सहमत हैं।
• Writes repeat करने के लिए safe होनी चाहिए। Failed step retry करने वाला loop वही write फिर call करेगा। Retried "create customer" दूसरा customer बना दे तो duplicate records और double billing होते हैं। Blind creates के बजाय repeat-safe operations चुनें, जैसे update-or-create या one PR per branch।
• Errors को अगला action बताना चाहिए। Loop में error message अगले beat का input है। "Permission denied: request the repo scope" अगले try में खुद fix हो सकता है। "Error 403" एक beat waste करता है।

हाथ से आप इन तीनों problems को बिना notice किए absorb करते हैं: सही tool चुनते हैं, duplicate skip करते हैं और error search करते हैं। Unattended run में इन्हें absorb करने वाला कोई नहीं होता।

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 में primary agents Build और Plan हैं। तीन subagents भी हैं: general, explore और scout। Scout read-only है और external documentation तथा dependency research के लिए इस्तेमाल होता है। Additional agents को opencode.json या agents folder की markdown files में define कर सकते हैं।

Checker को अपना model दें, जो अक्सर सस्ता और read-only हो सकता है। Maker उसे @ mention या Task tool से call कर सकता है। Common design में strong model explore और implement करता है, फिर focused model result check करता है।

Loop में दो settings ख़ास important हैं: हर agent के लिए steps limit, Concept 5, और ऐसे permission.task rules जो subagent को आगे subagents शुरू करने से रोकें। Limits न हों तो agents work को circles में delegate करके unnecessary tokens खर्च कर सकते हैं।

---
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 कर सकते हैं।

इसे plain words में माँगें ("use a workflow to…"), ultracode keyword से शुरू करें, या built-in /deep-research चलाएँ। पुराना workflow trigger word mid-2026 में retire हो गया; आप क्या चाहते हैं, वह describe करना अब भी काम करता है। Run मनचाहा काम करे तो /workflows view में s दबाकर script को /command की तरह save करें, ताकि हर branch पर फिर चला सकें। Guardrails इसे honest रखते हैं। Agents capped हैं, लगभग 16 एक साथ और 1000 per run, इसलिए runaway script spiral नहीं कर सकता। Validation में लगातार fail होने वाले subagents कुछ tries के बाद हमेशा loop करने के बजाय रुक जाते हैं। और run की memory सिर्फ़ उसी run में रहती है: same 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 लगने पर यह सबसे आसान mistake है। Dynamic workflow एक बार चलता है, जब आप या ultracode setting इसे शुरू करते हैं, और end होने पर सब भूल जाता है। उसका heartbeat या spine नहीं है। इसलिए वह एक beat की body है, loop नहीं। Loop combination है: heartbeat (Routine, /loop या cron) beat fire करता है, workflow उस beat पर चलने वाली body है और agents की लिखी progress file वह spine है जिसे अगली firing पढ़ती है। Literal terms में: workflow एक run करता है, trigger बाद के runs शुरू करता है और progress file उनके बीच information रखती है।

Memory aid: workflow engine है, Routine key घुमाती है और progress.md अगली trip तक information ले जाता है।

खुद को जाँचें

आपका loop एक साथ दो agents चलाता है और आप उन commits पर भी trust करना चाहते हैं जो वह आपके दूर रहते करता है। ये दो अलग problems हैं। Body का कौन सा part हर problem solve करता है?

Answer दिखाएँ

Worktrees parallel problem solve करते हैं: हर agent का अपना checkout होता है, इसलिए edits collide नहीं करते। Maker-checker trust problem solve करता है: separate agent work grade करता है, इसलिए आपके देखे बिना भी "done" का अर्थ रहता है। लोग दोनों को मिलाते हैं। Isolation agents को एक-दूसरे के रास्ते से हटाती है। Checker bad work को repo से बाहर रखता है। अलग reasons से दोनों चाहिए।

Interlude: Checker को verification skills से codify करें

पिछले interlude ने beat की body codify की। यह checker codify करता है। July 2026 में Anthropic की Claude Code team ने इसी विषय पर guidance publish की और इसे verification loop कहा: agent काम check करता है और check pass होने तक बार-बार fix करने की कोशिश करता है। आप इस loop को इस किताब के नाम से पहले मिल चुके हैं। यह agentic coding course का Attempt → Check → Fix → Repeat cycle है, जिसे Boris Cherny tool इस्तेमाल करने का सबसे important tip कहते हैं।

पहले names पर note, ताकि "loop" confuse न करे। Verification loop एक beat के अंदर चलता है। उसका अपना heartbeat या spine नहीं होता। Beat end होते ही वह भी end हो जाता है। इस course की vocabulary में यह small-loop machinery है। इस chapter में इसकी जगह आगे की बात से बनती है: वही check, एक बार लिख दिए जाने पर, heartbeat के fire करते ही big loop का checker बन जाता है। Part 5 का reviewer agent इसी तरह के written check के against grade करता है। इसलिए यह section उस एक move के बारे में है जिसमें आपके दिमाग़ का check एक file बन जाता है।

कौन से checks लिखें। Test simple है: agent के finish होने पर जिस चीज़ को आप हर बार हाथ से correct करते हैं, वह check लिखने लायक है। हर frontend change के बाद manual click-through, "क्या error logs से request body हटाई?" sweep या approve करने से पहले हर बार पढ़ी जाने वाली migration। Procedure को plain English में वैसे लिखें जैसे first day पर new teammate को देते। साफ़ न लिख सकें तो agent से पहले standard best-practice version माँगें, फिर edit करें। आपका version कुछ specific points पर अलग होगा और वही differences लिखना सबसे valuable है। Standard part model पहले से जानता है; project-specific part आपकी असली knowledge है।

Check को judgment call होना ज़रूरी नहीं। "Column drop करने वाली migration को backfill step के बिना reject करें" fixed rule है जिसे command prove कर सकती है, लेकिन कोई general-purpose linter include नहीं करेगा, क्योंकि यह आपका rule है। Concept 2 की checker ladder में एक rung आसानी से छूटता है: tools के mechanical checks और reviewer की rubric के बीच mechanical checks की ऐसी layer है जो सिर्फ़ आप लिख सकते हैं। Rubric से इस rung पर आने वाला हर rule claim को proof बनाता है।

Packaging एक skill है। Concept 9 से container जानते हैं: task match होने पर agent जो SKILL.md load करता है। Verification skill उसी container में procedure के बजाय check रखती है। पूरा example एक screen में आता है:

# .claude/skills/verify-log-hygiene/SKILL.md  (or .opencode/skills/…)
---
name: verify-log-hygiene
description: Check that error logs include the request ID and never
  include the request body. Use when the diff touches error handling
  or logging.
allowed-tools: [Read, Edit, Grep]
---

Read the error-handling paths in the current diff.

For each log call on an error path, confirm it includes the request ID
and does not pass the request body, headers, or any user-supplied
payload.

Report each violation with file:line, then fix it: add the request ID
where it's missing and strip the payload from the log call.

allowed-tools line देखें: यह check read, edit और search कर सकती है, और कुछ नहीं। यह Concept 14 का standing-permission idea है, check पर लागू किया गया। Part 5 के reviewer की tools line की तरह इसमें tool names आते हैं, individual commands नहीं। किसी check को specific commands तक pin करना enforcement layer है, जो अगले course Harness Engineering में है।

Check कहाँ चलता है। Anthropic की guidance यहाँ course में सचमुच कुछ नया जोड़ती है: एक check के चार possible homes हैं और हर home का heartbeat अलग है।

1. Standalone। Work बनने के बाद आप जानबूझकर invoke करते हैं। Course की vocabulary में आप अब भी heartbeat हैं। यह उन checks का सही home है जो कई kinds of work पर apply होते हैं, हर change पर नहीं: pre-commit security scan, licence-header sweep या pre-PR accessibility audit। Cost यह है कि invocation का turn आपको याद रखना पड़ता है।
2. Embedded। Check producing skill के end में append होती है, इसलिए workflow बिना पूछे चलाता है। Simplest version एक added line है: "Component बनाने के बाद उस पर eslint run करें और completion report करने से पहले errors ठीक करें।" Fresh task पर skill invoke करके confirm करें कि check output के part के रूप में run होती है। न चले तो earlier instructions उसे load नहीं कर रहे। Hard limit: embedding सिर्फ़ उन skills पर काम करता है जिन्हें आप edit कर सकते हैं। Built-in और plugin-managed skills update पर overwrite होती हैं, इसलिए appended check चुपचाप गायब हो जाती है। उनके लिए chain करें।
3. Chained। एक skill end में दूसरी call करती है, इसलिए कई verified handoffs end to end चलते हैं। Anthropic की Claude Code team इसे daily करती है: /code-review bugs ढूँढता है, /simplify diff clean करता है, /verify end-to-end behavior confirm करता है और custom /design skill UI changes को DESIGN.md के against check करती है। जिस skill को modify नहीं कर सकते, उसमें verification जोड़ने का यही तरीका है: thin wrapper skill original invoke करे, फिर check invoke करे। याद रखने वाली line: habit ("मैं बाद में हमेशा check चलाता हूँ") contract बनती है (skill finish होने पर हमेशा check चलाती है)। Trade-off real है। Chaining flexibility कम करती है और हर link हर run में tokens खर्च करता है, Concept 13। Steps independent हों और कभी सिर्फ़ एक चाहिए, तो chain न करें।
4. हर PR पर। Chain अपने changes पर solid हो जाए, तो Concept 7 का event heartbeat हर pull request पर वही skills चलाता है: Doorbell, लेकिन prompt आपकी check है। Teammate का change भी वही gates pass करता है, चाहे किसी ने manually invoke करना याद रखा हो या नहीं। यहाँ verification personal infrastructure से team infrastructure बनती है: जो check आपने weekly two minutes बचाने के लिए लिखी थी, वह हर change पर पूरी team के two minutes बचाती है।

Graduation rule। Home four से शुरू न करें। Standalone home छोड़ने का signal है कि आप खुद को हर change के बाद check चलाते पाते हैं। तब उसने permanent home earn किया है, इसलिए embed या chain करें। Chain बदल रही हो तो PR-wide gate न बनाएँ, क्योंकि team PRs guard करने के बाद उसमें हर change पूरी team को दिखाई देगा। ये Part 6 के वही दो rules हैं: slow और unattended trust करने से पहले fast और watched में prove करें। Check वही trust ladder चढ़ता है जो loop चढ़ता है।

तीन shortcuts, late July 2026 तक current:

• जो ship होता है, उससे शुरू करें। Built-in /verify skill application के changes को build, run और observe करती है। अपनी skill लिखने से पहले इसे try करें। उसी guidance की एक छोटी CLAUDE.md habit: rules file में exact build और test commands list करें, ताकि किसी run को guess न करना पड़े। Concept 12 से कारण जानते हैं: guessed command ऐसा guess है जिसे loop हमेशा दोहराता है; written command ऐसा fact है जिसे वह पढ़ता है।
• Agent को interview करने दें। Verification skill लिखने का fastest तरीका skill-creator plugin है: /skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow. वह पूछता है, आप answer देते हैं और file बनती है। .claude/skills/ में hand-writing Concept 9 की तरह ही काम करता है।
• Managed fourth home। Code Review (research preview) home four का product version है: enabled repos के PRs पर automated review pass चलाने वाली managed multi-agent service। Finding fix करके push करें या, अगर Concept 7 का GitHub Action setup है, finding पर @claude comment करके reply करें। वही shape जो hand-built chain की है, लेकिन Anthropic heartbeat और reviewers host करता है।

कुछ नया install नहीं करना, यही point है। ऊपर वाला SKILL.md .opencode/skills/ से unchanged काम करता है और चार homes पहले से बने parts पर map होते हैं:

• Standalone है opencode run "run the verify-log-hygiene skill on the current diff"।
• Embedded आपकी producing skill की body में वही one-line append है।
• Chained आपकी script है, यानी Concept 5 pattern, जहाँ हर skill की exit state तय करती है कि अगला opencode run fire हो या नहीं। Shell contract रखता है।
• हर PR पर Concept 7 का GitHub Action है, prompt में check के साथ। पहले देखा default no-prompt PR review OpenCode parts से बना Anthropic का /code-review idea है। Verification skill की ओर point करता prompt generic standards के बजाय आपके standards बनाता है।

आसान शब्दों में

Verification skill वह manual check है जो आप पहले से कर रहे थे, एक बार लिखी हुई, ताकि agent उसे run करके मिली problems fix करे। पहले खुद invoke करें। हर बार चलाने का pattern दिखे तो workflow से attach करें। पूरी chain आपके लिए काम करे, तभी हर PR पर रखें।

Neighboring courses इसे कहाँ आगे ले जाते हैं

दो topics जानबूझकर neighboring courses के लिए छोड़े गए हैं। Enforcement, यानी check को command by command checking से आगे कुछ करने में unable बनाना, Harness Engineering course में है। allowed-tools toolbox narrow करता है, real locks उस course में हैं। Grading, यानी check proof के बजाय rubric हो और model score पर कितना trust करें, Trusting the Checker course में है। उसी दूसरे course से जुड़ा product note: Rubrics in Claude Managed Agents (beta) Concept 2 की rubric-with-a-bar को managed service बनाता है। Separate grader agent outcomes को rubric के against verify करता है और failed work automatically another attempt पर जाता है। Hand-built shape अब platform primitive है। हमेशा की तरह यह mechanical layer है: live docs check करें।

खुद को जाँचें

आपने शानदार accessibility check लिखी और चाहते हैं कि आज से पूरी team के PRs इसे pass करें। Check दो बार चली है, दोनों बार आपने खुद हाथ से invoke किया। Graduation rule क्या कहता है और कौन से two homes skip हो रहे हैं?

Answer दिखाएँ

अभी नहीं। हाथ से दो invocations का मतलब check अभी standalone home में है और promotion earn करने वाला pattern, हर change के बाद चलना, prove नहीं हुआ। सीधे हर PR पर जाना embedded और chained homes skip करता है, जहाँ check पहले आपके work पर prove होती है। Team PR gate बनने के बाद check में हर fix पूरी team को दिखता है। Part 6 जैसी ladder: unattended से पहले watched, team से पहले personal।

---

Part 4: Runs के बीच memory (The Spine)

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

Beginners जिस हिस्से को छोड़ देते हैं, वही loop को loop बनाता है। Model runs के बीच सब कुछ भूल जाता है। हर beat zero से शुरू हो तो loop नहीं, वही first step हमेशा repeat होता है। Fix boring और powerful है: state को model के बाहर, disk पर रखें।

Save file चलाकर देखें (40 seconds)

Save file न हो तो agent हर run में उन्हीं spikes पर मरता है। फिर वह save करता है और switch आपके हाथ में आता है। On पर file पढ़कर finish करता है। Off पर भूलकर फिर शुरू करता है।

खोलें ↗

वही game यह concept है। Agent runs के बीच सब भूलता है, इसलिए disk पर save file रखता है और वही spine है। Start के बजाय checkpoint से respawn होना आपकी progress file (progress.md) है: क्या हुआ और क्या open है, ताकि next run zero से शुरू न हो। "Spikes आगे हैं" वाला saved note rules file (CLAUDE.md / AGENTS.md) है: एक बार सीखा lesson, ताकि वही mistake repeat न हो। Files हों तो loop हर run पर build करता है; files न हों तो start line पर हमेशा stranger रहता है। हर run इन files को पहले read और आख़िर में update करता है, क्योंकि repo वह याद रखता है जो model नहीं रख सकता।

State की दो layers साथ काम करती हैं:

• Rules file (CLAUDE.md / AGENTS.md): steady habits जिन्हें loop हर run पढ़ता है। इसे छोटा रखें। Bloated rules file की cost हर beat पर चुकती है।
• Progress file: plain Markdown file, या MCP से Linear board, जो record करती है क्या try हुआ, क्या pass हुआ और क्या open है। यही real spine है। कल 9am का run इसे खोलकर वहीं से चलता है जहाँ आज रुका था।

Habit: हर run शुरुआत में progress file पढ़ता है और end में update करता है। Loop वही mistake repeat करे तो fix smarter prompt नहीं है। Lesson rules file में लिखवाएँ, ताकि हर future run में रहे।

Intern की diary

दो state layers abstract लगें तो new intern सोचें। Context एक बार set करते हैं: workflow, ticket board, allowed tasks और कब आपसे पूछना है। फिर diary और दो standing instructions देते हैं। पहला: feedback मिले तो lesson diary के front में लिखें और हर morning पढ़ें। जैसे "यह design pattern न इस्तेमाल करें", "team commits squash करती है", "दिखाने से पहले linter हमेशा run करें"। दूसरा: घर जाने से पहले back में लिखें कि क्या finish हुआ और कहाँ रुके, ताकि tomorrow zero से नहीं, आज के checkpoint से शुरू हो। Front rules file है: durable lessons, हर run पढ़े जाते हैं। Back progress file है: checkpoints, हर run update होते हैं। Diary के बिना intern वही corrections और yesterday का work repeat करता है। Loop भी करता है, क्योंकि model memory पूरी तरह wipe होती है। Diary nice-to-have नहीं; employee और रोज़ आने वाले stranger का अंतर है।

<!-- 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 है, इसलिए आपके दूर रहने पर loop ने क्या किया उसका record भी है। Human gate पर हर run का transcript नहीं, spine पढ़ते हैं।

Loop को भूलते, फिर याद करते देखें: Paper Watch

Spine पर भरोसा तब होता है जब loop को भूलते देखें। Paper Watch आपके चुने topic के newest research papers दिखाता है, लेकिन केवल वे जो पहले नहीं देखे। कुछ install नहीं और key नहीं: Claude arXiv से खुद fetch करता है।

Clone करके agent में folder खोलें और पूछें:

show me what's new on arXiv about "LLM agents"

Latest papers newest-first मिलते हैं। अब exact same thing फिर पूछें और जवाब आता है "nothing new since last run ✓"। Loop ने याद रखा: दिखाए papers progress.md में लिखे और answer से पहले file पढ़ी। वही spine है। Prove करने के लिए memory delete करके फिर पूछें:

rm progress.md
show me what's new on arXiv about "LLM agents"

हर paper फिर "new" है। एक command में loop ने सब भुला दिया: spine नहीं, loop नहीं। Real watch बनाने के लिए daily heartbeat दें: /schedule every weekday at 9am, run the paper-watch skill and show me what's new। arXiv लगभग once daily refresh होता है, इसलिए daily rhythm सही है।

इसे Concept 6 के Sky Watch के साथ रखें। दोनों daily Routines हैं। Sky Watch हर run में आज के asteroids print करता है और memory नहीं चाहिए। Paper Watch सिर्फ़ new दिखाता है और spine के बिना काम नहीं कर सकता। Same heartbeat, opposite memory need। यही बताता है कि loop को memory कब चाहिए।

Industry files पर converge हुई

First read में optional background है।

इस course की spine disk पर plain Markdown है। यह beginner simplification नहीं है। Alternatives के एक year बाद Anthropic का memory work भी यहीं पहुँचा; उनका stated rule है "वही simple thing करें जो काम करती है"। Path जानना उपयोगी है:

1. Rules file (CLAUDE.md) पहले आई: हर session start पर inject होने वाली Markdown file। उम्मीद से बेहतर काम किया, लेकिन bloated हुई और हर run में उसकी cost लगी।
2. In-session memory tools बाद में आए: task के दौरान agent तय करे कि memories कब read/write करनी हैं। Autonomy ने काम किया, tooling बहुत opinionated थी।
3. Skills ने growth problem solve की: agent केवल short description पढ़ता है और full body on demand load करता है।
4. Current best practice सबसे simple है: memory को plain file system बनाएँ। Folders में Markdown files। Special memory API के बजाय agent को grep और shell जैसे ordinary tools से search करने दें। Store बड़ा हो सकता है, बस searchable रहे।

आख़िरी step यही spine है: repo की files, start में read, end में update, normal tools से search। Frontier lab का production answer और beginner का first loop same design इस्तेमाल करें तो design load-bearing है, training wheels नहीं।

वह loop जो loop को सुधारता है

First read में optional technical detail छोड़ सकते हैं।

Loop lesson को CLAUDE.md में लिखकर future runs बेहतर करे तो आप hill-climbing loop manually कर रहे हैं। उसका output work नहीं; work करने वाले system का improvement है।

Automatic version में हर run trace छोड़ता है। Step traces पढ़कर repeating mistakes ढूँढता है। Findings prompt, tools या checker rules बदलती हैं। Loop खुद को edit करता है।

LangChain चार stacked loops बताता है: agent tool cycle, checking loop, event-driven loop और ऊपर improvement loop। swyx stacking practice को loopcraft कहते हैं। पहले तीन इस course के inner loop, maker-checker और heartbeat हैं, दूसरे names में। Industry बार-बार same shape पर आती है; skill tool नहीं, shape है।

एक distinction इसे honest रखता है: model सीख नहीं रहा। कोई public model sessions से अपने weights नहीं बदलता। Tomorrow का model today जैसा है। Improve होता है उसके आसपास का system: rules file, skills, checker rubric और prompt। कुछ लोग पहले को self-learning और दूसरे को self-improving कहते हैं। इस course के loops second kind हैं। Lesson disk पर survive करता है, model में नहीं। Disappointing run के बाद beginner tomorrow better prompt के साथ zero से शुरू करता है। Loop run, log, lesson extract, system में write और फिर run करता है। Memory बनती है, system sharp होता है और gains compound करते हैं।

Special platform नहीं चाहिए। एक week की progress.md entries पढ़कर पूछें: "Rules file क्या कहे, ताकि यह mistake फिर न हो?" यही idea human speed पर है। Warning: unread improvement loop अपने rules खुद rewrite करता है। Loop के changes भी human gate deserve करते हैं।

Dreaming: improvement loop, product के रूप में और आपके द्वारा बनाया हुआ

First read में optional technical detail छोड़ सकते हैं।

Managed feature के रूप में hill-climbing loop मौजूद है। Anthropic applied AI team ने 2026 conference talk में इसे dreaming कहा: working agents के rest में चलने वाली process, जो उनकी learning clean करती है।

पहले vocabulary। In-band memory work live session के अंदर होता है: task रोककर agent lesson disk पर लिखता है, जैसा Concept 12 में। लेकिन agent task और future memory के बीच attention बाँटता है, और केवल अपना session देखता है, इसलिए ten sessions या ten agents में repeat हुई mistake नहीं देखता।

Dreaming out-of-band answer है। यह अलग loop है, अपना heartbeat और token budget लेकर। एक beat:

1. Memory store (rules और progress files) और recent run transcripts, tool calls समेत, collect करें।
2. Orchestrator transcripts analyst subagents में बाँटे।
3. Orchestrator cross-session patterns ढूँढे: same failing tool call, missing knowledge या style mistake।
4. Memory store changes evidence के साथ propose करे: example transcripts और frequency।
5. Human हर change accept या reject करे, लागू होने से पहले।

Course vocabulary में batch schedule heartbeat है, memory store spine है, analysts subagents हैं और evidence वाला proposal human decision में जाता maker-checker plus human gate है। Dreaming नई shape नहीं; six-part loop अपनी code के बजाय memory पर point करती है। Talk का picture school है: students work करते हैं, head teacher marked papers पढ़कर common failure देखता और curriculum fix करता है, बिना class time लिए।

Same talk की दो warnings: memories stale होती हैं, इसलिए six-month-old wrong lesson को prune करना चाहिए; dreaming का आधा काम यही है। और shared memory store को production guardrails चाहिए, जो Concept 14 की shared-memory note में हैं।

अपने tools पहले check करें, क्योंकि version ship हो रहा है। Claude Code का research-preview Auto Dream काम करते हुए project notes लिखता है। Sessions के बाद duplicates और contradictory old facts जमा होते हैं। Auto Dream background में उन्हें merge करता है, newer work से wrong proven notes delete करता है और सिर्फ़ memory files लिख सकता है, code नहीं। Availability के लिए /memory में Auto-dream toggle देखें। Manual pass के लिए "consolidate my memory files" कहें। OpenClaw opt-in /dreaming देता है और OpenCode community equivalents मिलते हैं। यह mechanical layer है; live docs check करें।

Cleaner newer evidence पर भरोसा करता है, इसलिए हाथ से लिखा note भी rewrite/delete कर सकता है। Rule रखें: कभी न बदलने वाला rule CLAUDE.md में है, जिसे सिर्फ़ आप control करते हैं। Auto-managed notes Claude की notebook हैं; CLAUDE.md आपकी है।

Auto Dream hygiene करता है, notes clean रखता है। नीचे वाला loop improvement करता है, repeated mistakes से new rules propose करता है। Cleaner और coach, same shape अलग job। Coach आप खुद बना सकते हैं:

1. Heartbeat weekly, daily नहीं। Cross-run patterns के लिए batch चाहिए। Weekly cloud Routine, cron या GitHub Actions schedule सही cadence है। Daily में patterns नहीं और cost multiply होती है।
2. Input: loops readable transcripts छोड़ें। Dated entry per beat in progress.md और repo में run logs। OpenCode में opencode run --format json तथा opencode export; Claude Code Routine outcome log file में append करके commit करे। Logs नहीं, dream material नहीं।
3. Body: orchestrator और analyst subagents। Last run से new logs पढ़ें, big batch बाँटें और पूछें: क्या fail हुआ, क्या same failure repeat हुई? One mistake noise है, three missing lesson।
4. Maker-checker twice। Analysts propose करते हैं, orchestrator evidence वाले patterns रखता है। Real checker: loop rules file या skill direct edit कभी नहीं करता। claude/ branch पर change draft करके PR खोलता है, description में runs, frequency और reason के evidence के साथ।
5. Human gate: आप merge या close करते हैं। CLAUDE.md या skill change highest-leverage write है, क्योंकि हर future run उसे पढ़ता है। Costly और hard-to-reverse जगह पर person decides।
6. Dreaming loop की spine: dreaming-state.md जैसी small file last reviewed batch की date रखती है, ताकि next week केवल new logs पढ़े।

Git store versioning और rollback free देता है; rule changes PRs हैं, इसलिए only-you-merge permission काफ़ी है। Staleness के लिए prompt deletions भी propose करे: unused rules और current logs से contradicted lessons। सिर्फ़ बढ़ती memory हर beat महँगी और हर month कम trusted होती है।

Dreaming loop के गलत होने के दो रास्ते

यह attack launder कर सकता है। Transcripts में outsider text होता है: issue bodies, PR descriptions और fetched pages। Memory poisoning में one-run input की instruction memory बनकर future runs steer करती है। Dreaming one-time injection को permanent rule बना सकता है। इसलिए evidence always: proposal source runs cite करे। Human gate always: rule change review skip न करे। Weekly rules read आपको unapproved line spot करने का chance भी देती है।

यह maintained चीज़ को erode कर सकता है। Repeated memory rewriting में brevity bias specifics गिरा देती है ("response payload check करें, status code नहीं" से "errors handle करें") और context collapse हर full rewrite की lossy copy से playbook को vague paragraph बना देता है। Defense: small diffs, full rewrites कभी नहीं। Git diff shrinking rules दिखाता है। Relative date न लिखें: "yesterday Redis चुना" six weeks बाद meaningless है। Consolidation actual date में convert करे और loops absolute dates लिखें।

Dream को material चाहिए। Three-run history या throwaway project में pattern नहीं; plausible lessons noise से बनेंगे। Real mileage वाले loops पर dream करें। Cheap check: काम करने वाला lesson वह failure है जो next week के logs में फिर नहीं आता।

वही warning: यह loop बाकी loops को steer करने वाले rules rewrite करता है। आपके सभी loops में human gate सबसे आख़िर में इसी से हटनी चाहिए।

Anthropic managed version को Managed Agents memory tooling के part के रूप में ship करता है। Product details के लिए live platform docs check करें। Lasting layer shape है, जिसे आपने ऊपर खुद बनाया।

खुद को जाँचें

Loop को अब तक किया work कहाँ रखना चाहिए और conversation में क्यों नहीं?

Answer दिखाएँ

Disk पर progress file और rules file में, या Linear जैसे board पर। Model memory runs के बीच wipe होती है, इसलिए survive करने वाली हर चीज़ 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
model: claude-haiku-4-5-20251001
---

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

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

Then reply with exactly one of:

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

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

tools line के बारे में एक ईमानदार बात: यह सिर्फ़ tool names (Read, Bash) लेती है, इसलिए reviewer को केवल test, lint और diff commands तक pin नहीं कर सकती। अभी numbered instructions यह limit carry करती हैं। अगला course Harness Engineering इसे enforce करने वाला rule जोड़ता है। Reviewer जिन checks के against grade करता है, उनका prompt में रहना ज़रूरी नहीं। Verification-skills interlude हर check को अपनी skill बनाता है, ताकि reviewer और /goal checker same file के against grade करें।

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 होने से laptop खुला हो या नहीं, यह 9am पर चलता है। यह plan की daily cap में भी आसानी से fit होता है: weekday-9am schedule week में 5 runs है, इसलिए Pro की 5-per-day cap में बहुत room रहता है। हर few hours वाली Routine नहीं रहती। First setup के environment, connector scoping और secrets panel को Routines appendix field by field समझाता है।

इसे एक 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-5   # confirm with `opencode models`
          prompt: |
            Run the daily-triage skill.
            Read progress.md first; update it last.
            For each candidate fix: draft it on a new branch, then invoke the
            @reviewer subagent to grade it. Open a PR only when the reviewer
            replies PASS. Append anything risky to the "needs a human" section
            of progress.md and leave it for the maintainer.

reviewer agent (एक सस्ते 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 play करें (लगभग 40 seconds)

ऊपर का run animation में देखें: fire होता है, काम खोजता है, हर fix draft करता है और separate reviewer हर item को PASS या FAIL देता है। Safe two PRs बनते हैं और risky one refuse होता है। फिर human gate आपको मिलता है। आप वह एक call करते हैं जिसे person चाहिए।

खोलें ↗

देखें क्या हुआ। Loop ने काम ढूँढा, draft किया, check किया, safe हिस्सा ship किया और आपको सिर्फ़ वही decision दिया जिसे person चाहिए था। यही practice में loop engineering है। दोनों tools के बीच एकमात्र real difference heartbeat और run की जगह थी। बीच की skill, spine, worktree, maker-checker और connector same 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 में सबसे ज़रूरी है।

आपका Loop तीन Loops के अंदर कैसे बैठता है

आपने अभी एक loop बनाया। इसके छह हिस्से हैं, और एक बार शुरू होने पर, यह अपने आप चलता है: agent code लिखता है, उसे test करता है, fix करता है, और फिर कोशिश करता है — आपके बिना।

यह एक loop है। यह सबसे तेज़ है। यह minutes में एक चक्कर पूरा करता है। लेकिन यह अकेला काम नहीं करता। यह तीन loops में सबसे छोटा है, और बाकी दो आपको चलाने हैं।

इन्हें देखने का सबसे आसान तरीका एक example है। मान लीजिए आप किसी agent से एक बच्चे के लिए एक छोटा typing game बनाने को कहते हैं।

• Coding loop minutes में चक्कर पूरा करता है। Agent game लिखता है, उसे test करता है, और bugs तब तक fix करता है जब तक यह आपके instructions से मेल न खाए। यही वह loop है जो आपने अभी बनाया।
• Feedback loop hours में चक्कर पूरा करता है। आप game खोलते हैं, उसे try करते हैं, और तय करते हैं कि क्या बदलना है — buttons बड़े करें, cat costumes जोड़ें जिन्हें बच्चा unlock कर सके, एक login जोड़ें ताकि कोई parent मदद कर सके। फिर आप अपने instructions update करते हैं, और agent फिर से बनाता है।
• Outside loop days में चक्कर पूरा करता है। असली लोग game इस्तेमाल करते हैं। कोई दोस्त इसे try करता है। कोई बच्चा इससे खेलता है। वे जो करते हैं, वही आपको दिखाता है कि आगे क्या fix करना है।

Loops एक-दूसरे के बगल में नहीं बैठते। वे एक-दूसरे के अंदर बैठते हैं। एक feedback loop चलाते समय कई coding loops होते हैं। बाहरी दुनिया से एक round feedback आने तक कई feedback loops होते हैं। तेज़ loop अपने आप चलता है। धीमे loops को आपकी ज़रूरत है।

दो शब्द जान लें। Spec आपका लिखा हुआ वर्णन है कि क्या बनाना है। Evals tests का एक छोटा set है जो जाँचता है कि agent ने इसे सही बनाया या नहीं। ये दोनों मिलकर पहले दो loops के बीच बैठते हैं और आपके फ़ैसलों को code तक ले जाते हैं।

अब मुख्य idea, Andrew Ng से। Agent तीनों loops खुद क्यों नहीं चला सकता? क्योंकि आप ऐसी चीज़ें जानते हैं जो यह नहीं जानता — इसे कौन इस्तेमाल करेगा, उन्हें असल में क्या चाहिए, और "अच्छा" कैसा महसूस होता है। जब तक आप कुछ ऐसा जानते हैं जो agent नहीं जानता, आप इसे बताने के लिए loop में बने रहते हैं। Ng इसे आपका context advantage कहते हैं।

यही वह सबक है जिस पर यह course खत्म होता है। Machine तेज़ loop चलाती है। आप वे दो चीज़ें थामे रहते हैं जो यह कभी नहीं थाम सकती: क्या बनाना है, और इसका जवाबदेह कौन है।

चाहे आप कभी कोई product न बनाएँ, इस map को याद रखें। यह दिखाता है कि किसी भी agent के काम में इंसान कहाँ बैठता है। पहले दो loops को जोड़ने वाले spec को और तेज़ बनाने के लिए, देखें Spec-Driven Development। आपकी भूमिका बाहरी loops में कैसे बढ़ती है, यह देखने के लिए देखें The Roles This Book Trains।

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 के लिए strong model, work के लिए cheap one। Claude Code में beat के लिए effort level भी match करें (/effort, या headless runs में CLAUDE_CODE_EFFORT_LEVEL)। Routine triage के लिए default काफ़ी है। Higher settings सिर्फ़ deep reasoning वाले beats के लिए हैं। हर scheduled fire पर maximum effort mechanical chore के लिए frontier model चलाने जैसी mistake है।
• Loop prompt और rules file छोटे रखें — आप इनके लिए हर beat पर भुगतान करते हैं। Detail को उन skills में धकेलें जो सिर्फ़ इस्तेमाल होने पर load होती हैं।
• इसे कम बार चलाएँ — हर पाँच minute के बजाय घंटे में एक बार आमतौर पर काफ़ी है, और लगभग बारह गुना सस्ता।

Numbers का quick अंदाज़ा (example)। मान लें एक beat, maker plus checker, करीब 40,000 tokens पढ़ता और 6,000 लिखता है। Standard Sonnet price $3 per million input और $15 per million output पर करीब $0.20 per beat है। 20-day month में five beats/day करीब $20 हैं।

Same loop every five minutes, day और night, 100× से अधिक beats करता है। Monthly cost आसानी से $1,000 पार कर सकती है, जबकि हर beat same work करता है। Command name नहीं, frequency increase drive करती है।

Optional current-model detail: Sonnet 5 August 2026 तक introductory pricing के साथ launch हुआ और उसका tokenizer older models के same text पर अधिक tokens बना सकता है। अपने actual loop के tokens measure करें, current model price से multiply करें, फिर scheduled runs की count से multiply करें।

OpenCode में model दूसरा cost lever है। ऊपर example standard Sonnet-class price मानता है। Claude Code loop commands Claude use करते हैं; OpenCode दूसरा model select कर सकता है। Lower-cost model per-beat price बहुत घटा सकता है।

लेकिन weaker maker अधिक failed attempts बना सकता है और saving खत्म कर सकता है। Practical pattern है lower-cost maker, trustworthy checker: clear mechanical work के लिए cheap model और checker में trusted tests, linters या reviewer।

Frequency फिर भी सबसे important है। 30× cheaper model every five minutes चलकर Sonnet hourly से अधिक cost कर सकता है। Model cost per beat बदलता है; schedule और retry rate paid beats तय करते हैं।

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

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

अच्छा spine cost lever भी है

Spine correctness feature है: memory नहीं, loop नहीं। Anthropic production fleets में दूसरा effect बताता है। Well-kept memory store से agent second time better करता है, क्योंकि first attempt का lesson disk पर है। Better first attempts, fewer retries और fewer tokens। Loop अधिक accurate और cheaper दोनों होता है। Dreaming pass once tokens खर्च करता है और हर future beat के first-time success पर payback देता है।

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

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

जब आप बहुत loops चलाते हैं

First read में optional technical detail छोड़ सकते हैं।

एक loop की तीन बातें fleet में organization problems बनती हैं। पहला, unattended failure का math। पाँच sequential steps हर एक 95% reliable हों तो केवल लगभग three runs in four clean finish होते हैं। Worse, mistakes spine में जमा होती हैं: tonight की wrong progress.md line tomorrow का wrong start है। Maker-checker bad step को permanent होने से रोकता है।

दूसरा, loop क्या कर सकता है limit करें, सिर्फ़ review नहीं। Reviewer diff grade करता है; यह prove नहीं करता कि loop ने config flip या outside connector call नहीं किया। Fix smarter reviewer नहीं, narrower loop है। Schedule sleep में act करने की standing permission है; connector real system का standing access; subagent borrowed identity में act करता है। Job जितनी permission ही दें। claude/ prefix, short connector list और read-only checker इसी idea के रूप हैं।

तीसरा, counting question। Five colleagues loop copy करें तो पूछना होगा: team कितने loops चलाती है, हर loop क्या touch कर सकता है, किस identity में act करता है और किसने approve किया? यह workforce management है, जहाँ Human-Agent Teams और Digital-FTE idea आगे बढ़ते हैं। अकेले trust कमाने वाले loop को team में जगह भी earn करनी है।

जब कई loops एक memory share करते हैं

First read में optional technical detail छोड़ सकते हैं।

एक loop की own progress.md को यह complexity नहीं चाहिए। Shared store में concurrent writes, organization-wide rules को agent द्वारा "fix" करना और January का truth June में wrong होना सामने आता है। Anthropic production fleets चार guardrails बताती हैं:

• Versioning: हर store change record हो: क्या, किस run ने और किस actor ने बदला। Bad update rollback हो सके। Git-tracked spine free में देता है।
• Write से पहले conflict check: draft के दौरान file बदली हो तो re-read और retry करें, overwrite नहीं। Databases decades से यही करते हैं।
• Level-based permissions: agent own scratch space लिख सकता है; organization-wide rules ordinary agents के लिए read-only हों और changes review से जाएँ। Top-level wrong line पूरी fleet scale करती है।
• Portability: curated memory open plain format और clean interface के पीछे रखें, ताकि products के बीच move हो सके।

Fleet memory production data है और production discipline deserve करती है। Stale memory को Concept 12 की dreaming pass sweep करती है।

Loop में, loop पर, या loop से बाहर: gate के industry names

यह course "human gate" कहता है। AI safety papers, EU AI Act, bank compliance teams और enterprise procurement तीन older terms इस्तेमाल करते हैं। Buyer या regulator इन्हीं words में पूछेगा और वे आपके design पर exact map होते हैं।

Term	अर्थ	Course में कहाँ बनाया
Human in the loop	Action लागू होने से पहले person approve करे। Higher control, slower।	Turn-by-turn prompting, plan mode, human-gate merge, two-routine gate A4।
Human on the loop	System खुद act करे; person watch करके intervene कर सके। Faster, more autonomy।	Routine claude/ branches पर push करती है; morning review और 9:30 spine read।
Human out of the loop	कोई watch नहीं और intervene का रास्ता नहीं।	जानबूझकर कहीं नहीं। यह third option नहीं, failure mode है।

तीन results निकलते हैं।

पहला, Concept 1 mindset shift का name है। Prompting human in the loop है: आप heartbeat, checker और memory हैं। Loop engineering आपको on the loop रखती है: system चलता है, attention gate पर है।

दूसरा, good loop per-action mix है। Morning triage safe fixes में on-the-loop और risky work में in-the-loop हो जाता है: reviewer FAIL, public-behavior change और merge। claude/ branch rule unattended work plus mandatory pre-main gate है। Concept 2 checker ladder mix तय करती है: checker जितना weak, उतने actions वापस in-the-loop। Passing test autonomy earn करता है; rubric score नहीं।

तीसरा, AI gravity out-of-loop की ओर drift कराती है। कोई इसे intentionally design नहीं करता। Diffs पढ़ना बंद करें, green checks trust करें और weekly shipped work skip करें, तो design change बिना on-the-loop system out-of-loop बनता है। Defense: costly, hard-to-reverse automatic move पर human रखें और verify करें कि human सच में मौजूद है। Concept 15 weekly habit यही check है।

Regulated vertical में Digital FTE बेचते समय exact सवाल होगा: "Human in the loop है या on the loop?" अब action by action answer और gate point कर सकते हैं।

आसान शब्दों में

In: person हर action approve करता है। On: system act करता है और person watch करके रोक सकता है। Out: कोई watch नहीं, writes के लिए कभी acceptable नहीं। Course के loops default on-the-loop हैं और risky steps in-the-loop gates पर हैं।

खुद को जाँचें

Dogfooding section का What's New loop approval step के बिना ship करता है। यह in, on या out कौन सा है और वहाँ acceptable क्यों है?

Answer दिखाएँ

On the loop। हर run approve नहीं होता, लेकिन output public, logged और one revert में fixable है; team transcripts पढ़ती है। कोई published work कभी न पढ़े, तभी out of the loop होगा। Dial wrong move की cost से set होता है और clumsy changelog line cheap-to-reverse है।

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

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

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

ये दोनों लोग उसी force के नीचे हैं, और उस force का नाम है। MIT Sloan के Eric So इसे AI gravity कहते हैं: वह लगातार pull जो आपको अपनी thinking का और अधिक हिस्सा AI को देने की ओर खींचता है। Loop वही pull है, बस heartbeat के साथ: यह आपके सोते समय भी चलता है, इसलिए जो ship होता है और जो आप समझते हैं, उनके बीच का gap तब भी बढ़ता है जब आप कुछ नहीं छूते। अगर इसे अकेला छोड़ दिया जाए, तो gravity उन दो सिरों को दबा देती है जिन्हें यह course आपका कहता है: intent एक precise, checkable condition से घटकर "बस इसे working रखो" बन जाता है, और accountability diffs पढ़ने से घटकर green checkmarks पर भरोसा करने लगती है। Loop दोनों हालत में चलता रहता है। यह नहीं बता सकता कि आप अभी भी engineer हैं या नहीं। Concept 15 के सवाल का जवाब देने वाली weekly habit — क्या ship हुआ पढ़ना, और check करना कि आपकी understanding साथ चली — वही तरीका है जिससे आप pull के खिलाफ अपना वजन बनाए रखते हैं।

यही पूरे course का main idea है। हर साल tools loop की अधिक mechanics खुद करते हैं। Dynamic workflows, /goal, Routines, retry limits, per-agent steps limits और background sessions जैसे features अब वह work replace करते हैं जिसके लिए पहले custom scripts चाहिए थीं।

लेकिन जो चीज़ें नहीं बदलतीं वे दो ends हैं जिनसे आप Concept 1 में मिले: intent, इतनी precise कि check हो सके, और जो ship हो उसकी accountability। Loop चाहे जितनी machinery absorb करे, वह न यह decide कर सकता है कि आप वास्तव में क्या चाहते हैं, न result की responsibility ले सकता है। बाकी सब automate हो सकता है। ये दोनों नहीं।

जब unattended loop fail होता है

Unattended loop unattended fail भी होता है। Overnight trust से पहले observable बनाएँ:

• Output वहाँ भेजें जहाँ देखेंगे: log file, Slack या Discord message (Claude Code Channels) या Triage inbox। Closed terminal नहीं।
• हर run एक line लिखे, failure पर भी: हर beat timestamp के साथ progress.md या log में tried, passed और broken लिखे। Silent failure worst है।
• Runs replayable रखें: OpenCode में opencode run --format json, opencode export <id> और opencode session list full record देते हैं। Claude Code Routine history web UI में रखती है; background sessions interactive ones के साथ --resume में दिखते हैं।
• Limit पर loudly fail करें: cap या error पर clear "needs a human" note छोड़ें, बस stop नहीं।
• Overnight से पहले prove करें: cadence और capability दोनों पर grow करें। कुछ days hourly और watched, फिर nightly unattended। पहले report-only, फिर human gate के पीछे fixes, और फिर unattended action। नीचे के level पर सही होकर next level earn होता है। Wrong लगे तो spine पहले पढ़ें; वह last good run बताती है।

जिस loop को debug नहीं कर सकते, उस पर trust नहीं कर सकते।

---

Loops के बाद: graph engineering

Course एक thread intentionally open छोड़ता है। July 18, 2026 को Peter Steinberger ने midnight के बाद पूछा: "Are we still talking loops or did we shift to graphs yet?" Crowd ने slogan बनाया, लेकिन real question है: एक से अधिक loops पर wiring चाहिए, यानी कौन किसे feed/check करता है, shared memory कहाँ है और कौन से measurements पर कोई loop argue नहीं कर सकता।

इसका full course series में two steps आगे Graph Engineering है, Harness Engineering के बाद। यह shared memory graphs, work का commit DAG और facts का knowledge graph, तथा many loops को honest रखने वाला governance graph cover करता है। Honest slogan रखें: graph composed loops है। Loops हटाएँ तो empty boxes हैं। यहाँ बनाए stopping condition, checker, spine और gate graph engineering की prerequisites हैं। First loop इसी course की तरह बनाएँ; second बनाते ही graph course ready है।

Late July 2026 में true। Term रहे या fade हो, pattern stable है।

---

इस book में loops इस्तेमाल करना (dogfooding)

Shape अब familiar है: heartbeat काम शुरू करता है; system work find, do, check, record और next decide करता है; spine सब जोड़ती है। आपने paper पर twice बनाया। अब production देखें।

Tool पर trust से पहले fair question है: builders खुद use करते हैं? Dogfooding own product को real production में use करना है। दो loops daily यह book चलाते हैं और exactly वही design use करते हैं जो course ने सिखाया। वे two stacks पर चलते हैं, Concept 3 का proof: loop once सीखें, tools में carry होता है।

Loop 1: feedback loop, book correct रखता है। हर lesson के bottom का feedback box front door है।

• Heartbeat: two cloud Routines। एक new feedback week में कुछ बार triage करती है, दूसरी weekly fixes draft करती है।
• Spine: reader notes की live database plus उनसे बने GitHub issues। Earlier work पढ़ने से same note twice नहीं होता।
• One beat: new feedback sort करें। Ratings, thanks, duplicates और handled items automatically close होते हैं। Rest tracked issues बनते हैं; small safe ones के actual fixes PR में draft होते हैं।
• Human gate: blocked reader, contribution offer या genuine content error जैसी essential few चीज़ें person तक जाती हैं। Drafted fix ship होने से पहले person approve करता है। Smaller items human touch बिना close होते हैं।
• क्या किया: first runs में thousands notes backlog clear हुआ, केवल decision वाली handful escalate हुई।

Loop 2: What's New loop, readers informed रखता है। What's New page loop लिखता है।

• Heartbeat: daily GitHub Actions schedule। Worker OpenCode है, Claude Code नहीं।
• Spine: last reported change की small state file, इसलिए repeat या miss नहीं।
• One beat: last time से book changes देखें, reader-relevant ones चुनें, हर एक की plain sentence लिखें, links check करें और publish करें।
• Human gate: none; live होने से पहले approval नहीं।

Difference useful है। Feedback loop ship से पहले human पर रुकता है; What's New नहीं। Factor importance नहीं, wrong move की cost है। Lesson edit costly/hard-to-undo है; clumsy changelog line one revert में fix है। Rule: human वहाँ रखें जहाँ wrong automatic move costly और hard to reverse हो; बाकी जगह बाहर रखें। Industry terms में costly action पर in-the-loop, elsewhere on-the-loop।

Honest part: दोनों alone नहीं छोड़े। Green run correct run नहीं, इसलिए transcripts पढ़ते हैं। Person तय करता है कौन सा feedback fix deserve करता है। Loops tireless middle करते हैं; दोनों ends human रहते हैं। यह limitation नहीं, design है।

अब आपने production में outside से finished loop देखा। नीचे projects में अपना first बनाएँ।

---

🚀 Projects

Loops के बारे में पढ़ना एक बनाने जैसा नहीं है। यहाँ आठ projects हैं, आसान से कठिन। इन्हें किसी भी tool में करें। Loop shape वही है, इसलिए 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 51-1.5 hrsBody को codify करेंProject 4 के orchestration को दोबारा run होने वाली एक unit बनाएँ, फिर साबित करें कि यह loop नहीं है।

Difficulty: medium to hard · Uses: dynamic-workflows interlude, Concepts 8 और 11.

Build. Project 4 के fix loop की body को codify करें। Claude Code में plain language में कहें: "इन तीन issues के fixes parallel worktrees में draft करने के लिए workflow use करें, और हर fix को reviewer से grade करवाएँ।" Runtime को script लिखने और run करने दें। Run सही काम करे, तो /workflows view से उसे /command के रूप में save करें। OpenCode में यही काम shell script से करें: candidates पर for loop, fan-out के लिए & और wait, तथा checker के रूप में reviewer का exit code। इसे दो बार run करें।

Done when एक command या script कई candidates, isolated checkouts और हर candidate का verdict बिना step-by-step prompting के चला दे। फिर fresh session या shell में साबित करें कि workflow को पिछले run की कोई memory नहीं है। Loop बनने के लिए इसे heartbeat और agents द्वारा लिखी progress file चाहिए। ये दोनों बता सकें, तो engine और loop का फ़र्क़ समझ गए। Dynamic workflows research preview हैं; इस project और live docs में मतभेद हो, तो docs सही हैं।

Routines appendix Project 6 के GitHub filters और trigger details देता है।

🔔Project 645-60 minDoorbell loopऐसा loop जो बिना prompt type किए pull request पर react करे।

Difficulty: medium · Uses: Concept 7 (event-driven), Concept 10 (connectors).

Build. अपने throwaway repo से उसके pull requests review करवाएँ। OpenCode में opencode github install run करें और generated workflow स्वीकार करें। Claude Code में GitHub pull-request trigger वाली Routine बनाएँ; appendix filters समझाता है। फिर off-by-one या deleted null check जैसा एक planted bug वाला PR खोलें और wait करें।

Done when PR को आपके कहे बिना review मिले और वह planted bug flag करे। Review miss करे, तो prompt tighten करके फिर push करें। Push का synchronize event loop को दोबारा fire करता है। Projects 1 से 3 के साथ यह चारों heartbeats पूरे करता है: in-session, conditional, scheduled और event-driven।

🔦Project 745-60 minजानबूझकर तोड़ेंअपने loop को sabotage करें, फिर सिर्फ़ spine से diagnose करें।

Difficulty: medium · Uses: Observability, Concept 13 (cost), Concept 14.

Build. Project 3 के loop की एक beat measure करें: एक run लगभग कितने tokens पढ़ता और लिखता है, उसे cadence से multiply करके monthly cost निकालें। फिर prompt को ऐसी file पर point करें जो मौजूद नहीं है, या limit के साथ ऐसी success condition दें जो कभी पूरी नहीं हो सकती। इसे schedule पर fail होने दें। अब full run replay किए बिना सिर्फ़ log line और progress.md से failure diagnose करें।

Done when spine से बता सकें कि क्या और कब fail हुआ, loop silent failure की जगह साफ़ "needs a human" note छोड़े, और current cadence पर monthly cost मालूम हो। Silent fail हुआ हो, तो पहले log line जोड़ें।

🔁Project 82-4 hrsआपका अपना daily loopअसली chore पर पूरा six-part loop, एक हफ़्ते unattended: 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 होता है से गुज़रें।)

---

Appendix: Routines, end to end

Advanced reference, पहली बार पढ़ते समय आवश्यक नहीं

इस appendix में product settings, limits, authentication details और failure cases हैं। जब आप असली cloud Routine configure करने के लिए तैयार हों, तब इसे पढ़ें। Loop engineering समझने के लिए इसे याद करना आवश्यक नहीं है।

मुख्य course Routine को एक प्रकार की heartbeat मानकर आगे बढ़ जाता है। यह appendix field guide है: form का हर field, तीनों triggers, secrets कहाँ रखे जाते हैं और वे failure modes जिनमें लोगों के असली कई घंटे लग जाते हैं। यह इस course का सबसे mechanical section है। Routines अभी research preview हैं, इसलिए बदलाव अपेक्षित हैं और किसी भी मतभेद में official page को अंतिम मानें। इसे अपनी पहली असली routine बनाने से ठीक पहले पढ़ें, उससे पहले नहीं।

पहले दिशा बताने वाला एक वाक्य। Routine एक saved Claude Code configuration है, यानी prompt, एक या अधिक repositories, cloud environment और connectors का set, जिसे एक बार package करके Anthropic के servers पर automatically चलाया जाता है। यह Concept 6 की heartbeat का product रूप है। Loop design आप लाते हैं। Scheduler, machine और plumbing platform लाता है।

जल्दी पढ़ने वालों के लिए पूरा appendix एक table में है। हर row को नीचे के sections में समझाया गया है:

Default / behavior	Risk	Fix
New-routine dialog में "Local" option	आप Desktop task को Routine समझकर बनाते हैं	Remote cloud routine है। Local Desktop scheduled task है (A1)
सभी connectors शामिल, writes allowed, कोई prompts नहीं	Unattended agent आपके हर linked tool में काम कर सकता है	Job को जिस connector की आवश्यकता नहीं, उसे हटाएँ (A2)
.env gitignored है, इसलिए cloud clone तक कभी नहीं पहुँचती	Routine को credentials नहीं मिलते और वह fail या improvise करती है	Secrets environment-variables panel में रखें और prompt में भी ऐसा कहें (A4)
हर run में fresh clone, fresh environment	Loop अपना पहला step हमेशा दोहराता रहता है	Committed context या progress file, या external board रखें (A4)
Schedule की न्यूनतम अवधि 1 hour है	Design 15-minute fires मानकर चलता है	अधिक frequency के लिए API trigger और अपना scheduler रखें (A3)
API bearer token एक बार दिखता है और endpoint कुछ deduplicate नहीं करता	Token खो जाता है और webhook retries duplicate runs बनाते हैं	Token तुरंत store करें और prompt को दोहराने के लिए safe बनाएँ (A3)
GitHub events पर hourly cap, अतिरिक्त events drop होते हैं	Event-heavy loop चुपचाप work miss करता है	Schedule trigger पर nightly reconciliation sweep रखें (A3)
matches regex पूरे field को test करता है	hotfix, "urgent hotfix for auth" से match नहीं करता	.*hotfix.*, या केवल contains use करें (A3)
Runs आपकी identity के साथ चलते हैं, mid-run approval नहीं	External actions बिना review आपके नाम से ship होते हैं	Two-routine gate: draft, फिर human approval, फिर API-fired executor (A4)
Green status का अर्थ infrastructure error न होना है	Failed tasks successful दिखते हैं	हर बार run transcript पढ़ें (A5)

A1. Local session cloud Routine नहीं है

Desktop app का New routine button आपको Remote या Local चुनने देता है और इन नामों ने internet के आधे tutorials को भ्रमित किया है। Remote cloud routine बनाता है, जिसके बारे में यह appendix है। Local एक Desktop scheduled task बनाता है: यह एक अलग feature है जो आपकी machine पर, unsaved changes सहित आपकी असली files के साथ, केवल machine चालू रहने तक चलता है। Rule Concept 6 वाला ही है। यदि local files चाहिए, तो Desktop task use करें। यदि laptop बंद रहने की guarantee, connectors, या API और GitHub triggers चाहिए, तो cloud routine use करें। अच्छा पहला step है कि prompt को Desktop task या one-off run के रूप में prove करें, फिर उसके ठीक चलने पर उसे scheduled cloud routine में ले जाएँ।

A2. Creation form, हर field के अनुसार

Routine claude.ai/code/routines पर, Desktop app में (Routines → New routine → Remote), या CLI में /schedule के साथ plain language में बनाएँ। तीनों एक ही account में लिखते हैं और एक जगह बनी routine दूसरी जगह भी दिखती है। CLI केवल schedule-triggered routines बनाता है। API और GitHub triggers बाद में web पर जोड़े जाते हैं। /schedule list, /schedule update और /schedule run existing routines manage करते हैं।

Name और prompt। Prompt पूरा job description है और उसे self-contained होना चाहिए। Routine full autonomous cloud session के रूप में चलती है, जिसमें permission prompts नहीं होते और mid-run पूछने के लिए कोई नहीं होता। इसलिए Claude को जो कुछ चाहिए, यानी क्या पढ़ना है, क्या करना है, success कैसी दिखती है और क्या नहीं छूना है, वह prompt या run की पहुँच वाली files में होना चाहिए। यहीं course की सलाह एक साथ जुड़ती है: prompt को repo में committed skill (Concept 9) की ओर point करें और routine का अपना text कुछ lines तक रखें। Prompt box में model selector है। Routine हर run में वही model use करती है, इसलिए उसे job के अनुसार चुनें (Concept 13)।

Repositories। आपकी जोड़ी गई हर repo हर run में fresh clone होती है और default branch से शुरू होती है। Default रूप से Claude केवल उन branches पर push कर सकता है जिनके names claude/ से शुरू होते हैं। Allow unrestricted branch pushes toggle (Permissions के अंतर्गत) हर repository के लिए यह limit हटाता है। जब तक unrestricted pushes की कोई specific, reviewed वजह न हो, उन्हें off रखें। Bad run में unattended agent का main पर push करना ठीक वही स्थिति है जिसे रोकने के लिए human gate है।

Environment। हर routine ऐसे cloud environment में चलती है जो तीन चीज़ें control करता है: network access, environment variables और setup script (dependencies install करने के लिए, जिसका result cache होता है ताकि वह हर session में दोबारा न चले)। Default environment में Trusted network access आता है, यानी package registries, cloud-provider APIs, container registries और common development domains की fixed allowlist। इसके बाहर कुछ भी 403 और x-deny-reason: host_not_allowed के साथ fail होता है। यदि routine को आपकी अपनी service तक पहुँचना है, तो environment को Custom करें और default list को साथ रखते हुए केवल उस एक domain को allow करें। Full access भी है, लेकिन वह अधिकांश loops की आवश्यकता से अधिक grants देता है। इसे सावधानी से विस्तृत करें।

Connectors। यहाँ एक default है जिसे हर बार बदलना उचित है। आपके सभी connected claude.ai connectors default रूप से शामिल होते हैं। Claude बिना पूछे उनके हर tool, writes सहित, को use कर सकता है। Save करने से पहले routine को जिस चीज़ की आवश्यकता नहीं, उसे हटा दें। दो और details हैं। Connector traffic Anthropic के servers से होकर जाता है, इसलिए connectors बिना network-allowlist changes के काम करते हैं। और claude mcp add से locally जोड़े MCP servers आपकी machine पर रहते हैं, account में नहीं, इसलिए routine को नहीं दिखते। उन्हें claude.ai/customize/connectors पर connectors के रूप में जोड़ें, या committed .mcp.json में declare करें ताकि वे clone के साथ जाएँ।

A3. तीन triggers

Schedule। Presets hourly, daily, weekdays या weekly हैं। Times आपकी local timezone में enter किए जाते हैं और आपके लिए convert होते हैं। जानबूझकर spacing के कारण runs hour के कुछ minutes बाद शुरू हो सकते हैं (किसी routine के लिए offset हर बार समान रहता है)। एक hour न्यूनतम है और इससे अधिक बार fire होने वाले cron expressions reject कर दिए जाते हैं। यदि अधिक frequency चाहिए, तो API trigger use करें और अपना scheduler लाएँ। Custom intervals (हर दो hours, month की पहली तारीख) nearest preset चुनकर और फिर CLI में cron expression के साथ /schedule update चलाकर set होते हैं। One-off schedule तय समय पर एक बार fire होकर खुद को off कर देता है। One-off scheduled runs daily routine cap में count नहीं होते, इसलिए schedule के लिए commit करने से पहले prompt rehearse करने का यह सस्ता तरीका है। CLI इन्हें plain language में लेता है: /schedule tomorrow at 9am, summarize yesterday's merged PRs।

API। API trigger routine को अपना /fire endpoint और bearer token देता है। Token generate करते समय एक बार दिखता है और बाद में retrieve नहीं हो सकता, इसलिए उसे तुरंत अपने alerting tool के secret store में रखें (वही window उसे Regenerate या Revoke कर सकती है)। अब authenticated POST भेज सकने वाला कोई भी system routine को fire कर सकता है: alerting webhook, deploy pipeline, form handler या आपकी अपनी machine का cron job। Request body run-specific context के लिए optional text field लेती है, जैसे alert body या failing log, जो saved prompt के साथ routine को freeform, unparsed text के रूप में दिया जाता है। Response नए session की ID और URL return करता है, इसलिए caller सीधे run को link कर सकता है।

curl -X POST https://api.anthropic.com/v1/claude_code/routines/<routine-id>/fire \
  -H "Authorization: Bearer <routine-token>" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

Dated beta header required है और preview के आगे बढ़ने पर बदलेगा। Docs वादा करते हैं कि सबसे recent पिछली दो versions काम करती रहेंगी, इसलिए callers को migrate करने का समय मिलता है।

Retry करने वाला webhook runaway heartbeat है

/fire endpoint में built-in deduplication नहीं है और webhook senders default रूप से retry करते हैं। इसलिए retried alert duplicate run है और पूरी रात retry करने वाला misconfigured alert ऐसा loop है जिसे आपने कभी design नहीं किया। पैसे वाला पहलू दिखने से अधिक गंभीर है। API-triggered runs आपके daily routine allowance में count होते हैं, इसलिए retry storm आपके जागने से पहले पूरे दिन का cap use कर देता है। Metered extra usage on हो तो cap सीमा रहना बंद करके bill बन जाता है। Concept 13 का rule केवल loops नहीं, triggers पर भी लागू होता है। Sender पर deduplicate या rate-limit करें। Prompt को दोहराने के लिए safe भी लिखें, उदाहरण के लिए draft करने से पहले check करें कि fix branch पहले से मौजूद है या नहीं। Concept 10 के connector rules ने ठीक यही सिखाया था।

GitHub events। Connected repo पर matching event आने पर GitHub trigger fresh session शुरू करता है। दो event kinds supported हैं: pull request (opened, closed, labeled, synchronized आदि) और release। हर kind किसी specific action या सभी actions पर fire हो सकता है। Repository पर Claude GitHub App installed होना आवश्यक है। ध्यान दें कि /web-setup clone access देता है, लेकिन app install नहीं करता; इस अंतर ने कई first attempts को भ्रमित किया है। Filters यह सीमित करते हैं कि कौन-से PRs routine fire करें: author, title, body, base branch, head branch, labels, draft state और merged state; operators में contains, is one of और matches regex शामिल हैं। एक महत्वपूर्ण detail: matches regex field के किसी हिस्से को नहीं, पूरे field को test करता है। इसलिए hotfix केवल उस title से match करता है जो exactly hotfix हो। .*hotfix.* लिखें, या केवल contains use करें। Loop design के लिए दो और facts महत्वपूर्ण हैं। पहला, preview के दौरान GitHub events की per-routine और per-account hourly caps हैं और cap से आगे के events drop हो जाते हैं जब तक window reset न हो। Drop होते हैं, queue नहीं। इसलिए event-heavy design को reconciliation sweep चाहिए: nightly scheduled run जो events से miss हुई हर चीज़ पकड़ता है। दूसरा, हर matching event अपना अलग session शुरू करता है। एक PR पर दो pushes ऐसे दो sessions हैं जो एक-दूसरे के बारे में कुछ नहीं जानते। GitHub setting में यह आपका Concept 12 spine lesson है।

A4. Secrets, state और identity

Secrets environment variables panel में रखे जाते हैं, .env file में कभी नहीं। कारण mechanical है: .env gitignored होती है, gitignored files GitHub तक कभी नहीं पहुँचतीं और इसलिए cloud clone में कभी नहीं होतीं। Routine fire होती है, उसे कुछ नहीं मिलता और वह fail होती है (या इससे भी बुरा, improvise करती है)। हर key environment के variables panel में रखें और prompt में एक clear line जोड़ें: "credentials environment variables के रूप में उपलब्ध हैं; .env file न खोजें"। इसके बिना Claude आदत से फिर भी .env path try कर सकता है।

हर run zero से शुरू होता है। Fresh clone, fresh environment, कोई working tree, cookies या leftovers नहीं। Routine को जो कुछ याद रखना है, उसे run समाप्त होने से पहले machine छोड़नी होगी: repo में push होकर, connector से external system में लिखकर, या board की API के माध्यम से भेजकर। यह ऐसी limitation नहीं है जिससे बचना है। यह Concept 12 का spine rule ही है, जिसे infrastructure लागू करती है। Matching pattern का नाम याद रखने योग्य है: repo में context files। Repository में committed clients.txt, progress.md या triage-rules.md हर run में पढ़ी जा सकती है और prompt छुए बिना update हो सकती है। Client list बदलने पर आप file edit करते हैं और routine का text नहीं बदलता।

Routines आपके रूप में काम करती हैं। वे आपके individual account की होती हैं, आपके daily allowance में count होती हैं और उनका हर काम, यानी commits, PRs, Slack posts, Linear tickets और drafted emails, आपकी identity के साथ होता है। Clients को reply करने वाली routine आपकी vacation के दौरान भी आपके रूप में reply करती रहती है। किसी भी externally visible चीज़ को schedule करने से पहले identity वाले पहलू पर विचार करें।

Mid-run approval नहीं होता। Routine अपने prompt को शुरू से अंत तक चलाती है। वह रुककर आपसे पूछ नहीं सकती। इसलिए जब किसी decision में वास्तव में human चाहिए, जैसे payment, बाहर जाने वाली email या deploy, तो gate को एक routine के भीतर नहीं, routines के बीच बनाएँ। यह तीन steps में काम करता है। Routine A work draft करती है और उसे ऐसी जगह post करती है जहाँ आप review कर सकें: claude/ branch, Slack message या draft email। Human उसे पढ़कर approve करता है। वह approval API trigger से Routine B को fire करता है और Routine B action करती है। यह Part 5 का human gate है, जिसे दो routines और webhook के रूप में लिखा गया है।

A5. Runs पढ़ना

हर run routine के detail page पर full session के रूप में दिखाई देता है। Transcript हर tool call, decision और change दिखाता है और आप conversation को manually जारी रख सकते हैं या result को PR बना सकते हैं। Docs की एक स्पष्ट warning, जिसकी experience भी पुष्टि करता है: green status का अर्थ है कि session infrastructure error के बिना समाप्त हुआ। इसका अर्थ यह नहीं कि आपका task सफल हुआ। Blocked network requests, missing connector tools और सामान्य task failures सभी transcript में होते हैं, status column में नहीं। Run खोलकर पढ़ें। Scheduler managed होने पर भी Concept 14 लागू होता है।

सरल शब्दों में: green का अर्थ है कि platform ने session पूरा किया। यह requested work के सफल होने का proof नहीं है।

Run now testing के लिए तुरंत run शुरू करता है। Repeats section का pause toggle configuration delete किए बिना schedule रोकता है। Cost के बारे में: runs आपकी subscription usage से भी लेते हैं और daily routine cap में भी count होते हैं। Cap से आगे extra usage enabled होने पर metered rates पर bill होता है और दोनों claude.ai/settings/usage पर दिखाई देते हैं। यदि /schedule CLI से गायब लगता है, तो सामान्य कारण API-key या cloud-provider authentication (इसके लिए claude.ai login चाहिए), telemetry-disabling environment variables, या outdated CLI हैं। Web UI दोनों स्थितियों में काम करती है।

यही appendix OpenCode approach में

ऊपर की हर row का GitHub Actions equivalent है, क्योंकि OpenCode approach ने ये problems कई वर्ष पहले अधिक साफ़ parts से हल कर ली थीं। Environment-variables panel repository secrets (secrets.ANTHROPIC_API_KEY) है। Connector list committed opencode.json का mcp section है। Schedule और PR triggers on: schedule और on: pull_request हैं। Statelessness समान है (CI runners भी हर run में fresh होते हैं, इसलिए committed-context-file pattern बिना बदलाव लागू होता है)। Identity के प्रश्न का उत्तर आपकी personal account की जगह GitHub App या bot token है। Branch guardrail वे branch protection rules हैं जिन्हें आप खुद set करते हैं। Names और configuration अलग हैं, लेकिन underlying problems समान हैं। यही course का केंद्रीय तर्क है।

A6. Checklist का routine रूप

Minimum safe loop checklist सीधे लागू होती है।

Success condition और limit prompt में रहती हैं (platform हर day के runs को cap करता है, हर run के damage को नहीं)। Isolation claude/ branch prefix है, इसलिए उसे on रखें। Read-only checker cloned repo में defined reviewer subagent है। State file committed context file है, क्योंकि clone हर बार fresh होता है। Human gate ऊपर का two-routine pattern है, या केवल "सिर्फ़ PRs draft करें, कभी merge न करें"। Log run transcript के साथ ऐसी जगह connector post है जिसे आप वास्तव में देखते हैं, और याद रखें कि green का अर्थ done नहीं है।

Cloud Routine save करने से पहले

हर बार इस list से गुजरें। इसमें एक minute लगता है और यही पढ़े हुए appendix और भरोसेमंद loop के बीच का अंतर है:

• Repositories: केवल सही repo, unrestricted branch pushes off।
• Prompt: self-contained, जिसमें success condition और limit शामिल हों।
• Connectors: job को जिस connector की आवश्यकता नहीं, वह हटा हुआ हो।
• Environment: secrets variables panel में हों, .env में नहीं, और network access उतनी ही narrow हो जितनी job अनुमति देती है।
• Trigger: schedule, API या GitHub को जानबूझकर चुनें, कोई accidental high-frequency fire न हो और trigger retry कर सकता हो तो safe-to-repeat handling हो।
• State: first run से पहले committed progress या context file, या external board चुना हुआ हो।
• Human gate: केवल draft PRs, branches या messages हों, direct merge, deploy, payment या client-facing send न हो।
• Test run: one-off schedule या Run now से एक बार fire करें, फिर status color नहीं, transcript पढ़ें।

अभ्यास: तीन routine drills

Field guide पढ़ना form में click करके हर step से गुजरने जैसा नहीं है। ये तीन drills throwaway repository में appendix के सबसे महत्वपूर्ण failure cases जानबूझकर reproduce करते हैं। इससे आप cost और risk कम रहते हुए हर problem को experience कर सकते हैं। इन्हें daily run cap के अनुसार भी design किया गया है। पहला drill one-off runs use करता है, जो cap में बिल्कुल count नहीं होते। दूसरे दो को कुल लगभग पाँच runs चाहिए, जो Pro cap का एक day है। Main projects के दो rules अब भी लागू होते हैं: throwaway repo use करें और limits पहले set करें।

(Project 12, इस section के अंत में, drill नहीं है। यह Projects 3 या 8 पर बनने वाला दूसरा capstone है और weekly चलता है, इसलिए इसके runs अलग से plan करें।)

🧪Project 920-30 minRoutine को free में rehearse करेंRepeating schedule लगाने से पहले one-off runs से prompt साबित करें।

Difficulty: easy · Uses: A1, A3 (one-off schedules), A5 (runs पढ़ना).

Build। Throwaway repo में ऐसी routine बनाएँ जिसका prompt एक छोटा, check करने योग्य काम करता हो, उदाहरण के लिए yesterday के commits को claude/summary branch पर summarize करना। इसे repeating schedule पर न रखें। One-off run (/schedule tomorrow at 9am, … या Run now) से fire करें और status column नहीं, पूरा transcript पढ़ें। फिर prompt ऐसा बदलें कि task को fail होना ही पड़े, जैसे उससे ऐसी file पढ़वाएँ जो मौजूद नहीं है, और एक बार फिर fire करें।

Done when आपने दो green runs देख लिए हों: एक जिसका transcript success दिखाता है और एक जिसका transcript failure दिखाता है। आप एक sentence में बता सकें कि status column उन्हें अलग क्यों नहीं बता सकता। वह sentence A5 का lesson है: green का अर्थ केवल यह है कि session infrastructure error के बिना समाप्त हुआ, इससे अधिक कुछ नहीं।

🔑Project 1030-45 minSecrets drill.env वाले ढंग से एक बार जानबूझकर fail हों, ताकि गलती से कभी न हों।

Difficulty: easy to medium · Uses: A4 (secrets), A2 (environment).

Build। ऐसा prompt लिखें जिसे एक secret चाहिए। Dummy token ठीक है, क्योंकि drill का विषय यह है कि value कहाँ रहती है, यह नहीं कि वह क्या unlock करती है। First run: token को gitignored .env file में रखें और routine fire करें। उसे value न मिल पाने पर fail होते देखें और transcript पढ़कर देखें कि Claude ने इसके बदले क्या try किया। Second run: token को environment-variables panel में ले जाएँ और appendix द्वारा सुझाई एक prompt line जोड़ें: "credentials environment variables के रूप में उपलब्ध हैं; .env file न खोजें।"

Done when second run environment से token पढ़े और आप वह mechanical कारण समझा सकें जिसके कारण first run नहीं पढ़ सका: gitignored files GitHub तक कभी नहीं पहुँचतीं, इसलिए fresh cloud clone में वे कभी नहीं होतीं।

🚪Project 111-2 hrsTwo-routine gate बनाएँA draft करे, आप decide करें और केवल आपका decision B को fire करे।

Difficulty: medium to hard · Uses: A3 (API trigger), A4 (gate), A6 (checklist).

Build। Routine A one-off schedule पर review करने योग्य कुछ draft करे: claude/ branch, या connector से post की गई short summary। Routine B में API trigger हो और वह एक छोटा follow-up action करे। B का bearer token दिखते ही store करें, क्योंकि वह एक बार दिखता है। A का draft खुद review करें। फिर A3 की curl call से B को fire करके approve करें।

Done when तीन बातें सच हों: B केवल आपके fire करने के कारण चला हो, B का transcript दिखाए कि action वास्तव में हुआ और आपने दोनों routines पर A6 checklist चलाई हो, जिसमें connectors pruned, unrestricted pushes off और state file चुनी हुई हो। यह Part 5 का human gate है और अब आपने इसे असली parts से बनाया है।

🌙Project 122-3 hrsDreaming loop बनाएँWeekly loop जो आपके दूसरे loops के logs पढ़कर rule changes को PR के रूप में propose करे।

Difficulty: capstone · Uses: Concept 12 (spine और improvement loop), Concept 11 (maker-checker), Concept 6 (schedule), Part 5 (human gate).

Build। आपको ऐसा loop चाहिए जो एक week से चल रहा हो और progress.md में dated entries छोड़ चुका हो (Project 3 या Project 8 ऐसा loop देता है)। अब उसके ऊपर दूसरा loop बनाएँ। Weekly schedule पर वह अपनी dreaming-state.md में लिखी date के बाद की सभी log entries पढ़े, एक से अधिक बार आने वाली failure या correction खोजे और उसे रोकने वाला सबसे छोटा rules-file या skill change direct commit नहीं, claude/ branch के PR के रूप में draft करे। PR description को अपना evidence cite करना चाहिए: कौन-से runs, कितनी बार और यह line उसे क्यों रोकती है। उससे एक deletion भी propose कराएँ: ऐसा rule जिसकी किसी recent run को आवश्यकता नहीं थी। अंत में dreaming-state.md update करें।

Done when तीन बातें सच हों। PR का proposed change plausible लगने वाले guess से नहीं, असली cited log entries से trace होता हो। Logs में जानबूझकर planted repeated failure (एक manually जोड़ें) पकड़ी जाकर proposal में बदले। और आपके merge किए बिना rules file में कुछ न बदला हो। यदि loop बिना evidence changes propose करे, तो prompt tighten करें: guess करने वाला improvement loop, improvement loop न होने से भी बुरा है, क्योंकि उसके guesses हर future run को steer करते हैं।

---

आगे कहाँ जाएँ

• एक से अधिक loops चला रहे हैं? जैसे ही दो loops work exchange करते या state share करते हैं, आपको wiring और shared memory चाहिए। इस series में दो steps आगे Graph Engineering दोनों को cover करता है।
• Non-coding work के लिए loops बना रहे हैं? Cowork & OpenWork crash course professionals के लिए वही heartbeat idea दिखाता है, जिसमें cron की जगह scheduled tasks हैं।
• Terminal की जगह API से loops चला रहे हैं? Claude Platform के Managed Agents अब scheduled deployments (public beta) support करते हैं। Agent को cron schedule दें और हर firing Anthropic की infrastructure पर fresh session शुरू करती है, इसलिए आपको scheduler build या host नहीं करना पड़ता। यह Routines idea को platform primitive के रूप में देता है और shape वही है। Schedule heartbeat है, आपका prompt beat है और spine अब भी आप देते हैं।
• Improvement loop को managed कराना चाहते हैं? वही Managed Agents platform memory और dreaming tooling देता है, यानी Concept 12 की note वाला out-of-band improvement pass product के रूप में। Shape नहीं बदलती: batch job heartbeat है, memory store spine है और approval step human gate है।
• Checker भी managed चाहिए? दो research previews verification-skills interlude को products में बदलते हैं। Code Review आपकी enabled repos के हर PR पर managed multi-agent review pass चलाता है (home four as a service), और Rubrics in Claude Managed Agents (beta) Concept 2 के rubric-with-a-bar को platform primitive बनाता है, जहाँ separate grader agent outcomes verify करता है और failed work को एक और attempt के लिए वापस भेजता है। Model के grade पर कितना भरोसा करना चाहिए, यह Trusting the Checker course का विषय है।
• Unattended runs के retries tune कर रहे हैं? Claude Code का Error reference automatic-retry settings document करता है, जिसमें CLAUDE_CODE_MAX_RETRIES और CI-style unattended sessions का CLAUDE_CODE_RETRY_WATCHDOG mode शामिल है।
• Clone-and-run starting points चाहते हैं? Community repo cobusgreyling/loop-engineering (MIT) production loop patterns (daily triage, PR monitor, CI checker, dependency checker, changelog drafter) को readiness checklist के साथ starter kits के रूप में collect करता है और कई agent CLIs पर map करता है। यह third-party और नया है, इसलिए check करें कि यह maintained है। लेकिन इसकी primitives table दूसरे names से इस course के छह parts ही है, इसलिए यह उपयोगी दूसरा वर्णन है। Reading trail के लिए Hugging Face पर community-curated awesome-loop-engineering collection primary articles को एक जगह gather करता है।
• Spec-Driven Development में लिखी spec आपके loop की stopping condition ही है। उसके acceptance criteria के against checker grade करता है और रुकने से पहले /goal उन्हें prove करता है। जब loop को चलने देना unsafe लगे, fix लगभग हमेशा अधिक sharp spec होती है, अधिक automation नहीं।

Sources और आगे पढ़ने की सामग्री

यह 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/
• Avi Chawla, Loop Engineering, Clearly Explained: inner-loop anatomy, चार nested engineering layers (prompt → context → harness → loop), doom-loop framing और loops के tool-design rules। https://www.dailydoseofds.com/p/loop-engineering-clearly-explained/
• Data Science Dojo, The 4 Layers of AI Engineering: one-failure-mode-per-layer framing और "कौन-सी layer अब भी manually कर रहे हैं" self-check, जिसे Concept 1 की note में paraphrase किया गया है। https://www.facebook.com/share/p/1HCxfwo5aC/
• Rakesh Gohel, How to Actually Use Fable 5 (infographic): self-learning और self-improving का अंतर, तथा prompt-harder-and-start-over और run, log, distill, repeat का contrast, जिसे Concept 12 की note में paraphrase किया गया है। https://rakeshgohel.substack.com
• Sydney Runkle (LangChain), The Art of Loop Engineering: four-loop stack (agent, verification, event-driven, hill-climbing), trace-driven improvement loop और swyx की loops stack करने वाली "loopcraft" framing का pointer। https://www.langchain.com/blog/the-art-of-loop-engineering
• Lamis (Anthropic, Applied AI), Context Engineering: Memory and Dreaming (AI DevCon 2026 talk): in-band और out-of-band memory split, dreaming consolidation process, Concept 14 की note में paraphrase किए production guardrails for shared memory stores और Concept 12 की note में paraphrase की school तथा head-teacher analogy। https://www.youtube.com/watch?v=tQ41RxfZZVg
• Letta (Charles Packer, Sarah Wooders आदि), Sleep-time Compute (April 2025 paper और blog): dreaming idea का सबसे शुरुआती productized रूप, MemGPT lineage का ऐसा background agent जो idle time में primary agent की memory rewrite करता है, और यह caveat कि offline consolidation केवल तब लाभ देती है जब future tasks past tasks से मिलती-जुलती हों। https://www.letta.com/blog/sleep-time-compute/
• Stanford / SambaNova / UC Berkeley, Agentic Context Engineering (ACE): repeated memory rewriting के दो failure modes, brevity bias और context collapse, तथा dreaming note में paraphrase किया fix, यानी monolithic rewrites की जगह incremental delta updates। https://arxiv.org/abs/2510.04618
• OWASP, Top 10 for Agentic Applications (2026): Memory and Context Poisoning को अलग agentic threat के रूप में define करता है, जिसमें injected content memory में बना रहता है और original attack चले जाने के बाद भी behavior को influence करता है। Dreaming note की poisoning warning इसी पर आधारित है।
• Simon Willison, Designing agentic loops (September 2025): सबसे शुरुआती clear statement कि skill agent को drive करना नहीं, loop design करना है। यह term से पहले आया था। https://simonwillison.net/
• TrueFoundry, Loop Engineering at Enterprise Grade: failure-stacking math, loop parts को standing permissions मानने की framing और team-scale inventory problem। यह Concept 14 की note में referenced governance analyses का प्रतिनिधि है। https://www.truefoundry.com/blog/loop-engineering-enterprise-agent-runtime
• The New Stack, "The Anthropic leader who built Claude Code says he ditched prompting — now he just writes loops." https://thenewstack.io/loop-engineering/
• Boris Cherny की "my job is to write loops" remark CNBC interview से है, जैसा Business Insider ने report किया। Peter Steinberger की "design loops that prompt your agents" line X पर उनकी post से है।
• Andrew Ng: तीन product-development loops (minutes में coding, hours में developer feedback, days में external feedback) और "taste" को human के context advantage के रूप में reframe करना। X पर उनकी post से। https://x.com/AndrewYNg/status/2071988145667928442
• Andrej Karpathy: "Don't tell it what to do, give it success criteria and watch it go," और AutoResearch project, ऐसा agent जो training script tweak करता, result measure करता और काम करने वाले change को रखता है, जबकि rounds के बीच कोई human editing नहीं होती। X पर उनकी posts से।

Claude Code (official docs)

• Routines: cloud scheduled automations, triggers, run caps और per-plan daily limits वाली launch announcement: https://code.claude.com/docs/en/routines और https://claude.com/blog/introducing-routines-in-claude-code
• Channels: चलते session में event-driven input: https://code.claude.com/docs/en/channels
• Scheduled tasks: /loop, cron tools, Desktop tasks और background-session carryover rule: https://code.claude.com/docs/en/scheduled-tasks
• Changelog: background sessions, retry watchdog, ultracode rename और chapter की हर दूसरी mechanical detail सबसे पहले यहाँ supersede होती है: https://code.claude.com/docs/en/changelog
• Memory: CLAUDE.md, auto memory और Auto Dream research preview के पीछे का consolidation pass: https://code.claude.com/docs/en/memory
• Delba de Oliveira (Anthropic, Claude Code team), Building verification loops in Claude Code with skills (July 22, 2026): verification-skills interlude का source, जिसमें skills के रूप में packaged checks, चार deployment homes (standalone, embedded, chained, on-every-PR), graduation signals, edit न कर सकने वाली skills के लिए wrapper-skill pattern, Anthropic की internal /code-review → /simplify → /verify → /design chain और /verify, Code Review तथा Rubrics in Managed Agents के pointers शामिल हैं। https://claude.com/blog/building-verification-loops-in-claude-code-with-skills
• लिखते समय Code Review और Rubrics in Managed Agents research previews या beta हैं। Availability या behavior पर निर्भर होने से पहले live docs check करें।

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, What's new in Claude Sonnet 5: claude-sonnet-5 model string, Sonnet 4.6 से direct migration, adaptive-thinking default और नए tokenizer का source। https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5
• Anthropic, Model IDs and versioning: 4.6 generation से आगे dateless IDs pinned snapshot हैं, Sonnet 5 जैसे major-version releases minor segment omit करते हैं, और 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
• Anthropic, Introducing Claude Fable 5 and Mythos 5: Opus से ऊपर flagship generation, जो mid-2026 में ship हुई, और reminder कि इस chapter के model examples illustrations हैं, frontier नहीं। https://www.anthropic.com/news/claude-fable-5-mythos-5

सभी links early July 2026 तक current हैं। ये tools अक्सर update होते हैं, इसलिए किसी specific limit, flag या model string पर निर्भर होने से पहले live docs से confirm करें।

---

एक-line summary

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

Flashcards Study Aid

---

Test Your Understanding

Checking access...