Obsidian के notes को Claude Code का साफ निर्देश-पत्र कैसे बनाएं

पिछले हफ्ते मैंने Obsidian में करीब 2000 शब्दों की एक note छोड़ी, और अगले दिन Claude Code से कहा — “वो checkout वाला button ठीक कर दो”।

जवाब में मुझे मिला: button की fix के साथ-साथ header की spacing में बदलाव, footer के links का क्रम बदलना, और ऊपर से CSS naming convention को “सुधारने” वाला तीन files का diff। इनमें से एक भी मैंने नहीं माँगा था। ऐसा क्यों हुआ? क्योंकि मैंने पूरी note ज्यों की त्यों चिपका दी थी। तीन दिन पहले की “यहाँ भी कुछ अटपटा लगता है” वाली बड़बड़ाहट तक, आज के निर्देश जितनी ही गंभीरता से पढ़ ली गई।

गलती note की नहीं थी। गलती मेरी थी — मैं समझ बैठा था कि note “जैसी है वैसी ही सौंपी जा सकती है”। लंबी note रिकॉर्ड रखने के लिए अच्छी है, पर काम का निर्देश देने के लिए नहीं। आज मैं यही फासला पाटने का तरीका लिखूँगा — Obsidian की note को एक छोटे निर्देश-पत्र में बदलने की प्रक्रिया।

मुख्य बातें

पूरी लंबी note चिपकाने पर AI पुरानी बड़बड़ाहट और आज के निर्देश में फर्क नहीं कर पाता, और बिना माँगे काम तक बढ़ा देता है।
सौंपना सिर्फ चार चीजें हैं: “पक्के तथ्य”, “तय की गई बातें”, “अभी अनजान बातें” और “अगला एक कदम”। इनमें “जहाँ हाथ न लगाना है” और “काम पूरा मानने का सबूत” जोड़ दें।
पूरा होने की शर्त छोटी रखें — एक file, एक screen, एक command तक सीमित करें, build और screenshot देखने के बाद ही आगे बढ़ें।
template वाला prompt और note को brief में बदलने वाला छोटा code सीधे copy करके इस्तेमाल कर सकते हैं।
AI को सौंपिए “लिखना, ढूँढना, ठीक करना”। इंसान तय करे “दायरा, प्राथमिकता, publish करना है या नहीं”। इन्हें मिला देने पर हादसा होता है।

पूरी note चिपकाने पर काम क्यों फैल जाता है

Claude Code बहुत तेज चलता है। इसीलिए शुरुआत में दिया गया input जितना चौड़ा होगा, वह उतनी ही चौड़ाई पर पूरी रफ्तार से दौड़ेगा।

note में समय का फर्क होता है। “button mobile पर दो लाइन में टूट रहा है” — यह आज का तथ्य, और “अरे हाँ, रंग-संयोजन भी पुराना लगता है” — यह एक हफ्ते पुरानी राय, दोनों एक ही bullet list में बराबरी से बैठी हैं। इंसान तारीख और संदर्भ से पढ़कर अलग कर लेता है, पर चिपकाई हुई note में AI को नहीं पता कि कौन-सा निर्देश अब भी जिंदा है। नतीजा — मदद के जोश में वह सब पर हाथ डाल देता है।

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

सौंपना सिर्फ चार चीजें हैं

छँटाई का तरीका सीधा है — नीचे दी चार खानों में बाँट दीजिए।

तथ्य (facts): जो सचमुच जाँच लिया गया हो। “375px screen पर button दो लाइन में टूटता है”, “live URL सही है” — जैसी बातें जिन पर देखकर कोई भी सहमत हो जाए।
तय की गई बातें (decisions): जो तय हो चुका है। “मुफ्त बँटने वाली PDF को paid कोर्स से पहले रखना है” — जिस पर बहस खत्म हो चुकी और जिसे अब हिलाना नहीं।
अभी अनजान (unknowns): जो अभी पता नहीं। “button की spacing किस component में है, यह अज्ञात है” — वो खाली जगह जिसे AI से मनमाने ढंग से भरवाना नहीं है।
अगला एक कदम (next action): इस बार करने का सिर्फ एक काम। “component पहचानो, सबसे छोटा CSS बदलाव करो, mobile चौड़ाई पर जाँचो” — इतना ठोस।

