Claude Code Context Management: /context, /compact, CLAUDE.md और Obsidian का सही उपयोग

आपने Claude Code को एक साफ काम दिया, लेकिन एक घंटे बाद वह पहले पढ़ी हुई फाइल फिर से खोलने लगा, पुराना फैसला मानने लगा या लंबे build log में असली error भूल गया। शुरुआत करने वाले व्यक्ति को यह model की क्षमता घटने जैसा लग सकता है। अक्सर समस्या model नहीं, बल्कि भरी हुई context window होती है।

Context window वह सीमित working area है जिसमें मौजूदा बातचीत, पढ़ी गई फाइलें, command output, project instructions और Claude के जवाब एक साथ रहते हैं। पुरानी जांच और बेकार output बढ़ने पर जरूरी तथ्य दब जाते हैं। इस लेख का लक्ष्य token बचाने की कोई चाल बताना नहीं, बल्कि यह तय करने की रोजमर्रा की प्रक्रिया देना है कि क्या अभी चाहिए, क्या project memory में रखना है, क्या संक्षिप्त करना है और कब नया session शुरू करना है।

मुख्य बातें

• अनुमान लगाने से पहले /context चलाकर देखें कि मौजूदा window में जगह किसने ली है।
• काम वही है लेकिन बातचीत लंबी हो गई है तो focus instruction के साथ /compact चलाएं।
• अगला काम पूरी तरह अलग है तो /clear का उपयोग करें; पिछला session मिटता नहीं और बाद में resume किया जा सकता है।
• स्थायी project rules देखने या बदलने के लिए /memory उपयोग करें, लेकिन कौन-सी memory वास्तव में load हुई है यह /context से जांचें।
• खर्च, plan limit और activity के लिए /usage देखें। /cost उसी command का alias है और /stats Stats tab खोलने वाला alias है।
• compact या handoff से पहले निर्णय, बदली फाइलें, test result और अगला कदम लिखकर छोड़ें।

Context window को काम की मेज समझें

साफ मेज पर current task, दो जरूरी फाइलें, छोटा error और completion criteria होते हैं। भरी मेज पर अधूरे रास्ते, पूरा build log, unrelated research, बार-बार पढ़ी गई फाइलें और आपस में टकराते निर्देश पड़े रहते हैं। Claude Code जरूरत पड़ने पर auto-compaction कर सकता है, पर उसे भी तय करना पड़ता है कि क्या बचाया जाए। इसलिए बड़े phase change से पहले focused manual compaction अधिक भरोसेमंद है।

Context में क्या आता है	बोझ कैसे बढ़ता है	बेहतर आदत
बातचीत का इतिहास	side question और बदले हुए फैसले बने रहते हैं	unrelated काम अलग करें और नया फैसला लिखें
पढ़ी गई फाइलें	पूरा folder या generated file पढ़ लिया जाता है	पहले search करें, फिर जरूरी range पढ़ें
tool output	retries और लंबे logs जमा होते हैं	root-cause line और final result रखें
CLAUDE.md और rules	बड़े या विरोधी निर्देश हर बार load होते हैं	हमेशा लागू rules छोटे रखें
skills और tool descriptions	जरूरत से ज्यादा capabilities startup context लेती हैं	काम से जुड़ी capabilities ही रखें

हर command का सही काम

इन commands को interactive Claude Code session में message की शुरुआत में लिखें। इनके नाम एक जैसे लग सकते हैं, लेकिन ये अलग समस्याएं हल करते हैं।

/context: मौजूदा window की जांच

/context colored grid में context usage और optimization suggestions दिखाता है। अधिक विस्तृत item-by-item breakdown के लिए /context all चलाएं। यह diagnostic command है; इसे देखने से context साफ नहीं होता। लंबा task शुरू करते समय baseline लें, बड़ी investigation के बाद दोबारा देखें और /compact से पहले तय करें कि summary में किसे प्रमुख रखना है।

/context
/context all

/compact [instructions]: उसी काम को summary के साथ जारी रखें

