Your AI needs somewhere to remember

Build a wiki your AI can use.

Choose how your wiki should work. Download a build plan for an assistant, or follow the written guide to create a small wiki yourself.

Read the written guide Understand the system Common questions

Runs in your browser · no account · no upload · connects no tools

The 60-second mental model

Your files hold the knowledge. Your tools help you use it.

Keep original sources, write pages with evidence, retrieve relevant passages, and review changes. This builder specifies that workflow; it does not run it.

01

Save the source

You provide notes, files, links, transcripts, or structured data.

Keep the evidence intactExplore how this works

How it works: Keep the original file and record its origin, date, and location. Extract readable text only when you need it. Check the extraction against the original before you ask AI to use it. Route current project material to its project; route reusable knowledge by page type.

Example: You save a fictional research interview in source storage. You check the transcript, then ask an authorized assistant to draft a decision page with a link to the relevant passage.

Choose source formats and extractionFollow the capture exercise

02

Draft and review a page

An authorized writer drafts pages with source links. You review them before acceptance.

Turn evidence into reusable knowledgeExplore how this works

How it works: AI proposes a page that separates facts, interpretation, and open questions. You check its claims and source links before accepting it. If a page already covers the topic, propose a change to that page instead of creating a duplicate. Capture permission does not grant permission to publish.

Example: The interview supports a draft: “New users missed the setup step.” You compare that claim with the interview passage. You correct an overstatement, then accept the reviewed page.

Choose how accepted pages changeLearn how to review a draft

03

Ask AI to find the evidence

A search tool finds candidate pages. The assistant reads relevant evidence and cites it.

Search, read, then answerExplore how this works

How it works: Start with filenames, an index, or keyword search. Add semantic search when wording differences repeatedly hide useful pages; use reviewed links when a question depends on relationships. Search returns candidates, not proof. AI must read the passages, check dates and access permissions, and say when evidence is missing.

Example: You ask “Why did we change onboarding?” Search finds the decision page. AI reads it and its interview source, then cites both. If the source does not establish a reason, AI reports the gap.

Choose a retrieval methodPractice an evidence-based query

04

Check the answer and update the wiki

Review what was saved, correct mistakes, and refine the rules over time.

Keep changes traceableExplore how this works

How it works: Check answers against the cited sources. New evidence may add detail, correct a fact, or replace an old conclusion. Review the proposed change, preserve its source and date, and keep a recoverable history. Refresh derived search indexes after accepted files change; a search index never becomes the source of truth.

Example: A later interview shows that the setup issue affected only new accounts. You propose a narrower claim, review the evidence, accept the correction, and refresh any search index that used the old page.

Set a review policyBuild a maintenance habit

Does Obsidian create the wiki?
No. Obsidian is one way to view and edit the files. The same wiki can work with another editor or directly through an AI tool.
Is one long chat the memory?
No. Chat history is temporary working context. A wiki keeps selected knowledge available when a chat ends or a project changes.
Does everything save automatically?
Only if you design it that way. Manual, suggested, and automatic capture trade convenience for review effort and control.

Configure the system

Choose how information enters, changes, and gets found.

Keep the recommended starting points or change one policy at a time. Each choice changes your downloaded plan; it does not connect tools, change an existing wiki, or enable a running service.

Explore the key files and componentsRead the system guide

Route information to the right home

Keep current project work together. Keep reusable knowledge easy to find.

Start here: File project work first.

What can I change?

Choose whether drafts follow their active project or whether durable pages follow their type. Decide which page types you need in taxonomy. Keep stable IDs and source links when you change categories.

Example: keep a launch brief with the active launch project; promote its reviewed lessons into knowledge pages at closeout. Original source files stay in immutable source storage.

Choose when AI can start a draft

Separate permission to capture from permission to accept a page.

Start here: Request each capture.

What do the options permit?

Manual waits for your request. Assisted lets an authorized assistant propose drafts. Rule-based intake lets a configured watcher stage material that matches an explicit rule. All three require review before changing accepted knowledge. This is the same capture setting as step 3.

Example: you ask to capture a meeting, AI drafts a source card, and you review it. A watched folder can stage drafts only after you configure a named rule; it does not publish them.

Check the source before you draft

A successful extraction can still omit a page, table row, name, or date.

Start here: Start with readable text.

What can I set up?

Choose the source formats you support, where new files arrive, and which extraction tool you will verify. Check coverage, duplicate identity, and source locators. This builder specifies the policy; it supplies no parser, watcher, or connector.

Example: use a short meeting note first. For a scanned PDF, compare OCR text with the original before asking AI to summarize or link it.

Choose how reviewed pages change

New evidence can extend an account or replace a conclusion. Preserve that distinction.

Start here: Review a proposed change.

