karpathy-llm-wiki

name	karpathy-llm-wiki
description	Use when building or maintaining a personal LLM-powered knowledge base. Triggers: ingesting sources into a wiki, querying wiki knowledge, linting wiki quality, 'add to wiki', 'what do I know about', or any mention of 'LLM wiki' or 'Karpathy wiki'.
pipeline-status	["new"]

Karpathy LLM Wiki

Build and maintain a personal knowledge base using LLMs. You manage two directories: raw/ (immutable source material) and wiki/ (compiled knowledge articles). Sources go into raw/, you compile them into wiki articles, and the wiki compounds over time.

Core ideas from Karpathy:

• "The LLM writes and maintains the wiki; the human reads and asks questions."
• "The wiki is a persistent, compounding artifact."

Architecture

Three layers, all under the user's project root:

raw/ — Immutable source material. You read, never modify. Organized by topic subdirectories (e.g., raw/machine-learning/).

wiki/ — Compiled knowledge articles. You have full ownership. Organized by topic subdirectories, one level only: wiki/<topic>/<article>.md. Contains two special files:

• wiki/index.md — Global index. One row per article, grouped by topic, with link + summary + Updated date.
• wiki/log.md — Append-only operation log.

SKILL.md (this file) — Schema layer. Defines structure and workflow rules.

Templates live in references/ relative to this file. Read them when you need the exact format for raw files, articles, archive pages, or the index.

Open Knowledge Format alignment

This skill is evolving toward Google Cloud's Open Knowledge Format (OKF): markdown concept files with YAML frontmatter, stable type metadata, markdown links as the graph, and optional index.md/log.md files for progressive disclosure and chronology.

All generated wiki concept pages must be OKF-compatible. At minimum, every wiki/<topic>/<article>.md page has parseable YAML frontmatter with type, title, description, tags, and timestamp. This skill uses:

• type: Concept for normal compiled wiki articles.
• type: Archive for archived query answers.
• type: Source for raw source captures.
• type: Index and type: Log only for support files when explicit metadata is useful.

When the user asks about OKF, OKR details, schema alignment, or implementation planning for OKF compatibility, read references/okf-alignment-plan.md before changing templates or wiki behavior.

Initialization

Triggers only on the first Ingest. Check whether raw/ and wiki/ exist. Create only what is missing; never overwrite existing files:

• raw/ directory (with .gitkeep)
• wiki/ directory (with .gitkeep)
• wiki/index.md — OKF support page with type: Index, heading # Knowledge Base Index, empty body
• wiki/log.md — OKF support page with type: Log, heading # Wiki Log, empty body

If Query or Lint cannot find the wiki structure, tell the user: "Run an ingest first to initialize the wiki." Do not auto-create.

---

Ingest

Fetch a source into raw/, then compile it into wiki/. Always both steps, no exceptions.

Fetch (raw/)

1. Get the source content using whatever web or file tools your environment provides. If nothing can reach the source, ask the user to paste it directly.

2. Pick a topic directory. Check existing raw/ subdirectories first; reuse one if the topic is close enough. Create a new subdirectory only for genuinely distinct topics.

3. Save as raw/<topic>/YYYY-MM-DD-descriptive-slug.md.

   • Slug from source title, kebab-case, max 60 characters.
   • Published date unknown → omit the date prefix from the file name (e.g., descriptive-slug.md). The metadata Published field still appears; set it to Unknown.
   • If a file with the same name already exists, append a numeric suffix (e.g., descriptive-slug-2.md).
   • Include OKF frontmatter with type: Source, title, description, tags, timestamp, source, collected, and published.
   • Keep the human-readable metadata header for scanability.
   • Preserve original text. Clean formatting noise. Do not rewrite opinions.

   See references/raw-template.md for the exact format.

Compile (wiki/)

Determine where the new content belongs:

• Same core thesis as existing article → Merge into that article. Add the new source to Sources/Raw. Update affected sections.
• New concept → Create a new article in the most relevant topic directory. Name the file after the concept, not the raw file.
• Spans multiple topics → Place in the most relevant directory. Add See Also cross-references to related articles elsewhere.

These are not mutually exclusive. A single source may warrant merging into one article while also creating a separate article for a distinct concept it introduces. In all cases, check for factual conflicts: if the new source contradicts existing content, annotate the disagreement with source attribution. When merging, note the conflict within the merged article. When the conflicting content lives in separate articles, note it in both and cross-link them.

See references/article-template.md for article format. Key points:

• Frontmatter must be parseable YAML and include type: Concept.
• title is the concept name, not the source title unless they are identical.
• description is a one-sentence retrieval surface for the article.
• tags are stable topic/entity terms useful for retrieval.
• timestamp reflects when the article's knowledge content last changed.
• sources is a YAML list of author, organization, or publication name + date.
• raw is a YAML list of markdown links to raw/ files.
• Relative paths from wiki/<topic>/ use ../../raw/<topic>/<file>.md (two levels up to project root).
• Keep the human-readable > Sources: and > Raw: block only when useful for scanability. If both frontmatter and prose provenance exist, they must agree.

Cascade Updates

After the primary article, check for ripple effects:

1. Scan articles in the same topic directory for content affected by the new source.
2. Scan wiki/index.md entries in other topics for articles covering related concepts.
3. Update every article whose content is materially affected. Each updated file gets its timestamp and index Updated date refreshed.

Archive pages are never cascade-updated (they are point-in-time snapshots).

Post-Ingest

Update wiki/index.md: add or update entries for every touched article. When adding a new topic section, include a one-line description. The Updated date reflects when the article's knowledge content last changed, not the file system timestamp. See references/index-template.md for format.

Append to wiki/log.md:

## [YYYY-MM-DD] ingest | <primary article title>
- Updated: <cascade-updated article title>
- Updated: <another cascade-updated article title>

Omit - Updated: lines when no cascade updates occur.

---

Query

Search the wiki and answer questions. Examples of triggers:

• "What do I know about X?"
• "Summarize everything related to Y"
• "Compare A and B based on my wiki"

Steps

1. Read wiki/index.md to locate relevant articles.
2. Read those articles and synthesize an answer.
3. Prefer wiki content over your own training knowledge. Cite sources with markdown links: [Article Title](wiki/topic/article.md) (project-root-relative paths for in-conversation citations; within wiki/ files, use paths relative to the current file).
4. Output the answer in the conversation. Do not write files unless asked.

Archiving

When the user explicitly asks to archive or save the answer to the wiki:

1. Write the answer as a new wiki page. See references/archive-template.md. When converting conversation citations to the archive page, rewrite project-root-relative paths (e.g., wiki/topic/article.md) to file-relative paths (e.g., ../topic/article.md or article.md for same-directory).
   • Frontmatter must use type: Archive.
   • archived_from records the user query or source conversation summary.
   • Sources: markdown links to the wiki articles cited in the answer.
   • No Raw field (content does not come from raw/).
   • File name reflects the query topic, e.g., transformer-architectures-overview.md.
   • Place in the most relevant topic directory.
2. Always create a new page. Never merge into existing articles (archive content is a synthesized answer, not raw material).
3. Update wiki/index.md. Prefix the Summary with [Archived].
4. Append to wiki/log.md:

   ## [YYYY-MM-DD] query | Archived: <page title>
   

---

Lint

Quality checks on the wiki. Two categories with different authority levels.

Deterministic Checks (auto-fix)

Fix these automatically:

OKF frontmatter — for every non-reserved wiki/**/*.md file:

• Missing frontmatter → add safe frontmatter only when type and title can be inferred mechanically; otherwise report it.
• Missing type on a normal article → add type: Concept.
• Missing type on an archived query page → add type: Archive only when the page title or index summary clearly marks it archived.
• Missing title → add the first H1 text.
• Missing timestamp → use the article's existing Updated metadata if present; otherwise use the file's last modified date.
• Unparseable frontmatter → report it; do not guess.

Index consistency — compare wiki/index.md against actual wiki/ files (excluding index.md and log.md):

• File exists but missing from index → add entry with (no summary) placeholder. For Updated, use the article's metadata Updated date if present; otherwise fall back to file's last modified date.
• Index entry points to nonexistent file → mark as [MISSING] in the index. Do not delete the entry; let the user decide.

Internal links — for every markdown link in wiki/ article files (body text and Sources metadata), excluding Raw field links (validated by Raw references below) and excluding index.md/log.md (handled above):

• Target does not exist → search wiki/ for a file with the same name elsewhere.
  • Exactly one match → fix the path.
  • Zero or multiple matches → report to the user.

Raw references — every link in a Raw field must point to an existing raw/ file:

• Target does not exist → search raw/ for a file with the same name elsewhere.
  • Exactly one match → fix the path.
  • Zero or multiple matches → report to the user.
• If both frontmatter raw and prose > Raw: exist, they must reference the same files. If one side is missing and the other side is parseable, mirror the parseable side.

See Also — within each topic directory:

• Add obviously missing cross-references between related articles.
• Remove links to deleted files.

Heuristic Checks (report only)

These rely on your judgment. Report findings without auto-fixing:

• Missing or weak description fields
• Missing or low-quality tags
• Factual contradictions across articles
• Outdated claims superseded by newer sources
• Missing conflict annotations where sources disagree
• Orphan pages with no inbound links from other wiki articles
• Missing cross-topic references
• Concepts frequently mentioned but lacking a dedicated page
• Archive pages whose cited source articles have been substantially updated since archival

Post-Lint

Append to wiki/log.md:

## [YYYY-MM-DD] lint | <N> issues found, <M> auto-fixed

---

Conventions

• Standard markdown with relative links throughout.
• wiki/ supports one level of topic subdirectories only. No deeper nesting.
• Today's date for log entries, Collected dates, and Archived dates. Updated dates and OKF timestamp values reflect when the article's knowledge content last changed. Published dates come from the source (use Unknown when unavailable).
• Inside wiki/ files, all markdown links use paths relative to the current file. In conversation output, use project-root-relative paths (e.g., wiki/topic/article.md).
• Ingest updates both wiki/index.md and wiki/log.md. Archive (from Query) updates both. Lint updates wiki/log.md (and wiki/index.md only when auto-fixing index entries). Plain queries do not write any files.
• For legacy pages, migrate conservatively. Auto-add safe OKF fields only when they can be inferred from the page itself. Report fields that require interpretation instead of inventing metadata.