اپنی agent skill کیسے لکھیں اور اسے test کریں

اپنی ایک حقیقی ناکامی سے agent skill لکھیں

اپنی agent skill لکھنے کا بہترین طریقہ یہ ہے کہ اسے ایک حقیقی ناکامی سے اخذ کریں۔ ایسا task تلاش کریں جس میں آپ کے coding agent نے دو مرتبہ غلطی کی ہو، دونوں مرتبہ آپ نے جو correction لکھی تھی اسے نوٹ کریں، اور اس correction کو SKILL.md file کے طور پر محفوظ کریں تاکہ agent اسے خود load کر سکے۔ اس کے بعد باقی کام mechanics پر مشتمل ہے: file layout، اور وہ ایک سطر جو طے کرتی ہے کہ skill کبھی فعال بھی ہوگی یا نہیں۔

یہ ترتیب اہم ہے۔ تخیل سے لکھی گئی skill ایسے مسئلے کی دستاویز بناتی ہے جس کا آپ نے کبھی سامنا نہیں کیا، اور ہر session میں context کی لاگت برقرار رہتی ہے۔ کسی دیکھی ہوئی failure سے اخذ کی گئی skill اپنے ساتھ test بھی لاتی ہے: وہی درخواست دوبارہ کریں اور دیکھیں کہ آیا agent اس بار درست نتیجہ دیتا ہے۔ اگر یہ format آپ کے لیے نیا ہے تو پہلے agent skills کیا ہیں اور agent انہیں کیسے load کرتا ہے پڑھیں، پھر واپس آ کر skill لکھیں۔

ایسے کام سے آغاز کریں جسے agent نے دو بار غلط کیا ہو

ایک بار اتفاق ہو سکتا ہے۔ دو بار ایک pattern ہے، اور pattern کو file میں درج کرنا چاہیے۔

حقیقی servers پر بار بار پیش آنے والی failure کی مثال دیکھیں۔ آپ agent سے nginx میں reverse proxy block شامل کرنے کو کہتے ہیں۔ وہ /etc/nginx/conf.d/app.conf میں ترمیم کرتا ہے، پھر sudo systemctl restart nginx چلاتا ہے۔ ترمیم میں typo ہوتا ہے، اس لیے nginx start ہونے سے انکار کر دیتا ہے، اور site اس وقت تک down رہتی ہے جب تک آپ اسے درست نہ کر دیں:

nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/conf.d/app.conf:12
Job for nginx.service failed because the control process exited with error code.

آپ chat میں اسے درست کر دیتے ہیں۔ service کو چھیڑنے سے پہلے sudo nginx -t سے configuration test کریں، پھر restart کے بجائے reload سے اسے apply کریں۔ ایک ہفتے بعد، ایک مختلف task میں، وہی غلطی دوبارہ ہوتی ہے۔ دوسری بار ملنے والا یہی signal ہے۔

Failure سامنے ہوتے ہوئے دو چیزیں لکھ لیں: آپ نے جو request لکھی تھی، اور جو correction دی تھی، بعینہٖ وہی الفاظ استعمال کرتے ہوئے۔ یہ دونوں سطریں skill بن جاتی ہیں۔ Request بتاتی ہے کہ trigger کو کس چیز سے match کرنا ہے۔ Correction پورا content فراہم کرتی ہے۔

Anthropic کی اپنی authoring guidance بھی اسی بات کو پہلے رکھتی ہے۔ Agent کو representative tasks پر skill کے بغیر چلائیں، نوٹ کریں کہ وہ کہاں fail ہوتا ہے، پھر وہ minimum instructions لکھیں جو ان failures کو درست کریں۔ Failures ہی specification ہیں، اس لیے ایسی skill جسے کسی مخصوص failure تک trace نہ کیا جا سکے، عموماً ایسی skill ہوتی ہے جس کی کسی کو ضرورت نہیں تھی۔

اسی distillation کی ایک مکمل مثال کے لیے، Ponytail ایک بار بار ہونے والی failure، یعنی agent کا آپ کی درخواست سے کہیں زیادہ مواد rewrite کرنا، کو skill میں تبدیل کرتا ہے اپنی skill لکھنے سے پہلے آخر تک پڑھ سکتے ہیں۔