/compact conversation history को structured summary से बदलता है और उसी conversation में अधिक जगह बनाता है। command के बाद दिया गया text बताता है कि summary में क्या प्राथमिकता होनी चाहिए। हर वाक्य सुरक्षित रहेगा, ऐसा न मानें; स्थायी नियम CLAUDE.md, specification या handoff note में होने चाहिए।

/compact preserve the accepted API contract, changed files, failing test, commands already run, and next action

/clear [name]: अलग काम के लिए नया conversation

/clear खाली conversational context से नई बातचीत शुरू करता है। नाम देना optional है। project memory फिर load होती है और पुरानी बातचीत /resume, claude --resume या उसी directory के सबसे हाल के session के लिए claude --continue से वापस मिल सकती है। इसका उपयोग तभी करें जब objective, files या decision history वास्तव में बदल गए हों।

/clear auth-fix-complete

/memory: स्थायी guidance को देखें

/memory CLAUDE.md और CLAUDE.local.md की locations, auto memory entries और auto-memory toggle दिखाता है। Project CLAUDE.md team guidance के रूप में commit किया जा सकता है। Auto memory repository के worktrees में स्थानीय रूप से साझा हो सकती है, लेकिन दूसरी machine पर अपने-आप नहीं जाती। /memory में कोई file दिखाई देना उसके current context में load होने का प्रमाण नहीं है; Memory files section /context में जांचें।

/memory

/usage, /cost और /stats: consumption देखें

/usage session cost, plan usage limits और activity details दिखाता है। /cost इसका alias है। /stats भी alias है, लेकिन Stats tab खोलता है। ये /context का विकल्प नहीं हैं: usage बताता है कितना consume हुआ, जबकि context बताता है working window में अभी क्या मौजूद है। /clear या /compact पहले से हुआ usage वापस नहीं करता।

/usage
/cost
/stats

नीचे का निर्णय-चित्र चार commands को एक workflow में जोड़ता है। पहले /context से स्थिति देखें; केवल window का भरना task बदलने का प्रमाण नहीं है।

flowchart TD
    A["/context से window जांचें"] --> B{"क्या अगला काम वही task है?"}
    B -->|"हां"| C["focus instruction के साथ /compact"]
    B -->|"नहीं"| D["receipt लिखें और /clear"]
    C --> E["उसी task पर काम जारी रखें"]
    D --> F["नए brief से शुरू करें"]

काम शुरू होने से पहले context budget तय करें

“पूरा repository पढ़ो और ठीक करो” जैसी शुरुआत से बचें। Objective, scope, बाहर का काम, done condition, verification command और human approval points लिखें। इससे Claude की पहली file reads सीमित रहती हैं और बाद की compaction को स्थिर ढांचा मिलता है।

## Task brief
- Objective: expired-session redirect loop ठीक करना
- In scope: src/auth/, tests/auth/session.test.ts
- Out of scope: UI redesign और identity-provider migration
- Done when: expired session केवल एक बार /login पर redirect हो और regression test pass हो
- Verify with: npm test -- tests/auth/session.test.ts
- Human approval required for: cookie lifetime या public API behavior बदलना

फाइलें load करने से पहले shell में संकीर्ण search करें। नीचे के commands सीधे copy-paste करके paths और search terms बदल सकते हैं।

rg -n "expired session|redirect loop|set-cookie" src tests
git diff --stat
git status --short
npm test -- tests/auth/session.test.ts

यह क्रम पहले संभावित फाइलें खोजता है, फिर पहले से मौजूद changes बचाने में मदद करता है और अंत में focused test से स्पष्ट finish line देता है।

Compact करने से पहले handoff receipt छोड़ें

Receipt पूरा transcript नहीं है। यह उतनी ही state है जितनी किसी दूसरे व्यक्ति या agent को discovery दोहराए बिना आगे बढ़ने के लिए चाहिए। Raw log के बजाय outcome लिखें। “session.test.ts:84 पर दो redirects निकल रहे हैं” उपयोगी है; एक ही stack trace की दो सौ lines उपयोगी नहीं हैं।

