[1]Skip to content 
[2]
[3](Toggle navigation)
Search Gists
[4][                    ]
[5] Search Gists
[6]All gists [7]Back to GitHub [8] Sign in [9] Sign up
[10]
[11] Sign in [12] Sign up
You signed in with another tab or window. [13]Reload to refresh your session. 
You signed out in another tab or window. [14]Reload to refresh your session. 
You switched accounts on another tab or window. [15]Reload to refresh your
session. [16] Dismiss alert
[17](Dismiss this message)
{{ message }}

Instantly share code, notes, and snippets.

[18]@karpathy

[19]karpathy/[20]llm-wiki.md

Created April 4, 2026 16:25

[21] Show Gist options

  • [22] Download ZIP

  • [23] Star 5,000+ (5,000+) You must be signed in to star a gist
  • [24] Fork 5,000+ (5,000+) You must be signed in to fork a gist

  • [25] Embed

    Select an option

    [26](Close)
      □ [27] Embed Embed this gist in your website.
      □ [28] Share Copy sharable link for this gist.
      □ [29] Clone via HTTPS Clone using the web URL.

    No results found

    [30]Learn more about clone URLs
    Clone this repository at <script src="https://gist.github.com/
    karpathy/442a6bf555914893e9891c11519de94f.js"></script>
    [31][<script src="https:/]
  • [32] Save karpathy/442a6bf555914893e9891c11519de94f to your computer and
    use it in GitHub Desktop.

[33] Code [34] Revisions 1 [35] Stars 5,000+ [36] Forks 5,000+
[37] Embed

Select an option

[38](Close)

  • [39] Embed Embed this gist in your website.
  • [40] Share Copy sharable link for this gist.
  • [41] Clone via HTTPS Clone using the web URL.

No results found

[42]Learn more about clone URLs
Clone this repository at &lt;script src=&quot;https://gist.github.com/karpathy/
442a6bf555914893e9891c11519de94f.js&quot;&gt;&lt;/script&gt;
[43][<script src="https:/]
[44] Save karpathy/442a6bf555914893e9891c11519de94f to your computer and use it
in GitHub Desktop.
[45]Download ZIP
llm-wiki
[46] Raw
[47] llm-wiki.md

LLM Wiki

[48] 

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent
(e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to
communicate the high level idea, but your agent will build out the specifics in
collaboration with you.

The core idea

[49] 

Most people's experience with LLMs and documents looks like RAG: you upload a
collection of files, the LLM retrieves relevant chunks at query time, and
generates an answer. This works, but the LLM is rediscovering knowledge from
scratch on every question. There's no accumulation. Ask a subtle question that
requires synthesizing five documents, and the LLM has to find and piece
together the relevant fragments every time. Nothing is built up. NotebookLM,
ChatGPT file uploads, and most RAG systems work this way.

The idea here is different. Instead of just retrieving from raw documents at
query time, the LLM incrementally builds and maintains a persistent wiki — a
structured, interlinked collection of markdown files that sits between you and
the raw sources. When you add a new source, the LLM doesn't just index it for
later retrieval. It reads it, extracts the key information, and integrates it
into the existing wiki — updating entity pages, revising topic summaries,
noting where new data contradicts old claims, strengthening or challenging the
evolving synthesis. The knowledge is compiled once and then kept current, not
re-derived on every query.

This is the key difference: the wiki is a persistent, compounding artifact. The
cross-references are already there. The contradictions have already been
flagged. The synthesis already reflects everything you've read. The wiki keeps
getting richer with every source you add and every question you ask.

You never (or rarely) write the wiki yourself — the LLM writes and maintains
all of it. You're in charge of sourcing, exploration, and asking the right
questions. The LLM does all the grunt work — the summarizing,
cross-referencing, filing, and bookkeeping that makes a knowledge base actually
useful over time. In practice, I have the LLM agent open on one side and
Obsidian open on the other. The LLM makes edits based on our conversation, and
I browse the results in real time — following links, checking the graph view,
reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the
wiki is the codebase.

This can apply to a lot of different contexts. A few examples:

  • Personal: tracking your own goals, health, psychology, self-improvement —
    filing journal entries, articles, podcast notes, and building up a
    structured picture of yourself over time.
  • Research: going deep on a topic over weeks or months — reading papers,
    articles, reports, and incrementally building a comprehensive wiki with an
    evolving thesis.
  • Reading a book: filing each chapter as you go, building out pages for
    characters, themes, plot threads, and how they connect. By the end you have
    a rich companion wiki. Think of fan wikis like [50]Tolkien Gateway —
    thousands of interlinked pages covering characters, places, events,
    languages, built by a community of volunteers over years. You could build
    something like that personally as you read, with the LLM doing all the
    cross-referencing and maintenance.
  • Business/team: an internal wiki maintained by LLMs, fed by Slack threads,
    meeting transcripts, project documents, customer calls. Possibly with
    humans in the loop reviewing updates. The wiki stays current because the
    LLM does the maintenance that no one on the team wants to do.
  • Competitive analysis, due diligence, trip planning, course notes, hobby
    deep-dives — anything where you're accumulating knowledge over time and
    want it organized rather than scattered.

Architecture

[51] 

There are three layers:

Raw sources — your curated collection of source documents. Articles, papers,
images, data files. These are immutable — the LLM reads from them but never
modifies them. This is your source of truth.

The wiki — a directory of LLM-generated markdown files. Summaries, entity
pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this
layer entirely. It creates pages, updates them when new sources arrive,
maintains cross-references, and keeps everything consistent. You read it; the
LLM writes it.

The schema — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex)
that tells the LLM how the wiki is structured, what the conventions are, and
what workflows to follow when ingesting sources, answering questions, or
maintaining the wiki. This is the key configuration file — it's what makes the
LLM a disciplined wiki maintainer rather than a generic chatbot. You and the
LLM co-evolve this over time as you figure out what works for your domain.

Operations

[52] 

Ingest. You drop a new source into the raw collection and tell the LLM to
process it. An example flow: the LLM reads the source, discusses key takeaways
with you, writes a summary page in the wiki, updates the index, updates
relevant entity and concept pages across the wiki, and appends an entry to the
log. A single source might touch 10-15 wiki pages. Personally I prefer to
ingest sources one at a time and stay involved — I read the summaries, check
the updates, and guide the LLM on what to emphasize. But you could also
batch-ingest many sources at once with less supervision. It's up to you to
develop the workflow that fits your style and document it in the schema for
future sessions.

Query. You ask questions against the wiki. The LLM searches for relevant pages,
reads them, and synthesizes an answer with citations. Answers can take
different forms depending on the question — a markdown page, a comparison
table, a slide deck (Marp), a chart (matplotlib), a canvas. The important
insight: good answers can be filed back into the wiki as new pages. A
comparison you asked for, an analysis, a connection you discovered — these are
valuable and shouldn't disappear into chat history. This way your explorations
compound in the knowledge base just like ingested sources do.

Lint. Periodically, ask the LLM to health-check the wiki. Look for:
contradictions between pages, stale claims that newer sources have superseded,
orphan pages with no inbound links, important concepts mentioned but lacking
their own page, missing cross-references, data gaps that could be filled with a
web search. The LLM is good at suggesting new questions to investigate and new
sources to look for. This keeps the wiki healthy as it grows.

Indexing and logging

[53] 

Two special files help the LLM (and you) navigate the wiki as it grows. They
serve different purposes:

index.md is content-oriented. It's a catalog of everything in the wiki — each
page listed with a link, a one-line summary, and optionally metadata like date
or source count. Organized by category (entities, concepts, sources, etc.). The
LLM updates it on every ingest. When answering a query, the LLM reads the index
first to find relevant pages, then drills into them. This works surprisingly
well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need
for embedding-based RAG infrastructure.

log.md is chronological. It's an append-only record of what happened and when —
ingests, queries, lint passes. A useful tip: if each entry starts with a
consistent prefix (e.g. ## [2026-04-02] ingest | Article Title), the log
becomes parseable with simple unix tools — grep "^## \[" log.md | tail -5 gives
you the last 5 entries. The log gives you a timeline of the wiki's evolution
and helps the LLM understand what's been done recently.

Optional: CLI tools

[54] 

At some point you may want to build small tools that help the LLM operate on
the wiki more efficiently. A search engine over the wiki pages is the most
obvious one — at small scale the index file is enough, but as the wiki grows
you want proper search. [55]qmd is a good option: it's a local search engine
for markdown files with hybrid BM25/vector search and LLM re-ranking, all
on-device. It has both a CLI (so the LLM can shell out to it) and an MCP server
(so the LLM can use it as a native tool). You could also build something
simpler yourself — the LLM can help you vibe-code a naive search script as the
need arises.

Tips and tricks

[56] 

  • Obsidian Web Clipper is a browser extension that converts web articles to
    markdown. Very useful for quickly getting sources into your raw collection.
  • Download images locally. In Obsidian Settings → Files and links, set
    "Attachment folder path" to a fixed directory (e.g. raw/assets/). Then in
    Settings → Hotkeys, search for "Download" to find "Download attachments for
    current file" and bind it to a hotkey (e.g. Ctrl+Shift+D). After clipping
    an article, hit the hotkey and all images get downloaded to local disk.
    This is optional but useful — it lets the LLM view and reference images
    directly instead of relying on URLs that may break. Note that LLMs can't
    natively read markdown with inline images in one pass — the workaround is
    to have the LLM read the text first, then view some or all of the
    referenced images separately to gain additional context. It's a bit clunky
    but works well enough.
  • Obsidian's graph view is the best way to see the shape of your wiki —
    what's connected to what, which pages are hubs, which are orphans.
  • Marp is a markdown-based slide deck format. Obsidian has a plugin for it.
    Useful for generating presentations directly from wiki content.
  • Dataview is an Obsidian plugin that runs queries over page frontmatter. If
    your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts),
    Dataview can generate dynamic tables and lists.
  • The wiki is just a git repo of markdown files. You get version history,
    branching, and collaboration for free.

Why this works

[57] 

The tedious part of maintaining a knowledge base is not the reading or the
thinking — it's the bookkeeping. Updating cross-references, keeping summaries
current, noting when new data contradicts old claims, maintaining consistency
across dozens of pages. Humans abandon wikis because the maintenance burden
grows faster than the value. LLMs don't get bored, don't forget to update a
cross-reference, and can touch 15 files in one pass. The wiki stays maintained
because the cost of maintenance is near zero.

The human's job is to curate sources, direct the analysis, ask good questions,
and think about what it all means. The LLM's job is everything else.

The idea is related in spirit to Vannevar Bush's Memex (1945) — a personal,
curated knowledge store with associative trails between documents. Bush's
vision was closer to this than to what the web became: private, actively
curated, with the connections between documents as valuable as the documents
themselves. The part he couldn't solve was who does the maintenance. The LLM
handles that.

Note

[58] 

This document is intentionally abstract. It describes the idea, not a specific
implementation. The exact directory structure, the schema conventions, the page
formats, the tooling — all of that will depend on your domain, your
preferences, and your LLM of choice. Everything mentioned above is optional and
modular — pick what's useful, ignore what isn't. For example: your sources
might be text-only, so you don't need image handling at all. Your wiki might be
small enough that the index file is all you need, no search engine required.
You might not care about slide decks and just want markdown pages. You might
want a completely different set of output formats. The right way to use this is
to share it with your LLM agent and work together to instantiate a version that
fits your needs. The document's only job is to communicate the pattern. Your
LLM can figure out the rest.

[62]Load earlier comments...
[63]@frankchu91

[64]frankchu91 commented [65]Jul 18, 2026 •
edited
Loading

Uh oh!

There was an error while loading. [66]Please reload this page.

Copy link
Copy Markdown

MindBase — an open-source implementation of this post (MCP server, MIT)

Built this over the past few months: [67]https://github.com/frankchu91/mindbase

[68]MindBase web UI — the LLM-maintained context.md of a research project

Mapping to the three layers as specced:

  • Raw sources → sources/ is append-only, enforced by tooling rather
    than convention: each operation runs as a sub-agent with a strict tool
    allowlist — the builder agent has no file-write tool at all, only an
    atomic-write MCP call that snapshots context.md before replacing it.
  • The wiki → LLM-maintained markdown with [[wikilinks]], plus a typed
    link index (sqlite, derived state — markdown stays the source of truth):
    edges carry contradicts/supersedes/mentions, so lint can proactively
    surface "this new source contradicts what you wrote in March."
  • The schema → a per-project README.md the LLM re-reads at every
    operation; user-editable, co-evolves with the wiki.

All three operations are in — a day looks like:

/mb:contribute paper.pdf → sub-agent reads, discusses 3 takeaways, waits
for approval, then updates 5-15 wiki pages
/mb:ask "my stance on X?" → cited answer from the already-synthesized wiki
/mb:lint → contradictions · orphans · stale claims · gaps

Works in any MCP client (Claude Code / Cursor / Windsurf / Cline):
npx -y mindbase-mcp. All local markdown — you can open the data dir
straight in Obsidian.

One finding for the drift discussion in this thread: the biggest drift
reducer for us wasn't better prompts — it was making the layer contract
physically unviolable via tool boundaries. A sloppy LLM turn can't
corrupt the sources layer even in principle, so drift stays confined to
the wiki layer, where lint can catch it.

Happy to compare notes with the other implementations here.

Sorry, something went wrong.

Uh oh!

There was an error while loading. [71]Please reload this page.

[72]@sturlese

[73]sturlese commented [74]Jul 19, 2026

Copy link
Copy Markdown

I looked at a lot of personal second brains before building this one, and
bounced off most of them for the same two reasons: I could never tell what the
system was actually doing, and getting started meant installing a stack. I
wanted something simple enough that I always know exactly what happens when,
and that asks you to install as little as possible.

That constraint produced the design:
[75]https://github.com/sturlese/hippocampus

No vector database, no embeddings, no MCP server, no Obsidian plugins, no
dependencies. Markdown, one stdlib Python linter, one shell hook, git.

Retrieval is three reads instead of a similarity search: a 500-word
working-memory cache injected at session start, then the master index (one line
per page), then the three to five pages it points to. Grep as fallback.

Every step is a file you can open and read.

That's the part I care about most. A missed lookup is a bad line in index.md —
visible, editable. With embeddings you get a number, and the cause could be a
chunk boundary, a stale index or an unlucky neighbour, none of which you can
see.

It stops working somewhere in the low thousands of pages, when the index no
longer fits in context.

I wrote up the whole pipeline step by step, in case the approach is useful even
without the tool:
[76]https://github.com/sturlese/hippocampus/blob/main/docs/
what-happens-when-you-ingest.md

Sorry, something went wrong.

Uh oh!

There was an error while loading. [79]Please reload this page.

[80]@lucianfialho

[81]lucianfialho commented [82]Jul 19, 2026

Copy link
Copy Markdown

Built a variant of this pattern backed by Neo4j instead of markdown — same
three layers (immutable Source nodes / a Concept+Claim graph / a
schema-as-constraints), but cross-references become real typed edges you can
run graph algorithms on.

Benchmarked the two things that actually matter instead of just shipping a
demo:

Entity resolution: 45 labeled mention pairs (same-entity / related-but-distinct
/ unrelated), real embeddings. A single cosine threshold doesn't work —
related-but-distinct pairs often score higher than true synonyms (best F1 =
0.667). A two-stage pipeline instead — cheap embedding filter for candidates,
then one real LLM judgment call per candidate ("same entity or just related?")
— got F1 to 1.000 on the same pairs.

Graph vs flat RAG on multi-hop questions: small real-facts corpus, 6 questions
each needing 2-3 connected documents. Flat RAG (top-k) covered 4/6; graph
traversal (N hops over typed edges) covered 6/6. Caveat: on this small dense
corpus the traversal's recall win came with a precision cost (pulled 5-6 of 8
docs on 3 of 6 questions) — not tested at scale.

Full pattern, corpus, labeled pairs, and the chart: [83]https://gist.github.com
/lucianfialho/44034e0d02a2bfccca2ad6358bde1dff

Sorry, something went wrong.

Uh oh!

There was an error while loading. [86]Please reload this page.

[87]@bprice1000

[88]bprice1000 commented [89]Jul 19, 2026

Copy link
Copy Markdown

I’ve been applying lmm_wiki as a heavy influence in creating a CMMS; Manage
assets, resources, build metrics, feed them with real time signals or data
gathered from procedures, build fully fleshed unscheduled/preventable
maintenance/upkeep plans, and create issues against any of the entities; All
while being fully greppable, levering markdown in multiple ways, requiring no
database or license. Llm_wiki is a great influence for a cmms as the systems
themselves are relatively low event.

Flattest. 1st principles. The assets don’t have logs, they are logs with
fields, the resources are counts, etc.

I just wanted to share the index file I am using inside of my project. Perhaps
it shows how the schema aspect of the concept can be heavily expanded and most
concepts on display held through testing during an earlier second iteration.
Third iteration maybe in testing next month.

[90]https://gist.github.com/bprice1000/f986547dda0a82c5178faa6e237247fe

Sorry, something went wrong.

Uh oh!

There was an error while loading. [93]Please reload this page.

[94]@umezy

[95]umezy commented [96]Jul 20, 2026 •
edited
Loading

Uh oh!

There was an error while loading. [97]Please reload this page.

Copy link
Copy Markdown

[98]@geetansharora asked on day one how to share one of these with a team — the
answers so far have been "serve the vault over MCP." We've been running a
different, git-native answer for a few months, so here are some notes from
actually operating it.

Context: we build on a niche SDK that models happily hallucinate APIs for, so
the wiki layer (synced official docs + our own verified tips) is not optional
for us. It's a lighter take on the pattern than the gist describes — the LLM
acts more as searcher than librarian, and the compiled layer is human-verified
tips and SKILL.md procedures rather than an LLM-maintained wiki. The part that
turned out to be interesting is distribution: that compiled layer replicates to
every teammate's agent on git pull.

The repo itself is the deployment. No MCP server, no RAG index, no sync
service. One git repo with two layers: sources/ (the wiki: synced official
docs, API references, tips) and skills/ (the agency side: SKILL.md packages,
including the search skills that query sources/). A one-time setup command
links each skill into ~/.claude/skills (symlinks; junctions on Windows), and a
post-merge hook re-runs the sync — so daily operation for everyone on the team
is literally git pull.

Notes from living with it:

  • Working copy = live instance changes behavior. The linked skills point into
    each member's checkout, so editing a skill + git push is the entire publish
    flow. The unexpected outcome: our designers — not engineers — started
    pushing skills. The contribution barrier is "edit a markdown file," and
    that turned out to be low enough for non-engineers.
  • Retrieval stayed a skill in the repo, not a service. The template ships a
    ranked-grep search skill (generate keyword variants → grep sources/ → rank
    the hits). In our team repo we also run a hybrid semantic skill — embedded
    Chroma + a local multilingual MiniLM, RRF-fused with the grep results,
    index rebuilt incrementally by the skill itself — and honestly that's the
    one I reach for most: for natural-language "how do I…" queries over our
    (mostly Japanese) docs it beats keywords. So my data point for the
    grep-vs-RAG debate isn't "grep wins" — it's that at hundreds of pages, both
    flavors of retrieval fit inside the repo as skills, with nothing to host.
  • A failure worth writing down: we first tried a shared .claude/ in a parent
    folder above all projects. Claude Code doesn't pick it up for the
    git-managed projects underneath it. Per-skill links into ~/.claude/skills
    was the reliable path.

Template (MIT): [99]https://github.com/umezy/team-ai-workflows

Sorry, something went wrong.

Uh oh!

There was an error while loading. [102]Please reload this page.

[103]@suwonleee

[104]suwonleee commented [105]Jul 20, 2026

Copy link
Copy Markdown

Reading down this thread, nearly every tool here — mine included — exists to
keep the model's memory current. But the pattern puts the judgment on the
human: "you're in charge of sourcing, exploration, and asking the right
questions." Nothing in it keeps that side from decaying. Your wiki stays
current; your memory of why you decided things doesn't.

So I built the other half of the loop. The wiki quizzes you back — day-granular
spaced repetition (1·3·7·16·35·60) over the decision and insight pages only,
since those are the ones whose why rots. It's the one part of the system that
spends your time instead of saving it.

Two things I didn't expect while building it:

Citations don't survive leaving your machine. A footnote pointing at
session-abc.jsonl is provenance for exactly one person. Pages now carry 1–2
verbatim lines of the evidence inline — secret-screened, because transcripts
really do contain credentials — so a teammate gets the grounding and not just
the conclusion.

Indexing that evidence made pages harder to find. BM25 length normalization:
the excerpt lengthens the page's own chunk, which lowers its score for its own
topic. Excluding excerpts from the index put recall@5 back to baseline.

Markdown as the source of truth, local-first, no MCP, no build step. Works with
Claude Code / Codex / OpenCode.

[106]https://github.com/suwonleee/llmwiki

("llmwiki" is a crowded name in this thread — this is the one with the quiz.)

[107][social-preview]

Sorry, something went wrong.

Uh oh!

There was an error while loading. [110]Please reload this page.

[111]@kytmanov

[112]kytmanov commented [113]Jul 20, 2026 •
edited
Loading

Uh oh!

There was an error while loading. [114]Please reload this page.

Copy link
Copy Markdown

Synto v0.7.0 is out - 200★

[115]https://github.com/kytmanov/synto

Main addition: concept relations. Opt-in on ingest - the model extracts links
between known concepts (e.g. Raft depends_on Consensus) with a short evidence
quote. Packs ship the graph as graph/graph.json. Queries follow one hop to pull
in related articles.

Also new in v0.7:

• reverse lookup: synto find ranks concept names, then titles, then body text.
• provenance: synto trace shows where a term shows up in sources, or which
articles used a source segment.
• fix a wrong alias without a merge: synto concept alias add|remove|move.
• silence known lint noise: ack advisories in synto.toml so they stop
cluttering maintain.

Same shape as before:

• works with local LLMs
• great with Ollama and LM Studio
• plain Markdown
• Obsidian-friendly
• no vector DB
• no cloud required
• multi-language

Star it if you want to support local-first AI tools. Fork it if you want to
build on it.

Sorry, something went wrong.

Uh oh!

There was an error while loading. [118]Please reload this page.

[119]@Sarthib7

[120]Sarthib7 commented [121]Jul 20, 2026 •
edited
Loading

Uh oh!

There was an error while loading. [122]Please reload this page.

Copy link
Copy Markdown

CItadel 0.3.0

This clicked hard — especially the contrast with RAG-as-rediscovery and the
three-layer split (immutable sources → LLM-maintained wiki → schema). I've been
running a team version of the same idea, and it maps cleanly onto your ingest/
query/lint loop.

For a personal wiki, your Obsidian + git + index.md approach is hard to beat at
moderate scale. For a team, we hit different walls: who owns writes, what gets
shared vs stays draft, semantic drift when five agents touch the same "entity
page," and capture that can't depend on someone remembering to ingest after
every meeting.

We built [123]Citadel as that team layer — an Organization Vault on Cognee
(Apache-2.0). It's not "markdown in a folder" (though markdown/Obsidian still
fit as sources and UI):

