এজেন্ট স্কিল শেয়ার করার উপায়: রিপোজিটরি ম্যানেজমেন্ট টিপস

রিপোজিটরিগুলোর মধ্যে agent skill কীভাবে শেয়ার করবেন

রিপোজিটরিগুলোর মধ্যে agent skill শেয়ার করতে হলে ফাইল কপি করা বন্ধ করে সেটির ওপর নির্ভর করুন। একটি skills repository রাখুন, সেটিকে tag করুন, এবং প্রতিটি project-কে একটি tag pin করতে দিন। এরপর প্রতিটি skill-এর জন্য একটি smoke test যোগ করুন, এবং dependency bump review করার মতো করেই প্রতিটি bump review করুন।

এখানে চারটি অংশ আছে: shared source of truth, প্রতিটি repository-এর জন্য pinned version, প্রতিটি skill-এর জন্য smoke test, এবং একটি review path। নিচের সবকিছুতে ব্যাখ্যা করা হয়েছে কেন প্রতিটি অংশ প্রয়োজন, 2026 সালে প্রকাশিত tools এগুলো কীভাবে পরিচালনা করে, এবং কোনো বাইরের git host বা package registry ব্যবহার না করে self-hosted git remote-এ পুরো ব্যবস্থা কীভাবে তৈরি করবেন। smoke test-গুলোই একমাত্র ব্যতিক্রম। এগুলো Claude Code চালায়, যা প্রতিটি request একটি model API-তে পাঠায়। তাই এই ধাপটি এখনও আপনার server-এর বাইরে request পাঠায়।

একটি agent skill হলো এমন একটি folder, যাতে SKILL.md file এবং প্রয়োজনীয় scripts ও reference files থাকে। এই unit-টি নতুন হলে আগে agent skill কী এবং SKILL.md কীভাবে কাজ করে পড়ুন। এই পৃষ্ঠায় সেই unit-কে ঘিরে supply chain নিয়ে আলোচনা করা হয়েছে।

একটি skill কোথায় থাকে এবং শেয়ার করা কঠিন কেন

Claude Code অন্যান্য অবস্থানের পাশাপাশি নিচের অবস্থানগুলো থেকে skill লোড করে। skills documentation-এ প্রতিটি path-এর নাম দেওয়া আছে।

• .claude/skills/<skill-name>/SKILL.md managed settings directory-এর ভেতরের enterprise অবস্থান। কোনো organization যে machine-গুলোতে এটি deploy করে, সেখানে এটি প্রতিটি user-এর জন্য লোড হয়।
• ~/.claude/skills/<skill-name>/SKILL.md ব্যক্তিগত। এটি আপনার সব project-এ লোড হয়, অন্য কারও project-এ নয়।
• .claude/skills/<skill-name>/SKILL.md project level-এর অবস্থান। যে ব্যক্তি ওই repository checkout করেন, তার জন্য এটি লোড হয়।
• <plugin>/skills/<skill-name>/SKILL.md একটি plugin-এর ভেতরে থাকে। যেখানে ওই plugin enabled থাকে, সেখানেই এটি লোড হয়।

Claude Code nested project directory, --add-dir-এর মাধ্যমে দেওয়া directory এবং আপনার claude.ai account-এর জন্য enabled skill থেকেও skill লোড করে।

দলের জন্য project level-এর অবস্থানটি কার্যকর, কারণ এটি commit করা থাকে এবং যে কেউ repository clone করলে তা পেয়ে যায়। সমস্যাও এখান থেকেই শুরু হয়। .claude/skills/-এর একটি skill একটি repository-এর অন্তর্ভুক্ত। আপনার আটটি repository আছে। তাই skill-টি আটবার copy হয়।

frontmatter কোনো সহায়তা করে না। Agent Skills spec ছয়টি key অনুমোদন করে। অন্য কোনো key ব্যবহার করলে distribution path-গুলো অনুমোদিত key-এর তালিকা দেখায়:

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

লক্ষ করুন, কী অনুপস্থিত: কোনো version key নেই। file-এর ভেতরে কোন copy নতুন, তা রেকর্ড করার কোনো তথ্য নেই। এটি যুক্তিসঙ্গত, কারণ skill একটি package নয়, একটি document। তবে এর অর্থ হলো versioning file-এর বাইরের layer থেকে করতে হবে, এবং সেই layer-এর দায়িত্ব আপনার।

সমস্যা এক: আটটি কপি যা নীরবে ভিন্ন হয়ে যায়

প্রথম দিনে কপি-পেস্ট কাজ করে। ষাটতম দিনে এটি ব্যর্থ হয়। কেউ একজন payments রিপোজিটরিতে একটি ভুল নির্দেশ সংশোধন করে কিন্তু অন্য সাতটিতে কোনো পরিবর্তন করে না। অন্য কেউ orders-তে পেজিনেশন সংক্রান্ত একটি নিয়ম যোগ করে। এখন একই স্কিলের নাম দুটি ভিন্ন রিভিউ প্রদান করে, যা নির্ভর করে এজেন্ট কোন ডিরেক্টরি থেকে শুরু হয়েছে তার ওপর, এবং কোনো ডেভেলপারই তা জানে না।

