آپ کا پہلا ایجنٹ ورک فلو ایک پرامپٹ اور چند ٹولز سے شروع ہوتا ہے۔ یہ سوالات کے جوابات دیتا ہے۔ یہ آرڈر کا اسٹیٹس چیک کرتا ہے۔ یہ کام کرتا ہے، اس لیے آپ اسے لانچ کر دیتے ہیں۔

پھر پروڈکٹ بڑھتی ہے۔ سیلز ٹیم ایک CRM اپڈیٹر مانگتی ہے جو میٹنگ نوٹس کو سنک (sync) کر سکے۔ سپورٹ کو ایک ریفنڈ ورک فلو کی ضرورت ہوتی ہے جو تین اندرونی سسٹمز سے منسلک ہو۔ انجینئرنگ وینڈر فارمز بھرنے کے لیے براؤزر ایکشنز شامل کرتی ہے۔ ہر درخواست چھوٹی معلوم ہوتی ہے۔ ہر ایک کی اپنی پرامپٹ فائل، اپنا Slack تھریڈ اور اپنا "کوئیک فکس" (quick fix) ہوتا ہے۔ چھ ماہ بعد، آپ کا ایجنٹ اب ایک سسٹم نہیں رہتا۔ یہ کاپی کیے گئے پرامپٹس، چھپے ہوئے بزنس رولز اور پرانے چیٹ تھریڈز میں کیے گئے فیصلوں کا ایک بکھرا ہوا ڈھیر بن جاتا ہے جسے کوئی ڈھونڈ نہیں سکتا۔ اسے "پرامپٹ اسپراول" (prompt sprawl) کہتے ہیں۔ یہ آپ کی AI پروڈکٹ کو ٹیسٹ کرنا، ریویو کرنا اور اعتماد کے ساتھ واپس پرانی حالت میں لانا (roll back) مشکل بنا دیتا ہے۔

اس کا حل ایک AI agent skill registry ہے۔

اصل میں اسکل (Skill) کیا ہے

اسکل محض ایک فولڈر میں محفوظ کیا گیا پرامپٹ نہیں ہے۔ یہ ایک ورژن شدہ (versioned) اور ٹیسٹ کے قابل پیکج ہے جو یہ طے کرتا ہے کہ ایجنٹ کیا کرتا ہے، وہ کن ٹولز کو کال کر سکتا ہے، اور اسے کیا کبھی نہیں کرنا چاہیے۔ اسے اپنی ٹیم اور مشین کے درمیان ایک معاہدے کے طور پر سمجھیں۔ جب کوئی ایجنٹ کسی اسکل کو لوڈ کرتا ہے، تو اسے بالکل معلوم ہونا چاہیے کہ اس کی حدود کیا ہیں اور کامیابی کی صورت کیا ہوگی۔

اس ڈھانچے کے بغیر، ہر پرامپٹ ایک چھوٹا، غیر اعلانیہ پروڈکشن سسٹم بن جاتا ہے۔ اس میں چھپی ہوئی اجازتیں (permissions)، شامل شدہ بزنس رولز اور لاگت کے اثرات ہوتے ہیں جن کا کسی نے حساب نہیں رکھا ہوتا۔ یہ اصل پروڈکٹ سے دور ہو جاتا ہے کیونکہ پروڈکٹ روڈ میپ آگے بڑھ جاتا ہے جبکہ پرامپٹ پیچھے رہ جاتا ہے۔ سب سے بدترین بات یہ ہے کہ اسے کاپی کر لیا جاتا ہے۔ کوئی ڈیمو کے لیے اسے فورک (fork) کر لیتا ہے، یا اسے کسی نئے مائیکرو سروس میں پیسٹ کر دیتا ہے، اور اب آپ کے پاس سچائی کے دو ایسے ذرائع ہیں جو اندھیرے میں ایک دوسرے سے الگ ہو رہے ہیں۔

صرف پرامپٹس کیوں ناکام ہو جاتے ہیں

پرامپٹس متن (text) کی طرح نظر آتے ہیں، اس لیے ٹیمیں انہیں کنفیگریشن کی طرح سمجھتی ہیں۔ حقیقت میں، وہ کوڈ کے زیادہ قریب ہیں جتنا کوئی تسلیم نہیں کرنا چاہتا۔ ایک پروڈکشن پرامپٹ عام طور پر ترتیب (sequencing)، فارمیٹنگ، ایرر ہینڈلنگ اور ایکسیس کنٹرول کے بارے میں لاجک کو انکوڈ کرتا ہے۔ جب وہ لاجک صرف قدرتی زبان (natural language) میں ہوتی ہے، تو ابہام پیدا ہو جاتا ہے۔ کیا ایجنٹ کے پاس CRM کو اپ ڈیٹ کرنے کی اجازت ہے، یا پرامپٹ نے محض اس کا مشورہ دیا تھا؟ اگر بلنگ API ڈاؤن ہو جائے، تو کیا پرامپٹ کو معلوم ہے کہ محفوظ طریقے سے کیسے ناکام ہونا ہے، یا وہ کامیابی کا جھوٹا پیغام (hallucinate) دے دیتا ہے؟

