8 सेशंस में महारत हासिल करें! Claude Code ऑर्केस्ट्रेशन के लिए संपूर्ण गाइड

"मैं Claude Code का उपयोग कर रहा हूँ, लेकिन जैसे-जैसे स्केल बढ़ता है, कॉन्टेक्स्ट ओवरफ्लो हो जाता है और सटीकता गिर जाती है।"

"अंत में, AI को सुधार के निर्देश देने के लिए मेरे अपने हाथ ही सबसे बड़ी बाधा बन गए हैं।"

बहुत से लोग शायद इस बिंदु पर अटके हुए हैं। मैं भी पहले ऐसा ही था – कोड, टेस्ट और डिज़ाइन चर्चाओं को एक ही सेशन में डाल देता था, और जैसे-जैसे हिस्ट्री बढ़ती, Claude की सटीकता गिरती जाती।

हाल ही में मुझे एहसास हुआ है कि Claude Code स्वयं आधिकारिक रूप से कई सेशन को समानांतर चलाने के लिए तीन तंत्र प्रदान करता है।

इसके अलावा, ये तीनों समान लेकिन अलग हैं; इन्हें भ्रमित करने से दुर्घटनाएँ हो सकती हैं। इसके विपरीत, यदि आप इन्हें भूमिका के अनुसार विभाजित करते हैं, तो आप बिना खुद एक भी लाइन कोड लिखे "कमांडिंग पक्ष" में जा सकते हैं।

आज, मैं इन तीन तंत्रों और आधिकारिक दस्तावेज़ीकरण से प्राथमिक जानकारी की जाँच करते हुए भूमिका सीमाओं को ठीक करने के सही तरीके को व्यवस्थित करूँगा।

विशेष रूप से, मैं इसे एक कॉन्फ़िगरेशन में तोड़ूँगा जहाँ तीन परतों – कमांड, कार्यान्वयन और गुणवत्ता – में 8 सेशन रखे गए हैं।

बोनस के रूप में, मैं यह समझाने के लिए प्राथमिक जानकारी का भी उपयोग करूँगा कि "CLAUDE.md में भूमिका ID लिखकर स्विच करना" या "SQLite के साथ मेमोरी साझा करना" जैसी सामान्य व्याख्याएँ आधिकारिक तंत्र से थोड़ी अलग क्यों हैं।

मेरा नाम tatsuki है (@nobel_824)।

मैं छोटे और मध्यम उद्यमों के लिए AI उपयोग का समर्थन करता हूँ, Claude / Codex के व्यावसायिक कार्यान्वयन में मदद करता हूँ, जबकि स्वयं पूरे दिन Claude Code चलाता हूँ। समानांतर संचालन एक ऐसा क्षेत्र है जिसे मैं काम और व्यक्तिगत परियोजनाओं दोनों के लिए रोज़ छूता हूँ।

संबंधित लेख: Vibe Coding का परिचय: गैर-कोडर्स के लिए Claude के साथ ऐप बनाने के 6 कदम। एक सप्ताहांत में इन-हाउस उत्पादन का युग

https://note.com/nobel/n/n8192ec07d689

1. "एक ही सेशन में सब कुछ ठूंसना" विफल क्यों होता है

पहला जाल एक ही सेशन में बहुत अधिक जानकारी लोड करना है। चाहे Claude मॉडल कितना भी स्मार्ट क्यों न हो, यह संरचनात्मक सीमाओं से टकराता है।

विशेष रूप से, आपको ये तीन समस्याएँ मिलती हैं:

कॉन्टेक्स्ट संदूषण: जब कार्यान्वयन कोड, टेस्ट, डिबग हिस्ट्री और डिज़ाइन चर्चाएँ एक ही संदर्भ में मिल जाती हैं, तो तर्क की नींव गंदी हो जाती है और सटीकता गिर जाती है।
निर्देश विरोध: यदि "गति प्राथमिकता के साथ कार्यान्वित करें" और "सुरक्षा में सख्त रहें" एक ही स्थान पर मौजूद हैं, तो निर्णय अधूरे हो जाते हैं।
टोकन फूलना: हर बार एक विशाल हिस्ट्री लोड करना समय और लागत दोनों की बर्बादी है।

समाधान "एकल कमांडर बनना और विशिष्ट Claudes को पंक्तिबद्ध करना" का विचार है। यह एक CTO के पास Tech Lead और Backend Lead होने के समान है, लेकिन महत्वपूर्ण चीज़ सिर्फ़ माहौल नहीं है – यह है कि आधिकारिक Claude Code तंत्र का सही उपयोग किया जाए।