এই ব্যর্থতাটি নীরব কারণ এতে কোনো এরর স্টেট নেই। একটি স্কিল হলো গদ্য। একটি পুরনো নির্দেশ আত্মবিশ্বাসের সাথে ভুল উত্তর তৈরি করে, যা অত্যন্ত ব্যয়বহুল। এজেন্টের মধ্যে এমন কিছু নেই যা আপনার কপিকে অন্যদের সাথে তুলনা করবে, তাই একমাত্র সংকেত হলো যখন কোনো ব্যক্তি লক্ষ্য করেন যে দুটি রিপোজিটরির তথ্যে অমিল রয়েছে।

সমস্যা দুই: কোনো ভার্সন পিন করা নেই

এমনকি যখন একটি টিম তাদের স্কিলগুলো এক জায়গায় রাখে, তখনও শেয়ার করার সাধারণ পদ্ধতি হলো কপি করা: একটি সেটআপ স্ক্রিপ্ট, অনবোর্ডিং ডক-এ থাকা একটি curl লাইন, অথবা একটি শেল অ্যালিয়াস যা একটি ফোল্ডার সিঙ্ক করে। এই সব পদ্ধতিই বর্তমানে ব্রাঞ্চের মাথায় (head) যা আছে, তা-ই ইনস্টল করে।

এর মানে হলো, একই অ্যাপ্লিকেশনের একই কমিটে থাকা দুইজন ডেভেলপার ভিন্ন ভিন্ন ইন্সট্রাকশন অনুযায়ী কাজ করতে পারেন, কারণ তারা ভিন্ন ভিন্ন দিনে সিঙ্ক করেছেন। এর মানে আরও একটি বিষয়, একটি খারাপ এজেন্ট রান হওয়ার পর যে প্রশ্নটি সবচেয়ে গুরুত্বপূর্ণ, তার উত্তর আপনি দিতে পারবেন না: কোন ভার্সনের স্কিল এটি তৈরি করেছে? কোনো রেকর্ড করা রিভিশন ছাড়া রানটি পুনরায় তৈরি (reproducible) করা সম্ভব নয়, তাই বাগ রিপোর্টটি নিয়ে কোনো পদক্ষেপ নেওয়া যায় না।

সমস্যা তিন: দক্ষতাটি এখনও কাজ করছে কি না তা কেউ জানে না

একটি দক্ষতার কোনো compiler থাকে না। এটি মূলত একটি মডেলের উদ্দেশ্যে দেওয়া নির্দেশাবলি, তাই ফাইলটি হুবহু একই থাকলেও এটি কাজ করা বন্ধ করে দিতে পারে। মডেল আপগ্রেড করার ফলে দীর্ঘ নির্দেশাবলি অনুসরণের ক্ষেত্রে সূক্ষ্ম পরিবর্তন আসতে পারে। দক্ষতাটি যে command line tool-কে কল করে, সেটি কোনো flag-এর নাম পরিবর্তন করতে পারে। রেফারেন্স ফাইলে থাকা কোনো URL 404 error দিতে শুরু করতে পারে এবং agent তখন সেই error page থেকেই কাজ চালিয়ে যায়।

এই ধরনের কোনো ক্ষেত্রেই বড় কোনো ব্যর্থতা দেখা দেয় না। agent এখনও উত্তর দিয়ে যায়। সমস্যা হলো, উত্তরটি গত মাসের তুলনায় নিম্নমানের হয়, যা প্রতিটি pull request-এর সময় আলাদাভাবে শনাক্ত করা বেশ কঠিন।

2026 সালে প্রকাশিত টুলগুলো যে সমস্যার সমাধান করে

বর্তমানে কয়েকটি সমাধান পাওয়া যাচ্ছে, এবং version কোথায় রাখা উচিত সে বিষয়ে এগুলোর মতভেদ আছে।

Lockfiles। Vercel Labs-এর skills command line tool (vercel-labs/skills, MIT licensed, 9 October 2026 অনুযায়ী v1.7.2) একটি git repository থেকে skill ইনস্টল করে আপনার agent যে directory প্রত্যাশা করে সেখানে রাখে। এটি সত্তরের বেশি agent-এর layout জানে। npx skills add <repo> ইনস্টল করে, npx skills update upgrade করে, এবং npx skills list আপনার কাছে কী আছে তা দেখায়। এটি দুটি lock file রাখে। একটি global file, ~/.agents/.skill-lock.json, একজন user কী কী ইনস্টল করেছেন তা নথিবদ্ধ করে। 20 February 2026 থেকে, project scope-এ ইনস্টল করলেও project root-এ skills-lock.json লেখা হয়। Tool-এর source code অনুযায়ী, এই file version control-এ check in করার জন্য নির্ধারিত। npx skills experimental_install এটি থেকে একটি project-এর skill পুনরুদ্ধার করে। অন্য একটি machine-এ global lock file পুনরুদ্ধারের জন্য skills install command চাওয়া issue 283-কে 5 November 2026-এ পরিকল্পনায় না থাকায় বন্ধ করা হয়; maintainer এটিকে issue 549-এর একই অনুরোধ হিসেবে চিহ্নিত করেছেন। দুটি বিষয়কেই status report হিসেবে পড়ুন। Per-project lockfile রয়েছে। এটি থেকে পুনরুদ্ধার করার command-টি প্রকাশিত v1.7.6-এ এখনও experimental হিসেবে চিহ্নিত; project-এর main branch এখন কোনো source ছাড়াই project lockfile পুনরুদ্ধারের জন্য npx skills install সমর্থন করে।

