- AI के साथ सहयोग में context देना, preferences सेट करना, verification automation, delegation बढ़ाना, feedback loop जैसी पाँच प्रमुख बातों को व्यवस्थित रूप से समझाने वाली एक practical guide
- काम के सभी outputs (code, documents, analysis, decisions) अगली session के context के रूप में जमा होते जाते हैं, और corrections settings में शामिल होकर भविष्य की गलतियाँ कम करते हैं — यानी compounding जैसी संरचना
CLAUDE.md, skill files, guides आदि का उपयोग करके model के behavior और workflow को code की तरह manage करने के ठोस तरीके प्रस्तुत
- parallel sessions, models के बीच cross-verification, remote control आदि के जरिए throughput बढ़ाने वाली delegation strategies शामिल
- ये principles सिर्फ AI ही नहीं, human team collaboration पर भी समान रूप से लागू होने वाला एक general framework हैं
context को infrastructure के रूप में बनाना
- अगर सारा code
~/src में और knowledge work ~/vault(projects/, notes/, kb/ आदि) में व्यवस्थित हो, तो model के लिए grep या glob से context खोजना आसान हो जाता है
- संगठन के context (Slack, Drive, Mail आदि) को MCP(Model Context Protocol) के जरिए model से जोड़ा जा सकता है
- project-वार
INDEX.md बनाए रखें, और हर item में URL, owner, content description को comment के रूप में दर्ज करें
- सिर्फ URL की सूची होने पर model को हर link खोलना पड़ता है, इसलिए comments जोड़ने से context की बर्बादी रोकी जा सकती है
- हर नया session शुरू होने पर model blank slate से शुरू करता है, इसलिए project-वार
CLAUDE.md को new hire onboarding document की तरह लिखना चाहिए
- acronym glossary, project codenames, एक जैसे नाम वाले लोगों में भेद आदि शामिल करें
- पढ़ने का क्रम
INDEX.md → TODOS.md → किसी specific topic note के क्रम में तय करें
- memory layer को दो हिस्सों में अलग चलाएँ
~/vault: project status, artifacts, domain knowledge जैसी facts स्टोर करने के लिए
~/.claude(CLAUDE.md, skills/, guides/): preferences, workflows, personal style जैसी configuration स्टोर करने के लिए
preferences को configuration में encode करना
-
~/.claude/CLAUDE.md का उपयोग
- हर session की शुरुआत में Claude इसे पढ़ता है, इसलिए यह behavior contract की तरह काम करता है
- सीधे बोलना, असहमति होने पर तर्क देना, अनिश्चित होने पर ईमानदारी से बताना, failure होने पर root cause जाँचकर फिर कोशिश करना, task scope से बाहर reformat न करना जैसी behavior rules शामिल की जा सकती हैं
- किसी नए system या domain का core term आने पर 1–2 वाक्यों में समझाने वाला teaching section भी सेट किया जा सकता है
-
directory के हिसाब से scope अलग करना
- global(
~/.claude/CLAUDE.md): behavior, long-term goals, learning preferences जैसी हर जगह लागू होने वाली settings
- repo root: linting, naming, PR conventions जैसी repo-specific rules
- project directory: directory structure, domain knowledge जैसी project-specific context
- अगर Claude Code को किसी subdirectory से शुरू किया जाए, तो यह tree में ऊपर जाते हुए हर
CLAUDE.md को load करता है
-
CLAUDE.md लंबा हो जाए तो अलग करने की strategy
- लंबा
CLAUDE.md हर session में पूरा load होने के कारण context tax बन जाता है
@import की बजाय, CLAUDE.md में सिर्फ guide file path “ज़रूरत होने पर पढ़ें” के रूप में लिखकर lazy loading लागू करें
- उदाहरण: writing task के लिए
~/.claude/guides/writing.md, evaluation task के लिए ~/.claude/guides/evals.md
-
जो काम हफ्ते में कम-से-कम एक बार दोहरता है, उसे skill में बदलें
- skill एक Markdown workflow file है जिसमें नाम, trigger और procedure होते हैं
/polish: artifact diff देखें, metrics हों तो eval चलाएँ, browser rendering हो तो Chrome में देखें, नहीं तो code चलाकर output/error जाँचें → iterate करें → PR draft लिखें
/write: outline interview → research subagent बनाएँ → draft लिखें → adversarial critic से feedback लें → iterate करें
/daily: calendar, Slack, PR, पिछले दिन का log पढ़कर आज की priorities लिखें
SKILL.md को workflow और routing पर केंद्रित रखें, और templates/scripts जैसी knowledge को अलग files में रखकर सिर्फ ज़रूरत पर load करें
-
skill bootstrap करने का तरीका
- पहले task को एक बार interactive तरीके से करें, फिर model से इसे skill में बदलने के लिए कहें
- उसी या मिलते-जुलते task पर skill चलाएँ, और output correction उसी session के भीतर करें
- model से कहें कि correction और feedback के आधार पर skill update करे
- चाहें तो desired output का example देकर pattern (code structure, document structure, tone) निकालने को भी कह सकते हैं
-
transcript के जरिए skill सुधारना
- पहला version original session पर overfit हो जाना सामान्य है
SKILL.md को सीधे edit न करें; session के अंदर correction करें ताकि before-and-after pairs transcript में जमा हों
- output संतोषजनक हो जाए तो model से feedback को skill में merge करने को कहें → कुछ rounds बाद skill converge हो जाती है
-
हर काम के लिए यह context ज़रूरी नहीं
- brainstorming, exploration, draft work के लिए simple mode(
CLAUDE_CODE_SIMPLE=1 claude) इस्तेमाल करें
CLAUDE.md load तो होगा, लेकिन agent harness (hooks, skills, tool loop) disable रहेगा → model के साथ ज़्यादा सीधे सोचना संभव होगा
autonomy के लिए verification
-
verification को shift left करना
- verification को ladder structure में रखें: नीचे वाले स्तर सस्ते और deterministic, ऊपर वाले महंगे और judgment-dependent
- सबसे नीचे: model जिन files को edit करे, उन पर
ruff format, ruff check --fix चलाने वाला post-edit hook → deterministic और token cost शून्य
- ऊपर के स्तर: tests, evals, LLM review आदि
-
model खुद अपना काम verify कर सके, ऐसा setup बनाएँ
- अगर system metrics पैदा करता है, तो model को eval खुद चलाकर optimize करने दें
- अगर output browser rendering है, तो Claude in Chrome से inspect करें
- Docker image build करते समय error पढ़कर Dockerfile ठीक करें और फिर rebuild करें
- dashboard बनाते समय tooltip rendering, label overlap, numbers और narrative की consistency को Chrome में जाँचें
-
लंबी-running tasks में model, model पर नज़र रखे
- लंबे sessions में errors जमा होते जाते हैं और drift पैदा हो सकती है
- समाधान: दूसरे session को fresh context के साथ चलाकर original spec और पहले session के recent turns की तुलना करें
- tmux के दो panel: एक primary development के लिए, दूसरा pair programmer के लिए
- shared file में शुरुआती instructions और follow-up prompts जोड़ते जाएँ, और pair programmer समय-समय पर जाँच करे
- execution drift: model काम सही कर रहा है या नहीं — जैसे error ignore करना, गलत metric report करना, spec से हटना जैसी tactical checks → इन्हें बार-बार जाँचें
- direction drift: model सही काम कर रहा है या नहीं — जैसे मूल intent गलत समझकर गलत चीज़ बनाना जैसी strategic problem → इसे कभी-कभी जाँचें
delegation से scale करना
-
धीरे-धीरे बड़े work units delegate करें
- छोटे task और तेज feedback वाला pair programming तरीका fast iteration, exploratory analysis और prototyping के लिए उपयुक्त है
- ज़्यादा सक्षम model को intent, constraints और success criteria पहले से समझाकर end-to-end execution delegate करना चाहिए
- जिसे verify नहीं किया जा सकता, उसे delegate भी नहीं किया जा सकता; इसलिए success criteria और metrics की definition पहले होनी चाहिए
- उदाहरण: “हर eval suite के लिए isolated container build करें और smoke test चलाएँ → full run करें → metrics और transcript log करें → subagent से correctness verify करें → n बार repeat करके confidence interval निकालें → report बनाएँ और Slack पर result भेजें”
-
parallel sessions चलाना और bottleneck पहचानना
- बड़े tasks delegate करने पर एक साथ 3–6 sessions parallel चलाए जा सकते हैं
- bottleneck “काम करना” से हटकर “स्पष्ट spec लिखना और output की तेज review करना” बन जाता है — यानी बीच के कई step खाली हो जाते हैं
- अगर parallel sessions एक ही repo share करते हों, तो हर session को independent checkout देने के लिए git worktrees इस्तेमाल करें
-
sessions को observe करना आसान बनाएँ
- stop hook: session पूरा होने पर sound चलाएँ (macOS पर
afplay से Glass.aiff)
- tmux window title: status emoji (⏳ काम जारी, 🟢 पूरा) और Haiku द्वारा बनाए गए छोटे label से हर panel पहचानें
- Claude Code status line: context usage और current mode दिखाती है
-
AFK रहते हुए भी check-in संभव
- Claude Code के
/remote-control feature से चलते-फिरते Claude app के code tab में execution status देख सकते हैं, और फँसे हुए session को extra context या नए instructions दे सकते हैं
- इससे session घंटों idle नहीं पड़ा रहता, लेकिन इसका उपयोग सिर्फ urgent मामलों में करना चाहिए
feedback loop बंद करना
-
खुले में काम करें ताकि context समृद्ध बना रहे
- shared documents, repos, channels में काम करने पर model सहित टीम के सभी लोग context का उपयोग कर सकते हैं
- एक आसान test: “क्या नया team member सिर्फ shared context के आधार पर पिछले हफ्ते का काम reproduce कर सकता है?” — अगर नहीं, तो कोई महत्वपूर्ण context सिर्फ दिमाग में है
CLAUDE.md में निर्देश दें कि वास्तविक काम पूरा होने पर worklog channel में छोटा update और artifact link अपने-आप post हो
-
transcripts को mine करके settings update करें
- model को पुराने session transcripts पढ़ाने पर वह gaps खोज सकता है
- लगभग 2,500 पुराने user turns scan करने पर, काफ़ी हिस्से में "can you also…", "did you check…", "still wrong" जैसे वाक्य मिले
- यह संकेत है कि model को ये काम खुद से कर लेने चाहिए थे, या verification step गायब/गलत काम कर रहा था
- correction session के भीतर करें ताकि transcript अगली
CLAUDE.md या skill update के लिए input data बन सके
-
समय-समय पर refactoring और cleanup
- settings बढ़ने पर वे एक-दूसरे से overlap या conflict कर सकती हैं
- अगर model किसी rule को ignore कर रहा है, तो संभव है वह किसी दूसरे rule से टकरा रहा हो; इसलिए हर rule या preference ठीक एक ही जगह होनी चाहिए (महत्वपूर्ण instructions को main
CLAUDE.md में दोहराया जा सकता है)
- अलग-अलग directories में बिखरे
settings.json को ~/.claude में एकीकृत करके व्यवस्थित करें
निष्कर्ष
- model बदलते रहेंगे, इसलिए specific settings बदल सकती हैं; लेकिन अच्छा context देना, preferences encode करना, कम-लागत verification, ज़्यादा delegation, feedback loop बंद करना जैसे principles टिकाऊ हैं
- अंततः यह प्रक्रिया एक collaborator को एक-एक feedback के जरिए train करने जैसी है, और यही बात human teams के साथ collaboration पर भी लागू होती है
- यह सिर्फ personal tools तक सीमित नहीं, बल्कि agent harness design, team norms तय करने, और organizational infrastructure बनाने पर भी समान रूप से लागू हो सकती है
1 टिप्पणियां
इनका करियर काफ़ी दिलचस्प है,
मनोविज्ञान के छात्र से Coursera के data science कोर्स के ज़रिए पढ़ाई
दक्षिण-पूर्व एशिया की Amazon कही जाने वाली Lazada के शुरुआती दौर में शामिल हुए और VP तक प्रमोट हुए।
Lazada का Alibaba ने अधिग्रहण कर लिया।
उसके बाद Amazon में गए और recommendation/LLM के principal scientist बने।
फ़िलहाल Anthropic में technical staff हैं।