নিজের agent skill কীভাবে লিখবেন ও পরীক্ষা করবেন

একটি বাস্তব ব্যর্থতা থেকে নিজের agent skill লিখুন

নিজের agent skill লেখার সবচেয়ে ভালো উপায় হলো একটি বাস্তব ব্যর্থতা থেকে সেটির মূল নিয়ম বের করা। আপনার coding agent যে কাজটি দুবার ভুল করেছে, এমন একটি কাজ খুঁজে নিন। দুইবার আপনি যে সংশোধন লিখেছিলেন, তা নোট করুন এবং সেই সংশোধনটি একটি SKILL.md ফাইল হিসেবে সংরক্ষণ করুন, যাতে agent নিজে সেটি load করতে পারে। এরপরের সবকিছুই প্রক্রিয়াগত: ফাইলের বিন্যাস এবং সেই একটি লাইন, যা নির্ধারণ করে skill কখনও সক্রিয় হবে কি না।

এই ক্রমটি গুরুত্বপূর্ণ। কল্পনা থেকে লেখা skill এমন একটি সমস্যার নথি তৈরি করে, যা আপনি কখনও মোকাবিলা করেননি। তবু প্রতিটি session-এ এটি context ব্যবহার করে। আপনি যে ব্যর্থতা নিজের চোখে দেখেছেন, তা থেকে তৈরি skill-এর সঙ্গে নিজস্ব test-ও থাকে: একই অনুরোধ আবার করুন এবং দেখুন, এবার agent সঠিকভাবে কাজ করে কি না। এই format আপনার কাছে নতুন হলে আগে agent skill কী এবং agent কীভাবে তা load করে তা পড়ুন, তারপর ফিরে এসে একটি skill লিখুন।

এমন একটি কাজ দিয়ে শুরু করুন যেটি এজেন্ট দুবার ভুল করেছে

একবার হলে তা কাকতালীয় হতে পারে। দুবার হলে তা একটি ধারা, আর এমন ধারার জন্য একটি ফাইল তৈরি করা উচিত।

বাস্তব সার্ভারে বারবার দেখা যায় এমন একটি ব্যর্থতার উদাহরণ এখানে আছে। আপনি এজেন্টকে nginx-এ একটি reverse proxy block যোগ করতে বললেন। এটি /etc/nginx/conf.d/app.conf সম্পাদনা করে, তারপর sudo systemctl restart nginx চালায়। সম্পাদনায় একটি typo থাকায় nginx চালু হতে অস্বীকার করে, এবং আপনি ঠিক না করা পর্যন্ত site বন্ধ থাকে:

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 পরীক্ষা করুন, তারপর restart-এর পরিবর্তে reload দিয়ে তা প্রয়োগ করুন। এক সপ্তাহ পরে, অন্য একটি কাজে একই ভুল আবার হলো। দ্বিতীয়বারের ঘটনাটিই সংকেত।

ব্যর্থতাটি সামনে থাকতেই দুটি বিষয় লিখে রাখুন: আপনি যে request টাইপ করেছিলেন এবং যে correction দিয়েছিলেন, ঠিক আপনার ব্যবহৃত শব্দে। এই দুটি লাইনই skill হয়ে ওঠে। request জানায় trigger-কে কী মেলাতে হবে। correction-এ skill-এর সম্পূর্ণ বিষয়বস্তু থাকে।

Anthropic-এর নিজস্ব authoring guidance-এও এটিই প্রথম নির্দেশনা। কোনো skill ছাড়া representative task-এ agent চালান, কোথায় এটি ব্যর্থ হয় তা নথিবদ্ধ করুন, তারপর সেই ব্যর্থতাগুলো ঠিক করার জন্য ন্যূনতম নির্দেশনা লিখুন। ব্যর্থতাগুলোই specification। তাই কোনো skill-এর সঙ্গে নির্দিষ্ট ব্যর্থতার যোগসূত্র দেখাতে না পারলে, সাধারণত সেই skill কারও প্রয়োজন ছিল না।

একই distillation-এর একটি worked example হিসেবে Ponytail এমন একটি পুনরাবৃত্ত ব্যর্থতাকে, যেখানে agent আপনার চাওয়ার চেয়ে অনেক বেশি কিছু rewrite করে, একটি skill-এ রূপান্তর করে নিজের skill লেখার আগে শুরু থেকে শেষ পর্যন্ত পড়তে পারেন।

