Omnilude में Agent Skills को जोड़कर देखना

परिचय

पहले मैंने Skills और Agent Workflows पर एक परिचयात्मक लेख लिखा था।

उसे पढ़ते हुए मुझे लगा, अगर skills को AI chat से जोड़ा जाए, तो वे काफी उपयोगी हो सकते हैं।

यह लेख उसी विचार से शुरू हुआ एक implementation record है। मैं Skills को Claude Code और Codex जैसे tools के अंदर से निकालकर, Agent को उन्हें एक वास्तविक workflow के भीतर बुलाने देना चाहता था, ताकि देख सकूँ कि क्या बदलता है। अगर यह ठीक से काम करता है, तो शायद comparatively हल्के LLMs भी थोड़ा-थोड़ा Jarvis के करीब जा सकें।

Skill को एक वाक्य में समझाएँ तो

सबसे छोटा उत्तर यह है: एक skill ऐसा reusable work package है जो agent को किसी खास तरह के काम को एक repeatable order और criteria के साथ संभालना सिखाता है।

Anthropic की public guide भी skill को एक ऐसे folder के रूप में समझाती है जिसका केंद्र SKILL.md होता है, और ज़रूरत पड़ने पर उसमें scripts, references, assets जुड़े होते हैं। असली बात उसका shape नहीं, बल्कि उसका principle है। हर बार पूरी knowledge को prompt में ठूंसने की जगह, agent ज़रूरत पड़ने पर ही skill body और reference files को progressively खोलता है।

यह बात जितनी दिखती है उससे ज़्यादा महत्वपूर्ण है। General-purpose agents समझदार होते हैं, लेकिन repetitive work के सामने आसानी से डगमगा सकते हैं। वही repository, वही काम, और उसी व्यक्ति की वही request होने पर भी output का tone, structure और missing points बदल सकते हैं। skill उस instability को कम करने का एक तरीका है।

मेरे लिए तीन principles खास तौर पर महत्वपूर्ण हैं। पहला है progressive disclosure, यानी केवल ज़रूरत पड़ने पर ही deeper documents खोलना। दूसरा है composability, जहाँ एक skill पूरी दुनिया को अकेले हल करने की कोशिश नहीं करता, बल्कि दूसरे skills के साथ मिलकर काम करता है। तीसरा है portability, ताकि skill किसी एक UI या tool में बंधकर न रह जाए।

मैं जो Skill chain बना रहा हूँ

मेरे local repository में .codex/skills के नीचे 25 skills हैं। Document generation, API implementation, backoffice CRUD, SSE, story pipelines, translation, review और commit workflows जैसे recurring tasks को ये अलग-अलग संभालते हैं। .agents/skills के भीतर मैंने वही catalog इस तरह रखा है कि उसे किसी दूसरे surface से भी reuse किया जा सके।

और यह भी एक वजह है कि मैं हमेशा Claude Code की बात करता हूँ, लेकिन अचानक Codex का ज़िक्र आने लगता है। हाल ही में Korea में Kakao के जरिए OpenAI Pro पर लगभग 90% discount वाला एक event हुआ था। वह अच्छा मौका था, इसलिए अब मैं Codex पर आ गया हूँ।

मुख्य बात पर लौटें तो, जिन skills का मैं सबसे ज़्यादा इस्तेमाल करता हूँ, उनका axis काफी साफ है। prd-generator requirements लेकर document rules के अनुसार PRD बनाता है, और endpoint-implement-skill Entity से Controller तक implementation pattern को स्थिर करता है। ज़रूरत पड़ने पर frontend-task-handover frontend handover document तक flow को आगे बढ़ाता है, और branch-review अंत में regressions और risk फिर से देखता है।

यानि मैं skills को अक्सर individual features से ज़्यादा एक chain के रूप में देखता हूँ।

असल में CLAUDE.md में यह भी लिखा है कि किस तरह के काम के लिए कौन-से skills पहले जोड़े जाने चाहिए। उदाहरण के लिए API development की chain prd-generator -> endpoint-implement-skill -> frontend-task-handover है, और backoffice development की chain prd-generator -> backoffice-crud-skill -> frontend-task-handover है। इस बिंदु पर skill एक simple helper feature से कम और work operating rule से ज़्यादा लगता है।

दिलचस्प बात यह है कि यह लेख खुद भी उसी philosophy पर खड़ा है। जिस blog-post-writer skill का मैं अभी उपयोग कर रहा हूँ, वह blog category, reading time, tone, excerpt length, canonical URL, thumbnail prompt और import JSON schema को एक साथ align करने के लिए design किया गया है। अब writing भी सिर्फ intuition का मामला नहीं रह गया है। वह भी एक repeatable output format में packaged है।

Skills और assistants

