Obsidian निर्माण की तकनीकें जिनका उपयोग केवल जीनियस और अधिक कमाई करने वाले लोग करते हैं

AI से पैसा कमाना "नोट्स की संख्या" के बारे में नहीं है

पहले, एक शांत चर्चा करते हैं।

ऐसा कोई शोध नहीं है जो 10 करोड़ रुपये की वार्षिक आय और Obsidian कॉन्फ़िगरेशन के बीच कारण संबंध सुझाता हो। ऐसे कोई "गुप्त प्लगइन्स नहीं हैं जो केवल अमीर लोगों को पता हैं।"

मेरा "10 करोड़ रुपये के खिलाड़ी" से मतलब ऐसे व्यक्ति से नहीं है जो भारी मात्रा में ज्ञान संग्रहीत करता है।

यह उन लोगों को संदर्भित करता है जो प्राप्त जानकारी को इसमें परिवर्तित कर सकते हैं:

• निर्णय लेना
• बातचीत
• भर्ती
• निवेश निर्णय
• उत्पाद डिज़ाइन
• सामग्री
• बिक्री सामग्री
• संगठनात्मक प्रणालियाँ
• पुन: प्रयोज्य बौद्धिक संपत्ति

...बेहद तेज़ गति से।

सामान्य Obsidian उपयोगकर्ता "क्या सहेजना है" के बारे में सोचते हैं।

मजबूत उपयोगकर्ता पहले सोचते हैं "भविष्य में किस स्थिति में, किस प्रश्न का उपयोग करके, मैं इस जानकारी को पुनः प्राप्त करूंगा?"

इससे भी मजबूत उपयोगकर्ता ट्रैक करते हैं कि पुनर्प्राप्त ज्ञान अंततः किस निर्णय या आउटपुट में परिवर्तित हुआ।

दूसरे शब्दों में, आपको वास्तव में डिज़ाइन करना चाहिए वह "दूसरा मस्तिष्क" नहीं है।

यह एक व्यक्तिगत बुद्धिमत्ता OS है जो निर्णय लेने और बौद्धिक उत्पादन को संचयित करता है।

Obsidian नोट्स को स्थानीय Markdown फ़ाइलों के रूप में सहेजता है। Vault सिर्फ एक फ़ोल्डर है, और बाहरी संपादकों या स्क्रिप्ट से किए गए बदलाव Obsidian में दिखाई देते हैं। सेटिंग्स और प्लगइन जानकारी .obsidian फ़ोल्डर में अलग की जाती है। इसका मतलब है कि Obsidian सिर्फ एक ऐप नहीं है, बल्कि एक "ज्ञान भंडार" है जिसे Git, CLI, Claude और Codex द्वारा संभाला जा सकता है।

इस लेख में, हम Obsidian पर तत्वों को इस प्रकार मानते हैं:

एक बार जब आप इस दृष्टिकोण पर पहुँच जाते हैं, तो Obsidian का उपयोग करने का आपका तरीका पूरी तरह से बदल जाता है।

अध्याय 1: विदेशी मामलों पर शोध—जीतने की रणनीति "संगठन" नहीं, बल्कि "खोज" थी

1. 7 शोधकर्ताओं के Vaults से क्या सीखा

2025 में प्रकाशित एक केस स्टडी है जो एक ब्राज़ीलियाई शोध संस्थान में सात कंप्यूटर विज्ञान शोधकर्ताओं के Obsidian उपयोग की जाँच करती है।

इस अध्ययन से सबसे महत्वपूर्ण सबक यह नहीं था कि प्रतिभागियों ने नोट्स कैसे बनाए।

यह खोज थी कि भविष्य में उन्हें पुनः प्राप्त करने के उनके इरादे ने उनके नोट्स बनाने और व्यवस्थित करने के तरीके को दृढ़ता से प्रभावित किया। प्रतिभागियों ने विभिन्न उद्देश्यों के लिए खोज बार, टैग सूचियाँ, पाठ के भीतर टैग और आंतरिक लिंक का उपयोग किया। कुछ उपयोगकर्ताओं ने बनाए गए नोट्स को Inbox में रखा और सप्ताह में एक बार उन्हें संसाधित किया।

