AI कार्यप्रवाह

यह प्रोजेक्ट Claude Code के साथ बनाया गया था। अधिकांश “AI से बनाया” दावे लेबल पर ही रुक जाते हैं। यहाँ पूरी तस्वीर है: AI को क्या पता है, सत्र कैसे काम करते हैं, प्रॉम्प्टिंग व्यवहार में कैसी दिखती है, और मानव कहाँ अपनी सीमा खींचता है। अगर आप स्वयं AI के साथ कुछ बना रहे हैं, या बस उत्सुक हैं कि यह वास्तव में कैसा दिखता है, तो यह आपके लिए है।

AI को क्या पता है

Claude Code के पास एक स्थायी मेमोरी फ़ाइल है जो सत्रों के बीच संदर्भ बनाए रखती है। हर बातचीत में कोडबेस को दोबारा खंगालने के बजाय, यह वहीं से शुरू करता है जहाँ हमने छोड़ा था। यहाँ इसमें क्या है (संवेदनशील जानकारी हटाकर):

प्रोजेक्ट पहचान

• ऐप का नाम, स्रोत स्थान, लाइसेंस, ऐप पहचानकर्ता
• फ़ोर्क संबंध: अपस्ट्रीम Francisco Salgueiro का En Croissant है, हम अपना फ़ोर्क स्वतंत्र रूप से बनाए रखते हैं
• फ़ोर्क क्यों बनाया: अपस्ट्रीम मेंटेनर ने TTS सुविधा को अस्वीकार कर दिया, जो उचित था — एक ही प्रोजेक्ट के लिए अलग-अलग दृष्टिकोण

बिल्ड नियम

• केवल pnpm — npm vanillaExtract को तोड़ देता है (रनटाइम पर सफ़ेद स्क्रीन, कोई त्रुटि नहीं, बस कुछ नहीं)
• Node.js 22+ आवश्यक (Vite 7 को crypto.hash चाहिए)
• कमिट करने से पहले हमेशा pnpm format && pnpm lint:fix
• बाइनरी को ओवरराइट करने से पहले ऐप बंद करें (“Text file busy”)
• स्रोत डायरेक्टरी स्थानांतरित करने के बाद, पुराने पथ संदर्भों को साफ़ करने के लिए cargo clean

आर्किटेक्चर ज्ञान

• कौन सी फ़ाइलें किन सुविधाओं की मालिक हैं (atoms.ts में atoms, tree.ts में tree navigation, tts.ts में TTS इंजन)
• सभी TTS atoms को getOnInit: true क्यों चाहिए (React सब्सक्राइब करने से पहले store.get() द्वारा इम्पेरेटिव रीड्स)
• ऑडियो कैश कैसे काम करता है (provider:voiceId:lang:text कुंजियाँ)
• chessground कोऑर्डिनेट फ़िक्स CSS-साइड है, लाइब्रेरी का फ़ोर्क नहीं
• डेटा लेआउट: क्या कहाँ है, क्या सिमलिंक किया गया है, क्या ऐप रीस्टार्ट के बाद भी बना रहता है

जो इसे नहीं पता

मेमोरी में API कुंजियाँ, पासवर्ड या क्रेडेंशियल नहीं हैं। यह उनके भंडारण स्थानों (localStorage atom नाम) का संदर्भ देती है लेकिन कभी मान नहीं। AI ऐसा कोड बनाता है जो सेटिंग्स से कुंजियाँ पढ़ता है — यह कभी वास्तविक गोपनीय जानकारी नहीं देखता या संभालता।

AI को क्या बताया जाता है

मेमोरी फ़ाइल के अलावा, Claude Code अपने सिस्टम में बेक किए गए नियमों का पालन करता है:

• ओवर-इंजीनियरिंग मत करो। केवल वही बदलाव करो जो सीधे माँगे गए हैं। एक बग फ़िक्स के लिए आसपास के कोड को साफ़ करने की ज़रूरत नहीं। कोड की तीन समान पंक्तियाँ एक समय-पूर्व अमूर्तन (premature abstraction) से बेहतर हैं।
• URL का अनुमान मत लगाओ। कभी भी लिंक या एंडपॉइंट गढ़ो मत।
• संपादित करने से पहले पढ़ो। कभी भी ऐसे कोड में बदलाव प्रस्तावित मत करो जो पढ़ा नहीं गया।
• नया बनाने से बेहतर मौजूदा संपादित करो। जब तक बिल्कुल ज़रूरी न हो, नई फ़ाइलें मत बनाओ।
• कोई सुरक्षा कमज़ोरियाँ नहीं। इंजेक्शन, XSS, और OWASP शीर्ष 10 मुद्दों पर नज़र रखो।
• अनिश्चित होने पर पूछो। अगर कोई निर्देश अस्पष्ट है, तो अनुमान लगाने के बजाय पूछो।
• दो बार नापो, एक बार काटो। विनाशकारी ऑपरेशन (force push, reset —hard, फ़ाइलें हटाना) के लिए स्पष्ट मानवीय अनुमोदन आवश्यक है।

