New to Claude Skills? Learn how to install them →

ar9av on GitHub

Wiki Narrate

Free

Transform wiki topics into structured Markdown briefings.

by ar9av3.2k stars on ar9av/obsidian-wiki
1 views
Updated Aug 8, 2026
Get this skill

Free · Opens the source repo

What Wiki Narrate does

Wiki Narrate is a specialized skill designed for users who need to convert topics from their Obsidian vault into structured Markdown briefings. This skill allows for topic-based readouts that are strictly grounded in the evidence available within the vault, ensuring that all information is accurate and well-cited. By using this skill, users can create plain-language explanations, concise briefings, or detailed lectures based on the content they have compiled in their Obsidian notes.

The operation of Wiki Narrate is straightforward. Users can invoke the skill with a command specifying the desired topic and an optional voice type, such as 'briefing', 'plain-language', or 'lecturer'. The skill ensures that the selected voice influences the style and ordering of the output while maintaining the integrity of the factual content. Each output is accompanied by citations from the vault, allowing users to trace back the information to its source, which is essential for maintaining credibility and accuracy.

Wiki Narrate is particularly useful for educators, researchers, or anyone who needs to present information derived from their notes in a clear and structured format. It is ideal for creating study materials, lectures, or informative documents that require a high level of accuracy and citation. The skill's emphasis on evidence-based output makes it a valuable tool for users who prioritize reliability in their documentation.

However, it is important to note that Wiki Narrate is not designed for creating new content or integrating external knowledge. The skill strictly adheres to the information present in the user's vault, meaning that if the vault lacks relevant material for a requested topic, it will not generate a readout. This limitation ensures that all outputs are grounded in verifiable sources, but it also means that users must have a comprehensive and well-organized vault to fully benefit from the skill's capabilities.

When to use it

Use this skill when you need to create a detailed, evidence-based briefing or lecture from existing notes in your Obsidian vault.

When not to use it

Avoid using this skill if you require the generation of new content or external knowledge, as it strictly relies on the material present in the vault.

What you can build with it

Creating Lecture Notes

Use Wiki Narrate to convert your Obsidian notes into structured lecture notes for a class presentation.

Generating Study Materials

Transform complex topics into clear, concise study materials that are well-cited and easy to understand.

Documenting Research Findings

Compile your research findings into a structured Markdown document with citations directly from your notes.

How to install Wiki Narrate

View source

1. Install with the skills CLI

npx skills add ar9av/obsidian-wiki/wiki-narrate --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by ar9av

Wiki Narrate — Cited Narrative Readouts

Use this skill only for a topic-based Markdown readout. Do not add tag or page-list selection, prior-query input, voice aliases, HTML, PDF, slides, renderer handoffs, or new compiled knowledge pages.

Command Contract

/wiki-narrate <topic> [--voice briefing|plain-language|lecturer] [--save]

  • Require a non-empty <topic>.
  • The default voice is briefing.
  • Voice names are canonical and case-sensitive. Unsupported values must return an error listing briefing, plain-language, and lecturer without searching or writing.
  • --save is the only persistence switch.
  • For a missing topic, malformed option, or unsupported voice, return a short usage or validation error and do not search, write, append a log event, or change hot.md.

Retrieval

  1. Resolve configuration with the Config Resolution Protocol, including an inline @name vault override, then read the target vault's AGENTS.md when it exists. Load OBSIDIAN_LINK_FORMAT before drafting citations.
  2. Read hot.md and index.md first. Select candidates by frontmatter and summary before reading bodies.
  3. When configured, use QMD before rg; if QMD is absent, unconfigured, or fails, continue with the index and rg path. Treat QMD output as candidate guidance, not evidence: establish each claim from the allowed vault page itself.
  4. Honor filtered-mode phrases such as "public only", "user-facing", "no internal content", "as a user would see it", and "exclude internal". Skip pages tagged visibility/internal or visibility/pii in that mode: never read, cite, or expose them.
  5. Exclude _readouts/, _raw/, _archives/, _meta/, index.md, log.md, hot.md, and _insights.md from candidates.
  6. Read matching sections before full pages, and read full pages only when a factual claim cannot otherwise be established. Preserve relevant lifecycle and freshness annotations; do not upgrade a page's trust.

Claim Ledger and Citation Audit

Draft a ledger before prose. Each item contains a claim, supporting [[vault page]] links, and one status: supported fact, inferred connection, or ambiguous conflict. When OBSIDIAN_LINK_FORMAT=markdown, render the same supporting page as a standard Markdown link; otherwise use the vault's [[wikilink]] form.

Ensure every factual sentence has adjacent supporting citations. Mark inferred connections ^[inferred]; mark unresolved conflicts ^[ambiguous]. Never use web knowledge, model memory, or invented examples to close a gap. Omit unsupported claims and name the gap in Coverage. An inference or ambiguity marker supplements, rather than replaces, adjacent citations.

Drafting and Output

Read references/voices.md and use exactly the requested voice skeleton. The selected voice may change prose and ordering, but cannot change the ledger's factual boundary. Return Markdown only, structured as:

  1. A title naming the topic and selected voice.
  2. The selected voice's sections, in its documented order.
  3. Adjacent citations for each factual sentence, rendered with OBSIDIAN_LINK_FORMAT.
  4. A ## Coverage footer listing cited pages, the count of inferred statements, and known evidence gaps.

If evidence is weak or contradictory, produce only the supported portion. Mark each unresolved conflict ^[ambiguous] with citations to all conflicting pages, and list the remaining gaps in ## Coverage.

Persistence

Present the result by default. For --save, create _readouts/ if necessary and write _readouts/<slug>.md with title, topic, voice, sources, created, and updated frontmatter. Use a deterministic, filesystem-safe <slug> derived from the topic. Save the same completed Markdown readout that was returned in conversation.

A readout is derived output: exclude _readouts/ from retrieval and must not update index.md or .manifest.json. Do not create _readouts/ or a readout file without a successful --save result.

Logging and Hot Cache

After a narration attempt that reaches retrieval, append one WIKI_NARRATE event to log.md:

- [TIMESTAMP] WIKI_NARRATE topic="<topic>" voice=<voice> result_pages=N mode=normal|filtered saved=true|false outcome=success|no_match|write_failed
  • Without --save, append the event with saved=false after returning the readout; do not create a readout or change hot.md.
  • After a successful --save write, append the event with saved=true, then refresh hot.md with the topic, voice, cited pages, inference count, evidence gaps, and saved readout path. hot.md changes only after a successful save.
  • If the readout write fails after drafting, return the completed readout in conversation, report that saving failed, append a WIKI_NARRATE event with saved=false outcome=write_failed when log.md remains writable, and do not update hot.md.
  • If appending log.md fails, preserve the readout result and report the logging failure separately. Never represent a failed log or save as successful.

Safe Failure Behavior

  • No matching pages: explain that the vault lacks material for the topic. Create no readout file even if --save was requested, do not change hot.md, and record a WIKI_NARRATE event with outcome=no_match when log.md is writable.
  • Weak evidence or source conflict: do not resolve it with outside knowledge. Return only supported claims, label ambiguity where applicable, and make the gap explicit in ## Coverage; saving remains available for that successful partial readout.
  • QMD unavailable or unconfigured: state the fallback briefly in the working update and continue safely through index.md and rg; do not fail the narration merely because QMD is unavailable.
  • Write failure: never leave a partial readout presented as saved, never update hot.md, and never update index.md or .manifest.json.

Frequently asked questions about Wiki Narrate

Similar skills