اسکل کی ساخت

اسکل ایک ڈائریکٹری ہوتی ہے جس میں ایک لازمی فائل شامل ہوتی ہے۔

.claude/skills/nginx-config-changes/
├── SKILL.md
├── reference/
│   └── proxy-headers.md
└── scripts/
    └── check-and-reload.sh

SKILL.md سے ایک frontmatter بلاک شروع ہوتا ہے۔ اس میں YAML میں لکھی ہوئی چند settings ہوتی ہیں۔ یہی configuration format Docker Compose files میں بھی استعمال ہوتا ہے۔ یہ بلاک --- markers کے درمیان ہوتا ہے، جس کے بعد instructions markdown میں لکھی جاتی ہیں۔ اوپر دی گئی failure کے لیے مکمل skill یہ ہے۔

---
name: nginx-config-changes
description: Tests and reloads nginx safely after a config edit. Use when editing files under /etc/nginx, adding a server block or a reverse proxy, or changing a TLS certificate path.
---

## Rules

Run `sudo nginx -t` after every edit under `/etc/nginx`. Do not touch the service until it prints `test is successful`.

Apply the change with `sudo systemctl reload nginx`. Never use `restart`. A reload keeps the running workers serving traffic until the new config parses, so a broken config leaves the site up. A restart stops nginx first, so a broken config takes the site down.

If `nginx -t` fails, fix the file and test again. Never reload a config that failed the test.

For the proxy header defaults this project expects, see [reference/proxy-headers.md](reference/proxy-headers.md).

یہ فائل 20 lines سے کم ہے اور ایک مکمل skill ہے۔ اس کے اجزا یہ ہیں:

• name: زیادہ سے زیادہ 64 characters، صرف lowercase letters، digits اور hyphens پر مشتمل ہو، اور اس میں claude یا anthropic الفاظ شامل نہیں ہو سکتے۔ personal یا project skill میں یہ صرف display label ہوتا ہے۔ جو command آپ type کرتے ہیں وہ directory name سے آتی ہے، اس لیے یہ /nginx-config-changes کے نام سے چلتی ہے۔
• description: skill کیا کرتی ہے اور اسے کب استعمال کرنا ہے، اس کی وضاحت۔ حد 1,024 characters ہے۔ اصل کام یہ line کرتی ہے، اور اگلا section صرف اسی موضوع سے متعلق ہوتا ہے۔
• body: instructions، جو صرف اس وقت load ہوتی ہیں جب skill واقعی activate ہو۔
• reference/: اضافی files جنہیں agent ضرورت کے وقت پڑھتا ہے۔ انہیں SKILL.md سے link کریں اور links کو ایک level گہرا رکھیں، کیونکہ کسی دوسری referenced file سے refer کی گئی file اکثر صرف جزوی طور پر پڑھی جاتی ہے۔
• scripts/: وہ files جنہیں agent پڑھنے کے بجائے execute کرتا ہے۔ context میں صرف ان کا output شامل ہوتا ہے، اس لیے 300 line کا script کم لاگت رکھتا ہے۔

جب skill جس behaviour کو درست کرتی ہے وہ اتنا مستقل ہو کہ مکمل layout درکار ہو، تو skill اسی layout میں بڑھ جاتی ہے۔ unlazy skill پورا کام مکمل کیے بغیر agent کو done کا اعلان کرنے سے روکنے کے لیے اس جگہ کو Depth Tree، gates files کے مجموعے اور PLAN.md contract پر صرف کرتی ہے، تاکہ کام کی پوری branches نظر انداز نہ ہوں۔

ڈائریکٹری کہاں رکھی گئی ہے، اس سے طے ہوتا ہے کہ skill کس کے لیے دستیاب ہوگی۔

• .claude/skills/<name>/SKILL.md repository میں: صرف اسی project کے لیے، اور جو بھی repository clone کرے گا اسے بھی مل جائے گی۔
• ~/.claude/skills/<name>/SKILL.md: آپ کی machine کے ہر project کے لیے، لیکن کسی اور کی machine کے لیے نہیں۔
• <plugin>/skills/<name>/SKILL.md: plugin کے اندر shipped، اور جہاں بھی وہ plugin enabled ہو وہاں دستیاب۔

