agentleFS
Ar9avAr9av/obsidian-wiki/skills/wiki-narrate/SKILL.md

wiki-narrate

Skill3.7k starsChanged 9 days agoMITView on GitHub

Turn a wiki topic into a cited Markdown briefing, plain-language explanation, or progressive lecture. Use this skill for topic-based briefing, explanation, and lecture requests that must stay within the evidence compiled in an Obsidian vault.

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Who's talking about Ar9av/obsidian-wiki

The biggest 5 of 27 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 27

Talked about on GitHub and Bluesky (27 times).

On GitHub · 25

20 more on GitHub

On Bluesky · 2

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 2 are distinctive, and 12 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 12

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill only for a topic-based Markdown readout.

    line 11
  2. Very specific:

    Writing profile: Before drafting or rewriting natural-language Markdown, read and apply the Writing Profile Resolution section in …

    line 30
  3. Very specific:

    Read hot.md and index.md first.

    line 36
  4. Very specific:

    When configured, use QMD before rg.

    line 38
  5. Distinctive:

    Read matching sections before full pages, and read full pages only when a factual claim cannot otherwise be established.

    line 47
  6. Very specific:

    When OBSIDIAN_LINK_FORMAT=markdown, render the same supporting page as a standard Markdown link.

    line 55
  7. Very specific:

    Read references/voices.md and use exactly the requested voice skeleton.

    line 62
  8. Very specific:

    If evidence is weak or contradictory, produce only the supported portion.

    line 73
  9. Very specific:

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

    line 88
  10. Very specific:

    After a successful --save write, append the event with saved=true, then refresh the hot cache with a one-line takeaway naming the topic, …

    line 102
  11. Very specific:

    If the readout write fails after drafting, return the completed readout in conversation, report that saving failed, append a WIKI_NARRATE …

    line 106
  12. Very specific:

    If appending log.md fails, preserve the readout result and report the logging failure separately.

    line 110
  13. Very specific:

    Weak evidence or source conflict: do not resolve it with outside knowledge.

    line 118
  14. Very specific:

    Write failure: never leave a partial readout presented as saved, never update hot.md, and never update index.md or .manifest.json.

    line 125

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

Writing profile: Before drafting or rewriting natural-language Markdown, read and apply the Writing Profile Resolution section in llm-wiki/SKILL.md. Framework schema, provenance, safety, and operation-specific requirements take precedence. WRITING.md preferences apply only to newly drafted or rewritten natural-language Markdown; preserve source content and structured records.

  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:

obsidian-wiki memory log WIKI_NARRATE \
  topic="<topic>" voice=<voice> result_pages=<N> \
  mode=<normal|filtered> saved=<true|false> \
  outcome=<success|no_match|write_failed>

This is the only write a narration without --save may perform. Do not touch index.md or hot.md by hand.

  • 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 the hot cache with a one-line takeaway naming the topic, voice, cited-page count, and saved readout path: obsidian-wiki memory hot --takeaways "<line>". hot.md changes only after a successful save, and only through that command.
  • 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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.