इनमें दो चीजें और जोड़िए। जहाँ हाथ न लगाना है (उदाहरण: auth से जुड़ी files को इस बार न छूना) और काम पूरा मानने का सबूत (उदाहरण: build पास हो, mobile चौड़ाई का screenshot)। ये छह बिंदु ही निर्देश-पत्र की पूरी सामग्री हैं।

छँटाई करते समय एक बात का ध्यान रखें — “अनजान” को मिटाइए मत। जो पता नहीं उसे ईमानदारी से छोड़ देंगे, तो AI वहीं सवाल पूछ लेता है। उल्टा अगर अनजान को मिटाकर उसे तथ्य की तरह लिख देंगे, तो AI गलत मान्यता के साथ आगे बढ़ता रहेगा।

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

सबसे पहले यह लकीर खींच लीजिए कि क्या सौंपना ठीक है और किस पर इंसान को पकड़ रखनी है। यहाँ धुँधलापन रहा, तो निर्देश-पत्र बनाकर भी अंत में बात डगमगाएगी।

चरण	AI को सौंपें	इंसान तय करे
दायरा	-	किस file या screen तक सीमित रखना है
जाँच-पड़ताल	component और code ढूँढना	किसे पहले ढूँढना है, उसकी प्राथमिकता
implementation	सबसे छोटा बदलाव लिखना	बदलाव की ऊपरी सीमा
पुष्टि	build और test चलाना	publish करना है या नहीं, अंतिम फैसला

जैसा table में है, “ढूँढना, लिखना, चलाना” में AI माहिर है। वहीं “कितनी दूर तक जाना है” और “publish करना है या नहीं” — इस पर इंसान की पकड़ रहे। यह लकीर निर्देश-पत्र में लिख दें, तो AI दायरा फैलाने को बढ़े भी, तो खुद रुक जाएगा। AI को कितना सौंपा जाए, इसकी बुनियाद claude-code-for-non-engineers में समझाई है।

copy करके इस्तेमाल होने वाला prompt template

पहले note को ज्यों का त्यों select करके इस अनुरोध-पाठ के नीचे चिपका दीजिए। छँटाई का काम ही AI से करवाने का तरीका है यह।

नीचे दी Obsidian note को Claude Code के लिए एक छोटे निर्देश-पत्र में बदलिए।
output में सिर्फ ये heading रखिए, बाकी सब हटा दीजिए:

- तथ्य: सिर्फ जाँची हुई बातें
- तय: जो अब नहीं बदलना
- अनजान: मनमाने ढंग से न भरें, अज्ञात ही छोड़ें
- अगला कदम: इस बार का सिर्फ एक काम, ठोस रूप में
- हाथ न लगाएँ: इस बार जिन files या features को नहीं छूना
- सबूत: काम पूरा मानने की पुष्टि का तरीका (build, screenshot आदि)

पुरानी राय और इधर-उधर की बातें "संदर्भ note" के अलग खाने में रखें,
निर्देश में न मिलाएँ।

जो निर्देश-पत्र निकले उसे एक बार दोबारा पढ़िए — बस इतना देखिए कि कहीं अनजान बात तथ्य का रूप तो नहीं ले बैठी, और अगला कदम सच में एक ही पर सिमटा है या नहीं। ठीक लगे तो इसे सीधे CLAUDE.md या issue की comment में चिपकाकर implementation माँग लीजिए। CLAUDE.md कैसे लिखें, इस पर claude-md-best-practices में विस्तार से लिखा है।

note को निर्देश-पत्र में बदलने वाला verification code

हाथ से करने से पहले, ढाँचा शरीर में बैठाने के लिए एक छोटा code रख रहा हूँ। यह Node.js पर चलता है। note को ऊपर के छह बिंदुओं में बाँटकर रखता है और Claude Code को सौंपने लायक एक पन्ने का निर्देश-पत्र जोड़ देता है — बस इतना ही।

