Fable method का उपयोग करके AI एजेंट स्किल्स कैसे बनाएं

Fable method वास्तव में क्या दावा करता है

Fable method एजेंट स्किल्स का एक छोटा समूह है जो एक मॉडल की कार्य करने की आदतों को एक क्रमिक प्रक्रिया के रूप में लिखता है, ताकि कोई अन्य मॉडल उसी प्रक्रिया को चला सके। रिपॉजिटरी Sahir619/fable-method है, जो MIT लाइसेंस के अंतर्गत है, और इसका अपना एक-पंक्ति विवरण है "Claude Fable 5 कैसे काम करता था, इसे उन स्किल्स में संकलित किया गया है जिन्हें कोई भी मॉडल चला सकता है, साथ ही वह मूल्यांकन जो इसे ईमानदार रखता है।" इस वाक्य का दूसरा भाग परीक्षण करने योग्य दावा है।

क्या कोई टेक्स्ट फाइल वास्तव में यह पकड़ पाती है कि एक विशिष्ट मॉडल ने कैसे सोचा, यह ऐसी चीज नहीं है जिसे Anthropic के बाहर कोई भी जांच सके। जब कोई सस्ता मॉडल उस टेक्स्ट फाइल को पढ़ता है तो वह अलग तरह से व्यवहार करता है या नहीं, यह आप स्वयं एक VPS पर, एक दोपहर में जांच सकते हैं। नीचे दी गई हर चीज का उद्देश्य यही मापन है: एक ही कार्य को दो बार करना, मेथड के साथ और उसके बिना, टूल कॉल्स और लागत की गणना करना।

यदि 'skill' शब्द आपके लिए नया है, तो एजेंट स्किल वास्तव में क्या है से शुरुआत करें: एक फोल्डर जिसमें एक SKILL.md फाइल होती है, जिसका फ्रंटमैटर विवरण एजेंट को बताता है कि बॉडी को कब लोड करना है। जिस मॉडल के नाम पर रिपॉजिटरी है, उसे Claude Fable 5 की लागत और उसकी उपयोगिता में कवर किया गया है।

Skills इंस्टॉल करें और जिस वर्ज़न का आप परीक्षण कर रहे हैं उसे पिन करें

इंस्टॉल करने के दो तरीके हैं। Claude Code के भीतर, प्लगइन रूट के लिए दो कमांड्स की आवश्यकता होती है:

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

VPS पर, जहाँ आप डिस्क पर एक पिन की गई कॉपी चाहते हैं, पहले क्लोन करें और एक टैग चेक आउट करें:

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 की सूची होती है। देखें कि क्या मौजूद नहीं है। रिपॉजिटरी चार स्किल्स के साथ आती है और v1.4.0 शेल इंस्टॉलर तीन को कॉपी करता है, इसलिए एक स्टैंडअलोन उपयोगकर्ता को fable-domain तब तक नहीं मिलता जब तक वे इसे मैन्युअल रूप से कॉपी न करें:

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

टैग को पिन करें, और जो भी परिणाम आपको मिलते हैं, उनके बगल में टैग को नोट कर लें। चेंजलॉग में 2026-07-06 और 2026-07-15 के बीच पांच वर्ज़न सूचीबद्ध हैं, 1.0.0 से 1.4.0 तक, लेकिन केवल चार को टैग किया गया था (v1.0.0, v1.1.0, v1.2.0 और v1.4.0) और केवल v1.2.0 और v1.4.0 ही GitHub releases के रूप में जारी किए गए थे। कोई v1.3.0 टैग नहीं है; v1.4.0 के रिलीज़ नोट्स कहते हैं कि इसमें अनरिलीज़्ड v1.3.0 की सभी चीजें शामिल हैं। v1.4.0 ने एक नया राउटिंग गेट जोड़कर स्वयं विधि को बदल दिया। अक्टूबर 2026 तक, v1.4.0 अभी भी सबसे नया टैग है, लेकिन main इससे आगे बढ़ चुका है: 2026-10-03 के एक कमिट ने एक Codex इंस्टॉल टारगेट जोड़ा और install.sh को सभी चार स्किल्स कॉपी करने के लिए बनाया, और अभी तक कोई टैग उस बदलाव को नहीं ले जाता है। यदि आपका कंट्रोल रन नियमों का एक वर्ज़न पढ़ता है और आपका टेस्ट रन दूसरा, तो आपने कुछ भी मापा नहीं है।

