Skill: ducheneadas-source/obsidian-karpathy-wiki (version 1.0.0)

--- name: obsidian-karpathy-wiki description: Operate an Obsidian knowledge base as a persistent LLM wiki using a raw-to-source-to-wiki pattern. Use when Codex or another agent needs to ingest raw notes, reconcile loose inbox material, maintain source summaries, compile formal wiki pages, write back valuable query outputs, run heartbeat maintenance, lint contradictions and stale claims, or hand off ongoing wiki operations to another agent. --- # 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](references/object-model.md) before restructuring a vault. Read [references/workflow.md](references/workflow.md) before ingest, query, lint, or migration work. Read [references/adaptation-checklist.md](references/adaptation-checklist.md) before adapting this skill to a specific user's vault. Read [references/heartbeat.md](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

path: agents/openai.yaml
content: interface:
  display_name: "Obsidian Karpathy Wiki"
  short_description: "Operate an Obsidian vault as a living LLM wiki."
  default_prompt: "Use this skill to ingest raw notes, maintain source summaries, compile formal wiki pages, write back valuable query outputs, and run heartbeat maintenance for an Obsidian knowledge base."


path: references/adaptation-checklist.md
content: # Adaptation Checklist

Use this when another user wants to adopt the skill in a different vault.

## Customize First

- vault root path
- raw folder names
- output folder names
- whether root loose notes should be auto-moved
- whether a compile or staging layer exists
- preferred formal page categories
- domain names

## Verify These Files Exist

- governance file such as `CLAUDE.md`
- `wiki/index.md`
- `wiki/log.md`
- at least one maintenance instruction file or skill

## Make These Decisions Explicit

- what counts as raw
- what counts as output
- what can be promoted into formal knowledge
- whether principles are first-class pages
- where loose root notes should go
- whether query outputs should always be saved or only saved selectively

## Good Defaults

- keep raw read-only by default
- keep outputs out of the formal wiki by default
- use source pages as the bridge
- make questions, methods, and decisions the main axis
- add principles when the user needs stronger "why" and "theory" support
- treat outputs as reusable query artifacts and future write-back sources


path: references/heartbeat.md
content: # Heartbeat

Use heartbeat as recurring vault maintenance, not as a passive status message.

## Good Heartbeat Tasks

- scan the vault root for new loose notes
- scan the raw inbox for unread material
- detect source pages that were never promoted
- detect formal pages with no source support
- detect questions with no methods
- detect methods and decisions that are missing principle-level explanation
- detect stale assumptions in decision pages
- detect contradictions between key pages
- detect query outputs that should be written back

## Recommended Cadence

### Daily

- check root loose notes
- check raw inbox
- create missing source summaries

### Weekly

- run compile over recent source and staging material
- promote stable methods, decisions, and principles
- review and backfill high-value outputs
- update index and log

### Monthly

- merge duplicates
- demote overly noisy pages
- identify stale governance and stale assumptions
- review whether the object model still fits the domain

## Output Rule

Heartbeat should produce one of two outcomes:

- direct maintenance work
- a concrete maintenance findings page

Avoid empty heartbeat reports unless the user explicitly asks for status-only output.


path: references/object-model.md
content: # Object Model

Use this model when designing or operating a vault as a persistent LLM wiki.

## Main Axis

### Questions

Use for recurring user problems.

A good question page answers:

- what is the problem
- why it matters
- which methods apply
- which decisions constrain the answer
- which sources support it

### Methods

Use for stable ways of doing something.

A good method page includes:

- definition
- applicable scenario
- standard steps
- common pitfalls
- related questions
- sources

### Decisions

Use for choices that need rationale.

A good decision page includes:

- background
- options
- tradeoffs
- conclusion
- reuse condition
- sources

## Explanation Layer

### Principles

Use for "why this stays true across situations."

Promote principles only when they explain more than one nearby method or decision, or when they capture a durable invariant in the system.

### Concepts

Use for concept boundaries, terminology, and abstraction support.

### Entities

Use for people, companies, projects, tools, or platforms that matter repeatedly.

## Evidence Layer

### Sources

Use for summaries of raw material.

A source page is the bridge between raw notes and formal knowledge. It should not try to be both evidence and final conclusion.

## Derived Layer

### Outputs

Use for reusable answers, syntheses, comparison tables, and analysis deliverables created during query work.

Outputs are not automatically formal pages, but they often become future source material for promotion.

## Main Principle

Do not let raw material, source summaries, formal conclusions, and query outputs collapse into the same page type.


path: references/workflow.md
content: # Workflow

## Ingest

Use this when new material enters the vault.

1. Read the raw note, article, reflection, or draft.
2. Decide whether it is source material, output material, or already-stable formal knowledge.
3. If it is a loose root note, move it into a raw inbox unless the user wants otherwise.
4. Create or update a source summary page.
5. Extract the minimum stable upgrades:
   - question
   - method
   - decision
   - principle
   - concept
   - entity
6. Update index and log.

## Query

1. Read the index.
2. Start from question, method, and decision pages.
3. Pull principles for "why", and sources for evidence.
4. Save reusable outputs back into the wiki.
5. Revisit saved outputs during later maintenance and decide whether to promote them.

## Lint

Look for:

- orphan formal pages
- weak source-to-formal connections
- repeated questions without shared methods
- methods without boundaries
- decisions without current validity
- contradictions between pages
- stale claims superseded by newer sources
- principles that are not actually more general than adjacent methods
- outputs accumulating without write-back

## Migration

When converting an existing vault:

1. Do not immediately archive old material.
2. First classify old material into source batches.
3. Create source summaries.
4. Promote only the strongest stable themes.
5. Create or update outputs for useful existing syntheses.
6. Archive duplicates, stale governance, and obsolete copies last.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)