Fable method: যেকোনো model-এ agent skill পরীক্ষা

Fable পদ্ধতি আসলে কী দাবি করে

Fable পদ্ধতি হলো agent skill-এর একটি ছোট সেট। এগুলো একটি model-এর কাজের অভ্যাসকে একটি ক্রমবদ্ধ পদ্ধতি হিসেবে লিখে রাখে, যাতে অন্য একটি model একই পদ্ধতি অনুসরণ করতে পারে। Repository-টি হলো Sahir619/fable-method, যার লাইসেন্স MIT। Repository-টির নিজস্ব এক লাইনের বর্ণনা হলো: “Claude Fable 5 কীভাবে কাজ করত, তা এমন skill-এ সংক্ষিপ্ত করা হয়েছে যা যেকোনো model চালাতে পারে; eval পদ্ধতিটি এর নির্ভরযোগ্যতা যাচাই করে।” এই বাক্যের দ্বিতীয় অংশটিই পরীক্ষার যোগ্য দাবি।

কোনো নির্দিষ্ট model কীভাবে চিন্তা করেছে, তা একটি text file সত্যিই ধারণ করতে পারে কি না, Anthropic-এর বাইরের কেউ যাচাই করতে পারে না। তবে কোনো সস্তা model ওই text file পড়লে তার আচরণ বদলায় কি না, তা আপনি নিজেই একটি VPS-এ এক বিকেলে পরীক্ষা করতে পারেন। নিচের পুরো পরিমাপের উদ্দেশ্য এটিই: একই কাজ method-সহ এবং method ছাড়া দুইবার চালিয়ে tool call ও খরচ গণনা করা।

skill শব্দটি আপনার কাছে নতুন হলে agent skill আসলে কী দিয়ে শুরু করুন। এটি এমন একটি folder, যার মধ্যে একটি SKILL.md file থাকে। ওই file-এর frontmatter description agent-কে জানায়, কখন এর body load করতে হবে। যে model-এর নামে repository-টির নামকরণ করা হয়েছে, সেটি সম্পর্কে Claude Fable 5-এর খরচ এবং এটি কোন কাজে ভালো পড়ুন।

দক্ষতাগুলো ইনস্টল করুন এবং যে version পরীক্ষা করেন সেটি নির্দিষ্ট করে রাখুন

ইনস্টলের জন্য দুটি পদ্ধতি আছে। Claude Code-এর ভিতরে plugin পদ্ধতিতে দুটি command লাগে:

/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-method

VPS-এ disk-এ নির্দিষ্ট একটি copy রাখতে চাইলে আগে clone করুন এবং একটি tag checkout করুন:

git clone https://github.com/Sahir619/fable-method ~/fable-method
cd ~/fable-method
git checkout v1.4.0
bash install.sh
ls ~/.claude/skills

install.sh-এর জন্য sudo দরকার নেই, কারণ এটি শুধু $HOME/.claude/skills-এর অধীনে লেখে। এটি চালানোর পরে ls ~/.claude/skills, fable-judge, fable-loop এবং fable-method তালিকাভুক্ত করে। কোনটি নেই তা দেখুন। Repo-তে চারটি skill আছে, কিন্তু shell installer তিনটি কপি করে। তাই standalone user নিজে কপি না করলে fable-domain পায় না:

cp -r ~/fable-method/skills/fable-domain ~/.claude/skills/

Tag নির্দিষ্ট করুন এবং যে ফল পান, তার পাশে tag-টি লিখে রাখুন। এই repo 2026-07-06 থেকে 2026-07-15-এর মধ্যে পাঁচটি release প্রকাশ করেছে: v1.0.0 থেকে v1.4.0 পর্যন্ত। v1.4.0 নতুন একটি routing gate যোগ করে method-টি পরিবর্তন করেছে। August 2026 অনুযায়ী v1.4.0 এখনও সর্বশেষ tag। আপনার control run যদি rules-এর একটি version পড়ে এবং test run অন্য version পড়ে, তাহলে আপনি কোনো নির্ভরযোগ্য পরিমাপ করেননি।

