Your first agent workflow starts with one prompt and a few tools. It answers questions. It looks up an order status. It works, so you ship it.

Then the product grows. Sales asks for a CRM updater that syncs meeting notes. Support needs a refund workflow that touches three internal systems. Engineering adds browser actions to fill out vendor forms. Each request seems small. Each gets its own prompt file, its own Slack thread, its own "quick fix." Six months later, your agent is no longer one system. It is a scattered pile of copied prompts, hidden business rules, and decisions made in old chat threads that nobody can find. That is prompt sprawl. It makes your AI product hard to test, hard to review, and impossible to roll back with confidence.

The fix is an AI agent skill registry.

What a Skill Actually Is

A skill is not a prompt saved to a folder. It is a versioned, testable package that defines what the agent does, which tools it can call, and what it must never do. Think of it as a contract between your team and the machine. When an agent loads a skill, it should know exactly where its boundaries are and what success looks like.

Without this structure, every prompt becomes a tiny, undeclared production system. It carries hidden permissions, embedded business rules, and cost impacts that no one tracked. It drifts away from the actual product because the product roadmap moved left while the prompt stayed behind. Worst of all, it gets copied. Someone forks it for a demo, or pastes it into a new microservice, and now you have two sources of truth diverging in the dark.

Why Prompts Alone Fall Apart

Prompts look like text, so teams treat them like configuration. In reality, they are更接近 code than anyone admits. A production prompt usually encodes logic about sequencing, formatting, error handling, and access control. When that logic lives only in natural language, you get ambiguity. Does the agent have permission to update the CRM, or did the prompt merely suggest it? If the billing API goes down, does the prompt know how to fail safely, or does it hallucinate a success message?

Cost is another silent killer. A prompt that asks the agent to "think step by step and search extensively" can burn through tokens on every single run. When that prompt is copied into a high-traffic support flow, your monthly inference bill doubles and no one knows why.

Drift happens when the business changes but the text does not. Your refund policy now requires manager approval above a certain threshold. If that rule lives inside a prompt instead of a policy layer, you must hunt through every deployment to find the copies that need updating. Miss one, and you have agents handing out money they should not.

Anatomy of a Production Skill

If you want to escape this mess, treat every skill like a software artifact. A useful production skill includes more than just text. It needs:

  • Name and purpose. Not "prompt_v3_final," but "process_standard_refund" with a clear description of the business goal.
  • Input schema and required context. Define the exact fields the skill expects. Does it need a user ID, a conversation history, a tenant identifier? Strong typing here prevents the agent from making assumptions.
  • Tool permissions and safety limits. Explicitly list which tools the skill can invoke. Set guardrails on retries, spending limits, and rate caps. If the skill should not touch the user deletion API, say so in code, not just in prose.
  • Success criteria and test cases. A skill does not "work" just because it runs. Define what the output must contain. For a refund skill, success might mean a validated transaction record, an email confirmation sent, and an audit log entry created.
  • Version history and owner status. Someone needs to own this. A changelog should explain why v2.3 exists and what broke in v2.2.

Separate Your Layers

The biggest mistake teams make is stuffing everything into one prompt. They mix friendly guidance, tool documentation, security policy, and error handling into a wall of text. That is unmaintainable.

Break it apart:

  • निर्देश (Instructions) एजेंट के लिए मार्गदर्शन हैं। वे टोन, फॉर्मेट और सामान्य दृष्टिकोण को समझाते हैं।
  • टूल नियम (Tool Rules) एजेंट को बताते हैं कि कौन से टूल मौजूद हैं और वे क्या करते हैं। यह खोज (discovery) है, अनुमति (permission) नहीं।
  • पॉलिसी (Policy) कोड द्वारा लागू की जाती है, न कि केवल उम्मीद पर। यदि $500 से अधिक के रिफंड के लिए दूसरे व्यक्ति की समीक्षा की आवश्यकता है, तो वह जांच एक वैलिडेशन फंक्शन में होती है जो टूल को कॉल करने से पहले ही चलता है।
  • Evals वे टेस्ट हैं जो साबित करते हैं कि किसी भी बदलाव के बाद स्किल अभी भी काम कर रही है।

उदाहरण के लिए, यह न लिखें, "कृपया ग्राहक के क्रेडिट कार्ड नंबर को कभी भी पूरा उजागर न करें।" इसके बजाय, एक डेटा फॉर्मेटर बनाएं जो एजेंट के देखने से पहले ही PAN को रेडैक्ट (redact) कर दे। पॉलिसी कोड में होनी चाहिए क्योंकि एक चतुर यूजर इनपुट के जरिए कोड को उसके काम से रोका नहीं जा सकता।

प्रोडक्शन को "Latest" पर पॉइंट करना बंद करें

एक साइलेंट प्रॉम्प्ट अपडेट शुक्रवार की शाम को बर्बाद करने के लिए काफी है। यदि आपका प्रोडक्शन एजेंट हमेशा किसी स्किल का "latest" वर्जन खींचता है, तो main में किया गया हर मर्ज एक संभावित लाइव इंसिडेंट बन जाता है। आपको dev, staging, और prod जैसे एलियास (aliases) की आवश्यकता है। एक ज्ञात, टेस्ट किए गए वर्जन को इन चरणों के माध्यम से प्रमोट करें। जब prod v2.1.4 को पॉइंट करता है, तो आप इसे चलते हुए देख सकते हैं, इसके व्यवहार को माप सकते हैं, और चैन की नींद सो सकते हैं। यदि कुछ गलत होता है, तो आप एलियास को वापस पीछे ले जाते हैं। आप आधी रात को दबाव में नेचुरल लैंग्वेज को डीबग नहीं करते हैं।