একটি skill-এর গঠন

একটি skill হলো একটি directory, যাতে একটি required file থাকে।

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

SKILL.md-এ একটি frontmatter block থাকে। এতে YAML-এ লেখা কয়েকটি setting থাকে। YAML হলো Docker Compose file-এ ব্যবহৃত একই configuration format। এই block-টি --- marker-এর মধ্যে থাকে। এর পরে markdown-এ instructions থাকে। 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).

এই file-এ 20-এর কম line আছে, এবং এটিই একটি সম্পূর্ণ skill। অংশগুলো হলো:

• name: সর্বোচ্চ 64 characters। এতে শুধু lowercase letters, digits এবং hyphens থাকতে পারে। এতে claude বা anthropic শব্দ থাকতে পারবে না। personal বা project skill-এ এটি শুধু display label। আপনি যে command লিখবেন, সেটি directory name থেকে আসে। তাই এই skill-এর command হলো /nginx-config-changes।
• description: skill-টি কী করে এবং কখন ব্যবহার করতে হবে, তার বিবরণ। এর সর্বোচ্চ দৈর্ঘ্য 1,024 characters। এই line-টিই মূল কাজ করে। পরের section-এ শুধু এই বিষয়েই আলোচনা করা হয়েছে।
• Body: instructions। skill কার্যকর হওয়ার পরেই এটি load হয়।
• reference/: অতিরিক্ত file, যা agent প্রয়োজন অনুযায়ী পড়ে। SKILL.md থেকে এগুলোর link দিন এবং link এক level গভীরে রাখুন। কারণ একটি referenced file থেকে আরেকটি referenced file উল্লেখ করা হলে দ্বিতীয় file-টি অনেক সময় আংশিকভাবে পড়া হয়।
• scripts/: যে file agent পড়ার বদলে execute করে। শুধু তাদের output context ব্যবহার করে। তাই 300 line-এর একটি script-এর খরচ কম।

Directory-টি কোথায় রাখবেন, তার ওপর নির্ভর করে কারা skill-টি ব্যবহার করতে পারবে।

• Repository-তে .claude/skills/<name>/SKILL.md: শুধু এই 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 তৈরি করে file-টি লিখুন। Claude Code এই directory-গুলো monitor করে। তাই চলমান session-এর মধ্যে existing skill edit করলে পরিবর্তন কার্যকর হয়। Session শুরু হওয়ার সময় top-level skills directory না থাকলে সেটি তৈরি করার পর restart করতে হবে। কারণ session শুরু হওয়ার সময় monitor করার মতো directory ছিল না।

বিবরণী ফিল্ডটি ফাইলের সবচেয়ে গুরুত্বপূর্ণ লাইন

শুরু হওয়ার সময় agent প্রতিটি উপলভ্য skill-এর name এবং description তার context-এ লোড করে। skill-এর মূল অংশ লোড করে না। আপনার request এলে, এই একটি লাইনই skill-টি প্রাসঙ্গিক কি না নির্ধারণের সম্পূর্ণ ভিত্তি হিসেবে কাজ করে। তাই অস্পষ্ট description-এর আড়ালে নিখুঁত body থাকলেও সেটি কখনও পড়া হয় না।

description তৃতীয় পুরুষে লিখুন। "Tests and reloads nginx safely" কার্যকর। "I can help you with nginx" কার্যকর নয়, কারণ এই text system prompt-এ যুক্ত হয়, যেখানে first person মডেল নিজেকে নিয়ে কথা বলছে বলে মনে হয়।

description-এ দুটি বিষয় রাখুন: skill-টি কী করে এবং কোন শর্তে এটি প্রযোজ্য। গুরুত্বপূর্ণ use case প্রথমে লিখুন, কারণ Claude Code listing entry-টি 1,536 characters-এ truncate করে। অতিরিক্ত trigger phrase এবং example request-এর জন্য ঐচ্ছিক when_to_use field রয়েছে। এটিও একই সীমার মধ্যে description-এর শেষে যুক্ত হয়।

