Agent skills، MCP servers یا rules files: کیا چنیں؟

ایجنٹ skills بمقابلہ MCP servers بمقابلہ rules files: مختصر جواب

ایجنٹ skills، MCP servers اور rules files سبھی coding agent کے سامنے معلومات رکھتے ہیں۔ انتخاب اس بات کی بنیاد پر کریں کہ یہ معلومات کیا کام کرتی ہیں۔ MCP (model context protocol) ایسے data کے لیے ہے جو اگلی بار دیکھنے پر مختلف ہو سکتا ہے۔ skill ایسے طریقۂ کار کے لیے ہے جسے آپ آج لکھ سکتے ہیں اور چھ ہفتے بعد بھی وہ درست رہے گا۔ rules file ان چند facts کے لیے ہے جو ہر session میں لازماً برقرار رہنے چاہییں۔

اس انتخاب کی ایک قیمت ہے، اور وہ قیمت context ہے۔ agent کو درکار نہ ہونے والی instruction پر خرچ ہونے والا ہر token اس code کے لیے دستیاب نہیں رہتا جسے agent پڑھ رہا ہے۔ ہر turn پر اس token کی قیمت دوبارہ ادا ہوتی ہے، کیونکہ ہر request کے ساتھ مکمل context window دوبارہ بھیجی جاتی ہے۔ اس لیے مفید سوال یہ نہیں کہ کون سا mechanism یہ کام کر سکتا ہے۔ اکثر دنوں میں تینوں یہ کام کر سکتے ہیں۔ سوال یہ ہے کہ idle رہتے ہوئے کون سا mechanism سب سے کم لاگت رکھتا ہے۔

استعمال سے پہلے ہر ایک کی لاگت

یہ تینوں مختلف اوقات میں لوڈ ہوتے ہیں، اور اصل فرق اسی وقت بندی سے پیدا ہوتا ہے۔

rules file آغاز کے وقت مکمل طور پر لوڈ ہوتی ہے، ہر session میں، خواہ متعلقہ ہو یا نہ ہو۔ Claude Code ہر conversation کے آغاز پر CLAUDE.md پڑھتا ہے اور لمبائی سے قطع نظر اسے مکمل طور پر لوڈ کرتا ہے۔ دستاویزی ہدف ہر file کے لیے 200 lines سے کم ہے، کیونکہ بڑی file زیادہ context استعمال کرتی ہے اور اس کی ہدایات پر کم مستقل مزاجی سے عمل ہوتا ہے۔ یہ دونوں اثرات ایک ہی سمت میں کام کرتے ہیں، اسی لیے 900-line rules file فائدے کے بجائے نقصان دہ ہوتی ہے۔

skill دو مراحل میں لوڈ ہوتی ہے۔ startup کے وقت ہر SKILL.md frontmatter سے صرف description line context میں شامل ہوتی ہے، تاکہ model کو معلوم ہو کہ skill موجود ہے اور تقریباً کب لاگو ہوتی ہے۔ body اس وقت لوڈ ہوتی ہے جب skill invoke کی جاتی ہے۔ اس لیے 400-line reference document اس وقت تک تقریباً کوئی لاگت نہیں ڈالتا جب تک اس کی ضرورت نہ ہو۔

MCP server پہلے مہنگا option ہوا کرتا تھا، اور اب آپ جو زیادہ تر موازنے پڑھیں گے وہ اسی وجہ سے پرانے ہو چکے ہیں۔ موجودہ Claude Code میں tool search default طور پر فعال ہے۔ session کے آغاز پر صرف tool names اور server کا instructions field لوڈ ہوتا ہے، جبکہ مکمل JSON (JavaScript object notation) schemas اس وقت تک مؤخر رہتے ہیں جب تک Claude انہیں search نہ کرے۔ اب server شامل کرنے پر ابتدا ہی میں ہزاروں tokens خرچ نہیں ہوتے۔ پھر بھی کچھ لاگت رہتی ہے، اور جن configurations میں tool search بند ہو وہاں مکمل لاگت ابتدا ہی میں برداشت کرنا پڑتی ہے۔

