karpathy

LLM Wiki

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

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.

nolanlawson

name	code-review-turbo
description	Run a triple-agent code review on the current branch's PR. Waits for Cursor Bugbot, runs a Claude sub-agent and Codex in parallel, then cross-references all findings to filter out hallucinations. Use when you want a thorough, multi-perspective code review before merging.
metadata	disable-model-invocation argument-hint true [pr-number]
allowed-tools	Bash(gh:*) Bash(codex:*) Bash(cat:*) Bash(tee:*) Bash(sleep:*) Agent Read Grep Glob Write(/tmp/*)

Code Review Turbo

rssnyder

how to leverage oracle's temping offers

free tier limits

The limits of the free tier say that you can create up to 4 instances.

• x2 x86 instances (2core/1g)
• x2 ampere instances (with 4core/24g spread between them)
• 200GB total boot volume space across all intances (minimum of 50G per instance)

create your account

aparente

---

name: tufte-viz description: | Ideate and critique data visualizations using Edward Tufte's principles from "The Visual Display of Quantitative Information." Use this skill when: (1) Designing new data visualizations or charts (2) Critiquing or improving existing visualizations (3) Reviewing dashboards or reports for graphical integrity (4) Deciding between visualization approaches (5) Reducing chartjunk or improving data-ink ratio (6) Planning small multiples or high-density displays

lancejpollard

Copied from http://code.lancepollard.com/complete-list-of-html-meta-tags/

Basic HTML Meta Tags

<meta name="keywords" content="your, tags"/>
<meta name="description" content="150 words"/>
<meta name="subject" content="your website's subject">
<meta name="copyright"content="company name">
<meta name="language" content="ES">

todgru

#!/bin/sh
#
# Setup a work space called `work` with two windows
# first window has 3 panes. 
# The first pane set at 65%, split horizontally, set to api root and running vim
# pane 2 is split at 25% and running redis-server 
# pane 3 is set to api root and bash prompt.
# note: `api` aliased to `cd ~/path/to/work`
#
session="work"

RyuZinOh

local states = {}
local timer = nil
local DVD_W, DVD_H = 300, 300

-- dvd
local function bounce(s)
	s.x = s.x + s.vx
	s.y = s.y + s.vy

	if s.x <= s.mx or s.x + s.w >= s.mx + s.mw then

TTSR

/*
    A
   ---
  F |   | B
  | G |
   ---
  E |   | C
  |   |
   ---
    D

vurtun

LIBRARY WRITING REFERENCE LIST
===============================
1.) Designing and Evaluating Reusable Components (Casey Muratori: http://mollyrocket.com/casey/stream_0028.html)
----------------------------------------------------------------------------------------------------------------
_THE_ reference on API design up to this day on the internet. Nobody should write a library without having seen this.
I come back to this talk every N number of weeks it is that good.

2.) stb_howto (Sean Barrett: https://github.com/nothings/stb/blob/master/docs/stb_howto.txt)
--------------------------------------------------------------------------------------------
Sean Barretts single header libraries (https://github.com/nothings/stb) was the first time for me that I came across 

vurtun

API Design: Modular Data-oriented processes (June-2017)

This is the second entry in my series about API design. While I wrote about granularity and request based APIs in my last post I want to write about API design and code architecture for modular data-oriented process this time. This is basically the write up of my findings while writing and finishing the core of my current GUI research quarks.

Actually sparking my interest for writing up my findings however was rasmusbarr@github (rasmusbarr@twitter) releasing his small data-oriented and SIMD-optimized 3D rigid body physics library. I noticed a lot of overlap in design between his physics and my GUI library and wanted to write up some general thoughts about what seems