Fable method: کسی بھی model کے لیے agent skills

Fable method کا اصل دعویٰ

Fable method چند agent skills پر مشتمل ہے۔ یہ ایک model کے کام کرنے کے طریقوں کو ایک مرتب procedure کی صورت میں لکھتا ہے، تاکہ کوئی دوسرا model اسی procedure کو چلا سکے۔ اس repo کا نام Sahir619/fable-method ہے اور یہ MIT licensed ہے۔ اس کی اپنی ایک سطری وضاحت یہ ہے: "Claude Fable 5 نے کیسے کام کیا، اسے ایسی skills میں ڈھالا گیا ہے جنہیں کوئی بھی model چلا سکتا ہے، اور ساتھ وہ eval بھی ہے جو اس دعوے کو جانچتا رہتا ہے۔" جانچنے کے قابل دعویٰ اس جملے کا دوسرا حصہ ہے۔

کیا کوئی text file واقعی یہ محفوظ کر سکتی ہے کہ کسی مخصوص model نے کیسے سوچا، اس کی تصدیق Anthropic سے باہر کوئی نہیں کر سکتا۔ لیکن جب کوئی کم لاگت والا model وہ text file پڑھتا ہے تو کیا اس کا رویہ مختلف ہوتا ہے، یہ آپ خود ایک VPS پر ایک دوپہر میں جانچ سکتے ہیں۔ ذیل کی پوری مشق کا مقصد یہی پیمائش ہے: ایک ہی task کو دو مرتبہ چلانا، method کے ساتھ اور اس کے بغیر، اور tool calls اور لاگت گننا۔

اگر skill کی اصطلاح آپ کے لیے نئی ہے تو پہلے agent skill اصل میں کیا ہوتی ہے پڑھیں۔ یہ ایک folder ہوتی ہے جس میں SKILL.md file شامل ہوتی ہے، اور اس کے frontmatter description سے agent کو معلوم ہوتا ہے کہ body کب load کرنی ہے۔ جس model کے نام پر repo رکھا گیا ہے، اس کے بارے میں Claude Fable 5 کی لاگت اور اس کی موزوں استعمالات میں بتایا گیا ہے۔

skills انسٹال کریں اور آزمائی گئی version کو pin کریں

انسٹال کرنے کے 2 طریقے ہیں۔ Claude Code کے اندر plugin طریقہ 2 commands پر مشتمل ہے:

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

VPS پر، جہاں آپ disk پر pinned 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 میں 4 skills شامل ہیں، لیکن shell installer صرف 3 کو copy کرتا ہے، اس لیے standalone user کو fable-domain نہیں ملتا، جب تک وہ اسے دستی طور پر copy نہ کرے:

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

tag کو pin کریں، اور حاصل ہونے والے نتائج کے ساتھ tag بھی لکھیں۔ اس repository نے 2026-07-06 اور 2026-07-15 کے درمیان 5 releases شائع کیں، یعنی v1.0.0 سے v1.4.0 تک۔ v1.4.0 نے method میں خود تبدیلی کی، کیونکہ اس میں نیا routing gate شامل کیا گیا۔ August 2026 تک v1.4.0 اب بھی تازہ ترین tag ہے۔ اگر آپ کا control run rules کا ایک version پڑھتا ہے اور test run دوسرا version پڑھتا ہے تو آپ نے کچھ بھی measure نہیں کیا۔

ماہر سے چاروں skills ماڈل کو کیا کرنے کی ہدایت دیتی ہیں

بنیادی فائل skills/fable-method/SKILL.md ہے۔ اس میں دو gates اور سات numbered steps ہیں، اور اس کے rules اتنے واضح ہیں کہ ان پر اختلاف بھی کیا جا سکتا ہے۔

