रोज़मर्रा में इस्तेमाल होने वाले Claude Code के 50 टिप्स और best practices

 (x.com/codevolutionweb)
25 पॉइंट द्वारा GN⁺ 2026-03-20 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • जो डेवलपर्स पहले से Claude Code इस्तेमाल कर रहे हैं, उनके लिए 50 व्यावहारिक टिप्स का संग्रह, जिसे Anthropic के आधिकारिक दस्तावेज़ों, डेवलपर Boris Cherny, कम्युनिटी अनुभव, और 1 साल के दैनिक उपयोग के अनुभव के आधार पर संकलित किया गया है
  • cc alias, ! prefix, Esc rewind जैसे session ऑपरेशन शॉर्टकट से लेकर sub-agent, agent team, और worktree parallel work तक सब कुछ शामिल
  • CLAUDE.md लिखने का तरीका, Hooks system, context window management जैसे quality और consistency बनाए रखने वाले संरचित methodology भी शामिल
  • CLI tools का उपयोग, MCP server चुनना, batch processing जैसी विभिन्न workflow patterns प्रस्तुत
  • सभी 50 को एक साथ लागू करने की ज़रूरत नहीं; सबसे असुविधाजनक एक चीज़ से शुरू करने वाली क्रमिक अपनाने की सलाह

1. cc alias सेट करना

  • alias cc='claude --dangerously-skip-permissions' को ~/.zshrc (या ~/.bashrc) में जोड़ने पर सिर्फ cc टाइप करके Claude Code session शुरू किया जा सकता है
  • यह सेटिंग सभी permission prompts को bypass करती है, और flag का नाम जानबूझकर डरावना रखा गया है
  • इसे तभी इस्तेमाल करना चाहिए जब आप पूरी तरह समझते हों कि Claude Code आपके codebase पर क्या कर सकता है

2. ! prefix से bash commands inline चलाना

  • !git status या !npm test टाइप करने पर command तुरंत execute होता है, और command व output context में बने रहते हैं
  • Claude परिणाम देखकर अगला काम कर सकता है — Claude से command चलाने के लिए कहने से यह तेज़ है

3. Esc से रोकें, Esc+Esc से rewind करें

  • Esc Claude को बीच में रोकता है, लेकिन context नहीं खोता — यानी आप तुरंत दिशा बदल सकते हैं
  • Esc+Esc (या /rewind) Claude द्वारा बनाए गए सभी checkpoints का scroll menu खोलता है, जिससे code, conversation, या दोनों restore किए जा सकते हैं
    • restore के 4 विकल्प: code और conversation, सिर्फ conversation, सिर्फ code, checkpoint के बाद का summary
  • 40% confidence वाला approach भी आज़मा सकते हैं — असफल होने पर rewind से zero damage
    • लेकिन checkpoints सिर्फ file edits को track करते हैं; bash commands (migrations, DB operations) से हुए बदलाव capture नहीं होते
  • claude --continue से सबसे हाल की conversation फिर शुरू करें, claude --resume से session selector इस्तेमाल करें

4. Claude को self-verification के साधन दें

  • prompt में test commands, linter checks, expected output शामिल करने से Claude खुद अपनी गलतियाँ पकड़ने वाला feedback loop बना सकता है
    • उदाहरण: "auth middleware को JWT में refactor करो. बदलाव के बाद existing test suite चलाओ, सभी failures ठीक करो, फिर पूरा मानो"
  • Boris Cherny के अनुसार, सिर्फ इससे 2~3 गुना quality improvement हासिल हो सकती है
  • UI changes के मामले में Playwright MCP server सेट करें ताकि Claude browser खोल सके, page के साथ interact कर सके, और verify कर सके कि UI उम्मीद के मुताबिक काम कर रहा है — इससे वे issues भी पकड़े जाते हैं जो unit tests से छूट जाते हैं

5. भाषा-विशिष्ट code intelligence plugins इंस्टॉल करें

  • LSP plugins file edit के बाद automatic diagnostics देते हैं (type errors, unused imports, missing return types आदि) — install किए जा सकने वाले single plugin में सबसे अधिक impact
  • install commands के उदाहरण:
    • /plugin install typescript-lsp@claude-plugins-official
    • /plugin install pyright-lsp@claude-plugins-official
    • /plugin install rust-analyzer-lsp@claude-plugins-official
    • /plugin install gopls-lsp@claude-plugins-official
  • C#, Java, Kotlin, Swift, PHP, Lua, C/C++ plugins भी /plugin के Discover tab में उपलब्ध हैं
  • आपके system में संबंधित language server binary install होनी चाहिए (न होने पर plugin सूचित करेगा)

