Claude Code शुरुआती: रोज 15 मिनट की सुरक्षित सुबह की routine

शुक्रवार की रात मैंने Claude Code से कहा, “इस project में जो भी ठीक करने लायक है, सब ठीक कर दो,” और सो गया।

अगली सुबह 23 files बदली हुई थीं। कुछ code चल भी रहा था। पर सच में क्या ठीक हुआ, क्या जांचना चाहिए — मैं खुद किसी को समझा नहीं सकता था। ऊपर से नीचे तक diff पढ़ने में एक घंटा लगा, और आखिर में डर के मारे एक भी line commit नहीं कर पाया।

एक होशियार AI को इतना बड़ा काम सौंपा, फिर भी आगे बढ़ने के बजाय पीछे चला गया। यही वह पहला गड्ढा है जिसमें लगभग हर शुरुआती गिरता है।

वजह Claude Code की क्षमता नहीं थी। वजह बस इतनी थी कि मैंने काम को “बंद करने” का तरीका तय नहीं किया था। आज मैं वही 15 मिनट की routine आपको दे रहा हूं, जो मैं हर सुबह coffee बनते-बनते कर लेता हूं।

मुख्य बातें

• “सब ठीक कर दो” हादसे की जड़ है। रोज सिर्फ “एक वाक्य में तय किया हुआ एक छोटा काम” ही करें।
• संपादन शुरू करने से पहले यह तय करें कि काम पूरा हुआ या नहीं, इसे जांचने वाला verification command कौन-सा होगा।
• काम के बाद बस तीन चीजें छोड़ें — “कौन-सी files बदलीं”, “verification command का नतीजा”, और “अगला एक कदम”।
• AI को सौंपें वह हिस्सा जहां हाथ चलाने का काम है। दायरा तय करना और publish का बटन दबाना इंसान का काम है।
• नीचे दिया script copy-paste करके आप हर सुबह की जांच अपने-आप एक क्रम में चला सकते हैं।

“छोटा करके बंद करना” शुरुआती के लिए क्यों काम करता है

जब मैंने Claude Code छूना शुरू किया था, तब हर बार मेरा goal धुंधला रहता था। “अच्छा कर दो”, “पढ़ने लायक बना दो”। ऐसे निर्देश से AI ने क्या-कहां तक किया, यह काम खत्म होने के बाद भी पता नहीं चलता।

इंसानी नए साथी के साथ भी यही होता है। जिसे कहा जाए “यह document देख लेना, ठीक-ठाक कर देना”, वह उलझ जाता है। पर जिसे कहा जाए “page 3 के आंकड़े नए version से बदल दो और देख लो कि table बिगड़ा तो नहीं”, वह तुरंत काम पर लग जाता है और खुद भी तय कर लेता है कि काम पूरा हुआ या नहीं।

रोज की routine में अहम यह नहीं है कि आप एक ही बार में एक होशियार निर्देश लिख दें। अहम यह है कि काम को छोटे टुकड़ों में बांटें और उसे “अंत जांचने लायक” रूप दें। यह आ जाए तो शुरुआती भी हर रोज कह सकता है, “आज यहां तक प्रगति हुई।”

वैसे, इस सोच की बुनियाद मेरे दूसरे लेखों — Claude Code शुरू कैसे करें और अनुमति प्रबंधन की मूल बातें — से जुड़ी है। पहले वहां environment तैयार कर लें, फिर इस आदत को ऊपर रखें, तो यह बेहतर असर करती है।

15 मिनट में करने को बस 4 कदम हैं

मैं हर सुबह सिर्फ ये चार चीजें करता हूं। क्रम भी हर बार एक जैसा रखता हूं। क्रम fix कर दें तो बिना सोचे शरीर अपने-आप चलने लगता है।