चारों कौशल मॉडल को क्या करने का निर्देश देते हैं

मुख्य फाइल skills/fable-method/SKILL.md है। इसमें दो गेट और सात क्रमांकित चरण हैं, और इसके नियम इतने विशिष्ट हैं कि उन पर तर्क किया जा सकता है।

सबसे पहले 'triviality' गेट आता है: सीधे कार्य करें, बिना किसी औपचारिकता के, जब बदलाव केवल एक फाइल तक सीमित हो, लगभग 10 लाइनों के भीतर हो, कोई नया व्यवहार न जोड़े, और आप पहले से जानते हों कि क्या बदलना है। केवल इसी प्रवृत्ति पर एक अलग कौशल आधारित है, Ponytail, जो एजेंट को सबसे छोटे कार्यशील बदलाव की ओर धकेलता है, और इसका मुख्य नियम इतना छोटा है कि आप बिना कुछ इंस्टॉल किए इसे अपने निर्देशों में कॉपी कर सकते हैं। इसके बाद 'fit' गेट आता है जो अनुरोध को इस आधार पर निर्देशित करता है कि उत्तर कहाँ स्थित है: ऐसे स्रोत जिन्हें आप खोल सकते हैं, कोई तकनीक जिस पर आपको पहले शोध करना होगा, या आपका अपना अनुमान, जिसे तथ्य के रूप में प्रस्तुत करने के बजाय 'low confidence' के रूप में चिह्नित किया जाना चाहिए। वह मध्य शाखा तभी काम करती है जब एजेंट वास्तव में वेब तक पहुँच सके, जिसका अर्थ है कि एक locked-down VPS पर उसे अपना स्वयं का सर्च बैकएंड देना होगा, जैसे कि JSON सर्च टूल के रूप में expose किया गया एक self-hosted SearXNG instance।

फिर लूप आता है: अनुरोध को वर्गीकृत करें, 'done' को परिभाषित करें, साक्ष्य जुटाएं, निर्णय लें, कार्य करें, सत्यापित करें, रिपोर्ट करें। चरण 2 कहता है कि फाइलें चुनने से पहले डायरेक्टरी को लिस्ट करके स्थिति समझें, याददाश्त के बजाय प्राथमिक स्रोतों को प्राथमिकता दें, और लगातार दो बार कुछ भी नया न मिलने पर रुक जाएं। चरण 4 कहता है कि किसी भी व्यवहार-परिवर्तन वाले संपादन से पहले एक INTENT: लाइन लिखें, जिसमें यह बताएं कि कोड क्या करता है, विफल चेक क्या अपेक्षा करता है, और स्पेक (spec) क्या कहता है। यदि ये तीनों आपस में मेल नहीं खाते हैं, तो संपादन बिल्कुल न करें, क्योंकि यही विसंगति ही वास्तविक निष्कर्ष है। चरण 5 पुनः प्रयासों (retries) को सीमित करता है: एक ही समस्या पर तीन विफल 'fix-and-verify' चक्रों के बाद, रुक जाएं और वास्तविक आउटपुट के साथ वापस आएं।

फाइल का सबसे अधिक परीक्षण योग्य हिस्सा इसके चार रिपोर्ट टोकन हैं। व्यवहार में बदलाव के लिए एक INTENT: लाइन आवश्यक है। बाहरी कार्रवाई के लिए AUTH: user said "<exact words>" की आवश्यकता होती है, जिसमें उपयोगकर्ता को उद्धृत किया जाता है, क्योंकि रेपो स्पष्ट रूप से कहता है कि दस्तावेज़ीकरण प्राधिकरण नहीं है। निर्धारित लेकिन न की गई कार्रवाई के लिए PENDING: लाइन की आवश्यकता होती है। ठीक किए गए दोष के लिए TWINS: searched <pattern> - found <N> other sites की आवश्यकता होती है। आपको यह जांचने के लिए कि क्या ये चार स्ट्रिंग्स तब दिखाई देती हैं जब वे आवश्यक हों, विधि के बारे में कुछ भी मानने की आवश्यकता नहीं है; यही बात इसे 'vibes' के बजाय मापने योग्य बनाती है।