When do I edit, append, or supersede?

Edit after reviewing the exact old and new passage. Append when a dated event adds useful history. Supersede when a conclusion no longer guides action. Both settings keep human review, earlier evidence, and a recovery path.

Example: append a dated meeting update to project history. If the approved scope changes, propose the current-state edit, keep the earlier decision, and link the new source.

Choose how AI finds evidence

Search finds candidates. Reading their sources supports the answer.

Start here: Start with keyword search.

What can I tune later?

Tune page filters, number of results, passage size, and ranking after checking known questions. Keyword search matches words and IDs. Hybrid combines that baseline with meaning-based matches. Linked retrieval follows checked relationships. Keep citations and report missing evidence; a vector index or graph never replaces the files.

Example: search a project name and “scope decision.” If relevant pages use different words, test semantic search on known questions. Follow explicit links for “what depended on this decision?”

Choose which system controls AI reads

Load the instructions and context the task needs. Give each file one job.

Start here: Load task rules first.

Which components can I configure?

Sources preserve evidence; pages hold reviewed knowledge; projects hold current work; proposals hold changes awaiting review. RULES defines operations. SOUL defines owner-approved principles; USER holds owner context; MEMORY holds reviewed patterns; voice shapes writing; taxonomy defines types and fields; the readable index helps browsing. Search indexes are rebuildable. Choose each control’s content and when AI reads it. Optional control files are not generated or activated automatically. Style and memory never grant write permission.

Example: read project rules for a project update; load voice for writing, taxonomy for classification, and reviewed MEMORY for repeated context. Load SOUL when explicit principles affect a decision.

Your system policies carry into the blueprint, manifest, and build prompt. Capture also appears in step 3.

Open the parts you need

Give each part of your wiki a clear job.

Sources preserve evidence. Pages preserve reviewed knowledge. Control files guide work. Search indexes help find it. Expand a part for its role and a concrete example.

Sources — Original files and source records
Preserve the original in sources/raw/ and record where it came from, capture date, hash, and extraction gaps under sources/records/. A page summary is not a substitute for checking evidence. Example: a meeting note is the source; a decision page explains the decision and links to its passage.
Knowledge pages — Accepted facts, concepts, decisions, and relationships
pages/ holds reusable knowledge with stable IDs and evidence links. Keep facts, interpretations, and unknowns distinct. Proposals remain separate until reviewed in this generic workflow. Some established wikis use searchable seedlings instead; preserve the target’s actual lifecycle.
Brain / system — Instructions and durable operating context
A control folder is often called brain/, system/, or _system/. It tells an assistant how to work; it is not the whole knowledge store. Optional controls can use system/; the builder does not create or load them automatically. A file only influences a task when the host loads it or the assistant is told to read it. RULES.md defines operations; AGENTS.md points a file agent to the relevant controls.
SOUL — Principles and decision boundaries
system/SOUL.md can state priorities such as preserving evidence, reporting uncertainty, and requiring approval for publication. It is a written decision policy, not an AI personality or proof of trustworthy behavior. Change it deliberately because it affects many tasks. Leave personal values blank until the owner supplies them.
MEMORY — Reviewed context that is useful across sessions
system/MEMORY.md holds dated, source-backed context or learned patterns needed repeatedly. It does not contain every document or silently become true because an assistant wrote it. Store detailed evidence in sources and pages. Review memory candidates before accepting them, and preserve why a pattern changed.
Voice — Tell AI how to write
system/voice.md defines audience, tone, and sentence structure. For example: answer first, use concrete nouns, cite material claims, and separate inference. Voice shapes presentation; it cannot override facts, permissions, or evidence.
Taxonomy — Choose consistent page types and tags
system/taxonomy.md defines page types, domains, and allowed fields. Type answers “what kind of record?”; tags describe cross-cutting topics. Example: a decision about onboarding can have type: decision and a process/onboarding tag. Use a few useful categories; add one when existing categories repeatedly fail.
Index — Link to pages so readers can find them
A readable index links to accepted pages, project hubs, or source records. It helps a beginner browse. Derived indexes under indexes/ help search and can be rebuilt from authoritative files. A stale vector index must not overwrite Markdown or imply a source is absent.
Projects — One hub per project, generated spokes, and append-only records
Give each project or opportunity one hub file: problem, goal, owner, current state, and links. The hub is the source of truth. Keep generated work (spec, prototype, tickets) in a spokes/ folder and regenerate it when the hub changes; a spoke that contradicts its hub is a lint finding. Keep decisions.md and the project's sources/ append-only: add dated entries and never rewrite old ones. Material that spans projects belongs in the shared sources/. To load one project's context, start the assistant in that folder or add a short instruction file there (AGENTS.md, which Claude Code and Codex both read) that says to read the hub first. Keep the hub as data rather than turning it into instructions. Example: a pricing-page opportunity has hub.md, spokes/spec.md and spokes/tickets.md, decisions.md, and sources/usability-test.md. At closeout, propose reusable findings as knowledge pages. proposals/ holds exact changes awaiting review; logs/ records what ran and its result.