शोधकर्ताओं द्वारा प्राप्त डिज़ाइन प्रस्तावों को इन तीन बिंदुओं में संक्षेपित किया जा सकता है:

1. शुरू से ही सही वर्गीकरण की माँग न करें; एक न्यूनतम प्रारंभिक संरचना तैयार करें।
2. उपयोग के दौरान संरचना को बदलने की अनुमति दें।
3. निर्माण/संगठन विधि को भविष्य की खोज विधि से शुरू से जोड़ें।

दूसरे शब्दों में, यह "सही फ़ोल्डर बनाने" के बारे में नहीं है।

यह तय करने के बारे में है कि आपका भविष्य का स्व कैसे खोजेगा और उस खोज पथ के अनुसार रिकॉर्ड करना है।

यह अकेला बिंदु दिखाता है कि अधिकांश सामान्य Obsidian कोर्सेज़ उल्टे हैं।

कई कोर्सेज़ पहले फ़ोल्डर, टैग, प्लगइन्स और दिखावट तय करवाते हैं।

हालाँकि, वास्तव में, आपको पहले यह प्रश्न तय करना चाहिए:

तीन महीने बाद, जब मुझे इस जानकारी की आवश्यकता होगी तो मैं किस बारे में चिंतित होऊंगा?

2. Nicole van der Hoeven—नोट्स को करियर सीखने का उपकरण बनाना

Nicole van der Hoeven, जो एक Developer Advocate और Performance Engineer के रूप में काम करती हैं, बताती हैं कि काम पर लगातार नोट्स लेने का सीखने की गति और तकनीकी उद्योग में उनके करियर दोनों पर सकारात्मक प्रभाव पड़ा है।

मुख्य बात यह नहीं है कि उन्होंने "एक सुंदर ज्ञान डेटाबेस बनाया।"

यह है कि वह काम के दौरान सीखने को रिकॉर्ड करती हैं और इसे सार्वजनिक साझाकरण, स्पष्टीकरण और प्रस्तुतियों के लिए पुन: उपयोग करती हैं।

वह सीखने के नोट्स को व्यक्तिगत रिकॉर्ड से आगे बढ़ाकर इसमें प्रवाहित करती हैं:

• प्रस्तुतियाँ
• लेख
• वीडियो
• दस्तावेज़
• शैक्षिक सामग्री
• अगली नौकरी

"इनपुट से आउटपुट में यह रूपांतरण" ज्ञान का आर्थिक मूल्य बनाता है।

3. Bruno Paz—स्थानीय, Markdown, न्यूनतम प्लगइन्स

सॉफ्टवेयर इंजीनियर Bruno Paz कोड स्निपेट्स, मीटिंग्स, प्रोजेक्ट स्पेक्स से लेकर शोध और जीवन ज्ञान तक सब कुछ Obsidian में एकत्रित करता है।

हालाँकि, सब कुछ Obsidian में डालने से भी अधिक महत्वपूर्ण उनका डिज़ाइन दर्शन है।

वह Markdown की पोर्टेबिलिटी और Git के माध्यम से इतिहास प्रबंधन पर जोर देते हैं, प्लगइन्स की संख्या न्यूनतम रखने की नीति अपनाते हैं। प्लगइन्स Obsidian को सुविधाजनक बनाते हैं, लेकिन सामग्री स्वयं विशिष्ट प्लगइन्स पर बहुत अधिक निर्भर नहीं होनी चाहिए।

वह type जैसे Frontmatter को टेम्पलेट्स के साथ मानकीकृत करते हैं, संबंधित नोट्स के Wikilinks को topics में डालते हैं, और उन्हें Bases या Dataview के साथ सूचीबद्ध करते हैं।

यहाँ निष्कर्ष स्पष्ट है:

उच्च-कार्यक्षम होने से अधिक महत्वपूर्ण है कि जब चीज़ें टूट जाएँ तो सिर्फ Markdown के साथ पुनर्प्राप्त करने में सक्षम होना।

4. Ian O'Byrne—जानकारी को "उपभोग → क्यूरेट → निर्माण" से प्रवाहित करना

