Claude Code की कमांड याद कर लीं पर हाथ रुक जाता है? सुरक्षित पहला कदम उठाने का तरीका

शुक्रवार की रात मेरे एक जूनियर का Slack पर मैसेज आया: “भैया, Claude Code की सारी कमांड याद कर लीं, पर अब आगे क्या टाइप करूँ — यही समझ नहीं आ रहा, हाथ ही रुक गया है।” उसे /init भी आता है, /clear भी, claude -p भी। पर जैसे ही अपनी repo सामने आती है, उँगलियाँ जम जाती हैं।

यह काबिलियत की कमी नहीं है। कमांड चीटशीट तो बस “औज़ारों के नाम” की लिस्ट है — उसमें यह कहीं नहीं लिखा होता कि “सबसे पहले किस काम को, कितनी हद तक, कैसे जाँच कर AI को सौंपें”। इसीलिए कुछ लोग जितना ज़्यादा याद करते हैं, उतना ही ज़्यादा अटक जाते हैं।

यह लेख उसी “याद तो कर लिया पर हाथ रुक गया” वाली जगह से निकलने के बारे में है — सबसे छोटा पहला कदम कैसे उठाएँ।

मुख्य बातें

• कमांड याद करने के बाद भी हाथ इसलिए रुकता है क्योंकि चार चीज़ें तय नहीं होतीं: किस हद तक इजाज़त, किन files को न छूना, वापस कैसे लौटना, और जाँच कैसे करना।
• पहला नतीजा बहुत छोटा हो तो भी ठीक है — “बस एक paragraph सुधारना” या “failing test का सिर्फ़ मतलब समझाना”।
• सौंपने से पहले edit करवाने के बजाय “सिर्फ़ plan लौटाओ” कहने से हादसे बहुत कम हो जाते हैं।
• जाँच इंसानी नज़र से नहीं — पहले से git diff जैसी मशीनी कमांड तय कर लें जो साफ़ बता दे।
• आदत पड़ने पर सिर्फ़ उन्हीं operations को धीरे-धीरे automatic करें जो आज़माकर सुरक्षित निकले।

चीटशीट रटने पर भी हाथ क्यों जम जाता है

कमांड लिस्ट नक़्शे में “ट्रैफ़िक साइन की सूची” जैसी है। आप सारे साइन के नाम बोल सकते हैं, पर जब तक मंज़िल और कहाँ मुड़ना है यह तय न हो, गाड़ी आगे नहीं बढ़ती।

रुकने वाले लोगों में ज्ञान की कमी नहीं होती — इन चार बातों को शब्दों में उतारने की आदत की कमी होती है।

• किन files को पढ़ने दें और कहाँ हाथ न लगाने दें।
• पहले बदलाव को कितना छोटा काटें।
• “कामयाब हुआ” कहने की शर्त क्या है (क्या देखकर पता चले कि सफल रहा)।
• गड़बड़ होने पर वापस पुरानी हालत में कैसे लौटें।

मैं भी शुरू में “इस पूरे project को अच्छा कर दो” बोलकर सब छोड़ देता था, और 30 files बदल देने वाला diff सामने देख कर जम जाता था। जो diff पढ़ा न जा सके, उसे जाँचा नहीं जा सकता। और जो बदलाव जाँचा न जाए, उसे डर के मारे अपनाया नहीं जा सकता। इसीलिए शुरुआत हँसी आने की हद तक छोटी रखना ही सही जवाब है।

पहला कदम इतना छोटा हो तो भी काफ़ी है

“नतीजा” सुनते ही मन में बड़ा feature जुड़ने का ख़्याल आता है, पर शुरुआत में इतना ही काफ़ी है।

• README की intro लाइनों में से सिर्फ़ 3 लाइनें पढ़ने लायक साफ़ करना।
• लेख के नीचे वाले guide text में सिर्फ़ एक वाक्य जोड़ना।
• फ़ेल हो रहे test का मतलब “बिना ठीक किए” समझाना।

