हमने LLM-आधारित code convention linter बनाया है.
(github.com/DevSymphony)नमस्ते! हम sym-cli विकसित कर रही कॉलेज छात्रों की टीम Symphony हैं.
क्या आप भी आजकल Cursor या Claude Code जैसे टूल्स का इस्तेमाल करके vibe coding बहुत करते हैं? हमारी टीम भी development process में LLM का सक्रिय रूप से उपयोग कर रही है. लेकिन इस्तेमाल करते-करते हमें एक कमी महसूस हुई.
AI द्वारा लिखा गया कोड functional तौर पर अच्छी तरह चलता है, लेकिन हमारी टीम के अपने convention (variable naming, comment style, खास library usage rules आदि) को बार-बार नज़रअंदाज़ कर देता था. हर बार prompt में नियम लिखना झंझट भरा था, और बार-बार ऐसा करने पर conventions खुद भी धीरे-धीरे याद से निकलने लगते थे.
इसीलिए हमने इस सवाल से sym-cli बनाना शुरू किया: "क्या LLM कोड लिखने से पहले, या लिखते समय, खुद ही conventions चेक नहीं कर सकता?"
[sym-cli क्या है?]
sym-cli AI coding tools के लिए एक policy-based code convention linter है. इसकी सबसे बड़ी खासियत यह है कि यह MCP का उपयोग करके सीधे LLM से संवाद करता है.
मौजूदा linters से इसके अंतर इस प्रकार हैं.
- (Natural language-based settings) जटिल configuration files की जगह, अगर आप "कभी भी log को print से मत लिखो" जैसे natural language में नियम परिभाषित करते हैं, तो LLM उन्हें समझकर पालन करता है.
- (Context optimization) LLM प्रोजेक्ट के सभी नियम नहीं पढ़ता, बल्कि MCP tool के जरिए मौजूदा काम के लिए ज़रूरी नियम ही समझदारी से लाता है.
- (Active validation)
validate_codetool के जरिए LLM कोड generate करने के तुरंत बाद खुद यह जांच सकता है कि नियमों का पालन हुआ है या नहीं.
[यह कैसे काम करता है?]
sym कमांड डाउनलोड करने के बाद sym init कमांड चलाने पर MCP server configuration अपने आप सेट हो जाती है, और MCP को support करने वाले IDE (Cursor आदि) या LLM tools में ये नियम तुरंत refer होने लगते हैं.
[कृपया feedback दें!]
हम अभी भी कॉलेज छात्रों की टीम हैं, और यह प्रोजेक्ट अभी बस शुरुआती चरण में है जहाँ इसका बुनियादी ढांचा ही बना है. इसमें कई कमियाँ हो सकती हैं और bugs भी हो सकते हैं. लेकिन working developers और LLM tools में रुचि रखने वाले लोगों का समर्थन और feedback हमारे लिए बहुत ज़रूरी है.
"अगर ऐसा feature हो तो अच्छा होगा", "यह हिस्सा structural रूप से problematic लगता है", "असल industry में इसे इस तरह इस्तेमाल किया जाता है" — किसी भी तरह की राय हम कृतज्ञता से सुनेंगे. यह open source है, इसलिए contribution या GitHub Star हमारी टीम के लिए सचमुच बहुत बड़ी ताकत है!
GitHub Repository: https://github.com/DevSymphony/sym-cli
npm: npm install -g @dev-symphony/sym
पढ़ने के लिए धन्यवाद.
7 टिप्पणियां
अगर आप opencode इस्तेमाल करते हैं, तो lint फ़ीचर को भी workflow में शामिल कर सकते हैं
https://hi.news.hada.io/topic?id=21883
https://opencode.ai/docs/formatters/
मैं सहमत हूँ। सिंटैक्स·टाइप errors जैसी चीज़ें जिन्हें तुरंत पकड़ा जा सकता है, उनके लिए LSP या compile stage सबसे efficient है, और token usage के लिहाज़ से भी यही सही approach लगता है। हम भी LLM को इसका replacement मानने के बजाय, इसे natural language में लिखे गए rules को मौजूदा lint/test workflow से अपने-आप जोड़ने वाली भूमिका के अधिक करीब देखते हैं।
मैं भी t7vonn की तरह मानता हूँ कि convention को automation tool से ही एकसमान करना सही है
लेकिन LSP फीचर में काफ़ी फ़र्क महसूस होता है, क्योंकि test या compile चलाकर ही पकड़ी जाने वाली syntax errors को यह तुरंत पकड़ लेता है, इसलिए token usage कम हो जाता है।
PR review agent को convention document और diff देकर छूटी हुई चीज़ें ढूंढने जितना काम अभी भी पहले से किया जा रहा है.. और इससे आगे शायद इस्तेमाल नहीं होगा
मेरे जैसा ही विचार रखने वाले व्यक्ति की एक पोस्ट संलग्न कर रहा हूँ
आपके बताए इस्तेमाल का तरीका फिलहाल सबसे व्यावहारिक अप्रोच लगता है। हम जिस समस्या को हल करना चाहते हैं, वह है हर PR पर convention document थमाने की प्रक्रिया को कम करना, और natural language में परिभाषित नियमों को पहले से linter·validation rules में बदलकर PR/CI चरण में अपने-आप चलने लायक बनाना।
उम्.. लगता है कि इसे Claude hooks/subagents/skill जैसी किसी फीचर से भी बनाया जा सकता है ..
तकनीकी रूप से यह hooks या subagent से भी संभव लगता है, लेकिन हमने किसी खास LLM पर निर्भर न रहने के लिए MCP और मौजूदा linter workflow के ऊपर एक thin layer रखने का विकल्प चुना। इसलिए agent features की तुलना में हमारा फोकस conventions को reusable infrastructure बनाने पर है।