अच्छे प्रॉम्प्ट लिखना

एक उपयोगी AI इंटरैक्शन और एक निराशाजनक इंटरैक्शन के बीच का अंतर लगभग हमेशा प्रॉम्प्ट होता है।

आप क्या चाहते हैं, विशिष्ट रहें। “बग ठीक करो” नहीं बल्कि “TTS कैश कुंजी में प्रोवाइडर नाम शामिल नहीं है, इसलिए ElevenLabs से Google पर स्विच करने पर नया ऑडियो जनरेट करने के बजाय कैश किया हुआ ElevenLabs ऑडियो बजता है।”

वह संदर्भ शामिल करें जो AI के पास नहीं है। AI आपका कोड पढ़ सकता है, लेकिन आपका मन नहीं। “उपयोगकर्ता ने बताया कि बोर्ड पर निर्देशांक उल्टे हैं” उतना उपयोगी नहीं जितना “chessgroundBaseOverride.css में CSS में रैंक और फ़ाइलें अदला-बदली हैं — Francisco के मूल में ये उल्टी थीं।”

अपनी बाधाएँ बताएँ। “नई फ़ाइलें मत बनाओ” या “मौजूदा atom पैटर्न का उपयोग करो” या “यह बिना API कुंजी के काम करना चाहिए” AI को बताता है कि सुरक्षा सीमाएँ कहाँ हैं।

बताएँ कि आप क्या नहीं चाहते। “उन मामलों के लिए त्रुटि हैंडलिंग मत जोड़ो जो हो ही नहीं सकते” या “आसपास के कोड को रीफ़ैक्टर मत करो” ओवर-इंजीनियरिंग से बचाता है — AI की सबसे आम विफलता का तरीका।

पैटर्न यह है: इरादा + संदर्भ + बाधाएँ। इसमें महारत हासिल करें और AI नाटकीय रूप से अधिक उपयोगी हो जाता है।

प्लान मोड: एक Claude का उपयोग दूसरे Claude को प्रॉम्प्ट करने के लिए

Claude Code में एक “प्लान मोड” है जो सोचने को करने से अलग करता है। प्लान मोड में, AI फ़ाइलें पढ़ता है, कोडबेस की खोज करता है, और एक योजना तैयार करता है — लेकिन कोई कोड नहीं लिखता। आप योजना की समीक्षा करते हैं, उसे समायोजित करते हैं, फिर कार्यान्वयन मोड में स्विच करते हैं जहाँ AI उसे निष्पादित करता है।

यह काम क्यों करता है? क्योंकि किसी भी कोडिंग कार्य का सबसे कठिन हिस्सा कोड लिखना नहीं है। यह पता लगाना है कि कौन सा कोड लिखना है — कौन सी फ़ाइलें बदलनी हैं, कौन से पैटर्न अपनाने हैं, कौन से एज केस मौजूद हैं। प्लान मोड एक भी पंक्ति लिखे जाने से पहले पूरा ध्यान उस प्रश्न पर लगाता है।

इस प्रोजेक्ट से एक उदाहरण: जब हमने Help मेनू को भाषा चयनकर्ता जोड़ने के लिए पुनर्गठित किया, तो प्लान मोड वार्तालाप ने यह जाना कि Tauri मेनू कैसे काम करते हैं, कौन से atoms पहले से मौजूद थे, डॉक व्यूअर रिसोर्स पथों को कैसे हल करता था, और कन्फ़र्मेशन डायलॉग API कैसा दिखता था। जब तक हमने कार्यान्वयन पर स्विच किया, AI के पास बदलावों का पूरा नक्शा था। कोई गलत शुरुआत नहीं।

आप अनिवार्य रूप से AI के एक इंस्टेंस का उपयोग वरिष्ठ आर्किटेक्ट के रूप में और दूसरे का डेवलपर के रूप में कर रहे हैं। वही मॉडल, अलग-अलग भूमिकाएँ।

सत्र कैसे काम करते हैं

एक सामान्य सत्र इस तरह दिखता है:

1. मानव इरादा बताता है। “KittenTTS अनुभाग में कैशिंग नोट जोड़ो।” “PostHog टेलीमेट्री हटाओ।” “गुणवत्ता रेटिंग गलत हैं, ये रहा सही।”

2. AI संबंधित फ़ाइलें पढ़ता है। यह अनुमान नहीं लगाता कि फ़ाइल में क्या है। यह पढ़ता है, वर्तमान स्थिति समझता है, फिर बदलाव प्रस्तावित करता है। जब फ़ाइलें स्वतंत्र होती हैं तो एक साथ कई फ़ाइलें पढ़ी जाती हैं।