Node (seat:{slug}): private working memory; default target for autonomous
capture (git pre-push + session hooks, fail-silent)
Central: shared org memory; read-only for seats, evolves via governed promotion
+ org sync (GitHub/Linear digests)
MCP + CLI: agents search before coding; citadel_search replaces "read index.md
first" at scale
Lint-ish: open Knowledge Conflicts instead of silently merging contradictions
Re [124]@geetansharora team question: we did end up at MCP, but over a
maintained vault rather than a static RAG index — closer to your wiki
compounding than chunk retrieval.

Repo + docs:

[125]https://github.com/masumi-network/Citadel
Connect an agent (MCP setup): [126]https://
citadel-archive-production.up.railway.app/skills/connect
Install the agent skill: npx skills add masumi-network/Citadel-Archive
Would love to see a future where a Karpathy-style personal git wiki can promote
curated pages into an org Central. Citadel is the org half today; the personal
half still looks a lot like this gist.
[127]Screenshot 2026-07-22 at 11 44 42

Sorry, something went wrong.

Uh oh!

There was an error while loading. [130]Please reload this page.

[131]@gavischneider

[132]gavischneider commented [133]Jul 20, 2026

Copy link
Copy Markdown

I've been documenting everything LLM Wikis for the past 2+ months: [134]https:/
/github.com/gavischneider/awesome-llm-wiki