[
  {
    "label": "Rules file, 200 lines",
    "at_startup": "2,500",
    "after_use": "2,500"
  },
  {
    "label": "Skill, 12 KB body",
    "at_startup": 40,
    "after_use": "3,000"
  },
  {
    "label": "MCP server, tool search on",
    "at_startup": 500,
    "after_use": "3,200"
  },
  {
    "label": "MCP server, tool search off",
    "at_startup": "4,500",
    "after_use": "4,500"
  }
]

یہ اندازے ہیں، آپ کی machine سے حاصل کی گئی measurements نہیں۔ یہ اس text کے حجم پر مبنی ہیں جسے ہر mechanism لوڈ کرتا ہے، اور تقریباً ہر token کے لیے چار characters کے حساب سے: 200-line rules file تقریباً 10 KB markdown ہوتی ہے، skill description تقریباً 160 characters پر مشتمل ہوتی ہے، اور 12 tools فراہم کرنے والا server تقریباً 18 KB schema کے علاوہ 2 KB instructions block رکھتا ہے۔ Claude Code ہر tool description اور ہر server instructions field کو 2 KB پر truncate کرتا ہے، اس لیے اس حصے کی زیادہ سے زیادہ حد مقرر ہے۔ اگلا section بتاتا ہے کہ اپنی حقیقی numbers کیسے پڑھیں۔

پہلی دو rows کو ساتھ پڑھیں۔ rules file ایسے session میں 2,500 tokens خرچ کرتی ہے جس میں کسی کو اس کی ضرورت نہیں تھی۔ اسی session میں skill 40 tokens خرچ کرتی ہے، اور ہر دس میں سے اس ایک session میں 3,000 tokens خرچ کرتی ہے جس میں یہ فعال ہوتی ہے۔ آخری دو rows ایک ہی server کو دو بار دکھاتی ہیں، tool search کے فعال اور غیر فعال ہونے کی صورت میں: 500 tokens کے مقابلے میں 4,500۔ یہی فرق ہے جس کی وجہ سے MCP context bloat کے بارے میں پرانا مشورہ اب بھی گردش میں ہے۔

Tool search کے لیے ایسے model کی ضرورت ہوتی ہے جو tool_reference blocks کو support کرتا ہو۔ August 2026 تک اس میں Claude Sonnet 4.5، Haiku 4.5، Opus 4.5 اور اس کے بعد کے models شامل ہیں۔ جب ANTHROPIC_BASE_URL ایسے host کی طرف اشارہ کرے جو first party نہ ہو تو Claude Code اسے بند کر دیتا ہے، کیونکہ زیادہ تر proxies ان blocks کو آگے منتقل نہیں کرتے۔ اسے control کرنے کے لیے ENABLE_TOOL_SEARCH set کریں: false ہر schema کو ابتدا ہی میں لوڈ کرتا ہے، true سبھی schemas کو مؤخر کرتا ہے، اور auto انہیں صرف اس وقت ابتدا ہی میں لوڈ کرتا ہے جب وہ context window کے 10% کے اندر آ جائیں۔

# Load schemas up front only if they fit in 5% of the window
ENABLE_TOOL_SEARCH=auto:5 claude

فیصلہ کن سوال یہ ہے: کیا ہر بار استعمال کرنے پر ڈیٹا تبدیل ہو جاتا ہے؟

یہ سوال پہلے پوچھیں، کیونکہ اس سے ایک اختیار فوراً خارج ہو جاتا ہے۔ اگر agent کو ایسی چیز پڑھنے یا لکھنے کی ضرورت ہو جو اگلی بار دیکھنے پر مختلف ہو سکتی ہے، تو آپ کو server درکار ہے۔ مثلاً issue tracker، database، monitoring dashboard، یا آپ کی اپنی internal API (application programming interface)۔ اسے لکھ کر رکھ دینے سے مسئلہ حل نہیں ہوتا، کیونکہ کوئی دوسرا شخص record میں ترمیم کرتے ہی آپ کی لکھی ہوئی معلومات پرانی ہو جاتی ہے۔