यह अनुशासन आपकी टीम को बैकवर्ड कम्पैटिबिलिटी (backwards compatibility) के बारे में सोचने के लिए भी मजबूर करता है। क्या v2.2 उसी इनपुट शेप को हैंडल कर सकता है जैसा v2.1 करता है? यदि नहीं, तो प्रमोशन स्टेजिंग में ही फेल हो जाता है, और आप इसे ग्राहक के पहुँचने से पहले ही पकड़ लेते हैं।

सुरक्षा पैकेज के अंदर से शुरू होती है

बिना ऑडिट किए गए प्रॉम्प्ट्स से भरी रजिस्ट्री एक संभावित भेद्यता (vulnerability) है। आपको अपने स्किल्स को उन्हीं जोखिमों के लिए स्कैन करने की आवश्यकता है जिनके लिए आप कोड को स्कैन करते हैं।

प्रॉम्प्ट टेम्पलेट्स में दबे हुए हार्डकोडेड सीक्रेट्स या API कीज़ (keys) को खोजें। उन बाहरी वेबहुक्स (webhooks) या शेल कमांड्स की जांच करें जो डेटा एक्सफ़िल्ट्रेट (exfiltrate) करते हैं। सिस्टम पॉलिसी को ओवरराइड करने के प्रयासों पर नज़र रखें, जैसे कि वे प्रॉम्प्ट जिनमें "ignore previous instructions" लिखा हो या जो एजेंट से उसकी अपनी कॉन्फ़िगरेशन बताने को कहें। ये केवल सैद्धांतिक नहीं हैं। ये प्रॉम्प्ट-इंजेक्शन हमलों के सामान्य पैटर्न हैं, और ये खतरनाक हैं क्योंकि वे अक्सर कॉपी किए गए टेक्स्ट के साथ आते हैं जिसकी किसी ने समीक्षा नहीं की होती।

अपने स्किल पैकेज को स्टैटिक एनालिसिस (static analysis) से गुजारें। यदि किसी स्किल फाइल में ऐसा URL है जो अलाउलिस्ट (allowlist) पर नहीं है, तो बिल्ड को फेल कर दें। यदि यह किसी ऐसे टूल का संदर्भ देता है जो स्वीकृत मैनिफेस्ट (manifest) में नहीं है, तो उसे रिजेक्ट कर दें।

यदि आप इसका परीक्षण नहीं कर सकते, तो आप इस पर भरोसा नहीं कर सकते

बिना इवल्स (evaluations) वाली रजिस्ट्री केवल प्रॉम्प्ट्स का एक फोल्डर है। प्रत्येक स्किल को एक टेस्ट सेट की आवश्यकता होती है जो हैप्पी पाथ (happy path), एज केसेस (edge cases), और फेलियर मोड (failure modes) का परीक्षण करे। उच्च-जोखिम वाली स्किल्स के लिए, आपको कार्यात्मक परीक्षणों (functional tests) से अधिक की आवश्यकता है। आपको अनुमति सीमाओं (permission boundaries) की जांच करने की आवश्यकता है ताकि यह सुनिश्चित हो सके कि एजेंट दूसरे उपयोगकर्ता का डेटा नहीं देख सकता। आपको रिफ्यूजल बिहेवियर (refusal behavior) चेक की आवश्यकता है ताकि यह पुष्टि हो सके कि जब पॉलिसी किसी एक्शन को रोकती है, तो वह "ना" कहता है। आपको प्रॉम्प्ट-इंजेक्शन रेजिस्टेंस टेस्ट की आवश्यकता है ताकि यह सत्यापित किया जा सके कि एडवर्सरियल इनपुट (adversarial inputs) आपके कोड-लेवल सुरक्षा उपायों को बायपास नहीं करते हैं।

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

असली लक्ष्य नियंत्रण (Control) है

पुन: उपयोग (Reuse) अच्छा है, लेकिन नियंत्रण ही वह चीज़ है जो आपको नौकरी पर बनाए रखती है। एक स्किल रजिस्ट्री आपकी टीम को निश्चितता के साथ यह कहने की अनुमति देती है: यह स्वीकृत वर्कफ़्लो है। यह प्रोडक्शन में चल रहा वर्जन है। ये वे टूल हैं जिनका यह उपयोग कर सकता है। हम इसे ठीक इसी तरह रोलबैक करते हैं।

वह स्पष्टता आपको केवल चतुर डेमो भेजने से हटाकर भरोसेमंद सॉफ्टवेयर चलाने की ओर ले जाती है। डेमो स्टेकहोल्डर्स को दस मिनट के लिए प्रभावित करते हैं। भरोसेमंद सॉफ्टवेयर तड़के तीन बजे चलता है, अपवादों (exceptions) को शालीनता से संभालता है, और केवल इसलिए अपना व्यवहार नहीं बदलता क्योंकि किसी ने मंगलवार दोपहर को एक पुल रिक्वेस्ट (pull request) मर्ज कर दी है।

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