लूप शुरू करना

• हर prompt पर coding agent को अलग-अलग निर्देश देने के बजाय, अब ऐसे agent operating pattern की ओर बदलाव हो रहा है जो stop condition पूरी होने तक work cycle को दोहराता है
• Claude Code टीम लूप्स को trigger करने का तरीका, stop करने का तरीका, इस्तेमाल किए गए primitive, और उपयुक्त task type — इन चार मानदंडों पर वर्गीकृत करती है
• मुख्य loop type चार हैं: Turn-based, Goal-based, Time-based, और Proactive
• हर काम के लिए complex loop की ज़रूरत नहीं होती; सबसे सरल समाधान से शुरू करें और ज़रूरत पड़ने पर ही pattern लागू करें
• loop output की quality आसपास के system पर निर्भर करती है, इसलिए code quality बनाए रखना और token usage को manage करना अहम है

---

लूप की परिभाषा और वर्गीकरण के मानदंड

• Claude Code टीम लूप को ऐसे agent के रूप में परिभाषित करती है जो stop condition पूरी होने तक work cycle दोहराता है
• loop classification के लिए चार मानदंड दिए गए हैं
  • यह कैसे trigger होता है
  • यह कैसे stop होता है
  • यह कौन-से Claude Code primitive का उपयोग करता है
  • यह किस प्रकार के काम के लिए सबसे उपयुक्त है
• complex loop हमेशा ज़रूरी नहीं होता; पहले सरल समाधान को प्राथमिकता दें, फिर pattern को चुनिंदा रूप से इस्तेमाल करें

Turn-based लूप

• यह user prompt से trigger होता है, और जब Claude काम पूरा मान ले या उसे अतिरिक्त context की ज़रूरत हो तो stop होता है
• यह नियमित process या schedule का हिस्सा न होने वाले छोटे कामों के लिए उपयुक्त है
• इसे manage करने के तरीके हैं specific prompt लिखना और skills के ज़रिए verification बेहतर बनाकर turns की संख्या कम करना
• हर prompt एक manual loop शुरू करता है जिसमें user हर turn को निर्देशित करता है; इसे agentic loop कहा जाता है
  • Claude context इकट्ठा करता है → action करता है → काम की पुष्टि करता है → ज़रूरत हो तो दोहराता है → response देता है
  • उदाहरण: like button बनाने के अनुरोध पर code पढ़ना, edit करना, test चलाना और result लौटाना; फिर user manual review करके अगला prompt लिखता है
• verification चरण में manual procedure को SKILL.md में encode करके Claude की self-checking सीमा बढ़ाई जा सकती है
  • इसमें result देखने, मापने या interact करने के लिए tools और connectors शामिल होने चाहिए
  • verification जितना अधिक quantitative होगा, self-verification उतनी आसान होगी

• SKILL.md उदाहरण (verify-frontend-change)

  • UI change को complete घोषित करने से पहले end-to-end verify करने का नियम
  • सिर्फ edit सफल होने पर completion report करना मना है; human reviewer की तरह verify करें
    • dev server शुरू करने के बाद edited page को browser में खोलें
    • बदले गए element को सीधे operate करें (button·input·toggle click), state change देखें, और पहले/बाद के screenshots लें
    • browser console में नए error या warning zero होने की पुष्टि करें
    • Chrome Devtools MCP से performance trace चलाएँ और Core Web Vitals audit करें
  • किसी भी चरण के fail होने पर fix करके चरण 1 से फिर चलाएँ; partial verification state में वापस न लौटें

Goal-based लूप (/goal)

• यह real-time manual prompt से trigger होता है और goal पूरा होने या maximum turn count तक पहुँचने पर stop होता है
• यह verifiable end condition वाले कामों के लिए उपयुक्त है
• इसे manage करने के तरीके हैं specific completion criteria तय करना और turn limit साफ़-साफ़ सेट करना, जैसे: "5 attempts के बाद stop"
• ऐसे complex कामों में जो single turn में पूरे नहीं होते, agent iterate करके बेहतर perform करता है
• /goal से completion state define करने पर Claude यह खुद तय नहीं करता कि "क्या यह काफ़ी अच्छा है", इसलिए यह जल्दी stop नहीं करता
  • हर बार Claude stop करने की कोशिश करता है, evaluator model condition check करता है और goal पूरा होने या तय turn count तक पहुँचने तक दोबारा काम करवाता है
  • passed tests की संख्या, किसी specific score threshold जैसी deterministic criteria प्रभावी रहती हैं
• उदाहरण
  • /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

Time-based लूप (/loop और /schedule)

• यह तय time interval पर trigger होता है और user cancellation या काम पूरा होने (PR merge, queue empty) पर stop होता है
• यह repetitive tasks या external environment/system के साथ interface करने के लिए उपयुक्त है
• इसे manage करने के तरीके हैं interval को लंबा रखना या समय के बजाय event-based reaction अपनाना
• कुछ agentic tasks स्वभाव से repetitive होते हैं; काम वही रहता है, सिर्फ input बदलता है, जैसे: हर सुबह Slack message summary बनाना
• external system पर निर्भर काम interval के हर चक्र में check करके बदलाव पर react करने वाले interface के रूप में काम करते हैं, जैसे: code review या CI failure वाले PR
• /loop हर interval पर prompt को फिर से execute करता है
  • /loop 5m check my PR, address review comments, and fix failing CI