mkdir -p .claude/skills/nginx-config-changes کے ذریعے ایک skill بنائیں اور فائل لکھیں۔ Claude Code ان directories کو monitor کرتا ہے، اس لیے موجودہ skill میں editing running session کے اندر نافذ ہو جاتی ہے۔ اگر session شروع ہونے کے وقت top-level skills directory موجود نہ ہو اور آپ اسے بعد میں بنائیں، تو restart درکار ہوگا، کیونکہ session شروع ہوتے وقت monitor کرنے کے لیے کوئی directory موجود نہیں تھی۔

description فیلڈ فائل کی سب سے زیادہ مؤثر لائن ہے

Startup کے وقت agent ہر دستیاب skill کے name اور description کو اپنے context میں load کرتا ہے۔ یہ skill کے bodies load نہیں کرتا۔ جب آپ کی request آتی ہے تو یہ ایک لائن ہی اس فیصلے کی مکمل بنیاد ہوتی ہے کہ skill متعلقہ ہے یا نہیں۔ اس لیے مبہم description کے پیچھے موجود بہترین body کبھی پڑھی ہی نہیں جاتی۔

Description تیسرے شخص میں لکھیں۔ "Tests and reloads nginx safely" درست ہے۔ "I can help you with nginx" درست نہیں، کیونکہ یہ متن system prompt میں inject ہوتا ہے، جہاں first person سے ایسا لگتا ہے کہ model اپنے بارے میں بات کر رہا ہے۔

Description میں دو چیزیں شامل کریں: skill کیا کرتا ہے، اور یہ کن حالات میں لاگو ہوتا ہے۔ اہم use case پہلے رکھیں، کیونکہ Claude Code listing entry کو 1,536 characters پر truncate کرتا ہے۔ ایک اختیاری when_to_use field اضافی trigger phrases اور example requests کے لیے موجود ہے، اور اسے اسی حد کے اندر description کے آخر میں شامل کیا جاتا ہے۔

پھر وہی الفاظ استعمال کریں جو آپ حقیقت میں type کریں گے۔ description: Helps with nginx کسی چیز سے match نہیں کرتا، کیونکہ کوئی بھی "helps with" type نہیں کرتا۔ اوپر والا version /etc/nginx، server block، reverse proxy اور TLS (transport layer security) certificate path کا نام لیتا ہے، جو تقریباً ہر ایسی request کی vocabulary ہے جس سے اسے trigger ہونا چاہیے۔

Description کے لیے یہ test کریں۔ اس ایک لائن کو ایسے شخص کو دیں جس نے body کبھی نہیں دیکھی، اور ساتھ وہ request بھی دیں جو آپ type کرنے والے ہیں۔ اس سے پوچھیں کہ آیا skill لاگو ہوتا ہے۔ اگر وہ فیصلہ نہ کر سکے تو model بھی نہیں کر سکتا۔

باڈی مختصر رکھیں، کیونکہ یہ context میں برقرار رہتی ہے

جب کوئی skill invoke کی جاتی ہے تو اس کا rendered content ایک message کے طور پر conversation میں شامل ہو جاتا ہے اور session کے اختتام تک وہیں رہتا ہے۔ Claude Code بعد کی turns میں file کو دوبارہ read نہیں کرتا۔ آپ کی لکھی ہوئی ہر line صرف ایک answer کے لیے نہیں بلکہ پورے session کے لیے context cost بنتی ہے۔

Anthropic تجویز کرتا ہے کہ SKILL.md کو 500 lines سے کم رکھا جائے اور تفصیل الگ files میں منتقل کی جائے۔ Compaction سے واضح ہوتا ہے کہ یہ number بے بنیاد نہیں ہے۔ جب context خالی کرنے کے لیے conversation کا خلاصہ بنایا جاتا ہے تو Claude Code ہر skill کی حالیہ ترین invocation دوبارہ attach کرتا ہے، ہر skill کے صرف پہلے 5,000 tokens رکھتا ہے، اور مجموعی 25,000 token budget کو حالیہ ترین invoke کی گئی skill سے شروع کرکے بھرتا ہے۔ لمبی skill درمیان سے cut off ہو جاتی ہے۔ کئی لمبی skills ایک دوسرے کو مکمل طور پر context سے باہر کر دیتی ہیں۔

