Obsidian के नोट को Claude Code आज लागू कर सके, ऐसे request में बदलने का तरीका

शुक्रवार की रात मैंने Obsidian में सिर्फ इतना लिखा था: “signup की तरफ खींचना कमजोर लग रहा है। बहुत से लोग scroll किए बिना free PDF के link को देख ही नहीं पाते।” सोमवार सुबह मैंने वही नोट पूरा का पूरा Claude Code में paste किया और कहा “इसे ठीक कर दो।” जवाब में आया दो स्क्रीन भर का “मौजूदा हालत का विश्लेषण।” कोड की एक भी line नहीं थी।

नोट खराब नहीं था। गलती यह थी कि मैंने नोट को जस का तस दे दिया। उस दिन मैंने सिर्फ background सुनने में तीस मिनट गला दिए।

Obsidian में जानकारी जमा होती जा रही है, फिर भी हर बार Claude Code को वही भूमिका वाली बात लिखकर देनी पड़ती है। अगर यह आपकी भी कहानी है, तो कमी ज्यादा होशियार AI की नहीं है, कमी है नोट को “request” में छाँटने वाले एक साँचे की।

मुख्य बातें

• Obsidian का नोट जस का तस paste करने पर Claude Code summary बनाने वाला बन जाता है और लागू करना पिछड़ जाता है। देना है पूरा नोट नहीं, सिर्फ एक task जो आज खत्म हो जाए।
• नोट से निकालने हैं सिर्फ छह चीज़ें: goal, न छूने वाला हिस्सा, पहला कदम, जांच का तरीका, CTA path और वापस लौटने का तरीका।
• “पढ़ने का दायरा” और “न छूने का दायरा” पहले लिख देने से payment या login में बिना कहे फैल जाने वाला हादसा खत्म हो जाता है।
• request को template बनाकर Obsidian में रख लें, तो अगली बार दोबारा लिखने की मेहनत नहीं बचती।
• “हो गया” वाली रिपोर्ट पर भरोसा करने के बजाय, screen की capture या build के result जैसे ठोस सबूत से फैसला लें।

नोट को पूरा क्यों नहीं देना चाहिए

Obsidian का नोट भविष्य के अपने-आप के नाम एक चिट्ठी है। उसमें context भी है और दुविधा भी, सब लिखा होता है। इसी वजह से जब AI को देते हैं, तो वह “सब पढ़कर समझ लूँ” करने लगता है।

अगर इंसान साथी होता, तो लंबा नोट पढ़कर खुद ही छाँट लेता: “मतलब, बात link की जगह की है।” Claude Code इतनी समझदारी नहीं दिखाता। जितना ज्यादा text दोगे, उतना ही विस्तार से, सलीके से summary लौटा देता है। मददगार है, पर मुझे summary नहीं चाहिए थी।

इसलिए देने से पहले, इंसान की तरफ से छाँट लेते हैं। हज़ार अक्षर के नोट में से, लागू करने के लिए ज़रूरी सिर्फ तीस अक्षर बचाते हैं। यही छाँटने का काम, हर बार की भूमिका वाली बात को खत्म करने का सबसे छोटा रास्ता है।

नोट को सँभालने का काम भी Claude Code को सौंपना चाहते हैं, तो पहले Obsidian के साथ जोड़ने की बुनियाद पढ़ लें, इससे इस लेख के कदम आपस में आसानी से जुड़ जाएँगे।

नोट से निकालने वाले छह बिंदु

मैं हर बार नोट से सिर्फ ये छह चीज़ें निकालता हूँ। ज़रूरी नहीं कि नोट में ये छहों मौजूद ही हों। जो खाने खाली हैं, उन्हें छाँटते वक्त मैं खुद तय कर लेता हूँ।

