{"slug": "karpathy-s-llm-wiki-no-code-with-claude-or-github-copilot", "title": "Karpathy's LLM Wiki? No Code with Claude or Github Copilot!", "summary": "Here is a factual summary of the article:\n\nThe article introduces \"llm-wiki-nocode,\" a no-code knowledge management system designed to work with Claude Code and GitHub Copilot. It allows users to ingest documents, ask questions, and maintain a structured wiki using only natural language commands, with the core principle that all knowledge comes exclusively from user-fed sources to prevent AI hallucination. The system operates through three main commands—`/wiki-ingest`, `/wiki-query`, and `/wiki-lint`—and requires zero dependencies, installation, or coding experience.", "body_md": "I first encountered Andrej Karpathy's [LLM Wiki gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) and realized it captures something essential about how we should manage knowledge in the AI era: a structured, human-curated knowledge base that grows from what you feed it, not from what an LLM hallucinates. The problem is that most implementations I found required heavy coding. I decided to build a **completely no-code version** that works seamlessly with both Claude Code and GitHub Copilot's `.github/copilot-instructions.md`\n\nsystem.\n\nThe result is `llm-wiki-nocode`\n\n: a production-ready knowledge management system where you ingest documents, ask questions, and maintain a living wiki, all through natural language commands, zero Python required.\n\n## What Is an LLM Wiki?\n\nBefore diving into the implementation, let me explain the concept. An LLM Wiki is a **structured knowledge base** that:\n\n-\n**Ingests raw documents** and extracts entities (tools, people, companies), concepts (patterns, ideas), and relationships -\n**Retrieves facts** exclusively from stored knowledge (no training data, no hallucinations) -\n**Maintains integrity** through automated health checks and human review -\n**Compounds knowledge** as you validate and refine auto-generated answers\n\nThe key principle is simple: **everything the wiki knows comes from what you feed it.** Not from the LLM's training data. Not from the web. Only from your sources.\n\nThis solves a real problem. When you ask an LLM a question about your proprietary system, it often confidently makes things up. A wiki-based approach forces it to admit \"I found nothing\" if the knowledge isn't there. No pollution. No false authority.\n\n## Why No-Code?\n\nMost LLM Wiki implementations assume you have a Python environment, dependency management, vector databases, and patience for debugging integrations. That's the wrong barrier to entry.\n\nI'm also building a **production Python version** using the **Microsoft Agent Framework**, structured around agentic workflows, knowledge graph construction, and semantic retrieval. But that's a separate project with its own architecture and tradeoffs. It will be the subject of a future article.\n\n*This* project takes the opposite approach: **zero dependencies, zero installation, pure natural language**. No friction. Immediate usability.\n\nWhat if you could ingest a document, ask questions, and maintain your knowledge base entirely through natural language? No terminals. No `pip install`\n\n. No YAML configuration. Just commands that read like English:\n\n```\n/wiki-ingest\n/wiki-query What are the key architectural patterns?\n/wiki-lint\n```\n\nThis is what `llm-wiki-nocode`\n\ndelivers. The system is designed to be **human-operable**: someone who has never written a line of code can build and maintain their own knowledge base.\n\n## The Three Core Operations\n\nThe wiki's entire interface consists of three commands. Everything else follows from these three:\n\n### 1. `/wiki-ingest`\n\n, Build Your Knowledge Base\n\nIngest is where documents become knowledge. You point it at a raw file (Markdown, plain text, whatever), and it extracts **entities**, the named things like tools, frameworks, companies, people, and **concepts**, the abstract ideas like patterns, methodologies, principles. It detects relationships between them, merges new information with existing wiki pages, flags contradictions for your review, and updates the index and audit log in one pass.\n\nYou can pass a file path, use `scan`\n\nfor auto-ingest, or `--RESET-ALL`\n\nif you want to start fresh. The output is new and updated pages in `wiki/`\n\n, plus a detailed log of what changed.\n\n### 2. `/wiki-query`\n\n, Ask Questions Without Hallucination\n\nQuery is the retrieval side. You ask a question in natural language, and the system reads 3–8 relevant wiki pages and synthesizes an answer **exclusively from that content**. No external knowledge. No training data pollution. This is the core promise: every claim in the answer is cited with a wikilink showing exactly where it came from. The answer is saved to `questions_pending/`\n\nfor your review before it gets integrated as a synthesis page in the wiki.\n\n### 3. `/wiki-lint`\n\n, Maintain Health\n\nLint is your wiki's health check. It runs in two phases: first, a deterministic pass that catches broken links, orphaned pages, missing frontmatter, and empty sections. Then a semantic phase that looks for contradictions, stale claims, missing pages, and unreferenced entities. The output is a detailed report with suggested fixes, saved to `lint_pending/`\n\nfor you to review and approve.\n\n## The Directory Structure\n\nUnderstanding the layout is key to understanding how the wiki works:\n\n```\nwiki/                      ← Living knowledge base\n├── index.md               ← Catalog of all pages\n├── log.md                 ← Operation audit trail\n├── sources/               ← One page per ingested document\n├── entities/              ← Named things: tools, frameworks, companies\n├── concepts/              ← Abstract ideas: patterns, methodologies\n└── synthesis/             ← Approved answers from your questions\n\nraw/                       ← Documents awaiting ingestion\n\nquestions_pending/         ← Auto-generated answers (your review)\nquestions_approved/        ← Answers you've validated\n\nlint_pending/              ← Wiki health reports (your review)\nlint_approved/             ← Fixes you've approved\n\ndocs/                      ← Specifications and guides\n```\n\nThe key insight: `wiki/`\n\nis the single source of truth. Everything else is a **queue** waiting for a human decision. `raw/`\n\nis input. `questions_pending/`\n\nand `lint_pending/`\n\nare decisions waiting to be made. Once you approve something, it moves to `_approved/`\n\nand gets integrated back into `wiki/`\n\n.\n\n### Three Page Types\n\nThe wiki uses three distinct page types to keep knowledge organized.\n\n**Sources** are created when you ingest a document, one page per source file. Each source page contains the title, author, date, raw content, and a list of all entities and concepts extracted from that document. This is your audit trail: you know exactly which document something came from.\n\n**Entities** are named, identifiable things. A tool like Jira or Kubernetes. A framework like React or MAF. A company. A person. Each entity page lists its definition, where it appears (which sources and concepts reference it), and related entities. This creates a web of interconnected knowledge.\n\n**Concepts** are abstract ideas and patterns. A methodology like microservices or CQRS. A principle like DRY or YAGNI. A design pattern. Each concept page includes an explanation, examples (always with source citations), and connections to related concepts and entities. Concepts are how you see patterns across your sources.\n\n## How It Works: The Human-Gated Loop\n\nThis is the part that makes `llm-wiki-nocode`\n\ndifferent from other implementations. The system never makes 100 auto-decisions and leaves you to inherit the consequences. Instead, it follows a human-gated approval loop.\n\nThe system generates, ingests a document, answers a question, finds health issues. Then you review what was generated, looking at the `_pending/`\n\nfolders. You decide which auto-generated content is good enough to integrate, and which needs refinement or rejection. Once you approve, the content moves to `_approved/`\n\nand gets integrated back into the living wiki.\n\nThis loop is non-negotiable. The system assists; you decide. You never wake up one morning and discover the wiki made a thousand bad decisions overnight.\n\n```\nAutomated generation    →    Human review    →    Integration\n         ↓                        ↓                      ↓\n   @wiki-querier          questions_pending/      wiki/synthesis/\n   @wiki-linter           lint_pending/           wiki pages updated\n```\n\n## Getting Started: A Practical Example\n\nThe repo includes three ready-made documents in the `bak/`\n\ndirectory for testing. There's **afw-instructions.md**, technical documentation about Microsoft Agent Framework best practices. **mfa_agents_howto.md** is a how-to guide for building agents. And **ARCH_BOOKING_PLATFORM.md** is a simulated system architecture document. These examples show how the wiki handles diverse source material.\n\nTo test the wiki, copy one of these files to `raw/`\n\nand run ingest:\n\n```\ncp bak/ARCH_BOOKING_PLATFORM.md raw/\n/wiki-ingest\n```\n\nThe ingestor will parse the architecture doc, extract entities like services, technologies, and teams, pull out concepts like \"microservices\", \"event-driven\", and \"CQRS\", create pages for each in `wiki/entities/`\n\nand `wiki/concepts/`\n\n, and log every change in `wiki/log.md`\n\n.\n\nNext, ask it a question:\n\n```\n/wiki-query What are the core services in the booking platform?\n```\n\nThe querier will search the wiki for relevant pages, answer using only what's there, cite sources with wikilinks, and save the answer for your review.\n\nFinally, run a health check:\n\n```\n/wiki-lint\n```\n\nThe linter will check for broken links, orphaned pages, contradictions, and suggest fixes. You review the report, decide which fixes to apply, and the wiki improves itself.\n\n## The Configuration Layer: `.claude/`\n\nand `.github/`\n\nThis is a critical design decision that deserves explanation.\n\n### `.claude/`\n\nDirectory, Claude Code Configuration\n\nThe `.claude/`\n\nfolder contains the complete configuration for Claude Code:\n\n```\n.claude/\n├── CLAUDE.md                  ← Project instructions and behavioral constraints\n├── settings.json              ← Command registration and harness configuration\n└── commands/\n    ├── wiki-ingest.md         ← /wiki-ingest command workflow definition\n    ├── wiki-query.md          ← /wiki-query command workflow definition\n    └── wiki-lint.md           ← /wiki-lint command workflow definition\n```\n\n**How it works**: `CLAUDE.md`\n\nis the main system prompt that defines the wiki's identity and available commands. `settings.json`\n\nregisters each command and maps it to a workflow. Each file in `commands/`\n\nis a **complete specification**, it tells Claude exactly how to perform that operation: what to read, what to extract, what format to use, what to validate.\n\nWhen you type `/wiki-ingest`\n\nin Claude Code, it reads `commands/wiki-ingest.md`\n\nand executes that workflow.\n\n### `.github/`\n\nDirectory, GitHub Copilot Configuration\n\nSimilarly, `.github/`\n\ncontains GitHub Copilot-specific instructions:\n\n```\n.github/\n├── prompts/\n│   ├── wiki-ingest.prompt.md   ← LLM prompt for ingest command\n│   ├── wiki-query.prompt.md    ← LLM prompt for query command\n│   └── wiki-lint.prompt.md     ← LLM prompt for lint command\n├── instructions/\n│   └── wiki-schema.instructions.md  ← Shared page format and schema documentation\n└── agents/\n    ├── wiki-ingestor.agent.md  ← Ingestor agent definition\n    ├── wiki-querier.agent.md   ← Querier agent definition\n    └── wiki-linter.agent.md    ← Linter agent definition\n```\n\nGitHub Copilot reads these files automatically when you open the repo. The `prompts/`\n\nfolder contains the LLM instructions (analogous to Claude's `commands/`\n\n). The `agents/`\n\nfolder defines how each agent behaves. The `instructions/`\n\nfolder holds shared schema documentation so both Claude Code and Copilot understand the page format identically.\n\n**Mental Model**: Think of `.claude/`\n\nand `.github/`\n\nas **platform-specific adapters**. The core logic (what to extract, how to format, what to validate) is shared through `wiki-schema.instructions.md`\n\n. But the way you invoke commands, the syntax, and how each LLM system structures its workflows differs between Claude Code and GitHub Copilot.\n\nThis dual-support approach means:\n\n-\n**If you use Claude Code**: Open the project, type`/wiki-ingest`\n\n, Claude reads`.claude/commands/wiki-ingest.md`\n\n-\n**If you use GitHub Copilot**: The repo integrates automatically, Copilot reads`.github/prompts/wiki-ingest.prompt.md`\n\nand uses`.github/agents/wiki-ingestor.agent.md`\n\n-\n**If you use neither**: You can still read all the files and understand exactly what each operation does\n\nNo core logic is duplicated. Both versions implement the same three operations with identical semantics, they just speak different dialects.\n\n## Key Design Choices\n\nWorking through the full implementation revealed several important patterns worth sharing.\n\nThe wiki uses **retrieval-only queries, not fine-tuning**. It doesn't train or modify the LLM. Instead, it uses semantic search to find relevant pages and asks the LLM to synthesize an answer from only those pages. This is both simpler to implement and more reliable than RAG with fine-tuning.\n\n**Entities and concepts are fundamentally different**, and treating them that way matters. A tool like Jira or PostgreSQL is an entity, a concrete thing you can point to. A pattern like CQRS or event sourcing is a concept, an idea that can apply in many contexts. When the wiki understands this distinction, you can ask \"What concepts relate to Kubernetes?\" and get a meaningful, connected answer.\n\n**Human review before integration** is non-negotiable. A single document ingest can generate hundreds of pages. If you didn't review them, you'd have garbage in your wiki. The `_pending/`\n\nfolders force a decision point. It's cheap human attention spent upfront that saves you from debugging corrupted data later.\n\n**The audit trail is mandatory.** Every operation, every ingest, query, lint, is logged with timestamps, the files it touched, and what changed. This is how you answer \"When did I ingest that architecture doc?\" and \"What exactly did that ingest change?\" questions months later when your memory is fuzzy.\n\nFinally, the wiki uses **plain Markdown with simple YAML frontmatter**. No proprietary format. No database. Everything is human-readable, editable, and version-controlled. You can throw it in Git, diff it, and understand what changed without needing special tools.\n\n## What's Not Included (Yet)\n\nThis is a no-code system for knowledge ingestion and retrieval. It doesn't include vector databases or semantic search, you don't need them at small scale, and simple keyword plus fuzzy matching works fine for document lookup. If you scale large, that's a future architectural decision you can make then.\n\nThe wiki doesn't fine-tune or train the model. It works with any LLM that supports Claude Code or Copilot integrations, so you're not locked into a single backend.\n\nWeb ingestion isn't built in. You ingest documents from files. If you want to ingest web pages, you'd scrape them to Markdown first and place them in `raw/`\n\n.\n\nMulti-user collaboration is deferred. The system assumes a single human curator making review and approval decisions. Role-based approval and conflict resolution for teams are possible, but not yet implemented.\n\nNone of these are impossible, they're just outside the current scope, waiting for a real use case to drive them.\n\n## Takeaways\n\nBuilding `llm-wiki-nocode`\n\nclarified something important: **the most powerful knowledge systems are simple systems that humans control**. The wiki doesn't make decisions. It generates, you review, you decide.\n\nIf you're drowning in documentation that lives in Slack threads, scattered Markdown files, or worse, in everyone's heads, this pattern offers a way out. Feed documents to the wiki. Ask questions. Maintain a single source of truth. All without leaving your editor.\n\nThe code is on [GitHub (rosidotidev/llm-wiki-nocode)](https://github.com/rosidotidev/llm-wiki-nocode). The specifications are in `docs/`\n\n. Start with a simple document, ingest it, ask a question, and see what happens.\n\n**What would you use a no-code LLM wiki for?** Is knowledge management the bottleneck in your projects, or is something else? I'd love to hear your thoughts in the comments.", "url": "https://wpnews.pro/news/karpathy-s-llm-wiki-no-code-with-claude-or-github-copilot", "canonical_source": "https://dev.to/rosidotidev/karpathys-llm-wiki-no-code-with-claude-or-github-copilot-5fb0", "published_at": "2026-05-23 15:22:49+00:00", "updated_at": "2026-05-23 15:31:56.951178+00:00", "lang": "en", "topics": ["large-language-models", "developer-tools", "artificial-intelligence", "open-source"], "entities": ["Andrej Karpathy", "Claude Code", "GitHub Copilot", "Microsoft Agent Framework"], "alternates": {"html": "https://wpnews.pro/news/karpathy-s-llm-wiki-no-code-with-claude-or-github-copilot", "markdown": "https://wpnews.pro/news/karpathy-s-llm-wiki-no-code-with-claude-or-github-copilot.md", "text": "https://wpnews.pro/news/karpathy-s-llm-wiki-no-code-with-claude-or-github-copilot.txt", "jsonld": "https://wpnews.pro/news/karpathy-s-llm-wiki-no-code-with-claude-or-github-copilot.jsonld"}}