3. AI बदलाव करता है। मौजूदा फ़ाइलों में लक्षित संपादन। पूरे पुनर्लेखन नहीं — सर्जिकल संशोधन जो आसपास की हर चीज़ को सुरक्षित रखते हैं।

4. मानव समीक्षा करता है। हर संपादन डिस्क पर जाने से पहले दिखाया जाता है। मानव स्वीकृत करता है, अस्वीकृत करता है, या दिशा बदलता है। “नहीं, यह बहुत नरम है — कहो कि यह सचमुच बेकार है।” “वह पैराग्राफ़ ऊपर ले जाओ।” “मेरा यह मतलब नहीं था।”

5. बताए जाने पर कमिट। AI कभी अपनी पहल पर कमिट नहीं करता। मानव कहता है “commit” या “commit and push”। कमिट में Co-Authored-By: Claude Opus 4.6 शामिल होता है — हमेशा श्रेय दिया जाता है, कभी छिपाया नहीं जाता।

कॉन्टेक्स्ट विंडो और सेव स्टेट्स

हर AI वार्तालाप की एक कॉन्टेक्स्ट विंडो होती है — कुल पाठ की मात्रा जो यह एक बार में मेमोरी में रख सकता है। जब बातचीत काफ़ी लंबी हो जाती है, तो जगह बनाने के लिए पुराने संदेशों को संपीड़ित किया जाता है।

दो रणनीतियाँ: बातचीत को केंद्रित रखें (प्रति बातचीत एक कार्य), और सेव स्टेट्स का उपयोग करें (Claude Code ट्रांसक्रिप्ट को JSONL फ़ाइलों के रूप में सहेजता है जिन्हें पूर्ण संदर्भ बहाल करके फिर से शुरू किया जा सकता है)। मेमोरी फ़ाइल एक अलग उद्देश्य पूरा करती है — यह एक स्थायी ज्ञान आधार है जो सभी वार्तालापों के बीच बना रहता है।

AI क्या प्रस्तावित करता है बनाम क्या शिप होता है

AI का पहला सुझाव शायद ही कभी अंतिम संस्करण होता है। एक सामान्य आदान-प्रदान:

• AI कुछ उचित लिखता है
• मानव कहता है “बहुत कॉर्पोरेट” या “ज़्यादा सीधे बोलो” या “यह गलत है, यह रहा कारण”
• AI समायोजित करता है
• मानव स्वीकृति देता है

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

स्किल्स और स्लैश कमांड

Claude Code “स्किल्स” का समर्थन करता है — .claude/commands/ डायरेक्टरी में मार्कडाउन फ़ाइलों के रूप में संग्रहीत पुन: प्रयोज्य प्रॉम्प्ट। आप इन्हें /translate-docs जैसे स्लैश कमांड से चालू करते हैं।

यह प्रोजेक्ट /translate-docs स्किल का उपयोग करता है जो दस्तावेज़ीकरण को कई भाषाओं में अनुवाद करने को स्वचालित करती है। स्किल फ़ाइल में पूर्ण निर्देश होते हैं: कौन सी फ़ाइलें अनुवाद करनी हैं, कौन सा प्रारूप उपयोग करना है, कोड ब्लॉक और लिंक कैसे संभालने हैं, कौन सा स्वर बनाए रखना है। हर बार यह सब समझाने के बजाय, आप बस /translate-docs टाइप करते हैं और AI को ठीक-ठीक पता होता है क्या करना है।

स्किल्स प्रक्रिया को एन्कोड करती हैं, केवल जानकारी को नहीं। आप इन्हें किसी भी बार-बार होने वाले कार्यप्रवाह के लिए बना सकते हैं: टेस्ट चलाना, डिप्लॉय करना, PR की समीक्षा करना, चेंजलॉग अपडेट करना।

कोडिंग सिद्धांत

पूर्ण सिद्धांत दस्तावेज़ रिपो में .claude/01_UNIVERSAL_PRINCIPLES.md पर उपलब्ध है। यह Robert C. Martin की Clean Code (2008) से शुरू हुआ जिसमें AI युग के लिए अतिरिक्त बातें जोड़ी गईं। फिर हमने एक ईमानदार बातचीत की कि क्या अभी भी प्रासंगिक है और क्या नहीं।

जो कालातीत है

