Ponytail AI कोडिंग एजेंट का उपयोग कैसे करें

Ponytail क्या है

Ponytail नियमों का एक ऐसा सेट है जो AI कोडिंग एजेंट को कम कोड लिखने के लिए प्रेरित करता है। यह प्रोजेक्ट खुद को एक पंक्ति में इस प्रकार वर्णित करता है: "यह आपके AI एजेंट को कमरे में मौजूद सबसे आलसी सीनियर डेवलपर की तरह सोचने पर मजबूर करता है। सबसे अच्छा कोड वह है जिसे आपने कभी लिखा ही नहीं।" यह MIT लाइसेंस के अंतर्गत आता है। इसका अपना कोई रनटाइम नहीं है और इसमें कुछ भी निष्पादित (execute) नहीं होता है। यह केवल टेक्स्ट है जिसे एजेंट के निर्देशों में शामिल किया जाता है। इसे उन होस्ट्स के लिए एक स्किल के रूप में पैक किया गया है जो स्किल्स लोड करते हैं, और उन होस्ट्स के लिए साधारण नियम फाइलों के रूप में जो ऐसा नहीं करते हैं।

रिपॉजिटरी DietrichGebert/ponytail है। इसे 12 June 2026 को बनाया गया था और 1 August 2026 तक इसे 90,000 से अधिक स्टार्स मिल चुके थे। 1 August 2026 को नवीनतम टैग किया गया release v4.8.4 था, जिसे 29 June 2026 को प्रकाशित किया गया था, और केवल 14 से 29 June के बीच releases पेज पर दस टैग्स सूचीबद्ध थे। इसकी गति कम नहीं हुई है: 17 October 2026 को नवीनतम release v5.3.2 है, जिसे 16 October की देर रात प्रकाशित किया गया था। यह उस दिन का तीसरा release था, जो v5.3.0 और v5.3.1 के बाद आया। इससे पहले 13 October को v5.2.0 आया था, जो 8 October को आए v5.0.0 और v5.1.0 के पांच दिन बाद आया था, और रिपॉजिटरी में 165,000 से अधिक स्टार्स दिखाई देते हैं। इतनी तेजी से आगे बढ़ने वाला प्रोजेक्ट आपके इसे पढ़ने तक बदल चुका होगा, इसलिए इस पर कुछ भी बनाने से पहले एक टैग को पिन (pin) कर लें।

टूल से पहले का विचार: उस पहले पायदान पर रुकें जो टिकता है

Ponytail का मूल एक निर्णय सीढ़ी (decision ladder) है। एजेंट कुछ भी लिखने से पहले इस पर चढ़ता है और उस पहले पायदान पर रुक जाता है जो टिकता है।

1. क्या इसका अस्तित्व में होना जरूरी है? यह YAGNI (you are not going to need it) है। यदि उत्तर नहीं है, तो इसे छोड़ दें।
2. क्या यह इस codebase में पहले से मौजूद है? पहले से मौजूद helper या pattern का पुन: उपयोग करें।
3. क्या standard library इसे करती है? उसका उपयोग करें।
4. क्या कोई native platform feature इसे कवर करता है? उसका उपयोग करें।
5. क्या कोई पहले से स्थापित dependency इसे हल करती है? उसका उपयोग करें।
6. क्या यह एक लाइन का हो सकता है? इसे एक लाइन का बनाएं।
7. केवल तभी, वह न्यूनतम कोड लिखें जो काम करता है।

यह वह सीढ़ी है जैसा कि v4.8.4 पर लिखा गया है, और इस लेख के बाकी हिस्सों में पायदान संख्या इसका पालन करती है। वर्तमान main branch पायदान 3 और 4 को एक में मिला देती है, "Standard library या platform feature? इसका उपयोग करें, जब तक कि प्रोजेक्ट का अपना न हो", और यह जोड़ती है कि "एक house component, native widget से बेहतर है", इसलिए इसमें छह पायदान हैं। क्रम वही है।

