Karpathy's LLM Wiki? No Code with Claude or Github Copilot!

I first encountered Andrej Karpathy's LLM Wiki gist 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 system.

The result is llm-wiki-nocode: 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.

What Is an LLM Wiki?

Before diving into the implementation, let me explain the concept. An LLM Wiki is a structured knowledge base that:

• Ingests raw documents and extracts entities (tools, people, companies), concepts (patterns, ideas), and relationships
• Retrieves facts exclusively from stored knowledge (no training data, no hallucinations)
• Maintains integrity through automated health checks and human review
• Compounds knowledge as you validate and refine auto-generated answers

The 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.

This 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.

Why No-Code?

Most 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.

I'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.

This project takes the opposite approach: zero dependencies, zero installation, pure natural language. No friction. Immediate usability.

What if you could ingest a document, ask questions, and maintain your knowledge base entirely through natural language? No terminals. No pip install. No YAML configuration. Just commands that read like English:

/wiki-ingest

/wiki-query What are the key architectural patterns?

/wiki-lint

This is what llm-wiki-nocode delivers. 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.

The Three Core Operations

The wiki's entire interface consists of three commands. Everything else follows from these three:

1. /wiki-ingest, Build Your Knowledge Base

Ingest 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.

You can pass a file path, use scan for auto-ingest, or --RESET-ALL if you want to start fresh. The output is new and updated pages in wiki/, plus a detailed log of what changed.

2. /wiki-query, Ask Questions Without Hallucination

Query 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/ for your review before it gets integrated as a synthesis page in the wiki.

3. /wiki-lint, Maintain Health

Lint 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/ for you to review and approve.

The Directory Structure

Understanding the layout is key to understanding how the wiki works:

wiki/                      ← Living knowledge base
├── index.md               ← Catalog of all pages
├── log.md                 ← Operation audit trail
├── sources/               ← One page per ingested document
├── entities/              ← Named things: tools, frameworks, companies
├── concepts/              ← Abstract ideas: patterns, methodologies
└── synthesis/             ← Approved answers from your questions

raw/                       ← Documents awaiting ingestion

questions_pending/         ← Auto-generated answers (your review)
questions_approved/        ← Answers you've validated

lint_pending/              ← Wiki health reports (your review)
lint_approved/             ← Fixes you've approved

docs/                      ← Specifications and guides

The key insight: wiki/ is the single source of truth. Everything else is a queue waiting for a human decision. raw/ is input. questions_pending/ and lint_pending/ are decisions waiting to be made. Once you approve something, it moves to _approved/ and gets integrated back into wiki/.

Three Page Types

The wiki uses three distinct page types to keep knowledge organized.

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.

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.

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.

How It Works: The Human-Gated Loop

This is the part that makes llm-wiki-nocode different 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.

The system generates, ingests a document, answers a question, finds health issues. Then you review what was generated, looking at the _pending/ folders. 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/ and gets integrated back into the living wiki.

This 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.

Automated generation    →    Human review    →    Integration
         ↓                        ↓                      ↓
   @wiki-querier          questions_pending/      wiki/synthesis/
   @wiki-linter           lint_pending/           wiki pages updated

Getting Started: A Practical Example

The repo includes three ready-made documents in the bak/ directory 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.

To test the wiki, copy one of these files to raw/ and run ingest:

cp bak/ARCH_BOOKING_PLATFORM.md raw/
/wiki-ingest

The 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/ and wiki/concepts/, and log every change in wiki/log.md.

Next, ask it a question:

/wiki-query What are the core services in the booking platform?

The 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.

Finally, run a health check:

/wiki-lint

The 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.

The Configuration Layer: .claude/ and .github/

This is a critical design decision that deserves explanation.

.claude/ Directory, Claude Code Configuration

The .claude/ folder contains the complete configuration for Claude Code:

.claude/
├── CLAUDE.md                  ← Project instructions and behavioral constraints
├── settings.json              ← Command registration and harness configuration
└── commands/
    ├── wiki-ingest.md         ← /wiki-ingest command workflow definition
    ├── wiki-query.md          ← /wiki-query command workflow definition
    └── wiki-lint.md           ← /wiki-lint command workflow definition

How it works: CLAUDE.md is the main system prompt that defines the wiki's identity and available commands. settings.json registers each command and maps it to a workflow. Each file in commands/ is 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.

When you type /wiki-ingest in Claude Code, it reads commands/wiki-ingest.md and executes that workflow.

.github/ Directory, GitHub Copilot Configuration

Similarly, .github/ contains GitHub Copilot-specific instructions:

.github/
├── prompts/
│   ├── wiki-ingest.prompt.md   ← LLM prompt for ingest command
│   ├── wiki-query.prompt.md    ← LLM prompt for query command
│   └── wiki-lint.prompt.md     ← LLM prompt for lint command
├── instructions/
│   └── wiki-schema.instructions.md  ← Shared page format and schema documentation
└── agents/
    ├── wiki-ingestor.agent.md  ← Ingestor agent definition
    ├── wiki-querier.agent.md   ← Querier agent definition
    └── wiki-linter.agent.md    ← Linter agent definition

GitHub Copilot reads these files automatically when you open the repo. The prompts/ folder contains the LLM instructions (analogous to Claude's commands/). The agents/ folder defines how each agent behaves. The instructions/ folder holds shared schema documentation so both Claude Code and Copilot understand the page format identically.

Mental Model: Think of .claude/ and .github/ as platform-specific adapters. The core logic (what to extract, how to format, what to validate) is shared through wiki-schema.instructions.md. But the way you invoke commands, the syntax, and how each LLM system structures its workflows differs between Claude Code and GitHub Copilot.

This dual-support approach means:

• If you use Claude Code: Open the project, type /wiki-ingest, Claude reads .claude/commands/wiki-ingest.md
• If you use GitHub Copilot: The repo integrates automatically, Copilot reads .github/prompts/wiki-ingest.prompt.md and uses .github/agents/wiki-ingestor.agent.md
• If you use neither: You can still read all the files and understand exactly what each operation does

No core logic is duplicated. Both versions implement the same three operations with identical semantics, they just speak different dialects.

Key Design Choices

Working through the full implementation revealed several important patterns worth sharing.

The 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.

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.

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/ folders force a decision point. It's cheap human attention spent upfront that saves you from debugging corrupted data later.

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.

Finally, 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.

What's Not Included (Yet)

This 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.

The 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.

Web 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/.

Multi-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.

None of these are impossible, they're just outside the current scope, waiting for a real use case to drive them.

Takeaways

Building llm-wiki-nocode clarified 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.

If 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.

The code is on GitHub (rosidotidev/llm-wiki-nocode). The specifications are in docs/. Start with a simple document, ingest it, ask a question, and see what happens.

---

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.