এরপর আপনি বাস্তবে যে শব্দগুলো type করবেন, সেগুলোই ব্যবহার করুন। description: Helps with nginx কোনো কিছুর সঙ্গে match করে না, কারণ কেউ "helps with" type করে না। আগের version-এ /etc/nginx, server block, reverse proxy এবং TLS (transport layer security) certificate path উল্লেখ করা হয়েছে। এই শব্দগুলোই মোটামুটি সেই vocabulary, যা skill-টি trigger করার মতো যেকোনো request-এ থাকবে।

description যাচাই করার পদ্ধতি হলো: body কখনও দেখেনি এমন কাউকে শুধু ওই একটি line দিন, সঙ্গে যে request type করতে যাচ্ছেন সেটিও দিন, এবং জিজ্ঞেস করুন skill-টি প্রযোজ্য কি না। সে যদি বুঝতে না পারে, model-ও বুঝতে পারবে না।

বডি সংক্ষিপ্ত রাখুন, কারণ এটি context-এ থেকে যায়

কোনো skill invoke হলে, তার rendered content একটি message হিসেবে conversation-এ যুক্ত হয় এবং session-এর বাকি সময় সেখানেই থাকে। পরের turn-গুলোতে Claude Code ফাইলটি আবার পড়ে না। আপনি যে প্রতিটি line লেখেন, তার খরচ পুরো session-এর জন্য হয়; শুধু একটি answer-এর জন্য নয়।

Anthropic SKILL.md-কে 500 lines-এর মধ্যে রাখার এবং বিস্তারিত তথ্য আলাদা ফাইলে সরানোর পরামর্শ দেয়। Compaction দেখায়, এই সংখ্যাটি ইচ্ছাধীন নয়। Context খালি করার জন্য conversation summary তৈরি হলে Claude Code প্রতিটি skill-এর সর্বশেষ invocation আবার যুক্ত করে, প্রতিটির শুধু প্রথম 5,000 tokens রাখে, এবং সর্বশেষ invoke করা skill থেকে শুরু করে সম্মিলিত 25,000 token budget পূরণ করে। দীর্ঘ skill মাঝপথে কেটে যেতে পারে। একাধিক দীর্ঘ skill একে অপরকে সম্পূর্ণভাবে সরিয়ে দিতে পারে।

তাই model ইতিমধ্যে যা জানে, শুধু তা লিখবেন না। এটি জানে nginx কী এবং reverse proxy কীভাবে কাজ করে। এটি জানে না reload-এর ওপর restart সংক্রান্ত আপনার local rule। এই ফাইলের অস্তিত্বের একমাত্র কারণ ওই rule।

skill-এ bundled script চালানোর নির্দেশ থাকলে, path-এ ${CLAUDE_SKILL_DIR} ব্যবহার করুন, যাতে skill যেখানেই installed থাকুক path সঠিকভাবে resolve হয়। একই command আগে থেকেই অনুমোদিত রাখুন, যাতে permission prompt-এ run থেমে না যায়।

---
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 হয়েছে, শুধু সেই turn-এর জন্য কার্যকর থাকে। পরের message পাঠালে এটি clear হয়ে যায়। তাই এটি অজান্তে permanent permission হয়ে যায় না।

দক্ষতা কার্যকর হচ্ছে—এটি কীভাবে প্রমাণ করবেন

কোনো skill load হতে দেখা গেলে বোঝা যায় যে agent সেটি খুঁজে পেয়েছে। এতে বোঝা যায় না যে উত্তর পরিবর্তিত হয়েছে। দুটোই যাচাই করুন। নতুন session-এও যাচাই করুন, কারণ skill লেখার সময় যে session-এ কাজ করেছেন, সেখানে লেখার সময় বলা সব তথ্য ইতিমধ্যেই থাকে। এই অতিরিক্ত context ফাইলের ঘাটতিগুলো আড়াল করতে পারে।