तीसरा सबसे ज़्यादा सुझाने लायक है। इसमें कोड की एक भी line नहीं बदलती, इसलिए कुछ टूट ही नहीं सकता। फिर भी “Claude Code को अपनी repo पढ़ाई और जवाब आया” वाला पहला एहसास पूरी तरह मिल जाता है। जो लोग अटके हुए हैं, वे सबसे पहले यहीं से उँगलियाँ चलाएँ।

AI को क्या सौंपें, इंसान क्या तय करे

Claude Code को कौन-सा काम सौंपना है और कौन-सा फ़ैसला इंसान अपने पास रखेगा — यह शुरू से साफ़ बाँट लें। धुँधला छोड़कर चलाने पर अक्सर AI वहाँ तक खुद आगे बढ़ जाता है जहाँ इंसान को फ़ैसला लेना चाहिए था।

स्थिति	Claude Code को सौंपें	इंसान तय करे
दायरा तय करना	संभावित files ढूँढकर सुझाव देना	छूने लायक दायरे का आख़िरी फ़ैसला
Edit	लेख/कोड का draft	अपनाना है या नहीं
जाँच	test चलाना, diff का सार बताना	publish करना ठीक है या नहीं
ख़तरनाक काम	सिर्फ़ “कैसे करें” का सुझाव	delete, production में लागू, billing चलाना

असली बात दाएँ कॉलम में है। Delete, production में लागू करना, पैसे से जुड़ा operation, और git push --force जैसे मुश्किल से वापस होने वाले काम — शुरुआत में ये सब “इंसान दबाएगा” पर पक्के रखें। जिसे आप खुद आज़माकर सुरक्षित मान लें, बस उसी को बाद में बाएँ कॉलम में ले जाएँ। यही क्रम बनाए रखने से आधी रात को पसीना छूटने वाले मौके बहुत घट जाते हैं।

पहले “सिर्फ़ plan” लौटाने को कहें

सीधे edit मत करवाइए — यही असली ट्रिक है। पहली request में हाथ चलाने मत दीजिए, सिर्फ़ plan बुलवाइए। नीचे वाला prompt जस का तस चिपकाकर इस्तेमाल कर सकते हैं।

अब मैं सिर्फ़ एक छोटा बदलाव करवाना चाहता हूँ। अभी edit मत करना।
पहले नीचे की चार बातें bullet में लौटाओ:

1. कौन-सी file छूनी है (सिर्फ़ एक)
2. कौन-सी files नहीं छूनी (.env और auth/billing वाली चीज़ें बिल्कुल नहीं)
3. क्या बदलना है (behavior मत बदलना, सिर्फ़ टेक्स्ट सुधारना)
4. बदलाव के बाद मैं किस command से जाँचूँगा (जैसे git diff)

इन चार बातों पर मेरी OK मिलने के बाद ही edit शुरू करना।

जवाब में आए चार बिंदु देखिए — अगर छूने वाली file एक पर सिमटी है और जाँच की command तक लिखी है, तो request की बारीकी सही है। उल्टा अगर “पूरी repository की समीक्षा करता हूँ” जैसा जवाब आए, तो समझिए माँग अब भी बहुत चौड़ी है। दायरा संकरा करके उसी ढाँचे में दोबारा request कीजिए।

अगर request लिखने में अटकाव महसूस हो, तो Claude Code prompt design और CLAUDE.md लिखने का तरीका इसकी नींव बनते हैं। project के नियम पहले से सौंप देने पर plan की गुणवत्ता एक स्तर ऊपर उठ जाती है।

कॉपी-पेस्ट से चलने वाली “पहला कदम” चेकलिस्ट

दिमाग़ की चारों बातें हर बार file में लिखना झंझट है। इसलिए एक छोटी script रख देता हूँ जो सिर्फ़ जवाब भरने पर “पहला कदम नोट” बना देती है। Node.js हो तो चल जाएगी।

// first-win.mjs — पहला कदम 1 मिनट में शब्दों में उतारने वाला नोट
// इस्तेमाल: node first-win.mjs