Ian O'Byrne, जो शिक्षा और शोध में Obsidian का उपयोग करते हैं, अपने Vault को मोटे तौर पर इस प्रवाह में संरचित करते हैं:

• उपभोग: लेख, किताबें, पेपर, पॉडकास्ट जैसे इनपुट
• क्यूरेट: मुख्य बिंदुओं को निकालना, उन्हें संबंधित करना, MOCs बनाना
• निर्माण: ब्लॉग, न्यूज़लेटर, शिक्षण सामग्री जैसे आउटपुट
• मेटा: Vault के संचालन के लिए जानकारी

मायने रखता है फ़ोल्डर के नाम नहीं।

यह वह संरचना है जहाँ जानकारी इनपुट से अर्थ निर्माण के माध्यम से आउटपुट की ओर बढ़ती है। वह बताते हैं कि प्रक्रिया प्लेटफ़ॉर्म से अधिक महत्वपूर्ण है और Vault आवश्यकतानुसार विकसित होता है।

इन विदेशी मामलों को सारांशित करते हुए, उत्कृष्ट Vaults में पाँच समानताएँ हैं:

1. पुनर्प्राप्ति-पहले—भविष्य की खोजों से पीछे की ओर काम करें
2. आउटपुट-केंद्रित—सिर्फ भंडारण नहीं, बल्कि प्रस्तुतियों की ओर प्रवाहित करें
3. स्थानीय-पहले—Markdown को सत्य के स्रोत के रूप में उपयोग करें
4. न्यूनतम स्कीमा—इनपुट फ़ील्ड को जटिल न बनाएँ
5. विकासशील—उपयोग करते समय संरचना बदलें

अध्याय 2: "10 करोड़ रुपये के Vault" को परिभाषित करने वाले छह मीट्रिक

नोट्स की संख्या, लिंक की संख्या और ग्राफ़ की सुंदरता आवश्यक प्रदर्शन मीट्रिक नहीं हैं।

मैं Vault प्रदर्शन को इन छह मीट्रिक से मापूंगा:

1. कैप्चर विलंबता

विचार आने से लेकर उसे सहेजने तक का समय।

लक्ष्य 30 सेकंड के भीतर है। एक संरचना जो आपको इनपुट के समय टैग, संबंधित नोट्स और सहेजने के स्थानों के बारे में सोचने के लिए मजबूर करती है, कमजोर है।

2. पुनर्प्राप्ति समय

आवश्यक जानकारी तक पहुँचने में लगने वाला समय।

सामान्य जानकारी के लिए 30 सेकंड के भीतर और महत्वपूर्ण निर्णय रिकॉर्ड के लिए 60 सेकंड के भीतर लक्ष्य रखें।

3. संदर्भ पुनर्निर्माण लागत

पुराने नोट्स को देखते समय यह पुनर्स्थापित करने का समय कि कोई कहानी किस बारे में थी।

सिर्फ मीटिंग शीर्षक वाला नोट कमजोर है। वह नोट जो "पृष्ठभूमि," "निर्णय," "कारण," "पूर्वधारणा," और "अगली कार्रवाई" को संरक्षित करता है, मजबूत है।

4. निर्णय ट्रेसबिलिटी

महत्वपूर्ण निर्णयों का प्रतिशत जहाँ आप बाद में ट्रैक कर सकते हैं:

• यह क्यों तय किया गया
• क्या अस्वीकार किया गया
• क्या पूर्वधारणाएँ मौजूद थीं
• कौन सी शर्तें उलटने को ट्रिगर करेंगी

5. आउटपुट रूपांतरण दर

संग्रहीत स्रोत नोट्स या एवरग्रीन नोट्स का प्रतिशत जो लेख, प्रस्ताव, उत्पाद, निर्णय, मीटिंग या बिक्री गतिविधियों के लिए पुन: उपयोग किए गए।

6. एजेंट निष्पादन क्षमता

वह प्रतिशत जो Claude या Codex Vault के नियमों को गलत समझे बिना खोज, प्रस्ताव और सत्यापन कर सकता है।

इन्हें सारांशित करते हुए, ज्ञान प्रणाली के ROI को इस प्रकार सोचा जा सकता है:

ज्ञान ROI = (पुन: उपयोग किया गया ज्ञान + बेहतर निर्णय + टाली गई विफलताएँ) / रिकॉर्डिंग, संगठन और रखरखाव पर खर्च किया गया समय

भले ही नोट्स की संख्या बढ़ जाए, यदि उनका पुन: उपयोग नहीं किया जाता, तो केवल हर बढ़ रहा है।

अध्याय 3: जापानी उपयोगकर्ताओं के लिए आसान Vault संरचना

यदि मैं शुरू से निर्माण कर रहा होता, तो मैं इस शीर्ष-स्तरीय संरचना का उपयोग करता:

MyVault/

├── 00_Inbox/

│ ├── AI/

│ └── Clippings/

├── 10_Daily/

│ └── 2026/

├── 20_Projects/

├── 30_Areas/

├── 40_Notes/

│ └── MOCs/

├── 50_Sources/

├── 60_Entities/

│ ├── People/

│ ├── Companies/

│ └── Products/

├── 70_Outputs/

│ ├── Drafts/

│ └── Published/

├── 80_Assets/

├── 90_System/

│ ├── Templates/

│ ├── Bases/

│ ├── Schemas/

│ ├── AgentSkills/

│ └── AI/

├── 99_Archive/

├── scripts/

├── .claude/

├── .agents/

├── .codex/

├── CLAUDE.md

└── AGENTS.md

00_Inbox

अवर्गीकृत इनपुट। यहाँ व्यवस्थित न करें। टैग आमतौर पर अनावश्यक हैं। यह "सिर्फ सहेजने" के लिए एक स्थान है।

10_Daily

कालानुक्रमिक कार्य लॉग। मेमो, बातचीत, अहसास और प्रगति छोड़ें जो स्वतंत्र नोट्स बनाने लायक नहीं हैं।

20_Projects

पूर्णता की शर्त वाली गतिविधियाँ। "बिक्री बढ़ाना" एक Area या लक्ष्य है, लेकिन "सितंबर 2026 तक कॉर्पोरेट योजना मूल्य निर्धारण में संशोधन" एक प्रोजेक्ट है। प्रोजेक्ट्स में हमेशा एक next_action होना चाहिए।

30_Areas

जिम्मेदारी के चल रहे क्षेत्र। प्रबंधन, बिक्री, भर्ती, वित्त, स्वास्थ्य, परिवार, सीखना, आदि। प्रोजेक्ट पूरा होने के बाद भी Areas बने रहते हैं।

40_Notes

दीर्घकालिक पुन: उपयोग के लिए ज्ञान। यहाँ सामग्री रखें जिसे आप अपने शब्दों में समझा सकते हैं, सिर्फ उद्धरण नहीं। "एक नोट, एक अवधारणा" का सख्ती से पालन करने की आवश्यकता नहीं है। जापानी में, विषय और पूर्वधारणाएँ आसानी से छोड़ दी जाती हैं, इसलिए अत्यधिक विखंडन संदर्भ को तोड़ता है। मानक है:

1 नोट = वह सामग्री जिसे आप भविष्य में एक इकाई के रूप में पुन: उपयोग करना चाहते हैं

50_Sources

बाहरी जानकारी के रिकॉर्ड। किताबें, पेपर, लेख, वीडियो, मीटिंग सामग्री, शोध डेटा, आदि। "दूसरे पक्ष ने क्या कहा" को "मैंने इसकी व्याख्या कैसे की" से अलग करें।

60_Entities

लोग, कंपनियाँ, उत्पाद, ग्राहक, प्रतियोगी और प्रौद्योगिकियाँ जैसी संस्थाएँ। भले ही वही व्यक्ति या कंपनी कई प्रोजेक्ट्स में दिखाई दे, केवल एक Entity Note रखें।

70_Outputs

लेख, योजना दस्तावेज़, प्रस्ताव, वीडियो स्क्रिप्ट, प्रस्तुतियाँ, बिक्री सामग्री, उत्पाद विनिर्देश, आदि। आउटपुट्स को एक स्वतंत्र शीर्ष-स्तरीय फ़ोल्डर में रखना महत्वपूर्ण है। केवल भंडारण के उद्देश्य वाला Vault ज्ञान का कब्रिस्तान बन जाता है।

90_System