اگر کوئی شخص اسے maintain نہ کرے تب بھی چھ ہفتے بعد جواب درست رہے گا، تو آپ کو skill چاہیے۔ مثلاً release checklist، migration procedure، error responses کی ساخت، یا اس repository میں tests لکھنے کا مطلوبہ طریقہ۔ skill، git میں موجود ایک file ہوتی ہے۔ اس کا کوئی port یا process نہیں ہوتا، اور اس کی واحد failure mode غلط ہونا ہے، جسے code review پکڑ سکتا ہے۔

اگر یہ ایک ایسی حقیقت ہے جس کا اطلاق ایسے کام پر ہونا ہے جس کے بارے میں آپ نے ابھی سوچا بھی نہیں، تو اسے rules file میں رکھیں۔ Run make lint before committing. Never push to main. Handlers live in src/api/handlers/. ہر سطر میں ایک حقیقت لکھیں۔ جیسے ہی کسی entry میں steps شامل ہونے لگیں، وہ حقیقت نہیں رہتی بلکہ procedure بن جاتی ہے، اور اسے skill میں منتقل کر دینا چاہیے۔

جب rules file کافی ہو

Rules files کئی مقامات سے load ہوتی ہیں۔ ترجیح وسیع ترین سے مخصوص ترین ترتیب میں ہوتی ہے: managed policy file، آپ کی ذاتی ~/.claude/CLAUDE.md، project کی ./CLAUDE.md یا ./.claude/CLAUDE.md، اور gitignored ./CLAUDE.local.md۔ دریافت ہونے والی تمام files ایک دوسرے کو override کرنے کے بجائے باہم concatenate ہوتی ہیں، اور working directory کے قریب موجود files آخر میں پڑھی جاتی ہیں۔

Claude Code، AGENTS.md کے بجائے CLAUDE.md پڑھتا ہے۔ اگر آپ کی repository میں دوسرے tools کے لیے پہلے ہی AGENTS.md موجود ہے تو دو ایسی copies برقرار نہ رکھیں جو وقت کے ساتھ مختلف ہو جائیں۔

ln -s AGENTS.md CLAUDE.md

Symlink کامیابی کی صورت میں کچھ بھی print نہیں کرتا۔ ایک session شروع کریں، /context چلائیں، اور تصدیق کریں کہ Memory files کے تحت CLAUDE.md ظاہر ہوتا ہے۔ اگر یہ وہاں درج نہیں ہے تو agent نے اسے کبھی نہیں دیکھا، اور الفاظ بدلنے سے کوئی فائدہ نہیں ہوگا۔ اگر آپ Claude-specific lines بھی شامل کرنا چاہتے ہیں تو اس کے بجائے import form استعمال کریں اور انہیں import کے نیچے رکھیں۔

@AGENTS.md

## Claude Code

Use plan mode for changes under `src/billing/`.

یہاں ایک اہم غلط فہمی ہے۔ @path imports context محفوظ نہیں کرتے۔ Imported file کو launch کے وقت اس file کے ساتھ expand اور load کیا جاتا ہے جس نے اسے reference کیا ہو، زیادہ سے زیادہ چار hops کی گہرائی تک۔ 600-line rules file کو چھ imports میں تقسیم کرنے سے اسے انسانوں کے لیے منظم کیا جا سکتا ہے، لیکن token cost میں بالکل کوئی تبدیلی نہیں آتی۔ AGENTS.md اور اس کے انسانی استعمال کے لیے بنائے گئے متبادل کے پسِ پشت اصول layout طے کرنے سے پہلے پڑھ لینا مفید ہے۔

Cost کم کرنے کے لیے .claude/rules/ کو paths field کے ساتھ استعمال کریں۔ paths frontmatter والی rule file صرف اسی وقت load ہوتی ہے جب agent ایسے file کو touch کرے جو patterns میں سے کسی ایک سے match کرتی ہو۔

