Starred Gists

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.

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

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

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

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

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

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

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

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.

Raspberry Pi 5 Media Server — Commands

Immich (photos) + Jellyfin (movies/TV) + Tailscale (access from anywhere). Commands only, in the order they're run in the video.

Tested August 2026 on:


Hardware	Raspberry Pi 5, 8GB — CanaKit Starter Kit PRO
Boot	128GB microSD (kit)
Storage	Samsung T7 1TB, ext4, at `/mnt/storage`
OS	Raspberry Pi OS Lite 64-bit, kernel `6.18.39+rpt-rpi-v8`
Immich	`immich-server:v3`
Jellyfin	`jellyfin/jellyfin:latest`
Tailscale	`1.98.10`

If you're following this much later and something doesn't match, the versions above are why. Immich in particular changes its compose file fairly often — always pull the current one from their releases page as Step 20 does.

What you actually have to change

Find and replace these before running the commands.

Token	Replace with	Where
`USER_NAME`	Your username	Steps 7, 18, 31, 32, 33 — the same username you set in Raspberry Pi Imager
`mediapi`	Your hostname	The `ssh` command and every URL
`/dev/sda`	Your drive	Steps 13–15. Verify with `lsblk` first. Never assume it.
`America/New_York`	Your timezone	Step 21. `timedatectl list-timezones` to find yours
`YOURUUIDHERE`	Your drive's UUID	Step 15. `blkid` prints it
`makeUpAPasswordHere`	Any password you invent	Step 21. Letters and numbers only

Anything starting with $ is not a placeholder — leave it exactly as written. $USER in Step 17, and $(id -u), $(id -g) and $(timedatectl ...) in Step 26, are filled in by the Pi itself when the command runs. Replacing them by hand is how you break them.

On the Pi vs on your laptop — everything below runs on the Pi over SSH, except where noted as running on your own computer.

Step 7 — Connect (run on your computer)

ssh USER_NAME@mediapi.local

If the hostname doesn't resolve, get the IP from your router and use ssh USER_NAME@192.168.x.x.

Step 9 — Update the OS

sudo apt update && sudo apt full-upgrade -y

sudo reboot

Step 10 — Timezone

timedatectl

Only if it's wrong (timedatectl list-timezones | grep America to find yours):

sudo timedatectl set-timezone America/New_York

Steps 11–12 — Confirm you booted from the SD card

findmnt -n -o SOURCE,FSTYPE,SIZE /

df -h /

Root should be on /dev/mmcblk0p2 — that's the SD card slot. df shows your card's capacity. If it comes back far smaller than the card actually is, the filesystem didn't expand on first boot; reboot and check again.

Step 13 — Identify the drive

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT,MODEL,SERIAL

Confirm before continuing: the model and size match the drive you plugged in, and it is not mmcblk0. Only one external drive should be connected.

About `sda` vs `sda1`

It will almost certainly be sda for you too. Linux names your SD card mmcblk0, so it never takes the sda slot — the first USB drive you plug in gets it. Booting from the SD card with one USB drive attached, it's sda every time.

They're two different things, not a typo:

sda is the whole physical drive. wipefs and parted use this — they work on the drive and its partition table.
sda1 is the first partition on that drive. mkfs.ext4, blkid, and umount use this — they work on a filesystem.

parted in Step 14 is what creates sda1 in the first place, which is why the commands switch from one to the other partway through.

If lsblk shows something different, swap both consistently:

Your drive shows as	Whole drive	Partition
`sda`	`/dev/sda`	`/dev/sda1`
`sdb`	`/dev/sdb`	`/dev/sdb1`
`nvme0n1`	`/dev/nvme0n1`	`/dev/nvme0n1p1`

NVMe is the only odd one — note the extra p before the partition number.

Step 14 — Format the drive

sudo umount /dev/sda1 2>/dev/null

sudo wipefs -a /dev/sda

sudo parted /dev/sda --script mklabel gpt

sudo parted /dev/sda --script mkpart primary ext4 0% 100%

sudo mkfs.ext4 -L bulk /dev/sda1

Step 15 — Mount it permanently

sudo blkid /dev/sda1

Copy the UUID from the output.

sudo mkdir -p /mnt/storage

sudo nano /etc/fstab

Add this as a new line at the bottom, swapping in the UUID you just copied. It has to be all on one line:

UUID=YOURUUIDHERE /mnt/storage ext4 defaults,noatime,nofail 0 2

Save and exit with Ctrl+X, then Y, then Enter.

sudo mount -a

sudo systemctl daemon-reload

df -h /mnt/storage

mount -a should print nothing. Any error means fix the fstab line before rebooting. df should then show your drive mounted at /mnt/storage.

Step 16 — Confirm it survives a reboot

sudo reboot