Specs এবং tests। SkillSpec অন্য দৃষ্টিভঙ্গি গ্রহণ করে। এটি একটি SKILL.md-কে বিশ্বাস করার মতো prose নয়, বরং যাচাই করার contract হিসেবে বিবেচনা করে। এর ঘোষিত লক্ষ্য হলো skill-গুলোকে "followable, testable, and provable" করা। skillspec doctor <path> দেখায়, কোনো agent কোথায় কাজের ধারাটি হারিয়ে ফেলতে পারে। skillspec boundary map <path> skill-এ কী আছে তা দেখায়, এবং skillspec boundary assess <path> skill কোন কোন resource-এ পৌঁছাতে পারে তা risk অনুযায়ী সাজিয়ে জানায়। এটি একটি Rust crate, যার license MIT অথবা Apache 2.0। Version 0.2.2 29 July 2026-এ প্রকাশিত হয় এবং 10 October 2026 অনুযায়ী crates.io-তে এখনও এটিই সর্বশেষ version। সর্বশেষ version-এর পরিবর্তে নির্দিষ্ট version ইনস্টল করুন:

cargo install skillspec --version 0.2.2 --locked
skillspec --version

--locked crate প্রকাশের সময় ব্যবহৃত dependency version-গুলো দিয়ে build করে। ফলে build প্রক্রিয়ায় version অপ্রত্যাশিতভাবে পরিবর্তিত হয় না। skillspec --version-এর 0.2.2 print করা উচিত। ভিন্ন কোনো number দেখালে বুঝবেন, আপনার PATH-এর আগে থাকা একটি পুরোনো binary কার্যকর হচ্ছে।

Vendor-এর practice। google/skills-এ skill কীভাবে build করা হয়, তা Google how it builds, tests and scales agent skills পোস্টে বর্ণনা করেছে। Scale বাদ দিলে পদ্ধতিটি সাধারণ continuous integration (CI)। Merge করার আগে প্রতিটি skill-কে frontmatter metadata, line count, directory layout এবং naming-এর জন্য linter-এর পরীক্ষায় পাস করতে হয়। কোনো URL 404 ফেরত দিলে link checker build ব্যর্থ করে। এতে agent-এর তৈরি করা বিশ্বাসযোগ্য কিন্তু ভুল link ধরা পড়ে। Authors-কে skill-এর সঙ্গে একটি evaluation prompt suite এবং scoring rubric দিতে হয়। এরপর scheduled evaluation job পুরো library-এর ওপর সাপ্তাহিকভাবে চলে, যাতে regression ধরা যায়। প্রতিটি skill-এর একজন নির্দিষ্ট owner থাকে, এবং quality কমলে তার কাছ থেকেই এটি ঠিক করার প্রত্যাশা করা হয়।

তিনটি উত্তরের অন্তর্নিহিত প্যাটার্ন

আপনাকে এর মধ্যে যেকোনো একটি বেছে নিতে হবে না। এগুলোর নিচে একটি সাধারণ কাঠামো রয়েছে এবং plain git আপনাকে এর সবকিছুই প্রদান করে।

1. তথ্যের একটি একক উৎস (One source of truth)। প্রতিটি skill-এর জন্য একটি নির্দিষ্ট হোম বা উৎস থাকে এবং প্রতিটি repository সেই উৎসকে নির্দেশ করে, নিজের কাছে কোনো কপি রাখে না।
2. প্রতিটি repository-র জন্য একটি নির্দিষ্ট version। প্রতিটি project তার ব্যবহৃত সঠিক revision রেকর্ড করে রাখে, তাই upgrade করার অর্থ হলো সেই project-এ একজন author এবং তারিখসহ একটি commit করা।
3. প্রতিটি skill-এর জন্য একটি smoke test। একটি runnable চেক যা প্রমাণ করে যে skill-টি এখনও তার প্রতিশ্রুতি অনুযায়ী ফলাফল দিচ্ছে।
4. একটি review path। একটি shared skill-এ কোনো পরিবর্তন আনা হলে তা অবশ্যই review-এর মধ্য দিয়ে যেতে হয় এবং প্রতিটি consumer তা গ্রহণ করার আগে একটি diff দেখতে পায়।

এটিই হলো dependency-র কাঠামো। টুলিং তৈরি হওয়ার আগেই skill-গুলো shared artifact হিসেবে দ্রুত জনপ্রিয় হয়ে উঠেছে, তাই আপনি যে টুলিংয়ের ওপর ইতিমধ্যে আস্থা রাখেন, সেটি ব্যবহার করাই সবচেয়ে নিরাপদ।