बिंदु	अंदर क्या	उदाहरण
goal	उपयोगकर्ता को जो मिलेगा, एक वाक्य में	visitor को scroll से पहले ही free PDF का link दिख जाए
न छूने का दायरा	जिसे तोड़ना नहीं	payment प्रोसेस, login, mobile पर layout का बिगड़ना
पहला कदम	शुरुआत कहाँ से	top के पहले screen में एक section जोड़ना
जांच का तरीका	”खत्म” मानने का आधार	build pass हो, बदलाव का diff, live URL की दिखावट
CTA path	reader को आगे कहाँ भेजें	free PDF के registration पेज पर
वापसी का तरीका	नाकाम होने पर बचने का रास्ता	बस इस commit को undo कर देना काफी

खास बात है “न छूने का दायरा।” इसे खाली छोड़ दिया, तो link ठीक करने के बहाने payment वाला कोड भी “साथ में सुधार दिया” कहकर बदला जा सकता है। मना किया हुआ इलाका पहले ही खींच देना, सबसे ज्यादा असर करता है।

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

इन दोनों को मिला दिया तो हादसा होता है। लकीर साफ खींच लेते हैं।

• इंसान तय करता है: goal, न छूने का दायरा, वापसी का तरीका। ये कारोबार के फैसले हैं, इन्हें AI पर मत फेंको।
• AI को सौंपते हैं: पहले कदम को ठोस बनाना, कोड लागू करना, जांच वाले command चलाना।
• इंसान आखिर में देखता है: live URL की दिखावट, और diff उम्मीद के मुताबिक है या नहीं। बस यहाँ आँख से जांचते हैं।

फैसला सौंपा जा सकता है सिर्फ “कैसे बनाना है” का, “किसे बचाना है” का नहीं। क्या बचाना है, यह तय करना हमेशा इंसान के पाले में रहता है।

नोट को request में बदलने वाला prompt साँचा

निकाले हुए छह बिंदुओं को, Claude Code को सीधे देने लायक रूप में ढाल लेते हैं। नीचे का साँचा copy करें और आखिर में अपना नोट चिपका दें।

नीचे दिए Obsidian नोट को, ऐसी एक request में बदलो जिसे तुम आज लागू कर सको।
output को इन छह headings में बाँटो। अभी कोड मत लिखो।

- goal (उपयोगकर्ता को जो मिलेगा, एक वाक्य में)
- न छूने का दायरा (जिसे बदलना मना है)
- पहला कदम (सबसे छोटा एक बदलाव)
- जांच का तरीका (build, diff, live URL वगैरह)
- CTA path (reader को आगे कहाँ भेजना है)
- वापसी का तरीका (नाकाम होने पर मूल हालत में लौटाने के steps)

【नोट】
(यहाँ Obsidian का नोट चिपकाएँ)

सबसे ज़रूरी है आखिरी वाक्य, “अभी कोड मत लिखो।” यह न हो, तो Claude Code बदलने और लागू करने का काम एक साथ करने लगता है और न छूने वाले दायरे की जांच को छोड़ देता है। पहले एक बार request निकलवाओ, इंसान मना किया इलाका जांच ले, फिर “अब इस request के मुताबिक लागू करो” कहकर लौटाओ। इस दो-चरण तरीके से हादसे घटते हैं।

साँचे की धार और तेज़ करनी हो, तो Claude Code के लिए prompt डिज़ाइन की उन्नत बातें में बारीक शब्द-चयन के तरीके इकट्ठा हैं।

copy-paste से चलने वाली बदलाव स्क्रिप्ट

हर बार हाथ से prompt बनाना झंझट लगे, तो नोट को object के रूप में लिख दो और request खुद-ब-खुद बन जाए। Node.js हो तो यह जस का तस चलता है।

// नोट को "आज लागू होने लायक request" में बदलने वाली सबसे छोटी स्क्रिप्ट
// इस्तेमाल: node note-to-issue.mjs

const note = {
  goal: "visitor को scroll से पहले free PDF का link दिख जाए",
  doNotTouch: ["payment प्रोसेस", "login", "mobile पर layout का बिगड़ना"],
  firstStep: "top के पहले screen में एक announcement section जोड़ना",
  proof: ["build pass हो", "बदलाव का diff", "live URL की दिखावट"],
  ctaPath: "free PDF का registration पेज",
  rollback: "बस इस commit को undo कर देने से मूल हालत लौट आती है",
};