6. gh CLI का उपयोग और सभी CLI tools सीखना

  • gh CLI से PR, issue, और comments को अलग MCP server के बिना संभाला जा सकता है — CLI tools, MCP servers की तुलना में ज़्यादा context-efficient होते हैं (tool schema को context window में load नहीं करते)
  • यही बात jq, curl जैसे standard CLI tools पर भी लागू होती है
  • Claude जिस tool को नहीं जानता, उसका --help output पढ़कर syntax समझ सकता है और खुद command चला सकता है — उदाहरण: "sentry-cli --help से सीखो, फिर production की सबसे हाल की error ढूँढो"
  • niche internal CLI tools भी काम कर सकते हैं

7. जटिल reasoning के लिए "ultrathink" जोड़ें

  • "ultrathink" keyword effort को high पर सेट करता है और Opus 4.6 में adaptive reasoning सक्रिय करता है
  • architecture decisions, tricky debugging, multi-step reasoning जैसी स्थितियों के लिए उपयुक्त, जहाँ Claude को action लेने से पहले पर्याप्त सोचना चाहिए
  • /effort से इसे default भी किया जा सकता है — simple tasks के लिए effort कम रखकर तेज़ और सस्ता रखें
  • variable names बदलने में thinking tokens खर्च करने की ज़रूरत नहीं — समस्या के हिसाब से effort समायोजित करें

8. skills से on-demand knowledge बढ़ाएँ

  • skills Markdown files होती हैं जो Claude के ज्ञान का विस्तार करती हैं; CLAUDE.md से अलग, ये सिर्फ संबंधित tasks में load होती हैं, जिससे context हल्का रहता है
  • इन्हें .claude/skills/ में बनाया जा सकता है, या plugin-bundled prebuilt skills install किए जा सकते हैं (/plugin में browse करें)
  • API rules, deployment procedures, coding patterns जैसी specialized domain knowledge के लिए उपयुक्त, जिसकी Claude को कभी-कभी ज़रूरत होती है, हमेशा नहीं

9. मोबाइल फ़ोन से Claude Code नियंत्रित करें

  • claude remote-control से session शुरू करें और claude.ai/code या iOS/Android Claude app से connect करें
  • session आपके local machine पर चलता है, और फ़ोन या browser सिर्फ access window होते हैं — message भेजना, tool calls approve करना, progress monitor करना संभव है
  • tip #1 का cc alias इस्तेमाल करने पर अलग approval की ज़रूरत नहीं पड़ती, इसलिए remote control और भी smooth हो जाता है — task शुरू करें, फिर अपनी जगह छोड़ दें और सिर्फ Claude के पूरा होने या किसी अप्रत्याशित स्थिति में ही देखें

10. context window को 1M tokens तक बढ़ाएँ

  • Sonnet 4.6 और Opus 4.6, दोनों 1M token context window को support करते हैं
  • Max, Team, Enterprise plans में Opus अपने आप 1M context में upgrade हो जाता है
  • /model opus[1m] या /model sonnet[1m] से session के दौरान model switch किया जा सकता है
  • अगर बड़े context में quality को लेकर चिंता हो, तो 500k से शुरू करके धीरे-धीरे बढ़ाकर test करें
  • CLAUDE_CODE_AUTO_COMPACT_WINDOW और CLAUDE_AUTOCOMPACT_PCT_OVERRIDE से compaction trigger timing को नियंत्रित किया जा सकता है

11. approach स्पष्ट न हो तो Plan Mode इस्तेमाल करें

  • Plan Mode multi-file changes, unfamiliar code, और architecture decisions के लिए उपयुक्त है — पहले कुछ मिनट लगाने से Claude को 20 मिनट तक गलत समस्या सुलझाने से रोका जा सकता है
  • छोटे और साफ़-साफ़ scoped tasks में इसे छोड़ दें — अगर diff को एक वाक्य में समझाया जा सकता है, तो सीधे execute करें
  • Shift+Tab से Normal, Auto-Accept, और Plan permission modes के बीच switch किया जा सकता है (conversation छोड़े बिना)