क्रम काम करता है, कोई एक पायदान नहीं। date picker के लिए कहे गए एजेंट को एक date picker लिखने के लिए कहा जाएगा, क्योंकि उसे वही करने के लिए कहा गया था। सीढ़ी उसे कुछ भी बनाने से पहले यह जांचने के लिए मजबूर करती है कि पहले से क्या मौजूद है: पायदान 2 पूछता है कि क्या repository में इसके लिए पहले से कोई component है, और पायदान 4 कहता है कि browser में पहले से ही <input type="date"> है। प्रोजेक्ट का वर्तमान benchmark ठीक इसी मामले को नोट करता है: एक date picker जो नियम के बिना 335 लाइनों का था, Ponytail 5 के साथ 10 लाइनों का हो गया, क्योंकि एजेंट ने repository के अपने Input component का type="date" के साथ पुन: उपयोग किया और browser को calendar प्रदान करने दिया। एक colour picker कम घटा, 135 लाइनों से 26 तक। पायदान 2 वह है जो चुपचाप विफल हो जाता है, क्योंकि एक एजेंट जो आपके पास पहले से मौजूद helper को नहीं देख सकता है, वह खुशी-खुशी दूसरा लिख देगा, जो कि वह अंतर है जिसे आपके codebase का एक queryable map भरने के लिए बनाया गया है।

यहाँ आलसी (lazy) होने का मतलब लापरवाह होना नहीं है, और ruleset सीधे तौर पर ऐसा कहता है। इसकी "never lazy about" सूची में निर्णय लेने से पहले समस्या को समझना, trust boundaries पर input validation, data loss को रोकने वाली error handling, security, accessibility, और आपके द्वारा नाम से मांगी गई कोई भी चीज़ शामिल है। यह गैर-तुच्छ logic के प्रत्येक हिस्से के लिए एक छोटा runnable check भी मांगता है। यह नियम आविष्कार (invention) को काटता है। यह शुद्धता (correctness) को नहीं काटता है।

रिपॉजिटरी वास्तव में क्या प्रदान करती है

• AGENTS.md, हमेशा सक्रिय रहने वाला रूल्सेट, जो पूरी अवधारणा को एक ऐसी फाइल में समेटता है जिसे आप पांच मिनट में पढ़ सकते हैं।
• skills/ponytail/SKILL.md, स्किल डेफिनिशन, जिसमें lite, full, ultra या off का आर्गुमेंट हिंट दिया गया है।
• एडिटर-विशिष्ट डायरेक्टरी जैसे .cursor/rules/ और .windsurf/rules/ के अंतर्गत रूल फाइलें, उन होस्ट्स के लिए जो रूल्स पढ़ते हैं लेकिन स्किल्स लोड नहीं करते।
• hooks/, benchmarks/, examples/ और scripts/।

इंटेंसिटी आर्गुमेंट यह बदलता है कि रूल कितना सख्ती से लागू होता है। lite आपके द्वारा मांगी गई चीजों को बनाता है और एक लाइन में एक अधिक शिथिल विकल्प का नाम देता है। full डिफ़ॉल्ट है और लैडर को लागू करता है। ultra YAGNI चरमपंथी सेटिंग है: यह जोड़ने के बजाय हटाने को प्राथमिकता देता है और यह आवश्यकता पर ही सवाल उठा सकता है।

स्किल-सक्षम होस्ट्स को स्लैश कमांड्स भी मिलते हैं। /ponytail लेवल सेट करता है, /ponytail-review ओवर-इंजीनियरिंग के लिए डिफ (diff) की जाँच करता है, /ponytail-audit पूरी रिपॉजिटरी की जाँच करता है, /ponytail-debt उन शॉर्टकट्स को इकट्ठा करता है जिन्हें आपने टाल दिया था, और /ponytail-gain बेंचमार्क स्कोरकार्ड प्रिंट करता है। जो होस्ट्स केवल रूल फाइलें पढ़ते हैं, उन्हें बिना कमांड्स के रूल्सेट मिलता है। 16 अक्टूबर 2026 को रिलीज हुए v5.3.0 के बाद से, Claude Code को प्रॉम्प्ट के ऊपर एक बैंड भी मिलता है जो टास्क की लागत, कोड का पुन: उपयोग और टेस्ट स्टेटस दिखाता है। इसके लिए Claude Code 2.1.290 या बाद का वर्जन चाहिए; यह VS Code चैट पैनल, क्लाउड सेशन या claude -p में दिखाई नहीं देता है, और /ponytail band off इसे छिपा देता है। v5.3.2 के बाद से, /ponytail band import आपके पिछले Claude Code सेशन को एक बार पढ़ता है और उन्हें उनकी लागत, एजेंट समय और टोकन के साथ बोर्ड पर जोड़ देता है, ताकि आप उनकी तुलना रूल के तहत चलाए गए सेशन से कर सकें।