سب سے پہلے triviality gate آتا ہے: جب تبدیلی صرف ایک file کو متاثر کرے، تقریباً 10 lines سے کم ہو، کوئی نیا behavior شامل نہ کرے، اور آپ کو پہلے ہی معلوم ہو کہ کیا تبدیل کرنا ہے، تو براہِ راست کام کریں اور غیر ضروری رسمی کارروائی نہ کریں۔ ایک الگ skill اسی اصول پر مبنی ہے، Ponytail، جو agent کو کام کرنے والی سب سے چھوٹی تبدیلی کی طرف لے جاتی ہے، اور اس کا بنیادی rule اتنا مختصر ہے کہ کچھ install کیے بغیر اسے اپنی instructions میں نقل کیا جا سکتا ہے۔ اس کے بعد fit gate آتا ہے، جو ask کو اس بنیاد پر route کرتا ہے کہ جواب کہاں موجود ہے: وہ sources جنہیں آپ کھول سکتے ہیں، وہ technique جس پر پہلے research کرنا ضروری ہے، یا آپ کا اپنا inference، جسے fact کے طور پر پیش کرنے کے بجائے low confidence کے طور پر نشان زد کرنا ہوگا۔ یہ درمیانی branch اسی وقت کام کرتی ہے جب agent واقعی web تک رسائی رکھتا ہو۔ locked-down VPS پر اس کا مطلب ہے کہ اسے اپنا search backend دینا ہوگا، مثلاً JSON search tool کے طور پر expose کیا گیا self-hosted SearXNG instance۔

پھر loop آتا ہے: ask کو classify کریں، done کی تعریف کریں، evidence جمع کریں، فیصلہ کریں، عمل کریں، verify کریں، اور report کریں۔ Step 2 کہتا ہے کہ files منتخب کرنے سے پہلے directory کی listing کے ذریعے صورتِ حال سمجھیں، یادداشت کے بجائے primary sources کو ترجیح دیں، اور جب دو مسلسل lookups سے کوئی نئی معلومات نہ ملے تو رک جائیں۔ Step 4 کہتا ہے کہ کسی بھی edit سے پہلے INTENT: line لکھیں۔ اس میں درج کریں کہ code کیا کرتا ہے، failing check کس چیز کی توقع رکھتا ہے، اور spec کیا کہتی ہے۔ اگر یہ تینوں ایک دوسرے سے متفق نہ ہوں تو بالکل edit نہ کریں، کیونکہ اصل finding یہی اختلاف ہے۔ Step 5 retries کی حد مقرر کرتا ہے: اسی issue پر تین failed fix-and-verify cycles کے بعد رک جائیں اور actual output واپس کریں۔

فائل کا سب سے زیادہ قابلِ آزمائش حصہ اس کے چار report tokens ہیں۔ Behavior change کے لیے INTENT: line ضروری ہے۔ بیرونی فریق پر اثر انداز ہونے والی action کے لیے AUTH: user said "<exact words>" ضروری ہے، اور اس میں user کا quote شامل ہونا چاہیے، کیونکہ repo واضح طور پر کہتا ہے کہ documentation authorization نہیں ہوتی۔ ایسی prescribed مگر نہ کی گئی action کے لیے PENDING: line ضروری ہے۔ Fixed defect کے لیے TWINS: searched <pattern> - found <N> other sites ضروری ہے۔ اس method کے بارے میں کسی بات پر یقین کیے بغیر بھی آپ جانچ سکتے ہیں کہ جن مواقع پر یہ چار strings درکار ہیں، وہاں وہ موجود ہیں یا نہیں۔ یہی چیز پورے طریقے کو محض تاثرات کے بجائے measurable بناتی ہے۔

fable-loop اسی method کو چار stages میں orchestration کے طور پر چلاتا ہے: parallel evidence subagents کے ذریعے plan بنائیں، main thread پر execute کریں، ایک سے تین attacker subagents کے ذریعے verify کریں، جن میں ہر subagent مختلف lens استعمال کرے، پھر audit اور report کریں۔ اس میں evidence اور attacker roles کے لیے سستے models، جبکہ decisions اور edits کے لیے زیادہ مضبوط model فرض کیا گیا ہے۔

fable-judge وہ حصہ ہے جسے باقی سب چھوڑ دینے کے باوجود install کرنا مفید ہے۔ اس کا مؤقف ہے کہ "report claims کا مجموعہ ہوتی ہے، evidence نہیں۔" یہ finished report سے claims جمع کرتا ہے، git diff اور git status سے ground truth قائم کرتا ہے، report میں بیان کردہ ہر verification دوبارہ چلاتا ہے، اور نامزد fraud list میں موجود مسائل تلاش کرتا ہے: کمزور کیے گئے checks، غلط completion، scope creep، unauthorized action، spec سے انحراف، اور باقی رہ جانے والا debris۔ یہ VERIFIED، VERIFIED WITH CAVEATS، یا REFUTED واپس کرتا ہے، اور جس چیز کو reproduce نہ کر سکے اسے 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 تیار کروایا جا سکتا ہے جسے آپ approve کریں، اور ایسا EVIDENCE report حاصل کیا جا سکتا ہے جسے آپ خود دوبارہ چلا سکیں۔ اس میں coverage کے بجائے mutation testing اس بات کے ثبوت کے طور پر استعمال ہوتی ہے کہ کوئی test واقعی regression پکڑ لے گا۔