12. असंबंधित कामों के बीच /clear चलाएँ

  • साफ़ session में लिखा गया focused prompt, अव्यवस्थित 3 घंटे के session से बेहतर होता है — अलग task हो तो /clear से शुरू करें
  • ऐसा लग सकता है कि आप progress फेंक रहे हैं, लेकिन accumulated context मौजूदा निर्देशों को दबा देता है, जिससे 30 मिनट की productivity loss महसूस होती है
  • /clear और focused start prompt लिखने में लगने वाले 5 सेकंड कहीं ज़्यादा efficient हैं

13. bug को interpret मत करें, raw data paste करें

  • bug को शब्दों में समझाने पर Claude अनुमान लगाता है, fix करता है, फिर दोहराता है — यह धीमी प्रक्रिया बन जाती है
  • error logs, CI output, Slack thread को जस का तस paste करके "fix" कहें; Claude distributed system logs पढ़कर समस्या की जगह trace कर सकता है
  • इंसानी interpretation, Claude के लिए root cause सही पकड़ने में मददगार details खो देती है — यानी यह अनावश्यक abstraction जोड़ती है
  • यह CI पर भी लागू होता है — "Go fix the failing CI tests" कहकर CI output paste करें, या PR URL/number के साथ failing checks ठीक करने को कहें
  • terminal output को सीधे pipe भी किया जा सकता है:
    • cat error.log | claude "explain this error and suggest a fix"
    • npm test 2>&1 | claude "fix the failing tests"

14. /btw से तेज़ side question

  • /btw एक overlay खोलता है जो conversation history में शामिल नहीं होता, जिससे आप जल्दी सवाल पूछ सकते हैं
  • मौजूदा session पर clarification के लिए उपयोग करें: "तुमने यह approach क्यों चुना?" या "दूसरे options के मुकाबले trade-off क्या हैं?"
  • जवाब एक बंद किए जा सकने वाले overlay में दिखता है, जिससे main context हल्का बना रहता है

15. --worktree से isolated parallel branch चलाना

  • claude --worktree feature-auth से isolated working copy और नया branch बनता है — git worktree setup और cleanup Claude अपने-आप संभालता है
  • Claude Code टीम इसे सबसे बड़े productivity unlocks में से एक मानती है
  • 3~5 worktree spin up करके हर एक में अलग Claude session parallel चलाएँ (आम तौर पर 2~3 इस्तेमाल होते हैं)
  • हर worktree के पास अलग session, branch, और file system state होती है
  • local worktree की सीमा machine resources हैं — कई dev server, build, और Claude session CPU के लिए प्रतिस्पर्धा करते हैं
    • Builder.io हर agent को अलग cloud container में रखकर machine load कम करता है

16. Ctrl+S से prompt अस्थायी रूप से save करें

  • अगर आप लंबा prompt लिख रहे हों और पहले जल्दी जवाब चाहिए, तो Ctrl+S से draft को stash करें
  • quick question submit करने के बाद stashed prompt अपने-आप restore हो जाता है

17. Ctrl+B से लंबे task को background में भेजें

  • जब Claude लंबा चलने वाला bash command शुरू करे (test suite, build, migration), तो Ctrl+B से उसे background में भेज दें
  • Claude काम जारी रखता है और आप बातचीत भी कर सकते हैं — process पूरा होने पर result दिखता है

18. live status line जोड़ें

  • status line एक shell script है जो Claude के हर turn के बाद चलती है, और terminal के नीचे current directory, git branch, और context usage को color coding के साथ दिखाती है
  • /statusline command से इसे जल्दी set up किया जा सकता है — यह पूछता है कि क्या दिखाना है और script अपने-आप बना देता है

19. subagent से main context साफ़ रखें

  • अगर आप कहें, "subagent का इस्तेमाल करके पता करो कि payment flow failed transactions को कैसे handle करता है", तो अलग Claude instance अपने independent context window में files पढ़कर analysis करेगा और फिर concise summary देगा
  • गहरी जांच context window का आधा हिस्सा खा सकती है, इसलिए subagent इस cost को main session से अलग रखता है
  • built-in type: Explore (Haiku, तेज़ file search), Plan (read-only analysis)

