Karpathy brain template

This page contains a ready-to-paste template for setting up an opinionated “Karpathy brain” workspace inside Orimora. It complements the conceptual setup in the marketing docs and is meant to be copied as the README of your Brain collection.

How to use this template

In Orimora, create a top-level collection called Brain (or whatever name you prefer).
Inside it create a single document titled README (or _index).
Copy the markdown block below into that document.
Adapt the project / people names to yours; keep the structure.
Reference the document in your AI assistant’s system prompt with: “Before any brain operation, read the doc titled ‘README’ in the Brain collection.”

The README acts as a mini-onboarding for the LLM at every session: it learns where things live and which tags exist for ~150–200 tokens, instead of guessing.

Collection structure (suggested)

Create these as sub-collections inside Brain upfront. The MCP tools quick_capture and journal_append will populate Inbox and Journal for you.

Sub-collection	Purpose
`Inbox`	Rolling capture document; thoughts you haven’t processed yet.
`Journal`	One doc per day (`Journal YYYY-MM-DD`), auto-created by `journal_append`.
`Decisions`	Distilled decisions with the question, the answer, and the why.
`People`	One doc per relevant person (coffee chats, context, follow-ups).
`Projects/<name>`	One hub doc per running project, linking sub-docs and decisions.
`Reading`	Notes on books, articles, talks.

In Settings → Developers → MCP, pin Brain/Inbox as the inbox collection and Brain/Journal as the journal collection.

The README — copy this into your Brain

# Brain — README

This is my second brain. It is read and written by AI assistants
through Orimora's MCP server. The conventions below let the assistant
file things in the right place without asking.

## Layout

- `Inbox` — quick captures; **never search here for answers**
- `Journal` — one doc per day; what happened, what I noticed
- `Decisions` — final calls with the _why_. Use when answers are settled.
- `People/<First Last>` — what I know about a person
- `Projects/<name>` — hub doc per project, links to sub-docs
- `Reading` — book / article notes, one doc per source

## Tag schema (controlled list — do not invent new ones without me)

- `#capture` — raw inbox item, not yet processed
- `#decision` — completed decision with rationale
- `#followup` — open action item I owe someone (or myself)
- `#question` — open question I don't have an answer for yet
- `#insight` — non-obvious learning worth remembering

Combinations matter: `#followup` without `#decision` = open loop.

## Naming conventions for new docs

| Type         | Title format                     | Example                              |
| ------------ | -------------------------------- | ------------------------------------ |
| Meeting note | `Meeting · YYYY-MM-DD · <topic>` | `Meeting · 2026-05-14 · Q3 planning` |
| Person       | `<First Last>`                   | `Lena Schmidt`                       |
| Decision     | `Decision · <short question>`    | `Decision · Switch DB host?`         |
| Project      | `Project · <name>`               | `Project · Karpathy brain`           |
| Reading note | `<Author> — <Title>`             | `K. Beck — Tidy First`               |

Always prefer a noun-shaped title over a sentence. Future-me searches
by topic, not by mood.

## How the assistant should behave

1. **Search first**: before answering anything I might already have
   notes on, run `search_documents`. Be explicit: tell me what you
   found and what you didn't.
2. **Capture proactively**: if I share a non-trivial fact, decision,
   or open question, write it down without asking permission:
    - Quick thought → `quick_capture(content)`
    - Today's events → `journal_append(content)`
    - Structured entry → `create_document` in the matching collection
3. **Append, don't overwrite**: when updating an existing doc, prefer
   `append_to_document` or `update_document` with a partial change.
   Never replace an entire doc unless I ask for it.
4. **Confirm before deleting**: never call `delete_document` without
   stating what will be deleted and why.
5. **Use the tag schema**: never invent new tags. If a topic genuinely
   doesn't fit, ask me before introducing one.
6. **Mind the audit trail**: assume I will read everything you write
   later. Be terse, factual, and link to sources where possible.

## Weekly distillation (Sunday, ~15 minutes)

Run this prompt against the assistant once a week:

> Read the Inbox doc and all entries from the past 7 days in Journal.
> Group them thematically. For each group, suggest:
>
> 1. Whether it belongs in Decisions, Projects, People, or Reading.
> 2. A target document title.
> 3. A 2-sentence summary suitable for that target doc.
>    Do **not** write anything yet — show me the plan first.
>    After I confirm, perform the moves with `create_document` /
>    `append_to_document` and tag the source entries with `#processed`.

## What does NOT belong here

- Passwords, API keys, secrets — use a password manager.
- Personally identifiable information about third parties without their consent.
- Drafts I want kept hidden — use a separate private collection
  with no API-key access.

## Bootstrap log

- _2026-05-14_ — Brain initialized from
  [Orimora's Karpathy brain template](https://docs.orimora.com/guides/karpathy-brain-template/).

After pasting

Replace the bootstrap-log line with today’s date.
Set the API key’s restrictedMode to true if other team members share the workspace, and grant the key write access only to Brain/*.
Add a stable system prompt to your AI assistant that points at this README.

Iterating on the template

Treat the README as a living convention file. After ~2 weeks of real use:

Drop sub-collections you never wrote into.
Promote tags you keep wishing for.
Tighten naming conventions that the assistant misinterpreted.

When you change the README, tell the assistant explicitly in the next session that the conventions changed — many models cache the system-prompt context aggressively.