Karpathy Llm Wiki

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.

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 — heading # Knowledge Base Index, empty body
• wiki/log.md — 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 metadata header: source URL, collected date, published date.
• 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:

• Sources field: author, organization, or publication name + date, semicolon-separated.
• Raw field: markdown links to raw/ files, semicolon-separated.
• Relative paths from wiki/<topic>/ use ../../raw/<topic>/<file>.md (two levels up to project root).

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

• 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:

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.

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:

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

Claude Code Statusline Market Scan

Source: claude-pace project research

Collected: 2026-03-19 (market data as of 2026-03-19, GitHub stars verified via gh api)

Competitive Landscape

Plus 6+ npm packages: ccstatusline, @owloops/claude-powerline, @illumin8ca/claude-statusline, @chongdashu/cc-statusline, @sponzig/cc-statusline, @this-dot/claude-code-context-status-line.

Detailed Competitor Analysis

ccusage (11,693 stars) - Overall Strongest

• Positioning: CLI usage analysis tool, statusline is a sub-feature
• Statusline display: model, session cost, today cost, 5h block remaining time, burn rate, context usage
• Tech: TypeScript, default offline mode (cached pricing data), no network latency
• Advantages: Largest user base, broad feature coverage, active maintenance
• Diff from claude-pace: ccusage's burn rate shows trends, no predictive alerts; requires Node.js runtime

claude-hud (7,038 stars) - Pioneer

