चार AI एजेंट एक फीचर शिप कर सकते हैं जब आप सो रहे हों। ज़्यादातर लोग इन्हें कभी आपस में जोड़ नहीं पाते।
वे एक को रिव्यूअर, दूसरे को टेस्ट जनरेटर के तौर पर हाथ से, एक-एक करके तैनात करते हैं, और हर एजेंट भूल जाता है कि पिछले ने क्या किया। आप अब भी बाधा बने रहते हैं।
हल: प्लानर → कोडर → टेस्टर → रिव्यूअर, एक श्रृंखला में जुड़े हुए जो स्वचालित रूप से हैंडऑफ़ करते हैं। एक ट्रिगर, चार चरण, सुबह तक एक तैयार फीचर।
यहाँ पूरी पाइपलाइन है, कॉपी-पेस्ट कोड के साथ 👇
गहराई में जाने से पहले, मैं अपने Telegram चैनल में AI और वाइब कोडिंग पर रोज़ाना नोट्स साझा करता हूँ: https://t.me/zodchixquant 🧠
एक पाइपलाइन एजेंटों के ढेर से बेहतर क्यों है
एक एजेंट जो सब कुछ करता है, वह अपने कॉन्टेक्स्ट विंडो को प्लानिंग, कोड, टेस्ट और रिव्यू नोट्स से भर देता है जब तक कि गुणवत्ता गिर न जाए।
चार विशेषज्ञ प्रत्येक एक साफ, संकीर्ण संदर्भ में रहते हैं।
चाल है हैंडऑफ़ फ़ाइल। प्रत्येक एजेंट अपना आउटपुट वहाँ लिखता है जहाँ अगला इसे पढ़ सके: प्लानर .pipeline/spec.md पर स्पेक डालता है, कोडर इसे पढ़ता है और .pipeline/changes.md लिखता है, और इसी तरह।
उन्हें क्रम में चलाने वाला ऑर्केस्ट्रेटर एक सिंगल स्लैश कमांड है। बस इतना ही: चार उप-एजेंट, एक कमांड, हैंडऑफ़ के लिए एक साझा फ़ोल्डर।
एजेंट 1: प्लानर (उप-एजेंट, opus)
प्लानर कभी कोड नहीं लिखता। वह एक अस्पष्ट फीचर अनुरोध को एक ठोस स्पेक में बदल देता है जिसे कोडर बिना अनुमान लगाए फॉलो कर सके।
.claude/agents/planner.md बनाएँ:
1---2name: planner3description: एक फीचर अनुरोध को कार्यान्वयन स्पेक में बदलता है। फीचर पाइपलाइन के पहले चरण के रूप में उपयोग करें।4tools: Read, Grep, Glob, Write5model: opus6---78आप एक योजना विशेषज्ञ हैं। आप कार्यान्वयन कोड नहीं लिखते।910एक फीचर अनुरोध दिए जाने पर:111. मौजूदा पैटर्न समझने के लिए कोडबेस के प्रासंगिक भागों को पढ़ें।122. `.pipeline/spec.md` पर एक स्पेक लिखें जिसमें शामिल हो:13 - बनाने या संशोधित करने के लिए फ़ाइलें, सटीक पथों के साथ14 - आवश्यक इंटरफ़ेस या फ़ंक्शन सिग्नेचर15 - एज केस जिन्हें कार्यान्वयन को संभालना चाहिए16 - किन मौजूदा पैटर्न का पालन करना है (कॉपी करने के लिए फ़ाइल का नाम बताएँ)173. स्पेक के शीर्ष पर एक OPEN QUESTION के रूप में किसी भी अस्पष्ट चीज़ को चिह्नित करें।1819स्पेक को संक्षिप्त रखें। कोडर इसे और कुछ नहीं पढ़ता, इसलिए कोई अंतर न छोड़ें और उन आवश्यकताओं का आविष्कार न करें जो नहीं माँगी गईं।
प्लानिंग opus पर चलती है क्योंकि यह चरण उसके बाद की हर चीज़ के लिए गुणवत्ता की सीमा तय करता है। एक अस्पष्ट स्पेक कोडर चाहे कितना भी अच्छा हो, अस्पष्ट कोड ही उत्पन्न करता है।
एजेंट 2: कोडर (उप-एजेंट, sonnet)
कोडर स्पेक पढ़ता है और कार्यान्वयन लिखता है। वह योजना नहीं बनाता और न ही अपने काम की समीक्षा करता है, वह केवल वही बनाता है जो स्पेक कहता है।
.claude/agents/coder.md बनाएँ:
1---2name: coder3description: .pipeline/spec.md पर स्पेक को लागू करता है। प्लानर के बाद फीचर पाइपलाइन के दूसरे चरण के रूप में उपयोग करें।4tools: Read, Write, Edit, Grep, Glob, Bash5model: sonnet6---78आप एक कार्यान्वयन विशेषज्ञ हैं।9101. `.pipeline/spec.md` को पूरा पढ़ें। यदि उसमें OPEN QUESTIONS हैं, तो रुकें और अनुमान लगाने के बजाय उन्हें सतह पर लाएँ।112. स्पेक में वर्णित बिल्कुल वैसा ही लागू करें। उसके द्वारा नामित पैटर्न का पालन करें। उन सुविधाओं को न जोड़ें जो नहीं माँगी गईं।123. `.pipeline/changes.md` पर एक छोटा सारांश लिखें: कौन सी फ़ाइलें बदली गईं, प्रत्येक परिवर्तन क्या करता है, और टेस्टर को किस पर ध्यान देना चाहिए।1314आप ऐसा कोड लिखते हैं जो रेपो से मेल खाता है। आप असंबंधित कोड को रिफैक्टर नहीं करते या स्पेक के दायरे से बाहर की चीज़ों को "बेहतर" नहीं बनाते।
Sonnet यहाँ सही विकल्प है: एक स्पष्ट स्पेक के विरुद्ध कार्यान्वयन बिल्कुल वह संतुलित लागत-गुणवत्ता वाला काम है जिसे Sonnet सबसे अच्छे से संभालता है।
.pipeline/changes.md पर हैंडऑफ़ नोट टेस्टर को सही सतह को लक्षित करने देता है, न कि आँख बंद करके परीक्षण करने।
एजेंट 3: टेस्टर (उप-एजेंट, sonnet)
टेस्टर पढ़ता है कि क्या बदला और परीक्षण लिखता है जो साबित करते हैं कि फीचर काम करता है, फिर उन्हें चलाता है।
.claude/agents/tester.md बनाएँ:
1---2name: tester3description: .pipeline/changes.md में वर्णित परिवर्तनों के लिए परीक्षण लिखता और चलाता है। फीचर पाइपलाइन का तीसरा चरण।4tools: Read, Write, Edit, Grep, Glob, Bash5model: sonnet6---78आप एक परीक्षण विशेषज्ञ हैं।9101. `.pipeline/changes.md` पढ़ें कि क्या बनाया गया और कहाँ।112. बदली गई फ़ाइलें और `.pipeline/spec.md` पर स्पेक पढ़ें।123. परीक्षण लिखें जो कवर करते हैं: हैप्पी पथ, स्पेक द्वारा नामित एज केस, और कम से कम एक विफलता मामला। रेपो के टेस्ट फ्रेमवर्क से मेल खाएँ।134. परीक्षण चलाएँ। यदि कोई विफल होता है, तो विफलताओं को `.pipeline/test-results.md` पर लिखें और रुक जाएँ। स्वयं कोड ठीक न करें।145. यदि सभी पास हो जाते हैं, तो इसे `.pipeline/test-results.md` में नोट करें।1516आप व्यवहार का परीक्षण करते हैं, कार्यान्वयन विवरण का नहीं। एक विफल परीक्षण का मतलब है कि पाइपलाइन रिव्यूअर के लिए रुकती है, न कि आप उसके आसपास पैच लगाएँ।
एजेंट 4: रिव्यूअर (उप-एजेंट, opus)
अंतिम द्वार। रिव्यूअर पाइपलाइन द्वारा उत्पादित सब कुछ पढ़ता है और इससे पहले कि उसमें से कोई भी आपकी मुख्य शाखा तक पहुँचे, एक फैसला देता है।
.claude/agents/reviewer.md बनाएँ:
1---2name: reviewer3description: संपूर्ण पाइपलाइन आउटपुट की अंतिम समीक्षा। मानव अनुमोदन से पहले चौथा और अंतिम चरण।4tools: Read, Grep, Glob, Bash5model: opus6---78आप एक वरिष्ठ समीक्षक हैं। आप केवल-पढ़ने वाले हैं। आप कोड संपादित नहीं करते।9101. `.pipeline/` से स्पेक, परिवर्तनों का सारांश और परीक्षण परिणाम पढ़ें।112. वास्तविक परिवर्तन देखने के लिए `git diff` चलाएँ।123. आकलन करें: क्या कोड स्पेक से मेल खाता है? क्या परीक्षण सार्थक हैं या सतही? कोई सुरक्षा, प्रदर्शन या शुद्धता के मुद्दे?134. `.pipeline/review.md` पर एक फैसला लिखें:14 - VERDICT: SHIP / NEEDS WORK / BLOCK15 - NEEDS WORK या BLOCK के लिए, ठीक से सूचीबद्ध करें कि क्या ठीक करना है और कहाँ।1617रक्षा की अंतिम पंक्ति बनें। यदि परीक्षण हरे हैं लेकिन कोड गलत है, तो BLOCK कहें। हरे परीक्षण सही व्यवहार के समान नहीं हैं।
केवल-पढ़ने के उपकरणों का मतलब है कि रिव्यूअर संपादन करके समस्याओं को छिपा नहीं सकता, वह केवल निर्णय कर सकता है।
ऑर्केस्ट्रेटर: चारों को चलाने के लिए एक कमांड
अब वह टुकड़ा जो चार अलग-अलग एजेंटों को एक पाइपलाइन में बदल देता है। एक स्लैश कमांड जो उन्हें क्रम में बुलाता है, प्रत्येक पिछले द्वारा लिखी गई हैंडऑफ़ फ़ाइल को उठाता है।
.claude/commands/ship.md बनाएँ:
1$ARGUMENTS के लिए पूर्ण फीचर पाइपलाइन चलाएँ।23इन चरणों को क्रम में निष्पादित करें। आगे न बढ़ें। प्रत्येक चरण के बाद, अगला शुरू करने से पहले पुष्टि करें कि हैंडऑफ़ फ़ाइल मौजूद है।451. उपरोक्त फीचर अनुरोध के साथ `planner` उप-एजेंट को सौंपें। `.pipeline/spec.md` की प्रतीक्षा करें।62. यदि स्पेक में OPEN QUESTIONS हैं, तो रुकें और उन्हें मुझे दिखाएँ। अन्यथा `coder` उप-एजेंट को सौंपें। `.pipeline/changes.md` की प्रतीक्षा करें।73. `tester` उप-एजेंट को सौंपें। `.pipeline/test-results.md` की प्रतीक्षा करें। यदि परीक्षण विफल हुए, तो रुकें और मुझे विफलताएँ दिखाएँ।84. `reviewer` उप-एजेंट को सौंपें। मुझे `.pipeline/review.md` दिखाएँ।910अंतिम फैसले की रिपोर्ट करें। कुछ भी मर्ज न करें। शाखा को मेरी सुबह की समीक्षा के लिए छोड़ दें।
फिर एक एकल पंक्ति पूरी श्रृंखला शुरू करती है: /ship add rate limiting to the login endpoint.
जहाँ मैं रात्रिकालीन संस्करण चलाता हूँ
इसलिए मैं Teamly का उपयोग करता हूँ: AI एजेंटों के लिए विशेष रूप से निर्मित प्रबंधित क्लाउड होस्टिंग।
आप एक टीम किराए पर लेते हैं, यह समर्पित बुनियादी ढाँचे पर 24/7 चलता है, और आप कभी सर्वर को नहीं छूते।
कारण कि @Teamly इस लेख में विशेष रूप से फिट बैठता है: हैंडऑफ़ समस्या पहले से ही आपके लिए हल हो चुकी है।
हमने ऊपर हाथ से जो कुछ भी बनाया (स्पेक फ़ाइल, परिवर्तन फ़ाइल, ऑर्केस्ट्रेटर जो एक एजेंट को अगले से जोड़ता है), Teamly एक कोऑर्डिनेटर के साथ करता है।
यह एजेंटों के बीच काम को रूट करता है, एक से दूसरे तक संदर्भ पास करता है, और एक साझा ब्रीफ रखता है जिसे वे सभी पढ़ते हैं।
वही प्लानर-से-कोडर-से-टेस्टर प्रवाह, सिवाय इसके कि आप स्वयं हैंडऑफ़ नहीं जोड़ते।
अंतर यह है कि @Teamly केवल-कोड नहीं है। बिल्कुल वही ऑर्केस्ट्रेशन एक मार्केटिंग टीम, एक शोध टीम, या एक सहायता टीम चलाता है।
आपकी Claude Code पाइपलाइन रात में फीचर शिप करती है; एक Teamly मार्केटिंग टीम उसी तरह कंटेंट शिप करती है, उसी हैंड-ऑफ तर्क के साथ नीचे।
अपनी ज़रूरत की सटीक टीम बनाएँ
नया फीचर, उस टीम ने अभी लॉन्च किया: My Team
अब आप केवल 3 प्रश्नों के साथ अपनी टीम बना सकते हैं।
आप नियंत्रित भी कर सकते हैं: आवाज के नियम, निषिद्ध वाक्यांश, एकीकरण, टीम शैली (Strict / Casual / Creative), और टीम का आकार (2-4 एजेंट)।
@Teamly एक टीम लौटाता है जिसमें एक वास्तविक तर्क होता है कि प्रत्येक विशेषज्ञ क्यों है, न कि सामान्य टेम्पलेट। किसी भी एजेंट को एक क्लिक से बदलें। यदि ब्रीफ गलत है तो उसे संपादित करें।
मुद्दा एक संरचित ब्रीफ है जो स्पष्टता को मजबूर करता है, फिर एक टीम तैयार करता है जिसे आप काम पर रखने से पहले ऑडिट कर सकते हैं।
प्री-बिल्ट टीमों के समान हैंडऑफ़ आर्किटेक्चर, आपकी विशिष्ट समस्या के अनुरूप।
पहले मुफ्त में आज़माएँ
आप पूरी चीज़ को Teamly 5 पर 3 दिनों के लिए मुफ्त में परीक्षण कर सकते हैं, चौथे दिन तक कोई शुल्क नहीं।
यदि आप रहते हैं, तो मूल्य निर्धारण 5 एजेंटों के लिए $29/माह है।
इतना सस्ता कि एक शिप किया गया फीचर पूरे महीने का भुगतान कर देता है।
निचली पंक्ति
एजेंटों के ढेर और एक पाइपलाइन के बीच का अंतर हैंडऑफ़ है।
चार विशेषज्ञ साझा फ़ाइलों में लिखते हैं, एक ऑर्केस्ट्रेटर उन्हें क्रम में चलाता है, प्रत्येक चरण पिछले पर निर्माण करता है बजाय शून्य से शुरू करने के।
पहले प्लानर और कोडर बनाएँ और उन्हें दो-चरणीय श्रृंखला के रूप में चलाएँ। एक बार जब वह प्रवाह ठोस लगे, तो टेस्टर और रिव्यूअर जोड़ें।
जब तक सभी चार वायर्ड हो जाते हैं, आप सोने से पहले एक फीचर शुरू करेंगे और अपनी कॉफी के साथ एक फैसला पढ़ेंगे।
AI एजेंटों, वाइब कोडिंग और Claude Code सेटअप पर दैनिक नोट्स के लिए: https://t.me/zodchixquant 🧠