একটি ছোট দলের জন্য self-hosted git remote-এর একটি লেআউট

একটি রিপোজিটরিতে দক্ষতা বা নলেজবেস রাখা হয়। এতে অন্য কিছু থাকে না, তাই এর হিস্ট্রি নির্দেশনার একটি চেঞ্জলগ হিসেবে কাজ করে।

agent-skills/
  skills/
    api-review/
      SKILL.md
    release-notes/
      SKILL.md
  tests/
    api-review.sh
    release-notes.sh
  CHANGELOG.md

Releases হলো ট্যাগ। Annotated ট্যাগ ব্যবহার করুন, কারণ এগুলোতে একটি বার্তা এবং তারিখ থাকে। বার্তাটি এমনভাবে লিখুন যাতে একজন ব্যবহারকারী বুঝতে পারেন কেন এই আপডেটটি প্রয়োজন:

git tag -a v1.4.0 -m "api-review: require pagination on list endpoints"
git push origin v1.4.0

আপনার রিমোট যদি Gitea, Forgejo, GitLab অথবা আপনার নিজস্ব VPS-এ SSH-এর মাধ্যমে কোনো bare repository হয়, তবে নিচের কোনো কিছুই পরিবর্তন হবে না। এখানে সবকিছুই হলো git এবং একটি symlink।

git submodule দিয়ে পিনিং (Pinning)

একটি submodule আপনার রিপোজিটরির ভেতরে অন্য একটি রিপোজিটরির নির্দিষ্ট একটি commit রেকর্ড করে রাখে। এই রেকর্ডটিই হলো পিন (pin)। প্রতিটি কনজিউমিং প্রজেক্টে:

git submodule add https://git.example.com/team/agent-skills.git vendor/agent-skills
git -C vendor/agent-skills fetch --tags
git -C vendor/agent-skills checkout v1.4.0
mkdir -p .claude/skills
ln -s ../../vendor/agent-skills/skills/api-review .claude/skills/api-review
git add .gitmodules vendor/agent-skills .claude/skills/api-review
git commit -m "Pin shared agent skills to v1.4.0"

symlink-ই এই প্রক্রিয়াটি কার্যকর করে। প্রজেক্ট লেভেলের একটি skill এন্ট্রি ডিস্কের অন্য কোনো ডিরেক্টরির symlink হতে পারে, এবং Claude Code তা অনুসরণ করে লক্ষ্যবস্তু থেকে SKILL.md পড়ে নেয়। ফলে skill-টি একটি সাধারণ প্রজেক্ট skill হিসেবে লোড হয়, অথচ এর বাইটগুলো আপনার বেছে নেওয়া commit-এর submodule-এ থাকে।

পিনটি যাচাই করুন:

git submodule status

একটি সঠিক লাইনের শুরুতে একটি স্পেস থাকে, এরপর commit, তারপর পাথ এবং সবশেষে নিকটতম ট্যাগ থাকে:

 4d1a7c2f0b93e5a1c8d6f2b40e7a95c3d1f8b602 vendor/agent-skills (v1.4.0)

শুরুতে - থাকার অর্থ হলো submodule-টি কখনোই initialised করা হয়নি, তাই .claude/skills/api-review কোনো কিছুকে নির্দেশ করছে না এবং skill-টি নীরবে লোড হচ্ছে না। git submodule update --init দিয়ে এটি ঠিক করুন। শুরুতে + থাকার অর্থ হলো চেক-আউট করা commit-টি রেকর্ড করা commit থেকে আলাদা, অর্থাৎ সেই ডেভেলপার এমন সব ইনস্ট্রাকশন চালাচ্ছেন যা অন্য কারো কাছে নেই। নতুন clone-এর জন্য git clone --recurse-submodules প্রয়োজন, এবং এই লাইনটি README-তে থাকা উচিত, কারণ সাধারণ clone-এর ক্ষেত্রে vendor/agent-skills খালি থাকে এবং কোনো এরর দেখায় না।

আপগ্রেড করা একটি সচেতন সিদ্ধান্ত, আর এটাই এর মূল উদ্দেশ্য:

git -C vendor/agent-skills fetch --tags
git -C vendor/agent-skills diff v1.4.0 v1.5.0 -- skills/
git -C vendor/agent-skills checkout v1.5.0
git add vendor/agent-skills
git commit -m "Bump shared agent skills to v1.5.0"

diff লাইনটি হলো রিভিউ পাথ। এটি সেই একই পরিবর্তন দেখায় যা অন্য সব কনজিউমিং রিপোজিটরি দেখতে পাবে এবং এটি একটি pull request-এর সাথে সামঞ্জস্যপূর্ণ।

একটি plugin marketplace ব্যবহার করে pinning

প্রতিটি developer-কে submodule শেখাতে না চাইলে Claude Code plugin system আপনার হয়ে distribution পরিচালনা করে। এটি self-hosted remote-এর সঙ্গেও কাজ করে। skills repository-তে .claude-plugin/marketplace.json-এ একটি catalog রাখুন:

{
  "name": "acme-agents",
  "owner": { "name": "Platform team", "email": "platform@example.com" },
  "plugins": [
    {
      "name": "team-skills",
      "description": "Shared review and release skills",
      "version": "1.4.0",
      "source": {
        "source": "url",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0",
        "sha": "4d1a7c2f0b93e5a1c8d6f2b40e7a95c3d1f8b602"
      }
    }
  ]
}

এখানে দুটি ভিন্ন source ব্যবহৃত হয়েছে। এগুলো গুলিয়ে ফেলাই সাধারণ ভুল। Marketplace source বলতে catalog নিজে যেখান থেকে fetched হয় সেটিকে বোঝায়। এটি branch বা tag-এর জন্য ref গ্রহণ করে, কিন্তু sha গ্রহণ করে না। Catalog-এর ভেতরের plugin source উভয়টিই গ্রহণ করে। উভয়টি সেট করা থাকলে sha কার্যকর pin হয়। Type-এর নামও ভিন্ন। Catalog-এর ভেতরে url বলতে clone করার জন্য একটি git repository বোঝায়। Marketplace source-এ url বলতে সরাসরি একটি marketplace.json file-এর link বোঝায়। সেখানে git repository হলো git।

এরপর প্রতিটি consuming repository তার committed .claude/settings.json-এ marketplace ঘোষণা করে:

{
  "extraKnownMarketplaces": {
    "acme-agents": {
      "source": {
        "source": "git",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0"
      }
    }
  },
  "enabledPlugins": {
    "team-skills@acme-agents": true
  }
}

Project folder-এর জন্য workspace trust dialog গ্রহণ করার পর Claude Code কোনো teammate-এর জন্য marketplace register করে। এজন্য তাকে নির্দেশনা দেওয়া কোনো wiki page-এর প্রয়োজন হয় না। Catalog entry-তে relative path-এর পরিবর্তে একটি git URL দেওয়া হয়েছে। তাই শুধু repository settings থেকে plugin install হয় না। প্রতিটি teammate একবার claude plugin install team-skills@acme-agents --scope project চালান। এটি না করা পর্যন্ত Claude Code জানায় যে project settings-এ plugin enabled, কিন্তু এটি installed নয়। এরপর skills-গুলো /team-skills:api-review-এর মাধ্যমে ব্যবহৃত হয়। কারণ plugin skill-গুলোর নাম plugin name দিয়ে namespace করা হয় এবং একই নামের project skill-এর সঙ্গে সংঘর্ষ হতে পারে না। নতুন tag push করার পর consumer-রা /plugin marketplace update acme-agents চালিয়ে refresh করে। এরপর install summary চাইলে /reload-plugins চালান।

একটি skill-এর জন্য smoke test লেখা

একটি smoke test হলো জানা ত্রুটিযুক্ত fixture-এর বিরুদ্ধে চালানো একটি scripted agent run, যার সঙ্গে একটি assertion থাকে। Claude Code -p ব্যবহার করে non-interactive ভাবে চলে, এবং সেখানে user-invoked skill কাজ করে: prompt string-এ /skill-name রাখলে run শুরু হওয়ার আগে সেটি expand হয়।

#!/usr/bin/env bash
set -euo pipefail

claude -p "/api-review Read fixtures/orders-api.md and list the rule ids it breaks." \
  --allowedTools "Read" \
  --output-format json \
  --json-schema '{"type":"object","properties":{"rule_ids":{"type":"array","items":{"type":"string"}}},"required":["rule_ids"]}' \
  | jq -e '.structured_output.rule_ids | index("pagination-required")' > /dev/null

fixtures/orders-api.md হলো একটি ছোট file, যাতে ইচ্ছাকৃতভাবে একটি fault রাখা আছে। Assertion হলো skill-টি fault-টির নাম উল্লেখ করবে। Filter-এর ফল null হলে jq -e non-zero exit করে। তাই seeded fault ধরা বন্ধ করে দেওয়া কোনো skill এই script-এ ব্যর্থ হবে। Run ব্যর্থ হলে claude নিজেও non-zero exit করে, এবং set -euo pipefail এই দুই ধরনের failure-এর যেকোনো একটিকে failed test-এ পরিণত করে।

একটি model প্রতিটি run-এ তার উত্তর নতুনভাবে লেখে। তাই কখনো সম্পূর্ণ sentence-এর ওপর assertion করবেন না। Skill-টি যে identifier emit করবে বলে প্রত্যাশা করা হচ্ছে, অথবা আপনি যে schema চেয়েছেন তার কোনো field-এর ওপর assertion করুন। Fixture ছোট রাখুন, যাতে run-এর খরচ কম থাকে।

CI-তে --bare যোগ করুন। এটি না থাকলে claude -p একটি interactive session-এর মতো একই context load করে। এর মধ্যে hooks, plugins এবং যে machine-এ এটি চলছে সেখানকার CLAUDE.md-ও থাকে। ফলে কোনো teammate-এর ব্যক্তিগত configuration ফল পরিবর্তন করতে পারে। Bare mode স্বয়ংক্রিয় discovery এড়িয়ে চলে। তবে স্পষ্টভাবে --add-dir দিয়ে সরবরাহ করা directory-এর অধীনে .claude/skills/-এ থাকা skills এর ব্যতিক্রম। আপনি এখানে যে project skill পরীক্ষা করছেন, bare mode সেটি এড়িয়ে যায়। তাই skill-টি explicit ভাবে load করুন। Bare mode আপনার subscription login-ও পড়ে না। তাই আগে environment-এ ANTHROPIC_API_KEY সেট করুন:

claude --bare -p "/team-skills:api-review Read fixtures/orders-api.md and list the rule ids it breaks." \
  --plugin-dir vendor/agent-skills \
  --allowedTools "Read" \
  --output-format json

--plugin-dir দিয়ে load করা plugin তার নাম .claude-plugin/plugin.json থেকে নেয়। ওই manifest না থাকলে plugin-টির নাম তার directory অনুসারে নির্ধারিত হয়। Skills repository-তে catalog-এর পাশে "name": "team-skills" সহ একটি plugin.json commit করুন। তা না হলে উপরের command-এ /agent-skills:api-review call করতে হবে।

--output-format stream-json ব্যবহার করলে system/init event কোন plugins load হয়েছে তা জানায় এবং যেগুলো load হয়নি সেগুলোর জন্য একটি plugin_errors array বহন করে। Startup event আগে না এলে এটি stream খুলে দেয়। plugin_errors খালি না হলে CI job ব্যর্থ করুন। এতে এমন pin ধরা পড়ে যা আর বিদ্যমান নেই এমন revision-এর দিকে নির্দেশ করছে। তা না হলে agent আপনার নির্ধারিত house rules নীরবে উপেক্ষা করছে বলে মনে হতে পারে।

একটি shared skill হলো চালানো যায় এমন নির্দেশনা

দুটি বৈশিষ্ট্য এই কথাটিকে আক্ষরিক অর্থে সত্য করে, এবং ফাইলটি অন্য কোনো team থেকে এলে দুটিই গুরুত্বপূর্ণ।

প্রথমত, একটি SKILL.md model কোনো কিছু পড়ার আগেই shell command চালাতে পারে। body-তে থাকা নিচের মতো একটি line preprocessing হিসেবে কাজ করে:

- Current branch: !`git rev-parse --abbrev-ref HEAD`

skill লোড করা machine-এ command-টি চলে, এবং এর output model যে text পায় সেখানে placeholder-এর স্থান দখল করে। তিনটি backtick-এর পরে ! দিয়ে শুরু করা fenced block একইভাবে একাধিক command চালায়। run time-এ এসবের কোনো কিছুর জন্য prompt দেখানো হয় না। Claude Code প্রতিটি command আপনার permission rule-এর সঙ্গে মিলিয়ে পরীক্ষা করে। auto mode-এর বাইরে, সেই rule যে command অনুমোদন করে না তা skill-টি বন্ধ করে দেয়, যদি না নিচের দ্বিতীয় বৈশিষ্ট্যের মাধ্যমে skill সেটিকে আগে থেকেই অনুমোদন করে থাকে। Deny এবং ask rule এই pre-approval-কে অগ্রাহ্য করে। একটি shared skill পড়ার অর্থ হলো এর command substitution-ও পড়া।

দ্বিতীয়ত, frontmatter tool আগে থেকেই অনুমোদন করতে পারে। allowed-tools তালিকাভুক্ত tool-গুলোকে skill যে turn চালু করেছে, সেই turn-এর জন্য permission prompt ছাড়াই অনুমোদন করে। Workspace trust এই অনুমোদন নিয়ন্ত্রণ করে না: কেউ trust না করা folder-এ -p run হলেও Claude Code একটি project skill-এর allowed-tools প্রয়োগ করে। Claude Code documentation-এ ফলাফলটি স্পষ্টভাবে বলা হয়েছে: একটি skill নিজেকে বিস্তৃত tool access দিতে পারে। তাই কোনো repository-তে রাখা skill-এর allowed-tools পরীক্ষা না করে সেখানে Claude Code চালাবেন না। managed settings-এ allowManagedPermissionRulesOnly সেট করে কোনো organization project ও personal skill থেকে এই field আটকে রাখতে পারে। এর জন্য Claude Code v2.1.282 বা পরবর্তী সংস্করণ প্রয়োজন।

তাই skill bump-কে dependency bump-এর মতোই পরিচালনা করুন। যেখানে ব্যবস্থা আছে, exact commit দিয়ে pin করুন, কারণ tag পরিবর্তন করা যায় এবং branch সংজ্ঞা অনুযায়ী পরিবর্তনশীল। সীমাবদ্ধ machine-এ settings-এ "disableSkillShellExecution": true সেট করলে প্রতিটি command substitution চালানোর বদলে literal text [shell command execution disabled by policy] বসানো হয়, এবং managed settings-এর মাধ্যমে প্রয়োগ করলে user এটি override করতে পারে না। Bundled ও managed skill এই setting-এর আওতামুক্ত।