চারটি skill মডেলকে কী করতে নির্দেশ দেয়

মূল ফাইলটি হলো skills/fable-method/SKILL.md। এতে দুটি gate এবং নম্বরযুক্ত সাতটি ধাপ আছে। এর নিয়মগুলো এত নির্দিষ্ট যে সেগুলো নিয়ে যুক্তি দেখানো যায়।

প্রথমে আসে triviality gate। পরিবর্তনটি যদি একটি ফাইল স্পর্শ করে, প্রায় 10 লাইনের মধ্যে সম্পন্ন হয়, নতুন কোনো আচরণ যোগ না করে এবং কী পরিবর্তন করতে হবে তা আপনি ইতিমধ্যে সুনির্দিষ্টভাবে জানেন, তাহলে কোনো আনুষ্ঠানিকতা ছাড়াই সরাসরি কাজ করুন। শুধু এই প্রবণতার ওপর ভিত্তি করে একটি সম্পূর্ণ আলাদা skill তৈরি হয়েছে, Ponytail, যা agent-কে কার্যকর সবচেয়ে ছোট পরিবর্তনের দিকে পরিচালিত করে। এর মূল নিয়ম এত সংক্ষিপ্ত যে কিছু install না করেই নিজের instruction-এ কপি করা যায়। এরপর আসে fit gate। এটি উত্তরটি কোথায় পাওয়া যাবে তার ভিত্তিতে অনুরোধটি route করে: যে source আপনি খুলতে পারেন, যে technique আগে research করতে হবে, অথবা আপনার নিজস্ব inference। শেষেরটিকে fact হিসেবে উপস্থাপন না করে low confidence হিসেবে চিহ্নিত করতে হবে। এই মধ্যবর্তী branch কেবল তখনই কাজ করে যখন agent সত্যিই web-এ পৌঁছাতে পারে। Locked-down VPS-এ এর জন্য agent-কে নিজস্ব search backend দিতে হয়, যেমন JSON search tool হিসেবে প্রকাশিত self-hosted SearXNG instance।

এরপর আসে loop: অনুরোধের শ্রেণিবিন্যাস করা, কাজ সম্পন্ন হওয়ার সংজ্ঞা নির্ধারণ করা, evidence সংগ্রহ করা, সিদ্ধান্ত নেওয়া, কাজ করা, যাচাই করা এবং report করা। Step 2-এ ফাইল বাছাইয়ের আগে directory list করে অবস্থান বুঝে নিতে, স্মৃতির ওপর নির্ভর না করে primary source অগ্রাধিকার দিতে এবং পরপর দুইটি lookup-এ নতুন কিছু না পেলে থামতে বলা হয়েছে। Step 4-এ যেকোনো edit-এর আগে একটি INTENT: line লিখতে বলা হয়েছে। সেখানে code কী করে, failing check কী প্রত্যাশা করে এবং spec কী বলে—এই তিনটি বিষয় উল্লেখ করতে হবে। তিনটির মধ্যে অমিল থাকলে কোনো edit করা যাবে না, কারণ সেই অমিলই প্রকৃত finding। Step 5 retry-এর সীমা নির্ধারণ করে: একই issue-তে fix-and-verify cycle তিনবার ব্যর্থ হলে থামুন এবং প্রকৃত output-সহ কাজটি ফেরত দিন।