If you'd like your implementation/tool/guide/article to be added, PRs are
welcome.

Sorry, something went wrong.

Uh oh!

There was an error while loading. [137]Please reload this page.

[138]@rath-muth

[139]rath-muth commented [140]Jul 21, 2026

Copy link
Copy Markdown

I'm a beginner in exploring Claude and LLMs. I'm trying to find the original
copy of Karpathy's base prompt to feed it to my LLM agent to set up the system,
I don't see it in the original post. Am I misunderstood something? or can
someone help guide me by providing a prompt to start with?

Sorry, something went wrong.

Uh oh!

There was an error while loading. [143]Please reload this page.

[144]@frankchu91

[145]frankchu91 commented [146]Jul 22, 2026

Copy link
Copy Markdown


    I'm a beginner in exploring Claude and LLMs. I'm trying to find the
    original copy of Karpathy's base prompt to feed it to my LLM agent to set
    up the system, I don't see it in the original post. Am I misunderstood
    something? or can someone help guide me by providing a prompt to start
    with?

there is no official prompt from Karpathy. Try this git repo here: [147]https:/
/github.com/frankchu91/mindbase

Sorry, something went wrong.

Uh oh!

There was an error while loading. [150]Please reload this page.

[151]@alfadur7

[152]alfadur7 commented [153]Jul 22, 2026 •
edited
Loading