1. आज का सबसे छोटा काम एक वाक्य में लिखें। जैसे “README का परिचय सिर्फ 3 lines फिर से लिखूंगा” — ऐसा कि अंत साफ दिखे। बड़ा काम जानबूझकर आज नहीं करता।
2. verification command पहले तय करें। “npm run build पास हो जाए तो OK”, “एक test हरा हो जाए तो OK” — संपादन शुरू करने से पहले goal का आकार तय कर लें।
3. काम करके diff, build, public URL के क्रम में जांचें। सीधे publish न करें; जो मशीन से पता चलता है, वहीं से शुरू करें।
4. अगली बार के लिए सिर्फ एक line छोड़ें। “बची हुई जोखिम” और “अगला सबसे छोटा काम” लिख दें। यही अगली सुबह की शुरुआत बनेगी।

असली बात कदम 2 है। verification command पहले तय किए बिना संपादन शुरू कर दें, तो आप उसी शुक्रवार रात पर लौट आते हैं — “लगता है तो ठीक हो गया, पर पक्का यकीन नहीं।” दौड़ने से पहले finish line की रस्सी बांध लें। बस इतने से रोज का काम काफी हल्का हो जाता है।

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

मुझे लगता है शुरुआती सबसे ज्यादा यहीं उलझता है। न तो सब कुछ AI पर फेंक देना ठीक है, न ही अगर सब खुद करना है तो इसे इस्तेमाल करने का मतलब रह जाता है। मैंने सीमा-रेखा का अंदाज एक table में रखा है।

स्थिति	AI को सौंपें	इंसान तय करे / बटन दबाए
दायरा तय करना	विकल्प सुझवाएं	आज का एक वाक्य पक्का करें
संपादन	code या text लिखवाएं	क्या ठीक करना है, यह नीति
जांच	build या test चलवाएं	किस जांच को goal बनाएं
publish	diff का सारांश निकलवाएं	publish का बटन दबाएं
जोखिम वाला काम	”करूं या नहीं” पुछवाएं	delete / production का आखिरी फैसला

उलझन में सीधा-सा नियम है। जो काम फिर से किया जा सके वह AI को, जो वापस न हो सके वह इंसान को। file का संपादन जितनी बार चाहें फिर से हो सकता है, इसलिए सौंप दें। production पर publish और file delete — शुरू में हमेशा अपने हाथ से ही दबाएं। जिन कामों की आदत हो जाए, बस उन्हें बाद में थोड़ा-थोड़ा automatic दर्जे तक बढ़ाएं। अनुमति की बारीक setting एक बार Claude Code की official documentation में ठीक से दी गई है, तो सीमा-रेखा पर उलझन हो तो एक बार उसे देख लेना सुकून देता है।

copy-paste करने लायक अनुरोध का template

हर बार शून्य से अनुरोध लिखें तो टुकड़े का आकार डगमगाता है। मैं यह template अपने notes app में चिपकाए रखता हूं और हर सुबह खाली जगह भर देता हूं।

आज का सबसे छोटा काम: (यहां एक वाक्य। जैसे: README का परिचय 3 lines फिर से लिखना)
छूने की अनुमति वाला दायरा: (जैसे: सिर्फ README.md. बाकी files बदलना मना)
पूरा होने की जांच का तरीका: (जैसे: npm run build सफल होना)

आगे कैसे बढ़ें:
1. पहले कुछ बदले बिना मौजूदा हाल पढ़कर सारांश दें।
2. ऊपर बताए दायरे को ही संपादित करें। दायरे से बाहर कुछ न छुएं।
3. संपादन के बाद बदली हुई files के नाम और जांच के तरीके का नतीजा बताएं।
4. delete / production पर लागू / बाहर भेजना जरूरी हो तो चलाने से पहले पूछें।

“दायरे से बाहर न छुएं” और “जोखिम वाला काम पहले पूछो” — ये दो lines डाल देने भर से शुरू वाला 23-file हादसा लगभग नहीं होता। AI को आजादी देने के बजाय, उसे एक सुरक्षित डिब्बा थमाने जैसा है यह।

copy-paste करके चलने वाला verification script

हर सुबह की जांच हाथ से टाइप करें तो भूल जाते हैं। मैं इस script को morning-check.mjs नाम से रख देता हूं और coffee बनाने से पहले चला देता हूं। Node.js installed हो तो यह चल जाएगा।