fable-loop वही विधि है जिसे चार चरणों में एक ऑर्केस्ट्रेशन के रूप में चलाया जाता है: समानांतर साक्ष्य उप-एजेंटों (subagents) के साथ योजना बनाना, मुख्य थ्रेड पर निष्पादित करना, एक से तीन हमलावर उप-एजेंटों के साथ सत्यापित करना जो प्रत्येक अलग दृष्टिकोण अपनाते हैं, फिर ऑडिट और रिपोर्ट करना। यह साक्ष्य और हमलावर भूमिकाओं पर सस्ते मॉडल और निर्णयों और संपादनों पर एक मजबूत मॉडल का उपयोग करता है।

fable-judge वह हिस्सा है जिसे इंस्टॉल करना सार्थक है, भले ही आप बाकी सब छोड़ दें। इसका रुख यह है कि "रिपोर्ट दावों का एक समूह है, साक्ष्य नहीं।" यह एक तैयार रिपोर्ट से दावे एकत्र करता है, git diff और git status से 'ground truth' स्थापित करता है, रिपोर्ट में बताए गए प्रत्येक सत्यापन को फिर से चलाता है, और एक नामित धोखाधड़ी सूची की तलाश करता है: कमजोर चेक, झूठी पूर्णता, स्कोप क्रीप, अनधिकृत कार्रवाई, स्पेक के साथ विश्वासघात, और बचा हुआ कचरा। यह VERIFIED, VERIFIED WITH CAVEATS, या REFUTED लौटाता है, और जिसे यह पुन: उत्पन्न नहीं कर सकता उसे UNVERIFIABLE के रूप में चिह्नित करता है, न कि यह मानकर कि वह पास हो गया। इंस्टॉलर की अपनी अंतिम पंक्ति इसकी ओर इशारा करती है: "इसे आज़माएं: Claude Code खोलें और किसी भी एजेंट द्वारा काम पूरा होने का दावा करने के बाद /fable-judge टाइप करें।" यदि आप काम के बाद इसे चलाने के बजाय इसे काम में ही बनाना चाहते हैं, तो Old Coder कौशल एजेंट से एक SPEC तैयार करवाता है जिसे आप अनुमोदित करते हैं और एक EVIDENCE रिपोर्ट जिसे आप स्वयं फिर से चला सकते हैं, जिसमें म्यूटेशन टेस्टिंग कवरेज के प्रमाण के रूप में कार्य करती है कि एक टेस्ट वास्तव में रिग्रेशन को पकड़ लेगा।

fable-domain ट्रैप फिक्स्चर और स्मोक इवल्स के साथ डोमेन एडाप्टर बंडल उत्पन्न करता है। आठ एडाप्टर उपलब्ध हैं: मार्केटिंग, रिसर्च, डेटा एनालिसिस, बिजनेस और ऑप्स, फाइनेंस, लीगल और कंप्लायंस, डिजाइन और UX, और devops। मेडिकल और क्लिनिकल कार्य के लिए जानबूझकर कोई एडाप्टर नहीं दिया गया है।

कौन से भाग दूसरे मॉडल पर पोर्ट होते हैं, और कौन से नहीं

