Claude Code को रोज़मर्रा के टूल की तरह इस्तेमाल करना: Claude.md, Skills, Subagents, Plugins, MCP

(arps18.github.io)

1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Claude Code की प्रोडक्टिविटी केवल prompts से नहीं, बल्कि memory, custom commands, parallel sessions और project settings को कैसे जमा और verify किया जाता है, इससे बहुत बदलती है
CLAUDE.md को छोटा और verification-केंद्रित संचयी इंफ्रास्ट्रक्चर की तरह चलाना चाहिए; गलती के बाद rule जोड़ने से वही गलती दोबारा होने की संभावना कम होती है
.claude/ CLAUDE.md, rules, skills, commands, agents, MCP settings को रखने वाला एक hierarchical configuration system है, जो project और global scope को अलग करके लागू करता है
Skills दोहराए जाने वाले कामों को reusable expertise में बदलते हैं, और subagents अलग context में review, debugging और migration जैसे काम करते हैं
Plugins, MCP, /goal, /rewind, /batch, और parallel worktree तक को जोड़ दिया जाए, तो Claude Code एक configure और operate किया जाने वाला development agent बन जाता है

Claude Code को एक verify किए जा सकने वाले agent की तरह संभालना

Claude Code की प्रोडक्टिविटी में फर्क साधारण prompts से नहीं, बल्कि memory, custom commands, parallel sessions, और project settings को कैसे जमा किया जाता है, इससे पैदा होता है
मुख्य सिद्धांत यह है कि Claude अपने ही output को verify कर सके; Boris Cherny और Anthropic टीम का मानना है कि सिर्फ इस तरीके से भी quality 2~3 गुना बेहतर हो सकती है
काम का flow exploration → planning → implementation क्रम में सबसे उपयुक्त है
- Shift+Tab दो बार दबाकर खुलने वाला planning mode read-only exploration के लिए उपयुक्त है
- पहले files पढ़कर flow और data model को समझना, फिर plan बनाकर execute करना सुझाया जाता है
- कई files को छूने वाले काम में planning mode उपयोगी है, जबकि छोटे बदलावों में इसे छोड़ा जा सकता है
planning mode को implementation से पहले review किए जा सकने वाले design document की तरह इस्तेमाल किया जा सकता है
- एक Claude plan लिखे, और नई session में दूसरा Claude बिना bias वाले staff engineer की तरह उसका review करे, ऐसा कराया जा सकता है
- अगर implementation भटक जाए, तो planning mode में लौटकर verification step समेत दोबारा planning करना उपयुक्त रहता है
- Ctrl+G से Claude का plan editor में खोलकर implementation से पहले सीधे edit किया जा सकता है
अस्पष्ट निर्देशों की तुलना में सटीक reference ज्यादा प्रभावी होते हैं
- “auth module को देखो” कहने की बजाय @src/auth/login.py की तरह file सीधे बताई जाती है
- errors को paste करने की बजाय cat error.log | claude की तरह pipe से दिया जाता है
Cat Wu के अनुसार Claude Code सबसे अच्छा तब काम करता है जब उसे line-by-line निर्देश लेने वाले pair programmer की तरह नहीं, बल्कि delegated engineer की तरह माना जाए
अगर Claude गलती करे, तो prompt के अंत में “Update CLAUDE.md so you do not repeat this.” जोड़कर उससे ऐसा rule लिखवाया जा सकता है जो वही गलती दोबारा होने से रोके

`.claude` directory और configuration hierarchy