---
paths:
  - "src/api/**/*.ts"
---

# API rules

- Every endpoint validates its input.
- Use the standard error response shape.

paths field کے بغیر rule، .claude/CLAUDE.md جیسی ہی priority کے ساتھ launch کے وقت load ہوتی ہے۔ اس لیے عملی طریقہ یہ ہے کہ مختصر unconditional rules رکھیں، اور ایسی چیز کے لیے paths list شامل کریں جو صرف ایک directory کے اندر متعلق ہو۔

جب آپ کو کوئی skill درکار ہو

skill ایک directory ہوتی ہے جس میں SKILL.md موجود ہوتا ہے۔ ذاتی skills، ~/.claude/skills/<name>/SKILL.md میں رہتی ہیں اور آپ کی مشین کے ہر project پر لاگو ہوتی ہیں۔ project skills، .claude/skills/<name>/SKILL.md میں رہتی ہیں، repository کے ساتھ منتقل ہوتی ہیں، اور دیگر files کی طرح pull request میں review کی جا سکتی ہیں۔

mkdir -p ~/.claude/skills/summarize-changes

---
name: summarize-changes
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff.
---

Run `git status` and `git diff` against the merge base.
Group the changes by intent, not by file.
Call out anything touching auth, migrations or deletions.

description اس file کا واحد حصہ ہے جو skill کے چلنے سے پہلے context میں موجود ہوتا ہے، اس لیے یہ دو کام کرتا ہے۔ یہ بتاتا ہے کہ skill کیا کرتی ہے، اور یہ بھی بتاتا ہے کہ اسے کب استعمال کرنا ہے۔ "Helps with deploys" جیسی description model کو request کے ساتھ مطابقت پیدا کرنے کے لیے کوئی معلومات نہیں دیتی۔ نتیجتاً skill خاموشی سے کبھی invoke نہیں ہوتی، اور آپ یہ نتیجہ نکالتے ہیں کہ skills کام نہیں کرتیں۔

directory کا نام command بن جاتا ہے، اس لیے اوپر دی گئی مثال میں آپ کو /summarize-changes ملتا ہے۔ personal یا project skill میں frontmatter name صرف listings میں دکھایا جانے والا label مقرر کرتا ہے۔

skill invoke ہونے کے بعد اس کا rendered content ایک single message کے طور پر conversation میں شامل ہو جاتا ہے اور session کے باقی حصے میں موجود رہتا ہے۔ Claude Code بعد کی turns میں file دوبارہ نہیں پڑھتا۔ مستقل ہدایات لکھیں، one-time steps نہیں، اور body مختصر رکھیں، کیونکہ اس مرحلے کے بعد ہر line ہر request پر بار بار لاگت بنتی ہے۔ auto-compaction کے بعد Claude Code ہر skill کی حالیہ ترین invocation دوبارہ attach کرتا ہے۔ ہر skill کے پہلے 5,000 tokens کو مشترکہ 25,000 tokens کے budget میں رکھا جاتا ہے۔ ایک session میں کئی بڑی skills invoke کرنے پر سب سے پرانی skills مکمل طور پر خارج ہو جاتی ہیں۔ اسی وجہ سے طویل conversation کے بعد کوئی skill غیر مؤثر محسوس ہو سکتی ہے۔ اسے دوبارہ invoke کریں، تو یہ واپس آ جاتی ہے۔ جب ایک ہی procedure ایک سے زیادہ codebase پر لاگو ہو، تو file کی نقول بنانے کے بجائے متعدد repositories میں ایک skill شیئر کریں۔

MCP سرور کی ضرورت کب ہوتی ہے

اسے شامل کرنا ایک ہی command سے ممکن ہے، جبکہ transport اس کی ساخت طے کرتا ہے۔

# Remote HTTP server
claude mcp add --transport http notion https://mcp.notion.com/mcp

# Remote HTTP server behind a bearer token
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

# Local stdio server: everything after -- is passed through untouched
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
  -- npx -y airtable-mcp-server

