Obsidian Karpathy Wiki#

Overview#

Use this skill to maintain an Obsidian vault as a persistent, compounding knowledge base instead of a passive note archive.

The core pattern is:

• raw material enters the vault
• the agent summarizes it into sources
• stable conclusions are promoted into formal wiki pages
• valuable query results are saved into outputs
• outputs can later be written back into formal knowledge

This skill is designed for an agent that does recurring maintenance, not just one-off cleanup.

Read references/object-model.md before restructuring a vault. Read references/workflow.md before ingest, query, lint, or migration work. Read references/adaptation-checklist.md before adapting this skill to a specific user's vault. Read references/heartbeat.md before setting up recurring maintenance behavior.

Core Idea#

Do not treat the goal as organizing files.

Treat the goal as compiling knowledge once and then keeping it current.

A good vault maintained with this skill should let the agent answer questions by reading a living wiki, not by rediscovering everything directly from raw documents every time.

Recommended Vault Shape#

Prefer this logical structure, even if physical names differ:

• raw/
• compile/ or another staging layer
• wiki/
• an output layer such as outputs/ or content-outputs/
• governance files such as CLAUDE.md and a maintenance skill

Within wiki/, prefer this formal structure:

• index.md
• log.md
• questions/
• methods/
• decisions/
• principles/
• domains/
• concepts/
• entities/
• sources/
• outputs/

Questions, methods, and decisions are the main navigation axis. Principles explain why methods and decisions stay valid across situations. Sources are evidence bridges. Outputs are reusable query artifacts.

Operating Model#

Raw#

Raw material is source-of-truth input.

Do not treat raw notes as formal knowledge by default.

Loose notes in the vault root should usually be treated as temporary inbox material and moved into a raw inbox folder unless the user explicitly wants them to remain in place.

Sources#

wiki/sources/ is the bridge between raw material and formal knowledge.

A source page should summarize:

• what the material says
• which questions it informs
• which methods it supports
• which decisions it changes
• which principles it strengthens or challenges

Formal Pages#

Promote stable knowledge into:

• questions/
• methods/
• decisions/
• principles/

Avoid creating many thin formal pages from a single source.

Outputs#

Save high-value query results into wiki/outputs/.

Examples:

• syntheses
• comparison tables
• structured analysis
• decision memos
• topic briefs

Outputs are not automatically formal knowledge, but they are often new source material for future write-back.

Core Operating Loop#

1. Ingest#

When new material appears:

1. Read the source.
2. If a loose note appears in the vault root, treat it as inbox material.
3. Move loose inbox notes to a human raw inbox folder unless the user explicitly wants them to remain in place.
4. Create or update a wiki/sources/ page.
5. Extract only the stable upgrades:
   • question
   • method
   • decision
   • principle
   • concept
   • entity
6. Update only the few formal pages that truly benefit.
7. Update wiki/index.md.
8. Append a record to wiki/log.md.

Do not explode one source into many thin pages.

2. Query#

When answering a user question:

1. Read wiki/index.md first.
2. Read the most relevant question, method, and decision pages.
3. Read principle, concept, entity, and source pages as supporting context.
4. Produce a structured answer.
5. If the answer is reusable, save it under wiki/outputs/.
6. Decide whether the output should later be written back into formal pages.

3. Weekly Compile#

Use weekly compile to:

• review the last 5-7 days of source and staging material
• extract repeated questions
• promote stable methods
• update decisions if assumptions changed
• promote principles when repeated patterns explain why methods remain valid
• update domain maps, index.md, and log.md

4. Lint#

Check for:

• questions with no linked methods
• methods with no scenario or caveat
• decisions with stale assumptions
• principles that duplicate lower-value pages
• source pages not connected to formal knowledge
• pages that contradict each other
• stale claims superseded by newer sources
• loose notes that never entered the ingest flow
• high-value outputs that should have been written back

5. Backfill#

Treat output folders as write-back sources.

Backfill only:

• reusable methods
• recurring questions
• strategic decisions
• principle-level lessons

Do not promote finished drafts directly into formal wiki pages.

Heartbeat Rule#

Heartbeat should mean recurring maintenance, not empty status pings.

A good heartbeat checks:

• whether new loose notes appeared
• whether raw inbox has unread material
• whether source pages are piling up without promotion
• whether formal pages are missing principle-level explanation
• whether the vault has new orphan pages, stale assumptions, or contradictions
• whether query outputs are accumulating without write-back

Heartbeat should lead to either:

• direct maintenance work
• or a concrete maintenance findings page

Publishing Safety#

When publishing or sharing this skill:

• do not hardcode a specific local path
• do not include private automation ids
• do not include personal account names or bot nicknames
• do not assume the output folder must use one particular language name
• keep user-specific rules in a separate private operator layer if needed

Writing Rules#

• Use Markdown only.
• Use YAML frontmatter on formal pages.
• Use Obsidian wiki links.
• Keep source material distinct from formal conclusions.
• Prefer durable formal page titles over date-based titles.
• Treat loose root notes as temporary inbox material.

Handoff Rule#

This skill is suitable as a public foundation for persistent Obsidian wiki maintenance.

For a private deployment, pair it with a separate vault-specific governance file that defines:

• the actual vault path
• exact folder names
• any automations or heartbeat schedule
• user-specific output folders
• domain-specific operating rules