1. project-এ claude ব্যবহার করে একটি নতুন session শুরু করুন।
2. কোনো সাধারণ কর্মদিবসে যেভাবে request করতেন, নিজের ভাষায় সেভাবে request লিখুন। skill-এর নাম উল্লেখ করবেন না।
3. invocation হয়েছে কি না দেখুন। skill কার্যকর না হলে description ঠিক করুন। এখনো body নিয়ে সমস্যা খোঁজার দরকার নেই।
4. নিয়ন্ত্রণ হিসেবে /nginx-config-changes ব্যবহার করে skill-টি হাতে invoke করুন। হাতে invoke করলে আচরণ সঠিক, কিন্তু request থেকে invoke করলে ভুল হলে বোঝা যায় সমস্যা trigger-এ, instruction-এ নয়।
5. skill বন্ধ রেখে একই request চালান এবং দুটি উত্তর তুলনা করুন। /skills menu-তে skill-টি highlight করুন, Space চাপ দিয়ে এর state পরিবর্তন করে off করুন, তারপর সংরক্ষণ করতে Enter চাপুন। এতে .claude/settings.local.json-এ একটি skillOverrides entry লেখা হবে। কাজ শেষ হলে Space আবার চাপলে state চক্রাকারে on-এ ফিরে যাবে।
6. এমন কয়েকটি request লিখুন যেগুলোতে skill কার্যকর হওয়ার কথা নয়। সেগুলোতে skill নীরব থাকে কি না যাচাই করুন।

এই প্রক্রিয়াটি স্বয়ংক্রিয় করতে 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-কে skill-এর নাম উল্লেখ করে skill-টি মূল্যায়ন করতে বলুন। plugin skill directory-এর evals/evals.json-এ test case সংরক্ষণ করে এবং প্রতিটি case নিজস্ব subagent-এ চালায়। তাই প্রতিটি run পরিষ্কার context দিয়ে শুরু হয়। এরপর এটি with-skill এবং without-skill তুলনা লিখে। এটিই প্রকৃত মাপকাঠি: skill ব্যবহারের জন্য প্রয়োজনীয় token ও সময় বিবেচনা করে pass rate কতটা উন্নত হয়েছে।

ব্যর্থতার ধরন: skill কখনো সক্রিয় হয় না

আপনি অনুরোধটি লিখলেন, agent আগের ভুল কাজটিই করল, কিন্তু কোনো skill line দেখা গেল না। নিচের বিষয়গুলো ক্রমানুসারে পরীক্ষা করুন।

• Description-এ skill কী করে তা বলা আছে, কিন্তু কখন ব্যবহার করতে হবে তা বলা নেই। তাই আপনার অনুরোধের সঙ্গে কোনো মিল পাওয়া যায় না।
• Description-এ আপনি যে শব্দগুলো ব্যবহার করেন, সেগুলো নেই। আপনি যদি "nginx" বলেন, তাহলে description-এ nginx শব্দটিও থাকতে হবে।
• Frontmatter-এ disable-model-invocation: true সেট করা আছে। এর ফলে description সম্পূর্ণভাবে model-এর context-এর বাইরে থাকে এবং skill-টি শুধু আপনার মাধ্যমে /name দিয়ে চালু করা যায়।
• Frontmatter-এ থাকা paths glob activation-কে মিলে যাওয়া file-এ সীমাবদ্ধ করে, কিন্তু আপনি যে file নিয়ে কাজ করছেন সেটি এর সঙ্গে মেলে না।
• Skill-টি আপনার starting directory-এর নিচে একটি nested .claude/skills/ directory-তে রয়েছে। Agent ওই subdirectory-র কোনো file পড়া বা সম্পাদনা করার পরেই সেগুলো load করে। তাই তার আগে skill-টি একেবারেই available থাকে না।

ব্যর্থতার ধরন: skill সব সময় সক্রিয় হয়

উল্টো সমস্যা হলো, description এত বিস্তৃত যে skill অসংশ্লিষ্ট কাজেও সক্রিয় হয়। “সার্ভারে কাজ করার সময় ব্যবহার করুন” — এই শর্তটি server repository-এর প্রায় যেকোনো অনুরোধের সঙ্গে মিলে যায়। ফলে body এমন কাজেও load হয়, যেখানে এটি কোনো সহায়তা করতে পারে না, এবং বাকি session জুড়ে এটি context-এ থেকে যায়।

