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'.
npx skills add https://github.com/Astro-Han/karpathy-llm-wiki --skill 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:
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.
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 — heading # Knowledge Base Index, empty bodywiki/log.md — heading # Wiki Log, empty bodyIf Query or Lint cannot find the wiki structure, tell the user: "Run an ingest first to initialize the wiki." Do not auto-create.
Every load-bearing fact in wiki/ — numbers, dates, direct quotes — exists verbatim in the raw/ files linked by that article's Raw field. Compile *establishes* this invariant (locate before you write); lint *verifies* it (scripts/check_evidence.py greps the high-signal literals — suffixed or large numbers, decimals, ISO dates, longer quotes — in the linked raws; the compile-time locate-before-write rule covers the rest). Because raw/ is immutable, a verified article stays verified; the script re-checks the whole wiki in seconds, so there is no incremental state to maintain.
Fetch a source into raw/, then compile it into wiki/ — unless the source adds nothing new. Always fetch; whether to compile depends on the triage below.
raw/ subdirectories first; reuse one if the topic is close enough. Create a new subdirectory only for genuinely distinct topics.raw/<topic>/YYYY-MM-DD-descriptive-slug.md.descriptive-slug.md). The metadata Published field still appears; set it to Unknown.descriptive-slug-2.md).See references/raw-template.md for the exact format.
After saving the raw file and before editing wiki/, search wiki/ with the source's key entities and synonyms, then state the disposition:
New, Update, and Disputed may be combined. No material is exclusive.
Determine where the new content belongs:
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, mark the contested claims with a Status: Disputed block (see references/article-template.md). When the conflicting content lives in separate articles, mark both and cross-link them.
Source fidelity. Every number, date, and direct quote must be located in the raw file (grep or read) *before* it is written; write the value exactly as found — if the source says 42K, write 42K, not 42,000. Derived values (sums, deltas, counts you computed) must show their components so each component is findable in raw. If you cannot locate a value, do not write its exact form; drop it or state it without precision.
See references/article-template.md for article format. Key points:
wiki/<topic>/ use ../../raw/<topic>/<file>.md (two levels up to project root).After the primary article, check for ripple effects. Do not rely on the index alone: search the full wiki for the source's key entities, aliases, and the claims it touches, then update every non-archive article whose content is materially affected. Each updated file gets its Updated date refreshed.
When the new source supersedes or contradicts an existing claim, keep the old claim for the record but mark it with a Status block (see references/article-template.md): Outdated when something newer replaces it, Disputed when sources disagree. Never silently rewrite history.
Archive pages are never cascade-updated (they are point-in-time snapshots).
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>
- Disposition: <New; Update; Disputed>
- Raw: <raw file path>
- Updated: <cascade-updated article title>
Omit - Updated: lines when no cascade updates occur. For No material, log and stop. Use a project-root-relative raw path (for example, raw/topic/file.md):
## [YYYY-MM-DD] ingest | no material: <project-root-relative raw file path>
- Disposition: No material
The exact no-material heading is the machine-readable inventory key; the Disposition line remains required for a complete human-readable log entry.
Use only when the user explicitly asks to research a topic or gather sources into the wiki. Ordinary knowledge questions go to Query, which never writes files.
Search the wiki and answer questions. Examples of triggers:
wiki/index.md to locate candidate articles, then full-text search wiki/ with the topic's key terms *and their synonyms*. Never claim the wiki has no relevant content until both the index and the full-text search come back empty — and say that you searched.Article Title (project-root-relative paths for in-conversation citations; within wiki/ files, use paths relative to the current file).When the user explicitly asks to archive or save the answer to the wiki:
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).transformer-architectures-overview.md.wiki/index.md. Prefix the Summary with [Archived].wiki/log.md: ## [YYYY-MM-DD] query | Archived: <page title>
Quality checks on the wiki. Three categories with different authority levels.
Fix these automatically:
Index consistency — compare wiki/index.md against actual wiki/ files (excluding index.md and log.md):
(no summary) placeholder. For Updated, use the article's metadata Updated date if present (for archive pages, the Archived date); otherwise fall back to file's last modified date.[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), excluding See Also section links (handled by the See Also rule below), and excluding index.md/log.md (handled above):
Raw references — every link in a Raw field must point to an existing raw/ file:
See Also — within each topic directory:
Run these mechanically with python3 <skill-dir>/scripts/check_evidence.py <project-root> (optionally followed by project-root-relative article paths to limit scope). Default scope is the whole wiki; the script is fast. Report findings; never auto-fix facts.
Source fidelity — reported suspects are candidates, not verdicts: derived values and product names may appear. Judge each against the raw context and report only real mismatches.
Evidence errors — articles the script cannot verify (missing Raw field, unresolvable Raw links, or Raw links escaping raw/). These always need a decision, not a fix from the script.
Unreferenced raw files — files logged with a No material disposition are excluded; everything else is a genuine backlog reminder.
These rely on your judgment. Report findings without auto-fixing:
references/article-template.md)Append to wiki/log.md:
## [YYYY-MM-DD] lint | <N> issues found, <M> auto-fixed
Unknown when unavailable).wiki/topic/article.md).wiki/index.md and wiki/log.md (a No material ingest updates only the log). 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.Document technical debt, anti-patterns, and patterns to avoid from analyzed frameworks. Use when (1) creating a "Do Not Repeat" list from framework analysis, (2) categorizing observed code smells and issues, (3) assessing severity of architectural problems, (4) generating remediation suggestions, or (5) synthesizing lessons learned across multiple frameworks.
> Run an AI impact assessment — structured intake, risk analysis, regulatory classification per regime in scope, policy consistency diff, and recommendation with conditions. Uses the house-style structure learned from the seed impact assessment in `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`. Use when user says "impact assessment for", "assess this AI use case", "run an AIA", "generate an AIA", "we need to document this AI system", "AI risk assessment for X", or follows a conditional triage result.
Produce a proposed marked-up policy redraft that closes a gap found by /regulatory-legal:gaps or /regulatory-legal:policy-diff. A first draft for internal review — not for direct application to approved policy documents. Use when the user says "redraft the policy", "draft the policy fix", "mark up the policy", or when gap-surfacer hands off a gap for drafting.
> Scan the Obsidian wiki and automatically discover missing cross-references between pages. Use this skill when the user says "link my pages", "find missing links", "cross-reference", "connect my wiki", "add wikilinks", "what pages should be linked", or after any large ingestion to ensure new pages are woven into the existing knowledge graph. Also trigger when the user mentions "orphan pages" in the context of wanting to connect them, or says things like "my wiki feels disconnected" or "pages aren't linked well". This is a write-heavy skill — it actually modifies pages to add links, unlike wiki-lint which just reports issues.
> Scan the Obsidian wiki for page-level identity collisions — different pages covering the same concept under different names (e.g. "RSC" vs "React Server Components") — and merge them. Use this skill when the user says "dedup my wiki", "find duplicate pages", "merge duplicates", "identity resolution", "consolidate my wiki", "I have duplicate pages", or "my wiki has two pages for the same thing". Distinct from wiki-lint (which checks structure) and cross-linker (which adds links) — this skill makes destructive page-level merges and requires careful confirmation.
> Audit and maintain the health of the Obsidian wiki. Use this skill when the user wants to check their wiki for issues, find orphaned pages, detect contradictions, identify stale content, fix broken wikilinks, or perform general maintenance on their knowledge base. Also triggers on "clean up the wiki", "what needs fixing", "audit my notes", or "wiki health check". Add --consolidate to switch from for orphans, corrects lifecycle states, demotes stale peripheral pages, normalizes tag aliases, and adds contradiction callouts — all with a dry-run preview and explicit user confirmation before any writes.
Reviews an ADK integration documentation page (a Markdown file under docs/integrations/) or an integration pull request for correctness, structure, style, working code, valid links, and catalog conventions. Produces a prioritized review report, a recommended decision (approve, request changes, or close PR), a top-level review response, and draft line-anchored comments; only fixes issues when explicitly asked. Triggers on "integration-review", "review integration page", "review integration PR", "review this integration", "check integration docs".
Check and fix formatting and other issues in markdown files using markdownlint-cli2.
Take astro-han/karpathy-llm-wiki from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.