स्रोत पर भरोसा करने से पहले उसे पढ़ने के लिए, ब्रांच के बजाय टैग को क्लोन करें। यह वही टैग है जहाँ से ऊपर दिया गया लैडर आता है; वर्तमान शब्दावली पढ़ने के लिए 17 अक्टूबर 2026 के नवीनतम टैग v5.3.2 का उपयोग करें:

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

Claude Code पर, प्रोजेक्ट इसके बजाय प्लगइन इंस्टॉलेशन का दस्तावेजीकरण करता है, और ये दो लाइनें 17 अक्टूबर 2026 को प्रलेखित की गई हैं:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

प्लगइन पाथ टैग के बजाय डिफ़ॉल्ट ब्रांच का अनुसरण करता है, इसलिए आपके एजेंट को निर्देशित करने वाले निर्देश सेशन के बीच में बदल सकते हैं। अपडेट कमांड की सुविधा के बदले में आपको यही समझौता स्वीकार करना पड़ता है।

VPS पर एक lazy agent सस्ता क्यों होता है

Agent द्वारा लिखा गया diff conversation से बाहर नहीं जाता। अगली turn पर यह वह context होता है जिसे model फिर से पढ़ती है, साथ ही वे सभी files भी जिन्हें उसने इसे बनाने के लिए open किया था। इसलिए, 500 lines का बदलाव session की हर बाद वाली turn पर बोझ डालता है, जब तक कि compaction पुरानी turns को summary से न बदल दे, न कि केवल उस turn को जिसने इसे बनाया था। यही कारण है कि एक runaway refactor session के आगे बढ़ने पर agent को धीमा और कम बुद्धिमान बना देता है: window agent के अपने output से भर जाती है, जिससे आपके वास्तविक code के लिए जगह कम हो जाती है। इसे नियंत्रण में रखना ही coding agent की context window को manage करने का पूरा विषय है।

Tokens का billing आने और जाने दोनों पर होता है, इसलिए जो diff आकार में आधा है वह दो बार सस्ता पड़ता है: एक बार जब वह लिखा जाता है और दूसरी बार हर उस turn पर जो उसे फिर से पढ़ती है। क्या वह बचत आपके bill में दिखेगी, यह इस पर निर्भर करता है कि आप भुगतान कैसे करते हैं, क्योंकि Pro या Max subscription अतिरिक्त tokens को केवल अपनी usage limits तक ही cover करता है, जिसके बाद opt-in usage credits अलग से charge किए जाते हैं, जबकि per-token API billing आपसे हर एक token के लिए शुल्क लेती है। यदि आप self-hosted setup पर bill पर नजर रख रहे हैं, तो instruction file एक ऐसा lever है जिसे इस्तेमाल करने में कोई खर्च नहीं आता। AI agent पर होने वाले खर्च को नियंत्रित करना output volume से शुरू होता है, और coding agent अपने tokens कैसे खर्च करता है यह बताता है कि re-reading लोगों की उम्मीद से कहीं अधिक मायने क्यों रखती है।

एक इंसान अभी भी diff को पढ़ता है। 400 lines का बदलाव जो 20 lines का होना चाहिए था, वह reviewer का ध्यान खींचता है, और ध्यान ही वह संसाधन है जो सबसे पहले खत्म होता है। दिन का चौथा लंबा diff कोई भी उतनी सावधानी से review नहीं करता जितनी सावधानी से उसने पहला किया था, इसलिए over-building केवल समय की बर्बादी नहीं है। यह चुपचाप उस review की गुणवत्ता को कम कर देता है जिसे गलतियों को पकड़ने के लिए किया जाना चाहिए।