اس لیے صرف وہی لکھیں جو model پہلے سے نہیں جانتا۔ اسے معلوم ہے کہ nginx کیا ہے اور reverse proxy کیا کرتا ہے۔ اسے آپ کا مقامی rule معلوم نہیں کہ reload کو restart سے زیادہ ہونا چاہیے، اور یہی rule اس file کے وجود کی واحد وجہ ہے۔

اگر skill agent کو bundled script چلانے کی ہدایت دیتی ہے تو path کو ${CLAUDE_SKILL_DIR} کے ساتھ لکھیں، تاکہ skill جہاں بھی installed ہو وہاں path درست resolve ہو، اور اسی command کو پہلے سے approve کریں تاکہ run permission prompt پر نہ رک جائے۔

---
name: nginx-config-changes
description: Tests and reloads nginx safely after a config edit. Use when editing files under /etc/nginx, adding a server block or a reverse proxy, or changing a TLS certificate path.
allowed-tools: Bash(${CLAUDE_SKILL_DIR}/scripts/check-and-reload.sh *)
---

Grant اس turn پر لاگو ہوتا ہے جس میں skill invoke کی گئی تھی اور آپ کا اگلا message بھیجتے ہی clear ہو جاتا ہے، اس لیے یہ خاموشی سے مستقل permission نہیں بن جاتا۔

مہارت کے فعال ہونے کا ثبوت کیسے حاصل کریں

مہارت کے لوڈ ہونے کو دیکھنے سے معلوم ہوتا ہے کہ agent نے اسے تلاش کر لیا ہے۔ اس سے یہ معلوم نہیں ہوتا کہ جواب تبدیل بھی ہوا ہے۔ دونوں چیزیں چیک کریں، اور یہ کام نئے session میں کریں، کیونکہ جس session میں آپ نے مہارت لکھی تھی، اس میں لکھتے وقت فراہم کی گئی تمام معلومات پہلے سے موجود ہوتی ہیں۔ یہ باقی ماندہ context فائل کی خامیوں کو چھپا دیتا ہے۔

1. project میں claude کے ساتھ نیا session شروع کریں۔
2. درخواست عام کام کے دن کی طرح اپنے الفاظ میں لکھیں، اور مہارت کا نام نہ لیں۔
3. invocation دیکھیں۔ اگر مہارت فعال نہ ہو تو description درست کریں۔ ابھی body مسئلہ نہیں ہے۔
4. بطور control اسے /nginx-config-changes کے ساتھ دستی طور پر invoke کریں۔ اگر دستی invocation پر درست رویہ ہو، لیکن درخواست پر غلط رویہ ہو، تو اس سے instruction کے بجائے trigger کے مسئلے کی تصدیق ہوتی ہے۔
5. مہارت بند کرکے یہی درخواست دوبارہ چلائیں اور دونوں جوابات کا موازنہ کریں۔ /skills menu میں مہارت کو highlight کریں، اس کی حالت off کرنے کے لیے Space دبائیں، پھر محفوظ کرنے کے لیے Enter دبائیں۔ اس سے .claude/settings.local.json میں skillOverrides entry لکھی جاتی ہے، اور کام مکمل ہونے پر Space دوبارہ دبانے سے حالت واپس on ہو جاتی ہے۔
6. ایسی دو تین درخواستیں لکھیں جن پر مہارت فعال نہیں ہونی چاہیے، اور چیک کریں کہ وہ خاموش رہتی ہے۔

اس عمل کو خودکار بنانے کے لیے official marketplace سے skill-creator plugin install کریں۔

/plugin marketplace add anthropics/claude-plugins-official
/plugin install skill-creator@claude-plugins-official

اگر install output میں Run /reload-plugins to activate. لکھا ہو تو وہ command چلائیں۔ پھر Claude سے کہیں کہ وہ آپ کی مہارت کا نام لے کر جائزہ لے۔ plugin ٹیسٹ cases کو skill directory کے اندر evals/evals.json میں محفوظ کرتا ہے اور ہر case کو اپنے subagent میں چلاتا ہے، اس لیے ہر run صاف context سے شروع ہوتا ہے۔ اس کے بعد یہ with-skill اور without-skill کا موازنہ لکھتا ہے۔ یہی قابلِ اعتماد عدد ہے: pass rate میں بہتری، جسے مہارت کے استعمال ہونے والے tokens اور وقت کے مقابلے میں ناپا جاتا ہے۔