-- اہم ہے۔ stdio سرور کے لیے یہ Claude Code کے اپنے options کو وہ command line سے الگ کرتا ہے جو آپ کے سرور کو شروع کرتی ہے۔ اسے چھوڑ دینے پر سرور کے لیے مقررہ --port 8080 کو claude mcp add کے option کے طور پر parse کیا جاتا ہے، اور claude mcp add اسے مسترد کر دیتا ہے۔

claude mcp list
claude mcp get notion

claude mcp add ایک Added ... line کے ذریعے تصدیق کرتا ہے، جو صرف یہ بتاتی ہے کہ configuration disk پر لکھ دی گئی ہے۔ claude mcp list وہ command ہے جو اصل صورتِ حال بتاتی ہے، کیونکہ یہ ہر سرور کے ساتھ health status دکھاتا ہے: ✔ Connected، ! Needs authentication، یا ✘ Failed to connect۔ failure status کا مطلب ہے کہ Claude Code اس سرور تک نہیں پہنچ سکا، یہ نہیں کہ list command ناکام ہو گئی۔ session کے اندر /mcp ہر سرور کے لیے یہی معلومات اور اس کے tools کی تعداد دکھاتا ہے۔

MCP سرور کو کی جانے والی ہر call مستقل ہوتی ہے اور اس میں اپنی ضرورت کا تمام data شامل ہوتا ہے۔ اسی لیے MCP سرور آپ کی پچھلی request یاد نہیں رکھتا۔ یہ ایک design choice ہے، جس کا نتیجہ آپ کو قبول کرنا ہوتا ہے: برقرار رکھنے کے قابل ہر state سرور کے پیچھے، database یا file میں موجود ہونی چاہیے، اور اب اس کی operation آپ کی ذمہ داری ہے۔

ایک MCP server ایک ایسا process ہے جسے آپ کو چلانا ہوتا ہے

یہ وہ لاگت ہے جسے vendor comparisons میں شامل نہیں کیا جاتا۔ ایک skill ایک file ہوتی ہے۔ MCP server ایسا software ہوتا ہے جو کہیں چلتا ہے، اور جب وہ جگہ آپ کا VPS (virtual private server) ہو تو اس کی uptime کی ذمہ داری آپ کی ہوتی ہے۔

stdio server سستا معاملہ ہے۔ session شروع ہونے پر Claude Code اسے child process کے طور پر شروع کرتا ہے، اور session ختم ہونے پر یہ process ختم ہو جاتا ہے۔ آپ کو اسے monitor کرنے یا اس کے اپنے schedule کے مطابق patch کرنے کی ضرورت نہیں ہوتی۔ remote HTTP server ایک طویل مدت تک چلنے والی service ہوتی ہے، اور اسے وہ تمام انتظام درکار ہوتا ہے جو کسی بھی ایسی service کے لیے ضروری ہوتا ہے۔

[Unit]
Description=Notes MCP server
After=network-online.target
Wants=network-online.target

[Service]
User=mcp
WorkingDirectory=/srv/notes-mcp
ExecStart=/usr/bin/node /srv/notes-mcp/dist/server.js
Environment=PORT=8931
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now notes-mcp
systemctl is-active notes-mcp
journalctl -u notes-mcp -n 50 --no-pager

systemctl is-active کو active دکھانا چاہیے۔ اگر یہ failed دکھائے تو journal میں اس کی وجہ موجود ہوگی، اور پہلی بار run کرنے پر وجہ تقریباً ہمیشہ missing environment variable یا ایسا port ہوتا ہے جسے کوئی دوسری چیز پہلے ہی استعمال کر رہی ہو۔ یہاں Restart=on-failure اختیاری نہیں ہے، کیونکہ crashed MCP server خود اپنی خرابی کی اطلاع نہیں دیتا۔ آپ کو اس وقت معلوم ہوتا ہے جب agent بتاتا ہے کہ وہ آپ کے issue tracker کو پڑھ نہیں سکتا۔