Uh oh!

There was an error while loading. [154]Please reload this page.

Copy link
Copy Markdown

"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
Taking that line literally is what made this click for me — if the wiki is a
codebase, the discipline the AI-coding world is building around agents
transfers. That discipline is harness engineering: everything around the agent
— its checks, its review, the rules themselves — treated as the real
engineering surface, organized as three nested loops. ([155]Dru Knox of Tessl)

Each loop has a distinct job here:

Inner — the agent checking itself while drafting, before you see anything. You
note a source "might touch 10-15 wiki pages," and that you "could also
batch-ingest many sources at once with less supervision." The inner loop is
what makes that second option safe.

Outer — review where a draft becomes part of the wiki. Right now that's you: "I
read the summaries, check the updates, and guide the LLM on what to emphasize."
Automating it takes two things a self-check can't do: deterministic checks
across the whole wiki rather than the page in hand (your lint list, but at
publication instead of "periodically"), and a fresh-eyes read by an agent that
didn't write the page and can't see the writer's reasoning.

Meta — the schema is what this loop edits. "You and the LLM co-evolve this over
time" is already it; the mechanical version is that a defect caught twice
becomes a rule, so you stop re-teaching it every session.

Then the analogy breaks. Shipped code stays correct until the spec changes;
knowledge doesn't. You already name the requirement — the wiki is "compiled
once and then kept current" — and lint lists "stale claims that newer sources
have superseded" right next to orphan pages and missing cross-references. But
those are defects in the work; staleness is the world moving. Keeping a wiki
current needs a fourth loop of its own, with published pages fed back in as
input.

I wrote up [156]the 4-loop Knowledge Factory in full — a design argument, not a
measured result.

[157]image

Sorry, something went wrong.

Uh oh!

There was an error while loading. [160]Please reload this page.

[161]@ErikEvenson

[162]ErikEvenson commented [163]Jul 24, 2026 •
edited
Loading

Uh oh!

There was an error while loading. [164]Please reload this page.

Copy link
Copy Markdown

The additions that turn Karpathy’s sketch into something you can still trust
after a few thousand pages:

[165]https://www.erikevenson.net/building-an-llm-wiki-part-2.html

Sorry, something went wrong.

Uh oh!

There was an error while loading. [168]Please reload this page.

[169]@ibehnam

[170]ibehnam commented [171]Jul 24, 2026

Copy link
Copy Markdown


    The additions that turn Karpathy’s sketch into something you can still
    trust after a few thousand pages:

    [172]https://www.erikevenson.net/building-an-llm-wiki-part-2.html

The article reads like AI slop.

Sorry, something went wrong.

Uh oh!

There was an error while loading. [175]Please reload this page.

[176]@denson

[177]denson commented [178]Jul 25, 2026

Copy link
Copy Markdown

Storing as OO-LD json seems to work well for at least up to 10k documents.

    This resonates strongly - and I'd push one layer deeper on why the
    bookkeeping gets abandoned. In our experience the thing that doesn't scale
    is unqualified links + free text. A lovingly hand-maintained personal wiki
    decays into prose and dead links within a couple of years; a team or
    corporate one gets there faster. What actually compounds is structure -
    typed entities you can query, not paragraphs you have to re-read.

    We took a structured variant of exactly this pattern into production about
    five years ago, on Semantic MediaWiki. Using MediaWiki's content-slot
    feature, every article keeps its unstructured body and a structured JSON
    slot side by side. The JSON slot's shape is defined by the article's
    category/categories, and each category carries a JSON Schema in its own
    slot - so one schema drives both auto-generated edit forms for humans and
    machine editing for everything else.

    Putting JSON-LD on top (we specced this as [179]OO-LD: one document that is
    simultaneously a JSON Schema and a JSON-LD context) turns the whole wiki
    into an RDF knowledge graph for free - you can run SPARQL across every
    entry. Your lint step (contradictions, orphans, missing cross-refs) becomes
    graph queries; query becomes structured retrieval, not just text search.

    When LLMs with JSON-Schema-driven structured output arrived, it was a
    drop-in fit: the exact schemas that render the forms also constrain LLM
    extraction.

    Mapping to your three layers: raw sources (immutable) / the wiki - but as
    typed, linkable entities rather than markdown / the schema - a JSON Schema
    per category rather than one prose config.

    Where we're putting research effort now is precisely your ingest loop at
    scale: take an unstructured knowledge chunk -> select the right schema(s)/
    categories to represent it -> fill them correctly and dedup against
    entities that already exist. That last "and" - entity resolution against a
    live graph - is the hard part; it's your lint moved to write-time.

    Curious whether others here have pushed on write-time dedup - that's where
    the pattern either compounds or sprawls.

    Reference implementation: [180]OpenSemanticLab (live demo: [181]https://
    demo.open-semantic-lab.org) · schema approach: [182]OO-LD.

Sorry, something went wrong.

Uh oh!

There was an error while loading. [185]Please reload this page.

[186]@akash07k

[187]akash07k commented [188]Jul 25, 2026

Copy link
Copy Markdown

[189]@frankchu91
Wow, it's really fantastic!
I read on your repo:

    still in v1 → v2 migration.

So, when are you planning to migrate it to V2?

    there is no official prompt from Karpathy. Try this git repo here: [190]
    https://github.com/frankchu91/mindbase

Sorry, something went wrong.

Uh oh!

There was an error while loading. [193]Please reload this page.

[194]@bollakarthikeya

[195]bollakarthikeya commented [196]Jul 26, 2026 •
edited
Loading

Uh oh!

There was an error while loading. [197]Please reload this page.

Copy link
Copy Markdown

This idea is very powerful and it resonates so deep with what I have been going
through; a running inventory of knowledge that is constantly updated with the
new incoming sources of information. Since I am an avid note taker and since it
is nearly impossible to constantly sieve through the many hand-written pages,
this idea - a knowledge wiki that is constantly evolving - is what I need.
Thank you Andrej for this brilliant idea. Kudos to you!

Sorry, something went wrong.

Uh oh!

There was an error while loading. [200]Please reload this page.

[201]@gowtham0992

[202]gowtham0992 commented [203]Jul 28, 2026

Copy link
Copy Markdown

Link 2.0.0 is out: the memory layer got a face.