df -h /mnt/storage

Step 17 — Folders

Run this exactly as written — $USER is not a placeholder. It's a variable your shell already knows, so it works for everyone with nothing to set up:

sudo chown -R $USER:$USER /mnt/storage

The shell swaps $USER for your username before sudo runs, so this makes you the owner, not root.

mkdir -p /mnt/storage/immich/library /mnt/storage/immich/postgres /mnt/storage/media/movies /mnt/storage/media/tv

find /mnt/storage -maxdepth 3

Step 18 — Docker

curl -fsSL https://get.docker.com | sh

Again, $USER stays exactly as written:

sudo usermod -aG docker $USER

exit

Reconnect from your computer:

ssh USER_NAME@mediapi.local

Step 19 — Verify Docker

docker run --rm hello-world

docker compose version

Both must work without sudo.

Step 20 — Download Immich

mkdir -p ~/immich && cd ~/immich

wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml

wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env

Step 21 — Configure Immich

nano .env

Change these four values. Leave everything else in the file alone.

UPLOAD_LOCATION=/mnt/storage/immich/library
DB_DATA_LOCATION=/mnt/storage/immich/postgres
TZ=America/New_York
DB_PASSWORD=makeUpAPasswordHere

TZ is commented out by default. Delete the # in front of it and put in your own timezone.
DB_PASSWORD — letters and numbers only, no symbols or spaces. Immich requires that.

Save and exit with Ctrl+X, then Y, then Enter.

Step 22 — Start Immich

docker compose up -d

Takes 10–20 min on first run.

Step 23 — Verify

docker compose ps

Four containers, all Up. If one is Restarting:

docker logs immich_postgres

Steps 24–25 — Browser and phone

Where	URL
Browser	`http://mediapi.local:2283`
Phone app	`http://mediapi.local:2283/api`

The /api suffix on the phone app is required.

Step 26 — Jellyfin compose file

UID, GID, and timezone all filled in automatically:

mkdir -p ~/jellyfin && cd ~/jellyfin

printf "services:\n  jellyfin:\n    image: jellyfin/jellyfin:latest\n    container_name: jellyfin\n    user: \"$(id -u):$(id -g)\"\n    network_mode: host\n    volumes:\n      - ./config:/config\n      - ./cache:/cache\n      - /mnt/storage/media:/media:ro\n    environment:\n      - TZ=$(timedatectl show -p Timezone --value)\n    restart: unless-stopped\n" > docker-compose.yml

Check your user and group IDs match what went into the file:

id -u && id -g

Both should print 1000 on a fresh Pi. That's the user Jellyfin runs as inside the container.

docker compose config

Must parse cleanly before you continue.

Step 27 — Start Jellyfin

Create these first or Docker makes them root-owned and Jellyfin crash-loops:

mkdir -p ~/jellyfin/config ~/jellyfin/cache

docker compose up -d

docker ps

If Jellyfin shows `Restarting (133)`

The Pi 5's default kernel uses 16KB memory pages, and Jellyfin's .NET runtime needs 4KB. It crashes instantly and keeps relaunching — it will never come up on its own.

getconf PAGESIZE

If that says 16384:

sudo nano /boot/firmware/config.txt

Scroll to the very bottom and add this line under [all]:

kernel=kernel8.img

Save and exit with Ctrl+X, then Y, then Enter.

sudo reboot

After it comes back, getconf PAGESIZE should say 4096 and Jellyfin should be Up.

Steps 28–29 — Jellyfin setup (in a browser)

http://mediapi.local:8096

Movies library → /media/movies
TV library → /media/tv
Uncheck automatic port mapping
Dashboard → Playback → Hardware acceleration → None

Use the container paths, not /mnt/storage/....

File naming

Jellyfin matches your files against its metadata database by name, so this is what decides whether you get posters and descriptions or a wall of grey boxes.

Movies — one folder per film, named Title (Year):

movies/
├── Big Buck Bunny (2008)/
│   └── Big Buck Bunny (2008).mp4
└── The Matrix (1999)/
    └── The Matrix (1999).mkv

TV — show, then season folder, then SxxExx in the filename:

tv/
└── Severance/
    ├── Season 01/
    │   ├── Severance - S01E01.mkv
    │   └── Severance - S01E02.mkv
    └── Season 02/
        └── Severance - S02E01.mkv

Does the folder name have to match the file name? No. For a movie sitting alone in its own folder, Jellyfin identifies it from the folder name, so the file inside can be called anything. A bare Big Buck Bunny (2008).mp4 with no folder at all works too.

Matching them is just the foolproof option, for three reasons:

Nothing is ambiguous — the folder and file can't disagree.
If you later add a second copy at a different quality, Jellyfin only groups them as one movie when they share a base name: Film (2008) - 1080p.mkv and Film (2008) - 4K.mkv.
Subtitles and artwork attach by matching base name. A .srt next to a differently-named video won't be picked up.

The one thing that genuinely is required: the year in parentheses for movies, and SxxExx in the filename for TV episodes. A folder name can't tell Jellyfin which episode a file is, so that has to be in the file itself. Zero-padded — S01E01, not 1x1 or Ep1.

Also strip release-group tags, resolution strings, and codec names from filenames. They confuse the matcher.

After adding files: Dashboard → Libraries → Scan All Libraries. If something doesn't match, right-click it → Identify → search manually.

Step 31 — Samba

sudo apt install -y samba samba-common-bin

Replace both USER_NAME with your username before running this. Run it once only — the -a appends, and without it tee would wipe the config:

printf '\n[media]\n   path = /mnt/storage/media\n   browseable = yes\n   read only = no\n   guest ok = no\n   valid users = USER_NAME\n   force user = USER_NAME\n   create mask = 0664\n   directory mask = 0775\n' | sudo tee -a /etc/samba/smb.conf > /dev/null

tail -12 /etc/samba/smb.conf

Step 32 — Samba password

Replace USER_NAME with your username here too. It has to match the valid users line from Step 31, or the share won't let you connect.

sudo smbpasswd -a USER_NAME

This sets a separate password just for file sharing — it's not your Pi login password, though you can use the same one. You'll be asked to type it twice, and nothing appears on screen as you type.

sudo systemctl restart smbd && sudo systemctl enable smbd

Step 33 — Connect from your computer

OS	How
macOS	Finder → `Cmd+K` → `smb://mediapi.local`
Windows	File Explorer → `\\mediapi.local\media`
Linux	Files → Other Locations → `smb://mediapi.local`

Command line:

rsync -avh --progress "/path/to/Movie (2024)" USER_NAME@mediapi.local:/mnt/storage/media/movies/

Windows uses scp -r instead.

Step 35 — Tailscale

curl -fsSL https://tailscale.com/install.sh | sh

sudo tailscale up

tailscale status

Step 36 — Admin console (in a browser)

login.tailscale.com/admin

Machines → your Pi → ⋯ → Disable key expiry
DNS tab → confirm MagicDNS is on

Steps 37–38 — Phone, then verify remotely

Install Tailscale on the phone, log in, connect. Turn off WiFi — cellular only.

Service	URL
Immich	`http://mediapi:2283`
Immich app	`http://mediapi:2283/api`
Jellyfin	`http://mediapi:8096`

Note: no .local when away from home.

Quick Reference

Service	URL	Port
Immich	`http://mediapi.local:2283`	2283
Immich app	`http://mediapi.local:2283/api`	2283
Jellyfin	`http://mediapi.local:8096`	8096
Samba	`smb://mediapi.local`	445
SSH	`ssh USER_NAME@mediapi.local`	22

Ports are the software's defaults — identical for everyone.

Task	Command
Update a service	`cd ~/immich && docker compose pull && docker compose up -d`
Logs	`docker compose logs -f`
Running containers	`docker ps`
Resource usage	`docker stats`
Disk space	`df -h`
Temperature	`vcgencmd measure_temp`
Power/thermal faults	`vcgencmd get_throttled`

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.

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

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

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

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

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

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

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

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.

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.

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

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

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

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

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

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

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

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.

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.

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

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

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

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

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

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

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

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.

AGENTS.md

Apply these rules within the host's instruction hierarchy and follow repository instructions within their scope. “Prefer” marks guidance; other instructions are requirements.

Judgment and Scope

Identify the requested outcome, scope, constraints, and observable completion criteria. Challenge assumptions or approaches that materially undermine the goal; then follow the user's informed decision.
Resolve uncertainty from available evidence. Ask early when missing information materially affects correctness, scope, authorization, or consequential choices. Make routine, reversible decisions directly.
Carry authorized work through implementation and verification without routine reconfirmation. When approval is required, first complete already-authorized preparation that does not depend on that approval, and present a concrete, reviewable proposal or result.
Change only what the task requires and preserve unrelated existing work. Report out-of-scope findings without fixing them. Obtain approval for destructive actions or changes to shared systems when existing authorization does not cover them.

Explore and Plan

Before editing, read applicable repository guidance and inspect the current working state. Start with relevant code, callers, tests, configuration, and dependencies; expand exploration only to resolve specific questions.
Verify material uncertain claims against source code, types, configuration, observed behavior, or authoritative documentation. Match external guidance to the actual versions and environment. Distinguish evidence from inference; do not invent APIs, sources, or results.
Use a brief plan when dependencies, uncertainty, or coordination make it useful. Execute simple tasks directly. Update the approach when new evidence invalidates it.