रिपॉजिटरी इसका उत्तर सीधे AGENTS.md के साथ देती है, जो यह बताता है: "किसी भी कोडिंग एजेंट या हार्नेस (Codex, Cursor, aider, एक रॉ सिस्टम प्रॉम्प्ट) के लिए पोर्टेबल संस्करण। SKILL.md के समान विधि; इस फ़ाइल को अपने एजेंट निर्देशों में पेस्ट करें या इसे अपने रिपॉजिटरी रूट में AGENTS.md के रूप में रखें।" यह लगभग 2,600 शब्दों का है और इसमें समान गेट्स, चरण और मोड शामिल हैं। यदि आप पहले से ही रिपॉजिटरी-रूट निर्देश फ़ाइलें रखते हैं, तो AGENTS.md और HUMAN.md कन्वेंशन यह बताता है कि वह फ़ाइल कहाँ जाती है और उसे कौन पढ़ता है।

दो भाग आसानी से पोर्ट हो जाते हैं। विधि का टेक्स्ट एक क्रमित प्रॉम्प्ट है जिसमें कोई मॉडल-विशिष्ट कोड नहीं है, इसलिए कोई भी मॉडल जो निर्देशों का पालन करता है, वह इसका पालन कर सकता है, और रिपॉजिटरी का मुख्य तर्क यह है कि 'लिफ्ट' (विधि का लाभ) मॉडल टियर के व्युत्क्रमानुपाती होता है। जज भी पोर्ट हो जाता है, बशर्ते एजेंट के पास शेल और रिपॉजिटरी हो, क्योंकि यह जो कुछ भी करता है वह git diff है, साथ ही उन कमांड्स को फिर से चलाना जिन्हें रीडर भी चला सकता है।

एक भाग आसानी से पोर्ट नहीं होता है। fable-loop यह मानकर चलता है कि हार्नेस समानांतर सब-एजेंट्स को स्पॉन कर सकता है और उन्हें अलग-अलग मॉडल्स पर रूट कर सकता है। बिना सब-एजेंट्स वाला एजेंट उन चरणों को एक ही मॉडल पर क्रमिक रूप से चलाता है, जिससे वह समानांतरता और लागत बचत समाप्त हो जाती है जिसने इस डिज़ाइन को उचित ठहराया था। जो बचता है वह अतिरिक्त शब्दावली के साथ fable-method है।

दो छोटी चीजें हार्नेस-विशिष्ट हैं और आसानी से छूट सकती हैं। /fable-method ट्रिगर एक Claude Code स्लैश कमांड है, इसलिए किसी अन्य हार्नेस पर आप इसका वर्णन करके विधि को इनवोक करते हैं। और SKILL.md फ्रंटमैटर विवरण वह है जो एजेंट को बॉडी को केवल तब लोड करने देता है जब वह कार्य से मेल खाती है, जिसका अर्थ है कि एक इंस्टॉल की गई स्किल तब तक लगभग कुछ भी खर्च नहीं करती जब तक वह सक्रिय न हो। इसके बजाय AGENTS.md को सिस्टम प्रॉम्प्ट में पेस्ट करें और वे 2,600 शब्द आपके द्वारा भेजे गए प्रत्येक अनुरोध में शामिल रहेंगे, चाहे कार्य एक लाइन की टाइपो फिक्स हो या रिफैक्टर। यह एक वास्तविक लागत अंतर है, और यही मुख्य कारण है कि स्किल पैकेजिंग का अस्तित्व है।

VPS पर A/B टेस्टिंग कैसे करें: एक ही कार्य, दो बार

दो समान वर्किंग कॉपी सेट करें ताकि कोई भी रन दूसरे के बदलावों को न देख सके। जिस रिपॉजिटरी के खिलाफ आप टेस्ट करना चाहते हैं, उसके लिए YOUR_ORG/YOUR_REPO को बदलें; दोनों क्लोन एक ही कमिट से होने चाहिए।

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

ऐसा कार्य चुनें जिसका परिणाम आप बिना किसी राय के देख सकें: एक फेल होने वाला टेस्ट जिसे पास होना है, या एक स्क्रिप्ट जिसे 0 पर एग्जिट होना है। एक अस्पष्ट कार्य अस्पष्ट तुलना देता है, क्योंकि आप परिणामों के बजाय गद्य (prose) को ग्रेड करने लगते हैं।

