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

I first encountered Andrej Karpathy's

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.