---
name: wiki-init
description: >
  Initialize a plain-markdown knowledge base (Wiki/) in the current repo.
  Use when the user says "init wiki", "set up knowledge base", "add wiki to
  this repo", or when starting a new project that needs a wiki.
  Also triggers when wiki-update or wiki-check is invoked but Wiki/ does not
  exist yet.
---

Before acting, read [the runtime guidance](../../RUNTIME.md).


# Wiki Initialization

Create a `Wiki/` knowledge base in the current repo.
The wiki is plain Markdown — no databases, no embeddings, no special tooling.
Works on GitHub, in Obsidian, in any text editor.

## When to use

- The user says "init wiki", "set up knowledge base", "add wiki to this repo".
- A new project needs its knowledge base (`project-create` invokes this).
- `wiki-update` or `wiki-check` was invoked but `Wiki/` does not exist yet.

## Steps

### 1. Ask the user for domain folders

The core structure is fixed:

```
Wiki/
  Index.md
  Status.md
  Concepts/
  Resources/
  <Domain>/         ← user chooses these
```

Ask the user what domain-specific folders to create.
Give examples based on the repo content:

- Math project: `Systems/`, `Proofs/`, `Theorems/`
- Formalization project: `Systems/`, `Proofs/`, `Concepts/`
- Software project: `Architecture/`, `APIs/`, `Modules/`
- Research project: `Experiments/`, `Methods/`, `Datasets/`

Also ask what the **code directory** should be called.
Default is `Code/`, but some projects use `Wolfram/`, `src/`, `Lean/`, etc. This affects where the project-create skill creates code files.

If the user doesn't care, pick sensible defaults based on the repo.

### 2. Create the folder structure

Create all directories and seed files.
Use empty `.gitkeep` files in folders that start empty (except `Concepts/` and `Resources/` which get populated via other skills).
Ensure `Scripts/recover_resources.sh` exists before advertising it: if absent, create `Scripts/` and copy `${PLUGIN_ROOT}/scripts/recover_resources.sh` there, preserving its executable mode.
Keep any existing helper untouched, including a customized copy; do not run recovery during initialization.

### 3. Seed Index.md

```markdown
# Wiki Index

Knowledge base for [project]. Updated after each substantial step.

## Status
- [Status](Status.md) — current state

## Work

Execution state (specs, tasks, per-session progress) lives in the top-level
`Work/` folder, not the Wiki. See `Work/README.md`.

## Concepts

(none yet)

## Resources

(none yet)

## Tour

Interactive guided walk through the project — say **"start tour"** to begin.
Tour data lives in `Tour/` (local, gitignored).

## [Domain Section]

(none yet)
```

One section per domain folder.
Link format: `[Title](Folder/File.md) — summary`.

### 4. Seed Status.md

Seed `Status.md` with the section skeleton from [wiki-update § *Update Wiki/Status.md*](../wiki-update/SKILL.md) — `Current state` reads "Wiki initialized. No articles yet.", the other sections "(none yet)".

`Status.md` summarizes the knowledge base.
Execution state — active work, next tasks, blockers — lives in `Work/README.md`, not here.

Populate with real information if the repo already has content worth summarizing.

### 5. Update AGENTS.md

Append the wiki section to the repo's `AGENTS.md` (create the file if it doesn't exist).
Use this template:

```markdown
## Knowledge Base (Wiki)

Wiki/ is a plain-markdown knowledge base maintained by the LLM. Human-readable,
no special tooling needed.

### Maintenance rules

After every substantial step, the LLM:
1. Creates or updates relevant articles in Wiki/
2. Updates Wiki/Index.md
3. Updates Wiki/Status.md
4. Adds cross-links in See also sections

The wiki is documentation — the LLM keeps it accurate automatically.
No human sign-off needed for wiki prose. Every article carries a
`[[ LLM Generated ]]` marker directly under its `# Title`.

### Human revision (code & functionality)

The LLM always presents new code, functionality, and work specs to the user for
review. It does not silently overwrite user-edited content. The revision loop:
generate → present → wait for feedback → revise or proceed.

### Work items (execution state)

Multi-session work lives in the top-level `Work/` folder (spec / tasks /
progress per item), separate from the Wiki. Run `$backlog-run` in a fresh
session to do the next task. See `Work/README.md`.

### Resources

Wiki/Resources/ holds summaries with download/clone URLs and a ## Recover
section. Resources/ (gitignored) holds actual binary files.

To rebuild all resources from wiki: Scripts/recover_resources.sh
The script parses ## Recover sections from Wiki/Resources/*.md.