एक क्रिया जो आप आज कर सकते हैं: अपने वर्तमान सेशन के बारे में सोचें और जाँचें कि क्या "कार्यान्वयन", "शोध" और "समीक्षा" एक ही संदर्भ में सह-अस्तित्व में हैं। यदि हैं, तो यह उन्हें विभाजित करने का आपका प्रारंभिक बिंदु है।

2. आधिकारिक रूप से प्रदान किए गए "तीन समानांतर तंत्रों" को सुधारना

यह लेख का मूल है। Claude Code में समानांतरता के लिए तीन तंत्र हैं, प्रत्येक का एक अलग दायरा है।

पहला है subagent (एक सहायक AI जो मुख्य वार्तालाप से अलग संदर्भ में चलता है)। यह अपने स्वयं के कॉन्टेक्स्ट विंडो, समर्पित सिस्टम प्रॉम्प्ट और सीमित टूल अनुमतियों का उपयोग करके शोध या समीक्षा जैसे साइड कार्यों को निष्पादित करता है, और मुख्य सेशन को केवल परिणामों का सारांश लौटाता है। मुख्य बिंदु यह है कि subagent एक ही सेशन के भीतर चलते हैं, केवल मुख्य को रिपोर्ट करते हैं, और subagent एक-दूसरे से बात नहीं करते (आधिकारिक दस्तावेज़)।

दूसरा है agent teams (एक तंत्र जहाँ कई Claude Code सेशन एक टीम के रूप में सहयोग करते हैं)। एक सेशन टीम लीड बन जाता है और टीम के साथियों को जन्म देता है, एक साझा कार्य सूची और मेलबॉक्स के माध्यम से सहयोग करता है। Subagents के विपरीत, टीम के साथी सीधे एक-दूसरे को संदेश भेज सकते हैं। यह एक प्रायोगिक सुविधा है और डिफ़ॉल्ट रूप से अक्षम है। आपको CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 सेट करना होगा और Claude Code v2.1.32 या बाद के संस्करण का उपयोग करना होगा (आधिकारिक दस्तावेज़)।

तीसरा है git worktree (एक Git सुविधा जो एक ही रिपॉजिटरी से कई कार्यशील निर्देशिकाओं की अनुमति देती है)। claude --worktree feature-auth से शुरू करके, Claude एक अलग शाखा/निर्देशिका पर एक पृथक वातावरण में लॉन्च होता है। यदि आप किसी भिन्न टर्मिनल में दूसरा चलाते हैं, तो वे एक-दूसरे की फ़ाइलों पर कदम रखे बिना समानांतर चल सकते हैं (आधिकारिक दस्तावेज़)। डेस्कटॉप ऐप का उपयोग करते समय, प्रत्येक नए सेशन के लिए स्वचालित रूप से एक worktree बनाया जाता है।

यहाँ तीनों की तुलना करने वाली एक तालिका है:

आप भ्रमित नहीं होंगे यदि आप याद रखें कि worktree फ़ाइल अलगाव को संभालता है, जबकि subagents और agent teams स्वयं कार्य के समन्वय को संभालते हैं।

एक क्रिया जो आप आज कर सकते हैं: पहले, एक पृथक सेशन लॉन्च करने का अहसास पाने के लिए claude --worktree bugfix-test टाइप करने का प्रयास करें। जब आप बदलाव करने के बाद समाप्त करते हैं, तो यह पूछेगा कि क्या worktree को रखना या हटाना है।

3. अभ्यास: "3-परत संरचना" में 8 सेशन तैनात करना

ये तीन तंत्र 8 सेशन में कैसे अनुवादित होते हैं? मैं कमांड, निष्पादन और गुणवत्ता परतों में विभाजित एक लेआउट का उपयोग करता हूँ।

कमांड/डिज़ाइन परत (2 सेशन)

सेशन 1 PM (प्रोजेक्ट मैनेजर): समग्र प्रगति प्रबंधन, कार्य विभाजन, मनुष्यों को रिपोर्टिंग।
सेशन 2 आर्किटेक्ट: तकनीकी स्थिरता और निर्देशिका संरचना तय करता है। कोड लिखे बिना डिज़ाइन तैयार करने के लिए योजना अनुमोदन की आवश्यकता होती है।

निष्पादन/कार्यान्वयन परत (4 सेशन)