function toIssuePrompt(n) {
  // ज़रूरी बिंदु छूट गया हो तो request निकलने से पहले ही पता चल जाए
  const required = ["goal", "doNotTouch", "firstStep", "proof"];
  const missing = required.filter((key) => {
    const v = n[key];
    return v === undefined || (Array.isArray(v) && v.length === 0);
  });
  if (missing.length > 0) {
    throw new Error(`request के लिए ज़रूरी बिंदु कम हैं: ${missing.join(", ")}`);
  }

  const line = (label, value) =>
    `${label}: ${Array.isArray(value) ? value.join(" / ") : value}`;

  return [
    line("goal", n.goal),
    line("न छूने का दायरा", n.doNotTouch),
    line("पहला कदम", n.firstStep),
    line("जांच का तरीका", n.proof),
    line("CTA path", n.ctaPath),
    line("वापसी का तरीका", n.rollback),
    "अभी कोड मत लिखो, इस दायरे में सबसे छोटी implementation plan ही लौटाओ।",
  ].join("\n");
}

console.log(toIssuePrompt(note));

चलाने पर छह line और आखिरी एक वाक्य वाली request बनकर निकलती है। doNotTouch को खाली array करके दोबारा चलाओ, तो request निकलने से पहले ही “बिंदु कम हैं” कहकर रुक जाती है। खाली खाने के साथ ही दे देने वाला हादसा, कोड की तरफ से पहले ही रोक देने का इंतज़ाम है।

जहाँ यह सच में काम आता है, ऐसे तीन मौके

1. CTA link सुधारने का नोट “free PDF का link कमजोर है” वाला नोट जस का तस paste करो, तो सुधार की राय की व्याख्या लगातार चलती रहती है। request में छाँट दो, तो पहला कदम सिमटकर “पहले screen में एक section जोड़ना” भर रह जाता है और payment वाले हिस्से को छूने नहीं दिया जाता। सुधार से पहले और बाद की दिखावट live URL पर मिलाकर देखो, तो असर अंदाज़े से नहीं, आँख से तय होता है।

2. bug खोजने का नोट “कभी-कभी login के बाद screen सफेद हो जाता है” वाले नोट में जानकारी ज़रूरत से ज्यादा होती है। request में पहला कदम को “बस repro की शर्तें और error log पहले शेयर करो” तक सीमित करो। वजह ढूँढना और सुधारना एक साथ मत कराओ, पहले repro पर ध्यान केंद्रित कराओ, तो गलत दिशा का सुधार टल जाता है।

3. लेख की योजना का नोट “अगले लेख में internal link ठीक से लगाने हैं” जैसे धुँधले नोट को भी, goal को “related articles के दो internal link पक्के लगाना” तक छाँट दो, तो वह लागू होने लायक बन जाता है। जांच का तरीका “build pass हो” रख लो, तो टूटे link publish से पहले रुक जाते हैं। लेख से जुड़ा काम सौंपने से पहले non-engineer के लिए Claude Code की शुरुआत में एक बार अभ्यास कर लेना ठीक रहता है।

request को template बनाकर रखना

एक बार बनाई request को इस्तेमाल करके फेंकने के बजाय Obsidian में वापस रख देता हूँ। अगली बार ऐसा ही नोट आए, तो छहों heading समेत दोबारा काम आ जाती है।

मैंने templates/issue-prompt.md नाम का एक नोट बनाकर उसमें छह heading का खाली template रख दिया है। नया नोट आते ही, बस उस template को copy करके भर देता हूँ। हर बार भूमिका लिखने का समय खत्म हो गया।

इसके अलावा, Claude Code को जो नियम पढ़ने चाहिए उन्हें project में पक्का कर दो, तो request और छोटी हो जाती है। project में सबके लिए तय बातें CLAUDE.md लिखने का तरीका में रख दो, तो request की तरफ हर बार दोहराना नहीं पड़ता।

जहाँ अक्सर ठोकर लगती है, और सुधार का तरीका

शुरुआत में मैंने खुद जो गलतियाँ कीं, उन्हें सुधार समेत गिना रहा हूँ।

