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

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

टैग को पिन करें, और जो भी परिणाम आपको मिलते हैं उनके बगल में टैग को नोट कर लें। इस रिपॉजिटरी ने 2026-07-06 और 2026-07-15 के बीच पांच रिलीज़ प्रकाशित कीं, v1.0.0 से v1.4.0 तक, और v1.4.0 ने एक नया राउटिंग गेट जोड़कर स्वयं विधि को बदल दिया। अगस्त 2026 तक, v1.4.0 सबसे नया टैग है। यदि आपका कंट्रोल रन नियमों का एक वर्ज़न पढ़ता है और आपका टेस्ट रन दूसरा वर्ज़न पढ़ता है, तो आपने किसी भी चीज़ का सटीक मापन नहीं किया है।

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

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

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

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

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

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

fable-judge वह हिस्सा है जिसे इंस्टॉल करना सार्थक है, भले ही आप बाकी सब छोड़ दें। इसका रुख यह है कि "रिपोर्ट दावों का एक समूह है, साक्ष्य नहीं।" यह एक तैयार रिपोर्ट से दावे एकत्र करता है, git diff और git status से ground truth स्थापित करता है, रिपोर्ट में वर्णित हर सत्यापन को फिर से चलाता है, और एक नामित fraud list की तलाश करता है: कमजोर किए गए चेक, झूठी पूर्णता, scope creep, अनधिकृत कार्रवाई, spec के साथ विश्वासघात, और बचा हुआ कचरा। यह VERIFIED, VERIFIED WITH CAVEATS, या REFUTED लौटाता है, और जिसे यह reproduce नहीं कर पाता उसे UNVERIFIED चिह्नित करता है, न कि यह मान लेता है कि वह सफल रहा। इंस्टॉलर की अंतिम पंक्ति इसी की ओर इशारा करती है: "इसे आजमाएं: Claude Code खोलें और किसी भी एजेंट द्वारा काम पूरा होने का दावा करने के बाद /fable-judge टाइप करें।" यदि आप बाद में जांच करने के बजाय काम में ही उस जांच को शामिल करना चाहते हैं, तो Old Coder skill एजेंट से एक SPEC तैयार करवाती है जिसे आप अनुमोदित करते हैं और एक EVIDENCE रिपोर्ट जिसे आप स्वयं फिर से चला सकते हैं, जिसमें mutation testing इस प्रमाण के रूप में कार्य करती है कि एक टेस्ट वास्तव में 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। चिकित्सा और नैदानिक कार्यों के लिए जानबूझकर कोई adapter नहीं दिया गया है।

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

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

दो भाग आसानी से पोर्ट हो जाते हैं। विधि का टेक्स्ट एक क्रमित प्रॉम्प्ट है जिसमें कोई मॉडल-विशिष्ट कोड नहीं है, इसलिए जो भी मॉडल निर्देशों का पालन करता है वह इसका पालन कर सकता है, और रिपॉजिटरी का मुख्य तर्क यह है कि प्रयास मॉडल टियर के व्युत्क्रमानुपाती होता है। जज भी पोर्ट हो जाता है, बशर्ते एजेंट के पास शेल और रिपॉजिटरी हो, क्योंकि यह जो कुछ भी करता है वह 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 हैं और लागत चालीस प्रतिशत अधिक है, उसने उस कार्य पर आपको कुछ भी अतिरिक्त नहीं दिया।

संख्याओं के बारे में दो सावधानियां बरतें। पहली, ~/.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' है

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

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

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

Eight domain adapters ऐसी व्यापकता है जिसे eval कवर नहीं करता। आठ में से केवल दो log में दिखाई देते हैं: round 9 में marketing और round 12 में devops। finance, legal, design और data adapters बिना किसी round के साथ आते हैं। आपके क्षेत्र के लिए adapter शायद अच्छा हो। हालाँकि, यह लेखक का ड्राफ्ट है, न कि ऐसी चीज जो किसी trap fixture से गुजरी हो।

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

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

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

• ऑथराइजेशन कोट (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 एक portable copy के रूप में उपलब्ध है जिसे Codex, Cursor, aider या raw system prompt के लिए इस्तेमाल किया जा सकता है। दो चीजें इसमें शामिल नहीं हैं। /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, निर्णय लेने से पहले प्रमाण, और बाद में वास्तविक सत्यापन मांगता है। इसे मापें: दोनों स्थितियों में --output-format json के साथ एक ही कार्य चलाएं और total_cost_usd field की तुलना करें।

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

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

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

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