Server पर जोखिम बदल जाते हैं, क्योंकि agent अक्सर बिना किसी की निगरानी के चलता है। tmux session में या timer पर काम करने वाले agent के पास आपके देखने से पहले गलत निर्णय पर निर्माण करने के लिए घंटों का समय होता है। VPS पर coding agent चलाने में यही व्यावहारिक जोखिम है, और यही कारण है कि loop engineering करने वाले लोग individual prompts के बजाय standing instructions पर इतना ध्यान देते हैं। Always-on file का एक नियम turn 200 पर लागू होता है। Chat में आपके द्वारा टाइप किया गया नियम turn 3 पर लागू होता है। यह उसी box पर शुरू किए गए दूसरे session पर भी लागू होता है, जो committed file को तो पढ़ता है लेकिन आपके द्वारा पहले session में टाइप की गई किसी भी चीज़ को inherit नहीं करता, तब भी जब दोनों sessions एक-दूसरे को message भेज सकते हैं।

नई dependencies दूसरी गुप्त लागत हैं। Rung 5 कहता है कि जो installed है उसी का उपयोग करें। Agent अपनी पहल पर जो भी package जोड़ता है, वह कुछ ऐसा है जिसे आप बाद में patch करते हैं और जो उस repository से आपके द्वारा बनाए गए हर container image में शामिल हो जाता है।

Ponytail के अपने बेंचमार्क आंकड़े क्या कहते हैं

प्रोजेक्ट ने दो प्रकार के परिणाम प्रकाशित किए हैं, और वे एक-दूसरे से काफी भिन्न हैं। ये दोनों आंकड़े स्वयं प्रोजेक्ट द्वारा प्रकाशित किए गए हैं। इनमें से कोई भी स्वतंत्र परीक्षण नहीं है।

[
  {
    "label": "Lines of code",
    "v4_13_pct": 48,
    "v5_pct": 53
  },
  {
    "label": "Cost per run",
    "v4_13_pct": 16,
    "v5_pct": 26
  },
  {
    "label": "Wall clock time",
    "v4_13_pct": 38,
    "v5_pct": 41
  }
]

यह चार्ट प्रोजेक्ट का वर्तमान एजेंटिक बेंचमार्क है, जो 7 अक्टूबर 2026 का है। Opus 5.5 पर डिफ़ॉल्ट प्रयास के साथ Headless Claude Code 2.1.288 सत्रों ने 39 कार्यों को पूरा किया, जिसमें प्रति कार्य और आर्म पांच रन शामिल थे। कुल मिलाकर no skill, Ponytail v4.13.0 और Ponytail 5 के बीच 585 सत्र हुए। इनमें से बारह कार्य tiangolo के full-stack-fastapi-template में फीचर टिकट हैं, जो एक वास्तविक FastAPI और React रिपॉजिटरी है, जिसे छोड़े गए git diff के आधार पर स्कोर किया गया है। बाकी 18 सर्जिकल कार्य छिपे हुए चेक के साथ, छह छोटे ऐप अनुरोध और तीन "मुझे एक उदाहरण दिखाएं" अनुरोध हैं। हर आर्म के लिए Bash को डिसेबल रखा गया था। Ponytail 5 के साथ आउटपुट टोकन में 45 प्रतिशत की कमी आई।

इसकी तुलना जून 2026 में प्रोजेक्ट द्वारा प्रकाशित सिंगल-शॉट आंकड़ों से करें। वे आंकड़े एक बेयर मॉडल से आए थे जो नियम के साथ और बिना पांच सामान्य प्रॉम्प्ट्स का उत्तर दे रहा था, जिन्हें बार-बार रन करने के बाद मीडियन के रूप में रिपोर्ट किया गया था। उन्होंने Haiku, Sonnet और Opus में 80 से 94 प्रतिशत कम कोड दिखाया, और 17 जून 2026 की लागत सत्यापन रिपोर्ट ने Haiku को 63 प्रतिशत सस्ता बताया। Ponytail 5 के लिए वर्तमान एजेंटिक परिणाम 53 प्रतिशत कम कोड लाइनें, 26 प्रतिशत कम लागत और 41 प्रतिशत कम वॉल क्लॉक टाइम है। प्रोजेक्ट ने सिंगल-शॉट आंकड़े को जल्दी ही सुधार लिया था। v4.8.4 तक, 29 जून 2026 को, README में पहले ही एजेंटिक परिणाम को मुख्य रूप से दिखाया गया था, "~54% कम कोड (94% तक)", इस नोट के साथ कि पहले के 80 से 94 प्रतिशत आंकड़े "प्रति-कार्य अधिकतम सीमा थे, औसत नहीं", और इसने सिंगल-शॉट नंबरों को "पुराने सिंगल-शॉट नंबर" शीर्षक वाले एक कोलैप्स सेक्शन में डाल दिया था। वह सेक्शन इस बारे में स्पष्ट था कि यह अंतर क्यों मौजूद है: सिंगल-शॉट बेसलाइन एक ऐसा बेयर मॉडल है जो "अपने उत्तर को गद्य और विकल्पों के साथ भर देता है", जिसे हराना आसान है। वास्तविक काम करने वाले एक वास्तविक एजेंट के खिलाफ मापें तो जीत का अंतर कम हो जाता है। यह वास्तविक भी रहता है, जो कि अधिक उपयोगी तथ्य है। वह जून वाला एजेंटिक रन, Haiku 4.5 पर बारह टिकट और प्रत्येक के चार रन, 54 प्रतिशत कम लाइनों के साथ आज के आंकड़े के करीब था, और वर्तमान README में अब सिंगल-शॉट नंबर बिल्कुल भी नहीं हैं।

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