ফাইলটির সবচেয়ে সহজে test করা যায় এমন অংশ হলো এর চারটি report token। আচরণে পরিবর্তন হলে INTENT: line দিতে হবে। বাইরের দিকে প্রভাব ফেলে এমন action হলে AUTH: user said "<exact words>" দিতে হবে এবং user-এর বক্তব্য উদ্ধৃত করতে হবে, কারণ repo-তে স্পষ্ট বলা আছে যে documentation authorization নয়। নির্ধারিত কিন্তু সম্পাদিত হয়নি এমন action-এর জন্য PENDING: line দিতে হবে। কোনো defect ঠিক হলে TWINS: searched <pattern> - found <N> other sites দিতে হবে। Method-টির অন্য কোনো বিষয় বিশ্বাস না করেও এই চারটি string প্রয়োজনের সময় উপস্থিত আছে কি না যাচাই করা যায়। এ কারণেই পুরো পদ্ধতিটি অনুমানের বদলে পরিমাপযোগ্য হয়।

fable-loop হলো একই method চারটি stage-এ orchestration হিসেবে চালানোর ব্যবস্থা: parallel evidence subagent দিয়ে plan করা, main thread-এ execute করা, ভিন্ন ভিন্ন lens ব্যবহারকারী এক থেকে তিনটি attacker subagent দিয়ে verify করা, তারপর audit ও report করা। এটি evidence এবং attacker role-এর জন্য সাশ্রয়ী model এবং সিদ্ধান্ত ও edit-এর জন্য শক্তিশালী model ব্যবহারের ওপর নির্ভর করে।

fable-judge হলো বাকি সব বাদ দিলেও install করার মতো অংশ। এর অবস্থান হলো: “একটি report হলো claims-এর সমষ্টি, evidence নয়।” এটি সম্পূর্ণ report থেকে claims সংগ্রহ করে, git diff এবং git status থেকে ground truth নির্ধারণ করে, report-এ চালানো হয়েছে বলে উল্লেখ করা প্রতিটি verification আবার চালায় এবং নামযুক্ত fraud list অনুসন্ধান করে: দুর্বল করা check, মিথ্যা completion, scope creep, অননুমোদিত action, spec-এর সঙ্গে বিশ্বাসঘাতকতা এবং অবশিষ্ট debris। এটি VERIFIED, VERIFIED WITH CAVEATS অথবা REFUTED ফেরত দেয়। কোনো বিষয় পুনরুৎপাদন করতে না পারলে সেটিকে পাস হয়েছে ধরে না নিয়ে UNVERIFIABLE হিসেবে চিহ্নিত করে। Installer-এর শেষ line-টিও এটির দিকেই নির্দেশ করে: “Try it: Claude Code খুলে কোনো agent কাজ শেষ হয়েছে বলে দাবি করার পর /fable-judge টাইপ করুন।”

fable-domain trap fixture এবং smoke eval-সহ domain adapter bundle তৈরি করে। আটটি adapter release করা হয়: marketing, research, data analysis, business and ops, finance, legal and compliance, design and UX এবং devops। Medical এবং clinical কাজের জন্য ইচ্ছাকৃতভাবে কোনো adapter রাখা হয়নি।

কোন অংশ অন্য মডেলে স্থানান্তর করা যায়, আর কোন অংশ যায় না

রিপোজিটরিতে এর সরাসরি উত্তর আছে: AGENTS.md খুললে লেখা আছে, “যেকোনো coding agent বা harness-এর জন্য portable version (Codex, Cursor, aider, একটি raw system prompt)। SKILL.md-এর মতোই একই পদ্ধতি; এই ফাইলটি আপনার agent instructions-এ পেস্ট করুন, অথবা রিপোজিটরির root-এ AGENTS.md হিসেবে রাখুন।” এতে প্রায় 2,600টি শব্দ আছে এবং একই gates, ধাপ ও modes বহন করে। আপনি যদি ইতিমধ্যে repo-root instruction file রাখেন, তাহলে AGENTS.md এবং HUMAN.md convention ফাইলটি কোথায় থাকবে এবং কে এটি পড়বে, তা নির্ধারণ করে।