// note को "तथ्य, तय, अनजान, अगला कदम" में बाँटकर रखें
const note = {
  title: "checkout का button mobile पर टूट रहा है",
  facts: ["375px screen पर button दो लाइन में टूटता है", "live URL सही है"],
  decision: "मुफ्त PDF को paid कोर्स से पहले दिखाना है",
  unknowns: ["button की spacing किस component में है, अज्ञात"],
  nextAction: "component पहचानो, सबसे छोटा CSS बदलाव करो, mobile चौड़ाई पर जाँचो",
  doNotTouch: ["auth से जुड़ी files"],
  proof: ["build पास हो", "375px चौड़ाई का screenshot"],
};

// छह बिंदुओं को एक पन्ने के निर्देश-पत्र में जोड़ें
function toBrief(item) {
  return [
    `लक्ष्य: ${item.nextAction}`,
    `तथ्य: ${item.facts.join(" / ")}`,
    `तय: ${item.decision}`,
    `अनजान (खुद न भरें): ${item.unknowns.join(" / ")}`,
    `हाथ न लगाएँ: ${item.doNotTouch.join(" / ")}`,
    `सबूत: ${item.proof.join(" / ")}`,
  ].join("\n");
}

// छँटाई में रह गई कमी को मशीन से जाँचने वाला दरबान
function checkBrief(item) {
  const missing = [];
  if (item.facts.length === 0) missing.push("तथ्य");
  if (item.unknowns.length === 0) missing.push("अनजान");
  if (!item.nextAction) missing.push("अगला कदम");
  if (missing.length) {
    throw new Error(`छँटाई अधूरी है: ${missing.join(", ")}`);
  }
  return true;
}

checkBrief(note);
console.log(toBrief(note));

checkBrief दिखने में मामूली है, पर असली कील यही है। तथ्य खाली, अनजान खाली, अगला कदम खाली — ऐसी हालत में निर्देश-पत्र निकालने की कोशिश यहीं रुक जाती है। “बस चिपका दो” वाली आदत को code के स्तर पर ही रोक देंगे, तो कच्ची note सीधे AI तक बह जाने वाला हादसा घटता है। output को सीधे issue की comment या handoff note में चिपका दें, तो अगली बार भी वही फैसला दोबारा काम आ जाता है। handoff note कैसे बनाएँ, इस पर claude-code-session-handoff-template मददगार है।

इन जगहों पर यह काम आता है

1. किसी लेख को बेहतर करवाते समय “इस लेख को सुधार दो” कहकर पूरा फेंक देंगे, तो AI आम तौर पर पूरा मूल पाठ ही दोबारा लिख डालता है। इसलिए निर्देश-पत्र में लिखिए — “सिर्फ search intent और CTA की नीति दे रहा हूँ”, “पूरे पाठ को दोबारा लिखना मना है”। तथ्य = आज के heading, तय = routing की नीति, अनजान = कमजोर लगने वाला paragraph, अगला कदम = सिर्फ एक heading ठीक करना। ऐसा बाँटने पर diff छोटा रहता है और वापस लौटाना भी पल भर का काम है। Obsidian को Claude Code से जोड़ने की setup claude-code-obsidian-integration में दी है।

2. कोई bug ठीक करते समय जो दोबारा reproduce हो सका, वह तथ्य; और जिसका कारण अभी अज्ञात है, वह अनजान — दोनों अलग करके सौंपना ही असली तरकीब है। “375px पर button टूटता है” तथ्य है, “किस component में spacing है” अनजान है। इन्हें मिलाकर “कारण तो CSS में ही होगा” लिख देंगे, तो AI गलत अंदाजे के साथ ठीक करना शुरू कर देता है। अनजान को अनजान ही रहने दें, तो AI पहले वहीं जाँच-पड़ताल कर लेता है।

3. किसी की Claude Code-introduction में सलाह देते समय ग्राहक की काम-संबंधी note को ज्यों का त्यों दिखाने के बजाय “इस बार जिस दायरे में हाथ डालना है”, “जिसे बिल्कुल नहीं छूना” और “अगली बार जाँचना है” — इन खानों में बाँटकर दीजिए। live data और billing से जुड़ी चीजों को अनजान रहते हुए AI से अपने-आप मत छुड़वाइए। यह लकीर निर्देश-पत्र में लिख देने भर से, सलाह की बैठक में screen share करते हुए चैन रहता है।

अक्सर होने वाली गलतियाँ और उनका इलाज