Vault को चलाने वाली तंत्र, जैसे टेम्पलेट्स, Schemas, Bases, AI नियम और Skills। इसे बनाकर, आप अपने स्वयं के संचालन को समझाने में सक्षम हो जाते हैं।

क्या एक Vault होना चाहिए?

सिद्धांत रूप में, हाँ। Obsidian में आंतरिक लिंक एक Vault के भीतर हल किए जाते हैं; Vaults को विभाजित करने से ज्ञान के बीच संबंध टूट जाते हैं। उपर्युक्त अध्ययन में, जिन प्रतिभागियों ने अपने Vault को तीन में विभाजित किया, उन्होंने खोज भ्रम की सूचना दी।

हालाँकि, निम्नलिखित को भौतिक रूप से अलग करें:

• ऐसी जानकारी जहाँ अनुबंध द्वारा बाहरी AI इनपुट निषिद्ध है।
• चिकित्सा, व्यक्तिगत पहचान संख्या, क्रेडेंशियल।
• अत्यधिक संवेदनशील HR जानकारी।
• विनियमित डेटा।
• ऐसी जानकारी जो संगठनात्मक नीति के अनुसार बाहरी मॉडलों को नहीं दी जा सकती।

इसे "व्यक्तिगत Vault" और "विनियमित Vault" के रूप में अलग करने के बारे में सोचें।

अध्याय 4: फ़ोल्डर, Properties, Links और Tags की भूमिकाओं को न मिलाएँ

Obsidian सिस्टम के टूटने का सबसे बड़ा कारण एक साथ फ़ोल्डर, टैग, Properties और लिंक का उपयोग करके एक ही वर्गीकरण को व्यक्त करना है। उनकी भूमिकाओं को इस प्रकार तय करें:

फ़ोल्डर "जीवनचक्र" के लिए हैं

Inbox, Project, Source, Output, Archive, आदि। वे दर्शाते हैं कि कोई नोट वर्तमान में प्रक्रिया के किस चरण में है।

Properties "मशीन-संभाले जाने वाले प्रकार और स्थितियों" के लिए हैं

type, status, created, project, revisit, आदि। Obsidian Properties YAML के रूप में सहेजे जाते हैं और इनमें text, list, number, checkbox, date, datetime और tags जैसे प्रकार हो सकते हैं।

लिंक "अर्थ संबंधी संबंधों" के लिए हैं

[[Pricing Strategy]], [[ABC Corp]], [[Reversibility of Decisions]], आदि। किसी विषय को टैग के बजाय नोट बनाने से उस विषय में स्वयं स्पष्टीकरण, प्रतिप्रमाण, संदर्भ सामग्री और MOCs रखे जा सकते हैं।

टैग "अस्थायी क्रॉस-कटिंग स्थितियों" के लिए हैं

टैग को #review, #waiting, #question, #contradiction, #publish जैसी चीज़ों तक सीमित रखें।