process کو 127.0.0.1 پر bind کریں اور اس کے سامنے TLS (transport layer security) کے ساتھ reverse proxy رکھیں۔ ایسا MCP server جو آپ کے database تک رسائی رکھتا ہو اور authentication کے بغیر public port پر جواب دیتا ہو، دراصل وہ database ہے جسے آپ نے public کر دیا ہے۔ VPS پر MCP server چلانا proxy، certificate اور firewall کے پہلوؤں کا درست طریقے سے احاطہ کرتا ہے۔

اس کے بعد recurring کام کا دیانت داری سے حساب کریں۔ service اپنے security updates اپنے schedule کے مطابق حاصل کرتی ہے، جو اس agent سے الگ ہوتا ہے جو اس سے رابطہ کرتا ہے۔ اس کا OAuth token expire ہو جاتا ہے، اور claude mcp list کسی نامناسب وقت پر ! Needs authentication دکھانا شروع کر دیتا ہے۔ اس کی credentials کسی config file یا Authorization header میں موجود ہوتی ہیں، اس لیے انہیں بھی ہر دوسرے secret جیسی احتیاط درکار ہوتی ہے۔ یہ الگ موضوع ہے: secrets کو AI agent کی رسائی سے دور رکھنا۔ skill کے لیے ان میں سے کوئی کام درکار نہیں ہوتا۔

اسے build کرنے سے پہلے متبادل کے مقابلے میں اس کی لاگت کا جائزہ لیں۔ اگر مجوزہ server کے پیچھے موجود data تقریباً ہر quarter میں ایک بار تبدیل ہوتا ہے تو agent کو یہ بتانے والی skill کہ اسے کہاں دیکھنا ہے اور fields کا مطلب کیا ہے، ایسی service سے سستی ہوگی جسے آپ کو مسلسل چلتا رکھنا پڑتا ہے۔

اپنے context cost کی پیمائش کیسے کریں

اندازہ لگانا بند کریں اور session کے اندر /context چلائیں۔ یہ startup breakdown دکھاتا ہے: system prompt، memory files، tools اور MCP servers، ساتھ ہی ہر جزو کا token weight بھی۔

دو چیزیں چیک کریں۔ Memory files کے تحت تصدیق کریں کہ آپ کی توقع کے مطابق ہر rules file درج ہے۔ جو file موجود نہ ہو وہ agent کو نظر نہیں آتی، اس لیے instructions نظرانداز ہونے کی صورت میں سب سے پہلے اسی امکان کو خارج کریں۔ پھر دیکھیں کہ آپ کے servers کتنے tokens استعمال کرتے ہیں۔ اگر کوئی server، جسے آپ مہینے میں صرف دو مرتبہ استعمال کرتے ہیں، اس فہرست کی بڑی entries میں شامل ہے تو اسے /mcp میں off کر دیں اور ضرورت والے sessions کے لیے دوبارہ on کر دیں۔ configuration دونوں صورتوں میں محفوظ رہتی ہے۔

Remote server cached 2h ago · connects on first use · 5 tools جیسی status بھی رپورٹ کر سکتا ہے۔ اس کا مطلب ہے کہ Claude Code نے startup پر connect کرنے کے بجائے پچھلے session سے tool list پڑھی ہے، اور پہلی مرتبہ کوئی tool call ہونے پر connect کرے گا۔ tools پہلے message سے دستیاب ہیں، اس لیے کچھ درست کرنے کی ضرورت نہیں۔ اگر آپ چاہتے ہیں کہ ہر server startup پر connect ہو تو MCP_DISCOVERY_CACHE=0 set کریں۔ مزید تفصیل کے لیے Claude Code context window کا انتظام میں بتایا گیا ہے کہ compaction کے بعد کیا محفوظ رہتا ہے، جبکہ ان tokens کی اصل لاگت کیا ہے ان اعداد کو رقم میں تبدیل کرتا ہے۔

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