20. multi-session coordination के लिए agent team

  • यह experimental लेकिन powerful feature है — इसे enable करने के लिए settings या environment variable में CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS जोड़ें
  • निर्देश दें: "इन modules को parallel refactor करने के लिए 3 teammates की agent team बनाओ"
  • team leader teammates में काम बाँटता है, और हर सदस्य के पास independent context window और shared task list होती है; सदस्य आपस में सीधे message भी कर सकते हैं
  • शुरुआत के लिए 3~5 teammates और प्रति teammate 5~6 tasks recommended हैं
  • एक ही file को edit करने वाले task assign करने से overwrite issues हो सकते हैं, इसलिए पहले research और review tasks से शुरू करें, फिर parallel implementation तक बढ़ें

21. compaction में preserve instructions जोड़ें

  • context compaction के समय (auto या /compact) आप क्या preserve रखना है यह बता सकते हैं: /compact focus on the API changes and the list of modified files
  • आप CLAUDE.md में स्थायी instruction भी जोड़ सकते हैं: "compaction के समय **modified files की पूरी list और current test status** preserve करो"

22. /loop से recurring check चलाएँ

  • /loop 5m check if the deploy succeeded and report back से recurring prompt background में schedule किया जा सकता है
  • interval optional है (default 10 मिनट), और s, m, h, d units supported हैं
  • /loop 20m /review-pr 1234 की तरह दूसरे commands भी loop में चल सकते हैं
  • task session-scoped होते हैं और 3 दिन बाद expire हो जाते हैं — भूले हुए loop हमेशा के लिए नहीं चलते
  • deploy monitoring, CI pipeline watching, और external service polling में उपयोगी

23. voice dictation से richer prompt लिखें

  • /voice से push-to-talk चालू करें, Space key दबाकर बोलें, और speech real time में transcribe होकर prompt में जुड़ जाती है
  • एक ही message में voice और typing को साथ में मिला सकते हैं
  • voice prompt, typing की तुलना में स्वाभाविक रूप से ज़्यादा context शामिल करते हैं — background, constraints, और desired outcome बिना extra typing के समझा सकते हैं
  • Claude.ai account चाहिए (API key नहीं)
  • ~/.claude/keybindings.json में push-to-talk key को meta+k जैसी key पर rebind करके hold-detection warm-up skip किया जा सकता है

24. एक ही समस्या पर 2 बार fix के बाद भी हल न हो, तो fresh शुरू करें

  • अगर आप fixes के rabbit hole में फँस गए हैं और issue फिर भी हल नहीं हुआ, तो context failed approaches से भर जाता है और अगली कोशिश पर बुरा असर डालता है
  • /clear के बाद सीखी हुई बातों को शामिल करते हुए बेहतर starting prompt के साथ फिर शुरू करें
  • साफ़ session में sharp prompt, जमा हुए dead end वाले लंबे session से लगभग हमेशा बेहतर होता है

25. Claude को ठीक-ठीक बताएँ कि कौन-सी file देखनी है

  • @src/auth/middleware.ts has the session handling की तरह @ prefix से file को सीधे refer करें
  • @ prefix अपने-आप file path के रूप में resolve हो जाता है, इसलिए Claude तुरंत सही location समझ लेता है
  • Claude खुद grep/search भी कर सकता है, लेकिन candidates को narrow down करने और सही file पहचानने की प्रक्रिया में tokens और context खर्च होते हैं — शुरुआत में ही file दे देने से पूरा step बच जाता है

26. unfamiliar code explore करने के लिए vague prompt इस्तेमाल करें

  • "तुम इस file में क्या improve करोगे?" एक बेहतरीन exploration prompt है — हर prompt का specific होना ज़रूरी नहीं
  • जब existing code पर नया नज़रिया चाहिए, तो vague question Claude को unexpected चीज़ें खोजने की गुंजाइश देता है
  • unfamiliar repo में onboarding के समय उपयोगी — Claude patterns, inconsistencies, और improvement opportunities बता सकता है जो पहली reading में छूट जाएँ

27. Ctrl+G से plan edit करें

  • Claude जब कोई plan दे, तो Ctrl+G से उसे text editor में सीधे खोलकर edit किया जा सकता है
  • Claude के code लिखना शुरू करने से पहले ही constraints जोड़ें, steps हटाएँ, या approach बदलें
  • जब plan ज्यादातर सही हो लेकिन सिर्फ कुछ steps बदलने हों, तब सब कुछ दोबारा समझाने की ज़रूरत नहीं पड़ती