• /loop user के computer पर चलता है और session समाप्त होने पर रुक जाता है; /schedule से routine बनाकर इसे cloud में shift किया जा सकता है

Proactive लूप

• यह event या schedule से trigger होता है और इसमें real-time human intervention नहीं होता
• हर task goal पूरा होने पर खत्म होता है, लेकिन routine खुद user के बंद करने तक चलता रहता है
• यह bug report, issue triage, migration, dependency upgrade जैसे well-defined repetitive workflow के लिए उपयुक्त है
• इसे manage करने का तरीका है routine को छोटे और तेज़ model की ओर route करना, और सिर्फ judgment की ज़रूरत वाले हिस्सों में सबसे powerful model का उपयोग करना
• ऊपर दिए गए primitive, auto mode, और dynamic workflows (research preview) को मिलाकर long-running loop बनाया जा सकता है

• feedback handling configuration उदाहरण

  • /schedule (research preview) से नए reports check करने वाला routine चलाना
  • /goal से completion define करना, और skills में verification method document करना
  • Dynamic workflows से हर report के लिए classify, fix, और review agents को orchestrate करना
  • Auto mode से permission confirmation के बिना routine चलाना
  • integrated prompt उदाहरण: /schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.

Code quality बनाए रखना

• loop output की quality आसपास के system पर निर्भर करती है, इसलिए system design महत्वपूर्ण है
• codebase को साफ़ रखें: Claude मौजूदा codebase के patterns और conventions का पालन करता है
• self-verification के साधन दें: skills के ज़रिए team standard के अनुसार "good state" को encode करें
• documentation तक पहुँच आसान बनाएं: framework और library docs में latest best practices होती हैं
• code review के लिए second agent का उपयोग करें: नया context रखने वाला reviewer कम biased होता है और main agent की reasoning से प्रभावित नहीं होता; built-in /code-review skill या Github के लिए Code Review का उपयोग करें
• अगर individual result standard से नीचे हो, तो सिर्फ अलग issue fix न करें बल्कि system itself को बेहतर बनाने के लिए भी encode करें

Token usage manage करना

• loops की स्पष्ट boundaries होनी चाहिए और नीचे दिए गए सिद्धांत लागू करने चाहिए
• उपयुक्त primitive और model चुनें: छोटे कामों में multi-agent या loop की ज़रूरत नहीं; कुछ tasks के लिए सस्ते और तेज़ models पर्याप्त हैं
• स्पष्ट success और stop criteria तय करें: completion state को specific बनाएं ताकि बहुत जल्दी premature completion न मान लिया जाए
• large-scale run से पहले pilot करें: dynamic workflows सैकड़ों agents बना सकते हैं, इसलिए पहले छोटे scope में usage मापें
• deterministic tasks के लिए script का उपयोग करें: हर चरण पर reasoning कराने से script चलाना सस्ता पड़ता है; उदाहरण: PDF skill form-filling script देती है ताकि हर बार code regenerate करने के बजाय उसे चलाया जा सके
• routine को ज़रूरत से ज़्यादा न चलाएँ: monitored target की change frequency के हिसाब से interval तय करें
• usage review करें: /usage skills, subagents, और MCPs के हिसाब से usage analysis दिखाता है; बिना argument वाला /goal current turn count और token usage दिखाता है; /workflows हर agent का token usage दिखाता है और उन्हें कभी भी stop किया जा सकता है

शुरू करना

• loop type के हिसाब से सारांश
  • Turn-based: verification (check) delegate करें; exploration या decision के लिए उपयोग करें; custom verification skills का उपयोग करें
  • Goal-based: stop condition delegate करें; जब completion state पता हो तब उपयोग करें; /goal का उपयोग करें
  • Time-based: trigger delegate करें; जब project के बाहर schedule के अनुसार काम आता हो तब उपयोग करें; /loop और /schedule का उपयोग करें
  • Proactive: prompt delegate करें; जब काम repetitive और well-defined हो तब उपयोग करें; ऊपर की सभी चीज़ों और dynamic workflows का उपयोग करें
• शुरुआत करने का तरीका यह है कि अपने मौजूदा कामों को देखें और ऐसा एक काम चुनें जहाँ bottleneck आप खुद हों, फिर तय करें कि उसका कौन-सा हिस्सा delegate किया जा सकता है
  • क्या आप verification checks लिख सकते हैं
  • क्या goal पर्याप्त रूप से स्पष्ट है
  • क्या काम schedule के रूप में आता है
• जब कोई idea मिल जाए, loop चलाएँ, देखें कि कहाँ अटकाव या over-execution हो रहा है, और iterative improvement से न डरें