[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-75021":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":9,"rankLanguage":9,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":9,"pushedAt":9,"updatedAt":36,"readmeContent":37,"aiSummary":38,"trendingCount":15,"starSnapshotCount":15,"syncStatus":39,"lastSyncTime":40,"discoverSource":41},75021,"llm-wiki-compiler","atomicstrata\u002Fllm-wiki-compiler","atomicstrata","The knowledge compiler. Raw sources in, interlinked wiki out. Inspired by Karpathy's LLM Wiki pattern.",null,"TypeScript",1489,155,10,4,0,27,87,356,81,19.58,"MIT License",false,"main",true,[26,27,28,29,30,31,32,33,34,35],"cli","compiler","context-engineering","karpathy","knowledge-base","knowledge-compilation","llm","markdown","obsidian","wiki","2026-06-12 02:03:31","# llmwiki\n\nCompile raw sources into an interlinked markdown wiki.\n\nInspired by Karpathy's [LLM Wiki](https:\u002F\u002Fgist.github.com\u002Fkarpathy\u002F442a6bf555914893e9891c11519de94f) pattern: instead of re-discovering knowledge at query time, compile it once into a persistent, browsable artifact that compounds over time.\n\n![llmwiki demo](docs\u002Fimages\u002Fdemo.gif)\n\n## Who this is for\n\n- **AI researchers and engineers** building persistent knowledge from papers, docs, and notes\n- **Technical writers** compiling scattered sources into a structured, interlinked reference\n- **Anyone with too many bookmarks** who wants a wiki instead of a graveyard of tabs\n\n## Quick start\n\n```bash\nnpm install -g llm-wiki-compiler\nexport ANTHROPIC_API_KEY=sk-...\n# Or use ANTHROPIC_AUTH_TOKEN if your Anthropic-compatible gateway expects it.\n# Or use a different provider:\n# export LLMWIKI_PROVIDER=openai\n# export OPENAI_API_KEY=sk-...\n\nllmwiki ingest https:\u002F\u002Fsome-article.com\nllmwiki compile\nllmwiki query \"what is X?\"\n```\n\n## Configuration\n\nllmwiki configures providers via environment variables. The default provider is Anthropic.\n\nConfiguration precedence for Anthropic values:\n\n1. Shell env \u002F local `.env`\n2. Claude Code settings fallback (`~\u002F.claude\u002Fsettings.json` → `env` block)\n3. Built-in provider defaults (where applicable)\n\n- `LLMWIKI_PROVIDER`: The provider to use (e.g., anthropic, openai).\n- `LLMWIKI_MODEL`: The model name to override the provider default.\n\n### Anthropic (Default)\n\n- `ANTHROPIC_API_KEY` or `ANTHROPIC_AUTH_TOKEN`: Required. Either one can satisfy Anthropic authentication.\n- `ANTHROPIC_BASE_URL`: Optional. Custom endpoint for proxies. Valid HTTP(S) URLs are accepted, including Claude-style path endpoints such as `https:\u002F\u002Fapi.kimi.com\u002Fcoding\u002F`.\n\nExample using an Anthropic or cc-switch custom proxy:\n\n```bash\nexport LLMWIKI_PROVIDER=anthropic\nexport ANTHROPIC_API_KEY=sk-...\nexport ANTHROPIC_BASE_URL=https:\u002F\u002Fproxy.example.com\n```\n\nIf those values are not set in shell env or `.env`, llmwiki will try Anthropic-compatible values from `~\u002F.claude\u002Fsettings.json` (`env` block) for:\n\n- `ANTHROPIC_API_KEY`\n- `ANTHROPIC_AUTH_TOKEN`\n- `ANTHROPIC_BASE_URL`\n- `ANTHROPIC_MODEL`\n\nExample with zero exports (Claude Code already configured):\n\n```bash\nllmwiki compile\n```\n\n### OpenAI-Compatible Local Servers\n\nUse the OpenAI provider for local OpenAI-compatible servers such as\n`llama-server`. `OPENAI_BASE_URL` is used for chat\u002Ftool calls, and\n`OPENAI_EMBEDDINGS_BASE_URL` is optional. Set it only when embeddings are\nserved from a different endpoint; when unset, embeddings use the same client\nand base URL as chat. Include `\u002Fv1` in custom URLs.\n\nSplit endpoint example:\n\n```bash\nexport LLMWIKI_PROVIDER=openai\nexport LLMWIKI_MODEL=qwen3.6-35b\nexport LLMWIKI_EMBEDDING_MODEL=text-embedding-model\nexport OPENAI_API_KEY=sk-local\nexport OPENAI_BASE_URL=http:\u002F\u002Fhost_url:port\u002Fv1\nexport OPENAI_EMBEDDINGS_BASE_URL=http:\u002F\u002Fhost_url:port\u002Fv1\n```\n\n`OPENAI_API_KEY` is still required by the CLI and OpenAI SDK. For local\nservers that do not check authentication, any dummy value is sufficient.\n\n### Ollama\n\nOllama uses its OpenAI-compatible endpoint. Set `OLLAMA_HOST` for chat and\noptionally set `OLLAMA_EMBEDDINGS_HOST` only when embeddings are served from a\ndifferent endpoint. When unset, embeddings use `OLLAMA_HOST`. Include `\u002Fv1` in\ncustom URLs.\n\n```bash\nexport LLMWIKI_PROVIDER=ollama\nexport LLMWIKI_MODEL=llama3.1\nexport LLMWIKI_EMBEDDING_MODEL=nomic-embed-text\nexport OLLAMA_HOST=http:\u002F\u002Follama_host:11434\u002Fv1\nexport OLLAMA_EMBEDDINGS_HOST=http:\u002F\u002Follama_host:11435\u002Fv1\n```\n\n### GitHub Copilot\n\nUses the GitHub Copilot API (`https:\u002F\u002Fapi.githubcopilot.com`), an\nOpenAI-compatible endpoint available to Copilot subscribers. Requires a GitHub\nOAuth token with the `copilot` scope — **classic PATs are not supported**.\n\nFirst, ensure your `gh` CLI token has the required scope:\n\n```bash\ngh auth refresh --scopes copilot\n```\n\nThen run:\n\n```bash\nexport LLMWIKI_PROVIDER=copilot\nexport GITHUB_TOKEN=$(gh auth token)  # OAuth token required; PATs will not work\nexport LLMWIKI_MODEL=gpt-4o           # optional; gpt-4o is the default\n```\n\nAvailable models (names use dots, not dashes): `gpt-4o`, `gpt-4o-mini`,\n`claude-sonnet-4.5`, `claude-sonnet-4.6`, `claude-opus-4.5`, `gemini-2.5-pro`,\nand others — availability depends on your Copilot plan.\n\n**Embeddings:** The GitHub Copilot API does not expose an embeddings endpoint.\nSemantic search (used by `llmwiki query` with chunked retrieval) will fall back\nto full-index selection without embeddings. For embedding-dependent workflows,\nswitch to the `openai` provider and provide `OPENAI_API_KEY`.\n\n### Request timeouts\n\nThe OpenAI SDK defaults to a 10-minute per-request timeout, which can cut off long compile-time completions on slower local models. Override per provider:\n\n- `LLMWIKI_REQUEST_TIMEOUT_MS` — provider-agnostic timeout in milliseconds. Applies to both the `openai` and `ollama` backends.\n- `OLLAMA_TIMEOUT_MS` — Ollama-specific override. Wins over `LLMWIKI_REQUEST_TIMEOUT_MS` when both are set.\n\nDefaults: 10 minutes for `openai`, 30 minutes for `ollama` (local models commonly need more).\n\n### Output language\n\nGenerated wiki content defaults to whatever language the model produces from the source material — typically English. Override with either:\n\n- `LLMWIKI_OUTPUT_LANG` — e.g. `zh-CN`, `Chinese`, `ja`, `Japanese`. Applies to every prompt the compile and query pipelines make.\n- `--lang \u003Ccode>` on `llmwiki compile` and `llmwiki query` — same effect, scoped to one invocation. Wins over the env var.\n\nUnset preserves prior behaviour byte-for-byte.\n\n### Per-concept prompt budget\n\nWhen many sources contribute to the same compiled concept, `compile` enforces a per-concept character cap on the combined source content sent to the LLM so popular shared concepts don't blow past the model's context window. Each contributing source gets a fair share when truncation kicks in.\n\n- `LLMWIKI_PROMPT_BUDGET_CHARS` — character ceiling for the combined per-concept prompt. Defaults to `200000` (~50k tokens), which fits modern context windows with headroom. Raise it for larger-context models, lower it for local small-context models.\n\nA truncation warning prints to stderr when the cap fires so you know which concept hit the budget.\n\n## Why not just RAG?\n\nRAG retrieves chunks at query time. Every question re-discovers the same relationships from scratch. Nothing accumulates.\n\nllmwiki **compiles** your sources into a wiki. Concepts get their own pages. Pages link to each other. When you ask a question with `--save`, the answer becomes a new page, and future queries use it as context. Your explorations compound.\n\nThis is complementary to RAG, not a replacement. RAG is great for ad-hoc retrieval over large corpora. llmwiki gives you a persistent, structured artifact to retrieve from.\n\n```\nRAG:     query → search chunks → answer → forget\nllmwiki: sources → compile → wiki → query → save → richer wiki → better answers\n```\n\n## How it works\n\n```\nsources\u002F  →  SHA-256 hash check  →  LLM concept extraction  →  wiki page generation  →  [[wikilink]] resolution  →  index.md\n```\n\n**Two-phase pipeline.** Phase 1 extracts all concepts from all sources. Phase 2 generates pages. This eliminates order-dependence, catches failures before writing anything, and merges concepts shared across multiple sources into single pages.\n\n**Incremental.** Only changed sources go through the LLM. Everything else is skipped via hash-based change detection.\n\n**Compounding queries.** `llmwiki query --save` writes the answer as a wiki page and immediately rebuilds the index. Saved answers show up in future queries as context.\n\n### What it produces\n\nA raw source like a Wikipedia article on knowledge compilation becomes a structured wiki page:\n\n```yaml\n---\ntitle: Knowledge Compilation\nsummary: Techniques for converting knowledge representations into forms that support efficient reasoning.\nkind: concept\nsources:\n  - knowledge-compilation.md\ncreatedAt: \"2026-04-05T12:00:00Z\"\nupdatedAt: \"2026-04-05T12:00:00Z\"\n---\n```\n\n```markdown\nKnowledge compilation refers to a family of techniques for pre-processing\na knowledge base into a target language that supports efficient queries.\n\nRelated concepts: [[Propositional Logic]], [[Model Counting]]\n```\n\nPages include source attribution in frontmatter. Paragraphs are annotated with `^[filename.md]` markers pointing back to the source file that contributed the content; specific claims can use line ranges like `^[filename.md:42-58]` or `^[filename.md#L42-L58]`.\n\n## Commands\n\n| Command | What it does |\n|---------|-------------|\n| `llmwiki ingest \u003Curl\\|file>` | Fetch a URL or copy a local file into `sources\u002F` |\n| `llmwiki ingest-session \u003Cpath>` | Import a Claude\u002FCodex\u002FCursor session export (single file or whole directory) into `sources\u002F` |\n| `llmwiki compile` | Incremental compile: extract concepts, generate wiki pages |\n| `llmwiki compile --review` | Write candidate pages to `.llmwiki\u002Fcandidates\u002F` instead of `wiki\u002F` so you can review before they land |\n| `llmwiki compile --lang \u003Ccode>` | Generate wiki content in the given language (e.g. `Chinese`, `ja`, `zh-CN`); also works on `query` |\n| `llmwiki review list` | List pending candidate pages |\n| `llmwiki review show \u003Cid>` | Print a candidate's title, summary, and body |\n| `llmwiki review approve \u003Cid>` | Promote a candidate into `wiki\u002F` and refresh index\u002FMOC\u002Fembeddings |\n| `llmwiki review reject \u003Cid>` | Archive a candidate without touching `wiki\u002F` |\n| `llmwiki schema init` | Write a starter `.llmwiki\u002Fschema.json` file |\n| `llmwiki schema show` | Print the resolved schema for the current project |\n| `llmwiki query \"question\"` | Ask questions against your compiled wiki |\n| `llmwiki query \"question\" --save` | Answer and save the result as a wiki page |\n| `llmwiki export [--target \u003Cname>]` | Export the wiki to portable formats — `llms.txt`, `llms-full.txt`, JSON, JSON-LD, GraphML, Marp slides |\n| `llmwiki lint` | Check wiki quality (broken links, orphans, empty pages, low confidence, contradictions, etc.) |\n| `llmwiki watch` | Auto-recompile when `sources\u002F` changes |\n| `llmwiki serve [--root \u003Cdir>]` | Start an MCP server exposing wiki tools to AI agents |\n\n## Output\n\n```\nwiki\u002F\n  concepts\u002F         one .md file per concept, with YAML frontmatter\n  queries\u002F          saved query answers, included in index and retrieval\n  index.md          auto-generated table of contents\n.llmwiki\u002F\n  schema.json       optional page-kind and cross-link policy\n  candidates\u002F       pending review candidates from `compile --review`\n  candidates\u002Farchive\u002F  rejected candidates kept for audit\n```\n\nObsidian-compatible. `[[wikilinks]]` resolve to concept titles.\n\n## Review queue\n\nBy default, `compile` writes pages directly to `wiki\u002F`. Add `--review` to write candidate JSON records to `.llmwiki\u002Fcandidates\u002F` instead, so you can inspect each generated page before it lands.\n\n```bash\nllmwiki compile --review     # produces candidates, leaves wiki\u002F untouched\nllmwiki review list          # see what's pending\nllmwiki review show \u003Cid>     # inspect a single candidate\nllmwiki review approve \u003Cid>  # write into wiki\u002F + refresh index\u002FMOC\u002Fembeddings\nllmwiki review reject \u003Cid>   # archive to .llmwiki\u002Fcandidates\u002Farchive\u002F\n```\n\nA few things to know:\n\n- **Approve and reject acquire `.llmwiki\u002Flock`** so they serialize cleanly against each other and against any concurrent `compile`.\n- **Source state is deferred per-source.** When one source produces multiple candidates, the source isn't marked compiled until the last candidate is approved — so unresolved siblings stay re-detectable on the next `compile --review`.\n- **Deletion bookkeeping is deferred.** `compile --review` does not orphan-mark deleted sources; the next non-review `compile` does that. The `--review` help text advertises this.\n- MCP `wiki_status` exposes `pendingCandidates` so agents can see the queue depth.\n\n## Page metadata\n\nCompiled pages can carry epistemic metadata in frontmatter so consumers know how trustworthy each page is. All fields are optional and existing pages without them continue to work.\n\n```yaml\n---\ntitle: Knowledge Compilation\nsummary: Techniques for converting knowledge representations...\nsources:\n  - knowledge-compilation.md\nconfidence: 0.82           # 0–1, LLM-reported confidence in the synthesized page\nprovenanceState: merged    # extracted | merged | inferred | ambiguous\ncontradictedBy:\n  - slug: probabilistic-reasoning\n---\n```\n\nWhen multiple sources merge into one slug, metadata is reconciled: `min` confidence, `provenanceState = 'merged'`, union of `contradictedBy` (deduped by slug).\n\n`llmwiki lint` adds three rules that surface this metadata:\n\n- `low-confidence` — flags pages with `confidence` below a threshold\n- `contradicted-page` — flags pages with non-empty `contradictedBy`\n- `excess-inferred-paragraphs` — flags pages whose body has too many uncited prose paragraphs (counted directly from the rendered text — the body is the single source of truth, no frontmatter field involved)\n\n## Claim-level provenance\n\nParagraph citations continue to use the original source-marker form:\n\n```markdown\nThis paragraph is grounded in the source. ^[source.md]\n```\n\nFor claims that need tighter verification, pages can pin a statement to a line range in the ingested source:\n\n```markdown\nThe system uses a two-phase compile pipeline. ^[architecture-notes.md:42-58]\nThe same range can also use GitHub-style anchors. ^[architecture-notes.md#L42-L58]\n```\n\n`llmwiki lint` validates both forms. It reports missing source files, malformed claim citations, impossible ranges like line `0` or `8-3`, and ranges that extend past the end of the source file.\n\n## Schema layer\n\nProjects can optionally define `.llmwiki\u002Fschema.json` to shape the wiki beyond flat concept pages. Existing projects do not need a schema file; missing or invalid `kind` values fall back to `concept`.\n\n```bash\nllmwiki schema init\nllmwiki schema show\n```\n\nThe schema supports four page kinds:\n\n- `concept` — standalone idea or pattern\n- `entity` — specific person, product, organization, or named artifact\n- `comparison` — side-by-side analysis across concepts or entities\n- `overview` — map page that connects several concepts in a domain\n\nSchema rules can set per-kind `minWikilinks` and optional `seedPages`. Compile can materialize seed pages such as overviews, lint enforces page-kind-specific cross-link minimums, and review candidates surface schema violations before approval.\n\n## Demo\n\nTry it on any article or document:\n\n```bash\nmkdir my-wiki && cd my-wiki\nllmwiki ingest https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FAndrej_Karpathy\nllmwiki compile\nllmwiki query \"What terms did Andrej coin?\"\n```\n\nSee `examples\u002Fbasic\u002F` in the repo for pre-generated output you can browse without an API key.\n\n## MCP Server\n\nllmwiki ships an MCP (Model Context Protocol) server so AI agents (Claude Desktop, Cursor, Claude Code, etc.) can drive the full pipeline directly: ingest sources, compile, query, search, lint, and read pages — without scraping CLI output.\n\nWhere [llm-wiki-kit](https:\u002F\u002Fgithub.com\u002Fiamsashank09\u002Fllm-wiki-kit) gives agents raw CRUD against wiki pages, llmwiki exposes the **automated pipelines**: agents get intelligent compilation, incremental change detection, and semantic query routing built in.\n\n### Setup\n\nStart the server (stdio transport, no API key required at startup):\n\n```bash\nllmwiki serve --root \u002Fpath\u002Fto\u002Fyour\u002Fwiki-project\n```\n\n### Claude Desktop \u002F Cursor configuration\n\nAdd to your client's MCP config (e.g. `claude_desktop_config.json`):\n\n```json\n{\n  \"mcpServers\": {\n    \"llmwiki\": {\n      \"command\": \"npx\",\n      \"args\": [\"llm-wiki-compiler\", \"serve\", \"--root\", \"\u002Fpath\u002Fto\u002Fwiki-project\"],\n      \"env\": {\n        \"ANTHROPIC_API_KEY\": \"sk-ant-...\"\n      }\n    }\n  }\n}\n```\n\nTools that need an LLM (`compile_wiki`, `query_wiki`, `search_pages`) check for a configured provider on each call. Read-only tools (`read_page`, `lint_wiki`, `wiki_status`) and `ingest_source` work without any credentials.\n\n### Tools\n\n| Tool | What it does |\n|------|--------------|\n| `ingest_source` | Fetch a URL or local file into `sources\u002F`. |\n| `compile_wiki` | Run the incremental compile pipeline; returns counts, slugs, errors. |\n| `query_wiki` | Two-step grounded answer with optional `--save`. |\n| `search_pages` | Return full content of pages relevant to a question. |\n| `read_page` | Read a single page by slug (concepts\u002F then queries\u002F). |\n| `lint_wiki` | Run quality checks; returns structured diagnostics. |\n| `wiki_status` | Page count, source count, orphans, pending changes (read-only). |\n\n### Resources\n\n| URI | Returns |\n|-----|---------|\n| `llmwiki:\u002F\u002Findex` | Full `wiki\u002Findex.md` content. |\n| `llmwiki:\u002F\u002Fconcept\u002F{slug}` | A single concept page (frontmatter + body). |\n| `llmwiki:\u002F\u002Fquery\u002F{slug}` | A single saved query page. |\n| `llmwiki:\u002F\u002Fsources` | List of ingested source files with metadata. |\n| `llmwiki:\u002F\u002Fstate` | Compilation state (per-source hashes, last compile times). |\n\n## Limitations\n\nEarly software. Best for small, high-signal corpora (a few dozen sources). Query routing is index-based.\n\n**Honest about truncation.** Sources that exceed the character limit are truncated on ingest with `truncated: true` and the original character count recorded in frontmatter, so downstream consumers know they're working with partial content.\n\n## Karpathy's LLM Wiki pattern vs this compiler\n\nKarpathy describes an abstract pattern for turning raw data into compiled knowledge. Here's how llmwiki maps to it:\n\n| Karpathy's concept | llmwiki | Status |\n|---|---|---|\n| Data ingest | `llmwiki ingest` | Implemented |\n| Compile wiki | `llmwiki compile` | Implemented |\n| Q&A | `llmwiki query` | Implemented |\n| Output filing (save answers back) | `llmwiki query --save` | Implemented |\n| Auto-recompile | `llmwiki watch` | Implemented |\n| Linting \u002F health-check pass | `llmwiki lint` | Implemented |\n| Agent integration | `llmwiki serve` (MCP server) | Implemented |\n| Image support | `llmwiki ingest \u003Cimage>` | Implemented |\n| Marp slides | `llmwiki export --target marp` | Implemented |\n| Fine-tuning | — | Not yet implemented |\n\n## Roadmap\n\nShipped in 0.6.0:\n\n- ✅ Export bundle (`llms.txt`, JSON, JSON-LD, GraphML, Marp slides)\n- ✅ Session-history adapters — `llmwiki ingest-session` for Claude, Codex, and Cursor exports\n- ✅ Configurable output language — `--lang \u003Ccode>` and `LLMWIKI_OUTPUT_LANG`\n- ✅ Defensive per-concept prompt budget so popular shared concepts don't crash compile\n\nShipped in 0.5.0:\n\n- ✅ Multimodal ingest (images, PDFs, transcripts)\n- ✅ Chunked retrieval with reranking and `--debug` output\n- ⚠️ Minimum Node version raised to 24 (was 18)\n\nShipped in 0.4.0:\n\n- ✅ Claim-level provenance with source ranges\n- ✅ First-class schema layer with typed page kinds (`concept`, `entity`, `comparison`, `overview`)\n\nShipped in 0.3.0:\n\n- ✅ Candidate review queue (approve compile output before pages are written)\n- ✅ Confidence and contradiction metadata on compiled pages\n\nShipped in 0.2.0:\n\n- ✅ Better provenance (paragraph-level source attribution)\n- ✅ Linting pass for wiki quality checks\n- ✅ Multi-provider support (OpenAI, Ollama, MiniMax)\n- ✅ Larger-corpus query strategy (semantic search, embeddings)\n- ✅ Deeper Obsidian integration (tags, aliases, Map of Content)\n- ✅ MCP server for agent integration\n\nNext up:\n\n- **Read-only local web UI** — browse `wiki\u002F` without Obsidian: sidebar, markdown rendering, wikilinks, search, and provenance\u002Fcitation panels.\n- **Graph\u002Fcontext layer** — page-neighborhood tools, graph paths, gap detection, and token-budgeted context packs for agents.\n- **Evaluation harness** — benchmark answer quality, citation accuracy, update drift, retrieval recall, and scale curves against serious retrieval baselines.\n- **Task and decision ledger** — turn session ingest into durable agent memory: goals, decisions, open questions, outcomes, and next-agent handoffs.\n- **Rollback, audit, and source lifecycle** — undo\u002Freverse ingest, compile diff reports, stale-claim checks, freshness reports, and a durable operation log.\n- **Domain templates** — schema\u002Fprompt packs for research, codebase docs, team handbooks, decision logs, and standards\u002Fregulations.\n\nLater \u002F open to discussion:\n\n- Recurring source refresh jobs — re-ingest URLs on a schedule, diff against the prior snapshot, re-compile only what changed\n- MCP prompt resources — curated agent prompts such as \"review the wiki\", \"propose new sources\", and \"draft a comparison page\"\n- Team-chat connectors for Slack\u002FDiscord\u002FTeams-style institutional memory\n\nIf you like ambitious problems: **local web UI**, **graph\u002Fcontext packs**, and **eval harness** are the meatiest next contributions. Open an issue to claim one or kick off a design discussion.\n\nExplicitly not planned (good ideas, just not for this repo): full static-site generator, desktop or mobile apps, fine-tuning, a formal ontology engine, heavy graph database infrastructure.\n\n## Requirements\n\nNode.js >= 24, plus provider credentials (for Anthropic: `ANTHROPIC_API_KEY` or `ANTHROPIC_AUTH_TOKEN`).\n\n## License\n\nMIT\n\n\n## Disclaimer\n\nNo LLMs were harmed in the making of this repo.\n","llm-wiki-compiler 是一个知识编译工具，将原始资料转换为相互链接的Markdown格式维基。该项目支持从各种文档、论文和笔记中提取信息，并通过一次性的编译过程生成持久化且易于浏览的知识库，避免了每次查询时重新发现知识的需求。技术上基于TypeScript构建，采用命令行界面（CLI）方式操作，支持Anthropic、OpenAI等多款语言模型作为后端提供者。适合AI研究人员和技术作家整理分散的信息源，也适用于个人用户创建个性化的知识管理系统，以替代杂乱无章的书签收藏。",2,"2026-06-11 03:51:59","high_star"]