> ## Documentation Index > Fetch the complete documentation index at: https://saydo-5cd0e3d7.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # 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 ```json theme={null} "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. Good for teams tracking experiments, metrics, and evolving strategy. ```json theme={null} "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 } ] ``` Good for literature reviews, experiment logs, and academic notes. ```json theme={null} "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 } ] ``` Good for daily notes, reflections, and personal knowledge bases. ```json theme={null} "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 } ] ``` Good for reading logs, book summaries, and literary analysis. ```json theme={null} "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 } ] ``` Good for engineering wikis, API references, and system documentation. ```json theme={null} "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 } ] ``` Good for team wikis, meeting digests, and decision logs. ```json theme={null} "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".