const plan = {
  goal: "Claude Code से एक छोटा बदलाव, सुरक्षित ढंग से पास करना",
  touchFile: ["README.md"],                 // सिर्फ़ एक पर सीमित रखें
  doNotTouch: [".env", "auth", "billing", "production DB"],
  firstCommand: "git status --short",       // अभी की हालत जाँचें
  change: "intro की 3 लाइनें साफ़ करना। behavior मत बदलना",
  verify: "git diff -- README.md",          // diff पढ़ने लायक है या नहीं
  rollback: "git checkout -- README.md",    // बिगड़े तो तुरंत वापस
};

// जाँच: छूने वाली file एक पर सिमटी है या नहीं
if (plan.touchFile.length !== 1) {
  console.error("⚠ शुरू में छूने वाली file सिर्फ़ एक रखें");
  process.exit(1);
}

console.log("=== पहला कदम नोट ===");
for (const [key, value] of Object.entries(plan)) {
  const text = Array.isArray(value) ? value.join(", ") : value;
  console.log(`${key}: ${text}`);
}
console.log("\nयह नोट Claude Code में चिपकाकर कहें: 'edit से पहले plan लौटाओ'");

चलाना बस इतना है।

node first-win.mjs

जो नोट निकले उसे जस का तस Claude Code में चिपकाइए और ऊपर वाले “सिर्फ़ plan लौटाओ” prompt के साथ मिलाकर इस्तेमाल कीजिए। छूने वाली files दो या ज़्यादा होते ही script पहली ही line पर रुक जाती है, इसलिए लालच में आ जाने पर यह ब्रेक का काम भी करती है।

सचमुच काम आए तीन इस्तेमाल

मैंने और मेरे आसपास के लोगों ने “पहला कदम” के लिए जो चुना और जिससे सचमुच आगे बढ़े, वे तीन उदाहरण।

1. README की intro सुधारना. कमांड ढूँढने आए पाठक के लिए सिर्फ़ पहली 3 लाइनें आसान कीजिए। जाँच बस git diff से हो जाती है, इसलिए “diff पढ़ पा रहा हूँ” वाला एहसास सबसे जल्दी मिलता है। यहीं आत्मविश्वास बनता है।

2. लेख के नीचे एक वाक्य जोड़ना. जहाँ guidance पतली है वहाँ सिर्फ़ एक वाक्य जोड़िए और public URL पर खोलकर देखिए कि link ज़िंदा है या नहीं। सिर्फ़ टेक्स्ट का बदलाव होने से कोड टूटने का डर नहीं।

3. फ़ेल हो रहे test का मतलब समझवाना. यहाँ ठीक मत करवाइए। बस तीन चीज़ें लौटवाइए — “error का मतलब”, “जो files शामिल हो सकती हैं”, और “अगली बार इंसान कहाँ देखे”। कोड की एक भी line छुए बिना वजह का अंदाज़ा लगाने की प्रैक्टिस हो जाती है।

तीनों में एक बात समान है: जाँच एक ही command में पूरी, और गड़बड़ होने पर एक सेकंड में वापसी। नॉन-इंजीनियर साथी नॉन-इंजीनियरों के लिए Claude Code भी साथ में पढ़ लें, तो टेक्स्ट से जुड़ा पहला कदम चुनना आसान हो जाता है।

आम पड़ने वाले गड्ढे और उनका इलाज

गड्ढा 1: चीटशीट देखते ही “इस repository को अच्छा कर दो” कह देना. दायरा इतना चौड़ा हो जाता है कि लौटा हुआ diff पढ़ा ही नहीं जाता। इलाज सीधा है — “1 file, 1 paragraph” तक सीमित कीजिए। जितना संकरा, पहला नतीजा उतना पक्का।

गड्ढा 2: जाँच का तरीका बाद के लिए टालना. क्या देखकर सफलता मानी जाए, यह तय किए बिना चलाने पर अच्छा-सा नतीजा आ भी जाए तो भी पता नहीं चलता कि अपनाना ठीक है या नहीं। request में शुरू से ही git diff जैसी जाँच-command लिख दीजिए।