Description-কে প্রকৃত প্রাসঙ্গিক শর্তে সীমাবদ্ধ করুন এবং এটি কোন file বা command কভার করে তা উল্লেখ করুন। skill শুধু নির্দিষ্ট file-এর ক্ষেত্রে প্রযোজ্য হলে একটি paths glob যোগ করুন। deploy বা commit-এর মতো side effect-যুক্ত কাজের ক্ষেত্রে disable-model-invocation: true সেট করুন এবং /name ব্যবহার করে skill-টি নিজে invoke করুন। এতে agent নিজে থেকে deploy করার উপযুক্ত সময় নির্ধারণ করতে পারবে না।

ব্যর্থতার ধরন: নির্দেশনাটি rules file-এ থাকা উচিত

CLAUDE.md বা AGENTS.md-এর মতো একটি rules file প্রতিটি session-এর শুরুতে লোড হয় এবং প্রতিটি task-এ প্রযোজ্য হয়। কোনো skill-এর body শুধু skill সক্রিয় হলে লোড হয়। সিদ্ধান্তের ভিত্তি হলো প্রয়োগের frequency। repository-এর প্রতিটি task-এ প্রযোজ্য কোনো তথ্য, যেমন আপনি যে package manager ব্যবহার করেন, rules file-এ থাকা উচিত। অল্প কিছু task-এ প্রযোজ্য কোনো procedure, যেমন উপরের nginx rule, skill-এ থাকা উচিত। যেদিন কেউ nginx সম্পাদনা করে না, সেদিন এটি কোনো অতিরিক্ত খরচ তৈরি করে না।

আসল ব্যর্থতা হলো একই নির্দেশনা উভয় জায়গায় রাখা। দুটি copy আলাদা হয়ে যায়। agent ভুল কাজ করলে কোন copy অনুসরণ করেছে, তা বোঝা যায় না। প্রতিটি নির্দেশনার জন্য একটি নির্দিষ্ট স্থান বেছে নিন। skills, MCP servers এবং rules files-এর সীমানা কঠিন পরিস্থিতিগুলোও ব্যাখ্যা করে। এর মধ্যে সেই অবস্থাও আছে, যখন সঠিক উত্তর হলো একটি MCP (model context protocol) server, যা agent-কে নতুন instruction নয়, নতুন tool দেয়।

প্রাপ্যতা প্রমাণিত হলে এটি শেয়ার করুন

একটি skill এক সপ্তাহের বাস্তব কাজ টিকে গেলে সেটি commit করার মতো উপযুক্ত। .claude/skills/-এর project skill-গুলো code-এর মতো review করা হয় এবং repository-এর সঙ্গে আসে। তাই কোনো teammate repository clone করলে অতিরিক্ত setup ছাড়াই আপনার সংশোধনটি পেয়ে যায়। copy এবং paste ছাড়া একটি repository থেকে অন্য repository-তে skill সরানো আলাদা একটি সমস্যা। এটি repository জুড়ে agent skill শেয়ার করার পদ্ধতি-তে ব্যাখ্যা করা হয়েছে।

Portability সম্পর্কে একটি বিষয় মনে রাখুন। Claude Code দীর্ঘ একটি frontmatter field তালিকা গ্রহণ করে। কিন্তু Agent Skills standard-এ মাত্র ছয়টি field অনুমোদিত: name, description, license, compatibility, metadata এবং allowed-tools। অন্য কোনো frontmatter field রেখে কোনো skill claude.ai-তে upload করলে বা Skills API-এর জন্য package করলে সেটি সরাসরি ব্যর্থ হয়। Field-টি উপেক্ষা করা হয় না:

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

এই ছয়টি field-এর মধ্যেই থাকলে একই file Claude Code এবং standard পড়ে এমন অন্যান্য সবকিছুর মধ্যে load হবে। ভিন্ন model-এ স্থানান্তরের পরেও instructions কার্যকর থাকে এমনভাবে সেগুলো লেখা আলাদা একটি কাজ। যেকোনো model-এর সঙ্গে কার্যকর skill লেখার পদ্ধতি-তে এটি ব্যাখ্যা করা হয়েছে।

FAQ

একটি SKILL.md ফাইল কত দীর্ঘ হওয়া উচিত?