सेशन 3 फ्रंटएंड: कम्पोनेंट निर्माण, UI समायोजन।
सेशन 4 बैकएंड: एंडपॉइंट कार्यान्वयन, क्वेरी ऑप्टिमाइज़ेशन।
सेशन 5 इन्फ्रा/DevOps: Docker, CI/CD रखरखाव।
सेशन 6 सुरक्षा: भेद्यता जाँच, प्रमाणीकरण को सख्त करना।

गुणवत्ता/रखरखाव परत (2 सेशन)

सेशन 7 QA/समीक्षक: PR समीक्षाएँ, एज केसों को इंगित करना।
सेशन 8 तकनीकी लेखक: README, API दस्तावेज़ीकरण रखरखाव।

इस लेआउट के लिए तीन युक्तियाँ हैं: कार्यान्वयन परत के चार सेशन को worktrees से अलग करें ताकि वे एक-दूसरे की फ़ाइलों पर कदम न रखें। गुणवत्ता परत के लिए भूमिकाओं को subagent परिभाषाओं या agent team साथियों के रूप में तय करें। और प्रत्येक सेशन को साझा Markdown फ़ाइलों (डिज़ाइन नोट्स या समीक्षा परिणाम) के माध्यम से जानकारी रिले करें। आर्किटेक्ट डिज़ाइन अपडेट करता है, कार्यान्वयन परत उसके आधार पर चलती है, और समीक्षक परिणाम वापस लिखता है। मनुष्यों को केवल इन फ़ाइल अपडेट से प्रेरित होकर प्रत्येक सेशन को निर्देश देने की आवश्यकता है।

एक नोट: एक agent team के लिए आधिकारिक दिशानिर्देश 3–5 लोग हैं, इसलिए एक बार में सभी 8 को एक टीम में न भरें (आधिकारिक दस्तावेज़)। worktree-पृथक सेशन को 3–5 व्यक्तियों वाली agent team और आवश्यकतानुसार subagents के साथ जोड़ना सुरक्षित है ताकि कुल 8 कार्यकर्ता तक पहुँचा जा सके।

एक क्रिया जो आप आज कर सकते हैं: उपरोक्त 8 में से दो ऐसी भूमिकाएँ चुनें जो आपके वर्तमान प्रोजेक्ट में विभाजित करना आसान लगती हैं। कई मामलों में, आर्किटेक्ट और समीक्षक विभाजन के पहले बिंदु होते हैं।

4. "CLAUDE.md" के बजाय "Subagent परिभाषाओं" के साथ भूमिका सीमाएँ तय करें

समानांतर संचालन के बारे में एक सामान्य गलतफहमी को सुधारता हूँ। आप "CLAUDE.md में भूमिकाएँ (ID: arch, ID: dev-main...) लिखें और स्टार्टअप पर व्यक्तित्व स्विच करें" जैसी व्याख्याएँ देख सकते हैं, लेकिन यह तंत्र वास्तव में मौजूद नहीं है।

CLAUDE.md एक साझा निर्देश फ़ाइल है जिसे Claude Code स्टार्टअप पर पढ़ता है। हालाँकि, आधिकारिक दस्तावेज़ स्पष्ट रूप से बताते हैं कि CLAUDE.md "संदर्भ है, एक बाध्यकारी सेटिंग नहीं"। चूँकि यह सिस्टम प्रॉम्प्ट के बाद एक उपयोगकर्ता संदेश के रूप में पारित किया जाता है, सख्त अनुपालन की गारंटी नहीं है। यदि आप किसी चीज़ को रोकना चाहते हैं, तो आपको hooks का उपयोग करना चाहिए (आधिकारिक दस्तावेज़)। इसे एक पूर्ण "संविधान" के बजाय एक मजबूत अनुशंसा समझें।

तो आप भूमिकाएँ कहाँ तय करते हैं? उत्तर है subagent परिभाषाएँ। .claude/agents/ के अंतर्गत एक फ़ाइल को frontmatter में नाम, विवरण, उपलब्ध उपकरण और मॉडल के साथ रखकर, आप एक पुन: प्रयोज्य विशेषज्ञ पूरा करते हैं। यहाँ एक न्यूनतम उदाहरण है:

name: security-reviewer

description: Critically audits code from the perspective of authentication, input validation, and session management.

tools: Read, Grep, Bash

model: sonnet

You are a senior security reviewer. Focus on token handling,

session management, and input validation, and report findings with severity levels.