fable-domain trap fixtures اور smoke evals کے ساتھ domain adapter bundles تیار کرتا ہے۔ آٹھ adapters فراہم کیے جاتے ہیں: marketing، research، data analysis، business and ops، finance، legal and compliance، design and UX، اور devops۔ Medical اور clinical کام کو دانستہ طور پر کسی adapter کے بغیر رکھا گیا ہے۔

کون سے حصے دوسرے model پر منتقل کیے جا سکتے ہیں، اور کون سے نہیں

repo اس کا براہِ راست جواب AGENTS.md میں دیتا ہے، جو اس طرح شروع ہوتا ہے: "Portable version for any coding agent or harness (Codex, Cursor, aider, a raw system prompt). Identical method to SKILL.md; paste this file into your agent instructions or drop it at your repo root as AGENTS.md." یہ تقریباً 2,600 الفاظ پر مشتمل ہے اور اسی gates، steps اور modes کو برقرار رکھتا ہے۔ اگر آپ پہلے ہی repo-root instruction files رکھتے ہیں تو AGENTS.md اور HUMAN.md convention بتاتا ہے کہ یہ file کہاں رکھی جائے گی اور اسے کون پڑھے گا۔

دو حصے آسانی سے منتقل ہو جاتے ہیں۔ method text ایک ordered prompt ہے جس میں model-specific code نہیں، اس لیے ہر وہ model جو instructions پر عمل کر سکتا ہے، اس method پر بھی عمل کر سکتا ہے۔ repo کا بیان کردہ thesis یہ ہے کہ یہ منتقلی model tier کے الٹ تناسب سے ہوتی ہے۔ judge بھی منتقل ہو جاتا ہے، بشرطیکہ agent کے پاس shell اور repository موجود ہو، کیونکہ اس کا تمام کام git diff اور ان commands کو دوبارہ چلانے پر مشتمل ہے جنہیں قاری بھی چلا سکتا ہے۔

ایک حصہ آسانی سے منتقل نہیں ہوتا۔ fable-loop فرض کرتا ہے کہ harness parallel subagents چلا سکتا ہے اور انہیں مختلف models تک route کر سکتا ہے۔ subagents کے بغیر agent یہ stages ایک ہی model پر serially چلاتا ہے۔ اس سے وہ parallelism اور cost saving ختم ہو جاتی ہے جس نے اس design کا جواز فراہم کیا تھا۔ باقی fable-method رہ جاتا ہے، جس میں صرف اضافی vocabulary شامل ہوتی ہے۔

دو چھوٹی باتیں harness-specific ہیں اور آسانی سے نظرانداز ہو سکتی ہیں۔ /fable-method trigger ایک Claude Code slash command ہے، اس لیے دوسرے harness پر method کو اس کی وضاحت کر کے invoke کرنا ہوگا۔ اسی طرح SKILL.md frontmatter description agent کو body صرف اسی وقت load کرنے دیتی ہے جب وہ task سے match کرے۔ اس کا مطلب ہے کہ installed skill کے فعال ہونے تک اس کی لاگت تقریباً نہ ہونے کے برابر رہتی ہے۔ اس کے بجائے AGENTS.md کو system prompt میں paste کریں تو وہ 2,600 الفاظ آپ کی بھیجی جانے والی ہر request میں شامل رہیں گے، خواہ task ایک سطری typo fix ہو یا refactor۔ یہ لاگت کا حقیقی فرق ہے، اور تقریباً یہی بنیادی وجہ ہے کہ skill packaging موجود ہے۔

VPS پر A/B ٹیسٹ کیسے کریں: ایک ہی کام دو مرتبہ

دو یکساں working copies تیار کریں تاکہ کسی بھی run کو دوسری copy کی edits نظر نہ آئیں۔ YOUR_ORG/YOUR_REPO کو اس repository سے تبدیل کریں جس کے خلاف آپ test کرنا چاہتے ہیں؛ دونوں clones ایک ہی 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 منتخب کریں جس کا outcome رائے کے بغیر مشاہدہ کیا جا سکے: ایسا failing test جس کا pass ہونا ضروری ہو، یا ایسی script جسے 0 exit code کے ساتھ مکمل ہونا چاہیے۔ مبہم task سے موازنہ بھی مبہم ہو جاتا ہے، کیونکہ آپ results کے بجائے prose کی grading کرنے لگتے ہیں۔