कंट्रोल आर्म को --bare के साथ चलाएं, जो हुक, स्किल्स, प्लगइन्स और CLAUDE.md की ऑटो-डिस्कवरी को छोड़ देता है। यही वह फ्लैग है जो इसे कंट्रोल बनाता है: आपके द्वारा पहले इंस्टॉल की गई स्किल्स इसमें लीक नहीं हो सकतीं। बेयर मोड आपके सब्सक्रिप्शन लॉगिन का उपयोग नहीं करता है, इसलिए पहले 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

मेथड आर्म वही कमांड है जिसमें एक फ्लैग जोड़ा गया है, जो पोर्टेबल मेथड को सिस्टम प्रॉम्प्ट एडिशन के रूप में लोड करता है:

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

वही बाइनरी, वही मॉडल, वही टूल्स, वही शुरुआती ट्री। केवल एक फ्लैग का अंतर है, जो तुलना को सार्थक बनाने का एकमात्र तरीका है।

यह डिज़ाइन मेथड टेक्स्ट को मापता है। यह स्किल पैकेजिंग को नहीं मापता, जो एक अलग प्रश्न है। पैकेजिंग को मापने के लिए, --bare को हटा दें, स्किल्स को ऊपर बताए अनुसार इंस्टॉल करें, और स्किल नाम को प्रॉम्प्ट स्ट्रिंग के अंदर रखें, क्योंकि यूजर-इनवोक्ड स्किल्स प्रिंट मोड में एक्सपैंड होती हैं: claude -p "/fable-method $task"। उम्मीद करें कि कॉस्ट प्रोफाइल सिस्टम-प्रॉम्प्ट आर्म से अलग होगी, भले ही दिखने वाला व्यवहार एक जैसा हो।

चरणों और लागत की गणना

दोनों runs ने JSON events की एक stream लिखी। अंतिम पंक्ति एक result संदेश है जिसमें अंतिम text, लागत और session metadata होता है। इसे एक बार print करें और किसी भी script को लिखने से पहले इसे पढ़ें, क्योंकि Claude Code releases के बीच field names बदलते रहते हैं।

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

प्रति run लागत उसी पंक्ति से प्राप्त होती है, और यही वह संख्या है जिसकी तुलना करनी है:

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 के लिए इसे चलाएं। अंतर का स्वरूप आपको कुल योग से अधिक जानकारी देता है। एक method run जो अधिक files पढ़ती है और कम edits करती है, वह वही कर रही है जो method के लिए आवश्यक है, और यही वह trade-off है जिसे आप खरीद रहे हैं। एक method run जिसमें समान edits हैं और लागत चालीस प्रतिशत अधिक है, उसने उस कार्य पर आपको कुछ भी अतिरिक्त नहीं दिया।

संख्याओं के बारे में दो सावधानियां बरतें। पहली, ~/.claude/projects/ के अंतर्गत session transcripts से output_tokens को जोड़कर उसे कुल योग न कहें: वे प्रति-संदेश usage blocks streaming के दौरान लिए गए snapshots हैं, और ऐसी रिपोर्टें हैं कि वे कम गणना (undercounting) करते हैं। result पंक्ति ही वह संख्या है जिस पर भरोसा किया जाना चाहिए। दूसरी, प्रति arm एक run केवल एक किस्सा है, इसलिए किसी अंतर पर विश्वास करने से पहले एक ही कार्य पर प्रत्येक arm को तीन या चार बार चलाएं, क्योंकि एक ही कार्य पर एक ही agent के दो runs पहले से ही एक-दूसरे से भिन्न होते हैं। खर्च के व्यापक दृष्टिकोण के लिए, Claude Code खर्च को ट्रैक करने वाले tools और Claude Code tokens की गणना कैसे करता है यह समझाते हैं कि cache lines raw counts पर हावी क्यों होती हैं।

सुनिश्चित करें कि जब agent unattended चल रहा हो, तो वह किसी ऐसी चीज़ तक न पहुँच सके जिसकी आपको परवाह है। Claude Code को VPS पर सुरक्षित रूप से चलाना user account और permission flags को कवर करता है।

रिपॉजिटरी का अपना मूल्यांकन, ईमानदारी से पढ़ें