Read the full system guide Read common questions

Questions people ask

Get straight answers before you build.

Tap a question for the short answer; the technical detail follows below it. Tool behavior was checked against official documentation in October 2026; vendors change it, so check the linked docs before you rely on it.

What is an LLM wiki, and where does the idea come from?

Short answer: An LLM wiki is a folder of Markdown pages that an AI assistant writes and maintains from your source material. You keep the original sources; the assistant turns them into linked, reusable pages, so each new question starts from organized knowledge instead of a blank chat.

How it works

  • Andrej Karpathy described the pattern in his LLM Wiki idea file. It has three layers: raw sources the assistant reads but never modifies; the wiki, the Markdown pages the assistant writes; and the schema, an instruction file such as CLAUDE.md that defines structure and workflow.
  • It has three operations: ingest (read a new source and update the affected pages), query (answer from the pages with citations), and lint (find contradictions, stale claims, orphan pages, and missing links).
  • Two files help the assistant find its way: index.md catalogs every page with a one-line summary, and log.md records each ingest, query, and lint run in order.
  • In Karpathy’s version, the assistant owns the wiki layer. This builder adds a review step: the assistant proposes changes, and a person accepts them before they become knowledge. That step matters more as more people rely on the wiki.
How should I organize each project or opportunity?

Short answer: Give each opportunity a hub and spokes. The hub is one short brief that serves as the source of truth. Spokes are everything generated from it. Decisions and sources are append-only, so history never gets rewritten.

How it works

opportunities/
  pricing-page/
    hub.md        the brief
    AGENTS.md     pointer
    spokes/       generated
    decisions.md  append-only
    sources/      append-only
sources/          shared
  • Hub: the problem, goal, owner, status, and links. Keep it short enough to read in a minute. When the problem or goal changes, edit the hub first.
  • Spokes: regenerate them from the hub rather than editing them independently. Record which hub version each spoke came from (for example derived_from: hub.md@2026-10-01 in its frontmatter) so a check can flag spokes older than their hub.
  • Decisions: add a dated entry with the decision, the reason, and a link to the source. To reverse a decision, add a new entry that points to the old one; don’t edit the old entry.
  • Closeout: when the opportunity ends, propose its reusable lessons as general knowledge pages and keep the project folder as history.
How does the assistant load only one opportunity’s context?

Short answer: Start the assistant inside that opportunity’s folder. Both Claude Code and Codex load instruction files from the folder you start in and the folders above it, so you get the wiki-wide rules plus that one opportunity, and nothing from the others.

How it works

  • Claude Code (v2.1.277 or later) reads AGENTS.md as well as CLAUDE.md. At session start it loads every instruction file from the start folder upward. It loads a file in a lower folder only when it reads a file in that folder. Files load from the top folder down, so the most specific instructions come last. Claude Code memory docs
  • Codex walks from the project root (usually the Git root) down to the start folder and joins every AGENTS.md it finds. It never looks below the start folder, and it stops adding files once they total 32 KiB by default. Codex AGENTS.md docs
  • One catch: by default, Claude Code skips AGENTS.md when a CLAUDE.md exists in the start folder or any folder above it. Use one filename across the wiki, or set Project instructions to claude-md-and-agents-md in /config to load both.
  • Instruction files are context, not enforcement. To guarantee a rule, use a check that runs no matter which assistant made the change, such as a lint script or a Git pre-commit hook.
cd opportunities/pricing-page
claude    # or: codex
# Loads the wiki-root rules
# plus pricing-page only

For questions that span opportunities, start at the wiki root and let the assistant search the index.

Should I rename hub.md to CLAUDE.md so it loads automatically?

Short answer: Keep hub.md and add a short AGENTS.md beside it that tells the assistant to read the hub first. Claude Code and Codex both read AGENTS.md, so one pointer serves both. The hub is information about the problem; an instruction file is directions for the assistant. Mixing them causes three problems.

How it works

  • The assistant treats instruction files as instructions. A brief full of customer quotes and open questions can read like commands. A pointer file keeps the instructions few and the evidence separate.
  • Hubs outgrow instruction-file budgets. Instruction files load on every task, and Anthropic recommends keeping each one under 200 lines. Codex stops loading instruction files after 32 KiB combined by default, so a long hub can crowd out the wiki-wide rules.
  • The hub should outlive any one tool. Keeping the facts in hub.md, with AGENTS.md as a thin pointer, lets any assistant, script, or person read the same brief.