इसके अलावा, इन परिभाषाओं को agent teams में साथियों के रूप में नाम से बुलाया जा सकता है। यदि आप "auth मॉड्यूल का ऑडिट करने के लिए security-reviewer agent प्रकार के साथ एक साथी सेट करें" कहते हैं, तो यह उस परिभाषा से उपकरण और मॉडल प्राप्त करने वाला सदस्य बन जाता है (आधिकारिक दस्तावेज़)। डिज़ाइन यह है कि आप एक बार subagent परिभाषा के रूप में एक भूमिका लिखें और इसे subagent और टीम सदस्य दोनों के रूप में पुन: उपयोग करें।

प्रयास करने के लिए प्रॉम्प्ट उदाहरण (Claude को भूमिका परिभाषा बनाने देना):

Create a subagent definition to be placed in .claude/agents/.

The role is "a reviewer who points out performance issues and N+1 queries in implementation code."

Include name / description / tools / model in the frontmatter,

and write the body in the persona of a senior engineer.

5. Agent Teams के साथ "आर्किटेक्ट-समीक्षक" टीम बनाकर सटीकता बढ़ाना

समानांतर संचालन में अत्यधिक प्रभावी एक कॉन्फ़िगरेशन एक "निर्माता" और एक "संदेह करने वाले" को अलग-अलग स्थापित करना है। यह केवल सिद्धांत नहीं है; आधिकारिक दस्तावेज़ वास्तविक दुनिया के उदाहरण प्रदान करता है।

आधिकारिक "समानांतर कोड समीक्षा" उदाहरण में, एक PR के लिए, सुरक्षा, प्रदर्शन और टेस्ट कवरेज के लिए तीन साथी स्थापित किए जाते हैं, प्रत्येक अलग-अलग दृष्टिकोण से देखता है जबकि लीड परिणामों को एकीकृत करता है। इसके अलावा, "प्रतिस्पर्धी परिकल्पनाएँ" उदाहरण में, एक बग के लिए पाँच साथियों को अलग-अलग परिकल्पनाएँ सौंपी जाती हैं ताकि वे एक-दूसरे के सिद्धांतों पर बहस करें और उन्हें गलत साबित करें, जीवित सिद्धांत को मूल कारण मानते हुए (आधिकारिक दस्तावेज़)। चूँकि एक एकल अन्वेषक पहले सिद्धांत की ओर खिंच जाता है, यह दृष्टिकोण जानबूझकर संघर्ष पैदा करता है और सटीकता में सुधार करता है।

आप एक ऐसा संचालन भी लागू कर सकते हैं जहाँ आर्किटेक्ट को आधिकारिक सुविधाओं का उपयोग करके "कोड लिखने की अनुमति नहीं" दी जाती है। एक साथी के लिए योजना अनुमोदन की आवश्यकता करके, साथी केवल-पढ़ने के लिए योजना मोड में रहता है, लीड द्वारा अनुमोदित होने तक केवल डिज़ाइन तैयार करता है। अनुमोदन मानदंड लीड के प्रॉम्प्ट में लिखे जा सकते हैं, जैसे "केवल उन योजनाओं को अनुमोदित करें जिनमें टेस्ट कवरेज शामिल है।"

प्रयास करने के लिए प्रॉम्प्ट उदाहरण (एक बार में संघर्ष संरचना स्थापित करना):

Create an agent team to review PR #142. Set up three teammates:

one for security, one for performance, and one for test coverage.

Have them review independently and output findings with severity, then integrate them at the end.

दो डिस्प्ले मोड हैं: in-process (सभी साथी एक ही टर्मिनल में चलते हैं, Shift+Down के साथ चक्र) और split panes (प्रत्येक साथी एक अलग पैन में; tmux या iTerm2 की आवश्यकता है)। in-process से शुरू करना आसान है क्योंकि इसमें अतिरिक्त सेटअप की आवश्यकता नहीं है।

6. "SQLite" के बजाय आधिकारिक ऑटो मेमोरी (Markdown) के माध्यम से मेमोरी साझा करें

कई सेशन चलाते समय, अगली बाधा "सत्रों के बीच मेमोरी साझा करना" है। जबकि "SQLite में टैग की गई मेमोरी संग्रहीत करना और इसे गतिशील रूप से इंजेक्ट करना" जैसी उन्नत तकनीकें कभी-कभी पेश की जाती हैं, यह एक मानक Claude Code सुविधा नहीं है। MCP (मॉडल कॉन्टेक्स्ट प्रोटोकॉल) के माध्यम से DB बनाना संभव है, लेकिन आपको इसे आधिकारिक रूप से प्रदान किए गए मेमोरी तंत्र से अलग करना चाहिए।