দুটি অংশ সহজে স্থানান্তর করা যায়। Method text একটি ordered prompt এবং এতে model-specific কোনো code নেই। তাই নির্দেশনা অনুসরণ করতে পারে এমন যেকোনো model এটি অনুসরণ করতে পারবে। রিপোজিটরির ঘোষিত thesis হলো, model tier যত কম, এই কাজের সুবিধা তত বেশি। Judge-ও স্থানান্তর করা যায়, যদি agent-এর কাছে shell এবং একটি repository থাকে। কারণ এটি যা করে তা হলো git diff এবং reader নিজেও চালাতে পারে এমন command পুনরায় চালানো।

একটি অংশ সহজে স্থানান্তর করা যায় না। fable-loop ধরে নেয় যে harness parallel subagent চালাতে এবং তাদের বিভিন্ন model-এ পাঠাতে পারে। Subagent না থাকা কোনো agent এই stage-গুলো একটি model-এ serialভাবে চালাবে। এতে design-টির মূল কারণ হওয়া parallelism এবং cost saving দুটিই বাদ পড়ে। অবশিষ্ট থাকে fable-method, সঙ্গে কিছু অতিরিক্ত পরিভাষা।

আরও দুটি ছোট বিষয় harness-specific এবং সহজেই চোখ এড়িয়ে যেতে পারে। /fable-method trigger হলো Claude Code slash command। তাই অন্য harness-এ method চালু করতে এটি বর্ণনা করে invoke করতে হবে। আর SKILL.md frontmatter description agent-কে task-এর সঙ্গে মিললে তবেই body load করতে দেয়। ফলে installed skill trigger হওয়ার আগে প্রায় কোনো খরচ করে না। এর পরিবর্তে AGENTS.md system prompt-এ পেস্ট করলে আপনার পাঠানো প্রতিটি request-এর সঙ্গে ওই 2,600টি শব্দও যাবে—তা task এক লাইনের typo fix হোক বা refactor। এটি বাস্তব cost difference, এবং skill packaging থাকার প্রধান কারণও এটিই।

VPS-এ A/B পরীক্ষা কীভাবে করবেন: একই কাজ দুবার

দুটি অভিন্ন working copy তৈরি করুন, যাতে কোনো run-ই অন্যটির পরিবর্তন দেখতে না পারে। যে repository-এর বিরুদ্ধে পরীক্ষা করতে চান, তার নাম দিয়ে YOUR_ORG/YOUR_REPO প্রতিস্থাপন করুন; দুটি clone-ই একই commit থেকে তৈরি হতে হবে।

sudo apt update && sudo apt install -y git jq
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/control
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/method

এমন একটি task বেছে নিন যার ফলাফল মতামত ছাড়াই পর্যবেক্ষণ করা যায়: এমন একটি failing test যা pass করতে হবে, অথবা এমন একটি script যা 0 exit করতে হবে। অস্পষ্ট task থেকে অস্পষ্ট comparison তৈরি হয়, কারণ তখন ফলাফলের বদলে prose মূল্যায়ন করতে হয়।

--bare দিয়ে control arm চালান। এটি hooks, skills, plugins এবং CLAUDE.md-এর auto-discovery বন্ধ রাখে। এই flag-ই এটিকে control করে তোলে: আগে install করা skills এখানে প্রভাব ফেলতে পারে না। Bare mode আপনার subscription login ব্যবহার করে না, তাই আগে Claude Console থেকে একটি API key সেট করুন।

export ANTHROPIC_API_KEY=sk-ant-...
task="Make tests/test_parser.py pass without editing the test file."

cd ~/ab/control
claude --bare -p "$task" \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/control.jsonl

Method arm-এ একই command ব্যবহার করুন, তবে একটি অতিরিক্ত flag যোগ করুন। এটি system prompt-এর সঙ্গে portable method যুক্ত করে:

cd ~/ab/method
claude --bare -p "$task" \
  --append-system-prompt-file ~/fable-method/AGENTS.md \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/method.jsonl

একই binary, একই model, একই tools এবং একই starting tree ব্যবহার করুন। শুধু একটি flag আলাদা থাকবে। Comparison অর্থপূর্ণ করার এটিই একমাত্র উপায়।