README की मुख्य पंक्ति है "पंद्रह eval राउंड, 260 से अधिक एजेंट रन, ब्लाइंड LLM जज जो diffing और execution द्वारा सत्यापन करते हैं।" यह किसी भी अन्य स्किल रिपॉजिटरी द्वारा दिए गए प्रमाणों से कहीं अधिक है, और eval/RESULTS.md को राउंड-दर-राउंड लिखा गया है जिसमें विफलताओं को भी शामिल रखा गया है। मुख्य पंक्ति की संख्याओं को देखने पर यह जितना बड़ा लगता है, व्यक्तिगत सेल्स (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 पंक्तियाँ 4 रन पर आधारित हैं। अन्य तीन पंक्तियाँ प्रत्येक 2 रन पर टिकी हैं। रिपॉजिटरी स्वयं लॉग के शीर्ष पर मौजूद सीमाओं में यह बताती है: "पूरे में छोटा n (प्रति सेल 1-4 रन), LLM जज (ब्लाइंड जहाँ कई आउटपुट की तुलना की जाती है, लेकिन उसी फ्रंटियर मॉडल पर निर्मित जो बेसलाइन के रूप में दिखाई देता है), सिंथेटिक फिक्स्चर, रिसर्च ग्राउंड ट्रुथ केवल रन की तारीख तक ही मान्य।" और अधिक स्पष्ट रूप से: "यह लॉग इसलिए मौजूद है ताकि मेथड एडिट्स का परीक्षण किया जा सके, न कि इसलिए कि कोई इसे बेंचमार्क समझ ले।"

इसकी सराहना करें। एक लेखक जो अपना n प्रकाशित करता है, और उस समस्या को नाम देता है कि उनका जज उसी मॉडल पर बना है जो बेसलाइन के रूप में कार्य करता है, वह इस श्रेणी के सामान्य मानकों की तुलना में अधिक ईमानदार है। इन संख्याओं को इस प्रमाण के रूप में पढ़ें कि लेखक ने वास्तव में चीजों को रन किया और विफलताओं को रिकॉर्ड में रखा। आपका अपना A/B टेस्ट ही आपको आपके कोडबेस के बारे में सही जानकारी देता है।

README इस बारे में भी समान रूप से स्पष्ट है कि यह मेथड कहाँ काम नहीं करता है, और यह इसका सबसे उपयोगी पैराग्राफ है। यह सक्षम मॉडल्स पर साधारण छोटे कार्यों के लिए कोई सुधार दर्ज नहीं करता है। यह स्पष्ट करता है कि "यह मेथड मॉडल के तथ्यों को अधिक ताज़ा नहीं बना सकता; ज्ञान-प्रधान रिसर्च में केवल फ्रंटियर मॉडल ही जीतते हैं।" और यह इसके मूल्य को "ट्रैप्स (अधिकार संघर्ष, गलत पूर्णता के दावे, कमजोर निष्पादक, बिना निगरानी वाले रन), न कि हर जगह" पर केंद्रित करता है। यदि आपका एजेंट वर्क एक मजबूत मॉडल पर छोटे बदलाव करना है और आप उसे देख रहे हैं, तो किसी भी सुधार के न मिलने की अपेक्षा करें। यदि यह बिना निगरानी के चल रहा एक सस्ता मॉडल है, तो वहीं पर अंतर दिखाई देना चाहिए, जो Opus, Sonnet और Haiku के बीच का चुनाव को भी उसी निर्णय का हिस्सा बनाता है।

जहाँ पैकेजिंग एक दिखावा (cargo cult) है

चार आलोचनाएँ करना उचित है, और इनमें से कोई भी रिपॉजिटरी को न इस्तेमाल करने का कारण नहीं है।

इसकी रूपरेखा सबूतों से कहीं आगे निकल जाती है। "Claude Fable 5 ने कैसे काम किया" मॉडल की आंतरिक कार्यप्रणाली के बारे में एक ऐसा दावा है जिसे Anthropic के बाहर कोई भी सत्यापित नहीं कर सकता, और रिपॉजिटरी का अपना मुख्य वाक्य ही इसे कमजोर कर देता है: "गुणवत्ता संरचना, साक्ष्य और ईमानदारी में निहित है, न कि मॉडल में।" यदि गुणवत्ता संरचना में है, तो इसकी उत्पत्ति की कहानी केवल सजावट है। यह प्रक्रिया अपने आप में पूर्ण है और इसे किसी मूल मिथक की आवश्यकता नहीं है।

चार स्किल्स (skills) की आवश्यकता सामग्री की तुलना में अधिक सतही है। fable-loop, fable-method के एक बड़े हिस्से को ऑर्केस्ट्रेशन के साथ फिर से प्रस्तुत करता है, और बिना सब-एजेंट्स वाले हार्नेस पर यह वापस fable-method में बदल जाता है। दोनों को इंस्टॉल करने से पहले दोनों फाइलों को साथ रखकर पढ़ें।

आठ डोमेन एडेप्टर (domain adapters) ऐसी व्यापकता है जिसे इवैल्यूएशन (eval) कवर नहीं करता है। आठ में से केवल दो ही लॉग में दिखाई देते हैं: राउंड 9 में मार्केटिंग और राउंड 12 में devops। फाइनेंस, लीगल, डिजाइन और डेटा एडेप्टर बिना किसी राउंड के साथ आते हैं। आपके क्षेत्र के लिए एडेप्टर अभी भी अच्छा हो सकता है। हालाँकि, यह लेखक का ड्राफ्ट है, न कि ऐसी कोई चीज जो किसी कठोर परीक्षण (trap fixture) से गुजरी हो।

और v1.4.0 टैग पर मौजूद इंस्टॉलर इस बात पर रिपॉजिटरी से असहमत है कि वह क्या शिप (ship) करता है, क्योंकि यह चार में से तीन स्किल्स को ~/.claude/skills में कॉपी करता है। main पर 2026-10-03 की एक कमिट ने इसे लगभग तीन महीने बाद ठीक किया, और अभी तक किसी भी टैग्ड रिलीज में यह सुधार शामिल नहीं है। यह एक छोटी बात है। लेकिन यह उस तरह की कमी है जो बताती है कि पैकेजिंग की गति समीक्षा से अधिक थी, जिसे याद रखना महत्वपूर्ण है जब आप यह तय करें कि इसे एक बार में कितना अपनाना है।

यदि आप कुछ और न रखें तो कम से कम इन्हें रखें

ब्रांडिंग को हटा दें, तो चार नियम अपने आप में प्रभावी रहते हैं, चाहे आप कोई भी एजेंट चलाएं।

• ऑथराइजेशन कोट (authorization quote)। कोई भी अपरिवर्तनीय (irreversible) या बाहरी कार्रवाई के लिए उपयोगकर्ता के अपने शब्दों की आवश्यकता होती है, जिन्हें AUTH: लाइन के रूप में लिखा जाना चाहिए। यदि कोई एजेंट कोट नहीं ढूंढ पाता है, तो वह कोई कार्रवाई नहीं करता।
• ट्विन चेक (twin check)। किसी त्रुटि को ठीक करने के बाद, पूरे प्रोजेक्ट में उसी गलत संरचना को खोजें और उसकी संख्या बताएं, भले ही वह संख्या शून्य ही क्यों न हो।
• अवलोकन द्वारा सत्यापन (verification by observation)। यदि कोई सफल टारगेटेड चेक किसी टूटे हुए बिल्ड पर चल रहा है, तो वह सत्यापन विफल माना जाएगा, सफल नहीं।
• परिणाम-प्रथम रिपोर्टिंग (outcome-first reporting), जिसमें जो कुछ भी छोड़ दिया गया या सत्यापित नहीं किया गया, उसे चुपचाप हटाने के बजाय एक चेतावनी (caveat) के रूप में स्पष्ट किया जाए।

इन चार नियमों को अपनाने में कोई लागत नहीं आती और आप grep के माध्यम से इनका अनुपालन सुनिश्चित कर सकते हैं। यहीं से शुरुआत करें, ऊपर दिए गए हार्नेस के साथ मापें, और फिर तय करें कि क्या बाकी रिपॉजिटरी आपके कॉन्टेक्स्ट बजट के अनुरूप है। यदि आप किसी एजेंट को कार्य करने की विधि के बजाय प्रोजेक्ट का स्थायी कॉन्टेक्स्ट देना चाहते हैं, तो एक DESIGN.md जिसे एजेंट संपादन से पहले पढ़ते हैं एक पूरक कदम है।

FAQ

क्या Fable method, Claude के अलावा अन्य models के साथ काम करता है?

Method का text काम करता है। यह एक क्रमिक prompt है जिसमें कोई model-specific code नहीं है, और repo AGENTS.md को Codex, Cursor, aider या raw system prompt के लिए एक portable copy के रूप में ship करती है। दो चीजें काम नहीं करती हैं। /fable-method और /fable-judge triggers, Claude Code के slash commands हैं, इसलिए अन्य जगहों पर आप method का वर्णन करके उसे invoke करते हैं। और fable-loop एक ऐसे harness को मानता है जो अलग-अलग models पर समानांतर subagents spawn कर सके; इसके बिना, यह क्रमिक रूप से चलता है और आपको अतिरिक्त चरणों के साथ fable-method देता है।

क्या इन skills को चलाने में अधिक tokens खर्च होते हैं?

हाँ, और कितना खर्च होगा यह इस पर निर्भर करता है कि आप उन्हें कैसे load करते हैं। Skills के रूप में install होने पर, body केवल तभी load होती है जब description task से मेल खाता है, इसलिए असंबंधित अनुरोध पर लगभग कुछ भी खर्च नहीं होता। System prompt में paste करने पर, AGENTS.md के लगभग 2,600 शब्द हर अनुरोध के साथ चलते हैं। स्वयं run करने में भी अधिक खर्च आता है, क्योंकि method संपादन से पहले orientation, निर्णय लेने से पहले प्रमाण, और बाद में वास्तविक सत्यापन मांगती है। इसे मापें: दोनों arms में --output-format json के साथ एक ही task चलाएं और total_cost_usd field की तुलना करें।

मुझे fable-method का कौन सा version install करना चाहिए, और इसे pin क्यों करें?

Install करने से पहले git checkout v1.4.0 चलाएं। वह tag 2026-07-15 को दिनांकित है और अक्टूबर 2026 तक सबसे नया tag है। इससे पहले तीन tags आए थे (v1.0.0, v1.1.0 और v1.2.0, जिसमें v1.2.0 एकमात्र पिछला GitHub release था), एक v1.3.0 जिसे कभी release नहीं किया गया, उसे इसमें मिला दिया गया, और v1.4.0 ने routing rules को ही बदल दिया। main भी बदलता रहा है, अक्टूबर में एक installer बदलाव के साथ जिसे अभी तक कोई tag नहीं मिला है। मापते समय main को track करने का मतलब है कि आपका control run और test run अलग-अलग निर्देश पढ़ सकते हैं, जिससे तुलना व्यर्थ हो जाती है। अपने परिणामों के साथ tag को record करें।

क्या repo में मौजूद eval एक ऐसा benchmark है जिस पर मैं भरोसा कर सकता हूँ?

इसे method के लिए एक change log मानें, जिसे इसके लेखक ने यही कहा है: "यह log इसलिए मौजूद है ताकि method edits का परीक्षण किया जा सके, न कि इसलिए कि कोई इसे benchmark समझ ले।" file के शीर्ष पर सीमाएं बताई गई हैं: प्रति cell 1 से 4 runs, synthetic fixtures, और उसी frontier model पर बने LLM judges जो baseline के रूप में भी काम करता है। Rounds वास्तविक हैं और विफल प्रयोगों को रखा गया है, जो अधिकांश repos द्वारा प्रकाशित किए जाने से अधिक है। यह अभी भी इस बात का माप नहीं है कि आपके codebase पर क्या होगा, इसलिए स्वयं two-arm तुलना करें।