जब कोई skill product के भीतर आता है, तो उसे सिर्फ SKILL.md से समझाया नहीं जा सकता। अगर current-weather-checker detail blueprint को reference मानें, तो real skill instructions और references भर नहीं होता, बल्कि executable code, metadata, network policy और trigger strategy के साथ बंधी एक runtime unit के करीब होता है। इसलिए अब मैं skill को सिर्फ folder structure के रूप में नहीं, बल्कि क्या store होता है, क्या execute होता है, और वह assistant से कैसे जुड़ता है इस रूप में देखता हूँ।

Skill structure overview

current-weather-checker blueprint को follow करें, तो skill की वास्तविक संरचना पहली नज़र से कहीं अधिक layered लगती है। स्क्रीन पर सबसे पहले नाम और description दिखते हैं, लेकिन उसके पीछे Instructions, Scripts, References, Assets, Metadata और Runtime Policy साथ जुड़े होते हैं। यही composition किसी skill को केवल context enrich करने, किसी दूसरे skill को sandbox में सीधे execute होने, और किसी तीसरे skill को external network access सुरक्षित तरीके से control करने लायक बनाती है।

संक्षेप में कहें, skill सिर्फ एक prompt file नहीं है। वह descriptive text + execution resources + operating policy को एक साथ बांधने वाले definition object के ज़्यादा करीब है। खासकर script skills में networkPolicy और allowedDomains जैसी execution policies ही असली permissions तय करती हैं। केवल body पढ़कर यह पूरी तरह समझा नहीं जा सकता कि skill वास्तव में क्या कर सकता है। यही वजह है कि blueprint documents इतने उपयोगी हैं। वे स्क्रीन के पीछे की structure को एक बार में restore कर देते हैं।

Assistant integration overview

अगले चरण में skill खुद से ज़्यादा महत्वपूर्ण यह है कि उस skill का मालिक कौन है, वह किन शर्तों पर बुलाया जाता है, और चुने जाने के बाद किस path से execute होता है। Omnilude की structure में skill किसी agent से ढीले ढंग से नहीं जुड़ता, बल्कि assistant से mapped होता है, और orchestrator उस mapping और trigger information को पढ़कर असली execution path तय करता है। Executable skills sandbox की ओर flow करते हैं, जबकि context-only material final response prompt की ओर जाता है।

Isolated execution environment

Executable skills के scripts assistant process के अंदर सीधे नहीं चलते। AssistantSkillScriptExecutor, sandbox-bridge के जरिए execution को एक अलग sandbox pod में delegate करता है, और script उसी isolated environment में stdin JSON को input के रूप में लेकर stdout JSON के रूप में result लौटाता है। इस structure की वजह से assistant core और execution code अलग रहते हैं, और networkPolicy तथा allowedDomains के जरिए external access की सीमा भी control की जा सकती है।

सरल शब्दों में कहें तो assistant तय करता है क्या execute करना है, और sandbox वह जगह है जहाँ उस execution को सुरक्षित तरीके से संभाला जाता है। Skills जितने बढ़ते हैं, यह separation उतना ही महत्वपूर्ण हो जाता है। इससे failures isolate किए जा सकते हैं, network permissions को अधिक बारीकी से बाँटा जा सकता है, और बाद में यह trace करना आसान हो जाता है कि कौन-सा script किस policy के तहत चला था।

इस flow से देखें, तो skill assistant का subordinate document कम और ऐसा module ज़्यादा है जिसे assistant ज़रूरत पड़ने पर चुनकर execute करता है। इसलिए attached skills जितने मज़बूत होते जाते हैं, उतना ही महत्वपूर्ण यह नहीं रहता कि explanation कितनी लंबी है, बल्कि यह होता है कि mapping, trigger, execution और observability कितनी स्पष्टता से design किए गए हैं। अंततः एक अच्छा skill सिर्फ अच्छी तरह लिखा हुआ document नहीं है। वह एक structured execution surface है जिसे assistant भरोसेमंद तरीके से invoke कर सके।

समापन

अगर 18 फ़रवरी 2026 वाले workflow लेख ने agent कैसे flow करता है यह समझाया था, तो यह लेख उस flow को skills के ज़रिए एक stable structure में कैसे बदला जा सकता है, इस बारे में है।

Skill कोई जादुई विकल्प नहीं है। फिर भी यह व्यक्तियों और टीमों के repetitive work, work standards, reference context, output format और execution paths को एक ही unit में बांधने का काफी शक्तिशाली तरीका है।

अगली बार मैं implementation और operations, दोनों दृष्टिकोणों से कुछ और ठोस उदाहरण लाना चाहता हूँ, ताकि दिखा सकूँ कि skills और assistants का संयोजन वास्तविक agent experience को कैसे बेहतर बनाता है।