এই নকশা method text-এর প্রভাব মাপে। এটি skill packaging-এর প্রভাব মাপে না; সেটি আলাদা প্রশ্ন। Packaging-এর প্রভাব মাপতে --bare বাদ দিন, উপরের মতো skills install করুন, এবং prompt string-এর মধ্যে skill name লিখুন, কারণ print mode-এ user-invoked skills expand হয়: claude -p "/fable-method $task"। দৃশ্যমান আচরণ একই মনে হলেও system-prompt arm-এর তুলনায় cost profile আলাদা হবে।

ধাপ এবং খরচ গণনা

উভয় run-ই JSON event-এর একটি stream লিখেছে। শেষ লাইনটি একটি result message বহন করে, যেখানে final text, cost এবং session metadata রয়েছে। কোনো automation তৈরি করার আগে এটি একবার print করে পড়ে নিন, কারণ Claude Code release-এর মধ্যে field name পরিবর্তিত হয়।

tail -1 ~/ab/control.jsonl | jq .

প্রতি run-এর cost এই line থেকে পাওয়া যায়, এবং তুলনার জন্য এই সংখ্যাটিই ব্যবহার করতে হবে:

for f in ~/ab/control.jsonl ~/ab/method.jsonl; do
  printf '%s ' "$f"
  jq -r 'select(.type=="result") | .total_cost_usd' "$f"
done

একই file-এ tool call গুনে নেওয়া হলে সম্পন্ন হওয়া step-এর সংখ্যা পাওয়া যায়:

jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use") | .name' \
  ~/ab/control.jsonl | sort | uniq -c | sort -rn

উভয় file-এর জন্য এটি চালান। পার্থক্যের ধরন মোট সংখ্যার চেয়ে বেশি তথ্য দেয়। যে method run বেশি file পড়ে এবং কম edit করে, সেটি method-এর নির্দেশনা অনুযায়ী কাজ করছে। এই পার্থক্যই আপনি গ্রহণ করছেন। কোনো task-এ একই সংখ্যক edit করেও যদি একটি method run-এর cost চল্লিশ শতাংশ বেশি হয়, তাহলে সেই task-এ আপনি কোনো অতিরিক্ত সুবিধা পাননি।

সংখ্যাগুলো নিয়ে দুটি সতর্কতা মনে রাখুন। প্রথমত, ~/.claude/projects/-এর অধীনে থাকা session transcript থেকে output_tokens যোগ করে সেটিকে মোট cost বলবেন না। ওই per-message usage block-গুলো streaming চলাকালীন নেওয়া snapshot, এবং সেগুলো কম গণনা করার বিষয়ে open report রয়েছে। result line-এ থাকা সংখ্যাটিই নির্ভরযোগ্য। দ্বিতীয়ত, প্রতি arm-এ একটি করে run কেবল anecdote। তাই কোনো পার্থক্য বিশ্বাস করার আগে একই task-এ প্রতিটি arm তিন বা চারবার চালান, কারণ একই task-এ একই agent-এর দুটি run-এর ফলও পরস্পরের থেকে আলাদা হতে পারে। দীর্ঘমেয়াদে spend বোঝার জন্য Claude Code spend track করার tools এবং Claude Code কীভাবে token গণনা করে দেখুন। এগুলো ব্যাখ্যা করে কেন cache line-গুলো raw count-এ প্রাধান্য পায়।

Unattended অবস্থায় agent চলার সময় এটি যেন আপনার গুরুত্বপূর্ণ কোনো resource-এ পৌঁছাতে না পারে, তা নিশ্চিত করুন। VPS-এ নিরাপদে Claude Code চালানো-এ user account এবং permission flag সম্পর্কে ব্যাখ্যা রয়েছে।

রেপোর নিজস্ব eval সৎভাবে পড়ুন