• इरादा प्रकट करने वाले नाम। हमेशा। सदा के लिए।
• फ़ंक्शन एक काम करें। असली सिद्धांत सुसंगतता है, आकार नहीं।
• कोई साइड इफ़ेक्ट नहीं। अभी भी अधिकांश बग्स का स्रोत।
• टिप्पणियाँ ‘क्यों’ समझाएँ, ‘क्या’ नहीं।
• एकल उत्तरदायित्व। एक मॉड्यूल को बदलने का एक ही कारण होना चाहिए।
• इंटरफ़ेस के लिए प्रोग्राम करो, कार्यान्वयन के लिए नहीं।
• त्रुटियाँ निगलो मत। हर त्रुटि जानकारी है।
• उभरता हुआ डिज़ाइन: सभी टेस्ट पास करे, कोई दोहराव नहीं, इरादा व्यक्त करे, जटिलता न्यूनतम करे। इसी क्रम में।

जो संदर्भ-निर्भर है

ये सिद्धांत ठोस हैं, लेकिन विशिष्ट नियम AI-पूर्व या भाषा-विशिष्ट दुनिया को दर्शाते हैं। हम भावना का पालन करते हैं, शाब्दिक नियम का नहीं:

• DRY. जो दोहराव अलग-अलग दिशाओं में बदलता है वह खतरनाक है। लेकिन हर दोहराए जाने वाले पैटर्न को अमूर्तन में निकालना ऐसा अप्रत्यक्षता पैदा करता है जो और बुरा हो सकता है। कभी-कभी यहीं तीन पठनीय पंक्तियाँ किसी दूसरी फ़ाइल में समय-पूर्व अमूर्तन से बेहतर हैं।
• सख्त TDD अनुष्ठान। सिद्धांत — परीक्षित कोड शिप करो, जानो कि यह काम करता है — अपरिहार्य है। अनुष्ठान — कोड से पहले टेस्ट लिखो — एक ऐसे कार्यप्रवाह के लिए डिज़ाइन किया गया था जहाँ मनुष्य धीरे टाइप करते हैं। टेस्ट लिखो। सुनिश्चित करो कि वे पास हों। टेस्ट पहले आया या कोड, यह उतना महत्वपूर्ण नहीं जितना कि दोनों मौजूद हों।
• बॉय स्काउट नियम। “कैम्पग्राउंड को साफ़ छोड़ो” — हाँ। लेकिन बॉय स्काउट ने कैम्पसाइट साफ़ किया, पूरा जंगल नहीं। जो छुओ उसे ठीक करो। एक पंक्ति बदलने के कारण पूरी फ़ाइल की संरचना मत बदलो।

AI-युग के अतिरिक्त सिद्धांत

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

मानव कहाँ सीमा खींचता है

AI एक उपकरण है। एक उल्लेखनीय रूप से अच्छा उपकरण। लेकिन कुछ चीज़ें हैं जो यह नहीं करता:

• उत्पाद निर्णय। कौन सी सुविधाएँ बनानी हैं, क्या हटाना है, ऐप कैसा महसूस होना चाहिए। “System TTS गुणवत्ता रेटिंग में ‘ठीक-ठाक’ लिखो क्योंकि यह सचमुच बेकार है” — यह एक मानवीय निर्णय है जो इसे वास्तव में सुनने पर आधारित है।
• अभिरुचि। AI साफ़ गद्य लिख सकता है, लेकिन प्रोजेक्ट की आवाज़, गुणवत्ता के बारे में स्पष्टवादी होने का निर्णय, Francisco को प्रमुखता से श्रेय देने का विकल्प — ये मानवीय चुनाव हैं।
• नैतिकता। PostHog हटाना एक रीफ़ैक्टरिंग कार्य नहीं था। यह था “सेटिंग्स पेज कहता है कि हम टेलीमेट्री एकत्र नहीं करते, लेकिन कोड में एक सक्रिय PostHog API कुंजी है। यह झूठ है। इसे ठीक करो।” AI ने निष्पादित किया। मानव ने समस्या पहचानी और उसकी परवाह की।
• शतरंज। बोर्ड को आपके टूल्स से कोई मतलब नहीं।

यह क्यों साझा करें

क्योंकि “AI से बनाया” अर्थहीन हो गया है। सब कहते हैं। कोई नहीं दिखाता। दिलचस्प सवाल यह नहीं है कि AI शामिल था या नहीं — बल्कि यह है कि कैसे शामिल था, और मानव ने वास्तव में क्या योगदान दिया।

यह उत्तर है। मानव दृष्टि, अभिरुचि, निर्णय-क्षमता और जवाबदेही लाता है। AI गति, स्मृति, और रात 2 बजे Rust त्रुटि संदेश पढ़ने की अथक इच्छा लाता है।

कोई भी अकेले यह चीज़ नहीं बनाता। दोनों को श्रेय दिया जाता है। यही समझौता है।

---

En Parlant~ En Croissant का एक फ़ोर्क है जो Francisco Salgueiro द्वारा बनाया गया था, और इसे Anthropic के Claude Code के साथ बनाया गया है।