• नोट पूरा paste करना: Claude Code summary बनाने वाला बन जाता है। सुधार: paste करने से पहले छह बिंदुओं में छाँट लो। जो नोट छँट नहीं रहा, वह अभी request के तौर पर पका नहीं है; पहले खुद एक वाक्य का निष्कर्ष लिखो।
• न छूने का दायरा न लिखना: payment या auth में बिना कहे फैल जाता है। सुधार: खाने को खाली मत छोड़ो, “कुछ खास नहीं” भी मत लिखो। कम से कम एक मना इलाका लिखने की आदत डालो।
• जांच का तरीका “चल जाए तो ठीक”: फिर “हो गया” रिपोर्ट पर ही भरोसा करना पड़ता है। सुधार: build का result, diff या live URL में से कम से कम एक ज़रूर तय करो।
• एक साथ लागू करा देना: बदलना और लागू करना मिल जाते हैं, मना इलाके की जांच छूट जाती है। सुधार: “अभी कोड मत लिखो” ज़रूर डालो, request जांचने के बाद ही लागू करने को कहो।

ठोकरें सब की सब “पहले एक line तय कर लेता तो बच जातीं” वाली ही थीं।

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

Q. नोट टुकड़ों में है, छहों बिंदु नहीं भर पा रहा। सब भरना ज़रूरी नहीं। कम से कम “goal” और “न छूने का दायरा” तय कर लो, तो request बन जाती है। बाकी request निकलने के बाद, Claude Code की राय देखकर भर लो, तब भी समय पर हो जाता है।

Q. क्या Obsidian के नोट को सीधे Claude Code से पढ़वाने वाला integration ज़रूरी है? शुरू में नहीं। नोट हाथ से copy करके साँचे में चिपका देना ही काफी काम कर जाता है। वही काम बार-बार दोहराने लगो, तब auto integration सोचो, देर नहीं होगी।

Q. “अभी कोड मत लिखो” लिखने पर भी लागू करना शुरू कर देता है। project की CLAUDE.md में “request में बदलते वक्त कोड न लिखो” साफ लिख दो, तो टिकता है। एक prompt के निर्देश से ज्यादा, project में सबके लिए तय नियम बेहतर माने जाते हैं।

Q. request की लंबाई कितनी ठीक है? छह heading मिलाकर करीब दस line का अंदाज़ रखता हूँ। इससे लंबी हो जाए, तो यह इशारा है कि एक ही task में कई goal मिल गए हैं। task को बाँट दो।

Q. जांच के तरीके में क्या डालूँ, समझ नहीं आता। उलझन हो तो “build pass हो” और “live URL की दिखावट”, इन दो से शुरू करो। बस इन दो से ही “हो गया” रिपोर्ट को आँख मूँदकर मानने वाली हालत से निकल आओगे।

असल में आज़माने पर क्या हुआ

शुरुआत वाले CTA link के नोट को, इन छह बिंदुओं के साँचे से छाँटकर मैंने दोबारा Claude Code को दिया। इस बार summary नहीं लौटी, सबसे पहले “पहले screen में एक announcement section जोड़ना” वाली implementation plan आई। न छूने वाले दायरे में लिखे payment प्रोसेस को ज़रा भी हाथ नहीं लगा।

जांच स्क्रिप्ट को भी doNotTouch जानबूझकर खाली करके चलाया, तो request निकलने से पहले ही “बिंदु कम हैं” पर रुक गई। खाली खाने के साथ दे देने वाला सबसे आम हादसा, चलने से पहले ही रुक सकता है, यह पक्का हो गया।

हर बार होशियार निर्देश निचोड़ने से तेज़ है, नोट छाँटने का एक साँचा अपने पास रखना। यही अभी मेरा अनुभव है। यही तरीका team के लेख बनाने या पूछताछ के जवाब तक फैलाना चाहते हो, तो काम के लिए training और सलाह में असल इस्तेमाल के हिसाब से साँचा गढ़ा जा सकता है। आधिकारिक मानक Anthropic के official दस्तावेज़ में देखे जा सकते हैं।