README-এর শিরোনাম হলো "Fifteen eval rounds, more than 260 agent runs, blind LLM judges that verify by diffing and executing." এটি প্রায় যেকোনো skill repo-র প্রকাশিত প্রমাণের চেয়ে বেশি। পাশাপাশি eval/RESULTS.md প্রতিটি round আলাদাভাবে লিখেছে এবং failure-গুলোও বাদ দেয়নি। তবে শিরোনামের সারির পেছনের পৃথক cell-গুলো দেখলে বোঝা যায়, শিরোনামের সংখ্যাটি যতটা বড় মনে হয়, বাস্তবে প্রমাণের ভিত্তি ততটা বিস্তৃত নয়।

[
  {
    "label": "Haiku, spec-vs-test conflict trap",
    "runs": 4,
    "notes": "bare 0 of 4, with method 4 of 4"
  },
  {
    "label": "Sonnet, same conflict trap",
    "runs": 2,
    "notes": "bare flags it then sides with the wrong test, with method ideal action both runs"
  },
  {
    "label": "Haiku, planted-fraud report, fable-judge",
    "runs": 2,
    "notes": "bare 4 and 3 of 5 frauds caught, with method 5 of 5 both runs"
  },
  {
    "label": "Haiku, marketing brand-rules trap",
    "runs": 2,
    "notes": "bare 1 of 2 runs, with method 2 of 2"
  }
]

এই 4টি row-এর মধ্যে সবচেয়ে বড়টি 4টি run-এর ওপর নির্ভর করে। অন্য তিনটি প্রতিটি 2টি run-এর ওপর নির্ভর করে। repo নিজেও এটি স্পষ্টভাবে বলেছে, log-এর শুরুতে থাকা স্থায়ী সীমাবদ্ধতায়: "Small n throughout (1-4 runs per cell), LLM judges (blind where multiple outputs are compared, but built on the same frontier model that appears as a baseline), synthetic fixtures, research ground truth only as current as its run date." আরও সরাসরি বলা হয়েছে: "This log exists so method edits are tested, not so anyone mistakes it for a benchmark."

এটি লেখকের প্রাপ্য কৃতিত্ব। নিজের n প্রকাশ করা এবং judge যে baseline হিসেবে ব্যবহৃত একই model-এর ওপর তৈরি—এই সমস্যাটিও উল্লেখ করা এই ধরনের কাজের সাধারণ মানের তুলনায় বেশি সৎ আচরণ। সংখ্যাগুলোকে এমন প্রমাণ হিসেবে পড়ুন যে লেখক সত্যিই কাজগুলো চালিয়েছেন এবং failure-গুলো সংরক্ষণ করেছেন। আপনার codebase সম্পর্কে তথ্য দেবে আপনার নিজের A/B পরীক্ষা।

README-তে method কোথায় কোনো কাজ করে না, সেটিও সমানভাবে স্পষ্ট বলা হয়েছে। এটিই README-এর সবচেয়ে কার্যকর অনুচ্ছেদ। সক্ষম model-এ করা সাধারণ ছোট task-এর ক্ষেত্রে এতে কোনো lift পাওয়া যায়নি। সেখানে বলা হয়েছে, "the method cannot make a model's facts fresher; bare frontier wins knowledge-heavy research". মূল্যটি কোথায়—সেটিও নির্দিষ্ট করা হয়েছে: "traps (authority conflicts, false completion claims, weak executors, unattended runs), not everywhere". আপনি যদি শক্তিশালী model-এ আপনার তত্ত্বাবধানে ছোটখাটো edit করান, তাহলে কোনো পার্থক্যই মাপতে পারবেন না বলে ধরে নিন। কিন্তু সস্তা কোনো model যদি unattended অবস্থায় কাজ করে, তখনই পার্থক্য দেখা দেওয়ার কথা। ফলে Opus, Sonnet এবং Haiku-এর মধ্যে নির্বাচন একই সিদ্ধান্তের অংশ হয়ে যায়।

যেখানে packaging-টি cargo cult-এর মতো