// morning-check.mjs : हर सुबह की जांच को क्रम से लगाकर चलाता है
import { execSync } from "node:child_process";

// जो commands जांचनी हैं, ऊपर से नीचे क्रम में लिखें. अपने project के हिसाब से बदलें.
const checks = [
  { label: "बदली हुई files", cmd: "git status --short" },
  { label: "build पास होता है या नहीं", cmd: "npm run build" },
];

let allOk = true;

for (const { label, cmd } of checks) {
  console.log(`\n=== ${label} : ${cmd} ===`);
  try {
    // नतीजा सीधे screen पर दिखाएं. error हो तो नीचे catch में जाएगा.
    const out = execSync(cmd, { encoding: "utf8" });
    console.log(out.trim() || "(कोई output नहीं)");
  } catch (e) {
    allOk = false;
    console.log("असफल:", e.message.split("\n")[0]);
  }
}

console.log("\n--- आज का समापन ---");
console.log(allOk ? "जांच OK. अगला सबसे छोटा काम एक line में छोड़ें." : "जांच रुक गई. ठीक करके आगे बढ़ें.");

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

node morning-check.mjs

checks के अंदर का हिस्सा अपने project के हिसाब से बदल लेना ही असली tip है। test हों तो npm test जोड़ें, static site हो तो public URL की जांच जोड़ें। हर सुबह वही commands उसी क्रम में चलें — बस इतने से जांच छूटना लगभग खत्म हो जाता है। मैंने यहां “कहीं बिना commit किए तो नहीं रुका” — यह जांच भी जोड़ ली है।

ऐसी स्थितियों में यह काम आता है (3 उदाहरण)

उदाहरण 1: पहले दिन सिर्फ repo का नक्शा बनाएं सीधे code ठीक करने की जरूरत नहीं। “जोखिम वाली directory कहां है”, “config files कहां हैं” — यह AI से summarize करवाकर बस पढ़ लें, तो पहला दिन सफल। अगले दिन से काम काफी तेज होगा।

उदाहरण 2: दूसरे दिन README का सिर्फ एक paragraph छोटी सी जीत का अनुभव बनाएं। परिचय की 3 lines फिर से लिखें, और npm run build से जांचें कि कुछ टूटा तो नहीं। बस इतना। छोटा करके खत्म करें और जांच तक पहुंच जाएं, तो “मैं भी इसे चला सकता हूं” वाला भरोसा हाथ आ जाता है।

उदाहरण 3: तीसरे दिन नतीजे से जुड़ा एक छोटा सुधार लेख का heading ठीक करना, एक test जोड़ना, एक टूटा link ठीक करना। ऐसा छोटा सुधार चुनें जिसका असर दिखे। अहम यह है कि रोज एक “जांच तक पास हुआ बदलाव” जमा करते रहें।

असफलता के उदाहरण और उनका हल

सच कहूं तो मैं खुद इन तीन में बार-बार गिरा हूं।

गड्ढा 1: एक ही बार में सब करने की कोशिश। “जो भी ठीक करने लायक है, सब” — इससे ऐसा विशाल diff बनता है जिसे जांचा ही नहीं जा सकता। हल सीधा है: आज का वाक्य “एक” तक सीमित करें। बाकी कल के note में डाल दें।

गड्ढा 2: सिर्फ local build को ही पूरा होना मान लेना। npm run build पास हो जाए तब भी जरूरी नहीं कि public URL सही दिख रहा हो। एक बार मेरा build हरा था पर public page पुराना ही रह गया और मुझे पता ही नहीं चला। हल: publish के बाद असली URL खोलकर आंखों से देखें कि heading और body की शुरुआत इस बार वाला बदलाव दिखा रही है या नहीं।

गड्ढा 3: जोखिम वाली approval को बहाव में दबा देना। confirmation dialog आए तो शुरुआती अक्सर “फिलहाल Yes” दबा देता है। delete या production पर लागू करने की पुष्टि आए तो एक पल रुक जाएं। फैसले में उलझन हो तो वह काम आज न करना ही सही जवाब है। अनुमति की सोच के लिए non-engineers के लिए व्याख्या भी काम आती है।