• Most features: context progress bar, rate limit usage, tool activity, subagent status, Todo progress, Git integration
• Usage API cache TTL 60s (success) / 15s (failure)
• Known issues: Cold start fails due to cold cache/API timeout (#214), 0-byte lock file permanent block (#220), Windows compatibility (#196)
• Not in awesome-claude-code list (29K stars, lists 5 statusline tools but excludes claude-hud)

Claude-Code-Usage-Monitor (7,009 stars) - Unmaintained

• Standalone terminal dashboard (not embedded statusline), Python implementation
• Strongest prediction: P90 ML + burn rate, using past 192 hours of history
• HN: 245 points / 135 comments, but code quality criticized ("vibe-coding style", main file 1000+ lines)
• Last update 2025-09-14, no active maintenance

ccstatusline (5,421 stars) - Customizable

• Positioned as "formatter", no API calls
• Powerline style, interactive TUI config, multiple themes
• npm distribution, performance determined by Node.js startup overhead

CCometixLine (2,227 stars) - Rust Performance

• Git integration, model display, usage tracking, interactive TUI config
• Only Rust solution in awesome-claude-code
• Documentation lacks specific ms performance numbers

Community Distribution Channels

awesome-claude-code currently lists 5 statuslines: CCometixLine, ccstatusline, claude-code-statusline, claude-powerline, claudia-statusline.

User Pain Points & Unmet Needs

Core Pain Point: Quota Opacity

1. Sudden limit hit with no warning - $200/month Max users hit limit in 10-15 minutes, only see "usage limit reached" (The Register, 2026-01-05) 2. Quota reset time invisible - 3 independent issues on same day 2026-03-18 requesting this (#35747, #35672, #35827) 3. 5h + 7d dual window cognitive load - Users confused about which limit they hit

Official Stance

• Explicitly rejected native token indicator: issue #10593 marked "Not Planned" (2026-01-19), recommends ccusage
• statusline stdin JSON doesn't expose quota fields: session_used_percentage, weekly_used_percentage, resets_at all missing
• Third-party tools must workaround via Usage API or parse local JSONL files

Other Requests

• Auto-resume task execution after limit hit (#18980, #26775, #35744)
• Push-based quota warning (alert at 80%) vs query-based (#35947)
• Cross-session cumulative usage tracking (#13891, #13892)

Tech Trends

• Migration from Node.js to lightweight runtimes: Rust (CCometixLine, claudia-statusline), Go (felipeelias), Shell (kamranahmedse, rz1989s, claude-pace)
• Zero-dep install as selling point: Go single binary, Bash script curl one-line install
• No public performance benchmarks: No tool has published hyperfine or equivalent ms-level benchmark numbers

User Feedback Analysis (2026-03-24补充)

Cross-session Daily Cost Summary - Best Feedback

ccusage's core value is "one command to see costs" and "verify if monthly fee worth it". Multiple independent reviews consistently list "cost visualization" as primary reason for choosing ccusage.

Context Progress Bar - Primary Install Motivation

Multiple independent sources agree: context bar is "install reason". SAP community author wrote "context bar alone is worth the install".

Rate Limit 5h/7d Visualization - Second Biggest Need

After v2.1.80, stdin provides official data, all tools have equal opportunity, differentiation shifts from "have or not" to "accurate or not".

Subagent Status Monitoring - Blog Hot, User Voting Weak

claude-hud's subagent monitoring listed as second value point by multiple blogs. But actual data doesn't support "strong demand" judgment:

• 6 subagent-related issues all 0 reactions
• All consecutive numbers, suspected maintainer or AI batch creation, not user-driven

Burn Rate / Consumption Rate - Competitors Already Failed

ccusage's Live Blocks feature (real-time token consumption monitoring) formally removed due to accuracy issues (issue #782). Issue #288 (16 reactions) and #483 (11 reactions) documented persistent user complaints about "shows not at limit but actually hit".

Zero Runtime Dependencies - Real Differentiator

ccusage statusline has severe process management bug (issue #459, 10 reactions, 17 comments): bun x ccusage statusline in hooks causes infinite process spawning, CPU 100%.

Multiple community authors explicitly list "reduce dependencies" as tool selection factor. Go/Rust single binary and pure Bash solutions' motivation includes this.

Feature Creep is Explicitly Warned Anti-pattern

• Ovidiu (Substack): "When everything is highlighted, nothing is"
• ccusage's Live Blocks from feature to removal is a live case study.

Contradictions & Uncertainties

1. Subagent monitoring demand strength contradiction: Blog authors highly rate vs GitHub issues 0 reactions. Possible explanation: Blog authors evaluate from feature completeness perspective, actual user voting reflects "most painful needs" 2. ccusage statusline user stickiness vs bug severity contradiction: Depended by multiple third parties (accuracy recognized), but most accuracy complaints. Possible: CLI reports accurate, statusline/live components inaccurate 3. claude-hud stars jumped from 7,038 (3/19) to 11,842 (3/24): 4,804 stars in 5 days, consistent with Trending effect

Competitor Feature Feedback Ranking

Conclusion

More valuable direction is not "add features competitors have", but "make existing features most accurate and reliable". ccusage's live blocks removed due to inaccuracy, claude-hud's 429 permanent warning bug, both show statusline competition focus shifted from "feature count" to "data accuracy and runtime reliability".

AI Coding Tools

Usage strategies, context management, multi-agent orchestration, and human-AI interaction best practices for AI coding tools.

Articles

Key Concepts

• Dual Quota Mechanism: Claude Max Plan's 5h rolling window and 7d weekly limit, controlling message count and equivalent API cost
• Context Degradation: When context window usage exceeds 70%, reasoning ability and instruction following全面下降
• Context Engineering: Designing workflows around context window utilization, not treating context management as副产品
• Subagent Isolation: Using independent context windows to isolate trial-and-error processes, trading total tokens for main context purity
• Compact Instructions: Specifying information retention priority during auto-compact, preventing architectural decisions等 key content loss
• Hooks: Lifecycle auto-trigger points, 25 event types + 4 execution types, implementing deterministic behavior control
• Three-Level Intervention Gradient: Intent declaration, small-step试探, proactive asking continuous spectrum, replacing binary yes/no questioning
• Four-Layer Progressive Explanation: Purpose layer, black-box layer, structure layer, detail layer, code explanation framework for zero-background users
• MCP Protocol Bridging: Connecting multiple AI coding CLIs via MCP protocol, loosely coupled but fixed token overhead
• Prompt Caching: Token reuse mechanism based on prefix hash, cache read only 0.1x price, normal session hit rate 92-99%
• Handoff: Codex App's official流程 for moving context and code between Local and associated Worktree at thread level, not arbitrary worktree switcher
• Permanent Worktree: Long-term保留的 worktree in Codex App, reused as independent project,适合 multi-thread持续工作
• Practical Bilingual Strategy: LLM working language allocation for bilingual developers, English for system-level content (CLAUDE.md, skills, subagents), Chinese preserved for interaction dialogue
• Language-Intensive vs Language-Light Tasks: MAPS evidence shows agentic long planning受语言影响大 (max 16% degradation), code and math tasks几乎不受影响
• Capability General ≠ Constraint General: Agent capabilities can cross-domain transfer (coding → tool calling), but harness must按领域重建, because each domain's consequence system根本不同
• Harness as Permission Upgrade Function: Agent capability upgrade本质上 is permission upgrade (file → browser → wallet), each level harness必须重写
• Mandate as Sandbox: Financial agent's constraint sandbox, defining budget/purpose/validity period, agent超出 mandate parts默认不可达
• Pre-Settlement Verification: Financial harness must把 verification前移到 settlement前, differentiating from code harness's post-execution verification
• Remote Compaction: Codex CLI's server-side path via /responses/compact for OpenAI provider, returning structured window not text summary, user messages原样保留, agent轨迹折叠为 Compaction { encrypted_content }
• Latent Understanding: OpenAI's official措辞 for encrypted_content semantics, explicitly stating "opaque and not intended to be human-interpretable",承载 density strictly higher than equivalent text summary
• Harness Training Loop: End-to-end training between compactor endpoint and codex model形成的 moat, harder for competitors to复刻 than pure model weights
• Ceremonialization: Instructions losing substance in long sessions, model claiming "verified" but actually未执行, meta-cognitive instructions最先衰减
• Anchor Bias: Model forming hypotheses in early rounds and not修正 even with contradictory evidence, multi-turn conversation average performance drops 39%
• Check/Ask/Flag Three-Level Routing: Checkable claims first check, user-intent-dependent first ask, both impossible flag as unverified; ask优先于 flag
• Brain/Hands/Session Decoupling: Managed Agents拆分 agent into three independent components (Claude + harness loop brain / sandbox and tools hands / append-only log session), each layer can independently fail and replace
• Meta-Harness: Agent runtime design not对具体 harness做假设, through minimal interfaces (execute / provision / wake / getSession / emitEvent / getEvents)让具体 harness implementations replaceable
• Session External Persistence: Treating session log as object living outside context window, harness通过 getEvents()按位置切片访问历史, avoiding compaction这类 irreversible keep-or-drop decisions
• Progressive Disclosure: AGENTS.md only as directory (约100行), pointing to docs/下 structured knowledge base,让 agent从小而稳定入口起步再按需深入, replacing "one big file塞所有指令" anti-pattern
• Agent Legibility: Information not accessible in agent runtime context等于不存在; Slack共识, Google Docs, oral约定必须落回 repo才能被 agent利用
• Entropy Garbage Collection: Agent-generated code会复制已有 patterns (含次优 patterns),需要周期性自动扫描偏差、开重构 PR的持续回收机制, analogous to GC
• Taste Invariants: Custom linter encoding architectural taste as mechanical rules, linter error messages直接写成 agent-readable repair guidance, implementing "encode once, execute globally"

Related Topics

• AI Research (Tool comparisons, personal developer practices; includes Capability-Alignment Paradox and Cyber-Driven Restricted Release related to Mythos Preview system card)
• Agent Deployment (Non-technical team deploying AI agents' real blockers, four-ring gap, 9 person/day/expert IT time limit. Complements OpenClaw Harness Stability and China AI Coding Agent Access: this topic from tool and harness perspective, agent-deployment from actual pushing tools to non-technical employees现场 perspective)
• LLM Knowledge Bases (Tool practices in knowledge base workflows)
• Open Source and Software Value (Code depreciation and open source value migration)
• GEO (GEO extending to agent economy: skill distribution as new distribution mechanism, to AI to People path, directly related to this topic's agent ecosystem and MCP discussions)

Related Sources

• Claude Code Documentation
• Anthropic Platform Docs
• Anthropic Research
• OpenAI Codex App Worktrees
• karpathy/autoresearch (Autonomous AI research loop, related analysis见 Reward Signal Quality and Autonomous Optimization Boundary)

Claude Code Statusline Tool Ecosystem

Source: claude-pace project research, 2026-03-19; 2026-03-24

Raw: raw/ai-coding-tools/2026-03-19-claude-code-statusline-landscape.md

Overview

Around Claude Code's opaque quota problem, the community has spawned over a dozen statusline tools, forming a rapidly evolving ecosystem. By mid-March 2026, competitive focus shifted from "feature count" to "data accuracy and runtime reliability", with zero runtime dependencies becoming a differentiation point.

Competitive Landscape (2026-03-19 Data)

Primary distribution channels:

• awesome-claude-code (29,014 stars): currently includes 5 statusline tools, excludes claude-hud
• Anthropic official plugin directory (12,653 stars): zero statusline entries

User Pain Points

Opaque Quota (Root Problem)

1. Sudden limit hit without warning: $200/month Max users hit limits in 10-15 minutes, only see "usage limit reached" 2. Invisible quota reset time: On 2026-03-18, 3 independent issues requested this feature on the same day 3. 5h + 7d dual window cognitive burden: Users can't distinguish which limit they're under

Officially Not Doing

Anthropic marked issue #10593 as "Not Planned" (2026-01-19), rejecting native token indicator, recommending ccusage. Meanwhile, statusline stdin JSON doesn't expose session_used_percentage, weekly_used_percentage, resets_at quota fields, forcing third-party tools to use Usage API or parse local JSONL files.

User Feedback Analysis

Best-Received Features

Context progress bar: Multiple independent sources consistently call it "install reason". SAP community author: "context bar alone is worth the install".

Cross-session daily cost summary: ccusage's core selling point, Japanese user community extensively documents "one command to see amount" experience. Multiple independent reviews list "cost visualization" as primary reason for choosing ccusage.

Rate Limit 5h/7d visualization: After v2.1.80, stdin provides official data, all tools have equal opportunity, differentiation space shifts from "having it" to "being accurate".

Pitfalls Already Hit

ccusage Live Blocks removed: Real-time token consumption monitoring was officially removed due to accuracy issues (issue #782). Issues #288 (16 reactions) and #483 (11 reactions) document persistent user complaints about "display shows under limit but actually hit limit".

ccusage process management bug (issue #459, 10 reactions): bun x ccusage statusline in hooks causes infinite process spawning, CPU 100%. This is structural risk from Node.js runtime.

claude-hud sub-agent monitoring: Blog authors highly praise it, but 6 subagent-related issues all have 0 reactions, suspected maintainer or AI bulk creation, not user-driven. This shows systematic bias between blog review perspective (feature completeness) and user voting (most painful needs).

Feature Creep Warning

Ovidiu (Substack): "When everything is highlighted, nothing is"

ccusage's Live Blocks from feature to removal全过程 is a live lesson: real-time features with inadequate accuracy反而 damage tool credibility.

Technical Trends

Migration from Node.js to lightweight runtimes:

• Rust: CCometixLine, claudia-statusline
• Go: felipeelias (single binary, minimal)
• Shell/Bash: kamranahmedse, rz1989s (curl one-line install)

Zero-dependency install as selling point: Multiple community authors list "reduce dependencies" as tool selection factor, Go single binary and pure Bash solutions' motivation both include this.

No public performance benchmarks: No tool has published hyperfine or equivalent ms-level benchmark numbers, this is unoccupied differentiation space.

Impact

Statusline track in March 2026 saw rapid growth (claude-hud gained 4,804 stars in 5 days, mainly GitHub Trending effect), but the track has become crowded. Real competitive advantage doesn't come from feature count, but from:

1. Data reliability: ccusage's live blocks removed due to inaccuracies, shows "accurate" is more important than "rich" 2. Zero dependencies: Node.js tools' process management bugs show runtime dependency is structural risk, not just installation inconvenience 3. Differentiated features: Unique core concepts (like pace tracking: is current speed enough) are more competitive than "me too" features

Features not worth pursuing: Sub-agent monitoring (data source not in stdin, actual user demand evidence insufficient), Multi-device data sync (high engineering complexity, weak demand evidence).

Wiki Log

<!-- Format: ## [YYYY-MM-DD] Action | Topic. Cascading updates use - Updated: sub-items -->

[2026-04-12] Update | content-strategy audience correction

• Target audience corrected from "IT/managers" to "personal knowledge workers" (ops/admin/assistant/marketing)
• Content perspective shifted from "deployer" to "user": not caring about installation, caring about time saved
• Second draft rewrite: from tool selection to specific efficiency scenarios (WeChat group → Lark table 2h → 10min)
• Updated: build-in-public-content-framework.md (audience section + ratio example + answer asset table), _index.md, draft files

[2026-04-12] Compile | content-strategy (new topic)

• Created articles/content-strategy/ topic, containing _index.md + build-in-public-content-framework.md
• Source: X account @AstroHanRay empirical data + wiki 7 articles cross-application (solo-developer-skills-2026, growth, karpathy-viral-product-analysis, traffic-channel-efficiency, geo-fundamentals, product-sense-and-restraint, opensource-tool-growth-patterns)
• Core finding: altruistic content has distribution, self-narrative doesn't; Xiaohongshu is gstack Build in Public main battlefield
• Action: deleted X pinned tweet (cat food thread, 0 engagement)

[2026-04-12] Update | Chunke GEO plan (Lark DiYndHeofovBUoxebYNcyd62nRf) supplemented based on complete conference minutes

• Scenario-type queries: 6 items upgraded from single-dimension to compound scenario descriptions ("just adopted 3-month kitten sensitive stomach...")
• Added attribution mechanism callout: UTM parameters + Tmall source survey + AI citation URL click tracking
• Updated annotation: noted 2026-04-12 based on 12 guest minutes supplement

[2026-04-12] Update | Yangzi GEO plan v1 supplemented based on complete conference minutes

• Source: articles/geo/ compiled conclusions + raw/geo/2026-04-12 newly added 9 guests
• Output: output/2026-04-08-yangzi-geo-plan-v1.md four changes
• Board proposal "opportunity" section: added "heavy-decision industries most suitable for priority GEO布局" + 8x growth data
• "How to judge success" section: added attribution mechanism (UTM/consultation source/400 phone同比), start after trial success
• B.3 scenario adaptation 6 questions: upgraded to compound scenario descriptions (multi-constraint叠加), matching AI search user intent expression
• C.1.1 content structure: added scenario-based content requirements (restore scenario → selection logic → product line落地)
• Appendix F success tier: attribution mechanism前置为 long-term budget application necessary condition

Examples from Real Wiki

This directory contains real files from a knowledge base maintained with karpathy-llm-wiki since April 2026.

Files

Raw vs Compiled Comparison

Raw source (2026-03-19-claude-code-statusline-landscape.md):

• Original research notes
• Unstructured content
• Metadata header (Source, Collected, Published dates)

Compiled article (claude-code-statusline-landscape.md):

• Structured sections (Overview, Competitive Landscape, User Pain Points)
• Tables synthesized from multiple sources
• Cross-references to other wiki articles
• Updated across multiple ingest operations

Operation Log

The log records every action:

• Compile — new article from source
• Update — cascade updates across related articles
• Lint — quality checks
• Query — archived query results

Recent activity shows daily maintenance: 87 entries in the last 7 days alone.

karpathy-llm-wiki

A reusable skill for building Karpathy-style LLM wikis with Claude Code, Cursor, Codex, and other Agent Skills tools.

    

<p align="center"> <img src="assets/karpathy-tweet.png" alt="Karpathy's tweet about LLM Wiki" width="560"> </p>

karpathy-llm-wiki packages Karpathy's LLM Wiki idea into one installable Agent Skills skill. Your coding agent ingests sources into raw/, compiles durable knowledge pages into wiki/, answers questions with citations, and lints the wiki for consistency.

What Is an LLM Wiki?

An LLM wiki is a knowledge system where the LLM maintains structured wiki pages instead of re-searching raw documents on every question. New sources are compiled into durable markdown pages, cross-references are updated over time, and answers cite the wiki pages that already contain the synthesized knowledge.

This skill gives you three operations:

See SKILL.md for the full skill specification.

LLM Wiki vs RAG

This skill is optimized for the wiki model: knowledge that improves over time instead of re-deriving relationships on every query.

Usage Stats

Based on a production knowledge base maintained daily since April 2026:

• 94 wiki articles across 13 topic directories
• 99 source materials ingested
• 87 operation log entries in the last 7 days

See examples/ for sample wiki pages, source files, and operation logs.

Install

npx add-skill Astro-Han/karpathy-llm-wiki

Works with any tool that supports the Agent Skills standard.

Quick Start

1. Ingest your first source

Give the skill a URL, a file, or pasted text:

"Ingest this article: https://example.com/attention-is-all-you-need"

The skill stores the source in raw/, then compiles or updates the right knowledge pages in wiki/.

2. Ask your wiki a question

"What do I know about attention mechanisms?"

The skill searches the wiki and answers with citations linking back to your markdown pages.

3. Keep the wiki healthy

"Lint my wiki"

Checks for broken links, missing index entries, stale cross-references, and related issues.

How the Workflow Works

The core idea from Karpathy: the LLM maintains the wiki while the human focuses on choosing sources and asking good questions.

your-project/
├── raw/            ← Immutable source material
│   └── topic/
│       └── 2026-04-03-source-article.md
├── wiki/           ← Compiled knowledge pages maintained by the LLM
│   ├── topic/
│   │   └── concept-name.md
│   ├── index.md    ← Global table of contents
│   └── log.md      ← Append-only operation log

Each new source can update multiple pages, strengthen cross-references, and record contradictions. That is what makes the wiki compound over time.

Tool Compatibility

This skill follows the agentskills.io open standard:

FAQ

What is the difference between an LLM wiki and a personal wiki?

An LLM wiki is maintained by the model. It updates summaries, cross-links, index entries, and contradictions as new material arrives. A normal personal wiki depends on manual editing.

What sources can I ingest?

Web pages, papers, blog posts, PDFs, markdown files, text files, and pasted text. The skill converts everything into markdown under raw/ and compiles it into wiki/.

Is this production-ready?

The workflow is based on a real knowledge base with 94 articles and 99 sources maintained daily since April 2026. The repo includes examples, templates, and a design spec.

Inspired By

Unofficial community implementation of the workflow from Karpathy's LLM Wiki idea. The value here is the reusable workflow, prompt structure, and battle-tested knowledge-compilation rules.

See also: lucasastorian/llmwiki, atomicmemory/llm-wiki-compiler.

License

MIT

{Title}

Sources: {Cited Article 1}; {Cited Article 2}

{Paths must be relative to this file: same-topic = filename only, cross-topic = ../other-topic/filename.md}

Archived: {YYYY-MM-DD}

Overview

{One paragraph summarizing the query and key findings.}

{Body Sections}

{The synthesized answer, lightly edited for wiki context. This page is a point-in-time snapshot; it will not be cascade-updated when source articles change.}

{OPTIONAL — include this section only when cross-references exist:}

See Also

{Cross-references to related wiki articles. Use relative links:

• Same topic: Other Article
• Different topic: Other Article}

{Title}

Sources: {Author1, YYYY-MM-DD; Author2, YYYY-MM-DD}

Raw: {source1}; {source2}

Overview

{One paragraph summarizing the key points of this article.}

{Body Sections}

{Synthesize a coherent structure from the source material. Do not copy source text verbatim; distill and reorganize. Use blockquotes sparingly for particularly important original phrasing.}

{OPTIONAL — include this section only when cross-references exist:}

See Also

{Cross-references to related wiki articles. Maintained during lint. Use relative links:

• Same topic: Other Article
• Different topic: Other Article}

Knowledge Base Index

{topic-name}

{One-line description of this topic.}

{another-topic}

{One-line description of this topic.}

{Title}

Source: {URL or origin description}

Collected: {YYYY-MM-DD}

Published: {YYYY-MM-DD or Unknown}

{Original content below. Preserve the source text faithfully. Clean up formatting noise (extra whitespace, broken HTML artifacts, navigation chrome), but do not rewrite opinions or alter meaning.}