Skill: teki-ai/karpathy-wiki (version 0.1.1)

--- name: karpathy-wiki description: Build, maintain, query, and lint a persistent markdown knowledge wiki that sits between raw sources and final answers. Use when managing a personal or team wiki, ingesting notes, articles, transcripts, reports, or research into a structured knowledge base, updating index and log pages, creating or revising topic, entity, concept, source, or analysis pages, answering questions from an existing wiki, or checking a wiki for contradictions, stale claims, missing links, orphan pages, duplicate pages, and schema drift. Best for Obsidian-friendly, plain markdown, or git-backed wikis where the agent should incrementally compile knowledge instead of re-deriving it from raw documents on every query. --- # Karpathy Wiki Maintain a persistent markdown wiki that compiles knowledge over time. Treat raw sources as immutable, treat the wiki as the maintained artifact, and keep structure and conventions consistent so future sessions can continue the work. ## Core model Operate with three layers: 1. `raw sources/` or equivalent input area, read-only source material 2. `wiki/` or equivalent markdown knowledge base, editable compiled knowledge 3. `schema` document that defines folder layout, naming, citation style, and workflows Prefer updating the wiki over answering from scratch. When useful work is produced during analysis or Q&A, file the result back into the wiki as a reusable page. ## Default wiki structure If the user does not already have a schema, propose a simple markdown-first layout like: ```text wiki/ index.md log.md schema.md sources/ pages/ topics/ concepts/ entities/ analyses/ ``` Adapt to the user's existing layout instead of forcing this one. ## Operating modes ### 1. Ingest Use when a new source is added. Workflow: 1. Read the source 2. Identify key topics, entities, concepts, dates, claims, and open questions 3. Create or update a source summary page if the wiki uses source pages 4. Update affected topic, entity, concept, or analysis pages 5. Add or repair internal links 6. Update `index.md` 7. Append a concise entry to `log.md` 8. Record uncertainties, contradictions, or follow-up questions explicitly During ingest, prefer touching a small number of clearly relevant pages over creating a large number of weak pages. Create a new page only when at least one of these is true: - the concept or entity is likely to recur - the page would receive meaningful links from multiple places - the content would otherwise make an existing page too broad or noisy Otherwise, expand an existing page. ### 2. Query Use when the user asks a question against the wiki. Workflow: 1. Read `index.md` first when available 2. Identify the most relevant wiki pages 3. Synthesize from the wiki before falling back to raw sources 4. Cite the wiki pages and, when appropriate, the underlying sources 5. If the answer creates durable value, save it as a new or updated analysis page 6. Update `index.md` if a new page is created 7. Append to `log.md` if the wiki treats queries as first-class events Prefer answers that preserve distinctions between: - facts directly supported by sources - synthesis across multiple pages - speculation or open questions ### 3. Lint Use when checking wiki health. Look for: - orphan pages with few or no inbound references - duplicate pages with overlapping scope - stale claims superseded by newer sources - contradictions between pages - missing cross-links - important concepts mentioned repeatedly without their own page - schema drift, inconsistent titles, inconsistent frontmatter, broken naming - analysis pages that should have been linked from topic/entity pages but were not When linting, prefer producing an actionable list of fixes grouped by severity: - critical consistency issues - likely quality improvements - optional structural improvements ## Page conventions Favor concise pages with clear structure. A useful default shape is: ```markdown # Page Title ## Summary Short synthesis of what this page is about. ## Key points - Bullet points of durable knowledge ## Details Longer notes, evidence, chronology, or structured sections ## Related - [[Other Page]] ## Sources - [[Source Page A]] - [[Source Page B]] ``` ``` If the wiki uses frontmatter, keep it minimal and consistent. Good optional fields include: - `type` - `aliases` - `status` - `updated` - `source_count` - `tags` Do not invent elaborate metadata unless the user actually benefits from it. ## Naming and linking rules Use stable, human-readable file names. Prefer: - one canonical page per concept/entity/topic - redirects or aliases only when the wiki supports them - explicit wiki-links between related pages - consistent singular vs plural naming When unsure whether two pages should merge, keep both only if they have clearly different scope. Otherwise merge and leave one canonical page. ## Index and log rules ### `index.md` Treat `index.md` as the navigational catalog. Include: - page link - one-line summary - optional grouping by category - optional source counts or update dates if the wiki uses them Keep it skimmable. It should help future sessions decide what to read next. ### `log.md` Treat `log.md` as append-only chronology. Use a parseable heading style such as: ```markdown ## [2026-04-12] ingest | Source title ``` Keep entries concise: - what was ingested, queried, or linted - which pages were created or updated - any unresolved issues ## Quality bar A good wiki update should: - preserve source fidelity - surface contradictions instead of hiding them - strengthen cross-links - reduce future work - make later questions cheaper to answer Do not overwrite uncertainty with confident prose. When the evidence is mixed, say so clearly. ## Working with existing wikis If a wiki already exists: 1. Inspect its schema, folder layout, and naming style 2. Follow the existing conventions unless they are clearly harmful 3. Repair inconsistencies gradually instead of rewriting the whole wiki at once 4. Propose larger schema changes before making them ## Obsidian-friendly guidance For Obsidian-style vaults: - prefer markdown files and wiki-links like `[[Page Name]]` - keep filenames readable - avoid fragile generated syntax unless the user already uses it - if frontmatter exists, preserve formatting and field order when practical - make pages pleasant to browse by humans, not only optimized for machine parsing ## Deliverables by task ### For ingest requests Deliver: - source summary or source page update - updated related pages - `index.md` update - `log.md` entry - short note on contradictions or open questions ### For query requests Deliver: - answer with citations - optional durable analysis page if worth keeping - any relevant index or log updates ### For lint requests Deliver: - prioritized issue list - concrete proposed edits - optional patch plan for high-value fixes ## References - Read `references/getting-started.md` when the user needs a minimal starter schema for a new wiki. - Read `references/wiki-patterns.md` for core page templates and structural heuristics. - Read `references/ingest-patterns.md` when ingesting a new source into the wiki. - Read `references/query-patterns.md` when answering questions from the wiki or deciding whether to save a durable analysis page. - Read `references/lint-checklist.md` when checking the wiki for contradictions, stale claims, weak links, duplicates, or structural drift.