अगली बार के लिए छोड़े जाने वाले note का रूप

आखिर में छोड़ा जाने वाला note छोटा ही ठीक है। बस इतना तय कर लें कि अगली सुबह वाला आप वही फैसला दोबारा न करे, इसके लिए उसका आकार fix कर दें।

- आज क्या किया: README का परिचय 3 lines फिर से लिखा
- कैसे जांचा: npm run build सफल / public URL पर heading देखा
- बची हुई जोखिम: image के 2 links टूटे हुए हैं
- कल का सबसे छोटा काम: सिर्फ एक image link ठीक करना

यह note हो तो अगली सुबह “किससे शुरू करूं” वाली उलझन का समय शून्य हो जाता है। यह शुरू करने के बाद मेरी सुबह की शुरुआत महसूस से करीब 5 मिनट तेज हो गई।

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

Q. रोज 15 मिनट भी नहीं निकलते। और छोटा कर सकते हैं? हां। शुरुआत में सिर्फ “आज का सबसे छोटा काम एक वाक्य में लिखना” भी OK है। verification command तय करने की आदत भर पड़ जाए, तो काम का समय अपने-आप घटता जाता है।

Q. मुझे पता ही नहीं verification command क्या हो। project में npm run build या npm test हो, तो पहले बस वही काफी है। कुछ न हो तो “public URL खोलकर आंखों से देखना” भी एक बढ़िया जांच है। शुरू में मशीन से पता चलने वाली एक चीज तय कर लें तो काफी है।

Q. सब AI को सौंप दूं तो तेज नहीं होगा? छोटे समय में ऐसा दिखता है। पर “क्या ठीक हुआ, यह समझा न सकें” वाले बदलाव को आखिर में पूरा फिर से पढ़ना ही पड़ता है। छोटा करके बंद करना कुल मिलाकर तेज है — यह मेरा अपना अनुभव है।

Q. शुरुआती को सबसे पहले क्या करना चाहिए? repo का नक्शा बनाना। code ठीक करने से पहले, कहां क्या है यह AI से summarize करवाकर पढ़ें। सुरक्षित आगे बढ़ने की यही बुनियाद है।

Q. क्या यह routine team में लागू करने पर भी चलती है? चलती है। बस team में “publish कौन approve करेगा”, “किस जांच को goal बनाएंगे” — यह पहले लिखकर तय कर लें, तो निजी आदत वैसे ही team का नियम बन जाती है।

आखिर में: मैंने असल में आजमाकर क्या पाया

उस शुक्रवार रात के बाद से मैंने “AI को कहां तक सौंपूं” वाली उलझन में पड़ना छोड़ दिया। उसकी जगह हर सुबह मैं सिर्फ दो चीजें तय करता हूं — आज का एक वाक्य, और verification command।

morning-check.mjs को दो हफ्ते चलाकर सबसे ज्यादा जो बदला, वह है जांच का छूटना। पहले build पास किया समझकर commit कर देता और बाद में पता चलता कि कुछ टूटा हुआ है — ऐसा कई बार हुआ। जांच को उसी क्रम में मशीन से चलाने लगा, तब से वह शून्य हो गया।

और हर रात छोड़ा जाने वाला 4-line note। यह शुरू करने के बाद अगली सुबह वाला “करना क्या था” गायब हो गया। होशियार तरीके ढूंढने के बजाय, छोटा करके बंद करें और जांच छोड़ दें। दिखने में मामूली है, पर शुरुआती के आगे बढ़ने की रफ्तार, मेरे ख्याल से, यहीं तय होती है।

पहले कल सुबह बस एक वाक्य तय करें, और एक verification command चलाकर देखें। करते-करते अपना खुद का ढांचा बन जाए, तो training / परामर्श से अनुरोध के template बढ़ा लें, ताकि रोज के कदम और कम हो जाएं।