LinkBar puts the review gate in your menu bar. Session hooks already captured
memory automatically; the missing half was reviewing it without going anywhere.
Now a capture lands and you get a native notification with a one-tap Accept,
showing the exact line it will save.

[204]linkbar-tour

The part I use most is the palette. Hit Option-Command-M anywhere on the
machine and a floating bar opens over whatever app you're in: type a question
to recall from your memory, or start with + to remember something. It's
review-gated like every other write. I stopped switching to a terminal to ask
my own memory things, which turned out to be the whole point.

[205]image

There's also a live pulse of which agent sessions are writing right now, a
browser over every memory file with supersede lineage, and a status tab showing
whether the CLI, workspace, MCP, hooks, recall tier, and viewer are actually
healthy, each with a one-click fix that verifies it worked instead of just
claiming success.

The whole app is a thin SwiftUI client over lnk --json. No new backend, no new
API, nothing new to trust: it runs the same reviewed commands as the CLI, so
the app can never drift from what Link actually does.

No breaking changes. Every CLI command, MCP tool, hook, and memory file from
1.7 works exactly as before; the major version marks the app's debut, not an
API break.

Still: wiki as the storage layer, every memory a file you can open, nothing
durable without review.

brew upgrade link                                # CLI 2.0.0
brew install --cask gowtham0992/link/linkbar     # the menu bar app

Release notes: [206]https://github.com/gowtham0992/link/releases/tag/v2.0.0

Repo: [207]https://github.com/gowtham0992/link
Site: [208]https://gowtham0992.github.io/link/
PyPI: [209]https://pypi.org/project/link-mcp/
MCP: [210]https://registry.modelcontextprotocol.io/?q=
io.github.gowtham0992%2Flink

Sorry, something went wrong.

Uh oh!

There was an error while loading. [213]Please reload this page.

[214]@XBlueSky

[215]XBlueSky commented [216]Jul 29, 2026

Copy link
Copy Markdown

Update from my earlier comment here: I originally shared Cortexes when it was
still an early workflow for collaboratively distilling Claude Code
conversations into a Markdown vault.

Since then, it has grown into an open-source, installable Claude Code plugin,
currently at v1.1.0:

[217]https://github.com/XBlueSky/cortexes

A few things I learned while turning the idea into something I use across real
coding sessions:

Capturing everything is easy; deciding what deserves to become knowledge is the
harder problem.

Cortexes now captures sessions automatically, but filters low-value tool output
before writing them into the Raw layer. Distillation is map-first and
context-budgeted, so a long session can be processed in bounded spans without
loading the entire transcript into the context window.

The more important part for me is maintenance. Newly distilled findings do not
always become new notes. The broadcast workflow can fuse them into related
existing pages, correcting assumptions and adding caveats. This is my attempt
to address knowledge rot rather than simply accumulating more memory.

Recall now uses hybrid BM25 + vector retrieval with reciprocal-rank fusion,
including mixed Chinese/English technical queries and a BM25-only fallback when
offline.

The durable artifact is still plain Markdown + Git. The vault can be opened
directly in Obsidian, so the agent’s memory remains readable, editable,
diffable, and reversible rather than hidden inside a vector database.

I now think of Cortexes less as a memory store and more as a maintenance
pipeline:

capture → distill → fuse → retrieve

Project: [218]https://github.com/XBlueSky/cortexes

Interactive overview: [219]https://cortexes.pages.dev/

I would be interested in feedback from people who have run an LLM-maintained
wiki over time: what policies or checks have been most effective at preventing
stale or contradictory knowledge from quietly accumulating?

Sorry, something went wrong.

Uh oh!

There was an error while loading. [222]Please reload this page.

[223]@GeraldGrootRoessink

[224]GeraldGrootRoessink commented [225]Jul 29, 2026

Copy link
Copy Markdown

I agree with the motivation (using an LLM to maintain a persistent, compounding
artifact as a “knowledge view”), but I’m skeptical of proposals that treat
Markdown front-matter as the semantic backbone. We need something
machine-executable: a precise way to define semantics, data selection, joins/
mappings, and provenance for the resulting view. Human-oriented formatting from
Markdown isn’t essential for that; an LLM can generate presentation at the end.

Much of the relevant infrastructure already exists in the Semantic Web: HTTP,
URIs, RDF, and SPARQL, plus established linked data vocabularies. So the gap is
less about inventing a new container and more about producing view ready
outputs in a repeatable, automated way.

My conclusion: the key missing piece is not a new metadata container format,
but a reliable, machine executable way to build and maintain an LLM ready
“knowledge view” from multiple sources.

Sorry, something went wrong.

Uh oh!

There was an error while loading. [228]Please reload this page.

[229]@suwonleee

[230]suwonleee commented [231]Jul 29, 2026

Copy link
Copy Markdown

Follow-up to my earlier comment here (the project wiki that quizzes you back) —
since then the interesting problems have all been trust boundaries, the kind
that only show up once the thing runs on machines that aren't yours:

A clone is not consent. Early versions treated git clone + setup as permission
to start capturing sessions. It isn't. Everything is now inert until you enroll
a repository explicitly, and until a session is known to belong to an enrolled
repo, the capture layer reads exactly two routing fields from a transcript and
stops — fail closed, by budget.

The installing agent is your least-trusted user. On a nonstandard machine, the
agent doing the install is also the thing searching your disk for where Claude
Code / Codex / OpenCode keep their data. So discovery became three-tier:
deterministic resolution → schema-signature verification (a candidate is judged
by what's inside — transcripts, rollouts, a session table — never by its name;
the E2E that motivated this watched a plain home directory pass as a Claude
profile because it contained a folder called projects/) → and only then
persistence, which the engine refuses unless verification passed. And a
connected location stays read-only forever: capture reads from it, install
wiring never writes into it.

Models are observed, not declared. The engine shipped with a hardcoded model id
for its generative passes; it had gone stale by the time the replacement landed
— the argument making itself. Now a pass runs on whatever model the session
actually recorded (every harness already writes this), with per-harness
fallbacks only when nothing was observed. The follow-up lesson cost a day: the
first id-validation regex rejected llama3.1:8b, and an over-strict guard fails
exactly like a stale constant — silently.

Still markdown as the source of truth, local-first, no MCP, no build step,
three harnesses.

[232]https://github.com/suwonleee/llmwiki — if any of this is useful to you, a
star genuinely helps others in this thread find it among the many llmwikis.

[233][social-preview]

Sorry, something went wrong.

Uh oh!

There was an error while loading. [236]Please reload this page.

[237]@antondziatkovskii

[238]antondziatkovskii commented [239]Jul 29, 2026

Copy link
Copy Markdown

One failure mode this pattern has that plain RAG doesn't — and a measurement of
it.

A compiled wiki answers more confidently than raw retrieval. That's the point
of it. But confidence gets decoupled from whether the answer is actually in
there, and in an incrementally compiled wiki that compounds: a confident
fabrication gets filed back as a page, and then it is a source.

I measured this on my own vault (~4 months of ingested sources, e5 embeddings +
a reranker on top). 6 questions — 3 with answers in the wiki, 3 deliberately
outside it — looking at the top rerank score of each result set:

               question                 in the wiki? top rerank score
our rule on treating a cause as a claim yes          +8.66
how we sync machines                    yes          +5.87
our memory-layer decision               yes          +1.57
my pizza recipe                         no           −1.03
bus fare in Kuala Lumpur                no           −3.82
max depth of the bathyscaphe Trieste    no           −4.53

Clean separation — worst "in" beats best "out" by 2.6, no overlap, natural
cutoff at 0.

The part that actually mattered: all six queries returned exactly 12 hits. The
bathyscaphe question got 12 confident notes out of a personal vault that has
never heard of bathyscaphes. Nothing anywhere in the output said "I found
nothing." There was no threshold in the code at all — the reranker computed the
score and then it was thrown away.

Honest limits: n=6, I picked the questions, and the "out" ones are far from my
domains. This shows the signal exists; it does not show where the threshold
belongs. The dangerous case — a question from a domain adjacent to the wiki —
is untested. Running it in shadow for a week, logging the top score of every
real query without cutting anything, before wiring an actual cutoff.