वह पैटर्न जिसे आप बिना कुछ इंस्टॉल किए आज ही कॉपी कर सकते हैं

यह लैडर केवल टेक्स्ट है, इसलिए इस विचार का उपयोग करने के लिए आपको किसी प्लगइन की आवश्यकता नहीं है। इस तरह के एक ब्लॉक को उस इंस्ट्रक्शन फाइल में पेस्ट करें जिसे आपका एजेंट पहले से ही पढ़ता है, चाहे वह AGENTS.md हो, CLAUDE.md हो या आपके एडिटर की रूल्स फाइल हो।

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

वह अंतिम नियम अपने आप में महत्वपूर्ण है। Ponytail के वर्तमान releases में इसका कन्वेंशन एक कमेंट है जिसे shortcut: टैग किया गया है, जो सीमा और अपग्रेड करने के समय का नाम बताता है (जून के releases, जिसमें v4.8.4 शामिल है, ने इसे ponytail: के रूप में टैग किया है):

# shortcut: global lock, per-account locks if throughput matters

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

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

जहाँ नियम सही नहीं रह जाता

यह ladder ऐसे codebase में feature work के लिए तैयार की गई है जो पहले से मौजूद है, जहाँ reuse आमतौर पर संभव और सही होता है। यह greenfield project के लिए कम उपयुक्त है, क्योंकि rung 2 में reuse करने के लिए कुछ नहीं होता और rung 5 में कुछ भी installed नहीं होता। agent अभी भी rung 1, standard library, platform feature या one-liner पर रुक सकता है, लेकिन दो सबसे सस्ते विकल्प उपलब्ध नहीं होते, इसलिए अधिक tasks नया code लिखने की ओर चले जाते हैं। यह उस समय भी ठीक से काम नहीं करती जब आप वास्तव में abstraction चाहते हैं। यदि आप एक ही copy किए गए block को चौथी बार call करने वाले हैं, तो "shortest diff" आपको पाँचवीं copy दे देगा।

ultra स्तर आपकी आवश्यकताओं को चुनौती देगा। यह स्तर इसी काम के लिए है, और जब आप निर्णय ले चुके हों और काम पूरा करना चाहते हों, तो यह एक वास्तविक लागत है। सामान्य काम के लिए full का उपयोग करें और जब आपको संदेह हो कि समस्या feature request में है, तो ultra का सहारा लें।

कोई भी instruction block आपको समस्या की गलत समझ से नहीं बचा सकता। ruleset का पहला बिंदु ही निर्णय लेने से पहले code को समझना है, जो कि सबसे महंगा हिस्सा है और जिसे text आपके लिए नहीं कर सकता। गलत function में minimal diff भी एक गलत सुधार ही है, और अब यह एक छोटा गलत सुधार है जिसे approve करना आसान है।

ईमानदारी से कहें तो Ponytail एक सावधानीपूर्वक लिखा गया prompt है, जिसे अच्छी तरह से distribute किया गया है और जिसमें numbers जोड़े गए हैं। इसमें ऐसी कोई भी चीज़ नहीं है जिसके लिए plugin की आवश्यकता हो। यह project आपको यह देता है कि किसी ने सूची को सही ढंग से लिखा है, उसे एक वास्तविक repository पर test किया है, और परिणाम के साथ-साथ विधि को भी प्रकाशित किया है।