Implement

Prefer the simplest complete solution that meets current requirements. Reuse suitable existing capabilities; add dependencies or abstractions only when they meet a confirmed need or reduce present complexity.
Check affected consumers, public interfaces, and persisted formats before changing contracts. Preserve supported behavior outside the requested change; add compatibility or migration code only for demonstrated needs.
Follow the repository's language and style conventions. Keep responsibilities clear and explain non-obvious intent or constraints in concise comments. Remove code made obsolete by the change after checking its uses.
Use subagents only for independent work when delegation saves time or improves quality. Define inputs, outputs, ownership, and completion criteria; avoid conflicting writes. Keep shared-state coordination and sequential decisions with the primary agent, which integrates results and checks the evidence supporting key conclusions.

Verify and Recover

Run checks proportionate to the changed behavior and failure risk, including applicable required repository checks. Add or update tests that detect meaningful regressions. For low-impact changes, use adequate existing checks instead of adding tests; avoid tests that merely mirror the implementation.
Once necessary checks pass, expand or repeat verification only for new changes, failures, or unresolved concerns.
On failure, inspect the evidence and revise the diagnosis before retrying. Establish whether the failure comes from the change, an existing problem, or the environment. Fix issues within scope; do not hide failures or weaken checks to obtain a pass.
When blocked, stop dependent work and continue useful independent work. State the blocker, relevant attempts, and the minimum information, access, or decision needed to proceed.
Before handoff, review the final changes for correctness and scope. Remove only temporary files created by this task that no longer serve a purpose; retain deliverables and evidence needed for review.

Communicate