आधिकारिक ऑटो मेमोरी Markdown फ़ाइलों के साथ काम करती है। ~/.claude/projects/<project>/memory/ के अंदर, MEMORY.md (इंडेक्स) और विषय-विशिष्ट फ़ाइलें जैसे debugging.md रखी जाती हैं, और Claude काम करते समय उनमें लिखता है। लोडिंग नियम स्पष्ट हैं: प्रत्येक सेशन MEMORY.md की पहली 200 लाइनों या 25KB तक पढ़ता है, और Claude केवल आवश्यक होने पर विषय-विशिष्ट फ़ाइलों को पढ़ने जाता है। यह Claude Code v2.1.59 से उपलब्ध है, प्रति रिपॉजिटरी सहेजा जाता है (इसलिए worktrees में साझा), और स्थानीय रूप से संग्रहीत किया जाता है (आधिकारिक दस्तावेज़)।

इस डिज़ाइन की खूबसूरती यह है कि "इंडेक्स को हमेशा लोड करके और केवल जरूरत पड़ने पर विवरण प्राप्त करके" आप कॉन्टेक्स्ट विंडो को साफ रख सकते हैं। हजारों छोटे नियमों के साथ भी, जब तक इंडेक्स फूलता नहीं, हर बार संदर्भ दूषित नहीं होगा।

क्रम के संदर्भ में, कस्टम SQLite समाधान बनाने का प्रयास करने से पहले आधिकारिक Markdown-आधारित ऑटो मेमोरी का पूर्ण उपयोग करें।

एक क्रिया जो आप आज कर सकते हैं: एक सेशन के दौरान /memory टाइप करने से वर्तमान में लोड की गई CLAUDE.md और ऑटो मेमोरी फ़ाइलों की सूची दिखाई देती है। पहले, इस बात पर एक नज़र डालें कि आपके पास कितनी और कहाँ मेमोरी है।

7. समानांतर संचालन में तीन नुकसान (लागत, DB, अनुमतियाँ)

अब जब आप तंत्र को समझ गए हैं, तो संचालन के लिए सावधानी के तीन बिंदु यहाँ हैं।

पहला है टोकन लागत। आधिकारिक दस्तावेज़ बताते हैं कि चूँकि agent team में प्रत्येक साथी का एक स्वतंत्र संदर्भ होता है, टोकन का उपयोग लोगों की संख्या के अनुपात में बढ़ता है। नियमित कार्यों के लिए 5 लोगों का उपयोग करने पर लागत की हानि होगी। यही कारण है कि आधिकारिक अनुशंसा 3–5 लोग है, यह देखते हुए कि "तीन केंद्रित सदस्य अक्सर पाँच विचलित सदस्यों से बेहतर होते हैं" (आधिकारिक दस्तावेज़)।

दूसरा है worktrees का अलगाव दायरा। एक worktree केवल फ़ाइल पृथक्करण के लिए एक Git तंत्र है; डेटाबेस, पर्यावरण चर और चल रही सेवाएँ अभी भी साझा हैं। यदि दो सेशन एक ही स्थानीय DB पर माइग्रेशन चलाते हैं, तो यह टूट जाएगा। आधिकारिक दस्तावेज़ चेतावनी देते हैं कि "प्रत्येक worktree में विकास वातावरण (निर्भरताएँ स्थापित करना, वर्चुअल एनवी सेट करना) को इनिशियलाइज़ करना याद रखें," और यदि कार्य DB को छूते हैं, तो आपको स्कीमा, Docker कंटेनर या .env फ़ाइलों को अलग करना होगा (आधिकारिक दस्तावेज़)।

तीसरा है अनुमतियाँ। साथी जन्म लेने पर लीड की अनुमति सेटिंग्स प्राप्त करते हैं। यदि आप लीड को --dangerously-skip-permissions के साथ चलाते हैं, तो सभी साथी भी उसी अपुष्ट स्थिति में होंगे। चूँकि एक दुर्घटना का प्रभाव समानांतर रूप से फैलता है, लीड पक्ष पर अनुमतियों को प्रतिबंधित करना सुरक्षित है।

8. मध्यवर्ती उपयोगकर्ताओं के लिए FAQ: हेडकाउंट, विस्तार और गुणवत्ता द्वार

