Fable method का उपयोग करके AI एजेंट स्किल्स कैसे बनाएं
Sahir619/fable-method रिपॉजिटरी का उपयोग करके Claude Fable 5 की कार्यप्रणाली को अन्य मॉडल्स में कैसे पोर्ट करें। VPS पर A/B टेस्टिंग के जरिए टूल कॉल्स और लागत का सटीक मूल्यांकन करें।
Fable method वास्तव में क्या दावा करता है
Fable method एजेंट स्किल्स का एक छोटा सेट है जो किसी एक मॉडल की कार्य करने की आदतों को एक क्रमिक प्रक्रिया (ordered procedure) के रूप में लिखता है, ताकि कोई अन्य मॉडल उसी प्रक्रिया को चला सके। यह रिपॉजिटरी Sahir619/fable-method पर उपलब्ध है, जो MIT लाइसेंस के अंतर्गत है, और इसका अपना एक-पंक्ति विवरण है: "Claude Fable 5 कैसे काम करता था, इसे उन स्किल्स में संकलित किया गया है जिन्हें कोई भी मॉडल चला सकता है, साथ ही वह मूल्यांकन (eval) जो इसे सटीक बनाए रखता है।" इस वाक्य का दूसरा भाग परीक्षण करने योग्य दावा है।
क्या कोई टेक्स्ट फ़ाइल वास्तव में यह दर्शाती है कि कोई विशिष्ट मॉडल कैसे सोचता था, यह 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/skillsinstall.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/fable-method/SKILL.md है। इसमें दो गेट और सात क्रमांकित चरण हैं, और इसके नियम इतने विशिष्ट हैं कि उन पर तर्क किया जा सकता है।
सबसे पहले ट्रिवियलिटी गेट आता है: जब बदलाव केवल एक फाइल तक सीमित हो, लगभग 10 लाइनों के भीतर हो, कोई नया व्यवहार न जोड़े, और आप जानते हों कि वास्तव में क्या बदलना है, तो बिना किसी औपचारिकता के सीधे कार्य करें। इसके बाद फिट गेट आता है जो अनुरोध को इस आधार पर निर्देशित करता है कि उत्तर कहाँ स्थित है: ऐसे स्रोत जिन्हें आप खोल सकते हैं, कोई ऐसी तकनीक जिस पर पहले शोध करना आवश्यक है, या आपका अपना अनुमान, जिसे तथ्य के रूप में प्रस्तुत करने के बजाय कम विश्वास (low confidence) के रूप में चिह्नित किया जाना चाहिए।
फिर लूप आता है: अनुरोध को वर्गीकृत करें, पूर्णता (done) को परिभाषित करें, साक्ष्य जुटाएं, निर्णय लें, कार्य करें, सत्यापित करें और रिपोर्ट करें। चरण 2 कहता है कि फाइलें चुनने से पहले डायरेक्टरी को सूचीबद्ध करके स्थिति को समझें, याददाश्त के बजाय प्राथमिक स्रोतों को प्राथमिकता दें, और लगातार दो बार ऐसी खोज के बाद रुक जाएं जो कोई नया परिणाम न दे। चरण 4 कहता है कि किसी भी संपादन से पहले एक INTENT: लाइन लिखें, जिसमें यह बताएं कि कोड क्या करता है, विफल चेक क्या अपेक्षा करता है, और स्पेक (spec) क्या कहता है। यदि ये तीनों आपस में मेल नहीं खाते हैं, तो संपादन बिल्कुल न करें, क्योंकि यही विसंगति वास्तविक निष्कर्ष है। चरण 5 पुनः प्रयासों (retries) की सीमा तय करता है: एक ही समस्या पर तीन विफल फिक्स-और-सत्यापन चक्रों के बाद, रुक जाएं और वास्तविक आउटपुट के साथ वापस सौंप दें।
फाइल का सबसे अधिक परीक्षण योग्य हिस्सा इसके चार रिपोर्ट टोकन हैं। व्यवहार में बदलाव के लिए एक INTENT: लाइन आवश्यक है। बाहरी कार्रवाई के लिए AUTH: user said "<exact words>" की आवश्यकता होती है, जिसमें उपयोगकर्ता को उद्धृत किया जाता है, क्योंकि रेपो स्पष्ट रूप से कहता है कि दस्तावेज़ीकरण प्राधिकरण नहीं है। निर्धारित लेकिन न की गई कार्रवाई के लिए 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 स्ट्रीमिंग के दौरान लिए गए 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) को देखने पर यह मुख्य पंक्ति की संख्या की तुलना में कम विस्तृत है।
The data behind this chart
[
{
"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 को छोड़ दें।
इसकी रूपरेखा सबूतों से आगे निकल जाती है। "Claude Fable 5 ने कैसे काम किया" मॉडल की आंतरिक कार्यप्रणाली के बारे में एक ऐसा दावा है जिसे 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 शायद अच्छा हो। हालाँकि, यह लेखक का draft है, न कि ऐसी चीज़ जो किसी trap fixture से गुज़री हो।
और installer इस बात पर repo से असहमत है कि वह क्या ship करता है, क्योंकि यह चार में से तीन skills को ~/.claude/skills में copy कर देता है। यह एक छोटी बात है। लेकिन यह उस तरह की कमी है जो बताती है कि पैकेजिंग की गति समीक्षा से अधिक तेज़ थी, जिसे याद रखना महत्वपूर्ण है जब आप यह तय करें कि इसमें से कितना एक साथ अपनाना है।
यदि आप कुछ और न रखें तो भी इन्हें जरूर रखें
ब्रांडिंग को हटा दें, तो भी चार नियम अपने आप में प्रभावी रहते हैं, चाहे आप कोई भी एजेंट चलाएं।
- ऑथराइजेशन कोट (authorization quote)। किसी भी अपरिवर्तनीय (irreversible) या बाहरी कार्रवाई के लिए उपयोगकर्ता के अपने शब्दों की आवश्यकता होती है, जिन्हें
AUTH:लाइन के रूप में लिखा जाना चाहिए। यदि कोई एजेंट कोट नहीं ढूंढ पाता है, तो वह कोई कार्रवाई नहीं करता है। - ट्विन चेक (twin check)। किसी खराबी को ठीक करने के बाद, पूरे प्रोजेक्ट में उसी गलत संरचना को खोजें और उसकी संख्या की रिपोर्ट करें, जिसमें शून्य संख्या भी शामिल है।
- अवलोकन द्वारा सत्यापन (verification by observation)। यदि कोई सफल (green) लक्षित चेक किसी टूटे हुए बिल्ड पर चल रहा है, तो यह एक विफल सत्यापन है, न कि पास।
- परिणाम-प्रथम रिपोर्टिंग (outcome-first reporting), जिसमें जो कुछ भी छोड़ दिया गया या सत्यापित नहीं किया गया, उसे चुपचाप हटाने के बजाय एक चेतावनी (caveat) के रूप में स्पष्ट किया जाए।
इन चार नियमों को अपनाने में कोई लागत नहीं आती है और आप अनुपालन (compliance) के लिए grep का उपयोग कर सकते हैं। यहीं से शुरुआत करें, ऊपर दिए गए हार्नेस (harness) के साथ मापें, और फिर तय करें कि क्या बाकी रिपॉजिटरी आपके कॉन्टेक्स्ट बजट का सही उपयोग कर रही है। यदि आप किसी एजेंट को कार्य करने की विधि के बजाय प्रोजेक्ट का स्थायी कॉन्टेक्स्ट देना चाहते हैं, तो एक DESIGN.md जिसे एजेंट संपादन से पहले पढ़ते हैं एक पूरक कदम है।
FAQ
क्या Fable method, Claude के अलावा अन्य models के साथ काम करता है?
Method का text काम करता है। यह एक क्रमिक prompt है जिसमें कोई model-specific code नहीं है, और repo में AGENTS.md को Codex, Cursor, aider या raw system prompt के लिए एक portable copy के रूप में दिया गया है। दो चीजें इसमें शामिल नहीं हैं। /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 edits का परीक्षण हो सके, न कि इसलिए कि कोई इसे benchmark समझ ले।" फाइल के शीर्ष पर सीमाएं बताई गई हैं: प्रति cell 1 से 4 runs, synthetic fixtures, और उसी frontier model पर आधारित LLM judges जो baseline के रूप में भी काम करता है। Rounds वास्तविक हैं और विफल प्रयोगों को रखा गया है, जो अधिकांश repos द्वारा प्रकाशित किए जाने से कहीं अधिक है। यह अभी भी इस बात का माप नहीं है कि आपके codebase पर क्या होगा, इसलिए दो-तरफा तुलना स्वयं करें।