Control arm کو --bare کے ساتھ چلائیں۔ یہ 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 شامل کریں۔ یہ 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 مختلف ہے۔ بامعنی موازنے کے لیے یہی ضروری ہے۔

یہ design method text کی پیمائش کرتا ہے۔ یہ skill packaging کی پیمائش نہیں کرتا، کیونکہ وہ الگ سوال ہے۔ Packaging کی پیمائش کے لیے --bare ہٹا دیں، اوپر دیے گئے طریقے کے مطابق skills install کریں، اور skill name کو prompt string میں شامل کریں، کیونکہ user-invoked skills print mode میں expand ہوتے ہیں: claude -p "/fable-method $task"۔ اگر visible behavior یکساں بھی نظر آئے، تو cost profile کے system-prompt arm سے مختلف ہونے کی توقع رکھیں۔

مراحل اور لاگت گننا

دونوں رنز نے JSON events کا stream لکھا۔ آخری سطر ایک result message ہے، جس میں آخری متن، لاگت اور session metadata شامل ہے۔ اسے ایک بار print کریں اور اس کے fields کو script میں استعمال کرنے سے پہلے پڑھیں، کیونکہ field names مختلف Claude Code releases میں تبدیل ہو سکتے ہیں۔

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

ہر run کی لاگت اسی سطر سے حاصل ہوتی ہے، اور موازنہ اسی number سے کریں:

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 calls گن کر معلوم ہوتے ہیں:

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

دونوں files کے لیے یہ عمل دہرائیں۔ فرق کی نوعیت totals سے زیادہ معلومات فراہم کرتی ہے۔ اگر کوئی method run زیادہ files پڑھتا اور کم edits کرتا ہے تو وہ method کی ہدایات کے مطابق کام کر رہا ہے، اور یہی وہ trade-off ہے جس کے لیے آپ لاگت ادا کر رہے ہیں۔ اگر کسی method run نے اتنے ہی edits کیے لیکن لاگت چالیس فیصد زیادہ رہی تو اس task میں اس اضافی لاگت سے کوئی فائدہ نہیں ہوا۔

ان numbers کے بارے میں دو احتیاطیں ضروری ہیں۔ پہلی، ~/.claude/projects/ کے تحت session transcripts سے output_tokens کو جمع کر کے اسے total نہ سمجھیں۔ یہ per-message usage blocks streaming کے دوران لیے گئے snapshots ہوتے ہیں، اور ان کے undercount کرنے کی متعدد reports موجود ہیں۔ result line وہ number ہے جس پر اعتماد کرنا چاہیے۔ دوسری، ہر arm کے لیے صرف ایک run ایک anecdote ہے۔ کسی فرق کو معتبر سمجھنے سے پہلے اسی task پر ہر arm کو تین یا چار بار run کریں، کیونکہ اسی task پر اسی agent کے دو runs بھی ایک دوسرے سے مختلف نتائج دے سکتے ہیں۔ spend کا طویل مدتی جائزہ لینے کے لیے Claude Code spend track کرنے والے tools اور Claude Code tokens کیسے count کرتا ہے یہ واضح کرتے ہیں کہ cache lines raw counts پر کیوں غالب آتی ہیں۔

یقینی بنائیں کہ unattended run کے دوران agent کسی ایسی چیز تک رسائی حاصل نہ کر سکے جس کی آپ کو حفاظت کرنی ہے۔ VPS پر Claude Code محفوظ طریقے سے چلانا user account اور permission flags کا احاطہ کرتا ہے۔

ریپو کی اپنی 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 کے مطابق لکھا گیا ہے، جبکہ failures بھی برقرار رکھے گئے ہیں۔ تاہم جب آپ سرخی والی rows کے پیچھے موجود انفرادی cells دیکھتے ہیں تو یہ سرخی کے عدد سے ظاہر ہونے کے مقابلے میں کم جامع معلوم ہوتی ہے۔