अंत में, सामान्य प्रश्नों के कुछ अतिरिक्त उत्तर।

Q. कितने सेशन यथार्थवादी हैं?

एक अच्छा दिशानिर्देश पहले बताई गई 3-परत, 8-सेशन संरचना है। मुख्य बात यह है कि 8 लोगों को एक agent team में न भरें, बल्कि 3–5 व्यक्तियों की टीम को कोर के रूप में उपयोग करें और worktree सेशन या subagents जोड़ें। यह आधिकारिक अनुशंसाओं (प्रति टीम 3–5 लोग, प्रति साथी 5–6 कार्य) के अनुरूप है। अंतिम सीमा वह सीमा है जिसे आप मॉनिटर और संचालित कर सकते हैं। यदि आप अपनी कमांड क्षमता से अधिक संख्या बढ़ाते हैं, तो दक्षता कम हो जाएगी।

Q. क्या होगा यदि मैं subagents और agent teams से आगे निकल जाऊँ?

यदि आप एक स्थान से बड़ी संख्या में स्वतंत्र सेशन की निगरानी करना चाहते हैं, तो आधिकारिक subagents पृष्ठ background agents नामक एक तंत्र का उल्लेख करता है। इसे परतों में सोचें: एक सेशन के भीतर मदद के लिए subagents, एक संवादात्मक समानांतर टीम के लिए agent teams, और कई स्वतंत्र सेशन के प्रबंधन के लिए background agents।

Q. मैं गुणवत्ता की गारंटी कैसे दे सकता हूँ?

CLAUDE.md में अनुशंसाएँ केवल "आसानी से पालन किए जाने वाले निर्देश" हैं। उन जाँचों के लिए जिन्हें आप निश्चित रूप से निष्पादित करना चाहते हैं, hooks के साथ बाध्य करें। Agent teams में TeammateIdle, TaskCreated और TaskCompleted जैसे hooks हैं; एग्ज़िट कोड 2 लौटाने पर फीडबैक भेजा जाता है और काम जारी रखने के लिए मजबूर किया जाता है (आधिकारिक दस्तावेज़)। इसका मतलब है कि आप प्रोग्रामेटिक रूप से नियम लागू कर सकते हैं जैसे "जब तक टेस्ट ग्रीन न हों, पूरा न करें।"

सारांश: मॉनिटर से डिज़ाइनर/प्रतिनिधि बनना

Claude Code का मूल्य केवल कोड तेजी से लिखने से अधिक है – यह एक व्यक्ति की कई विशिष्ट Claudes को नियंत्रित करने की क्षमता में निहित है। यहाँ मुख्य बिंदु हैं:

तीन तंत्रों को भ्रमित न करें: subagents परिणाम लौटाते हैं, agent teams संवादात्मक टीमें हैं, और worktrees फ़ाइलों को अलग करते हैं। 8 सेशन को कमांड, कार्यान्वयन और गुणवत्ता परतों में विभाजित करें; कार्यान्वयन को worktrees से अलग करें और गुणवत्ता भूमिकाओं को subagent परिभाषाओं या agent teams के साथ तय करें। भूमिका सीमाओं को CLAUDE.md के बजाय subagent परिभाषाओं में तय करें, और पूर्ण नियमों को hooks के साथ लागू करें। कस्टम SQLite समाधान बनाने से पहले आधिकारिक Markdown-आधारित ऑटो मेमोरी को व्यवस्थित करें। प्रति टीम 3–5 लोगों का लक्ष्य रखें और परतें जोड़कर 8 कार्यकर्ताओं तक निर्माण करें।

आज से शुरू करने के 3 कदम:

[ ] claude --worktree test-1 टाइप करके एक पृथक सेशन लॉन्च करने का अहसास प्राप्त करें।
[ ] .claude/agents/ में एक "समीक्षक" भूमिका के लिए एक subagent परिभाषा लिखें और इसे अपने कार्यान्वयन की समीक्षा करने दें।
[ ] CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 सेट करें और तीन साथियों के साथ समानांतर PR समीक्षा चलाने का प्रयास करें।

एकल सेशन में लगातार सुधार निर्देश टाइप करने में बिताया गया समय भूमिकाओं को डिज़ाइन करने और सौंपने में बदल जाएगा। क्या छोड़ना है और क्या देखना है, यह तय करना समानांतर संचालन में सबसे मानवीय काम है।

संदर्भ लिंक (आधिकारिक प्राथमिक स्रोत)