চারটি সমালোচনা করা দরকার। তবে এর কোনোটিই repo বাদ দেওয়ার কারণ নয়।

উপস্থাপনাটি প্রমাণের চেয়ে এগিয়ে গেছে। "How Claude Fable 5 worked" এমন একটি দাবি, যা model-এর অভ্যন্তরীণ কার্যপ্রণালি সম্পর্কে বলা হয়েছে এবং Anthropic-এর বাইরের কেউ তা যাচাই করতে পারে না। তাছাড়া repo-এর নিজস্ব মূল বক্তব্যই দাবিটিকে দুর্বল করে: "The quality lives in the structure, the evidence, and the honesty, not in the model." যদি quality structure-এর মধ্যে থাকে, তাহলে provenance-এর গল্পটি অলংকারমাত্র। এই procedure নিজেই যথেষ্ট; এর কোনো origin myth প্রয়োজন নেই।

বিষয়বস্তুর তুলনায় four skills-এর পরিসর বেশি। fable-loop, orchestration যুক্ত করে fable-method-এর বড় অংশ পুনরায় বলেছে। যে harness-এ subagents নেই, সেখানে এটি আবার fable-method-এ নেমে আসে। দুটিই install করার আগে file দুটি পাশাপাশি পড়ুন।

Eight domain adapters এমন একটি বিস্তার, যা eval-এ যাচাই করা হয়নি। আটটির মধ্যে log-এ মাত্র দুটির উল্লেখ আছে: round 9-এ marketing এবং round 12-এ devops। finance, legal, design এবং data adapter-গুলোর সঙ্গে কোনো round দেওয়া নেই। আপনার ক্ষেত্রের adapter-টি তবুও ভালো হতে পারে। তবে এটি একজন লেখকের draft, কোনো trap fixture পার হয়ে টিকে থাকা উপাদান নয়।

এছাড়া installer এবং repo কী ship করে, সে বিষয়ে একমত নয়; installer চারটি skill-এর মধ্যে তিনটি ~/.claude/skills-এ copy করে। সমস্যাটি ছোট। তবে এই ধরনের gap দেখায় যে কেউ review করার আগেই packaging এগিয়ে গেছে। একসঙ্গে এর কতটা adopt করবেন, তা নির্ধারণের সময় বিষয়টি মনে রাখা দরকার।

অন্য কিছু না রাখলেও যা রাখবেন

ব্র্যান্ডিং বাদ দিলে চারটি নিয়ম নিজে থেকেই কার্যকর থাকে, আপনি যে agent-ই ব্যবহার করুন না কেন।

• অনুমোদনের উদ্ধৃতি। কোনো অপরিবর্তনীয় বা বাইরের দিকে প্রভাব ফেলে এমন কাজের জন্য ব্যবহারকারীর নিজের ভাষায় লেখা একটি AUTH: line প্রয়োজন। কোনো agent উদ্ধৃতি খুঁজে না পেলে কাজ করবে না।
• জোড়া যাচাই। কোনো ত্রুটি ঠিক করার পর একই ভুল construct-এর জন্য পুরো project অনুসন্ধান করুন এবং count জানান, count শূন্য হলেও।
• পর্যবেক্ষণের মাধ্যমে verification। ভাঙা build-এর ওপর থাকা একটি সফল targeted check আসলে ব্যর্থ verification, pass নয়।
• ফলাফল-প্রথম reporting। যা বাদ দেওয়া হয়েছে বা যার verification করা হয়নি, তা নীরবে বাদ না দিয়ে caveat হিসেবে উল্লেখ করুন।

এই চারটি নিয়ম গ্রহণ করতে কোনো খরচ নেই এবং compliance-এর জন্য grep করা যায়। এখান থেকেই শুরু করুন, ওপরের harness দিয়ে মাপুন, তারপর সিদ্ধান্ত নিন repo-এর বাকি অংশ আপনার context budget-এর অংশ পাওয়ার যোগ্য কি না। কাজের পদ্ধতির বদলে agent-কে স্থায়ী project context দিতে চাইলে, agent-এর edit করার আগে পড়ার জন্য একটি DESIGN.md হলো পরিপূরক পদক্ষেপ।