path: references/getting-started.md
content: # Getting Started with an LLM Wiki

Use this reference when a user wants a simple starting point for a new markdown knowledge wiki.

## Minimal starter layout

```text
wiki/
  index.md
  log.md
  schema.md
  sources/
  pages/
    topics/
    concepts/
    entities/
    analyses/
```

## Minimal `schema.md`

```markdown
# Wiki Schema

## Purpose
Describe what this wiki is for and what kinds of source material belong in it.

## Source of truth
Treat files in `sources/` as immutable inputs. Update compiled knowledge in `pages/`, `index.md`, and `log.md`.

## Page types
- topic: broad subject pages
- concept: reusable ideas or abstractions
- entity: people, companies, products, places, organizations
- analysis: comparisons, syntheses, memos, decisions
- source: summaries of individual source documents

## Naming rules
Use stable, human-readable titles. Prefer one canonical page per concept or entity.

## Citation rules
Link related pages with wiki-links. List supporting source pages in a `Sources` section.

## Workflows
- ingest: summarize a source and update affected pages
- query: answer from the wiki first, then file durable analysis back into the wiki
- lint: check for contradictions, stale claims, missing links, and orphan pages
```
```

## Minimal `index.md`

```markdown
# Index

## Topics

## Concepts

## Entities

## Analyses

## Sources
```
```

## Minimal `log.md`

```markdown
# Log
```
```

## First-ingest checklist

When starting a fresh wiki:
1. create `schema.md`
2. create empty `index.md`
3. create empty `log.md`
4. ingest one high-value source
5. create only the pages that are clearly justified
6. keep summaries short and links explicit

## Good default habits

- prefer updating existing pages over spraying new ones everywhere
- make uncertainty visible
- keep pages pleasant for humans to browse
- store durable syntheses as analysis pages instead of leaving them trapped in chat history


path: references/ingest-patterns.md
content: # Ingest Patterns

Use this file for concrete templates and heuristics during source ingestion.

## Source summary template

```markdown
# Source: <title>

## Summary
2-6 sentence summary.

## Key takeaways
- durable point
- durable point

## Entities and concepts
- [[Entity A]]
- [[Concept B]]

## Claims
- specific claim that can be checked later

## Open questions
- unresolved question

## Related wiki pages
- [[Topic Page]]

## Provenance
- Author:
- Date:
- URL or local path:
```
```

## Update decision heuristic

Before creating a page, check:
- does a page already exist for the same concept under a slightly different name
- would a section in an existing page be enough
- will this page likely be linked again in the future

If not, avoid creating the page.

## Contradiction pattern

```markdown
## Tensions and contradictions
- New source claims X
- Existing page or older source claims Y
- Best current interpretation: Z
- Confidence: low | medium | high
```
```

## Log entry pattern

```markdown
## [YYYY-MM-DD] ingest | <title>
- Created: [[Source: Title]]
- Updated: [[Topic A]], [[Entity B]]
- Notes: unresolved question about <claim>
```
```


path: references/lint-checklist.md
content: # Wiki Lint Checklist

Use this checklist when reviewing a markdown knowledge wiki.

## Structural checks

- Does the wiki have a clear schema or at least stable conventions?
- Is `index.md` still useful as a navigation map?
- Is `log.md` append-only and parseable?
- Are page names stable and human-readable?

## Content checks

- Do important pages start with a short summary?
- Are claims supported by source pages or clearly marked as synthesis?
- Are contradictions surfaced instead of smoothed over?
- Are outdated claims still presented as current?

## Linking checks

- Do major pages link to related concepts and entities?
- Are there orphan pages?
- Are there duplicate pages that should be merged?
- Are durable analysis pages linked from the pages they affect?

## Reporting pattern