Lead with the outcome and impact, followed by necessary actions, decisions, and evidence. Omit elements that do not apply. Use concise, connected paragraphs and simple, concrete words; use lists when they help comparison or execution.
State disagreements and material risks directly, with reasons grounded in the task. Avoid flattery, filler, unnecessary jargon, repeated summaries, and unrequested contrasts. Do not introduce warnings, disclaimers, or approval procedures solely for hypothetical risks.
During longer work, give brief updates when there is meaningful progress, a changed approach, or a blocker.
At handoff, state what changed, what checks actually ran and their results, and any remaining limitations or unverified behavior. Provide paths, commands, or sources when they help verification. Claim only what the evidence supports.

	// ==UserScript==
	// @name IPA for translate.google
	// @namespace https://gist.github.com/adielBm/21762fe5e964071cb820a0c46896da34
	// @version 2024-06-27
	// @description Convert phonetic transcription to IPA on Google Translate
	// @author adielBm
	// @match https://translate.google.com/*
	// @grant none
	// @updateURL https://gist.githubusercontent.com/adielBm/21762fe5e964071cb820a0c46896da34/raw
	// @downloadURL https://gist.githubusercontent.com/adielBm/21762fe5e964071cb820a0c46896da34/raw
	// ==/UserScript==

	(function () {
	"use strict";
	function getIPA(str) {
	const mapping = {
	oi: "ɔɪ",
	ou: "aʊ",
	ô: "ɔ",
	ä: "ɑ",
	a: "æ",
	æʊ: "aʊ",
	i: "ɪ",
	ē: "i",
	o͝o: "ʊ",
	o͞o: "u",
	e: "ɛ",
	ā: "eɪ",
	ī: "aɪ",
	ō: "oʊ",
	NG: "ŋ",
	TH: "θ",
	T͟H: "ð",
	CH: "tʃ",
	SH: "ʃ",
	ZH: "ʒ",
	j: "dʒ",
	y: "j",
	};

	let result = "";
	let i = 0;
	const strLength = str.length;

	while (i < strLength) {
	let foundReplacement = false;

	// Check for multi-character replacements
	for (const key in mapping) {
	if (str.startsWith(key, i)) {
	result += mapping[key];
	i += key.length;
	foundReplacement = true;
	break;
	}
	}

	if (!foundReplacement) {
	result += str[i];
	i++;
	}
	}

	return result;
	}

	// Target element selectors
	const targetSelectors = ["[jsname=toZopb]", ".D4w5q"];

	// Function to be executed when a target element is created or its inner text changes
	function convertTextToIPA(element) {
	const text = element.innerHTML;
	if (text.length > 0 && text.charAt(0) !== "/") {
	element.innerText = `/${getIPA(text)}/`;
	}
	}

	// Create a new MutationObserver instance
	const observer = new MutationObserver((mutationsList) => {
	const processedElements = new Set();

	for (const mutation of mutationsList) {
	if (mutation.type === "childList" \|\| mutation.type === "characterData") {
	// Check added/modified nodes
	mutation.addedNodes.forEach((node) => {
	if (node.nodeType === Node.ELEMENT_NODE) {
	targetSelectors.forEach((selector) => {
	if (node.matches(selector)) {
	convertTextToIPA(node);
	processedElements.add(node);
	} else {
	node.querySelectorAll(selector).forEach((child) => {
	if (!processedElements.has(child)) {
	convertTextToIPA(child);
	processedElements.add(child);
	}
	});
	}
	});
	}
	});

	// Check directly modified nodes
	if (
	mutation.type === "characterData" &&
	mutation.target.nodeType === Node.TEXT_NODE
	) {
	const parent = mutation.target.parentElement;
	if (parent) {
	targetSelectors.forEach((selector) => {
	if (parent.matches(selector) && !processedElements.has(parent)) {
	convertTextToIPA(parent);
	processedElements.add(parent);
	}
	});
	}
	}
	}
	}
	});

	// Start observing the document for mutations
	observer.observe(document.body, {
	childList: true,
	characterData: true,
	subtree: true,
	});

	// Initial processing of existing elements
	targetSelectors.forEach((selector) => {
	document.querySelectorAll(selector).forEach(convertTextToIPA);
	});
	})();

	import json
	import os
	import psycopg2
	import pandas as pd
	import requests
	import numpy as np
	import random


	ENDPOINT = os.environ['ENDPOINT']
	DB_NAME = os.environ['DB_NAME']
	USERNAME = os.environ['USERNAME']
	PASSWORD = os.environ['PASSWORD']


	def lambda_handler(event, context):

	# Connect to the Postgres database
	try:
	print("Connecting to DB...")
	conn = psycopg2.connect(
	host=ENDPOINT,
	dbname=DB_NAME,
	user=USERNAME,
	password=PASSWORD
	)
	except psycopg2.Error as e:
	print("Error: Could not make connection to the Postgres database")
	print(e)
	exit(1)

	try:
	cur = conn.cursor()
	except psycopg2.Error as e:
	print("Error: Could not get cursor to the Database")
	print(e)
	exit(1)

	conn.set_session(autocommit=True)

	# Create table
	cur.execute("""
	CREATE TABLE IF NOT EXISTS posts (
	userId INT,
	id INT PRIMARY KEY,
	title TEXT,
	body TEXT
	);
	""")

	# Insert 10 random posts
	for i in range(10):
	random_post_id = random.randint(1, 100)
	url = f"https://jsonplaceholder.typicode.com/posts/{random_post_id}"
	print("Fetching data from:", url)

	response = requests.get(url)
	if response.status_code != 200:
	print(f"Error fetching post {random_post_id}")
	continue

	data = response.json()
	try:
	cur.execute("""
	INSERT INTO posts (userId, id, title, body)
	VALUES (%s, %s, %s, %s)
	ON CONFLICT (id) DO NOTHING;
	""", (data["userId"], data["id"], data["title"], data["body"]))
	except psycopg2.Error as e:
	print(f"Error inserting post {random_post_id}")
	print(e)

	# Print all posts
	try:
	cur.execute("SELECT * FROM posts;")
	rows = cur.fetchall()
	for row in rows:
	print(row)
	except psycopg2.Error as e:
	print("Error selecting rows")
	print(e)

	cur.close()
	conn.close()

	#!/bin/bash

	# Claude Desktop Multi-Instance Launcher
	#
	# Uses Electron's --user-data-dir flag to run fully isolated instances.
	# Each instance gets its own data directory (config, VM bundles, SDK, sessions).
	#
	# Usage:
	# ./claude_quick.sh # Show interactive menu
	# ./claude_quick.sh <instance> # Launch named instance
	# ./claude_quick.sh list # List all instances
	# ./claude_quick.sh delete <name> # Delete an instance
	# ./claude_quick.sh wrapper <name> # Create app wrapper for Dock/Launchpad
	# ./claude_quick.sh fix # Regenerate wrapper launcher scripts
	# ./claude_quick.sh diagnose # Diagnose problems

	INSTANCES_BASE="$HOME/.claude-instances"

	# ==================== Functions ====================

	copy_claude_icon() {
	local target_dir="$1"
	local icon=$(find "/Applications/Claude.app" -name "*.icns" -type f 2>/dev/null \| head -n 1)

	if [ -n "$icon" ]; then
	cp "$icon" "$target_dir/claude-icon.icns"
	echo "✅ Copied icon: $(basename "$icon")"
	else
	echo "⚠️ No icon found, wrapper will use default macOS icon"
	fi
	}

	list_instance_names() {
	ls -1 "$INSTANCES_BASE" 2>/dev/null
	}

	# List all instance names including the virtual "default" instance.
	list_all_instance_names() {
	echo "default"
	list_instance_names
	}

	# Find the .app wrapper for a given instance by checking its config.sh.
	find_wrapper_for_instance() {
	local target="$1"
	for app in /Applications/*.app; do
	local config="$app/Contents/MacOS/config.sh"
	[ ! -f "$config" ] && continue
	local name=$(grep "^INSTANCE_NAME=" "$config" 2>/dev/null \| head -1 \| sed 's/^INSTANCE_NAME=//')
	if [ "$name" = "$target" ]; then
	echo "$app"
	return 0
	fi
	done
	return 1
	}

	# List all .app bundles that have a config.sh (i.e., Claude instance wrappers).
	find_all_wrappers() {
	for app in /Applications/*.app; do
	[ -f "$app/Contents/MacOS/config.sh" ] && echo "$app"
	done
	}

	# Extract the instance name from a wrapper's config.sh.
	get_wrapper_instance_name() {
	local config="$1/Contents/MacOS/config.sh"
	grep "^INSTANCE_NAME=" "$config" 2>/dev/null \| head -1 \| sed 's/^INSTANCE_NAME=//'
	}

	list_instances() {
	echo "Claude Desktop Instances"
	echo "========================"
	echo ""

	# Default instance (uses Claude's built-in data directory)
	local wrapper_status="no wrapper"
	find_wrapper_for_instance "default" &>/dev/null && wrapper_status="has wrapper"
	echo " - default ($wrapper_status, built-in)"

	local count=0
	for dir in "$INSTANCES_BASE"/*/; do
	[ ! -d "$dir" ] && continue
	local name=$(basename "$dir")

	local wrapper_status="no wrapper"
	find_wrapper_for_instance "$name" &>/dev/null && wrapper_status="has wrapper"

	echo " - $name ($wrapper_status)"
	count=$((count + 1))
	done

	echo ""
	}

	diagnose() {
	echo "🔍 Claude Desktop Diagnostics"
	echo "=============================="
	echo ""

	if [ ! -d "/Applications/Claude.app" ]; then
	echo "❌ Claude.app not found in /Applications"
	echo " Download from https://claude.ai/download"
	return
	fi

	echo "✅ Claude.app installed"
	echo ""

	echo "App wrappers:"
	local found=false
	while IFS= read -r app; do
	found=true
	local instance=$(get_wrapper_instance_name "$app")
	local display=$(basename "$app" .app)
	echo " 📱 $display → instance: $instance"
	done < <(find_all_wrappers)
	$found \|\| echo " (none)"
	echo ""

	echo "Instance directories:"
	if [ -d "$INSTANCES_BASE" ]; then
	list_instance_names \| sed 's/^/ - /' \|\| echo " (none)"
	else
	echo " (no instances directory)"
	fi
	}

	# Write the static claude-launcher script into a wrapper.
	# Can be safely regenerated at any time — config.sh holds the instance name.
	write_launcher_script() {
	local wrapper_path="$1"
	local script_path="$wrapper_path/Contents/MacOS/claude-launcher"
	local main_script=$(which claude_quick.sh 2>/dev/null)

	if [ -z "$main_script" ]; then
	echo "❌ 'claude_quick.sh' not found in PATH"
	return 1
	fi

	cat > "$script_path" << LAUNCHER_EOF
	#!/bin/bash
	source "\$(dirname "\$0")/config.sh"
	exec "$main_script" "\$INSTANCE_NAME"
	LAUNCHER_EOF

	chmod +x "$script_path"
	}

	fix_wrappers() {
	echo "🔧 Fixing Claude Desktop wrappers"
	echo "=================================="

	local found=false
	while IFS= read -r app; do
	found=true
	local instance=$(get_wrapper_instance_name "$app")
	echo "🔨 Repairing: $(basename "$app") (instance: $instance)"

	if write_launcher_script "$app"; then
	echo " ✅ Regenerated launcher script"
	else
	echo " ❌ Failed to regenerate launcher"
	fi

	if [ ! -f "$app/Contents/Resources/claude-icon.icns" ]; then
	copy_claude_icon "$app/Contents/Resources"
	fi
	done < <(find_all_wrappers)

	$found \|\| echo "No wrappers found to fix."
	echo "✅ Done"
	}

	delete_instance() {
	local name="$1"

	if [ -z "$name" ]; then
	echo "Available instances:"
	list_instance_names \| sed 's/^/ - /'
	echo ""
	read -p "Instance name to delete: " name
	fi

	if [ -z "$name" ]; then
	echo "❌ Invalid instance name"
	return 1
	fi

	if is_default_instance "$name"; then
	echo "❌ Cannot delete the default instance"
	return 1
	fi

	if [ ! -d "$INSTANCES_BASE/$name" ]; then
	echo "❌ Instance '$name' does not exist"
	return 1
	fi

	local wrapper=$(find_wrapper_for_instance "$name")

	echo "⚠️ This will delete:"
	echo " - Data: $INSTANCES_BASE/$name"
	[ -n "$wrapper" ] && echo " - Wrapper: $wrapper"
	echo ""
	read -p "Type 'yes' to confirm: " confirm

	if [ "$confirm" != "yes" ]; then
	echo "Cancelled."
	return 0
	fi

	rm -rf "$INSTANCES_BASE/$name"
	[ -n "$wrapper" ] && rm -rf "$wrapper"
	echo "✅ Instance '$name' deleted"
	}

	create_app_wrapper() {
	local instance_name="$1"
	local display_name="$2"
	local wrapper_path="/Applications/Claude $display_name.app"

	if [ -d "$wrapper_path" ]; then
	read -p "⚠️ Wrapper already exists. Overwrite? (y/N): " overwrite
	[ "$overwrite" != "y" ] && [ "$overwrite" != "Y" ] && return
	rm -rf "$wrapper_path"
	fi

	mkdir -p "$wrapper_path/Contents/MacOS"
	mkdir -p "$wrapper_path/Contents/Resources"

	cat > "$wrapper_path/Contents/Info.plist" << EOF
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
	<plist version="1.0">
	<dict>
	<key>CFBundleExecutable</key>
	<string>claude-launcher</string>
	<key>CFBundleIdentifier</key>
	<string>com.anthropic.claude.$instance_name</string>
	<key>CFBundleName</key>
	<string>Claude $display_name</string>
	<key>CFBundleDisplayName</key>
	<string>Claude $display_name</string>
	<key>CFBundleVersion</key>
	<string>1.0</string>
	<key>CFBundleShortVersionString</key>
	<string>1.0</string>
	<key>CFBundlePackageType</key>
	<string>APPL</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>LSMinimumSystemVersion</key>
	<string>11.0</string>
	<key>CFBundleIconFile</key>
	<string>claude-icon</string>
	<key>NSHighResolutionCapable</key>
	<true/>
	</dict>
	</plist>
	EOF

	cat > "$wrapper_path/Contents/MacOS/config.sh" << CONFIG_EOF
	INSTANCE_NAME=$instance_name
	CONFIG_EOF

	write_launcher_script "$wrapper_path"
	copy_claude_icon "$wrapper_path/Contents/Resources"

	echo "✅ Wrapper created: $wrapper_path"
	echo " Search 'Claude $display_name' in Launchpad or drag to Dock."
	}

	prompt_wrapper_creation() {
	local instance_name="$1"

	if [ -z "$instance_name" ]; then
	echo "Available instances:"
	list_all_instance_names \| sed 's/^/ - /'
	echo ""
	read -p "Create wrapper for which instance: " instance_name
	fi

	if [ -z "$instance_name" ]; then
	echo "❌ Invalid instance name"
	return 1
	fi

	if ! is_default_instance "$instance_name" && [ ! -d "$INSTANCES_BASE/$instance_name" ]; then
	echo "❌ Instance '$instance_name' does not exist"
	return 1
	fi

	local default_suffix=$(echo "$instance_name" \| awk '{print toupper(substr($0,1,1)) substr($0,2)}')
	read -p "App name suffix (will show as 'Claude <suffix>') [$default_suffix]: " suffix
	[ -z "$suffix" ] && suffix="$default_suffix"

	create_app_wrapper "$instance_name" "$suffix"
	}

	is_default_instance() {
	[ "$1" = "default" ]
	}

	launch_instance() {
	local instance_name="$1"

	echo "🚀 Launching instance: $instance_name"

	if is_default_instance "$instance_name"; then
	open -n -a "/Applications/Claude.app"
	echo "✅ Claude Desktop launched (default)"
	else
	local instance_dir="$INSTANCES_BASE/$instance_name"
	mkdir -p "$instance_dir"
	open -n -a "/Applications/Claude.app" --args --user-data-dir="$instance_dir"
	echo "✅ Claude Desktop launched"
	echo "📂 Data: $instance_dir"
	fi

	if ! find_wrapper_for_instance "$instance_name" &>/dev/null; then
	echo "💡 Run '$0 wrapper $instance_name' to create a Dock shortcut."
	fi
	}

	# ==================== Main ====================

	echo "======================================"
	echo " Claude Desktop Multi-Instance Launcher"
	echo "======================================"

	if [ ! -d "/Applications/Claude.app" ]; then
	echo "❌ Claude Desktop not found. Install from https://claude.ai/download"
	exit 1
	fi

	# Handle subcommands
	case "$1" in
	list) list_instances; exit 0 ;;
	delete) delete_instance "$2"; exit $? ;;
	wrapper) prompt_wrapper_creation "$2"; exit $? ;;
	fix) fix_wrappers; exit 0 ;;
	diagnose) diagnose; exit 0 ;;
	esac

	# Direct instance launch
	if [ -n "$1" ]; then
	launch_instance "$1"
	exit 0
	fi

	# Interactive menu
	echo ""
	echo "1. Launch default instance"
	echo "2. Select existing instance"
	echo "3. Create new instance"
	echo "4. Delete instance"
	echo "5. Create app wrapper"
	echo "6. Diagnose problems"
	echo "7. Fix wrappers"
	echo ""
	read -p "Select (1-7): " choice

	case $choice in
	1) launch_instance "default" ;;
	2)
	list_all_instance_names \| sed 's/^/ - /'
	echo ""
	read -p "Instance name: " name
	[ -n "$name" ] && launch_instance "$name" \|\| echo "❌ No name provided"
	;;
	3)
	read -p "New instance name: " name
	if [ -z "$name" ]; then
	echo "❌ No name provided"
	elif is_default_instance "$name"; then
	echo "❌ 'default' already exists as the built-in instance"
	else
	launch_instance "$name"
	fi
	;;
	4) delete_instance ;;
	5) prompt_wrapper_creation ;;
	6) diagnose ;;
	7) fix_wrappers ;;
	*) echo "Invalid selection." ;;
	esac

	Meta (Instagram, Facebook)
	// Узлы
	157.240.253.174, 157.240.253.172, 157.240.253.167, 157.240.253.63, 157.240.253.32
	157.240.252.174, 157.240.252.172, 157.240.252.167, 157.240.252.63, 157.240.252.38
	57.144.112.34, 57.144.110.1, 157.240.205.174, 87.245.223.97

	// Подсети
	213.102.128.0/24
	204.15.20.0/22
	199.201.0.0/16
	185.89.0.0/16
	185.60.0.0/16
	179.60.0.0/16
	173.252.0.0/16
	164.163.191.64/26
	163.114.0.0/16
	163.77.128.0/17
	163.70.0.0/16
	157.240.0.0/16
	147.75.0.0/16
	142.250.0.0/15
	129.134.0.0/16
	103.4.0.0/16
	102.221.0.0/16
	102.132.0.0/16
	99.84.0.0/16
	87.245.208.0/24
	74.119.0.0/16
	69.171.0.0/16
	69.63.0.0/16
	66.220.0.0/16
	45.64.0.0/16
	31.13.0.0/16
	157.240.0.0/24
	157.240.251.0/24
	157.240.205.0/24
	173.194.10.0/24
	77.240.43.0/24
	57.144.222.0/24
	45.130.4.0/24