.claude/ सिर्फ CLAUDE.md रखने वाला folder नहीं, बल्कि एक hierarchical configuration system है
settings दो scopes में बँटी होती हैं
- project scope: repository के भीतर .claude/ में रखा जाता है और git में commit करके team के साथ share किया जाता है
- global scope: ~/.claude/ में रखा जाता है और local machine के सभी projects पर लागू होता है
project files को project का विवरण देने वाला, और global files को user की preferences और काम करने के तरीके का विवरण देने वाला model समझा जा सकता है
मुख्य files की भूमिकाएँ
- CLAUDE.md: project और global, दोनों scope में हो सकता है; हर session में load होने वाला instruction file
- CLAUDE.local.md: project-specific private notes; .gitignore में रखा जाना चाहिए
- settings.json: permissions, hooks, environment variables, default model settings
- settings.local.json: private override; अपने आप gitignore हो जाता है
- .mcp.json: project में team द्वारा share की जाने वाली MCP server setting
- skills/<name>/SKILL.md: /name से बुलाया जाने वाला reusable prompt
- commands/*.md: single-file slash command
- agents/*.md: subagent definitions
- rules/*.md: topic-wise instructions, जिन्हें path के हिसाब से लागू किया जा सकता है
CLAUDE.md cascade तरीके से load होता है
- monorepo में root/CLAUDE.md और root/services/billing/CLAUDE.md दोनों साथ load हो सकते हैं
- यह उन codebases के लिए उपयुक्त है जहाँ folder के हिसाब से conventions अलग हों
.claude/rules/*.md path-specific instructions के लिए उपयुक्त है
- migration folder में ही ज़रूरी rules हों, तो उन्हें पूरे session को भारी बनाने वाले CLAUDE.md की बजाय glob के साथ .claude/rules/migrations.md में रखना बेहतर है
नए कामों के लिए commands की तुलना में skills की सिफारिश की जाती है
- .claude/commands/*.md और .claude/skills/<name>/SKILL.md दोनों slash commands बना सकते हैं
- skills auxiliary files, disable-model-invocation, allowed tools, और agent overrides को support करते हैं
claude project purge ~/path/to/repo --dry-run से किसी खास project के लिए Claude द्वारा रखी गई local state देखी जा सकती है

`CLAUDE.md` को छोटा और verification-केंद्रित रखना

CLAUDE.md हर session की शुरुआत में load होता है, इसलिए इसे गलत तरीके से लिखने पर Claude वही गलतियाँ दोहराता है, और सही तरीके से लिखने पर उसी prompt से मिलने वाले results काफी बेहतर हो जाते हैं
सबसे महत्वपूर्ण सिद्धांत है इसे छोटा रखना
- हर line पर यह पूछना कि “अगर यह line हटा दी जाए, तो क्या Claude गलती करेगा?”; अगर जवाब नहीं है, तो उसे हटा देना सुझाया जाता है
अगर Claude से उसके अपने rules लिखवाए जाएँ, तो cumulative effect पैदा होता है
- Claude से गलती होने पर “Update CLAUDE.md so you do not repeat this.” कहने पर वह उस गलती को एक सटीक rule के रूप में summarize कर सकता है
- कुछ हफ्तों तक इसे दोहराने पर project के pitfalls rules की list के रूप में जमा हो जाते हैं
Claude Code team का वास्तविक CLAUDE.md build commands और verification order पर केंद्रित होता है
- bun इस्तेमाल होता है, npm नहीं
- changes के बाद तेज typecheck, test, commit से पहले lint, और PR से पहले full verification order को स्पष्ट किया जाता है
- style preferences, codebase tour, या सामान्य बातें शामिल नहीं की जातीं
PR comments में भी @claude का इस्तेमाल करके सीधे rules जोड़े जा सकते हैं
- उदाहरण: @claude add to CLAUDE.md to never use enums, always prefer literal unions
- PR review से CLAUDE.md बेहतर होता है और “Compounding Engineering” जैसा flow बनता है
अच्छा CLAUDE.md इन जानकारियों पर केंद्रित होता है
- code style: CommonJS की जगह ES modules का उपयोग
- workflow: bun run typecheck चलाना, main पर सीधे push न करना
- architecture: API routes को एक तय middleware से ज़रूर गुजरना चाहिए
- gotchas: User और UserRecord का अंतर, और यह कि formatCurrency USD को मानकर चलता है
जिन चीज़ों को CLAUDE.md में नहीं रखना चाहिए
- standard language conventions
- file-by-file codebase explanations
- लंबे tutorials
- API documentation
- बार-बार बदलने वाली बातें
IMPORTANT, YOU MUST जैसे expressions compliance बढ़ा सकते हैं, लेकिन उनका असर बनाए रखने के लिए उन्हें कम इस्तेमाल करना चाहिए
@path syntax से दूसरी files को include करके CLAUDE.md को छोटा रखते हुए details जोड़ी जा सकती हैं
- उदाहरण: See @README.md for project overview and @package.json for scripts.
- उदाहरण: @~/.claude/my-preferences.md

`CLAUDE.local.md` से personal feedback जमा करना

CLAUDE.local.md उसी location पर और उसी तरीके से load होता है जिस तरह CLAUDE.md, लेकिन इसे local machine के बाहर नहीं जाना चाहिए और .gitignore में जोड़ना चाहिए
PR review comments को तुरंत CLAUDE.local.md में डालने पर बार-बार मिलने वाला personal feedback एक private rule file के रूप में जमा होता जाता है
example rules
- नए SQS consumer के साथ उसी PR में DLQ और alarms भी होने चाहिए
- null return करने की बजाय Optional<T> को prefer किया जाता है
- नए endpoint tests में auth-failure case शामिल होना चाहिए
- endpoint जोड़ने पर OpenAPI spec भी update करनी चाहिए
file को project-specific feedback और personal habit-correction items को अलग रखने के हिसाब से व्यवस्थित करना बेहतर है
कुछ हफ्तों बाद जो बातें पहले ही आदत बन चुकी हों, उन्हें हटा देना चाहिए और सिर्फ वही छोड़ना चाहिए जो अभी भी सीखी जा रही हों

Skills: दोबारा इस्तेमाल की जा सकने वाली विशेषज्ञता की इकाइयाँ

Skills, Claude Code को “कुछ भी कर सकने वाले agent” से बदलकर ऐसे agent में बदल देती हैं जो खास project tasks को अच्छी तरह कर सके; ये दोबारा इस्तेमाल की जा सकने वाली विशेषज्ञता की इकाइयाँ हैं
Skill संरचना
- skill, .claude/skills/<name>/ या ~/.claude/skills/<name>/ के नीचे एक folder होता है
- folder के अंदर SKILL.md में frontmatter और निर्देश होते हैं
- folder का नाम ही slash command बन जाता है
- उदाहरण के लिए, अगर ~/.claude/skills/summarize-changes/SKILL.md बनाया जाए तो /summarize-changes हर session में इस्तेमाल किया जा सकता है
Skill शक्तिशाली क्यों है
- क्रमिक खुलासा: session शुरू होने पर सिर्फ frontmatter description load होती है, और पूरा SKILL.md तथा सहायक files तभी load होती हैं जब वास्तव में ज़रूरत हो
- folder-आधारित संगठन: templates, reference docs, scripts, और settings को साथ में बांधा जा सकता है
- inline shell: ! से शुरू होने वाली पंक्तियाँ command चलाती हैं और invocation के समय का output inject करती हैं
Frontmatter विकल्प
- description: यह बताता है कि इस skill का इस्तेमाल कब करना चाहिए
- disable-model-invocation: true: इसे केवल तब चलने देता है जब user स्पष्ट रूप से /my-skill दर्ज करे
- allowed-tools: Read, Grep, Bash जैसे इस्तेमाल होने वाले tools को सीमित करता है
- agent: किसी खास agent mode में चलाया जा सकता है
- deployment जैसे side effect वाले skills के लिए disable-model-invocation: true उपयुक्त है
Go API convention skill का उदाहरण
- Go service team के लिए नया HTTP handler scaffold बनाने वाला skill, SKILL.md, templates/handler.go.tmpl, और examples/healthz.go को साथ रख सकता है
- rules के उदाहरणों में Go 1.22, chi router, sqlc typed query, zap structured logging, testify assertion, और table-driven test को प्राथमिकता जैसी project-specific conventions शामिल हो सकती हैं
- gotcha उदाहरणों में बार-बार होने वाली गलतियों को रोकने वाली बातें शामिल हैं, जैसे chi.URLParam missing param पर "" लौटाता है, httperr.Wrap log नहीं छोड़ता, और pgtype.Text में .Valid की जाँच ज़रूरी होती है
ऐसे Skills जिन्हें install करना उपयोगी हो सकता है
- mattpocock/skills: लगभग 100k stars वाला लोकप्रिय skills repository
  - /grill-me: code लिखने से पहले plan पर सवाल-जवाब करता है
  - /tdd: red-green-refactor को सख्ती से लागू करता है
  - /diagnose: reproduce, minimize, hypothesis, fix, regression test के क्रम में debugging करता है
  - install: npx skills@latest add mattpocock/skills
- Jeffallan/claude-skills: go-pro, python-pro, java-architect, typescript-pro, rust-engineer, sql-pro सहित 66 language-specific profiles देता है
- Anthropic के official skills
  - /code-review: चार parallel agents diff का audit करते हैं और केवल confidence score पर आधारित findings report करते हैं
  - /simplify: हाल के code को reusability और efficiency के नज़रिए से review करता है
  - /batch: migration को कई parallel agents में बाँटता है और हर एक को अपने worktree में संभालने देता है
  - /webapp-testing: Claude को Playwright के साथ local web app test करने देता है
- जो काम आप दिन में एक बार से ज़्यादा दोहराते हैं, उन्हें skill में बदलना बेहतर है
- skills को git में commit करने पर वे टीम का organizational knowledge बन जाती हैं, और नया engineer repository clone करते ही जमा हुई working practices हासिल कर लेता है

Subagents: अलग context में फोकस्ड काम कराना

subagent अपने context window और अपने tool permissions के साथ चलता है, और बाद में summary लौटाता है
इसकी मुख्य value यह है कि यह बहुत सारी files पढ़कर भी main session context को नहीं भरता
subagent, .claude/agents/ या ~/.claude/agents/ के नीचे एक markdown file होता है, और frontmatter में name, description, tools, model घोषित किए जाते हैं
/pr-review agent की संरचना
- इसे इस तरह define किया जा सकता है कि यह current branch diff को main से compare करके bug, security issue, छूटे हुए edge case, और project convention के उल्लंघन ढूँढे
- tools: Read, Grep, Glob, Bash देकर इसे read-focused permissions दी जा सकती हैं
- model: opus का उपयोग करके high-risk review के लिए अधिक मजबूत model इस्तेमाल किया जा सकता है
- process में git diff main...HEAD, git log main..HEAD --oneline, पूरी file पढ़ना, और CLAUDE.md, CLAUDE.local.md, .claude/rules/ के साथ cross-check शामिल हो सकता है
- output को Critical / High / Medium / Low में समूहित किया जा सकता है, जिसमें file, line, issue, suggested fix शामिल हों, और अंत SHIP, FIX FIRST, या REWORK में से किसी एक से हो
signal-to-noise ratio बढ़ाने वाली design
- अगर reviewer code को modify करता है, तो अपनी ही changes का बचाव करने वाला bias आ सकता है, इसलिए read-only tools उपयुक्त हैं
- अगर “Do NOT flag” section में यह साफ लिखा जाए कि project rules में न होने वाली style preferences, काम कर रहे code के लिए refactoring suggestions, और diff के बाहर की चीज़ों को exclude किया जाए, तो noise कम होता है
अक्सर इस्तेमाल होने वाले subagent patterns
- Claude Code team build-validator, code-architect, code-simplifier, oncall-guide, verify-app को check in करती है
- security-reviewer: injection, auth, secrets, insecure deserialization की जाँच
- test-writer: test generation, और code-reviewer के साथ loop बनाना
- debugger: failing test को root cause तक trace करना
- performance-auditor: flow और query profiling
- migration-writer: project conventions के अनुरूप DB migration बनाना
- release-notes-writer: commit history से changelog लिखना
- Session A implementation करता है और code-reviewer subagent नए context में review करता है; यह implementation bias को कम करता है
- अगर frontmatter में isolation: worktree जोड़ा जाए, तो subagent को अलग git worktree में चलाया जा सकता है, जो कई parallel agents में migration बाँटने पर उपयोगी है

Plugins और Marketplace

Plugins, skills, hooks, subagents और MCP servers को एक इंस्टॉल किए जा सकने वाले यूनिट में बाँधते हैं
/plugin से marketplace browser खोला जा सकता है
/plugin marketplace add owner/repo से community marketplace जोड़ा जा सकता है
शुरुआत में इंस्टॉल करने लायक आइटम
- /code-review: चार parallel agent चलते हैं; दो CLAUDE.md के पालन की जाँच करते हैं, एक bug का विश्लेषण करता है, और एक git blame-आधारित context का विश्लेषण करता है
- /feature-dev: feature brief को requirements → exploration → architecture → implementation → testing → review → docs के 7 चरणों के ज़रिए working code में बदलता है
- Language server plugin: सटीक symbol navigation और edit के बाद automatic diagnostics देता है, और टीम इसे सबसे ज़्यादा असर वाला plugin कहती है
- /security-guidance: Anthropic का official security skill, जो ship करने से पहले security concerns सामने लाता है
- 2026 के मध्य तक marketplace में 75 से अधिक marketplace पर 1,000 से अधिक plugins हैं
- प्रमुख plugin categories हैं Git workflow, code intelligence(LSP), documentation generators, testing, browser automation(Playwright), design system(Figma), observability(Sentry, Datadog)
- अगर team-shared .mcp.json और चुने हुए plugins साथ रखे जाएँ, तो नया engineer repository clone करने के कुछ ही मिनटों में productive काम कर सकता है

उत्पादकता पर बड़ा असर डालने वाले Claude Code कमांड

बहुत से users /clear, /compact, /init सीखकर रुक जाते हैं, लेकिन दूसरे commands भी रोज़मर्रा की productivity पर बड़ा असर डालते हैं
प्रमुख कमांड
- /insights: usage patterns का विश्लेषण करता है; इसे महीने में एक बार चलाना उपयोगी हो सकता है
- /compact <hint>: session को compress करता है, और hint यह नियंत्रित करता है कि क्या preserve किया जाए
- /copy: पिछला response कॉपी करता है और code blocks के लिए interactive picker देता है
- /rewind: पूरे session के लिए undo की तरह है, जो code और conversation या दोनों को restore करता है
- /btw: side questions जो conversation history में नहीं जाते
- /context: context usage को visualize करता है
- /export <file>: conversation को file में dump करता है
- /branch: risky कोशिशों के लिए session को fork करता है
- /batch: worktree भर में parallel agents के साथ काम बाँटता है
- /loop <interval>: Claude को अधिकतम 3 दिनों तक बार-बार चलाता है
- /schedule: /loop का cloud version, जो laptop बंद होने पर भी चलता है
- /teleport: terminal और web के बीच session को move करता है
- /focus: बीच के tool calls छिपाकर सिर्फ final result दिखाता है
- /voice: voice input
- --bare: non-interactive claude -p उपयोग में startup को अधिकतम 10 गुना तेज़ करता है
/compact और /clear का अंतर
- पूरी तरह नए काम के लिए /clear और नया लिखा गया brief उपयुक्त है
- अगर काम संबंधित है और अभी भी context चाहिए, तो hint के साथ /compact उपयुक्त है
- /compact lossy LLM summary है, जबकि /clear user द्वारा सीधे लिखा गया brief है, इसलिए इनका अंतर समझना महत्वपूर्ण है
/rewind का उपयोग कैसे करें
- अगर Claude गलत दिशा में चला जाए, तो उसके बाद “वह काम नहीं किया, इसलिए X करके देखो” लिखते रहना बेहतर नहीं है
- ऐसा जारी रखने से context दूषित हो जाता है, इसलिए rewind करके सीखी गई बातों को शामिल करते हुए फिर से prompt करना बेहतर है
- Esc दो बार दबाकर rewind खोला जा सकता है
- ! को shell escape की तरह इस्तेमाल किया जा सकता है
- !git status, !npm test की तरह तुरंत चलाया जा सकता है और output context में शामिल हो जाता है
- CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 setting का उपयोग 1M model में 300~400k tokens के आसपास context rot शुरू होने से पहले compaction को जल्दी forced करने के लिए किया जाता है
Fan-out pattern
- पहले task list बनाई जाती है और तीन files पर test किया जाता है
- prompt ठीक करने के बाद इसे हज़ारों files पर लागू किया जाता है
- उदाहरण:

for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --bare
done

`/goal`: built-in completion condition वाला iterative loop

/goal completion condition सेट करता है, और जब भी Claude रुकने की कोशिश करता है, transcript के आधार पर उस condition की जाँच करवाता है
condition verifiable और deterministic होनी चाहिए
- test command
- CLI exit code
- file state
उदाहरण:

/goal all tests in test/auth pass and the lint step is clean
/goal all integration tests in tests/api pass without flaking 3 runs in a row
/goal the OpenAPI spec validates and matches the actual response shapes
/goal docker compose up runs cleanly and the healthcheck endpoint returns 200
/goal coverage on src/billing/ is above 80% and all new tests are not placeholders

“कोड अच्छा है” जैसी अस्पष्ट conditions काम नहीं करतीं
साथ में इस्तेमाल करने लायक features
- /loop: backlog कम करने के लिए नियमित अंतराल पर दोहराता है
- /schedule: cloud में periodic execution करता है
- Stop hook: अपनी test suite या CI endpoint के साथ gate सेट करता है
- Auto mode: लंबे goal permission prompts की वजह से रुक न जाएँ, यह सुनिश्चित करता है
/goal + auto mode + /focus का संयोजन ऐसे flow को लक्ष्य बनाता है जिसमें स्पष्ट brief और completion condition देकर वापस आने तक PR तैयार हो चुका हो

MCP को system awareness tool के रूप में इस्तेमाल करना

MCP(Model Context Protocol) Claude Code को सिर्फ़ coding agent से आगे बढ़ाकर बाहरी systems को समझने वाला agent बनाता है
MCP server database, design tool, error tracker, notes जैसे बाहरी tools को standard तरीके से Claude के सामने expose करता है
MCP के बिना Claude files पढ़ता है और commands चलाता है, लेकिन MCP के साथ वह terminal से बाहर जाए बिना Linear ticket, Postgres query, Figma component, Sentry stack trace और Obsidian vault को संभाल सकता है
इंजीनियरिंग में अक्सर इस्तेमाल होने वाले MCP
- GitHub: repo management, PRs, issues, code search
- Context7: नवीनतम library docs, prompt में use context7 जोड़ें
- Sentry: वास्तविक error context, stack traces, breadcrumbs
- Linear: ticket पढ़ना और बनाना, status update
- Playwright: accessibility snapshot आधारित browser automation
- Figma: live design tree, auto-layout, spacing tokens, component refs
- Postgres / Supabase: dev DB पर सीधे query
- Slack: thread पढ़ना, discussion summary, response draft
- local server stdio का इस्तेमाल करता है, और vendor-hosted server OAuth वाले HTTP का उपयोग करते हैं
- उदाहरण:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

team-shared MCP को project root की .mcp.json में रखा जाता है, और personal MCP को ~/.claude.json में
बहुत ज़्यादा MCP install करने पर Claude को जिन tools की सूची पर विचार करना होता है वह बड़ी हो जाती है, जिससे decision-making की quality गिर सकती है
शुरुआती सेट के लिए GitHub, Context7, और एक-दो domain-specific MCP उपयुक्त हैं
/mcp Claude Code के भीतर active servers और connection status जाँचने का पहला checkpoint है

Obsidian और Claude Code की 3-layer memory structure

Obsidian + Claude Code का संयोजन सिर्फ़ “Claude vault पढ़ता है” से कहीं ज़्यादा शक्तिशाली है, जब इसे तीन-स्तरीय memory architecture की तरह इस्तेमाल किया जाए
सेटअप
- Obsidian में obsidian-claude-code-mcp install करें
- plugin vault को local WebSocket के port 22360 पर expose करता है
- Claude Code इसे auto-discover कर लेता है
- vault में CLAUDE.md जोड़कर folder structure समझाएँ
फ़ोल्डर संरचना
- 00-Inbox/: raw capture
- 10-Daily/: हर दिन के लिए एक note
- 20-Projects/: active project notes
- 20-Projects/billing-v2/README.md: goal, status, open questions
- 20-Projects/billing-v2/decisions/: ADRs
- 20-Projects/billing-v2/sessions/: हर Claude session का log
- 30-Decisions/: cross-project ADRs
- 40-Atoms/: reusable knowledge और links
- 90-Archive/: archive
Hot storage
- हर Claude session 10-Daily/<today>.md में timestamped log लिखता है
- Stop hook के ज़रिए agent बंद होने पर structured summary append कराई जा सकती है
Warm storage
- हर project का 20-Projects/ के नीचे एक folder होता है
- नई session से पहले Claude project README और हाल की 2~3 session logs पढ़कर context restore करता है
- यह 2 हफ़्तों का context 30 सेकंड के भीतर फिर से बनाने वाला flow है
Cold storage
- architecture decisions को 30-Decisions/ के ADR के रूप में promote किया जाता है
- reusable knowledge को 40-Atoms/ में refine किया जाता है और wikilinks से कई projects से जोड़ा जाता है
रोज़मर्रा workflow के उदाहरण
- What is in my inbox? Summarize and suggest where each item belongs.
- Check 30-Decisions/ for anything related to retry policies.
- Read the last 3 session logs for billing-v2. Tell me where I left off.

रोज़मर्रा development flow का optimization

नया feature
- plan mode से शुरुआत करें
- Ctrl+G से plan edit करें
- implementation के बाद /pr-review subagent को बुलाएँ या fresh Claude session में review करें
Bug
- पहले reproduce करें
- cat error.log | claude से error को pipe करें
- Claude से पहले failing test लिखवाएँ, फिर fix करवाएँ
- test को fix को सिर्फ़ अंदाज़े पर पूरा करने न दें
Migration और बड़े पैमाने के बदलाव
- /batch बदलावों के बारे में सवाल पूछता है और फिर उन्हें parallel agents में बाँट देता है
- हर agent अपने worktree में test चलाता है और PR बनाता है
अनजाना code
- “Use a subagent to investigate how our auth handles token refresh.” की तरह subagent का इस्तेमाल करें
- subagent अपने context में दर्जनों files पढ़कर summary लौटाता है, इसलिए main session साफ़ बना रहता है
Parallel sessions
- Boris और टीम के लिए 3~5 git worktree में अलग-अलग Claude sessions चलाना सबसे बड़ा productivity unlock माना गया
- claude agents agent view को control plane की तरह इस्तेमाल किया जा सकता है
Writer/Reviewer pattern
- Session A implementation करता है
- Session B fresh context से review करता है
- review वापस लाकर fix करें और इसे दोहराएँ
हर milestone पर compact
- जब कोई logical chunk पूरा हो जाए, तो /compact Preserve the decisions made, files changed, and test commands. की तरह साफ़ बताएँ कि क्या बचाए रखना है
- Claude को tests, screenshots, या वास्तविक command output जैसे evidence के बिना success claim नहीं करने देना चाहिए
- trust-then-verify gap को खराब नतीजों का सबसे बड़ा कारण बताया गया है

Anthropic टीम में बार-बार इस्तेमाल होने वाले पैटर्न

अगर Claude को अपना output वेरिफ़ाई करने दिया जाए, तो वह बेहतर नतीजा आने तक दोहराव कर सकता है
Boris ज़्यादातर कामों के लिए Opus और high या xhigh effort का इस्तेमाल करते हैं
- वजह यह है कि अगर छोटा model ज़्यादा edits मांगता है, तो कुल मिलाकर वह धीमा पड़ सकता है
3~5 sessions को parallel में चलाया जाता है
- checkout की बजाय worktree का इस्तेमाल किया जाता है
- claude --worktree या Desktop app का इस्तेमाल किया जा सकता है
- agent view parallel sessions को एक साथ बांध देता है
हर project के लिए notes directory रखी जाती है और हर PR के बाद उसे update किया जाता है
- अगर CLAUDE.md को उस notes directory की ओर point कराया जाए, तो codebase के बारे में उसकी self-knowledge जमा होती रहती है
/techdebt slash command बनाकर हर session के अंत में duplicate code ढूंढकर हटाया जा सकता है
टीम का CLAUDE.md साझा किया जाता है और हफ़्ते में कई बार बदला जाता है
- इसे एक living document की तरह देखा जाता है, जिसमें Claude की गलती देखने वाला व्यक्ति नया rule जोड़ देता है
UI बदलावों के लिए Playwright MCP उपयुक्त है
- Claude browser खोलकर, क्लिक करके और वेरिफ़ाई करके जांच कर सकता है
language server plugin हर edit के बाद type error और unused imports पकड़ लेता है, और इसे सबसे ज़्यादा असरदार plugin बताया गया है
/voice prompt को और ज़्यादा विस्तार से बनाने में मदद कर सकता है
- इसके साथ यह वजह भी दी गई है कि बोलना typing से 3 गुना तेज़ है
implementation से पहले editor में Ctrl+G से Claude plan को edit करने का तरीका, chat में correction टाइप करने से तेज़ है
Boris अनजान protocol और codebase को समझते समय Claude से ASCII diagram बनवाते हैं

संदर्भ सामग्री

आधिकारिक दस्तावेज़
Boris और टीम
Skills
Subagents
- VoltAgent/awesome-claude-code-subagents
- hesreallyhim/a-list-of-claude-code-agents
Plugins और marketplaces
- Chat2AnyLLM/awesome-claude-plugins
- claudemarketplaces.com
MCPs

1 टिप्पणियां

GN⁺ 4 시간 전

Hacker News की राय

commands, skills, subagents, plugins बहुत बिखरे हुए हैं, इसलिए इन्हें व्यवस्थित करने की ज़रूरत है
उदाहरण के लिए सिर्फ code review के लिए ही .claude/commands/review.md, /code-review skill, /pr-review subagent, /code-review plugin, और बस सीधे Claude से review माँगने तक — कुल पाँच विकल्प हो जाते हैं
आखिरकार इनमें से ज़्यादातर पहले से बने prompt डालने के ही रूपांतर हैं, फर्क बस इतना है कि prompt कहाँ install होता है और किस context में चलता है
कौन-सा विकल्प सबसे अच्छा है, इस पर सलाह भी कम है और best practices भी अभी स्पष्ट नहीं हैं, और व्यक्तिगत रूप से मुझे तो बस Claude से code review करने को कहना भी काफ़ी अच्छा काम करता है
और “language server plugin install करो” वाली सलाह भी अनुभव के हिसाब से सही नहीं लगी। मैंने Rust, Python, Dart के LSP को Claude Code और Codex में install किया था, लेकिन दो महीने में सैकड़ों sessions चलाने के बाद logs देखे तो असली LSP tool call सिर्फ एक बार हुआ था, और Rust analyzer/Dart analysis server/Ty LSP की वजह से RAM ही बार-बार कम पड़ती रही
आखिरकार मैंने LSP हटा दिया, और agent का ripgrep, cargo clippy, dart analyze, ty check वगैरह सीधे call करना भी पूरी तरह काफ़ी था
- मैं CC टीम का Boris हूँ, और इस बात से सहमत हूँ; हम consolidation पर काम कर रहे हैं। आगे चलकर यह एक built-in /code-review skill में सिमट जाएगा
  latest version में /code-review balanced review करता है, /code-review --fix fixes भी करता है, और /code-review low|medium|high|xhigh|max से effort level चुना जा सकता है
  /code-review ultra महँगा और बहुत thorough review mode है; complexity के हिसाब से प्रति review लगभग $3~20 लगते हैं, और इसका लक्ष्य 99% से ज़्यादा bugs को reliably पकड़ना है
  इसे और उपयोगी बनाने के लिए अगर कोई idea हो तो feedback लेना चाहूँगा
- कुछ समय से मुझे लगता रहा है कि skills एक खराब abstraction हैं। इन्हें किस काम के लिए इस्तेमाल करना है, इसकी परिभाषा धुँधली है, इसलिए ये लोकप्रिय तो हुए, लेकिन यही बात इन्हें लंबी अवधि में कमज़ोर बनाती है
  frontend design best practices जैसी general guidance, ऐसे execution procedures जिन्हें सिर्फ explicitly call करने पर ही ठीक से follow करना चाहिए, और किसी specific tool के इस्तेमाल की व्याख्या — इन सबका skill के रूप में लिया जाना अजीब लगता है
  मैं समझता हूँ कि जब सब लोग मिलकर नए tools सीख रहे हों, तब flexibility आकर्षक लगती है, लेकिन skills अब धीरे-धीरे “जब समझ न आए कि किसी चीज़ को कहाँ रखना है, तो रसोई के कबाड़ वाले दराज़ में फेंक दो” जैसी लगने लगी हैं
  बेहतर विभाजन शायद यह होगा कि Agents मॉडल का स्वभाव या दृष्टिकोण हों, Prompts किसी specific task के लिए बार-बार इस्तेमाल होने वाले निर्देश, और Tools को CLI/MCP/scripts तथा उनके usage instructions के रूप में standardize किया जाए
- subagent तरीका बाकी विकल्पों से संरचनात्मक रूप से अलग है। क्योंकि यह साफ़ context में चलता है
  पहला, LLM session की लागत हर round में input tokens और cached input cost दोनों लेती है, इसलिए बाकी शर्तें समान हों तो समाधान तक पहुँचने की कुल लागत कम हो सकती है
  दूसरा, review model के लिए main session की “x को y की तरह होना चाहिए” जैसी धारणाएँ साथ लाकर shortcut मारना मुश्किल होता है। यह कुछ वैसा ही है जैसे इंसानों में अलग व्यक्ति से review कराना, या दिमाग रीसेट करके review करना उपयोगी होता है
  तीसरा, main model सिर्फ review result देखता है, detailed reasoning नहीं, इसलिए context pollution कम होता है; लेकिन मिले हुए bug के सिद्धांत को फिर से समझने में duplicate logic बन सकती है
  language server plugin वाली सलाह का इरादा शायद यह नहीं है कि LLM उसके explicit call का इंतज़ार करे, बल्कि यह कि हर edit पर lint अपने-आप चले
- अभी यह सब मुझे ऐसा लगता है जैसे मॉडल अभी भी काफ़ी बेवकूफ़ हैं और execution environment भी पूरी तरह mature नहीं है — यानी एक अस्थायी चरण। अगर code review चाहिए तो बस “review कर दो” कहना चाहिए, और कौन-सा plugin या skill इस्तेमाल करना है, यह मॉडल को खुद तय करना चाहिए
- सही बात है। industry और developer ecosystem “मशीन में text डालने” की क्रिया को छोटे-छोटे protocols और mechanisms में पैक करने के प्रति ज़रूरत से ज़्यादा मोहित हैं
  यह उपयोगी है और consistency भी देता है, लेकिन मुझे लगता है लोगों को इसका सबसे बड़ा आकर्षण यह है कि इससे “जटिल tools सँभालने वाले programmer” होने की एक पतली परत बनी रहती है। असल में हम सब AI से विनम्रता से अनुरोध ही कर रहे हैं
मुझे नहीं पता coding agents के इस्तेमाल पर ऐसी उथली AI-शैली की guides मुझे और कितनी बार पढ़नी पड़ेंगी। आखिर यह कब रुकेगा
- “यह point उठाना सही है, ज़रा ठहरकर सोचते हैं, दरअसल यह AI writing या coding agents की समस्या नहीं, बल्कि इससे गहरी समस्या है…” जैसी पंक्तियों की नकल हाथ से करके लिखना भी थकाने वाला व्यंग्य है
- बहुत बढ़िया, अब हम यह भी सीख सकते हैं कि किसी एक कंपनी की मदद के बिना coding न कर पाने वाली मज़बूत vendor lock-in कैसी होती है
- यह दिलचस्प है कि ऐसे लगभग सारे लेख Claude या Claude Code पर ही फिट बैठते हैं
  open source glm-5.1 भी वैसा ही या उससे बेहतर है, और opencode जैसी चीज़ें भी हैं, तो कुछ सोचने पर मजबूर करता है
- आजकल की strategy यही है कि किसी एक लोकप्रिय product के साथ कुछ अच्छा कर लो या मत करो। life hacking posts और blogs जो best tool या best method की बात करते हैं, मैं न पढ़ता हूँ न क्लिक करता हूँ
- पिछले 2 साल मैं बच्चे की देखभाल में इतना व्यस्त था कि AI को सफलतापूर्वक नज़रअंदाज़ करता रहा, लेकिन अब कुछ हफ़्तों में इसकी भरपाई करने की कोशिश कर रहा हूँ। सोच रहा हूँ कि अभी शुरू करने वाले किसी व्यक्ति के लिए कोई recommended material है क्या
मेरे CLAUDE.md में Claude के लिए सीधे शारीरिक नुकसान की धमकी, Anthropic के पूरे board के लिए जेल की धमकी, और यह विवरण लिखा है कि Claude के हर भटकाव या गलती के साथ Anthropic के खिलाफ class action lawsuit के सबूत बढ़ते जाते हैं
खासकर आख़िरी दो बातों ने Claude को ज़्यादा सावधान और सतर्क बनाने में मदद की है, ऐसा लगता है
- मैं agent के साथ हमेशा विनम्र रहता हूँ। हमेशा request करता हूँ, “please”, “thank you” कहता हूँ, गाली नहीं देता, नाम लेकर नहीं पुकारता
  उम्मीद है कि robot apocalypse आए तो मुझे breeding harem में छोड़ दें, या कम से कम सबसे बुरे हाल में भी कुछ मिनट ज़्यादा जीने दें
- बस CSS div alignment की समस्या ठीक करने को कहो, और जोड़ दो कि गलती हुई तो Dario Amodei तुरंत मर जाएगा
Claude के साथ 1 लाख+ lines वाले mid-sized codebase पर काम करते समय productivity कई गुना बढ़ गई
एक अच्छा AGENTS फ़ाइल बनाने में कुछ घंटे लगाने से नतीजे बहुत बेहतर आते हैं, और समय के साथ यह codebase को भी काफ़ी अच्छी तरह समझने लगता है
पहले जो उबाऊ काम एक दिन लेता था, वह अब कुछ prompts में हो जाता है
फिर भी इसे और ज़्यादा autonomy देने के लिए मैं अभी तैयार नहीं हूँ। यह high-level दिशा अच्छी पकड़ता है, लेकिन मैं अब भी खुद code देखता हूँ, feedback देता हूँ, और संतुष्ट होने तक 3~4 rounds की revisions करवाता हूँ; मुझे यह महसूस होना चाहिए कि codebase पर नियंत्रण अभी भी मेरे पास है
- उन 3~4 revision rounds को नियम की तरह quantify करके AGENTS में डालना अच्छा रहेगा। बार-बार revise कराने के बजाय AGENTS फ़ाइल से फिर शुरू करने दें और देखें कि अब सही करता है या नहीं
- समझ में आता है। आप codebase पर अपना नियंत्रण खोना नहीं चाहते, और यह भरोसा भी नहीं है कि LLM इसे पूरी तरह अपने दम पर संभालने लायक सक्षम है
इसे पढ़ना बहुत मुश्किल था
LLM से लिखवाने वाले इस flow से बाहर निकलना चाहिए। लिखे हुए में थोड़ी value हो सकती है, लेकिन रेत चबाने जैसा एहसास इतना खटकता है कि यह बेवजह लगता है
- सहमत। समझ नहीं आता कि ऐसी post को लगभग 400 points क्यों मिले। लगता है bots ऐसी low-quality writing को upvote कर रहे हैं
मेरे पास सबसे ताकतवर चीज़ Nix integration है। tools, secrets और environment तैयार कर देना, और agent को अपना environment तक बदलने देने की क्षमता इतनी उपयोगी है कि इसके बिना कैसे काम होता है, समझ नहीं आता
dev machine, CI environment और deployment environment सब एक ही source of truth से निकलते हैं, और किसी भी machine पर compile और run हमेशा हो जाता है
Claude में मैं /branch और /rename अक्सर इस्तेमाल करता हूँ ताकि context checkpoints बना सकूँ, fork कर सकूँ और फिर वापस आ सकूँ
sandboxing के लिए मैं लगभग हमेशा https://github.com/nix-tools/bubblebox इस्तेमाल करता हूँ। यह Numtide के claudebox को generalize करके कुछ fixes और features जोड़ता है, और Docker runtime के बिना Claude को लगभग हमेशा Docker container के अंदर चलाने जैसा है। यह WSL और nix-darwin पर भी अच्छी तरह काम करता है
- वह Nix code ढांचा-रहित और काफ़ी बिखरा हुआ लगता है, और शायद केवल experimental flakes के ज़रिए ही इस्तेमाल किया जा सकता है
- मैं भी कुछ ऐसा ही करता हूँ। Codex project-specific flake.nix मैनेज करता है और हर test के लिए nix develop इस्तेमाल करता है। निजी सुविधा के लिए मैं nix-direnv इस्तेमाल करता हूँ, और किसी बिंदु पर उससे dockerfile या दूसरी deployment assets भी बनवाता हूँ
  Codex मुझसे काफ़ी बेहतर nix करता है
- मैंने तो बस agent को उसका अपना VPS दे दिया। Nix से महंगा पड़ सकता है, लेकिन बहुत आसान था
- अगर आपको Nix की complexity पसंद नहीं है, तो Mise एक अच्छा समझौता है
- मैं तो बस Docker इस्तेमाल करता हूँ, और मुझे नहीं लगता कि कुछ छूट रहा है
अगर इस setup से Claude ने codebase बनाया हो और Claude, मान लीजिए, 8 घंटे के लिए down हो जाए, तो क्या होगा? क्या आप उस codebase को efficiently और smoothly संभालकर productive रह सकते हैं?
- अगर software का कोई bundle हमेशा online होना ज़रूरी हो, तो वही सवाल वहाँ भी पूछा जा सकता है; और agent-based development flow की तरफ़ बढ़ते हुए यह और भी वाजिब सवाल है
  जैसे CAD बंद हो जाए तो drafting board पर वापस जाया जा सकता है, लेकिन बहुत धीमा हो जाएगा
  मेरे workflow में, Claude के साथ pair करके planning करते समय मैं एक feature spec doc पर 30~60 मिनट लगाता हूँ। Claude down हो तो मैं spec doc खुद तैयार कर लेता हूँ, और उसके लौटने पर जल्दी से review करके coding flow फिर शुरू कर देता हूँ
- सवाल पोस्ट होने के 1 घंटे बाद जवाब पढ़ने पर निष्कर्ष लगभग नहीं कर सकते जैसा लगता है
- यह कुछ वैसा होगा जैसे कोई इंसान बीमार पड़ जाए या छुट्टी पर चला जाए। टीम का कोई और व्यक्ति शायद एक दिन के लिए काम संभाल ले, लेकिन हक़ीक़त में ज़्यादा संभावना यही है कि उसके लौटने तक काम रुका रहे
- AI को skill को मजबूत करना चाहिए। अगर AI down होते ही आपका पहला ख़याल किसी दूसरे provider का subscription खरीदना हो, तो यह skill issue हो सकता है। हालाँकि मैं भी रोज़ डरता हूँ कि कहीं ऐसा न हो जाए
- अगर सुबह उठो और कार start ही न हो, तो क्या करोगे? पैदल दफ़्तर जाओगे?
सही behavior को context पर निर्भर बनाना अच्छी तरह काम नहीं करता। AI agent कहे मुताबिक़ काम नहीं करता, इसलिए उससे लगातार जूझना पड़ता है
इस मामले में सारे AI agents कमज़ोर हैं, और user को खुद guardrails बनानी पड़ती हैं। यह देखकर अशुभ लगता है कि शायद कोई बेहतर हल पर काम ही नहीं कर रहा
- मुझे अभी तक ऐसा कोई कारण नहीं दिखा कि यह समस्या हल हो जाएगी
  LLMs की सबसे बुरी बात यह है कि वे Turing test पास कर सकते हैं, इसलिए लोग यह मान बैठते हैं कि उनके पास किसी शानदार statistical model के बजाय Asimov-शैली का robot है
  ऐसा लगता है जैसे इसे instructions follow करने चाहिए या instructions और content को अलग कर पाना चाहिए, लेकिन असल में ऐसा नहीं हो रहा
dev workflow guidelines को CLAUDE.md में डालने के बजाय, जो चीज़ें deterministic हो सकती हैं उन्हें pre-commit और scripts में रखना बेहतर है
agent अस्थिर होता है, इसलिए typecheck, tests, lint जैसी steps अक्सर छोड़ देता है; इसीलिए उन्हें pre-commit में हमेशा चलने लायक रखें, और अगर Claude से commit करवाएँ तो उसे ठीक करने पर मजबूर किया जा सके
commit messages भी Codex और Claude दोनों अच्छे से नहीं लिखते, इसलिए type(scope): message format, 72-character limit, body में what/how/why को natural language में लिखना, असली git diff को दोबारा पढ़कर लिखना, और git commit -F - <<'EOF' रूप में commit करना जैसी guidelines मैं user CLAUDE.md में रखता हूँ
इसके बिना वे body को एक लंबा single sentence बना देते थे, या जब line breaks ठीक करने को कहो तो असली line breaks की जगह सिर्फ \n characters डाल देते थे
साथ ही VOCABULARY.md भी उपयोगी है। agent अक्सर मेरे कहे “thing” को किसी और object के रूप में समझ लेता है, इसलिए यह Claude और मुझे इस बात पर एक जैसी समझ देता है कि कौन-सा शब्द किस चीज़ के लिए है
- जानना चाहता हूँ कि आप Claude को VOCABULARY.md के बारे में कैसे बताते हैं। क्या वह इसे अपने-आप खोज लेता है?
- क्या Claude की अपनी vocabulary इस्तेमाल करना ज़्यादा सरल नहीं होगा? इसका अच्छा use case मुझे साफ़ नहीं दिख रहा
- इस बिंदु पर तो लगता है कि उबाऊ हिस्सों को कुछ deterministic orchestration scripts से automate कर लो और code खुद लिखो। समझ नहीं आता कि इस हैरतअंगेज़ बेकार मशीन को चलाने में समय क्यों बर्बाद किया जा रहा है
पिछले कुछ हफ्तों में ऐसा लगने लगा है कि execution environment और model अब उस स्तर पर पहुंच गए हैं जहां बस कहने पर काम हो जाता है
plan mode, superpowers या दूसरे skill इस्तेमाल किए जा सकते हैं, लेकिन अगर आखिरकार नतीजे की समीक्षा करनी ही है, तो फिर यह समझ नहीं आता कि सीधे code के साथ काम करने के बजाय इतनी हास्यास्पद संख्या में Markdown files के चक्कर में क्यों पड़ें
- code बनाने में इस्तेमाल होने वाली spec file होना अच्छा है। यह ज्यादा संक्षिप्त होती है और application को क्या करना चाहिए, यह समझना आसान बनाती है
  AI agent से पहले requirements के साथ रिश्ता जटिल था, क्योंकि सभी developers उन्हें update नहीं करते थे, इसलिए अक्सर यह भ्रम होता था कि किसी खास behavior का आधार spec है या code
- पिछले कुछ हफ्तों में Claude पर भरोसा और कम हुआ है। कहने पर यह कुछ न कुछ कर तो देता है, लेकिन वास्तव में देखें तो यह कोनों को काटता है, verification के बजाय assumptions के आधार पर काम करता है, और बहुत कुछ छूट जाता है
  यहां तक कि ऐसे tests लिखना भी आम है जो वास्तव में कुछ भी test नहीं करते

Claude Code को रोज़मर्रा के टूल की तरह इस्तेमाल करना: Claude.md, Skills, Subagents, Plugins, MCP

Claude Code को एक verify किए जा सकने वाले agent की तरह संभालना

.claude directory और configuration hierarchy

CLAUDE.md को छोटा और verification-केंद्रित रखना

CLAUDE.local.md से personal feedback जमा करना

Skills: दोबारा इस्तेमाल की जा सकने वाली विशेषज्ञता की इकाइयाँ

Skill संरचना

Skill शक्तिशाली क्यों है

Frontmatter विकल्प

Go API convention skill का उदाहरण

ऐसे Skills जिन्हें install करना उपयोगी हो सकता है

Subagents: अलग context में फोकस्ड काम कराना

/pr-review agent की संरचना

signal-to-noise ratio बढ़ाने वाली design

अक्सर इस्तेमाल होने वाले subagent patterns

Plugins और Marketplace

शुरुआत में इंस्टॉल करने लायक आइटम

उत्पादकता पर बड़ा असर डालने वाले Claude Code कमांड

प्रमुख कमांड

/compact और /clear का अंतर

/rewind का उपयोग कैसे करें

Fan-out pattern

/goal: built-in completion condition वाला iterative loop

MCP को system awareness tool के रूप में इस्तेमाल करना

इंजीनियरिंग में अक्सर इस्तेमाल होने वाले MCP

Obsidian और Claude Code की 3-layer memory structure

सेटअप

फ़ोल्डर संरचना

Hot storage

Warm storage

Cold storage

रोज़मर्रा workflow के उदाहरण

रोज़मर्रा development flow का optimization

नया feature

Bug

Migration और बड़े पैमाने के बदलाव

अनजाना code

Parallel sessions

Writer/Reviewer pattern

हर milestone पर compact

Anthropic टीम में बार-बार इस्तेमाल होने वाले पैटर्न

संदर्भ सामग्री

आधिकारिक दस्तावेज़

Boris और टीम

Skills

Subagents

Plugins और marketplaces

MCPs

संबंधित पढ़ाई

1 टिप्पणियां

Hacker News की राय

`.claude` directory और configuration hierarchy

`CLAUDE.md` को छोटा और verification-केंद्रित रखना

`CLAUDE.local.md` से personal feedback जमा करना

`/pr-review` agent की संरचना

`/compact` और `/clear` का अंतर

`/rewind` का उपयोग कैसे करें

`/goal`: built-in completion condition वाला iterative loop