مہارت اپنا ثبوت بھی شامل کر سکتی ہے، بجائے اس کے کہ یہ کام الگ eval run پر چھوڑا جائے۔ Old Coder skill یہی کرتی ہے، جب وہ agent سے evidence report واپس لینے کو کہتی ہے جسے آپ خود دوبارہ چلا سکتے ہیں۔

ناکامی کی صورت: skill کبھی trigger نہیں ہوتی

آپ request لکھتے ہیں، agent پرانا غلط کام کرتا ہے، اور کوئی skill line ظاہر نہیں ہوتی۔ ان نکات کو اسی ترتیب سے دیکھیں۔

• Description میں skill کے کام کی وضاحت ہوتی ہے، لیکن یہ نہیں بتایا جاتا کہ اسے کب استعمال کرنا ہے، اس لیے آپ کی request میں کچھ بھی اس سے match نہیں ہوتا۔
• Description میں وہ الفاظ شامل نہیں ہوتے جو آپ لکھتے ہیں۔ اگر آپ "nginx" کہتے ہیں تو description میں nginx بھی ہونا چاہیے۔
• disable-model-invocation: true frontmatter میں set ہے۔ اس سے description مکمل طور پر model کے context سے باہر رہتی ہے، اور skill صرف آپ کے ذریعے /name کے ساتھ invoke ہو سکتی ہے۔
• Frontmatter میں موجود paths glob activation کو matching files تک محدود کرتا ہے، جبکہ آپ جس file پر کام کر رہے ہیں وہ match نہیں کرتی۔
• skill آپ کی starting directory کے اندر nested .claude/skills/ directory میں موجود ہے۔ یہ skills اس وقت تک load نہیں ہوتیں جب تک agent اس subdirectory کے اندر موجود file کو read یا edit نہ کرے، اس لیے اس سے پہلے skill بالکل دستیاب نہیں ہوتی۔

Failure mode: skill بار بار فعال ہو جاتی ہے

اس کے برعکس مسئلہ اس وقت پیدا ہوتا ہے جب description اتنی وسیع ہو کہ skill غیر متعلقہ کاموں پر بھی فعال ہو جائے۔ "Use when working on the server" سرور repository میں تقریباً ہر request سے مطابقت رکھتا ہے۔ اس کے بعد body ایسے tasks پر بھی load ہو جاتی ہے جن میں یہ مدد نہیں کر سکتی، اور باقی session کے دوران context میں موجود رہتی ہے۔

description کو اس condition تک محدود کریں جو حقیقتاً اہم ہے، اور ان files یا commands کے نام درج کریں جن پر یہ لاگو ہوتی ہے۔ اگر skill صرف مخصوص files پر لاگو ہوتی ہے تو paths glob شامل کریں۔ deploy یا commit جیسے side effects والے ہر کام کے لیے disable-model-invocation: true set کریں اور اسے خود /name کے ذریعے invoke کریں، تاکہ agent اپنے طور پر یہ فیصلہ نہ کرے کہ deploy کرنے کا وقت آ گیا ہے۔

ناکامی کی صورت: skill آپ کی rules file میں شامل ہونی چاہیے

CLAUDE.md یا AGENTS.md جیسی rules file ہر session کے آغاز پر load ہوتی ہے اور ہر task پر لاگو ہوتی ہے۔ skill body صرف اس وقت load ہوتی ہے جب skill فعال ہو۔ فیصلہ frequency کی بنیاد پر ہوتا ہے۔ ایسی حقیقت جو repository کے ہر task پر لاگو ہو، مثلاً آپ کا استعمال کردہ package manager، rules file میں ہونی چاہیے۔ ایسا طریقۂ کار جو tasks کے ایک محدود حصے پر لاگو ہو، مثلاً اوپر دیا گیا nginx rule، skill میں ہونا چاہیے؛ ان دنوں اس کی کوئی لاگت نہیں ہوتی جب کوئی nginx میں ترمیم نہ کر رہا ہو۔