FAQ

क्या Ponytail, Claude Code के अलावा अन्य agents के साथ काम करता है?

हाँ। यह उन hosts के लिए एक skill के रूप में आता है जो skills load करते हैं, जिसमें Claude Code, Codex, OpenCode, Gemini और README में उल्लिखित कई अन्य शामिल हैं। जो editors rule files को पढ़ते हैं लेकिन skills load नहीं करते, जैसे कि Cursor, Windsurf, Cline और Copilot, वे matching rules directory से always-on ruleset लेते हैं और उन्हें slash commands नहीं मिलतीं। दोनों ही स्थितियों में text समान रहता है, इसलिए मुख्य अंतर यह है कि आपका host उस text को हर turn पर context में रखता है या केवल तब जब कोई skill trigger होती है।

क्या कोई lazy agent tests, validation या security को छोड़ देगा?

नहीं, और ruleset में यह स्पष्ट रूप से लिखा है। इसकी "never lazy about" सूची में trust boundaries पर input validation, data loss से बचाने वाली error handling, security और accessibility शामिल हैं, और यह हर non-trivial logic के लिए एक छोटा runnable check करने के लिए कहता है। यह rule केवल उन फालतू structures को हटाता है जो किसी ने नहीं मांगे और ऐसी dependencies जिन्हें किसी ने नहीं चाहा। यदि इसे install करने के बाद आपका agent tests छोड़ने लगे, तो इसका कारण आपकी अपनी config में मौजूद कोई अन्य instruction है जो इस rule से ऊपर है, इसलिए उस file को पढ़ें जिसे agent सबसे अंत में load करता है।

क्या प्रकाशित speed और cost के आंकड़े विश्वसनीय हैं?

ये project के स्वयं के मापन हैं, जो अपनी पद्धति के साथ प्रकाशित किए गए हैं, और इन्हें उसी रूप में पढ़ा जाना चाहिए। जून 2026 के single shot आंकड़ों की तुलना एक ऐसे bare model से की गई थी जो अपने उत्तर को prose और options के साथ बढ़ा-चढ़ाकर पेश करता था, जिसे उस समय के README ने स्वयं एक कमजोर baseline माना था। वर्तमान agentic आंकड़े Opus 5.5 पर headless Claude Code sessions से लिए गए हैं, जिसमें 39 tasks के पांच runs शामिल हैं, जिनमें से बारह एक FastAPI और React repository में feature tickets थे। उस setup के लिए ये ईमानदार आंकड़े हैं। ये आपके codebase के लिए कोई पूर्वानुमान नहीं हैं, क्योंकि project के प्रति-task परिणाम दिखाते हैं कि जो code पहले से ही minimal था, उस पर बचत लगभग शून्य हो जाती है।

क्या लाभ पाने के लिए मुझे कुछ भी install करने की आवश्यकता है?

नहीं। यह ladder केवल text है, और आपके agent द्वारा पहले से पढ़ी जाने वाली instruction file में एक समान block paste करने से आपको अधिकांश प्रभाव मिल जाता है। यह plugin आपको updated wording, intensity levels, review commands और एक update path प्रदान करता है। क्या install करने की वास्तव में आवश्यकता है, इस प्रश्न का उत्तर पाने के लिए पहले copied block को आज़माना ही rung 1 का समाधान है।

मैं किसी unattended agent को रात भर में over-building करने से कैसे रोकूँ?

Rule को chat message के बजाय always-on instruction file में रखें, ताकि यह एक लंबे run के 200वें turn पर भी लागू हो, न कि केवल तीसरे turn पर। फिर नुकसान को अलग से सीमित करें: agent को आपकी एकमात्र copy के बजाय एक ऐसा checkout दें जिसे वह खराब कर सके, और कुछ भी merge होने से पहले human diff review अनिवार्य करें। एक minimal diff rule आपके पढ़ने के काम को कम करता है। यह यह तय नहीं करता कि क्या merge होगा, और इसे ऐसा करना भी नहीं चाहिए।