skill কী পড়ে, তার ক্ষেত্রেও একই সতর্কতা প্রযোজ্য। কোনো skill env চালালে বা config file খুললে, সেখানে যা পাওয়া যায় তা model-এর context-এ চলে আসে। আপনি যে agent চালান, তার context-এ secret রাখা থেকে বিরত থাকা বিষয়ক ব্যর্থতাটি এটাই। কোনো skill page fetch করলে বা query চালালে একই exposure বাইরের দিকে ঘটে, কারণ retrieved text আপনার লেখা instruction-এর মতোই context-এ উপস্থিত হয়। তাই web search-এর জন্য আপনার নিজের SearXNG instance-এ agent-কে নির্দেশ দেওয়ার আগে এই boundary সম্পর্কে পড়ে নিন।

ভার্সন পরিবর্তনের সময় যা যা পড়তে হবে

• প্রতিটি SKILL.md বডির ডিফারেন্স (diff), কারণ এই টেক্সটটিই সেই নির্দেশনা যা আপনার এজেন্ট অনুসরণ করবে।
• প্রতিটি কমান্ড সাবস্টিটিউশন, কারণ স্কিল লোড হওয়ার সময় এগুলো আপনার মেশিনে রান করে।
• allowed-tools-এ যেকোনো পরিবর্তন, কারণ এই লাইনটি কোনো প্রম্পট ছাড়াই টুল ব্যবহারের অনুমতি দেয়।
• ট্যাগটির পেছনে থাকা টেস্ট রান। যদি শেয়ার্ড রিপোজিটরি তার নিজস্ব স্মোক টেস্ট CI-তে রান করে, তবে আপনি যে ট্যাগটি পিন করছেন তার সাথে একটি গ্রিন রান সংযুক্ত থাকা উচিত।

যে রিভিউয়ার দশ মিনিটের মধ্যে পুরো ডিফারেন্স পড়তে পারেন না, তিনি এমন একটি স্কিল দেখছেন যা প্রয়োজনের চেয়ে বেশি বড় হয়ে গেছে। এটিকে ভাগ করুন। একই যুক্তি আপনার এজেন্টের পড়া রিপোজিটরি ডকুমেন্টগুলোর ক্ষেত্রেও প্রযোজ্য: স্থায়ী নিয়মগুলো AGENTS.md এবং HUMAN.md বিভাজন-এ বর্ণিত ফাইলগুলোতে রাখুন এবং আর্কিটেকচারাল যুক্তিগুলো এজেন্টদের জন্য লেখা DESIGN.md-এ রাখুন, আর স্কিলগুলোকে সুনির্দিষ্ট প্রসিডিউর হিসেবে থাকতে দিন।

যখন কোনো মডেল বা টুলের পরিবর্তনের কারণে স্কিল কাজ করা বন্ধ করে দেয়

কেউ কোনো কিছু এডিট না করলেও একটি স্কিলের নেপথ্যে অনেক কিছু পরিবর্তিত হতে পারে। মডেল আপগ্রেডের ফলে দীর্ঘ নির্দেশনা অনুসরণের নির্ভরযোগ্যতা বদলে যায়, তাই যে স্কিলটি আগে মডেলের নবম ধাপ পর্যন্ত পৌঁছাতে পারত, তা এখন আর সেখানে পৌঁছাতে পারে না। কোনো কমান্ড লাইন টুল হয়তো তার ফ্ল্যাগ পরিবর্তন করে, ফলে এজেন্ট পুরনো ফ্ল্যাগটি রান করে, এরর মেসেজ পড়ে এবং তাৎক্ষণিকভাবে নতুন কোনো উপায় বের করার চেষ্টা করে। কোনো রেফারেন্সড URL হয়তো 404 এরর দিতে শুরু করে। এজেন্ট হারনেস কীভাবে স্কিল নির্বাচন করে তা পরিবর্তিত হতে পারে, যার ফলে যে description আগে সফল হতো, তা এখন আর কাজ করে না। যখন কোনো প্রসিডিউর এভাবে মাঝপথে শেষ হয়ে যায়, তখন কোনো ভার্সন আপডেট তা ঠিক করতে পারে না। সেক্ষেত্রে নির্দেশনায় এমন কাঠামোর প্রয়োজন হয় যা শেষ ধাপগুলো সম্পন্ন করতে বাধ্য করে; আর এই পদ্ধতিটিই the unlazy skill and its Depth Tree method-এর মূল ভিত্তি।

এই কারণেই এই ব্যবস্থায় স্মোক টেস্ট অত্যন্ত গুরুত্বপূর্ণ। প্রতিটি স্কিলের টেস্ট শিডিউল অনুযায়ী এবং পুশ করার সময় রান করুন। গুগল এই কারণেই তাদের পুরো লাইব্রেরির ওপর সাপ্তাহিক ইভালুয়েশন জব চালায়। দশটি স্কিল আছে এমন একটি টিমের জন্য ছোট একটি VPS-এ সাপ্তাহিক ক্রন জবই যথেষ্ট। ডেভেলপার জানার আগেই সমস্যা সম্পর্কে অবগত হওয়ার এটিই একমাত্র উপায়।