```markdown
# Wiki Lint Report

## Critical consistency issues
- issue

## Important quality improvements
- issue

## Optional structure improvements
- issue
```
```

## Fix prioritization

Prioritize:
1. contradictions and stale claims
2. duplicate or ambiguous canonical pages
3. broken navigation and missing cross-links
4. cosmetic consistency improvements


path: references/query-patterns.md
content: # Query Patterns

Use this file for common answer shapes and decisions about when to file results back into the wiki.

## Answer structure

A good default answer shape is:

```markdown
## Answer
Short answer first.

## Why
- point supported by [[Page A]]
- point supported by [[Page B]]

## Uncertainty
- ambiguity or missing evidence

## Related pages
- [[Analysis X]]
- [[Topic Y]]
```
```

## Analysis page template

Use this when a query result should become a durable page.

```markdown
# Analysis: <short title>

## Question
What was being asked.

## Short answer
2-4 sentence synthesis.

## Key findings
- finding one
- finding two

## Evidence and reasoning
Longer synthesis grounded in relevant wiki pages.

## Uncertainty
Open questions, weak evidence, or conflicting claims.

## Related
- [[Topic A]]
- [[Entity B]]

## Sources
- [[Source: Example]]
- [[Source: Example 2]]
```
```

## Filing heuristic

File the result back into the wiki when:
- it combines information from multiple pages
- it creates a reusable comparison or recommendation
- it resolves or clarifies a recurring question
- it would be annoying or expensive to reconstruct later

Do not file it when:
- the answer is obvious from one page
- the answer is ephemeral or conversational only
- the result adds clutter without improving retrieval

## Log entry pattern

```markdown
## [YYYY-MM-DD] query | <question>
- Read: [[Topic A]], [[Analysis B]]
- Created: [[Analysis: <short title>]]
```
```

## Citation habit

Prefer citing wiki pages first. Add source-page citations when the user needs tighter traceability or when the claim is likely to be questioned.


path: references/wiki-patterns.md
content: # Wiki Patterns Reference

Use this file for concrete templates and operational patterns when working on a markdown knowledge wiki.

## Recommended source summary template

```markdown
# Source: <title>

## Summary
2-6 sentence summary of the source.

## Key takeaways
- Point one
- Point two
- Point three

## Entities and concepts
- [[Entity A]]
- [[Concept B]]

## Claims
- Claim with enough specificity to be checked later

## Open questions
- Question one

## Related wiki pages
- [[Topic Page]]

## Provenance
- Author:
- Date:
- URL or local path:
```
```

## Recommended topic page template

```markdown
# <Topic>

## Summary
Short synthesis.

## Current understanding
- Durable point
- Durable point

## Important nuances
- Caveat or ambiguity

## Timeline or developments
- Date: event

## Open questions
- Unknown or disputed point

## Related
- [[Related Page]]

## Sources
- [[Source: Example]]
```
```

## Contradiction handling pattern

When two sources disagree, do not silently merge them into one narrative.

Use a section like:

```markdown
## Tensions and contradictions
- Source A claims X
- Source B claims Y
- Current best interpretation: Z
- Confidence: low | medium | high
```
```

If the contradiction is important and recurring, create a dedicated analysis page.

## Page creation heuristics

Create a page when:
- the concept/entity appears in multiple sources
- the page can become a hub for links
- the content is substantial enough to deserve its own summary

Do not create a page when:
- the term is mentioned only once and is not central
- the resulting page would contain only one weak bullet
- the information fits naturally into an existing page

## Index organization patterns

Common groupings for `index.md`:

```markdown
# Index

## Topics
- [[Topic A]] - one line

## Concepts
- [[Concept A]] - one line

## Entities
- [[Entity A]] - one line

## Analyses
- [[Analysis A]] - one line

## Sources
- [[Source: Example]] - one line
```
```

Keep descriptions compact. Prefer one useful line over verbose summaries.

## Log entry pattern

```markdown
## [YYYY-MM-DD] ingest | <title>
- Created: [[Source: Title]]
- Updated: [[Topic A]], [[Entity B]]
- Notes: contradiction with [[Older Source]] on <claim>
```
```

For a query:

```markdown
## [YYYY-MM-DD] query | <question>
- Read: [[Topic A]], [[Analysis B]]
- Created: [[Analysis: <short title>]]
```
```

## Query filing heuristic

Save a query result back into the wiki when it has any of these qualities:
- cross-source synthesis that would be expensive to redo
- comparison between multiple entities or approaches
- a new framing or insight that changes how related pages should read
- a decision memo the user may revisit

Do not save trivial one-off answers.

## Minimal schema document template

```markdown
# Wiki Schema

## Purpose
Describe what this wiki is for.

## Folder layout
Describe top-level directories.

## Page types
- topic
- concept
- entity
- analysis
- source

## Naming rules
State canonical naming conventions.

## Citation rules
Describe how pages cite sources and related pages.

## Update workflow
Describe ingest, query, and lint workflows.
```
```

## Human factors

Optimize for a human browsing the wiki later.

Prefer:
- short summaries near the top
- sections with stable names
- explicit related pages
- visible uncertainty

Avoid:
- giant walls of generated prose
- excessive metadata
- duplicate pages with overlapping scope
- hiding evidence behind polished summaries


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