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 के भीतर, प्लगइन वाला तरीका दो commands का उपयोग करता है:

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

एक VPS पर, जहाँ आप डिस्क पर एक पिन की गई कॉपी चाहते हैं, पहले क्लोन करें और एक 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 चार skills प्रदान करता है और shell installer तीन को कॉपी करता है, इसलिए एक standalone उपयोगकर्ता को fable-domain तब तक नहीं मिलता जब तक वे इसे मैन्युअल रूप से कॉपी न करें:

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

tag को पिन करें, और जो भी परिणाम आपको मिलते हैं उनके बगल में tag को लिख लें। इस repo ने 2026-07-06 और 2026-07-15 के बीच पांच releases प्रकाशित किए, v1.0.0 से v1.4.0 तक, और v1.4.0 ने एक नया routing gate जोड़कर स्वयं विधि को बदल दिया। अगस्त 2026 तक, v1.4.0 सबसे नया tag है। यदि आपका control run नियमों का एक वर्ज़न पढ़ता है और आपका test run दूसरा, तो आपने कुछ भी मापा नहीं है।

चारों स्किल्स मॉडल को क्या करने के लिए कहती हैं

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

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

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

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

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

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

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

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

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

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

एक भाग आसानी से पोर्ट नहीं होता है। fable-loop यह मानकर चलता है कि हार्नेस समानांतर सब-एजेंट्स (subagents) को उत्पन्न कर सकता है और उन्हें अलग-अलग मॉडलों पर रूट कर सकता है। सब-एजेंट्स के बिना एक एजेंट उन चरणों को एक ही मॉडल पर क्रमिक रूप से चलाता है, जिससे वह समानांतरता और लागत बचत समाप्त हो जाती है जिसने इस डिज़ाइन को उचित ठहराया था। जो बचता है वह अतिरिक्त शब्दावली के साथ 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 हों और लागत 40 प्रतिशत अधिक हो, उसने उस कार्य पर आपको कुछ भी अतिरिक्त नहीं दिया।

संख्याओं के बारे में दो सावधानियां। पहली, ~/.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 चल रहा हो, तो वह किसी ऐसी चीज़ तक न पहुँच सके जिसकी आप परवाह करते हैं। VPS पर सुरक्षित रूप से Claude Code चलाना 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 के बीच चयन को भी उसी निर्णय का हिस्सा बनाता है।

जहाँ पैकेजिंग एक 'कार्गो कल्ट' है

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

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

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

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

और इंस्टॉलर इस बात पर रिपॉजिटरी से असहमत है कि वह क्या शिप करता है, क्योंकि यह चार में से तीन स्किल्स को ~/.claude/skills में कॉपी करता है। यह एक छोटी बात है। यह उस तरह की कमी भी है जो बताती है कि पैकेजिंग की गति समीक्षा से अधिक तेज़ थी, जिसे याद रखना महत्वपूर्ण है जब आप यह तय करें कि इसे एक बार में कितना अपनाना है।

यदि आप कुछ और न रखें तो भी इन्हें अवश्य रखें

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

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

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

FAQ

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

Method का text काम करता है। यह एक क्रमित prompt है जिसमें कोई model-specific code नहीं है, और repo में Codex, Cursor, aider या raw system prompt के लिए portable copy के रूप में AGENTS.md उपलब्ध है। दो चीजें काम नहीं करती हैं। /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 कार्य से मेल खाता है, इसलिए असंबंधित अनुरोध पर लगभग कुछ भी खर्च नहीं होता। System prompt में paste किए जाने पर, AGENTS.md के लगभग 2,600 शब्द हर अनुरोध के साथ चलते हैं। स्वयं run की लागत भी अधिक होती है, क्योंकि method संपादन से पहले orientation, निर्णय लेने से पहले प्रमाण, और बाद में वास्तविक सत्यापन मांगता है। इसे मापें: दोनों arms में --output-format json के साथ एक ही कार्य चलाएं और total_cost_usd field की तुलना करें।

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

Install करने से पहले git checkout v1.4.0 चलाएं। वह tag 2026-07-15 को dated है और अगस्त 2026 तक सबसे नया था। Repo ने उससे पहले के नौ दिनों में पांच releases प्रकाशित किए थे, और v1.4.0 ने routing rules को ही बदल दिया था। मापते समय main को track करने का मतलब है कि आपका control run और test run अलग-अलग निर्देश पढ़ सकते हैं, जिससे तुलना व्यर्थ हो जाती है। अपने परिणामों के साथ tag को record करें।

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

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