जब भी संभव हो, "मार्केटिंग" या "AI" जैसी अवधारणाएँ लिंक होनी चाहिए। टैग को अवधारणा शब्दकोश के रूप में उपयोग करने से टैग प्रसार होता है (जैसे, #AI, #ArtificialIntelligence, #GenerativeAI)। इसके बजाय, अवधारणा नोट्स में Aliases का उपयोग करें।

अध्याय 5: न्यूनतम Property Schema

शुरू से 20 आइटम भरने की कोशिश न करें। Schema को तीन चरणों में विभाजित करें:

कैप्चर चरण

केवल आवश्यक:
``yaml
type: inbox
created: 2026-07-24
status: inbox
``

प्रमोटेड चरण

जब यह दीर्घकालिक भंडारण के लिए मूल्य प्राप्त करे तो जोड़ें:
``yaml
type: नोट
created: 2026-07-24
status: सक्रिय
topics:
- "[[Pricing Strategy]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC प्रतियोगी मूल्य निर्धारण शोध 2026-07]]"
confidence: मध्यम
sensitivity: आंतरिक
``

संचालन चरण

प्रोजेक्ट्स या निर्णयों के लिए आवश्यक आइटम जोड़ें:
``yaml
type: प्रोजेक्ट
created: 2026-07-24
status: सक्रिय
owner: मैं
area: "[[प्रबंधन]]"
due: 2026-09-30
next_action: 5 प्रतियोगियों की वार्षिक योजनाओं की तुलना करें
``

अध्याय 6: जापानी फ़ाइल नामों के लिए नियम

जापानी बॉडी टेक्स्ट या शीर्षकों को अंग्रेजी में बदलने के लिए मजबूर करने की आवश्यकता नहीं है। हालाँकि, मशीन प्रसंस्करण के लिए उपयोग किए जाने वाले Property नाम और फ़ोल्डर नाम ASCII में रखें। मैं इन नामकरण परंपराओं का उपयोग करता हूँ:

• प्रोजेक्ट: PJT कॉर्पोरेट मूल्य निर्धारण का पुनः डिज़ाइन
• निर्णय: DEC 2026-07-24 वार्षिक योजना को मानक प्रस्ताव बनाएँ
• एवरग्रीन नोट: मूल्य सुविधा गणना के बजाय कार्यान्वयन विफलता जोखिम द्वारा निर्धारित होता है

एवरग्रीन नोट शीर्षकों को "श्रेणी नाम" के बजाय "दावे" बनाएँ। दावेदार शीर्षक आपको केवल खोज परिणामों से सामग्री याद रखने में मदद करते हैं।

अध्याय 7: वास्तव में शामिल करने के लिए टेम्पलेट्स

दैनिक नोट

एक "फ्रिक्शन लॉग" शामिल करें। "मैंने क्या खोजा लेकिन नहीं मिला" रिकॉर्ड करने से आप वास्तविक खोज विफलताओं के आधार पर Vault में सुधार कर सकते हैं। संरचना को सौंदर्य प्राथमिकता से नहीं, बल्कि असफल खोजों से विकसित करें।

प्रोजेक्ट नोट

एक प्रोजेक्ट नोट कार्यों का गोदाम नहीं है। यह प्रोजेक्ट कमांड सेंटर है जहाँ कोई भी 30 सेकंड में वर्तमान स्थिति समझ सकता है।

निर्णय नोट

उच्च-लाभ वाले काम में, निर्णयों की गुणवत्ता जानकारी से अधिक महत्वपूर्ण है। इस प्रकार, निर्णय नोट सबसे मूल्यवान नोट प्रकार है। सबसे महत्वपूर्ण फ़ील्ड रिवर्सल ट्रिगर है। एक उत्कृष्ट निर्णय निर्माता वह है जो निर्णय के समय लिख सकता है कि वे किन शर्तों के तहत अपना मन बदलेंगे।

अध्याय 8: MOCs "लिंक सूचियाँ" नहीं, बल्कि "संपादित विचार मॉडल" हैं

एक अच्छे MOC (Map of Content) में संपादक का निर्णय होता है। यह एक संपादित संज्ञानात्मक मॉडल है जो संपूर्ण क्षेत्र की आपकी वर्तमान समझ को संपीड़ित करता है, न कि केवल संबंधित नोट्स की सूची।

अध्याय 9: Bases के साथ "प्रबंधन डैशबोर्ड" बनाना

Obsidian Bases एक मुख्य विशेषता है जो आपको नोट Properties को डेटाबेस की तरह प्रदर्शित, फ़िल्टर और सॉर्ट करने की अनुमति देती है। इसका उपयोग "सक्रिय प्रोजेक्ट्स Base" या "निर्णय समीक्षा Base" बनाने के लिए करें ताकि लंबित निर्णयों को पुनर्प्राप्त किया जा सके।

अध्याय 10: स्तरीकृत प्लगइन्स

• स्तर 0 (केवल कोर): Properties, Templates, Daily Notes, Bases, Search, Canvas, आदि।
• स्तर 1 (जब घर्षण उत्पन्न हो): QuickAdd, Templater, Tasks।
• स्तर 2 (केवल यदि Bases पर्याप्त नहीं है): Dataview।

सक्रिय कम्युनिटी प्लगइन्स को 12 या उससे कम रखें। प्रत्येक के लिए उद्देश्य, विकल्प और हटाने की शर्तें रिकॉर्ड करें।

अध्याय 11: 2026 में निर्णायक परिवर्तन—आधिकारिक Obsidian CLI

जुलाई 2026 तक, Obsidian के पास एक आधिकारिक CLI है। यह आपको टर्मिनल से डेस्कटॉप संस्करण संचालित करने की अनुमति देता है: खोजना, पढ़ना, बनाना, Properties अपडेट करना और कार्यों की जाँच करना। यह Claude और Codex को सीधे Markdown संपादित करने के बजाय Obsidian के स्वयं के रिज़ॉल्यूशन लॉजिक का उपयोग करके संचालित करने की अनुमति देता है।

अध्याय 12: AI-नेटिव Vault के लिए सही संरचना

AI को सभी नोट्स को स्वतंत्र रूप से संपादित करने देना "AI उपयोग" नहीं है। यह एक अप्रशिक्षित इंटर्न को सभी कंपनी दस्तावेज़ सौंपने जैसा है। सही श्रम विभाजन है:

• मानव: लक्ष्य, मूल्य निर्णय, अंतिम अनुमोदन, MOC संपादन।
• Obsidian: सत्य का स्रोत, संबंध, इतिहास, दृश्य।
• Claude: अर्थ निकालना, तुलना, प्रतितर्क, मसौदा तैयार करना।
• Codex: संरचनात्मक परिवर्तन, स्क्रिप्ट, सत्यापन, diff समीक्षाएँ।
• Git: पुनर्प्राप्ति, ऑडिटिंग, प्रयोगों का अलगाव।
• Validator: Schema उल्लंघनों और लिंक विसंगतियों का पता लगाना।

अध्याय 13: CLAUDE.md और AGENTS.md रखना

Claude Code निरंतर निर्देशों के रूप में CLAUDE.md पढ़ता है। Codex AGENTS.md खोजता है। इन फ़ाइलों में एक "Vault संचालन अनुबंध" रखें जो भाषा (जापानी गद्य, ASCII Properties), सुरक्षा नियम (डिफ़ॉल्ट रूप से dry-run) और Schema नियमों को परिभाषित करता है।

अध्याय 14: Obsidian Tasks को Claude के माध्यम से Skills में बदलना

उन कार्यों के लिए "एजेंट स्किल्स" परिभाषित करें जो आप तीन बार से अधिक करते हैं या मानकीकृत गुणवत्ता के लिए। उदाहरण के लिए, एक obsidian-distill कौशल कच्चे मीटिंग नोट्स को निर्णयों, कार्यों और एवरग्रीन नोट्स में परिवर्तित कर सकता है। एक अच्छा कौशल स्पष्ट इनपुट, प्रक्रियाओं, निषेधों और पूर्णता शर्तों के साथ एक पुन: निष्पादन योग्य कार्य मानक है।

अध्याय 17: Claude, Codex और Obsidian CLI के लिए सहयोग पैटर्न

• पैटर्न 1: मीटिंग नोट डिस्टिलेशन (Claude निर्णय/कार्य निकालता है)।
• पैटर्न 2: साप्ताहिक प्रबंधन समीक्षा (Claude सप्ताह की प्रगति और अटके प्रोजेक्ट्स का सारांश देता है)।
• पैटर्न 3: Schema ड्रिफ्ट ऑडिट (Codex Property असंगतियों का पता लगाता है)।
• पैटर्न 4: निर्णय पूर्वधारणा ऑडिट (Claude जाँचता है कि क्या पिछले निर्णयों के पीछे की धारणाएँ अभी भी सही हैं)।

यह "AI के साथ नोट्स को सारांशित करने" से परे उपयोग है। आप AI को एक बौद्धिक नियंत्रक के रूप में उपयोग करते हैं जो आपके पिछले निर्णयों का ऑडिट करता है।

अध्याय 18: एक Vault Validator शामिल करना

यदि AI आपके Vault को संपादित कर रहा है, तो केवल "यह ठीक लगता है" से संतुष्ट न हों। स्क्रिप्ट (जैसे, vault_check.py) के माध्यम से न्यूनतम स्थैतिक परीक्षण लागू करें ताकि अनुमत प्रकार, स्थितियाँ और आवश्यक Properties सत्यापित हो सकें।