Claude Code में Multi-agent workflow: भूमिकाएँ, अलग worktree और मानव समीक्षा

1. Author, Reviewer और मानव की सीमाएँ तय करें

हर भूमिका का input और output पहले से तय रखें। इससे “किसने क्या मान लिया” जैसी अस्पष्टता कम होती है।

Author को scope से बाहर refactor करने की आवश्यकता नहीं होनी चाहिए। Reviewer का काम नया feature लिखना नहीं, बल्कि बदलाव और उसके failure modes को स्वतंत्र रूप से देखना है। मानव निर्णयकर्ता तय करता है कि जोखिम स्वीकार्य है या task वापस भेजना चाहिए।

2. Context और workspace को अलग रखें

Author और Reviewer को एक ही working directory या एक ही conversation thread में न चलाएँ। तीन स्तरों पर isolation रखें:

1. Session context: अलग threads mutual confirmation और circular reasoning को कम करते हैं।
2. Filesystem: अलग Git worktrees में Reviewer केवल उस branch और recorded diff को देखता है, किसी दूसरे dirty state को नहीं।
3. Environment security: API Key और runtime credentials environment variables में रखें; उन्हें prompt, handoff card या chat transcript में न डालें।

Worktree तैयार करने के commands

git worktree add ../agent-author -b feat/payment-retry
git worktree add ../agent-reviewer feat/payment-retry

हर Claude Code session के लिए अपना API Key प्रयोग करें। API Key, Base URL और model mapping को current BetterToken Claude Code Docs से जाँचें; configuration को repository या handoff में copy न करें।

3. Structured handoff card दें

Author के पूरा करने पर एक छोटा handoff card बनता है। इसमें raw conversation, secrets और अप्रमाणित निष्कर्ष नहीं होने चाहिए। Reviewer को चलाने योग्य command और बदली हुई files चाहिए, पूरी agent history नहीं।

Handoff Card

• Task: Add HTTP 429 retry support in payment client with exponential backoff.
• Branch: feat/payment-retry
• Changed Files: src/client/http.ts, tests/http-retry.test.ts
• Verification Command: npm test -- tests/http-retry.test.ts (Passed)
• Risks & Blockers: Exponential backoff capped at 3 attempts; socket timeout left unchanged.
• Next Step: Reviewer agent validates Retry-After header handling.

`Passed` केवल Author का recorded result है। Reviewer उसी command को अपने clean worktree में फिर चलाता है और `Retry-After` जैसे edge case को अलग से देखता है। अगर command fail होती है, source unclear है या diff में unrelated change है, handoff `Block` हो सकता है।

4. मानव की अंतिम स्वीकृति रखें

Reviewer isolated worktree में जाता है, verification command चलाता है, side effects और regressions के लिए diff पढ़ता है और lead engineer को structured summary देता है। उसके बाद मानव:

1. reviewer की findings पढ़ता है;
2. CI status और main के साथ conflict देखता है;
3. स्वीकार्य होने पर branch को खुद merge करता है।

git merge feat/payment-retry

यह प्रक्रिया perfect correctness की guarantee नहीं देती। इसका उद्देश्य assumptions को अलग रखना, evidence को repeat करना और code ownership को मानव के पास रखना है। API usage के लिए अपना BetterToken account और API Key बनाएँ, फिर request status तथा input, output और cache Token usage को Dashboard में जाँचें।