## Handoff receipt
- Objective:
- Current diagnosis:
- Decisions already accepted:
- Files changed:
- Commands run and results:
- Uncommitted user changes to preserve:
- Remaining risk:
- Next action:

/compact के बाद क्या बचता है

Compaction सभी जानकारी को समान तरह से नहीं संभालती। सबसे नाजुक जानकारी वह है जो केवल chat में एक बार कही गई हो। उसका सार summary में आ सकता है, पर बारीक detail छूट सकती है।

Mechanism	/compact के बाद व्यवहार
System prompt और output style	conversation history का हिस्सा न होने के कारण unchanged रहते हैं
Project-root CLAUDE.md और unscoped rules	disk से दोबारा inject होते हैं
Auto memory	disk से दोबारा inject होती है
paths: frontmatter वाले rules	matching file फिर पढ़े जाने तक absent रहते हैं
subdirectory का nested CLAUDE.md	उस directory की file फिर पढ़े जाने तक absent रहता है
invoke किए गए skill bodies	documented per-skill और total limits के भीतर फिर inject होते हैं
Hooks	code की तरह चलते रहते हैं; conversational context नहीं हैं

हर session में जरूरी rule को project-root CLAUDE.md या किसी उचित persistent file में रखें। Directory-specific rule को scoped रखें, लेकिन compaction के बाद matching file पढ़े बिना उसके सक्रिय होने की उम्मीद न करें। CLAUDE.md में compact instructions भी छोटी रखी जा सकती हैं:

# CLAUDE.md

## Compact instructions
- Preserve the current objective, accepted decisions, and out-of-scope areas.
- Preserve changed files, verification commands, test results, and blockers.
- Keep only log lines that explain the root cause.
- Preserve uncommitted user changes and the next safe action.

Agent और इंसान की जिम्मेदारी अलग रखें

Claude search, summary, test और proposed change संभाल सकता है। Business या security impact वाला फैसला repository देखकर सुरक्षित रूप से अनुमान नहीं लगाया जा सकता, इसलिए वह इंसान के पास रहना चाहिए।

Claude Code को सौंपें	इंसान तय करे
संबंधित फाइलें खोजना और लंबे log से root cause निकालना	business objective और स्वीकार्य trade-off
context pressure बताना और compact का समय सुझाना	दो tasks वास्तव में related हैं या नहीं
observed work से handoff receipt बनाना	destructive operation, credential या production change की अनुमति
तय verification commands चलाना	security policy, public behavior या data retention में बदलाव
approval के बाद documented rule update करना	stakeholders के विरोधी requirements का अंतिम निर्णय

चार उपयोग के मामले

उपयोग मामला 1: कई फाइलों वाला authentication refactor

स्थिति: Middleware, cookie utility, integration test और deployment settings की research एक conversation को जल्दी भर देती है।

Agent की सीमा: Search से auth path map करे, broad documentation research अलग subagent या note में रखे और main context में केवल चुना contract, target files और focused test result लौटाए।

इंसानी checkpoint: Cookie lifetime, logout behavior और compatibility guarantee का बदलाव approve करें। Discovery के बाद /context चलाएं, accepted design receipt में लिखें और editing से पहले focused /compact करें।

उपयोग मामला 2: failing deployment की debugging

स्थिति: कई retries लगभग एक जैसे logs बनाते हैं और causal error package output में दब जाता है।

Agent की सीमा: Attempts compare करे, पहला causal error, environment और exact command लिखे तथा duplicate output summary से हटाए।

इंसानी checkpoint: Credential, provider configuration या rollback approve करें। उसी incident पर काम जारी है तो compact करें; deployment verify होने के बाद ही unrelated feature के लिए clear करें।

उपयोग मामला 3: technical article बनाना और review करना

स्थिति: Source research, editorial rules, code checks, translation notes और rendered-page QA writing conversation को भर देते हैं।