गड्ढा 3: सीधे ख़तरनाक काम सौंप देना. file delete या production में लागू करना शुरू से ही automatic कर देने से न लौटने वाला हादसा हो सकता है। शुरुआत में सब “इंसान दबाएगा” पर पक्का रखिए, और जिसे आज़माकर सुरक्षित पाएँ बस उसी को automatic कीजिए।

अक्सर पूछे जाने वाले सवाल

Q. शुरू करने से पहले कितनी कमांड याद करनी चाहिए? A. तीन काफ़ी हैं। /init, /clear, और बदलाव जाँचने वाली git diff। बाक़ी का इस्तेमाल जब आएगा तब ढूँढ लेंगे, देर नहीं होगी। याद करने से पहले छोटा चलाकर देखना उल्टा जल्दी पक्का होता है।

Q. पहले कदम के लिए सबसे उपयुक्त काम कौन-सा है? A. फ़ेल हो रहे test का “सिर्फ़ मतलब” समझवाना। कोड नहीं बदलता इसलिए टूटने का सवाल ही नहीं, और repo पढ़ाने का एहसास भी मिल जाता है। बुनियादी क्रम शुरुआती गाइड में भी समेटा है।

Q. plan माँगा फिर भी सीधे edit शुरू कर देता है। A. prompt की शुरुआत में “अभी edit मत करना” रखिए और आख़िर में “मेरी OK का इंतज़ार करना” जोड़िए। फिर भी आगे बढ़े, तो अक्सर बदलाव का दायरा धुँधला होता है — इसलिए छूने वाली file का नाम लेकर एक तक सीमित कर दीजिए।

Q. जाँच तो इंसानी नज़र से ही काफ़ी है ना? A. व्यस्त दिन में यह ज़रूर टूटती है। character count, diff, test pass/fail — ऐसी मशीनी जाँच पहले तय कर लेने से चूक घटती है। इंसान का फ़ैसला “अपनाना है या नहीं” पर केंद्रित रखना ही ट्रिक है।

Q. आदत पड़ने के बाद आगे क्या करूँ? A. वही “पहला कदम नोट” थोड़े बड़े काम तक फैलाइए। जाँच-command भले बढ़ें, पर “ख़तरनाक काम इंसान दबाए” वाला नियम मत बदलिए। काम तेज़ करने के तरीक़े productivity tips में मिलेंगे।

मैंने ख़ुद आज़माकर क्या पाया

शुरुआत में बताए उसी जूनियर से मैंने पहले “फ़ेल हो रहे test का सिर्फ़ मतलब समझवाना” वाला कदम करवाया। कोड को हाथ नहीं लगाया। जवाब में आया — वजह वाली file का नाम, और अगली बार देखने लायक function की जगह। उसने कहा “इतना तो मैं कर लूँगा”, और उसी दिन README की 3 लाइनें सुधारने तक पहुँच गया।

मैंने ख़ुद भी सब छोड़ देना बंद करके बीच में “सिर्फ़ plan लौटाओ” डालना शुरू किया, तब से न पढ़े जाने वाले diff के सामने जमे रहने का वक़्त लगभग ख़त्म हो गया। git diff से जाँचने लायक दायरे से बाहर कुछ नहीं सौंपता, और ख़तरनाक काम इंसान दबाता है। बस इन दो बातों से पहला कदम हैरान कर देने वाली आसानी से निकल आता है। सारी कमांड याद करने की ज़रूरत नहीं — छोटा चलाइए, और वापस लौटने लायक दायरा जाँच लीजिए। यहीं से शुरू करना काफ़ी है।

सीखना एक स्तर आगे बढ़ाना हो तो उत्पाद/शिक्षण सामग्री देखिए, और कंपनी के काम में इसे कैसे उतारें — इस पर बात करनी हो तो training/consultation देखिए। कमांड के असल व्यवहार के लिए आधिकारिक डॉक्यूमेंटेशन सबसे पक्का प्राथमिक स्रोत है।