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

Fable method আসলে কী দাবি করে

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

কোনো text file সত্যিই একটি নির্দিষ্ট model কীভাবে চিন্তা করেছে তা ধারণ করে কি না, 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 pin করে skills ইনস্টল করুন

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

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

VPS-এ disk-এ একটি নির্দিষ্ট copy রাখতে চাইলে আগে repository 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 তালিকাভুক্ত করে। কোনটি অনুপস্থিত তা দেখুন। repository-তে চারটি skill আছে, কিন্তু v1.4.0 shell installer তিনটি copy করে। তাই standalone user নিজে হাতে copy না করলে fable-domain পায় না:

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

tag pin করুন এবং যে ফল পান, তার পাশে tag-টি লিখে রাখুন। changelog-এ 2026-07-06 থেকে 2026-07-15-এর মধ্যে 1.0.0 থেকে 1.4.0 পর্যন্ত পাঁচটি version আছে। কিন্তু tag করা হয়েছিল মাত্র চারটি: v1.0.0, v1.1.0, v1.2.0 এবং v1.4.0। এর মধ্যে শুধু v1.2.0 এবং v1.4.0 GitHub release হিসেবে প্রকাশিত হয়েছিল। v1.3.0 tag নেই। v1.4.0 release notes-এ বলা হয়েছে, unreleased v1.3.0-এর সব পরিবর্তন এতে যুক্ত করা হয়েছে। v1.4.0 নতুন routing gate যোগ করে পদ্ধতিটিই পরিবর্তন করেছে। 2026 সালের October পর্যন্ত v1.4.0-ই সর্বশেষ tag। কিন্তু main এতে এগিয়ে গেছে: 2026-10-03-এর একটি commit Codex install target যোগ করেছে এবং install.sh-কে চারটি skill-ই copy করতে পরিবর্তন করেছে। এখনো কোনো tag-এ এই পরিবর্তন নেই। আপনার control run যদি rules-এর একটি version পড়ে এবং test run অন্য version পড়ে, তাহলে আপনি কিছুই পরিমাপ করেননি।

চারটি skill মডেলকে কী করতে বলে

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

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

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

Fileটির সবচেয়ে সহজে test করা যায় এমন অংশ হলো এর চারটি report token। Behavior পরিবর্তনের ক্ষেত্রে 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 হলো একই পদ্ধতি চারটি stage-এ orchestration হিসেবে চালানো: parallel evidence subagent দিয়ে plan করা, main thread-এ execute করা, ভিন্ন ভিন্ন দৃষ্টিকোণ গ্রহণকারী এক থেকে তিনটি attacker subagent দিয়ে verify করা, তারপর audit ও report করা। এতে evidence এবং attacker role-এর জন্য সস্তা model এবং সিদ্ধান্ত ও edit-এর জন্য শক্তিশালী model ব্যবহারের ধারণা করা হয়েছে।

fable-judge হলো এমন অংশ, যা বাকি সব বাদ দিলেও install করা মূল্যবান। এর মূল অবস্থান হলো: "একটি report হলো claim-এর সমষ্টি, evidence নয়।" এটি সম্পন্ন report থেকে claim সংগ্রহ করে, 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: open Claude Code and type /fable-judge after any agent claims work is done." কাজ শেষ হওয়ার পরে check চালানোর বদলে যদি কাজের মধ্যেই এটি যুক্ত করতে চান, Old Coder skill agent-কে আপনার অনুমোদনের জন্য একটি SPEC এবং নিজে আবার চালাতে পারবেন এমন একটি EVIDENCE report তৈরি করায়। Regression test সত্যিই ধরতে পারবে কি না প্রমাণ করার জন্য এখানে coverage-এর বদলে mutation testing ব্যবহার করা হয়।

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-এ paste করুন অথবা AGENTS.md হিসেবে repo root-এ রাখুন।" এতে প্রায় 2,600টি শব্দ আছে এবং একই gates, steps ও modes বজায় থাকে। আপনি যদি ইতিমধ্যে repo-root instruction file ব্যবহার করেন, তাহলে AGENTS.md এবং HUMAN.md convention ফাইলটি কোথায় থাকবে এবং কে এটি পড়বে, তা নির্ধারণ করে।

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

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

