Article Sections

Customize the section structure for your compiled wiki articles.

Every topic article in your wiki follows the same section structure. You control that structure through the article_sections array in .wiki-compiler.json.

How sections are generated

When you run /wiki-init, the compiler samples 10–15 representative files from your source directories and reads the title and opening content of each. Based on what it finds — meeting notes, research papers, strategy docs, journal entries, technical specs — it proposes a set of sections that fit your domain.

You review the proposal and can add, remove, or rename any section before the config is written. Once you approve, the structure is saved to .wiki-compiler.json.

The article_sections config

"article_sections": [
  { "name": "Summary", "description": "standalone briefing of the topic", "required": true },
  { "name": "Key Findings", "description": "main discoveries and insights" },
  { "name": "Methodology", "description": "approaches and methods used" },
  { "name": "Open Questions", "description": "unresolved threads and gaps" },
  { "name": "Sources", "description": "backlinks to all contributing files", "required": true }
]

Each entry has three fields:

Field	Required	Description
name	Yes	The section heading that appears in every compiled article
description	Yes	Tells the compiler what content belongs in this section
required	No	If true, the section cannot be removed. Only Summary and Sources carry this flag.

Rules

• Summary is always first. It must be a standalone briefing — someone reading only that section should understand the current state of the topic without opening any source file.
• Sources is always last. It contains backlinks to every source file that contributed to the article, so you and Claude can trace the wiki back to raw files when needed.
• Summary and Sources cannot be removed. They are marked "required": true and the compiler enforces this on every run.
• All other sections are yours to define. You can add, remove, or rename them freely.

Removing a section from article_sections does not delete existing content from already-compiled articles. It stops the compiler from populating that section in future runs. Run /wiki-compile after editing to rebuild articles with the updated structure.

Domain examples

The sections that work well depend on the kind of content you’re compiling. /wiki-init proposes sections based on your actual files — the examples below show what that looks like in practice.

Product / growth

Good for teams tracking experiments, metrics, and evolving strategy.

"article_sections": [
  { "name": "Summary", "description": "standalone briefing of the topic", "required": true },
  { "name": "Timeline", "description": "key events in chronological order" },
  { "name": "Current State", "description": "active metrics, live experiments, and open questions" },
  { "name": "Key Decisions", "description": "decisions that shaped the current approach, with rationale" },
  { "name": "Experiments & Results", "description": "experiment name, status, and key finding" },
  { "name": "Gotchas & Known Issues", "description": "traps, workarounds, and things to watch out for" },
  { "name": "Open Questions", "description": "unresolved threads and next investigations" },
  { "name": "Sources", "description": "backlinks to all contributing files", "required": true }
]

Research notes

Good for literature reviews, experiment logs, and academic notes.

"article_sections": [
  { "name": "Summary", "description": "standalone briefing of the topic", "required": true },
  { "name": "Key Findings", "description": "main discoveries and insights" },
  { "name": "Methodology", "description": "approaches and methods used" },
  { "name": "Evidence", "description": "data points and supporting material" },
  { "name": "Gaps & Contradictions", "description": "conflicting findings and open questions" },
  { "name": "Open Questions", "description": "unresolved threads and suggested next steps" },
  { "name": "Sources", "description": "backlinks to all contributing files", "required": true }
]

Personal journal

Good for daily notes, reflections, and personal knowledge bases.

"article_sections": [
  { "name": "Summary", "description": "standalone briefing of the topic", "required": true },
  { "name": "Themes & Patterns", "description": "recurring ideas and observations" },
  { "name": "Progress", "description": "how thinking or circumstances have changed over time" },
  { "name": "Reflections", "description": "subjective reactions and personal takeaways" },
  { "name": "Action Items", "description": "things to do or follow up on" },
  { "name": "Sources", "description": "backlinks to all contributing files", "required": true }
]

Book notes

Good for reading logs, book summaries, and literary analysis.

"article_sections": [
  { "name": "Summary", "description": "standalone briefing of the topic", "required": true },
  { "name": "Characters", "description": "key people and their roles" },
  { "name": "Themes", "description": "central ideas and motifs" },
  { "name": "Plot Threads", "description": "major narrative arcs" },
  { "name": "Connections", "description": "links to other books, concepts, or real-world events" },
  { "name": "Quotes", "description": "notable passages worth preserving" },
  { "name": "Sources", "description": "backlinks to all contributing files", "required": true }
]

Technical docs

Good for engineering wikis, API references, and system documentation.

"article_sections": [
  { "name": "Summary", "description": "standalone briefing of the topic", "required": true },
  { "name": "Architecture", "description": "how the system is structured and why" },
  { "name": "API Surface", "description": "key interfaces, endpoints, and contracts" },
  { "name": "Dependencies", "description": "external services, libraries, and internal systems this depends on" },
  { "name": "Known Issues", "description": "bugs, limitations, and workarounds" },
  { "name": "Migration Notes", "description": "breaking changes and upgrade paths" },
  { "name": "Sources", "description": "backlinks to all contributing files", "required": true }
]

Business / team

Good for team wikis, meeting digests, and decision logs.

"article_sections": [
  { "name": "Summary", "description": "standalone briefing of the topic", "required": true },
  { "name": "Stakeholders", "description": "people involved and their roles" },
  { "name": "Decisions", "description": "key decisions made and the reasoning behind them" },
  { "name": "Action Items", "description": "outstanding tasks and owners" },
  { "name": "Meeting History", "description": "chronological log of relevant discussions" },
  { "name": "Open Threads", "description": "unresolved questions and follow-ups" },
  { "name": "Sources", "description": "backlinks to all contributing files", "required": true }
]

Editing sections after init

You can edit article_sections in .wiki-compiler.json at any time. The updated structure takes effect on the next /wiki-compile run.

The description field matters — it guides the compiler’s content decisions, not just the section label. Be specific: “decisions that shaped the current approach, with rationale” produces better output than just “decisions”.