لاگت ایک اور خاموش قاتل ہے۔ ایک ایسا پرامپٹ جو ایجنٹ سے "مرحلہ وار سوچنے اور تفصیل سے تلاش کرنے" کا کہتا ہے، ہر بار چلنے پر ٹوکنز (tokens) کو تیزی سے ختم کر سکتا ہے۔ جب وہ پرامپٹ کسی زیادہ ٹریفک والے سپورٹ فلو میں کاپی کیا جاتا ہے، تو آپ کا ماہانہ انفرنس بل (inference bill) دوگنا ہو جاتا ہے اور کسی کو معلوم نہیں ہوتا کہ کیوں۔

ڈرفٹ (Drift) تب ہوتا ہے جب بزنس بدل جاتا ہے لیکن متن نہیں بدلتا۔ آپ کی ریفنڈ پالیسی اب ایک خاص حد سے اوپر مینیجر کی منظوری مانگتی ہے۔ اگر وہ اصول کسی پالیسی لیئر کے بجائے پرامپٹ کے اندر ہے، تو آپ کو ہر ڈیپلائمنٹ میں ان کاپیوں کو تلاش کرنا پڑے گا جنہیں اپ ڈیٹ کرنے کی ضرورت ہے۔ اگر ایک بھی رہ گیا، تو آپ کے ایجنٹس ایسا پیسہ بانٹنا شروع کر دیں گے جو انہیں نہیں دینا چاہیے۔

پروڈکشن اسکل کی ساخت (Anatomy)

اگر آپ اس گڑبڑ سے بچنا چاہتے ہیں، تو ہر اسکل کے ساتھ ایک سافٹ ویئر آرٹفیکٹ (software artifact) کی طرح پیش آئیں۔ ایک مفید پروڈکشن اسکل میں صرف متن سے زیادہ چیزیں شامل ہوتی ہیں۔ اسے ضرورت ہوتی ہے:

  • نام اور مقصد۔ "prompt_v3_final" نہیں، بلکہ بزنس مقصد کی واضح وضاحت کے ساتھ "process_standard_refund"۔

  • ان پٹ اسکیمہ اور مطلوبہ سیاق و سباق (context)۔ ان مخصوص فیلڈز کی وضاحت کریں جن کی اسکل توقع رکھتی ہے۔ کیا اسے صارف کی ID، بات چیت کی ہسٹری، یا ٹیننٹ آئیڈینٹیفائر کی ضرورت ہے؟ یہاں مضبوط ٹائپنگ (strong typing) ایجنٹ کو مفروضے لگانے سے روکتی ہے۔

  • **ٹ

  • Instructions are guidance for the agent. They explain tone, format, and general approach.

  • Tool Rules tell the agent which tools exist and what they do. This is discovery, not permission.

  • Policy is enforced by code, not by hope. If a refund over $500 needs a second pair of eyes, that check lives in a validation function that runs before the tool is ever called.

  • Evals are tests that prove the skill still works after any change.

For example, do not write, "Please never expose the customer's full credit card number." Instead, build a data formatter that redacts PANs before the agent sees them. Policy belongs in code because code cannot be talked out of its job by a clever user input.

Stop Pointing Production at "Latest"

Nothing destroys a Friday evening like a silent prompt update. If your production agent always pulls the "latest" version of a skill, then every merge to main is a potential live incident. You need aliases such as dev, staging, and prod. Promote a known, tested version through these stages. When prod points to v2.1.4, you can watch it run, measure its behavior, and sleep soundly. If something goes wrong, you move the alias back. You do not debug natural language at midnight under pressure.

This discipline also forces your team to think about backwards compatibility. Can v2.2 handle the same input shape as v2.1? If not, the promotion fails in staging, and you catch it before a customer does.

Security Starts Inside the Package

A registry full of unaudited prompts is a vulnerability waiting to happen. You need to scan your skills for the same risks you would scan in code.

Look for hardcoded secrets or API keys buried in prompt templates. Check for external webhooks or shell commands that exfiltrate data. Watch for attempts to override system policy, such as prompts that contain "ignore previous instructions" or ask the agent to reveal its own configuration. These are not just theoretical. They are common patterns in prompt-injection attacks, and they are dangerous because they often ride along with copied text that no one reviewed.

Run your skill packages through static analysis. If a skill file contains a URL that is not on an allowlist, fail the build. If it references a tool that is not in the approved manifest, reject it.

If You Can't Test It, You Can't Trust It

A registry without evaluations is just a folder of prompts. Each skill needs a test set that exercises the happy path, the edge cases, and the failure modes. For high-risk skills, you need more than functional tests. You need to probe permission boundaries to make sure the agent cannot see another user's data. You need refusal behavior checks to confirm it says no when policy blocks an action. You need prompt-injection resistance tests to verify that adversarial inputs do not bypass your code-level protections.

Name your tests explicitly. A test called "refund_skill_rejects_negative_amount" tells the next engineer exactly what behavior is protected. When a test fails during a version promotion, you have hard evidence that the candidate build is unsafe.

The Real Goal Is Control

Reuse is nice, but control is what keeps you employed. A skill registry lets your team state, with certainty: this is the approved workflow. This is the version running in production. These are the tools it can use. This is exactly how we roll it back.

That clarity moves you from shipping clever demos to operating dependable software. Demos impress stakeholders for ten minutes. Dependable software runs at three in the morning, handles exceptions gracefully, and does not change behavior just because someone merged a pull request on Tuesday afternoon.

Build your registry. Version your skills. Enforce your policies in code. Test like your sleep schedule depends on it. Your future self will thank you.