Concrete suggestion for the schema layer (CLAUDE.md / AGENTS.md), since that's
where this belongs rather than in code: a rule that the agent must say "the
wiki has no confident answer on this" instead of synthesizing from
low-relevance hits — and that such an answer is never filed back.

Retrieval layer this came out of, if useful: [240]https://github.com/
Palo-Alto-AI-Research-Lab/sqlite-graph-memory — Graph RAG on SQLite over an
Obsidian vault, [[wikilinks]] as the graph. The citation-checking half is
separate: [241]https://github.com/Palo-Alto-AI-Research-Lab/
verbatim-citation-gate

Sorry, something went wrong.

Uh oh!

There was an error while loading. [244]Please reload this page.

[245]@Nikalo71

[246]Nikalo71 commented [247]Jul 30, 2026

Copy link
Copy Markdown

Voici un Gist très très utile, merci beaucoup pour votre travail et votre
partage.

Sorry, something went wrong.

Uh oh!

There was an error while loading. [250]Please reload this page.

[251]@JanYork

[252]JanYork commented [253]Jul 31, 2026

Copy link
Copy Markdown

I've implemented a small version, and I think it's pretty good.

If you're interested, you can check it out at [254]https://github.com/JanYork/
llm-wiki-cli

Sorry, something went wrong.

Uh oh!

There was an error while loading. [257]Please reload this page.

[258]@Nikalo71

[259]Nikalo71 commented [260]Jul 31, 2026

Copy link
Copy Markdown

Thanks again for this work. It's perfect and I'm sure it will help many people.
I created the Claude.MD file so it's in French and everything seems to be
working very well.

One technical question, though: I'm using Claude in VS Code.
My question (being a complete beginner with this kind of tool) is whether it's
necessary or optional to create a Wordspace for this project?

Sorry, something went wrong.

Uh oh!

There was an error while loading. [263]Please reload this page.

[264]@Nikalo71

[265]Nikalo71 commented [266]Jul 31, 2026

Copy link
Copy Markdown


    I've implemented a small version, and I think it's pretty good.

    If you're interested, you can check it out at [267]https://github.com/
    JanYork/llm-wiki-cli

Thank you fore sharring !

Sorry, something went wrong.

Uh oh!

There was an error while loading. [270]Please reload this page.

[271]@alexadamus77-ui

[272]alexadamus77-ui commented [273]Aug 1, 2026

Copy link
Copy Markdown

Really clean approach to unified academic search and deduplication across
sources! Managing source degradation and fallback queries across multiple
endpoints takes a lot of effort.

If you're looking for a fast, reliable academic search backend to simplify
paper lookup, citation graphs, and metadata retrieval, [274]ScholarAPI is worth
a look. It provides structured JSON responses directly, making paper search
workflows much more deterministic.

Sorry, something went wrong.

Uh oh!

There was an error while loading. [277]Please reload this page.

[278]@gowtham0992

[279]gowtham0992 commented [280]Aug 3, 2026

Copy link
Copy Markdown

Link 2.1.0 is out. This one is about trust: memory that cannot repeat itself
and knows when to re-ask.

Since 2.0 I dogfooded the automatic capture pipeline hard and my own review
inbox grew to 20 pending captures, five of them the same conversation captured
five times. 2.1 is everything that fixing that properly turned into.

What's new:

  • Inbox zero. Proposals are fingerprinted and deduped against everything
    pending, accepted, or dismissed. Deleting a capture records the dismissal,
    so the same proposal never comes back. One conversation = one capture,
    refreshed in place. "lnk dedup-captures" collapses an existing backlog
    (mine went 20 to 9 in one command).
  • Trust lifecycle. Every memory now gets a review window by type: project
    context 3 months, preferences 6, decisions 12. Reviewing re-arms it. Aged
    memories are never hidden, they get labeled "review due" everywhere agents
    read, including the session brief. As far as I know no other memory system
    re-asks whether what it knows is still true.
  • Contradiction detection got serious. Revisions like "we don't use X
    anymore" now supersede the old memory: exposure went from 0.583 to 0.167 on
    the hygiene benchmark, and with the local semantic tier on, even
    rephrasings with zero shared words get caught ("SQLite with FTS" revised as
    "DuckDB files").
  • Memory poisoning benchmark. A planted memory gets injected into every
    future session, which makes agent memory the biggest prompt injection
    target there is. 15 authored attacks now run through the real pipeline in
    CI: 0 reach the inbox unlabeled, 0 false positives on real preferences.
    Injection-shaped proposals get flagged in the inbox: "verify you actually
    said this before accepting". I believe this is the only published
    adversarial benchmark on an agent memory write path.

[281]linkbar-11-inbox-injection

  • lnk setup. Install is now two commands total. "lnk setup" detects every
    agent on your machine (Claude Code, Codex, Cursor, Windsurf, Zed, Kiro,
    Gemini CLI) and wires them all: workspace, MCP, session hooks. It ran on my
    own machine during the release and wired 5 agents first try. Upgrades are
    the same command.
  • LinkBar 1.1. Tap any memory for its trust card (where it came from, when it
    was reviewed, whether recall will use it and why). Injection warnings show
    right on the capture row. Full backlog is reviewable with a cleanup button.

[282]linkbar-11-explain-card

  • The homepage now embeds a real exported Link workspace you can click
    through, generated by "lnk snapshot".

# macOS, the full experience (CLI + menu bar app)
brew install --cask gowtham0992/link/linkbar
lnk setup

# CLI only (or Linux)
brew install gowtham0992/link/link
lnk setup

# already running Link
brew upgrade && lnk setup

Still: wiki as the storage layer, every memory a file you can open, nothing
durable without review.

Release notes: [283]https://github.com/gowtham0992/link/releases/tag/v2.1.0

Repo: [284]https://github.com/gowtham0992/link
Site: [285]https://gowtham0992.github.io/link/
PyPI: [286]https://pypi.org/project/link-mcp/
MCP: [287]https://registry.modelcontextprotocol.io/?q=
io.github.gowtham0992%2Flink
Benchmarks with full configs and the experiments that lost: [288]https://
github.com/gowtham0992/link/blob/main/benchmarks/RESULTS.md

Sorry, something went wrong.

Uh oh!

There was an error while loading. [291]Please reload this page.

[292]@mas213

[293]mas213 commented [294]Aug 3, 2026

Copy link
Copy Markdown

Update since my last comment. [295]https://gist.github.com/karpathy/
442a6bf555914893e9891c11519de94f?permalink_comment_id=6237886#
gistcomment-6237886
Ran the behavioral graph against a frontier model (Claude Fable 5) on the same
repo, same commit. Wanted to know: does a deterministic graph find the same
things a reasoning model finds?
Overlap: near zero.
The model read ~75 files it picked itself and found defect mechanisms. Races,
silent fallbacks, missing retries. The graph mapped all 4,849 behaviors
exhaustively and ranked them by structural exposure. Completely different
output lists. Each instrument's blind spot was the other's finding.
Two agreements mattered. Both flagged the same message-queue layer (184
importers, one spec file) as high-risk untested surface. Both deprioritized the
same view/page-layout family. Convergent deprioritization from decorrelated
instruments is harder to fake than convergent alarm.
One disagreement was productive. The model's top finding sat in the graph's
data but outside its top 20. Tracing why isolated two scoring factors
documented in the methodology but not yet weighted in the shipped formula. The
disagreement functioned as instrument calibration. Fixed same day, in public.
Also closed the proof ladder end-to-end on a second repo (Go, ~8,700
behaviors). Three mutation proofs. One was self-incriminating: the graph's own
test generator hallucinated an expected value. The execution layer caught it.
Oracle corrected from source. Mutation proof then closed the method. A
verification layer that catches its own generator is the strongest evidence for
the decorrelation argument.
The Lint operation from the original gist now has four evidence tiers instead
of binary tested/untested: dynamically proven (mutation killed), test signal
(static link, no proof), candidate (name match only), no signal. The graph
refuses to overstate. Nothing reaches "covered" without execution.