عام وجہ description ہے۔ skill کے چلنے سے پہلے context میں صرف یہی متن موجود ہوتا ہے۔ اگر اس میں صورتحال کا نام نہ ہو تو کوئی match نہیں ہوتا۔ Trigger کو جملے میں شامل کریں: "اس وقت استعمال کریں جب صارف پوچھے کہ کیا تبدیل ہوا ہے، commit message چاہے، یا اپنے diff کا جائزہ لینے کو کہے۔" مبہم descriptions خاموشی سے ناکام ہوتی ہیں، اس لیے اس مسئلے کا پتا چلانا مشکل ہوتا ہے۔

دوسری وجہ frontmatter میں typo ہے، اور اس کا نتیجہ واضح ہوتا ہے۔ نامعلوم key کو فوراً مسترد کر دیا جاتا ہے:

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

تیسری وجہ location ہے۔ Project skills آپ کی working directory میں .claude/skills/ اور repository root تک ہر parent directory سے load ہوتی ہیں۔ آپ کے شروع کردہ مقام کے نیچے موجود nested directories کی skills launch کے وقت load نہیں ہوتیں۔ Agent پہلی بار اس subdirectory کے اندر کسی file کو پڑھنے یا edit کرنے پر یہ skills load کرتا ہے۔ اس وقت تک یہ autocomplete میں ظاہر نہیں ہوتیں اور نام سے invoke نہیں کی جا سکتیں۔

MCP میں اس خاموش failure کے مساوی صورت حال .mcp.json entry ہے جس میں url موجود ہو لیکن type نہ ہو۔ Claude Code ایسی ہر entry کو جس میں type نہ ہو، stdio server سمجھتا ہے۔ اس لیے وہ entry کو skip کر دیتا ہے اور یہ message دکھاتا ہے:

MCP server "notes" has a "url" but no "type"; add "type": "http" (or "sse" / "ws") to this entry

تینوں کو ایک ساتھ استعمال کرنا

یہ طریقۂ کار ایک ہی جگہ کے لیے باہم مقابلہ نہیں کرتے۔ مؤثر setup میں ہر طریقے کو وہاں استعمال کیا جاتا ہے جہاں اس کی لاگت کم ہو۔ rules file میں چند ایسی سطریں ہوتی ہیں جو ہر جگہ درست رہتی ہیں۔ skills میں طریقۂ کار شامل ہوتے ہیں اور انہیں صرف متعلقہ صورت میں load کیا جاتا ہے۔ ایک MCP server، اور کبھی کبھار دو، ان systems کو connect کرتے ہیں جن کے contents کا آپ پہلے سے اندازہ نہیں لگا سکتے۔ اگر آپ کو اب بھی پہلے طریقے کا ذہنی خاکہ بنانے میں دشواری ہو رہی ہے تو agent skill حقیقت میں کیا ہوتی ہے میں format کی تفصیل موجود ہے۔

کسی چیز کی مناسب جگہ کے بارے میں زیادہ تر اختلاف ایک test سے ختم ہو جاتا ہے۔ اسے delete کریں، نئی session شروع کریں، اور agent کو task دیں۔ اگر agent صرف سست ہو جائے تو وہ skill میں ہونی چاہیے تھی۔ اگر agent پُراعتماد انداز میں غلط جواب دے تو وہ rules file میں ہونی چاہیے تھی۔ اگر agent معلومات بالکل حاصل نہ کر سکے تو server درکار تھا، اور اب اس server کو چلتا رکھنے کا plan بھی درکار ہے۔

FAQ

کیا مجھے skill لکھنی چاہیے یا MCP server قائم کرنا چاہیے؟

