/wiki-init

One-time setup that auto-detects your markdown directories and creates your wiki configuration.

Run /wiki-init once to set up your knowledge base. It scans your project, samples your files to understand your domain, and proposes a custom article structure before writing anything.

If a .wiki-compiler.json already exists, the command shows your current config and asks whether you want to reconfigure or abort — it will not overwrite anything without your confirmation.

Command

/wiki-init

Setup flow

1. Auto-detect directories

   The command scans your project for markdown-heavy directories — looking for folders named Knowledge/, docs/, notes/, or content/, and any directory containing 10 or more .md files. Standard non-content folders like node_modules/, .git/, and build/ are excluded automatically.

   You’ll see a summary like:

   I found 247 markdown files across 4 directories:
   - Knowledge/meetings/     (130 files)
   - Knowledge/strategy/     (42 files)
   - docs/research/          (61 files)
   - notes/                  (14 files)
   
2. Confirm your sources

   You’ll be asked three questions:

   1. What’s the name for this knowledge base? (e.g., “My Research”, “Project Alpha”, “Team Wiki”)
   2. Which directories should be compiled from? The auto-detected directories are shown with checkmarks — add or remove as needed.
   3. Where should the wiki output live? Defaults to {first_source}/wiki/.
3. Sample source files

   The command picks 10–15 representative files spread across your confirmed directories, reads the first ~500 characters of each, and identifies what kinds of content you have: meeting notes, research papers, journal entries, strategy docs, technical specs, and so on.

   This sampling step is what makes the article structure fit your actual content rather than forcing a generic template.

4. Review the proposed article structure

   Based on the sampled files, you’ll see a proposed list of 5–8 sections for each wiki article. Summary is always first and Sources is always last. The middle sections are tailored to your domain.

   Example proposals:

   Domain	Proposed sections
   Product / growth	Summary · Timeline · Current State · Key Decisions · Experiments & Results · Gotchas & Known Issues · Open Questions · Sources
   Research notes	Summary · Key Findings · Methodology · Evidence · Gaps & Contradictions · Open Questions · Sources
   Personal journal	Summary · Themes & Patterns · Progress · Reflections · Action Items · Sources
   Book notes	Summary · Characters · Themes · Plot Threads · Connections · Quotes · Sources
   Technical docs	Summary · Architecture · API Surface · Dependencies · Known Issues · Migration Notes · Sources
   Business / team	Summary · Stakeholders · Decisions · Action Items · Meeting History · Open Threads · Sources

   You can add, remove, or rename sections. Type “regenerate” to get a fresh proposal. Summary and Sources are required and cannot be removed.

5. Write configuration and create output directories

   Once you confirm the article structure, the command writes .wiki-compiler.json to your project root and creates the output directory:

   {output}/
   {output}/topics/
   {output}/compile-log.md
   

   You’ll see a summary confirming what was created, and next steps for your first compile.

What gets created

.wiki-compiler.json — your wiki configuration, stored at the project root. Contains source directories, output path, article sections, and mode. You can edit it anytime.

Output directory structure — the topics/ folder and supporting state files are created immediately. Topic articles are populated when you run /wiki-compile.

Next steps

After /wiki-init completes:

1. Run /wiki-compile to build your first wiki
2. Open {output}/INDEX.md in Obsidian to browse the result
3. Edit article_sections in .wiki-compiler.json anytime to adjust the structure
4. When ready, change "mode" in .wiki-compiler.json from staging → recommended → primary