### Notebooks

Notebooks about the code are artifacts: they live in Code/Artifacts/, the .md
source and the generated .nb sharing one dated stem; the .md is tracked, the .nb is not. Research
documents go in Research/Artifacts/ the same way. A document you keep
working on lives in the folder itself, and earlier versions go to Archive/.
The plugin never overwrites a file.
These are artifacts, not wiki articles — they do not go in Wiki/.

### Guided Tour

Say "start tour" for an interactive walk through the project. Tour/ is
created on demand (local, gitignored). Each section produces a narrative .md
and runnable code file. The LLM stops after each section for feedback.
```

If `AGENTS.md` does not already carry the `## Provenance` and `## Scientific journal` toggle sections (a scaffolded project gets them from `agents_template.md`), append them too, defaulting to **off**:

```markdown
## Provenance

Prompt tracking: **off**
<!-- When on, generated artifacts (notebooks, functions, wiki articles, work items)
     record their originating prompt/intent in Wiki/Prompts.md and carry an embedded
     back-pointer. Toggle with /project-provenance; see the `project-provenance` skill. -->

## Scientific journal

Scientific journal: **off**
<!-- When on, the LLM keeps a running LaTeX/Typst journal in Journal/ — a concise,
     structured, append-only stream of dated def/thm/rem/claim entries recording the
     math/physics content and main claims established, with resources cited into
     Journal/references.bib. Plain "on" = very concise; "on (verbose)" = fuller
     detail. Toggle with /paper-journal; see the `paper-journal` skill. -->
```

If `AGENTS.md` does not already contain a `Semantic line breaks:` line (a scaffolded project gets one from `code_style_template.md`), also append the source-formatting toggle so this repo carries the config:

```markdown
## Source formatting

Semantic line breaks: **on**
<!-- When on, prose in source files — markdown (.md) and LaTeX/Typst (.tex/.typ) —
     uses one sentence per line (semantic line breaks): each sentence starts on its
     own source line. Source only; rendered output is unchanged. Set to **off** to
     wrap prose into filled paragraphs. Do not reflow paragraphs onto one line; a
     blank line still separates paragraphs. Detect with:
     grep -qiE 'semantic line breaks:[[:space:]]*\*{0,2}on' AGENTS.md && echo on || echo off -->
```

### 6. Update .gitignore

Add these entries if not already present:

```
Tour/
Resources/
```

Exceptions: if the project has git submodules in `Resources/`, preserve them with lines like `!Resources/SubmoduleName/`.

`Wiki/` itself is tracked.
`Tour/` and `Resources/` (binary files) are gitignored. Artifacts are tracked, except a generated `.nb`: its `.md` source is tracked and the `.nb` is rebuilt from it.

### 7. Scan and seed articles

If the repo already has code, documentation, or other content:

1. Identify the main entities (modules, systems, proofs, experiments, etc.)
2. Create a short wiki article for each in the appropriate domain folder
3. Add entries to `Index.md`
4. Update `Status.md` with a real summary
5. Cross-link articles with relative markdown links in See also sections

Use the article format from the wiki-update skill.

## Article format

Use the article format from [wiki-update § *Create or update articles*](../wiki-update/SKILL.md) — every article carries the `*[[ LLM Generated ]]*` marker under its title.

No status headers on wiki articles — they're documentation, maintained automatically.

Seeded article prose follows the `Semantic line breaks` toggle in `AGENTS.md` § *Source formatting*.

## Backlink convention

Use standard markdown relative links so the wiki is clickable on GitHub:

```markdown
[Article Title](../Folder/Article.md)
```

Paths are relative to the current file.
Examples from `Wiki/Systems/TM.md`:
- Link to a proof: `[TM → GS](../Proofs/TMtoGS.md)`
- Link to a concept: `[Simulation Encoding](../Concepts/SimulationEncoding.md)`
- Link to a resource: `[Moore 1991](../Resources/Moore1991.md)`

From `Wiki/Index.md` (one level up from subfolders):
- `[Turing Machine](Systems/TuringMachine.md)`

## Integration with other skills

- `project-create` invokes this during scaffolding; `wiki-update` maintains what this seeds; `wiki-check` audits it.
- The article and Status skeletons are stated once in [wiki-update](../wiki-update/SKILL.md) and referenced from the steps above.
- The AGENTS.md template this skill appends is where the `project-provenance` and `paper-journal` toggles live.

## When NOT to use

- `Wiki/` already exists — use `wiki-update` (content) or `wiki-check` (health) instead.
- The repo is a throwaway experiment that will never accumulate durable knowledge.