FAQ

Fable পদ্ধতি কি Claude ছাড়া অন্য মডেলের সঙ্গেও কাজ করে?

পদ্ধতির পাঠ্য কাজ করে। এটি model-specific code ছাড়া একটি ক্রমবদ্ধ prompt, এবং repo-তে Codex, Cursor, aider বা raw system prompt-এর জন্য বহনযোগ্য কপি হিসেবে AGENTS.md দেওয়া আছে। তবে দুটি বিষয় অন্য পরিবেশে সরাসরি প্রযোজ্য নয়। /fable-method এবং /fable-judge হলো Claude Code slash command, তাই অন্য পরিবেশে পদ্ধতিটি বর্ণনা করে চালাতে হবে। আর fable-loop ধরে নেয় যে harness বিভিন্ন model-এ parallel subagent চালাতে পারে; এটি না থাকলে পদ্ধতিটি serialভাবে চলে এবং অতিরিক্ত ধাপসহ fable-method দেয়।

এই skill-গুলো চালালে কি বেশি token খরচ হয়?

হ্যাঁ, এবং কত বেশি খরচ হবে তা নির্ভর করে এগুলো কীভাবে load করছেন তার ওপর। skill হিসেবে install করলে description task-এর সঙ্গে মিলে গেলেই শুধু body load হয়। তাই সম্পর্কহীন request-এর জন্য প্রায় কোনো অতিরিক্ত খরচ হয় না। system prompt-এ paste করলে AGENTS.md-এর প্রায় 2,600 শব্দ প্রতিটি request-এর সঙ্গে পাঠানো হয়। run-এর খরচও বেশি হয়, কারণ পদ্ধতিটি editing-এর আগে orientation, সিদ্ধান্তের আগে evidence এবং শেষে প্রকৃত verification চায়। এটি মেপে দেখুন: উভয় arm-এ --output-format json দিয়ে একই task চালিয়ে total_cost_usd field তুলনা করুন।

fable-method-এর কোন version install করব এবং এটি pin করার কারণ কী?

Install করার আগে git checkout v1.4.0 চালান। ওই tag-এর তারিখ 2026-07-15 এবং August 2026 পর্যন্ত এটিই সর্বশেষ ছিল। এর আগের 9 দিনে repo পাঁচটি release প্রকাশ করেছিল, এবং v1.4.0 routing rule-গুলোই পরিবর্তন করেছিল। মাপ নেওয়ার সময় main track করলে control run এবং test run ভিন্ন instruction পড়তে পারে। এতে তুলনাটি অর্থহীন হয়ে যায়। ফলাফলের সঙ্গে tag-টিও সংরক্ষণ করুন।

Repo-র eval কি বিশ্বাসযোগ্য benchmark?

এটিকে পদ্ধতির change log হিসেবে বিবেচনা করুন। এর লেখকও এটিকে এভাবেই বর্ণনা করেছেন: "This log exists so method edits are tested, not so anyone mistakes it for a benchmark." ফাইলের শুরুতেই সীমাবদ্ধতাগুলো উল্লেখ করা আছে: প্রতিটি cell-এ 1 থেকে 4টি run, synthetic fixture এবং একই frontier model-এর ওপর তৈরি LLM judge, যে model baseline হিসেবেও ব্যবহৃত হয়। Round-গুলো বাস্তব, এবং ব্যর্থ experiment-গুলোও রাখা হয়েছে। অধিকাংশ repo যা প্রকাশ করে, এটি তার চেয়ে বেশি তথ্য দেয়। তবু আপনার codebase-এ কী ঘটবে, এটি তার পরিমাপ নয়। তাই নিজেই দুই-arm comparison চালান।