আরও দুটি ছোট বিষয় 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-এ paste করলে আপনি পাঠানো প্রতিটি request-এ ওই 2,600টি শব্দ থাকবে—তা এক লাইনের typo fix হোক বা refactor। এটি বাস্তব cost difference। Skill packaging থাকার প্রধান কারণগুলোর একটি, এবং কার্যত সবচেয়ে বড় কারণ, এটাই।

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

দুটি অভিন্ন working copy তৈরি করুন, যাতে কোনো run-ই অন্যটির edit দেখতে না পারে। যে 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 code দিয়ে শেষ হতে হবে। অস্পষ্ট task অস্পষ্ট তুলনা তৈরি করে, কারণ তখন ফলাফলের বদলে prose-এর মূল্যায়ন করতে হয়।

--bare দিয়ে control arm চালান। এটি hooks, skills, plugins এবং CLAUDE.md-এর auto-discovery এড়িয়ে যায়। এই flag-ই এটিকে control করে তোলে: আগে ইনস্টল করা 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 যোগ করুন। এতে portable method-টি system prompt-এর সংযোজন হিসেবে load হয়:

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 আলাদা থাকবে। তুলনাটি অর্থবহ করার একমাত্র উপায় এটাই।

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

ধাপ ও খরচ গণনা

উভয় run-ই JSON event-এর একটি stream লিখেছে। শেষ line-টি হলো একটি result message, যাতে final text, cost এবং session metadata থাকে। এটিকে একবার print করে পড়ে নিন, তারপর সেটিকে ঘিরে script লিখুন, কারণ 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 গুনে নেওয়া হলে ব্যবহৃত ধাপের সংখ্যা পাওয়া যায়:

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-এর নির্দেশনা অনুযায়ী কাজ করছে; আপনি এই trade-off-টির জন্যই খরচ করছেন। কোনো task-এ একই সংখ্যক edit করে 40 percent বেশি cost হলে, সেই method run আপনাকে কিছুই দেয়নি।

সংখ্যাগুলো নিয়ে দুটি সতর্কতা মনে রাখুন। প্রথমত, ~/.claude/projects/-এর অধীনে session transcript থেকে output_tokens যোগ করে সেটিকে মোট খরচ বলবেন না। ওই per-message usage block-গুলো streaming চলাকালে নেওয়া snapshot, এবং এগুলো কম হিসাব দেখায়—এমন একাধিক report রয়েছে। বিশ্বাস করার মতো সংখ্যা হলো result line-এর সংখ্যা। দ্বিতীয়ত, প্রতিটি arm-এ একটি করে run কেবল anecdote। একই task-এ প্রতিটি arm তিন বা চারবার চালানোর আগে কোনো পার্থক্যকে নির্ভরযোগ্য ধরে নেবেন না, কারণ একই task-এ একই agent-এর দুটি run-এর মধ্যেও পার্থক্য থাকে। দীর্ঘমেয়াদে খরচ বোঝার জন্য Claude Code-এর খরচ 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-এর বিবরণ ব্যর্থতাসহ ধরে রেখেছে। তবে শিরোনামের সারিগুলোর পেছনের পৃথক 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টি সারির মধ্যে সবচেয়ে বড় অংশটি 4টি run-এর ওপর নির্ভর করে। বাকি তিনটি সারি প্রতিটি 2টি run-এর ওপর নির্ভর করে। repo নিজেও লগের শুরুতে থাকা স্থায়ী সীমাবদ্ধতায় তা স্পষ্টভাবে বলেছে: "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-এর ওপর নির্ভর করে—এই সমস্যাটিও উল্লেখ করেন, তাহলে এই ধরনের প্রকল্পে প্রচলিত মানের তুলনায় তিনি বেশি সৎ। সংখ্যাগুলোকে এমন প্রমাণ হিসেবে দেখুন যে লেখক সত্যিই পরীক্ষা চালিয়েছেন এবং ব্যর্থতাগুলো সংরক্ষণ করেছেন। আপনার codebase সম্পর্কে তথ্য দেবে আপনার নিজের A/B পরীক্ষা।

