---
name: create-wiki
description: Initialize a Karpathy-style local wiki for a topic from raw sources. Use when the user asks to "create a wiki", "start a wiki", "build a wiki", "set up a wiki", or says "I want a wiki for X". Takes source links (URLs, file paths, Gmail labels) as input.
argument-hint: <topic-name> [source1] [source2] ...
allowed-tools:
  - Read
  - Write
  - Edit
  - Glob
  - Grep
  - Bash
  - WebFetch
---

# /create-wiki — Initialize a Karpathy-style Wiki

The user wants to create a local, markdown-based, AI-maintained wiki following the Karpathy philosophy:
- Plain markdown files stored locally (portable, future-proof)
- Git-versioned
- AI-maintained via a CLAUDE.md schema
- Knowledge compounds over time as new sources are ingested

**Arguments provided:** $ARGUMENTS

---

## Step 1 — Understand the Task

Parse `$ARGUMENTS`:
- First token (if not a URL or path) = topic/project name
- Remaining tokens = source links (URLs, file paths, Gmail label names, etc.)

If the topic or working directory is unclear, ask the user before proceeding:
- "What should the wiki be called?"
- "Which folder should I create it in?"

---

## Step 2 — Scaffold the Wiki

Create this structure in the working directory (or a subdirectory named after the topic):

```
<wiki-dir>/
├── CLAUDE.md           # Schema — tells Claude how to maintain this wiki
├── raw/
│   └── sync-log.md     # Tracks last-checked timestamps per source
├── wiki/
│   ├── index.md        # Master catalog (table of all pages)
│   ├── log.md          # Append-only operation log
│   ├── contractors/    # (or relevant domain folders)
│   ├── decisions/
│   ├── approvals/
│   ├── budget/
│   ├── materials/
│   ├── systems/
│   └── rooms/
└── outputs/            # Reports, summaries
```

Adapt folder names to the topic. For a project wiki these folders make sense; for other domains use appropriate categories.

### CLAUDE.md content

Write a `CLAUDE.md` that includes:
1. **Project context** — topic, owner, key people
2. **Data sources** — list each source with reading strategy
3. **Sync tracking** — how to use `raw/sync-log.md`
4. **Wiki structure** — folder layout with descriptions
5. **Page frontmatter** — required YAML for every page
6. **Page templates** — for each page type (contractor, decision, approval, budget, material, system)
7. **Ingest workflow** — steps to read new sources and update wiki
8. **Query workflow** — how to answer questions from the wiki
9. **Lint workflow** — periodic health checks

### Page frontmatter template

Every wiki page must start with:
```yaml
---
title: Page Title
type: <category>
sources:
  - "Source: description (date)"
related:
  - "[[related-page]]"
created: YYYY-MM-DD
updated: YYYY-MM-DD
---
```

### sync-log.md format

```markdown
# Sync Log

last_checked_files: YYYY-MM-DD
last_checked_gmail: YYYY-MM-DD

## History

| Date | Source | Notes |
|------|--------|-------|
```

### wiki/index.md format

Start with a table per category. Populate rows as pages are created:
```markdown
# Wiki Index — <Topic>

## <Category 1>

| Page | Summary | Status |
|------|---------|--------|

## <Category 2>
...

_Last updated: YYYY-MM-DD_
```

### wiki/log.md format

```markdown
# Operations Log

## YYYY-MM-DD | init
Initialized wiki scaffold. Sources: <list>.
```

---

## Step 3 — Initialize Git

```bash
git init
git add .
git commit -m "Initialize wiki scaffold for <topic>"
```

---

## Step 4 — Ingest Each Source

For each source provided in `$ARGUMENTS`, ingest it now:

### File paths (local)
- **PDF**: Use `pdftotext` if available: `pdftotext "path/to/file.pdf" -`
- **DOCX/XLSX/RTF**: Convert via LibreOffice headless: `soffice --headless --convert-to txt "file" --outdir /tmp/`
- **Images (PNG/JPG)**: Read with the Read tool (Claude can see images)
- **Plain text/Markdown**: Read directly with Read tool
- **Cannot read** (encrypted formats like Protondoc): Note in log, ask user to export

### URLs (web pages)
- Fetch with WebFetch tool
- Extract key facts, decisions, people, dates

### Gmail labels
- Access via Gmail MCP connector if available
- Search threads in the label, read email bodies (not attachments)
- Focus on correspondence relevant to the topic

### For each source ingested:
1. Identify what type of information it contains
2. Create or update the relevant wiki page(s) — one page per person/company/topic
3. Use `[[wikilinks]]` for cross-references between pages
4. Add the source to the `sources:` frontmatter of every page it informs

---

## Step 5 — Update index.md and log.md

After ingesting all sources:
- Add a row to `wiki/index.md` for each new page created
- Append an entry to `wiki/log.md`:
  ```
  ## YYYY-MM-DD | ingest | <description>
  Pages created: ...
  Sources read: ...
  Cannot read: ...
  ```
- Update `raw/sync-log.md` with today's date for each source type checked

---

## Step 6 — Final Git Commit

```bash
git add wiki/ raw/
git commit -m "Initial ingest: <brief description of sources>"
```

---

## Step 7 — Report to User

Tell the user:
- How many pages were created and which categories
- What couldn't be read and why (encrypted formats, missing tools, etc.)
- What the `/` command looks like for future syncs (e.g. "run `/sync-wiki` to pick up new sources")
- Open questions or gaps in the wiki

---

## Key Principles

- **One page per entity**: one page per person, company, decision, document — not one page per source
- **Cross-reference liberally**: use `[[wikilinks]]` whenever two pages relate
- **Cite every fact**: every claim should trace back to a source in the frontmatter
- **Dates in ISO 8601**: always `YYYY-MM-DD`
- **Filenames in kebab-case**: `pierre-devriel.md`, `building-permit.md`
- **Don't copy raw files**: extract knowledge into wiki pages; keep originals where they are
- **Log everything**: every ingest session gets an entry in `wiki/log.md`