18 भाषाएँ · कोई भी OpenAI-compatible endpoint · MIT

एक codebase अंदर। दो handbooks बाहर — एक आपकी टीम पढ़ती है, एक से आपका agent रास्ता निकालता है।

आपका coding agent किसी symbol को grep करता है, जो सात जगहें मायने रखती हैं उनमें से तीन ढूँढता है, और आधा-अधूरा बदलाव ship कर देता है। यह reasoning की विफलता नहीं, routing की विफलता है। Handbooks उसे नक़्शा थमा देता है।

Offline demo चलाएँ Documentation पढ़ें
# पूरी pipeline, offline, बिना API key, ~30 सेकंड
pnpm install && pnpm build
pnpm demo

साथ में आया sample project, साथ में आया mock LLM। ख़र्च हुए tokens: शून्य।

सात commands, एक loop

टील रंग के steps deterministic हैं — न LLM, न network, CI में जितनी बार चाहें मुफ़्त चलाइए। एम्बर रंग के steps आपके endpoint से बात करते हैं, और जो सीखते हैं उसे cache कर लेते हैं।

  1. 1analyzeबिना LLM

    हर file को typed call graph में parse करता है।

  2. 2generateLLM

    Cards, stages, prose, और cross-stage state।

  3. 3renderबिना LLM

    Markdown, HTML, agent index, llms.txt।

  4. 4skillबिना LLM

    आपके coding agent के लिए इसे package करता है।

  5. 5planLLM

    एक बदलाव को byte-exact edits में बदल देता है।

  6. 6applyबिना LLM

    सब-या-कुछ-नहीं patch, rollback के साथ।

  7. 7resyncLLM

    Handbooks को आगे बढ़ाता है। कोई rebuild नहीं।

  8. हर phase कैसे काम करता है →
Handbooks pipeline: analyze, generate, render, skill, plan, apply, और resync का feedback loop

आप जो पढ़ते हैं उस पर भरोसा क्यों कर सकते हैं

Facts parser से आते हैं

tree-sitter call graph बनाता है: functions, resolved edges, बाउंड्री कॉल, और वे calls जो resolve नहीं हो सकीं — वे quarantine में जाती हैं, उनके बारे में कभी अंदाज़ा नहीं लगाया जाता। यह layer कभी LLM को नहीं छूती, इसलिए हर run में एक जैसी रहती है।

Prose ऊपर की परत है, और यह कहती भी है

कोई file किसलिए है और कोई subsystem आपस में कैसे जुड़ा है, यह LLM लिखता है — हमेशा graph से बँधा हुआ। जहाँ वह विफल होता है, वहाँ भी structure ship होता है, बस description ख़ाली रहती है। गढ़े हुए वाक्य से छूटा हुआ वाक्य बेहतर है।

Routing के लिए बना है, पढ़ने के लिए नहीं

Output इस सवाल का जवाब देता है — “इस बदलाव को किन files, functions और state को छूना पड़ेगा?” — उन बिखरे और ग़ैर-ज़ाहिर हिस्सों समेत जो text search से छूट जाते हैं। इसके बाद planner हर address पर असली source पढ़ता है।

Apply करना जान-बूझकर उबाऊ है

Anchor का match byte-exact और अनोखा होना ज़रूरी है। कुछ भी लिखे जाने से पहले सब कुछ verify हो जाता है। छुई गई हर file का backup, patch से पहले के hash के साथ बनता है — ताकि rollback साबित कर सके कि वह क्या बहाल कर रहा है।

यह incremental ढंग से current रहता है

Resync पुराने graph का नए से diff करता है और सिर्फ़ वही regenerate करता है जो वाक़ई बदला। तीन files छुइए, तीन files की क़ीमत चुकाइए। Documentation सड़ना बंद कर देता है, क्योंकि उसे update करना महँगा रहा ही नहीं।

और यह अपनी सीमाएँ भी बता देता है

Config-driven analyzer से पढ़ी गई भाषाओं का overview में नाम लिया जाता है, ताकि “best-effort call relations” को कभी “exact” न पढ़ लिया जाए।

Analysis fidelity →

एक run। छह shipping formats।

Generation ही महँगा हिस्सा है, और वह एक ही बार होता है। नीचे का सब कुछ deterministic re-render है, जिसे आप हर commit पर चला सकते हैं।

Markdown handbook

overview · index · हर stage का एक page · state-register table

Multi-page HTML site

sticky TOC, breadcrumbs, theme toggle — file:// पर भी चलती है

एक self-contained page

एक अकेली .html, जिसे email करें या ticket में attach कर दें

Agent locator index

duty · entry concepts · state · exemplars · co-change hints

llms.txt + llms-full.txt

llms.txt convention, और साथ में पूरी handbook flattened

Agent SKILL package

SKILL.md + references/ + हर file का एक content hash

उस मुफ़्त command से शुरुआत कीजिए

handbook analyze को कभी API key की ज़रूरत नहीं पड़ती। इसे अपनी repo पर चलाइए, files और functions की गिनती देखिए, और तय कीजिए कि बाक़ी हिस्सा एक token ख़र्च करने लायक़ है या नहीं।

Install करें CLI संदर्भ