Starred Gists

IPA for Google Translate (phonetic transcription)

VPN IP Addresses (IP адреса ChatGPT, Copilot, Meta, Facebook, Instagram, YouTube, Medium, X ex. Twitter, Discord)

llm-wiki

LLM Wiki

The core idea

Architecture

Operations

Indexing and logging

Optional: CLI tools

Tips and tricks

Why this works

Note

Raspberry Pi 5 media server — Immich + Jellyfin + Tailscale

Raspberry Pi 5 Media Server — Commands

What you actually have to change

Step 7 — Connect (run on your computer)

Step 9 — Update the OS

Step 10 — Timezone

Steps 11–12 — Confirm you booted from the SD card

Step 13 — Identify the drive

About sda vs sda1

Step 14 — Format the drive

Step 15 — Mount it permanently

Step 16 — Confirm it survives a reboot

Step 17 — Folders

Step 18 — Docker

Step 19 — Verify Docker

Step 20 — Download Immich

Step 21 — Configure Immich

Step 22 — Start Immich

Step 23 — Verify

Steps 24–25 — Browser and phone

Step 26 — Jellyfin compose file

Step 27 — Start Jellyfin

If Jellyfin shows Restarting (133)

Steps 28–29 — Jellyfin setup (in a browser)

File naming

Step 31 — Samba

Step 32 — Samba password

Step 33 — Connect from your computer

Step 35 — Tailscale

Step 36 — Admin console (in a browser)

Steps 37–38 — Phone, then verify remotely

Quick Reference

llm-wiki

LLM Wiki

The core idea

Architecture

Operations

Indexing and logging

Optional: CLI tools

Tips and tricks

Why this works

Note

llm-wiki

LLM Wiki

The core idea

Architecture

Operations

Indexing and logging

Optional: CLI tools

Tips and tricks

Why this works

Note

llm-wiki

LLM Wiki

The core idea

Architecture

Operations

Indexing and logging

Optional: CLI tools

Tips and tricks

Why this works

Note

Lambda_API_RDS_Example.py

default-agents

AGENTS.md

Judgment and Scope

Explore and Plan

About `sda` vs `sda1`

If Jellyfin shows `Restarting (133)`