Agent की सीमा: Research notes अलग file में, durable editorial rules CLAUDE.md में और final article MDX में रखे। केवल confirmed facts और unresolved questions writing session में लाए।

इंसानी checkpoint: Audience, commercial promise और primary CTA तय करें। Agent wording सुधार सकता है, लेकिन अनुभव, benchmark या customer result गढ़ नहीं सकता। संबंधित workflows के लिए CLAUDE.md best practices, token optimization और Obsidian integration पढ़ें।

उपयोग मामला 4: bug fix से नए feature पर जाना

स्थिति: Bug fix पूरा है, पर उसी terminal में अगला prompt unrelated dashboard feature के लिए आता है।

Agent की सीमा: Final diff और test result report करे और साफ task boundary सुझाए।

इंसानी checkpoint: तय करें कि bug fix का कोई follow-up अगले काम में जरूरी तो नहीं। फिर /clear bug-fix-complete से नया brief शुरू करें; पुरानी detail चाहिए तो /resume करें।

सामान्य गलतियां, जोखिम और सुधार

गलती 1: /compact को perfect backup समझना

Summary selective होती है, इसलिए एक बार कही गई छोटी constraint छूट सकती है। सुधार: durable rules specification या CLAUDE.md में और accepted decisions receipt में लिखें।

गलती 2: active task के बीच /clear चलाना

इससे वही diagnosis दोबारा बनानी पड़ सकती है। सुधार: objective और acceptance test वही हों तो focus instruction के साथ compact करें; असली task boundary पर ही clear करें।

गलती 3: /memory को loaded-files report मानना

Nested memory और path-scoped rules अभी active न हों। सुधार: /context में Memory files देखें और compaction के बाद जरूरत पड़ने पर matching file पढ़ें।

गलती 4: enforcement केवल CLAUDE.md में रखना

CLAUDE.md contextual guidance है, hard security boundary नहीं। सुधार: जिन actions को रोकना या validate करना अनिवार्य है उनके लिए permissions और hooks उपयोग करें।

गलती 5: auto memory को team documentation मानना

Auto memory दूसरी machine पर अपने-आप साझा नहीं होती। सुधार: team conventions committed CLAUDE.md, rules या docs में रखें।

गलती 6: usage और available context को एक मानना

Low plan usage के साथ context window भरी हो सकती है। सुधार: context साफ करने का फैसला /context से और consumption का फैसला /usage से करें।

पांच कदम की रोजमर्रा की प्रक्रिया

1. Brief: Objective, scope, exclusions, completion test और approvals लिखें।
2. Narrow: Search पहले करें और अगले निर्णय के लिए जरूरी files/output ही load करें।
3. Inspect: बड़ी discovery के बाद या Claude के दोहराने पर /context चलाएं।
4. Record: Accepted decisions, changed files, verification result और next action लिखें।
5. Choose: उसी task के लिए /compact, नए task के लिए /clear और saved work पर लौटने के लिए /resume चुनें।

इस workflow के लिए reusable prompts और operating templates चाहिए तो Claude Code practical prompt guide देखें।

आधिकारिक स्रोत

• Context window को समझें
• Commands reference
• Claude project को कैसे याद रखता है
• Sessions manage करें

हमने क्या सत्यापित किया

इस revision में command names और aliases को official commands reference से मिलाया गया: /cost और /stats, दोनों /usage की ओर जाते हैं, जबकि /stats Stats tab खोलता है। Official context-window table से यह भी जांचा गया कि root CLAUDE.md और auto memory compaction के बाद फिर inject होते हैं, लेकिन nested CLAUDE.md और path-scoped rules matching file पढ़े जाने तक वापस नहीं आते। /clear के बाद saved conversation को resume करने का व्यवहार sessions documentation से और memory files के scope को memory documentation से सत्यापित किया गया। ऊपर दिए shell commands syntax-level पर दोबारा जांचे गए; project-specific paths को अपने repository के अनुसार बदलना होगा।