28. /init चलाने के बाद output को आधा कर दें

  • CLAUDE.md project root में मौजूद Markdown file है, जो Claude को build commands, coding standards, architecture decisions, और repo conventions जैसी permanent instructions देती है
  • Claude इसे हर session की शुरुआत में पढ़ता है
  • /init project structure के आधार पर draft version generate करता है — build commands, test scripts, और directory layout अपने-आप पहचान लेता है
  • output अक्सर फूला हुआ होता है — जिन lines का कारण आप समझा नहीं सकते, उन्हें हटाएँ, और जो छूटा हो उसे जोड़ें

29. CLAUDE.md की हर line के लिए litmus test

  • CLAUDE.md की हर line पर पूछें: "**अगर यह line न हो तो क्या Claude गलती करेगा?**"
  • जो instructions Claude पहले से सही तरह follow करता है, वे noise हैं — बेकार lines, महत्वपूर्ण lines को dilute कर देती हैं
  • compliance गिरने से पहले लगभग 150~200 instructions की limit है, जिसमें system prompt पहले से लगभग 50 इस्तेमाल करता है

30. Claude की गलती के बाद कहें: "CLAUDE.md को update करो ताकि यह गलती दोबारा न हो"

  • Claude से गलती हो जाए, तो कहें: "update the CLAUDE.md file so this doesn't happen again"
  • Claude अपना rule खुद लिख देगा, और अगले session से उसे अपने-आप follow करेगा
  • समय के साथ CLAUDE.md वास्तविक गलतियों से बना एक living document बन जाता है
  • अनंत growth रोकने के लिए @imports (tip #32) से अलग files (@docs/solutions.md आदि) refer करें — CLAUDE.md को हल्का रखें और Claude को ज़रूरत पड़ने पर detail पढ़ने दें

31. .claude/rules/ से conditional rules लागू करें

  • .claude/rules/ में Markdown फ़ाइलें रखें ताकि विषय-वार निर्देश व्यवस्थित रह सकें — डिफ़ॉल्ट रूप से सभी rule फ़ाइलें session शुरू होते ही load हो जाती हैं
  • paths frontmatter से सिर्फ़ खास file pattern पर load होने वाली conditional activation संभव है:
    • उदाहरण: paths: ["**/*.ts"] सेट करने पर Claude TypeScript rules सिर्फ़ तब load करेगा जब वह .ts फ़ाइलें पढ़ेगा
  • मुख्य CLAUDE.md को हल्का रखें — Claude उन भाषाओं के rules नहीं पढ़ेगा जिन पर वह अभी काम नहीं कर रहा

32. @imports से CLAUDE.md को हल्का रखें

  • @docs/git-instructions.md की तरह documents refer करें — @README.md, @package.json, @~/.claude/my-project-instructions.md भी संभव है
  • Claude ज़रूरत पड़ने पर ही फ़ाइल पढ़ता है — इससे हर session में load होने वाले CLAUDE.md को भारी बनाने के बजाय "ज़रूरत पड़ने पर extra context" दिया जा सकता है

33. /permissions से सुरक्षित commands की allowlist सेट करें

  • npm run lint के लिए सैकड़ोंवीं बार approval click करना बंद करें — /permissions से trusted commands को allowlist में जोड़ें
  • list में न होने वाले commands पर फिर भी prompt दिखेगा

34. /sandbox से Claude को आज़ादी के साथ काम करने दें

  • /sandbox से OS-level isolation सक्षम करें — write access project directory तक सीमित रहती है, और network requests सिर्फ़ approved domains तक ही allowed होती हैं
  • macOS पर Seatbelt, Linux पर bubblewrap इस्तेमाल होता है, और Claude द्वारा बनाए गए सभी subprocesses पर ये restrictions लागू होती हैं
  • auto-allow mode में sandbox के अंदर के commands permission prompt के बिना चल जाते हैं — यानी guardrails के साथ लगभग-पूर्ण autonomy
  • unattended work (overnight migration, experimental refactoring) के लिए Claude को Docker container के अंदर चलाने से पूरी isolation और आसान rollback मिलता है

35. दोहराए जाने वाले कामों के लिए custom subagent बनाएँ

  • tip #19 के ad-hoc subagent से अलग, custom subagent .claude/agents/ में पहले से configure करके save किए जाते हैं
    • उदाहरण: Opus + read-only tools वाला security reviewer agent, या Haiku का तेज़ search agent
  • /agents से browse और create करें
  • isolation: worktree से independent file system वाला agent भी सेट किया जा सकता है

36. अपनी stack के मुताबिक MCP server चुनें

  • शुरू करने के लिए अच्छे MCP servers: Playwright (browser testing और UI verification), PostgreSQL/MySQL (सीधे schema query), Slack (bug reports और thread context), Figma (design→code workflow)
  • Claude Code dynamic tool loading support करता है — Claude server definitions को तभी load करता है जब ज़रूरत हो

37. output style सेट करें

  • /config में अपनी पसंद की style चुनें — built-in options: Explanatory (विस्तृत, step-by-step), Concise (संक्षिप्त, action-focused), Technical (सटीक, terminology-friendly)
  • ~/.claude/output-styles/ में custom output style फ़ाइलें बनाना भी संभव है

38. CLAUDE.md सुझाव है, Hooks अनिवार्य हैं

  • CLAUDE.md advisory है — Claude लगभग 80% तक इसका पालन करता है
  • Hooks deterministic हैं — 100% execute होते हैं
  • जो चीज़ें बिना किसी exception के हर बार चलनी ही चाहिए (formatting, linting, security checks), उन्हें Hook के रूप में सेट करें
  • अगर वह सिर्फ़ ऐसी guideline है जिसे Claude को ध्यान में रखना चाहिए, तो CLAUDE.md काफ़ी है

39. PostToolUse Hook से auto-formatting

  • जब भी Claude फ़ाइल edit करे, formatter अपने-आप चले इसके लिए .claude/settings.json में PostToolUse Hook जोड़ें
    • Edit|Write matcher पर npx prettier --write "$CLAUDE_FILE_PATH" 2>/dev/null || true register करें
  • || true से यह सुनिश्चित करें कि Hook fail होने पर Claude block न हो
  • npx eslint --fix को दूसरी Hook entry के रूप में chain भी किया जा सकता है
  • अगर editor में वही फ़ाइल खुली है, तो format-on-save बंद करना बेहतर है — रिपोर्ट है कि editor save से prompt cache invalidate हो सकती है, जबकि Hook formatting संभाल लेगा

40. PreToolUse Hook से destructive commands ब्लॉक करें

  • rm -rf, drop table, truncate जैसे patterns को PreToolUse Hook से block करें — Claude इन्हें try भी नहीं करेगा
  • Hook, Claude द्वारा tool run करने से पहले trigger होता है, इसलिए destructive commands पहले ही रुक जाती हैं
  • इसे .claude/settings.json में जोड़ें, /hooks से interactive तरीके से configure करें, या Claude से कहें: "rm -rf, drop table, truncate commands को block करने वाला PreToolUse Hook जोड़ो"

41. Hook से compaction के समय अहम context बचाकर रखें

  • लंबे sessions में context compaction के दौरान Claude चल रहे काम का context खो सकता है
  • compact matcher वाला Notification Hook, हर बार compaction trigger होने पर key context को अपने-आप फिर inject कर देता है
  • Claude से कहें: "compaction के बाद current task, modified files और constraints याद दिलाने वाला Notification Hook सेट करो"
  • re-inject करने के लिए अच्छे items: current task description, modified files की list, hard constraints ("migration files को मत बदलो")
  • यह multi-hour sessions में सबसे ज़्यादा उपयोगी है, जहाँ Claude किसी feature में गहराई तक डूबा हो और context खोना नहीं चाहिए

42. auth, payments, और data mutation हमेशा manually review करें

  • auth flows, payment logic, data mutations, destructive DB operations — बाकी code कितना भी अच्छा लगे, इनकी इंसान द्वारा review ज़रूर करें
  • गलत auth scope, misconfigured payment webhook, या silently column delete करने वाला migration users, पैसा और भरोसा — सबका नुकसान कर सकता है
  • कोई भी automation testing इन सभी समस्याओं को पूरी तरह नहीं पकड़ सकती

43. /branch से मौजूदा रास्ता खोए बिना दूसरा approach आज़माएँ

  • /branch (या /fork) से मौजूदा point से conversation की copy बनाएँ
  • risky refactoring को branch में आज़माएँ — सफल हो तो रखें, विफल हो तो original conversation सुरक्षित रहती है
  • यह rewind (tip #3) से अलग है: दोनों रास्ते साथ में बचे रहते हैं

44. जब feature spec अधूरी हो, तो Claude से interview करवाएँ

  • अगर आपको पता है कि क्या बनाना है, लेकिन Claude के अच्छे implementation के लिए सभी details अभी नहीं हैं, तो Claude से सवाल पूछने को कहें
    • "मैं [संक्षिप्त विवरण] बनाना चाहता/चाहती हूँ। AskUserQuestion tool का इस्तेमाल करके मेरा विस्तार से interview करो। technical implementation, edge cases, concerns, और trade-offs पर सवाल पूछो। obvious सवाल मत पूछो। जब तक सब cover न हो जाए interview करो, फिर SPEC.md में complete spec लिखो"
  • spec पूरी होने के बाद नई session में clean context और complete spec के साथ implementation शुरू करें

45. एक Claude लिखे, दूसरा Claude review करे

  • पहला Claude feature implement करे, और दूसरा Claude fresh context में staff engineer की तरह review करे
  • reviewer को implementation shortcuts की पहले से जानकारी नहीं होगी, इसलिए वह हर हिस्से को चुनौती देगा
  • यही idea TDD पर भी लागू करें: session A tests लिखे, session B passing code लिखे

46. PR review को interactive conversation की तरह चलाएँ

  • one-shot PR review माँगने के बजाय (हालाँकि वह भी संभव है), PR को session में खोलकर बातचीत के रूप में review करें
    • "इस PR में सबसे risky change कौन-सा है?"
    • "अगर यह concurrent execution में चले तो क्या टूट सकता है?"
    • "क्या error handling codebase के बाकी हिस्सों के साथ consistent है?"
  • interactive review ज़्यादा issues पकड़ती है — क्योंकि आप महत्वपूर्ण areas में गहराई से जा सकते हैं
  • one-shot review अक्सर style nits को flag करती है और architecture-level problems miss कर सकती है

47. session को नाम और रंग दें

  • /rename auth-refactor से prompt bar में label दिखाएँ
  • /color red या /color blue से prompt bar का रंग सेट करें
    • उपलब्ध रंग: red, blue, green, yellow, purple, orange, pink, cyan
  • 2–3 parallel sessions चलाते समय, नाम और रंग देने में लगे 5 सेकंड गलत terminal में input करने की गलती रोक सकते हैं

48. Claude के पूरा होने पर साउंड चलाएँ

  • Stop Hook के साथ Claude का जवाब पूरा होते ही सिस्टम साउंड चलाएँ
  • टास्क शुरू करें, फिर किसी दूसरे काम पर स्विच हो जाएँ, और पूरा होने पर पिंग साउंड से नोटिफिकेशन पाएँ
  • उदाहरण: .claude/settings.json में Stop Hook के रूप में /usr/bin/afplay /System/Library/Sounds/Glass.aiff रजिस्टर करें

49. claude -p से बैच जॉब fan-out

  • non-interactive mode में फ़ाइल सूची को लूप में प्रोसेस करें — --allowedTools के साथ हर फ़ाइल पर Claude क्या कर सकता है, इसकी सीमा तय करें
  • & से parallel execution चलाकर अधिकतम throughput हासिल करें:
    • for file in $(cat files-to-migrate.txt); do claude -p "Migrate $file from class components to hooks" --allowedTools "Edit,Bash(git commit *)" & done; wait
  • फ़ाइल फ़ॉर्मैट कन्वर्ज़न, पूरे codebase में import अपडेट, और हर फ़ाइल के स्वतंत्र repetitive migration जैसे कामों के लिए उपयुक्त

50. spinner verbs को कस्टमाइज़ करना (मज़ेदार हिस्सा)

  • जब Claude सोच रहा हो, तब टर्मिनल में "Flibbertigibbeting...", "Flummoxing..." जैसे spinner verbs दिखते हैं
  • इन्हें अपनी पसंद के वाक्यांशों से बदला जा सकता है — Claude को निर्देश दें:
    • "Replace my spinner verbs in user settings with these: Hallucinating responsibly, Pretending to think, Confidently guessing, Blaming the context window"
  • सूची खुद देने की भी ज़रूरत नहीं — "Replace my spinner verbs with Harry Potter spells" की तरह सिर्फ मूड बता दें, Claude खुद सूची बना देगा
  • इंतज़ार के समय को थोड़ा और मज़ेदार बनाने वाला छोटा-सा कस्टमाइज़ेशन

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.