এটি 500 লাইনের মধ্যে রাখুন। সাধারণত কার্যকর skill-এর দৈর্ঘ্য এর চেয়ে অনেক কম হয়। skill invoke হলে এর body conversation-এ যুক্ত হয় এবং session-এর বাকি সময় সেখানে থাকে। তাই প্রতিটি লাইন একবারের খরচ নয়, বারবারের খরচ। দীর্ঘ reference material skill directory-এর আলাদা ফাইলে রাখুন এবং SKILL.md থেকে সেগুলোর link দিন, তবে এক স্তরের বেশি গভীরে যাবেন না। এতে agent প্রয়োজন হলেই সেগুলো পড়বে। Bundled script পড়ার পরিবর্তে execute হয়, তাই সেগুলোর খরচ শুধু output-এর সমান।

আমার skill কখনো trigger হয় না কেন?

সাধারণত description-ই এর কারণ। model সিদ্ধান্ত নেওয়ার সময় skill-এর শুধু এই অংশটি context-এ থাকে। description-এ skill কী করে তা নয়, কখন এটি ব্যবহার করতে হবে সেটিও লিখুন। আপনার request-এ বাস্তবে ব্যবহৃত শব্দগুলোও description-এ রাখুন। description সঠিক মনে হলে frontmatter-এ disable-model-invocation: true আছে কি না পরীক্ষা করুন। এটি skill-টিকে model-এর কাছ থেকে সম্পূর্ণ আড়াল করে। এছাড়া এমন কোনো paths glob আছে কি না দেখুন, যা আপনি যে file-গুলোতে কাজ করছেন না, শুধু সেগুলোর জন্য skill সীমাবদ্ধ করে। আপনার starting directory-এর নিচে nested .claude/skills/ directory-তে থাকা skill-ও একটি কারণ হতে পারে। Agent ওই subdirectory-র কোনো file পড়া বা সম্পাদনা করার পরেই শুধু skill-টি load করে।

এটি কি skill হওয়া উচিত, নাকি আমার rules file-এ একটি line?

আপনার কতগুলো task-এ এটি প্রযোজ্য, তা বিবেচনা করুন। rules file প্রতিটি session-এ load হয়। তাই এতে এমন তথ্য রাখা উচিত যা প্রতিটি task-এর জন্য সত্য, যেমন package manager বা branch naming convention। skill কেবল trigger হলে load হয়। তাই অল্পসংখ্যক task-এ প্রয়োজনীয় procedure রাখার জন্য এটিই উপযুক্ত স্থান। একই instruction দুই জায়গায় লিখবেন না। কারণ দুই copy আলাদা হয়ে যেতে পারে এবং agent কোনটি অনুসরণ করেছে তা বোঝা কঠিন হয়।

কোনো skill সত্যিই সহায়তা করেছে কি না কীভাবে বুঝব?

একটি baseline-এর সঙ্গে তুলনা করুন। কয়েকটি বাস্তব request সংগ্রহ করুন। skill available রেখে প্রতিটি request নতুন session-এ একবার চালান। এরপর /skills menu থেকে skill বন্ধ করে একই request আবার চালান। তারপর দুই উত্তর পাশাপাশি পড়ুন। নতুন session গুরুত্বপূর্ণ। কারণ skill লেখার সময় যে conversation ছিল, তাতে আপনার ব্যাখ্যাগুলো এখনও থাকে। ফলে অসম্পূর্ণ file-ও সম্পূর্ণ মনে হতে পারে। skill-creator plugin আপনার হয়ে এই তুলনা চালায় এবং token cost-এর পাশে pass rate দেখায়।

আমি কি একই SKILL.md অন্য agent-এর সঙ্গে ব্যবহার করতে পারি?

হ্যাঁ, যদি Agent Skills standard-এ নির্ধারিত field-গুলোর মধ্যে থাকেন: name, description, license, compatibility, metadata এবং allowed-tools। Claude Code আরও অনেক field গ্রহণ করে। এটি এমন body feature-ও সমর্থন করে, যেমন shell command injection, যা অন্য tool execute করে না। Standard-এর বাইরে কোনো field-সহ skill upload করলে allowed property-গুলোর তালিকা-সহ একটি স্পষ্ট error দেখিয়ে ব্যর্থ হয়। তাই শুরুতেই সিদ্ধান্ত নিন, skill-টি শুধু Claude Code-এ থাকবে, নাকি অন্য tool-এও ব্যবহার করা হবে।