পোর্টেবিলিটিও এক্ষেত্রে সহায়ক। Agent Skills স্পেসিফিকেশন ফ্রন্টম্যাটারকে ছয়টি কী-তে সীমাবদ্ধ রাখে। ফলে এই স্পেসিফিকেশন অনুযায়ী লেখা একটি স্কিল আপনি যে টুলের জন্য এটি লিখেছেন তার বাইরেও অন্যান্য টুলে লোড করা যায়। অন্যদিকে, হারনেস-নির্দিষ্ট প্রতিটি কী যোগ করা মানে হলো একটি নির্দিষ্ট ভেন্ডরের ওপর বাজি ধরা। মডেল পরিবর্তনের পরেও টিকে থাকে এমন স্কিল লেখা একটি আলাদা দক্ষতা, যা making a skill work on any model-এ বিস্তারিত আলোচনা করা হয়েছে।

FAQ

আমি কীভাবে একাধিক repository-তে একটি agent skill শেয়ার করব?

skill-টি একটি dedicated git repository-তে রাখুন, সেখানে release tag করুন, এবং প্রতিটি ব্যবহারকারী project-এ file কপি না করে একটি tag reference করুন। দুটি পদ্ধতি কার্যকর। একটি git submodule নির্দিষ্ট commit record করে, আর submodule-এর মধ্যে .claude/skills/<name> থেকে একটি symlink তৈরি করলে সেটি সাধারণ project skill হিসেবে load হয়। একটি plugin marketplace /plugin-এর মাধ্যমে একই কাজ করে, যেখানে pin ব্যবহারকারী repository-এর .claude/settings.json-এ ঘোষণা করা থাকে। উভয় পদ্ধতিতেই version git history-তে থাকে। তাই কোনো নির্দিষ্ট agent run তৈরি করতে কোন instructions ব্যবহৃত হয়েছে, তা নির্ধারণ করা যায়।

আমি কি একটি agent skill-কে নির্দিষ্ট version-এ pin করতে পারি?

SKILL.md-এর ভেতর থেকে নয়, কারণ ওই frontmatter-এ কোনো version key নেই। File-টির বাইরের layer থেকেই pin দিতে হবে। একটি git submodule নকশাগতভাবেই নির্দিষ্ট commit pin করে। Claude Code plugin marketplace-এ plugin source branch বা tag-এর জন্য ref এবং নির্দিষ্ট commit-এর জন্য sha গ্রহণ করে। দুটিই থাকলে sha অগ্রাধিকার পায়। Marketplace source নিজে শুধু ref গ্রহণ করে। Commit pin ব্যবহার করুন, কারণ আপনি review করার পরে tag পরিবর্তন করা যেতে পারে।

একটি skill smoke test-এ কী assert করা উচিত?

স্থিতিশীল কোনো বিষয়ের ওপর assert করুন। একটি পরিচিত fault-যুক্ত fixture-এর বিরুদ্ধে non-interactively skill চালান। এরপর পরীক্ষা করুন যে output-এ নির্দিষ্ট identifier আছে কি না। যেমন, skill যে rule id report করার কথা, সেটি খুঁজুন। --output-format json এবং --json-schema দিয়ে structured output চাইলে check-টি নির্ভুল হয়। মানটি অনুপস্থিত হলে jq -e script ব্যর্থ করে। সম্পূর্ণ কোনো sentence-এর ওপর কখনো assert করবেন না, কারণ run ভেদে model তার উত্তর ভিন্নভাবে লিখতে পারে।

অন্য দলের repository থেকে একটি shared skill install করা কি নিরাপদ?

এটিকে code dependency হিসেবে বিবেচনা করুন, কারণ এটি executable instruction। একটি SKILL.md load হওয়ার সময় ! command substitution form-এর মাধ্যমে shell command চালাতে পারে। এছাড়া frontmatter-এর allowed-tools field prompt ছাড়াই tool অনুমোদন করতে পারে। প্রতিটি bump-এর সময় diff পড়ুন। branch-এর পরিবর্তে নির্দিষ্ট commit-এ pin করুন। আপনার নিজের team নিয়ন্ত্রণ করে এমন source অগ্রাধিকার দিন। Managed machine-এ settings-এর "disableSkillShellExecution": true user, project, plugin এবং additional-directory skill-এ command substitution চলা বন্ধ করে। bundled এবং managed skill এ নিয়মের বাইরে থাকে।

Claude Code ছাড়া অন্য agent-এ কি একটি shared skill কাজ করবে?

আপনি কোন frontmatter ব্যবহার করছেন, তার ওপর এটি নির্ভর করে। Agent Skills spec ছয়টি key সংজ্ঞায়িত করে: name, description, license, compatibility, metadata এবং allowed-tools। শুধু ওই key-গুলো ব্যবহার করা skill spec বাস্তবায়নকারী বিভিন্ন tool-এ load হয়। এটি কোনো পরিবর্তন ছাড়াই Claude Code-এও load হয়। Harness-specific key এবং spec-এর বাইরের body feature অন্য tool-এ উপেক্ষিত বা প্রত্যাখ্যাত হতে পারে। তাই ব্যাপকভাবে share করার উদ্দেশ্যে তৈরি skill-এ এগুলো রাখবেন না।