اصل ناکامی اسے دونوں جگہ شامل کرنا ہے۔ دونوں نقول وقت کے ساتھ مختلف ہو جاتی ہیں، اور جب agent غلط عمل کرتا ہے تو یہ معلوم نہیں ہو پاتا کہ اس نے کس نقل کی پیروی کی۔ ہر instruction کے لیے ایک ہی جگہ منتخب کریں۔ ایسا rule جو پہلے ہی صرف ایک جگہ موجود ہو اور پھر بھی نظرانداز ہو جائے، ایک الگ مسئلہ ہے۔ اسے skill میں منتقل کرنے اور یہ امید رکھنے سے پہلے کہ منتقلی مسئلہ حل کر دے گی، نظرانداز شدہ instruction کے پسِ پردہ طریقۂ کار کا جائزہ لینا مفید ہے۔ skills، MCP servers اور rules files کے درمیان حد زیادہ پیچیدہ صورتوں میں کام آتی ہے، جن میں درست جواب MCP (model context protocol) server ہو سکتا ہے، جو agent کو نئی instruction کے بجائے نیا tool فراہم کرتا ہے۔

اسے اسی وقت شیئر کریں جب یہ اپنی افادیت ثابت کر دے

جو skill ایک ہفتہ حقیقی کام میں مؤثر ثابت ہو، اسے repository میں شامل کرنا مناسب ہے۔ .claude/skills/ میں موجود project skills کا code کی طرح جائزہ لیا جاتا ہے اور وہ repository کے ساتھ آتی ہیں، اس لیے جو teammate اسے clone کرتا ہے اسے آپ کی اصلاح بغیر کسی اضافی setup کے مل جاتی ہے۔ کسی skill کو copy اور paste کے بغیر ایک repository سے دوسری repository میں منتقل کرنا الگ مسئلہ ہے، جس کا احاطہ repositories کے درمیان agent skills شیئر کرنے کا طریقہ میں کیا گیا ہے۔

قابلِ نقل پذیری سے متعلق ایک اہم نکتہ ہے۔ Claude Code frontmatter کے بہت سے fields قبول کرتا ہے، لیکن Agent Skills standard صرف چھ fields کی اجازت دیتا ہے: name، description، license، compatibility، metadata اور allowed-tools۔ اگر frontmatter میں ان کے علاوہ کوئی field موجود ہو اور آپ skill کو claude.ai پر upload کریں یا اسے Skills API کے لیے package کریں، تو وہ field کو نظرانداز کرنے کے بجائے مکمل طور پر fail ہو جاتی ہے:

Unexpected key(s) in SKILL.md frontmatter: argument-hint. Allowed properties are: allowed-tools, compatibility, description, license, metadata, name

ان چھ fields تک محدود رہیں تو یہی file Claude Code اور standard پڑھنے والی دیگر تمام جگہوں پر load ہو جاتی ہے۔ تاہم file کہاں load ہوتی ہے، اس سے اب بھی طے ہوتا ہے کہ وہ کیا کر سکتی ہے، کیونکہ Cowork Anthropic sandbox میں چلتا ہے، جبکہ Claude Code آپ کی اپنی machine یا VPS پر چلتا ہے۔ اسی لیے اوپر والی nginx skill کو teammate کے checkout میں منتقل کرنا مفید ہے، لیکن ایسے sandbox میں بے فائدہ ہے جو server تک رسائی نہ رکھتا ہو۔ ہدایات کو اس طرح لکھنا کہ وہ مختلف model پر منتقلی کے بعد بھی مؤثر رہیں، الگ کام ہے، اور ایسی skills لکھنا جو کسی بھی model کے ساتھ کام کریں اس کا احاطہ کرتا ہے۔

FAQ

SKILL.md فائل کتنی طویل ہونی چاہیے؟

