Obsidian notes को Claude Code implementation brief में बदलना

अगर Obsidian vault में जवाब है, फिर भी हर Claude Code session वही explanation मांगता है, तो problem notes नहीं हैं। problem handoff shape है।

यह लेख Claude Code के लिए छोटा issue brief format बनाता है। पूरी note paste करने के बजाय facts, decisions, unknowns, next action और proof requirements दें।

संबंधित लेख: claude-code-obsidian-integration, claude-code-claude-md-templates, claude-code-session-handoff-template. आधिकारिक setup baseline यहां है Anthropic Claude Code getting started.

पहले कमांड से पहले यह क्यों जरूरी है

इस topic का केंद्र Obsidian knowledge को implementation brief में बदलना है। Claude Code तेज चलता है, लेकिन पहला input बहुत बड़ा हो तो low-value diff, पुराने hypothesis और revenue से अलग formatting भी important work जितनी priority पा लेते हैं।

जिनके पास useful notes हैं, लेकिन Claude Code handoff भारी है के लिए goal काम को बड़ा दिखाना नहीं है। goal है कि क्या पढ़ना है, क्या नहीं छूना है, पहले क्या try करना है और failure पर कहां लौटना है। content operations और product development दोनों में यह boundary जरूरी है।

व्यावहारिक workflow

1. note को facts, decisions, unknowns और next action में बांटें
2. पुरानी hypotheses implementation brief में न डालें
3. content change हो तो CTA और product routing decisions शामिल करें
4. अंत में build और mobile screenshot proof मांगें

इस order से request “freely सोचो” से “इस boundary में काम करो और proof छोड़ो” बन जाती है। Claude Code reasoning कर सकता है, पर dangerous areas first edit से पहले बंद रहते हैं।

स्थिति	सुरक्षित कदम	रखने वाला प्रमाण
article improvement	search intent और CTA policy दें, full rewrite न बुलाएं	build, diff, URL
bug fix	reproduced facts और unverified causes अलग रखें	build, diff, URL
consulting prep	customer notes को scope, blocked areas और next questions में बदलें	build, diff, URL

इस प्रमाण से Claude Code को भरोसेमंद वाक्य से नहीं, दिखने वाले काम से जांचा जाता है।

कॉपी करने योग्य prompt और code

इस Obsidian note को Claude Code implementation brief में बदलें। facts, decisions, unknowns, next action, blocked areas और proof अलग करें। stale hypotheses अलग section में रखें और instructions में न मिलाएं।

const note = {
  title: "Checkout CTA wraps on mobile",
  facts: ["375px screenshot shows two-line button", "Gumroad URL is correct"],
  decision: "keep free PDF before paid guide",
  unknowns: ["which component owns the button spacing"],
  nextAction: "find component, make smallest CSS change, verify mobile",
};

function toClaudeBrief(item) {
  return [
    `Goal: ${item.nextAction}`,
    `Facts: ${item.facts.join("; ")}`,
    `Decision: ${item.decision}`,
    `Do not assume: ${item.unknowns.join("; ")}`,
    "Proof: build plus mobile screenshot",
  ].join("\n");
}

console.log(toClaudeBrief(note));

यह code छोटा sanity check है। real project में output को CLAUDE.md, issue या handoff note में paste करें ताकि next session वही judgment reuse करे।

वास्तविक उदाहरण और failure case

स्थिति	सुरक्षित कदम	रखने वाला प्रमाण
article improvement	search intent और CTA policy दें, full rewrite न बुलाएं	build, diff, URL
bug fix	reproduced facts और unverified causes अलग रखें	build, diff, URL
consulting prep	customer notes को scope, blocked areas और next questions में बदलें	build, diff, URL

• पूरा vault paste करने से पुराने decisions और current constraints मिल जाते हैं।
• सिर्फ decision paste करने से काम का reason छिप जाता है।
• CTA policy छोड़ने से prose बेहतर हो सकता है पर revenue path कमजोर हो जाता है।

common failure Claude Code की ability नहीं, input boundary का पतला होना है। boundary thin हो तो assistant helpful बनने के लिए task बढ़ा देता है। monetized article में free PDF, Gumroad और consultation में चुनाव भी boundary का हिस्सा है।

पाठक को free PDF, Gumroad और consultation तक ले जाना

अगर basic commands अभी भी अस्पष्ट हैं, तो free cheatsheet से रोज का pattern बनाइए। setup, permissions, CLAUDE.md, MCP या CI bottleneck है तो Setup Guide अगला paid step है। review, debugging या refactoring prompts बार-बार लिखने पड़ते हैं तो 50 Prompt Templates उपयोगी है। team rollout या revenue path design चाहिए तो consultation पर जाएं। product comparison products से शुरू करें।

CTA सिर्फ अंत में एक बार होना जरूरी नहीं। introduction के पास free PDF friction घटाता है। implementation examples के बाद Gumroad guide fit होता है। team या production risk पर consultation natural next step है।

publish के बाद देखने वाले metrics

अब Obsidian articles से Prompt Templates और Setup Guide clicks देखें।

publish के बाद PV, opening-body reads, internal-link clicks, free PDF registrations, Gumroad clicks और consultation visits अलग-अलग देखें। HTTP 200 अकेला success नहीं है। h1, canonical, heroImage, CTA और localized body एक ही next action दिखाने चाहिए।