فیصلہ اس بنیاد پر کریں کہ معلومات ایک invocation سے اگلی invocation تک تبدیل ہوتی ہیں یا نہیں۔ اگر agent کو live state پڑھنی ہو جس میں کوئی دوسرا شخص تبدیلی کر سکتا ہو، مثلاً issue tracker، database یا dashboard، تو آپ کو MCP server درکار ہے، کیونکہ record تبدیل ہوتے ہی لکھی ہوئی کوئی بھی معلومات پرانی ہو جاتی ہے۔ اگر آپ جواب ایک بار لکھ کر چھ ہفتے بعد بھی درست رکھ سکتے ہیں تو skill لکھیں۔ skill، git میں موجود ایک file ہوتی ہے؛ اسے چلانے کے لیے process، expose کرنے کے لیے port، یا update کرنے کے لیے patch schedule درکار نہیں ہوتا۔ اس لیے جہاں ممکن ہو، یہ کم لاگت والا انتخاب ہے۔

کیا MCP servers اب بھی میری context window بھر دیتے ہیں؟

پہلے کی نسبت بہت کم۔ موجودہ Claude Code میں tool search by default فعال ہے، اس لیے session کے آغاز پر صرف tool names اور server کا instructions field load ہوتا ہے۔ مکمل schemas اس وقت fetch کیے جاتے ہیں جب Claude انہیں search کرتا ہے۔ جب tool search بند ہو تو upfront loading اب بھی ہوتی ہے: ENABLE_TOOL_SEARCH=false کے ساتھ، ANTHROPIC_BASE_URL کو ایسے proxy کی طرف point کرنے پر جو first party نہ ہو، یا Claude 4.5 generation سے پرانے model پر۔ /context چلائیں تاکہ معلوم ہو سکے کہ آپ کس صورتِ حال میں ہیں، کیونکہ پرانی comparison posts میں موجود numbers upfront loading فرض کرتے ہیں۔

کیا Claude Code AGENTS.md پڑھتا ہے؟

نہیں۔ Claude Code CLAUDE.md پڑھتا ہے۔ اگر آپ کے repository میں پہلے ہی دوسرے agents کے لیے AGENTS.md موجود ہے تو دو copies رکھنے کے بجائے ایک کو دوسرے کی طرف point کریں۔ سادہ symlink کے لیے ln -s AGENTS.md CLAUDE.md چلائیں، یا CLAUDE.md کی پہلی line پر @AGENTS.md رکھیں اور اس کے نیچے Claude-specific instructions شامل کریں۔ پھر session شروع کریں اور /context چلائیں تاکہ تصدیق ہو جائے کہ CLAUDE.md، Memory files کے تحت ظاہر ہوتا ہے۔

session کے دوران میری skill نے اچانک اثر انداز ہونا کیوں چھوڑ دیا؟

عام طور پر اس کی وجہ auto-compaction ہوتی ہے۔ جب conversation کا خلاصہ بنایا جاتا ہے تو Claude Code ہر skill کی حالیہ ترین invocation دوبارہ attach کرتا ہے، اور ہر skill کے پہلے 5,000 tokens رکھتا ہے۔ تمام skills کے لیے مشترکہ budget 25,000 tokens ہوتا ہے۔ یہ budget سب سے حالیہ invoke کی گئی skill سے بھرنا شروع ہوتا ہے۔ اس لیے اگر آپ نے کئی بڑی skills invoke کی ہوں تو پرانی skills مکمل طور پر خارج ہو جاتی ہیں۔ skill کو دوبارہ invoke کریں تاکہ اس کا مکمل content بحال ہو جائے۔

میں ہر session میں طویل rules file load ہونے سے کیسے روکوں؟

وہ حصے جو صرف کبھی کبھار درکار ہوتے ہیں، paths field والی .claude/rules/ files میں منتقل کریں۔ اس طرح ہر file صرف اس وقت load ہوگی جب agent matching file کو استعمال کرے گا۔ file کو @path imports میں تقسیم کرنے سے مدد نہیں ملے گی، کیونکہ imported files کو launch کے وقت اس file کے ساتھ expand اور load کیا جاتا ہے جس نے ان کا حوالہ دیا ہو۔ جو چیز standing fact کے بجائے multi-step procedure ہو، اسے skill بنائیں، کیونکہ skill body کی کوئی لاگت اس وقت تک نہیں ہوتی جب تک اسے invoke نہ کیا جائے۔