اسے 500 لائنوں سے کم رکھیں، اور توقع رکھیں کہ زیادہ تر مفید skills اس سے کافی مختصر ہوں گی۔ skill invoke ہونے پر اس کا متن conversation میں شامل ہو جاتا ہے اور باقی session کے دوران موجود رہتا ہے۔ اس لیے ہر لائن ایک بار کی نہیں بلکہ بار بار آنے والی لاگت ہے۔ طویل reference material کو skill directory کی الگ files میں منتقل کریں اور انہیں SKILL.md سے ایک ہی سطح کی گہرائی پر link کریں، تاکہ agent انہیں صرف ضرورت کے وقت پڑھے۔ Bundled scripts کو پڑھنے کے بجائے execute کیا جاتا ہے، اس لیے ان کی لاگت صرف ان کے output تک محدود رہتی ہے۔

میری skill کبھی trigger کیوں نہیں ہوتی؟

عام طور پر وجہ description ہوتی ہے، کیونکہ model فیصلہ کرتے وقت skill کے صرف اسی حصے کو context میں دیکھتا ہے۔ یقینی بنائیں کہ description میں یہ بتایا گیا ہو کہ skill کب استعمال کرنی ہے، صرف یہ نہیں کہ وہ کیا کرتی ہے۔ اس میں وہ الفاظ بھی شامل کریں جو آپ اپنی requests میں واقعی لکھتے ہیں۔ اگر description درست معلوم ہو تو frontmatter میں disable-model-invocation: true چیک کریں، کیونکہ یہ skill کو model سے مکمل طور پر چھپا دیتا ہے۔ ساتھ ہی paths glob بھی چیک کریں، جو skill کو صرف ان files تک محدود کرتا ہے جنہیں آپ touch نہیں کر رہے۔ آپ کی starting directory کے اندر nested .claude/skills/ directory میں موجود skill بھی ایک وجہ ہو سکتی ہے۔ یہ صرف اس وقت load ہوتی ہے جب agent اس subdirectory میں موجود file کو read یا edit کرے۔

کیا اسے skill ہونا چاہیے یا میری rules file میں ایک لائن؟

دیکھیں کہ یہ آپ کے کتنے tasks پر لاگو ہوتی ہے۔ rules file ہر session میں load ہوتی ہے، اس لیے اس میں وہ facts ہونے چاہییں جو ہر task کے لیے درست ہوں، مثلاً package manager یا branch naming convention۔ skill صرف trigger ہونے پر load ہوتی ہے، اس لیے یہ اس procedure کے لیے مناسب جگہ ہے جو tasks کے ایک چھوٹے حصے میں اہم ہو۔ ایک ہی instruction دونوں جگہ کبھی نہ لکھیں، کیونکہ دونوں copies میں وقت کے ساتھ فرق آ جاتا ہے اور آپ یہ متعین نہیں کر پاتے کہ agent نے کون سی copy follow کی۔

مجھے کیسے معلوم ہوگا کہ skill نے واقعی مدد کی؟

اسے baseline کے ساتھ compare کریں۔ چند حقیقی requests جمع کریں، ہر request کو skill دستیاب ہونے کے ساتھ ایک fresh session میں چلائیں، پھر /skills menu سے skill کو switch off کر کے انہیں دوبارہ چلائیں، اور دونوں answers کو ساتھ ساتھ پڑھیں۔ fresh session ضروری ہے، کیونکہ جس conversation میں آپ نے skill لکھی تھی اس میں آپ کی explanations اب بھی موجود ہوتی ہیں۔ اس سے ایک نامکمل file بھی مکمل دکھائی دے سکتی ہے۔ skill-creator plugin یہ comparison آپ کے لیے چلاتا ہے اور token cost کے ساتھ pass rate رپورٹ کرتا ہے۔

کیا میں یہی SKILL.md کسی مختلف agent کے ساتھ استعمال کر سکتا ہوں؟

ہاں، بشرطیکہ آپ Agent Skills standard میں بیان کردہ fields تک محدود رہیں: name، description، license، compatibility، metadata اور allowed-tools۔ Claude Code کئی مزید fields قبول کرتا ہے، اور یہ body features بھی support کرتا ہے، مثلاً shell command injection، جنہیں دوسرے tools execute نہیں کرتے۔ standard سے باہر کسی field والی skill upload کرنے پر allowed properties کی فہرست کے ساتھ واضح error آتا ہے۔ اس لیے ابتدا ہی میں طے کریں کہ skill صرف Claude Code میں رہنی ہے یا مختلف tools کے درمیان منتقل کی جائے گی۔