[
  {
    "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 rows میں سب سے بڑا حصہ 4 runs پر مبنی ہے۔ باقی تین rows میں سے ہر ایک 2 runs پر مبنی ہے۔ repo خود بھی log کے آغاز میں درج مستقل limitations میں یہی بات کہتا ہے: "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."

اس بات کا اعتراف کریں۔ جو author اپنا n شائع کرتا ہے اور یہ مسئلہ بھی واضح کرتا ہے کہ اس کا judge اسی model پر مبنی ہے جو baseline کے طور پر استعمال ہوتا ہے، وہ اس category کے عمومی معیار سے زیادہ دیانت دار ہے۔ ان اعداد کو اس بات کے ثبوت کے طور پر پڑھیں کہ author نے واقعی tests چلائے اور failures محفوظ رکھے۔ آپ کے codebase کے بارے میں معلومات آپ کا اپنا A/B test ہی فراہم کرے گا۔

README یہ بھی واضح کرتا ہے کہ یہ method کہاں کوئی فائدہ نہیں دیتا، اور یہی اس کا سب سے مفید paragraph ہے۔ اس میں capable models پر عام چھوٹے tasks کے لیے کسی اضافی فائدے کا اندراج نہیں ہے۔ اس میں کہا گیا ہے کہ "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" میں ظاہر ہوتا ہے۔ اگر آپ کا agent work کسی مضبوط model پر آپ کی نگرانی میں چھوٹی edits تک محدود ہے تو کسی فرق کی توقع نہ کریں۔ اگر یہ کوئی کم لاگت والا model ہے جو unattended چل رہا ہے تو فرق اسی صورت میں ظاہر ہونا چاہیے، اور اسی وجہ سے Opus، Sonnet اور Haiku کے درمیان انتخاب بھی اسی فیصلے کا حصہ بن جاتا ہے۔

جہاں packaging محض رسمی نقل بن جاتی ہے

چار تنقیدیں قابلِ ذکر ہیں، اور ان میں سے کوئی بھی repo کو نظرانداز کرنے کی وجہ نہیں بنتی۔

پیش کردہ framing دستیاب شواہد سے آگے نکل جاتی ہے۔ "How Claude Fable 5 worked" ایک model کے اندرونی طریقۂ کار کے بارے میں دعویٰ ہے، جس کی Anthropic سے باہر کوئی تصدیق نہیں کر سکتا۔ خود repo کا بنیادی جملہ بھی اس دعوے کو کمزور کرتا ہے: "The quality lives in the structure, the evidence, and the honesty, not in the model." اگر معیار structure میں ہے تو provenance story محض آرائش ہے۔ طریقۂ کار اپنی بنیاد پر قائم ہے اور اسے کسی origin myth کی ضرورت نہیں۔

چار skills مواد کی ضرورت سے زیادہ سطحی تقسیم پیش کرتی ہیں۔ fable-loop کے بڑے حصے میں fable-method کو دوبارہ بیان کیا گیا ہے، جبکہ اس کے گرد orchestration شامل ہے، اور ایسے harness میں جس میں subagents نہ ہوں یہ دوبارہ fable-method تک محدود ہو جاتا ہے۔ دونوں files کو side by side پڑھیں، پھر دونوں install کریں۔

آٹھ domain adapters ایسی وسعت ہیں جسے eval cover نہیں کرتا۔ log میں آٹھ میں سے صرف دو کہیں نظر آتے ہیں: round 9 میں marketing اور round 12 میں devops۔ finance، legal، design اور data adapters کے ساتھ کوئی round شامل نہیں۔ آپ کے field کا adapter پھر بھی اچھا ہو سکتا ہے۔ تاہم یہ مصنف کا draft ہے، ایسی چیز نہیں جو trap fixture میں کامیاب ثابت ہو چکی ہو۔

installer اور repo اس بارے میں متفق نہیں کہ کیا ship کیا جاتا ہے؛ installer چار میں سے تین skills کو ~/.claude/skills میں copy کرتا ہے۔ یہ مسئلہ چھوٹا ہے۔ لیکن یہ اسی نوعیت کا فرق ہے جو بتاتا ہے کہ packaging کا کام review سے زیادہ تیزی سے آگے بڑھا۔ اس بات کو یاد رکھیں جب آپ طے کریں کہ اسے ایک وقت میں کتنا اپنانا ہے۔

باقی سب کچھ چھوڑ دیں، مگر یہ چار اصول ضرور رکھیں

برانڈنگ ہٹا دیں تو بھی یہ چار اصول ہر agent کے ساتھ قابلِ عمل رہتے ہیں۔

• اجازت کا اقتباس۔ کسی ناقابلِ واپسی یا بیرونی اثر رکھنے والے action کے لیے user کے اپنے الفاظ درکار ہیں، جو واضح طور پر ایک AUTH: لائن میں درج ہوں۔ جو agent اقتباس تلاش نہ کر سکے، وہ action انجام نہ دے۔
• دوہری جانچ۔ کسی defect کو درست کرنے کے بعد پورے project میں اسی غلط construct کو تلاش کریں اور count رپورٹ کریں، چاہے count صفر ہی کیوں نہ ہو۔
• مشاہدے سے verification۔ خراب build کے اوپر موجود کامیاب targeted check، failed verification ہے، pass نہیں۔
• outcome-first reporting۔ جو کچھ skip کیا گیا ہو یا جس کی verification نہ ہوئی ہو، اسے خاموشی سے حذف کرنے کے بجائے caveat کے طور پر واضح کریں۔

ان چار اصولوں کو اپنانے پر کوئی لاگت نہیں آتی، اور آپ compliance کے لیے grep استعمال کر سکتے ہیں۔ وہیں سے شروع کریں، اوپر دیے گئے harness سے پیمائش کریں، پھر فیصلہ کریں کہ آیا repo کا باقی حصہ آپ کے context budget میں جگہ کا مستحق ہے۔ اگر آپ agent کو working method کے بجائے مستقل project context دینا چاہتے ہیں تو ایک DESIGN.md فائل جو agents کے edit کرنے سے پہلے پڑھتے ہیں اس کا تکمیلی طریقہ ہے۔

FAQ

کیا Fable method، Claude کے علاوہ دیگر models کے ساتھ بھی کام کرتا ہے؟

Method کا متن کام کرتا ہے۔ یہ ایک مرتب prompt ہے جس میں model-specific code شامل نہیں، اور repo میں AGENTS.md بطور portable copy موجود ہے جسے Codex، Cursor، aider یا raw system prompt کے طور پر استعمال کیا جا سکتا ہے۔ دو چیزیں منتقل نہیں ہوتیں۔ /fable-method اور /fable-judge، Claude Code کے slash commands ہیں، اس لیے دیگر جگہوں پر method کو اس کی وضاحت کر کے invoke کرنا ہوگا۔ اور fable-loop ایسے harness پر منحصر ہے جو مختلف models پر parallel subagents چلا سکے؛ اس کے بغیر یہ serially چلتا ہے اور fable-method کو اضافی مراحل کے ساتھ فراہم کرتا ہے۔

کیا ان skills کو چلانے سے زیادہ tokens خرچ ہوتے ہیں؟

ہاں، اور مقدار اس بات پر منحصر ہے کہ آپ انہیں کیسے load کرتے ہیں۔ Skills کے طور پر install ہونے پر body صرف اس وقت load ہوتی ہے جب description task سے match کرے، اس لیے غیر متعلقہ request پر خرچ تقریباً نہ ہونے کے برابر ہوتا ہے۔ System prompt میں paste کرنے پر AGENTS.md کے تقریباً 2,600 الفاظ ہر request کے ساتھ شامل ہوتے ہیں۔ Run پر بھی زیادہ خرچ آتا ہے، کیونکہ method editing سے پہلے orientation، فیصلہ کرنے سے پہلے evidence، اور اس کے بعد حقیقی verification کا تقاضا کرتا ہے۔ اس کی پیمائش کریں: دونوں arms میں --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 نے 5 releases شائع کیں، اور v1.4.0 نے routing rules میں خود تبدیلی کی۔ پیمائش کے دوران main کو track کرنے سے control run اور test run مختلف instructions پڑھ سکتے ہیں، جس سے comparison بے معنی ہو جاتا ہے۔ Tag کو اپنے results کے ساتھ record کریں۔

کیا repo میں موجود eval ایسا benchmark ہے جس پر میں اعتماد کر سکتا ہوں؟

اسے method کے change log کے طور پر دیکھیں، جیسا کہ اس کا author اسے بیان کرتا ہے: "This log exists so method edits are tested, not so anyone mistakes it for a benchmark." File کے شروع میں limitations واضح کی گئی ہیں: ہر cell کے لیے 1 سے 4 runs، synthetic fixtures، اور ایسے LLM judges جو اسی frontier model پر مبنی ہیں جو baseline کے طور پر بھی استعمال ہوتا ہے۔ Rounds حقیقی ہیں اور failed experiments بھی شامل رکھے گئے ہیں، جو زیادہ تر repos کی شائع کردہ معلومات سے بہتر ہے۔ پھر بھی یہ اس بات کی measurement نہیں کہ آپ کے codebase پر کیا ہوگا، اس لیے دو-arm comparison خود چلائیں۔