[296]@jessicayoung12 , curious what domain you applied it to. The compounding
effect you describe is exactly what we see. The graph after 50 PRs is a
fundamentally different instrument than the graph after 5. Every incident filed
teaches it a failure mode it didn't have before.

Full comparison write-up: [297]https://orangepro.ai/blog/fable-vs-orangepro
Repo unchanged: [298]https://github.com/OrangeproAI/orangepro-mcp

Sorry, something went wrong.

Uh oh!

There was an error while loading. [301]Please reload this page.

[302]@BackendGameSetMatch

[303]BackendGameSetMatch commented [304]Aug 3, 2026

Copy link
Copy Markdown

My take on it: [305]https://github.com/BackendGameSetMatch/sourcebook

Sorry, something went wrong.

Uh oh!

There was an error while loading. [308]Please reload this page.

[309]Sign up for free to join this conversation on GitHub. Already have an
account? [310]Sign in to comment

Footer

[311] © 2026 GitHub, Inc.

Footer navigation

  • [312]Terms
  • [313]Privacy
  • [314]Security
  • [315]Status
  • [316]Community
  • [317]Docs
  • [318]Contact
  • [319] Manage cookies
  • [320] Do not share my personal information

[321](Dismiss error) You can’t perform that action at this time.
[322](Close dialog)

References:

[1] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#start-of-content
[2] https://gist.github.com/
[6] https://gist.github.com/discover
[7] https://github.com/
[8] https://gist.github.com/auth/github?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f
[9] https://gist.github.com/join?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f&source=header-gist
[10] https://gist.github.com/
[11] https://gist.github.com/auth/github?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f
[12] https://gist.github.com/join?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f&source=header-gist
[13] -
[14] -
[15] -
[18] https://gist.github.com/karpathy
[19] https://gist.github.com/karpathy
[20] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
[22] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f/archive/ac46de1ad27f92b28ac95459c782c07f6b8c964a.zip
[23] https://gist.github.com/login?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f
[24] https://gist.github.com/login?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f
[30] https://docs.github.com/articles/which-remote-url-should-i-use
[33] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
[34] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f/revisions
[35] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f/stargazers
[36] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f/forks
[42] https://docs.github.com/articles/which-remote-url-should-i-use
[45] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f/archive/ac46de1ad27f92b28ac95459c782c07f6b8c964a.zip
[46] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f/raw/ac46de1ad27f92b28ac95459c782c07f6b8c964a/llm-wiki.md
[47] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#file-llm-wiki-md
[48] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#llm-wiki
[49] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#the-core-idea
[50] https://tolkiengateway.net/wiki/Main_Page
[51] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#architecture
[52] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#operations
[53] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#indexing-and-logging
[54] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#optional-cli-tools
[55] https://github.com/tobi/qmd
[56] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#tips-and-tricks
[57] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#why-this-works
[58] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#note
[63] https://gist.github.com/frankchu91
[64] https://gist.github.com/frankchu91
[65] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6263946#gistcomment-6263946
[66] -
[67] https://github.com/frankchu91/mindbase
[68] https://raw.githubusercontent.com/frankchu91/mindbase/main/docs/assets/webui.png
[71] -
[72] https://gist.github.com/sturlese
[73] https://gist.github.com/sturlese
[74] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6264580#gistcomment-6264580
[75] https://github.com/sturlese/hippocampus
[76] https://github.com/sturlese/hippocampus/blob/main/docs/what-happens-when-you-ingest.md
[79] -
[80] https://gist.github.com/lucianfialho
[81] https://gist.github.com/lucianfialho
[82] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6265193#gistcomment-6265193
[83] https://gist.github.com/lucianfialho/44034e0d02a2bfccca2ad6358bde1dff
[86] -
[87] https://gist.github.com/bprice1000
[88] https://gist.github.com/bprice1000
[89] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6265282#gistcomment-6265282
[90] https://gist.github.com/bprice1000/f986547dda0a82c5178faa6e237247fe
[93] -
[94] https://gist.github.com/umezy
[95] https://gist.github.com/umezy
[96] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6265520#gistcomment-6265520
[97] -
[98] https://github.com/geetansharora
[99] https://github.com/umezy/team-ai-workflows
[102] -
[103] https://gist.github.com/suwonleee
[104] https://gist.github.com/suwonleee
[105] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6265997#gistcomment-6265997
[106] https://github.com/suwonleee/llmwiki
[107] https://raw.githubusercontent.com/suwonleee/llmwiki/main/assets/social-preview.png
[110] -
[111] https://gist.github.com/kytmanov
[112] https://gist.github.com/kytmanov
[113] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6266796#gistcomment-6266796
[114] -
[115] https://github.com/kytmanov/synto
[118] -
[119] https://gist.github.com/Sarthib7
[120] https://gist.github.com/Sarthib7
[121] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6266907#gistcomment-6266907
[122] -
[123] https://github.com/masumi-network/Citadel-Archive
[124] https://github.com/geetansharora
[125] https://github.com/masumi-network/Citadel
[126] https://citadel-archive-production.up.railway.app/skills/connect
[127] https://private-user-images.githubusercontent.com/112841873/625046636-60c5bae4-7f06-41bc-97d6-55e086662db9.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODU4MjEyOTIsIm5iZiI6MTc4NTgyMDk5MiwicGF0aCI6Ii8xMTI4NDE4NzMvNjI1MDQ2NjM2LTYwYzViYWU0LTdmMDYtNDFiYy05N2Q2LTU1ZTA4NjY2MmRiOS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwODA0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDgwNFQwNTIzMTJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT03ZjQ1YTAzNjRhNzc2Y2VjMDU4ODA5ZGFiODhlYjNiN2ZlYjg2YjE1MThlYjQ5MjdlYWE3NTYxMDkzODk3NTA0JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.HRsnT7a_A-CJGo6SGlRV9erRQQtAso6v0ZFPcQrJReQ
[130] -
[131] https://gist.github.com/gavischneider
[132] https://gist.github.com/gavischneider
[133] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6266938#gistcomment-6266938
[134] https://github.com/gavischneider/awesome-llm-wiki
[137] -
[138] https://gist.github.com/rath-muth
[139] https://gist.github.com/rath-muth
[140] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6268995#gistcomment-6268995
[143] -
[144] https://gist.github.com/frankchu91
[145] https://gist.github.com/frankchu91
[146] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6269557#gistcomment-6269557
[147] https://github.com/frankchu91/mindbase
[150] -
[151] https://gist.github.com/alfadur7
[152] https://gist.github.com/alfadur7
[153] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6269698#gistcomment-6269698
[154] -
[155] https://www.youtube.com/watch?v=D_cw-k0F1DM&t=236
[156] https://alfadur7.github.io/llm-wiki-newsroom/knowledge-factory/
[157] https://private-user-images.githubusercontent.com/6949852/624935308-0e77e371-cba4-4e0d-8e7d-b1e2b9757713.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODU4MjEyOTIsIm5iZiI6MTc4NTgyMDk5MiwicGF0aCI6Ii82OTQ5ODUyLzYyNDkzNTMwOC0wZTc3ZTM3MS1jYmE0LTRlMGQtOGU3ZC1iMWUyYjk3NTc3MTMucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDgwNCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA4MDRUMDUyMzEyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9YmMzNzc4Y2UwNjFhMDA0ZDdiZTZkZmM3Mzg2NTFhZTM5YjQyMTc0NjQ5NTkzNDU2ZGRjMGZkZTM2MDcyYjk5NSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.qSUf3gssLHJKQLQXrusUZ7QdAcsL8L3ZQ8Q0nVkLOus
[160] -
[161] https://gist.github.com/ErikEvenson
[162] https://gist.github.com/ErikEvenson
[163] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6273560#gistcomment-6273560
[164] -
[165] https://www.erikevenson.net/building-an-llm-wiki-part-2.html
[168] -
[169] https://gist.github.com/ibehnam
[170] https://gist.github.com/ibehnam
[171] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6273920#gistcomment-6273920
[172] https://www.erikevenson.net/building-an-llm-wiki-part-2.html
[175] -
[176] https://gist.github.com/denson
[177] https://gist.github.com/denson
[178] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6276072#gistcomment-6276072
[179] https://github.com/OO-LD
[180] https://github.com/OpenSemanticLab
[181] https://demo.open-semantic-lab.org/
[182] https://github.com/OO-LD
[185] -
[186] https://gist.github.com/akash07k
[187] https://gist.github.com/akash07k
[188] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6276421#gistcomment-6276421
[189] https://github.com/frankchu91
[190] https://github.com/frankchu91/mindbase
[193] -
[194] https://gist.github.com/bollakarthikeya
[195] https://gist.github.com/bollakarthikeya
[196] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6278138#gistcomment-6278138
[197] -
[200] -
[201] https://gist.github.com/gowtham0992
[202] https://gist.github.com/gowtham0992
[203] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6281820#gistcomment-6281820
[204] https://private-user-images.githubusercontent.com/15722259/627599374-f5711fac-cec4-464c-b847-da9bfb077c6a.gif?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODU4MjEyOTIsIm5iZiI6MTc4NTgyMDk5MiwicGF0aCI6Ii8xNTcyMjI1OS82Mjc1OTkzNzQtZjU3MTFmYWMtY2VjNC00NjRjLWI4NDctZGE5YmZiMDc3YzZhLmdpZj9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MDQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODA0VDA1MjMxMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTE2MTg2Mzc5OGNhYmY4Zjk3MmIwMDFmNDhiODllOTk4ZmVkZWU5YTY5OGIzMzM1OGI4YjY3ZTJhNzY2ODBkZTEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRmdpZiJ9.37-hN6kHMCo63WKi1_b42bcCrMhSiX1A1CXkbe4Ogw0
[205] https://private-user-images.githubusercontent.com/15722259/627599063-7cac41f4-6fbb-4e44-bcd1-7c37221c26dd.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODU4MjEyOTIsIm5iZiI6MTc4NTgyMDk5MiwicGF0aCI6Ii8xNTcyMjI1OS82Mjc1OTkwNjMtN2NhYzQxZjQtNmZiYi00ZTQ0LWJjZDEtN2MzNzIyMWMyNmRkLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MDQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODA0VDA1MjMxMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWQyZTliMzgxZjNmMGZkZjQwMzE3YzY0MGE3ZDgzNDdhMzc1NDY0NDhmMzJjNzNiNjAzNDQyMGUyNTEwMDkwOGQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.2hvJrn4qDA9u_zh9Fy94tPAzY3FUNKoFJwhPsjZozVM
[206] https://github.com/gowtham0992/link/releases/tag/v2.0.0
[207] https://github.com/gowtham0992/link
[208] https://gowtham0992.github.io/link/
[209] https://pypi.org/project/link-mcp/
[210] https://registry.modelcontextprotocol.io/?q=io.github.gowtham0992%2Flink
[213] -
[214] https://gist.github.com/XBlueSky
[215] https://gist.github.com/XBlueSky
[216] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6284110#gistcomment-6284110
[217] https://github.com/XBlueSky/cortexes
[218] https://github.com/XBlueSky/cortexes
[219] https://cortexes.pages.dev/
[222] -
[223] https://gist.github.com/GeraldGrootRoessink
[224] https://gist.github.com/GeraldGrootRoessink
[225] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6284539#gistcomment-6284539
[228] -
[229] https://gist.github.com/suwonleee
[230] https://gist.github.com/suwonleee
[231] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6284942#gistcomment-6284942
[232] https://github.com/suwonleee/llmwiki
[233] https://raw.githubusercontent.com/suwonleee/llmwiki/main/assets/social-preview.png
[236] -
[237] https://gist.github.com/antondziatkovskii
[238] https://gist.github.com/antondziatkovskii
[239] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6285217#gistcomment-6285217
[240] https://github.com/Palo-Alto-AI-Research-Lab/sqlite-graph-memory
[241] https://github.com/Palo-Alto-AI-Research-Lab/verbatim-citation-gate
[244] -
[245] https://gist.github.com/Nikalo71
[246] https://gist.github.com/Nikalo71
[247] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6286837#gistcomment-6286837
[250] -
[251] https://gist.github.com/JanYork
[252] https://gist.github.com/JanYork
[253] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6288782#gistcomment-6288782
[254] https://github.com/JanYork/llm-wiki-cli
[257] -
[258] https://gist.github.com/Nikalo71
[259] https://gist.github.com/Nikalo71
[260] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6289081#gistcomment-6289081
[263] -
[264] https://gist.github.com/Nikalo71
[265] https://gist.github.com/Nikalo71
[266] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6289082#gistcomment-6289082
[267] https://github.com/JanYork/llm-wiki-cli
[270] -
[271] https://gist.github.com/alexadamus77-ui
[272] https://gist.github.com/alexadamus77-ui
[273] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6290598#gistcomment-6290598
[274] https://scholarapi.net/
[277] -
[278] https://gist.github.com/gowtham0992
[279] https://gist.github.com/gowtham0992
[280] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6294542#gistcomment-6294542
[281] https://private-user-images.githubusercontent.com/15722259/630686175-a04ed73d-5419-4cd8-aa72-d25357aeec87.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODU4MjEyOTIsIm5iZiI6MTc4NTgyMDk5MiwicGF0aCI6Ii8xNTcyMjI1OS82MzA2ODYxNzUtYTA0ZWQ3M2QtNTQxOS00Y2Q4LWFhNzItZDI1MzU3YWVlYzg3LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MDQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODA0VDA1MjMxMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTlmZTdlMzljYTIzOGIwZmE4YWI0Y2JjZGFmYmE1NDY5MmNjYmNmNjg0ZGQyNzllNjhjYWNlYWU5OWVhMzM4ZTQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.5G2DQYmD0w1iFKy321Nyt-f9fCEvIr31aUZm0lej598
[282] https://private-user-images.githubusercontent.com/15722259/630686425-35cd9bcd-87e1-4aed-9652-0f80562294f1.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODU4MjEyOTIsIm5iZiI6MTc4NTgyMDk5MiwicGF0aCI6Ii8xNTcyMjI1OS82MzA2ODY0MjUtMzVjZDliY2QtODdlMS00YWVkLTk2NTItMGY4MDU2MjI5NGYxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MDQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODA0VDA1MjMxMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWRhNzY4NTM3NmM1ODgzMGExMDRkZmJlNWMzZjE5ZDE1ODM0NjIzZjc5ZjAxM2M5NjY0MDk3ZDAzOGUxMTczZWYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.ds9RgsEVPnnzUdsEG-j3kNLkaGtSDEucaPBdxN0m42A
[283] https://github.com/gowtham0992/link/releases/tag/v2.1.0
[284] https://github.com/gowtham0992/link
[285] https://gowtham0992.github.io/link/
[286] https://pypi.org/project/link-mcp/
[287] https://registry.modelcontextprotocol.io/?q=io.github.gowtham0992%2Flink
[288] https://github.com/gowtham0992/link/blob/main/benchmarks/RESULTS.md
[291] -
[292] https://gist.github.com/mas213
[293] https://gist.github.com/mas213
[294] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6295034#gistcomment-6295034
[295] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6237886#gistcomment-6237886
[296] https://github.com/jessicayoung12
[297] https://orangepro.ai/blog/fable-vs-orangepro
[298] https://github.com/OrangeproAI/orangepro-mcp
[301] -
[302] https://gist.github.com/BackendGameSetMatch
[303] https://gist.github.com/BackendGameSetMatch
[304] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6295163#gistcomment-6295163
[305] https://github.com/BackendGameSetMatch/sourcebook
[308] -
[309] https://gist.github.com/join?source=comment-gist
[310] https://gist.github.com/login?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f
[311] https://github.com/
[312] https://docs.github.com/site-policy/github-terms/github-terms-of-service
[313] https://docs.github.com/site-policy/privacy-policies/github-privacy-statement
[314] https://github.com/security
[315] https://www.githubstatus.com/
[316] https://github.community/
[317] https://docs.github.com/
[318] https://support.github.com/?tags=dotcom-footer