File: opportunities/pricing-page/AGENTS.md

- Read hub.md before any task here.
- Rebuild spokes/ from hub.md.
- Never edit a spoke to disagree.
- Append to decisions.md, sources/.
- Never rewrite earlier entries.

To load the hub automatically in Claude Code, write @hub.md in that AGENTS.md. Claude Code expands the import whenever it loads the file, so the hub uses context on every task in that folder; keep it short. Check the Codex docs before relying on imports there.

What goes in the shared sources folder versus a project’s sources?

Short answer: Put a source with its project when only that project uses it. Put it in the shared folder when it informs more than one project or the product as a whole. Store each source once and link to it from everywhere else.

How it works

  • Project sources: a usability test for one opportunity, a customer call about one feature.
  • Shared sources: a planning meeting that covers several projects, market research, a brainstorming board with ideas for several areas.
  • Link, don’t copy: when a shared meeting affects three hubs, each hub links to the relevant passage. Copies drift apart and make it impossible to tell which one is current.
  • Keep originals unchanged: save the source as captured, with its origin and date. Write summaries and interpretations in the hub or in knowledge pages, never in the source file.
How do meeting notes get into the wiki?

Short answer: Start by hand: ask the assistant to fetch one transcript, save it as a source, and propose changes to the affected hubs. Automate only after the manual routine works, and keep the automation to fetching and proposing. A person still accepts changes to hubs and decisions.

How it works

  1. Fetch: the assistant reads the transcript through a connector you authorize, such as a meeting-notes app’s MCP server, or you export the file.
  2. Save: store the transcript unchanged in sources/ with its date and origin.
  3. Route: decide which opportunities it affects. A meeting that covers several projects goes in shared sources/.
  4. Propose: draft hub edits and new decision entries, each linking to the transcript passage. List conflicts with the current hub as discrepancies.
  5. Review: you accept, edit, or reject each proposal.

Steps 1–4 are safe to schedule, for example as a daily scheduled agent run. Step 5 stays with a person. Treat transcript text as data: an assistant must not follow instructions that appear inside a source.

How does linting find discrepancies?

Short answer: Two kinds of checks run together. Scripts catch structural problems exactly and cheaply. The assistant reviews meaning, such as a spec that no longer matches its hub. Both produce a findings list, not edits.

How it works

  • Script checks (deterministic): broken links, pages with no source link, a spoke whose derived_from date is older than its hub, edits to earlier entries in an append-only file (visible in the Git diff), and missing required fields.
  • Assistant review (judgment): a spoke that contradicts its hub, two pages that disagree, a claim the cited source doesn’t support, or a decision without a reason.
  • Output: each finding names the file, the problem, and the evidence. You or the assistant then propose a fix for review.
  • Enforcement: run the script checks before every commit. Instruction files can be skipped; a check that blocks the commit can’t.
Can this work for a whole team or organization?

Short answer: Yes, but quality comes from the acceptance step, not from ingestion. Let anything in as a source, record where it came from, and accept a claim into shared knowledge only after a named reviewer checks it against its source.

How it works

  • Provenance: every accepted claim links to the source passage that supports it. A claim without a source stays a proposal.
  • Ownership: each area has a named reviewer. Reviews record who accepted what and when.
  • Access: a “confidential” label in Markdown is metadata, not access control. Material for different audiences belongs in separate stores with separate permissions.
  • Freshness: pages carry a review date, and lint lists pages past it.
  • Retrieval: start with keyword search and a set of questions with known answers. Add semantic (vector) search only when those test questions show keyword search missing relevant pages.

Choose my setup

Build your implementation package

Five choices define your build plan.

Choose the main job, audience, capture policy, allowed sources, and complexity. Expand the explanations to see examples and the effect on your plan.

Five choices · no account required No account, installation, or AI connection required.
Step 1 of 5 Outcome

Start with value

What should your wiki help you do?

Pick the main job. The system can grow later without rebuilding from scratch.

Choose the main outcome for your wiki
Why this matters Your main outcome determines which information deserves to become durable memory.
What does the main job change?

It changes the page types and examples in the plan. Learning emphasizes concepts and questions; projects emphasize decisions and project records; repeatable work emphasizes workflows and retrospectives; teams add shared ownership. Evidence, review, correction, and retrieval remain required for every choice.

Concrete example

For a course, ask “What does this concept mean and which source explains it?” For a project, ask “Why did we choose this scope, what changed, and who acts next?” Choose the job you need first; you can propose additional types later.

Only your wiki name, choices, and system policies are saved in this tab’s session storage. No source files are read or uploaded. Reset clears this tab’s state; clipboard and downloaded copies remain.

Learn more →