কোথায় method কোনো কাজ করে না, README সেটিও সমানভাবে স্পষ্ট করেছে, এবং এটিই তার সবচেয়ে কার্যকর paragraph। সক্ষম model-এ করা সাধারণ ছোট task-এর ক্ষেত্রে এতে কোনো উন্নতি পাওয়া যায়নি। সেখানে বলা হয়েছে, "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 অবস্থায় run করে, তাহলে সেখানেই পার্থক্য দেখা দেওয়ার কথা; ফলে 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 প্রয়োজন নেই।

চারটি skill-এর প্রয়োজনের তুলনায় এর বাইরের কাঠামো বেশি। fable-loop-এ fable-method-এর বড় একটি অংশ orchestration দিয়ে ঘিরে পুনরাবৃত্তি করা হয়েছে। subagent-সমর্থনহীন harness-এ এটি আবার fable-method-এ নেমে আসে। উভয়টি install করার আগে file দুটি পাশাপাশি পড়ুন।

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

এবং v1.4.0 tag-এর installer repo-র সঙ্গে package করা উপাদান সম্পর্কে একমত নয়; এটি চারটির মধ্যে তিনটি skill ~/.claude/skills-এ copy করে। 2026-10-03 তারিখের main-এর একটি commit প্রায় তিন মাস পরে সমস্যাটি ঠিক করেছে। তবে এখনো কোনো tagged release-এ সেই fix অন্তর্ভুক্ত নেই। এই সমস্যাটি ছোট। একই সঙ্গে, এটি দেখায় যে কেউ review করার আগেই packaging এগিয়ে গেছে। একসঙ্গে এর কতটা গ্রহণ করবেন, তা নির্ধারণের সময় বিষয়টি মনে রাখা উচিত।

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

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

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

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

FAQ

Claude ছাড়া অন্য model-এ কি Fable method কাজ করে?

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

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

হ্যাঁ, এবং আপনি এগুলো কীভাবে load করছেন তার ওপর খরচের পরিমাণ নির্ভর করে। Skill হিসেবে install করলে description task-এর সঙ্গে মিলে যাওয়ার সময়ই body load হয়, তাই সম্পর্কহীন request-এর জন্য খরচ প্রায় হয় না। System prompt-এ paste করলে প্রায় 2,600 শব্দের AGENTS.md প্রতিটি request-এর সঙ্গে যুক্ত থাকে। Run নিজেও বেশি খরচ করে, কারণ method 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 এবং October 2026 পর্যন্ত এটিই সর্বশেষ tag। এর আগে তিনটি tag ছিল (v1.0.0, v1.1.0 এবং v1.2.0; আগের GitHub release ছিল শুধু v1.2.0), আর কখনো release না হওয়া v1.3.0-এর পরিবর্তন এতে যুক্ত করা হয়েছিল। v1.4.0 routing rules-ই পরিবর্তন করেছে। main-ও পরিবর্তিত হচ্ছে; October-এ installer পরিবর্তন হয়েছে, কিন্তু কোনো tag-এ এখনো সেটি নেই। পরিমাপের সময় main অনুসরণ করলে control run এবং test run ভিন্ন instruction পড়তে পারে, ফলে তুলনাটি অর্থহীন হবে। ফলাফলের সঙ্গে tag-টিও নথিভুক্ত করুন।

Repo-র eval কি এমন benchmark, যেটিকে আমি বিশ্বাস করতে পারি?

এটিকে method-এর change log হিসেবে বিবেচনা করুন; এর লেখকও এটিকে এভাবেই বর্ণনা করেছেন: "এই log-এর উদ্দেশ্য method-এর edit পরীক্ষা করা, কেউ যেন এটিকে benchmark মনে না করে।" File-এর শুরুতেই সীমাবদ্ধতাগুলো বলা আছে: প্রতিটি cell-এ 1 থেকে 4টি run, synthetic fixture এবং একই frontier model-এর ওপর তৈরি LLM judge, যে model baseline হিসেবেও ব্যবহৃত হয়। Round-গুলো বাস্তব, এবং ব্যর্থ experiment-গুলোও রাখা হয়েছে; অধিকাংশ repo যতটা প্রকাশ করে, এটি তার চেয়ে বেশি। তবু আপনার codebase-এ কী ঘটবে তার এটি কোনো পরিমাপ নয়। তাই দুই-arm comparison নিজেই চালান।