मैंने शुरू में जो गलतियाँ कीं, वे लगभग इन तीन में सिमट जाती हैं।

पहली — पूरा vault चिपका देना। पुराने फैसले और आज की पाबंदियाँ मिल गईं, और AI को समझ ही नहीं आया कि किसे सच माने। इलाज सीधा है: चिपकाने से पहले ऊपर के छह खानों में छँटाई कर लें। तीन दिन पुरानी राय को “संदर्भ note” में अलग कर दें।

दूसरी — सिर्फ फैसला सौंपना। जब मैंने बस “PDF को आगे रखो” लिखा, तो AI को कारण नहीं पता चला और किसी और जगह उसने उल्टा कर दिया। तथ्य और कारण दोनों साथ रखेंगे, तो बात दूसरी जगह भी ठीक से लागू होती है।

तीसरी — पूरा होने की शर्त बड़ी रख देना। “पूरी तरह से ठीक-ठाक कर दो” कहने पर AI मददगार बनकर दायरा फैला देता है। एक file, एक screen, एक command तक सीमित रखें, और build व screenshot देखने के बाद आगे बढ़ें। इतने से ही रफ्तार घटाए बिना वापस लौटाने का समय कम हो जाता है। prompt को कैसे सिकोड़ें, इस पर claude-code-prompt-engineering-advanced भी देख लीजिए।

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

Q. पूरी note चिपकाने से तो निर्देश-पत्र बनाना ज्यादा झंझट है न? पहली कुछ बार ऐसा ही लगता है। पर फेंके हुए काम से फैले diff को दोबारा पढ़कर वापस लौटाने का समय, लंबे समय में कहीं भारी पड़ता है। छँटाई की आदत पड़ जाए तो एक मिनट में हो जाती है।

Q. क्या छँटाई भी AI से करवा सकते हैं? हाँ। ऊपर दिया prompt template ठीक इसी काम के लिए है। बस निकले हुए निर्देश-पत्र को इंसान एक बार पढ़ ले, और इतना देख ले कि कहीं अनजान बात तथ्य का रूप तो नहीं ले बैठी।

Q. CLAUDE.md और निर्देश-पत्र में फर्क क्या है? CLAUDE.md पूरे project में न बदलने वाले नियमों की जगह है, निर्देश-पत्र इस बार के एक काम का अनुरोध। निर्देश-पत्र की कोई “तय बात” बार-बार आती दिखे, तो यह संकेत है कि उसे CLAUDE.md में ऊपर चढ़ा देना चाहिए।

Q. क्या यह Obsidian के बिना भी काम करता है? हाँ। Notion हो या सादी text note, सब चलेगा। अहम tool नहीं, बल्कि तथ्य-तय-अनजान-अगला कदम में बाँटने की सोच है।

Q. कहाँ तक AI को सौंपूँ और कहाँ से इंसान तय करे? “ढूँढना, लिखना, चलाना” बेफिक्र सौंप दीजिए। “दायरा कितना फैलाना है”, “publish करना है या नहीं” — यह इंसान की पकड़ में रहे। यह लकीर निर्देश-पत्र में लिख देना ही तरकीब है।

मैंने सचमुच आजमाकर जो पाया

शुरू वाले “बिना माँगे तीन files का हादसा” के बाद, मैंने note चिपकाने से पहले हमेशा छह खानों में छँटाई करना तय कर लिया।

उसी checkout button की fix को, इस बार निर्देश-पत्र बनाकर सौंपा। diff निकला सिर्फ एक file, CSS की चंद लाइनें। header और footer — बिना माँगे किसी चीज को छुआ तक नहीं गया। checkBrief ने एक बार अनजान खाली रहते हुए output रोक दिया, और “किस component में spacing है” लिखकर देने के बाद ही सौंपना, मुझे लगता है काम आया — क्योंकि AI ने पहले जाकर वही component ढूँढ़ा।

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

note की छँटाई की आदत पड़ जाए, और फिर पूरी team में यही तरीका चलाने का मन हो, तो आगे की राह साथ डिजाइन करने वाले training और consultation भी मौजूद हैं।

आधिकारिक शुरुआती शर्तें Anthropic Claude Code getting started पर देख सकते हैं।