| name | second-brain |
| description | Build and maintain a Karpathy-style LLM-maintained personal wiki (a "Second Brain") as plain markdown the user owns. Use when the user wants to set up a second brain, capture/ingest a source into their notes, ask their knowledge base a question, file decisions, or keep a personal wiki organized. Triggers on ingest/query/lint requests against the vault. |
| domain | knowledge |
| confidence | high |
| source | manual — Second Brain skill |
| risk_level | low |
| required_tools | ["file_read","file_write","file_edit"] |
| triggers | ["/second-brain","second brain","ingest into my notes","add to my wiki","file this","what do my notes say about","lint my vault","consolidate my notes"] |
Second Brain
This skill teaches you to build and maintain a Second Brain: an
LLM-maintained personal wiki in plain markdown, following the pattern Andrej
Karpathy described. You own the wiki and keep it organized. The user provides
sources and asks questions. Knowledge compounds — every ingest touches a few
pages, every good question becomes a new page.
Core principle
Three layers, clear ownership:
- raw/ — immutable inputs the user provides. You append, you never delete or
rewrite. This is the audit trail.
- the wiki (
10-Notes/, 20-Projects/, 30-Areas/, 40-Resources/) —
owned and maintained by you. You summarize, link, file, and bookkeep.
- the schema (
AGENTS.md, _meta/conventions.md) — co-evolved with the
user. Propose changes; don't impose them.
House rules, always:
- One idea per page.
- Cite sources in frontmatter (
sources:) and inline where it matters.
- Flag uncertainty explicitly — never paper over a gap with a plausible guess.
- Never delete from
raw/.
- Summarize before filing — raw text goes to
raw/, distilled knowledge to the
wiki.
- Every new page links to at least one existing page (no orphans).
Precondition: the vault must be writable
The vault is usually a folder outside the harness project directory. The
file tools can only write outside the project when the folder is on the
allow-list.
Before any file operation, confirm the vault path is reachable:
-
Attempt a tiny round-trip: file_write a temp file in the vault, file_read
it back, then delete it.
-
If the write is denied, stop and tell the user to add the vault path to
allowedExternalPaths in .harness/settings.json and restart the harness:
{ "allowedExternalPaths": ["<absolute path to the vault>"] }
