डेवलपर्स के लिए क्रॉस-टूल सर्च: कोडबेस गलत जगह है
डेवलपर के अधिकांश निर्णय कोड के बाहर रहते हैं। Slack, Linear, GitHub और Notion में क्रॉस-टूल सर्च कैसे बनाएं।
By Ellis Keane · 2026-03-17
आपकी कोडबेस किसी निर्णय के कारण की तलाश के लिए सबसे कम उपयोगी जगह है।
मुझे पता है यह उल्टा लगता है। हम ripgrep फ्लैग सीखने, IDE सर्च कॉन्फ़िगर करने, regex पैटर्न याद करने में वर्षों लगाते हैं – और इनमें से कुछ भी मदद नहीं करता जब सवाल यह नहीं होता कि "यह फ़ंक्शन कहाँ है?" बल्कि यह होता है कि "हमने उन तीन विकल्पों पर चर्चा करने के बाद यह तरीका क्यों चुना?" उस दूसरे सवाल का जवाब लगभग कभी कोड में नहीं होता। वह चार महीने पुराने Slack थ्रेड में है, एक Linear कमेंट में जो स्टेटस अपडेट के नीचे दब गया है, एक Notion डॉक में जो किसी ने शुरू किया और कभी पूरा नहीं किया, और एक PR रिव्यू में जहाँ असली बहस एक जवाब के जवाब के जवाब में हुई।
यही डेवलपर्स के लिए क्रॉस-टूल सर्च की समस्या है – निर्णय का संदर्भ बिना एकीकृत क्वेरी पथ के टूल्स में बँटा हुआ है। हमारे पास सर्च है जो प्रत्येक टूल के भीतर अच्छी तरह काम करती है – Slack की सर्च ठीक है, GitHub की कोड सर्च बेहतरीन है, Linear में सब कुछ के लिए फ़िल्टर हैं – लेकिन ऐसा कुछ नहीं है जो इन सबमें सर्च करे। आपकी आर्किटेक्चर को आकार देने वाले निर्णय पाँच अलग जगहों पर रहते हैं, और आपसे यह याद रखने की उम्मीद की जाती है कि कहाँ देखना है।
तो – यहाँ बताया गया है कि जो आपके पास पहले से है उससे क्रॉस-टूल सर्च कैसे बनाएं। कोई नए टूल की ज़रूरत नहीं (खैर, लगभग – मैं बिल्कुल अंत में एक का उल्लेख करूँगा, लेकिन यह उसके बिना भी काम करता है)।
एक बिखरे हुए निर्णय की संरचना
मुझे कुछ ठोस बात करते हैं। पिछले साल, हम अपने जॉब क्यू के लिए BullMQ या Temporal के बीच फैसला कर रहे थे। यह निर्णय वास्तव में यहाँ रहता था:
- Slack (#engineering): दो दिनों में तीन अलग थ्रेड। पहला Temporal ब्लॉग पोस्ट का एक लिंक था जो किसी ने शेयर किया था। दूसरा इस बारे में एक बहस थी कि क्या हमें durable execution की ज़रूरत है। तीसरा (एक हफ्ते बाद, अलग चैनल) कोई था जो पूछ रहा था "रुको, क्या हमने क्यू के बारे में फैसला किया?"
- Linear: "Evaluate job queue options" शीर्षक वाला एक इशू जिसमें छह कमेंट थे, जिनमें एक तुलना तालिका भी थी जिसे हमारे एक इंजीनियर ने एक दोपहर में लिखा था।
- GitHub: BullMQ इम्प्लीमेंटेशन के लिए एक PR डिस्क्रिप्शन जिसमें "as discussed" लिखा था, जिसमें इस बारे में कोई लिंक नहीं था कि यह कहाँ चर्चा हुई थी।
- Notion: एक अधूरा architecture decision record जिसमें Temporal के फायदे शामिल थे लेकिन अंतिम चुनाव के साथ कभी अपडेट नहीं किया गया।
- Google Docs: एक कॉल की मीटिंग नोट्स जहाँ हमने वास्तव में निर्णय लिया, जो दो असंबंधित एजेंडा आइटम के बीच बुलेट पॉइंट में दबी थी।
पाँच टूल। एक निर्णय। और अगर आपने किसी एक टूल में सर्च की होती, तो आपको एक टुकड़ा मिलता – कभी पूरी तस्वीर नहीं। PR बताता है कि हमने क्या चुना। Slack थ्रेड बताते हैं कि हमने क्या विचार किया। Linear इशू ट्रेड-ऑफ बताता है। Notion डॉक आधी तर्क-शक्ति बताता है। मीटिंग नोट्स वह पल बताते हैं जब यह अंतिम रूप दिया गया।
यह असामान्य नहीं है। 2026 में इंजीनियरिंग टीमें निर्णयों को ट्रैक करने के लिए यह किसी तरह से कला की स्थिति है। हमारे पास AI है जो कोड जेनरेट करती है और सर्च इंजन हैं जो पूरे इंटरनेट को इंडेक्स करते हैं, लेकिन यह पता लगाना कि आपकी टीम ने Temporal की बजाय BullMQ क्यों चुना, पाँच ऐप चेक करने और किसी की याददाश्त पर भरोसे की ज़रूरत होती है।
डेवलपर्स के लिए क्रॉस-टूल सर्च को क्या मुश्किल बनाता है
यह API की समस्या नहीं है – हम जो भी टूल इस्तेमाल करते हैं उसमें एक बिल्कुल अच्छी सर्च API है। समस्या इससे भी अजीब है:
अलग-अलग डेटा आकार। Slack टाइमस्टैम्प और चैनल IDs के साथ संदेश लौटाता है। Linear स्टेट और लेबल के साथ इशू लौटाता है। GitHub बिल्कुल अलग रिस्पॉन्स फॉर्मेट में कमिट, PR और कोड मैच लौटाता है। इन्हें एक सुसंगत टाइमलाइन में मर्ज करने के लिए नॉर्मलाइज़ेशन की ज़रूरत होती है जिसे कोई बनाने की तकलीफ नहीं उठाता (क्योंकि, सच कहूँ तो, यह उस तरह का काम है जो स्प्रिंट डेमो में नहीं दिखता)।
कॉन्टेक्स्ट फ्रैगमेंटेशन। एक Slack संदेश जो "ऑप्शन B चुनते हैं" कहता है वह उस थ्रेड के बिना अर्थहीन है जिसने ऑप्शन A, B और C को परिभाषित किया। लेकिन Slack की सर्च अलग-अलग संदेश लौटाती है, बातचीत के आर्क नहीं। आप निष्कर्ष तर्क के बिना पाते हैं।
समय का बहाव। निर्णय प्रक्रिया अक्सर दिनों या हफ्तों तक फैली होती है, जिसमें ऐसे अंतराल होते हैं जहाँ कुछ नहीं हुआ क्योंकि सब अन्य काम में व्यस्त थे। एक कीवर्ड सर्च बातचीत की शुरुआत और अंत दिखा सकती है जबकि महत्वपूर्ण मध्य भाग छूट जाए, बस इसलिए क्योंकि अलग-अलग चरणों में अलग-अलग शब्द इस्तेमाल हुए थे।
डेवलपर्स के लिए क्रॉस-टूल सर्च API की समस्या नहीं है – हर टूल में एक बिल्कुल अच्छा सर्च एंडपॉइंट है। यह कॉन्टेक्स्ट की समस्या है: निर्णय असंगत आकारों में टूल्स में बिखरे हैं, बातचीत के आर्क द्वारा खंडित हैं, और समय के बहाव से अलग हैं। कीवर्ड सर्च टुकड़े खोजती है; केवल जुड़ा हुआ कॉन्टेक्स्ट पूरी तस्वीर खोजता है।
जो आपके पास है उससे क्रॉस-टूल सर्च बनाना
यहाँ व्यावहारिक हिस्सा है। केवल-पढ़ने वाली सर्च के साथ तीन या चार टूल के लिए, MVP वर्शन चलाने में आधा दिन लगने की उम्मीद करें – इसका अधिकांश हिस्सा auth सेटअप और रिस्पॉन्स नॉर्मलाइज़ेशन पर खर्च होगा, सर्च लॉजिक पर नहीं।
API एक्सेस सेट करें
आपको प्रत्येक टूल के लिए टोकन की ज़रूरत होगी:
- Slack:
search:read स्कोप के साथ एक यूज़र टोकन (Slack की सर्च विधियों के लिए यूज़र टोकन चाहिए, बॉट टोकन नहीं – Slack API ऐप्स पेज के माध्यम से बनाएं)
- Linear: सेटिंग्स, फिर API से एक पर्सनल API की
- GitHub: आपके रेपो तक रीड एक्सेस के साथ एक fine-grained PAT
- Notion: सेटिंग्स, फिर कनेक्शन से एक इंटरनल इंटीग्रेशन टोकन
फैन-आउट क्वेरी स्क्रिप्ट
मूल पैटर्न शर्मनाक रूप से सरल है – हर API पर एक ही सर्च क्वेरी फेंकें और परिणाम इकट्ठा करें:
```typescript interface SearchResult { source: 'slack' | 'linear' | 'github' | 'notion'; title: string; snippet: string; url: string; timestamp: Date; }
async function crossToolSearch(query: string): Promise<SearchResult[]> { const results = await Promise.all([ searchSlack(query), searchLinear(query), searchGitHub(query), searchNotion(query), ]);
return results .flat() .sort((a, b) => b.timestamp.getTime() - a.timestamp.getTime()); } ```
प्रत्येक search* फ़ंक्शन संबंधित API को रैप करता है। Slack के लिए, वह search.messages है। Linear के लिए, यह उनके सर्च फ़ील्ड के खिलाफ एक GraphQL क्वेरी है। GitHub के लिए, यह REST सर्च एंडपॉइंट है। Notion के लिए, यह query पैरामीटर के साथ सर्च एंडपॉइंट है।
नॉर्मलाइज़ और डीडुप्लिकेट करें
मुश्किल हिस्सा सर्च नहीं है – परिणामों को उपयोगी बनाना है। आप चाहेंगे:
- टाइमस्टैम्प नॉर्मलाइज़ करें टूल्स में (Slack Unix epochs इस्तेमाल करता है, Linear ISO strings इस्तेमाल करता है, GitHub टाइमज़ोन ऑफसेट के साथ ISO इस्तेमाल करता है)
- संबंधित परिणाम ग्रुप करें – अगर वही Slack थ्रेड तीन बार दिखे क्योंकि तीन संदेश मेल खाए, तो उन्हें थ्रेड URL के साथ एक परिणाम में समेट दें
- प्रासंगिकता के आधार पर रैंक करें – अधिकांश API अपने खुद के प्रासंगिकता स्कोर लौटाती हैं, लेकिन वे टूल्स में तुलनीय नहीं हैं। एक सरल अनुमान: टाइटल में सटीक कीवर्ड मेल बॉडी मेल से ऊपर रैंक करते हैं, और समान प्रासंगिकता पर हाल के परिणाम पुराने से ऊपर रैंक करते हैं
इसे CLI में लपेटें
मैं इसके लिए Commander.js इस्तेमाल करता हूँ (ज़्यादातर आदत से, लेकिन कुछ भी काम करता है):
```bash $ cross-search "bullmq vs temporal"
Found 14 results across 4 tools:
[Slack] #engineering – 2025-11-14 "I've been comparing BullMQ and Temporal for the job queue..." https://myteam.slack.com/archives/C0X.../p17318...
[Linear] ENG-342 – 2025-11-15 "Evaluate job queue options – BullMQ vs Temporal" https://linear.app/myteam/issue/ENG-342
[GitHub] PR #289 – 2025-11-22 "feat: implement BullMQ job queue (as discussed)" https://github.com/myorg/myrepo/pull/289
[Notion] Architecture Decisions – 2025-11-13 "Job Queue Evaluation: Temporal vs BullMQ" https://notion.so/myteam/abc123... ```
चार टूल्स में समय के अनुसार क्रमबद्ध चौदह परिणाम। आप एक ही जगह पर निर्णय का पूरा आर्क देख सकते हैं: Notion डॉक पहले शुरू हुआ, फिर Slack चर्चा हुई, फिर ट्रैकिंग के लिए Linear इशू बना, और अंततः एक हफ्ते बाद PR लैंड हुआ।
इसे वास्तव में अच्छा बनाएं
ऊपर दिया गया बेसिक वर्शन काम करता है, लेकिन इसमें कुछ निराशाजनक कोने हैं। इसे कैसे बेहतर बनाएं:
Slack के लिए थ्रेड एक्सपैंशन। जब आप एक मेल खाने वाला संदेश पाएं, conversations.replies से पूरा थ्रेड फेच करें। मेल खाने वाला संदेश "हाँ, BullMQ चुनते हैं" हो सकता है – बहस के पिछले 40 संदेशों के बिना उपयोगी नहीं। सिर्फ मेल खाने वाला संदेश नहीं, थ्रेड का एक स्निपेट दिखाएं।
PR रिव्यू कमेंट। GitHub की सर्च API PR खोजने पर रिव्यू कमेंट नहीं दिखाती – उन्हें फेच करने के लिए pull request reviews एंडपॉइंट पर एक अलग कॉल की ज़रूरत होगी। असली तकनीकी चर्चा वहीं रहती है।
Backlinks। जब आप एक Linear इशू पाएं, जाँचें कि क्या कोई Slack संदेश उस इशू की URL रखता है। Slack की सर्च कीवर्ड के साथ has:link फ़िल्टर सपोर्ट करती है। यह औपचारिक ट्रैकिंग के आसपास हुई अनौपचारिक चर्चा को सामने लाता है।
Caching। अगर आपकी टीम बहुत ज़्यादा कंटेंट जेनरेट करती है (और किसकी नहीं करती), तो आप जल्दी रेट लिमिट से टकराएंगे। 30 मिनट के TTL के साथ परिणामों को लोकली कैश करें – अधिकांश ऐतिहासिक निर्णय इतनी जल्दी नहीं बदलते।
जब टेक्स्ट सर्च टूट जाती है
यहाँ मैं सीमाओं के बारे में ईमानदार रहूँगा। टूल्स में कीवर्ड सर्च आपको हैरानी की हद तक आगे ले जाती है, और फिर एक दीवार से टकराती है।
दीवार यह है: निर्णय विकसित होते हैं। "जॉब क्यू" के बारे में Slack थ्रेड कभी "BullMQ" का नाम नहीं ले सकता – बजाय इसके, किसी ने एक लिंक शेयर किया, किसी और ने कहा "मुझे Redis-backed ऑप्शन पसंद है," और तीसरे ने कहा "सहमत, वही चुनते हैं।" आपकी "BullMQ" की सर्च पूरा थ्रेड छोड़ देती है क्योंकि शब्द कभी इस्तेमाल नहीं हुआ। थ्रेड में लोग जानते थे कि "Redis-backed ऑप्शन" का क्या मतलब है। आपकी सर्च नहीं जानती।
यह मूल रूप से एक ग्राफ की समस्या है, टेक्स्ट की नहीं। आप वास्तव में चाहते हैं: "मुझे वह सब दिखाओ जो उस निर्णय से जुड़ा है जिसने PR #289 को जन्म दिया।" इसका मतलब है यह समझना कि PR एक Linear इशू को रेफर करता है, जो Slack चर्चा के बाद बनाया गया था, जो इसलिए शुरू हुई क्योंकि किसी ने एक Notion डॉक पढ़ा। कनेक्शन अंतर्निहित हैं – लोगों ने URL कॉपी करके और "as discussed" कहकर उन्हें बनाया – और कीवर्ड सर्च उन्हें पुनर्निर्मित नहीं कर सकती।
आप लिंक फॉलो करके इसे आंशिक रूप से हल कर सकते हैं। Slack संदेशों, PR डिस्क्रिप्शन और Linear कमेंट से URLs पार्स करें। एक सरल adjacency list बनाएं: यह Slack थ्रेड इस Linear इशू से जुड़ता है, जिसे इस PR में रेफर किया गया है। फिर जब कोई सर्च करे, आप परिणामों को लिंक किए गए आइटम शामिल करने के लिए एक्सपैंड कर सकते हैं, भले ही वे कीवर्ड से मेल न खाएं।
वह adjacency-list अप्रोच मूलतः एक प्राथमिक नॉलेज ग्राफ़ है – और यही वह जगह है जहाँ डेवलपर्स के लिए क्रॉस-टूल सर्च का असली मूल्य रहता है। अलग-अलग संदेश खोजने में नहीं, बल्कि उस निर्णय के धागे को उस हर टूल में फॉलो करने में जिसे उसने छुआ। यह कम "सर्च" है और ज़्यादा डेवलपर नॉलेज मैनेजमेंट – यह समझना कि आपके टूल्स के बीच जानकारी कैसे बहती है ताकि जब ज़रूरत हो आप कॉन्टेक्स्ट पुनर्निर्मित कर सकें।
रखरखाव की समस्या (और एक शॉर्टकट)
स्क्रिप्ट अप्रोच लगभग तीन महीने के लिए शानदार काम करती है, और फिर कोई Slack workspace बदल देता है, या Linear अपना GraphQL स्कीमा अपडेट कर देता है, या आप एक नया टूल जोड़ते हैं और कोई सर्च स्क्रिप्ट अपडेट करना याद नहीं रखता। मैंने यही चीज़ दो बार बनाई है और दो बार छोड़ी है (जो शायद अप्रोच की बजाय रखरखाव के प्रति मेरी प्रतिबद्धता के बारे में ज़्यादा कहता है)।
अगर आप चाहते हैं कि डेवलपर्स के लिए क्रॉस-टूल सर्च बिना निगरानी के अप-टू-डेट रहे, तो Sugarbug जैसे टूल इसी के लिए बने हैं – यह नॉलेज ग्राफ़ को स्वतः बनाए रखता है और आपके टूल्स बदलने पर कनेक्शन जीवित रखता है। लेकिन ऊपर दिया गया DIY वर्शन वास्तव में उपयोगी है अगर आप इसे बनाए रखने के इच्छुक हैं।
पाँच टूल्स में अलग-अलग सर्च करना बंद करें। Sugarbug नॉलेज ग्राफ़ बनाता है ताकि आप किसी भी निर्णय, चर्चा या कमिट को एक ही जगह पा सकें।
Q: एक साथ कई डेवलपर टूल्स में सर्च कैसे करें? A: आप प्रत्येक टूल की API को मिलाकर एक हल्की क्रॉस-टूल सर्च बना सकते हैं – Slack का search.messages, Linear का issueSearch, और GitHub का कोड सर्च एंडपॉइंट – एक सिंगल स्क्रिप्ट में जो क्वेरी फैलाती है और टाइमस्टैम्प के अनुसार परिणाम मर्ज करती है। ऊपर दिए गए कोड उदाहरण आपको एक दोपहर में शुरू कर देंगे। मुख्य चुनौती सर्च खुद नहीं है बल्कि विभिन्न रिस्पॉन्स फॉर्मेट को एक सुसंगत टाइमलाइन में नॉर्मलाइज़ करना है।
Q: क्या Sugarbug डेवलपर्स के लिए क्रॉस-टूल सर्च प्रदान करता है? A: हाँ। Sugarbug Linear, GitHub, Slack, Figma, Notion और अन्य टूल्स से सिग्नल एक नॉलेज ग्राफ़ में लेता है, ताकि आप किसी निर्णय या चर्चा को खोज सकें और सभी जुड़े हुए थ्रेड, इशू और कमिट एक जगह पा सकें। यह नॉर्मलाइज़ेशन, डीडुप्लिकेशन और लिंक फॉलोइंग स्वतः संभालता है – वे हिस्से जो DIY अप्रोच को समय के साथ नाजुक बनाते हैं।
Q: मुझे अपनी कोडबेस में आर्किटेक्चर संबंधी निर्णय क्यों नहीं मिलते? A: क्योंकि अधिकांश निर्णय Slack थ्रेड्स, Linear कमेंट्स, Notion डॉक्स और PR रिव्यू में होते हैं – कोड में नहीं। कोड किसी निर्णय का परिणाम दर्ज करता है (फ़ंक्शन मौजूद है, लाइब्रेरी चुनी गई), लेकिन तर्क, ट्रेड-ऑफ और चर्चा की गई विकल्प आपके कम्युनिकेशन टूल्स में बिखरे रहते हैं। एक git blame आपको बताता है कि किसने एक लाइन कब बदली, लेकिन यह नहीं कि उन्होंने विकल्पों की बजाय यह तरीका क्यों चुना।
Q: क्या Sugarbug निर्णय ट्रैकिंग के लिए ADR दस्तावेज़ों की जगह ले सकता है? A: Sugarbug ADRs की जगह नहीं लेता, लेकिन यह उन निर्णयों को पकड़ता है जो कभी ADR में नहीं पहुँचते। अधिकांश टीमें शायद 10% आर्किटेक्चरल विकल्पों के लिए ADR लिखती हैं – बाकी Slack थ्रेड्स और PR कमेंट में घुल जाते हैं। Sugarbug उन्हें बातचीत को उनके द्वारा उत्पन्न कोड परिवर्तनों से जोड़कर सामने लाता है, ताकि आपको बाकी 90% के लिए किसी के वर्कफ़्लो को बदले बिना निर्णय ट्रैकिंग मिले।