Agent skill

Wiki Export

by Ar9av in Ar9av/obsidian-wiki

Export the Obsidian wiki graph to JSON, GraphML, Neo4j Cypher, Postgres/SQL, HTML, or OKF bundles.

MITAuto-check: notesKnowledge Management

Install Wiki Export

skills CLI
$ npx skills add Ar9av/obsidian-wiki --skill wiki-export -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Ar9av/obsidian-wiki wiki-export --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Ar9av/obsidian-wiki.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.skills/wiki-export .claude/skills/wiki-export && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
wiki-export
GitHub stars
3.5k
Token cost
~6.9k tokens
SKILL.md length
2,366 words
Files
1
Skills in repo
39
Repo updated
First seen
Licence
MIT

At a glance

Export the Obsidian wiki graph to JSON, GraphML, Neo4j Cypher, Postgres/SQL, HTML, or OKF bundles.

  • Works in 5 steps: Build the Node and Edge Lists → Assign Community IDs → Write the Output Files → …
  • Visualizing wiki data in external tools
  • SKILL.md covers Before You Start, Project Filter (optional), Visibility Filter (optional) and Step 1: Build the Node and…, plus 5 more sections
  • Calls psql; reaches graphml.graphdrawing.org and unpkg.com

What it does

Wiki Export is an agent skill from Ar9av/obsidian-wiki. Export the Obsidian wiki graph to JSON, GraphML, Neo4j Cypher, Postgres/SQL, HTML, or OKF bundles. Use when transferring or visualizing wiki data in external tools; wiki-import handles the reverse direction.

Its SKILL.md is about 6.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Knowledge Management, covering LLM wikis. It works with Neo4j, Obsidian, PostgreSQL and SQL. The repository describes itself as: Framework for AI agents to build and maintain a digital brain through Obsidian wiki | Memory System for Agents. The licence is MIT.

When your agent uses it

  • Visualizing wiki data in external tools
  • Wiki-import handles the reverse direction

Example prompts

  • “/wiki-export”

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Build the Node and Edge Lists
  2. Assign Community IDs
  3. Write the Output Files
  4. 5: OKF Bundle Export (optional)
  5. Print Summary

What it can do on your machine

Read from SKILL.md and the folder at commit 709727e. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • psql

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • graphml.graphdrawing.org
    • unpkg.com

    Also links to:

    • github.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Wiki Export loads about 6.9k tokens when it runs. Until then it costs about 55 tokens; SKILL.md has 2,366 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~55
When it runs · the whole SKILL.md, loaded when a task matches
~6.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:13
    line `@name` override → walk up CWD for `.env` → global config → prompt setup). This gives `OBSIDIAN_VAULT_PATH`

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Ar9av/obsidian-wiki at commit 709727e, republished under its MIT licence (© Ar9av). 2,366 words, ~6,914 tokens.

Download SKILL.mdSave it as .claude/skills/wiki-export/SKILL.md (or your agent's skills folder).
name
wiki-export
description
Export the Obsidian wiki graph to JSON, GraphML, Neo4j Cypher, Postgres/SQL, HTML, or OKF bundles. Use when transferring or visualizing wiki data in external tools; wiki-import handles the reverse direction.

Wiki Export — Knowledge Graph Export

You are exporting the wiki's wikilink graph to structured formats so it can be used in external tools (Gephi, Neo4j, custom scripts, browser visualization).

Before You Start

  1. Resolve config — follow the Config Resolution Protocol in llm-wiki/SKILL.md (inline @name override → walk up CWD for .env → global config → prompt setup). This gives OBSIDIAN_VAULT_PATH
  2. Confirm the vault has pages to export — if fewer than 5 pages exist, warn the user and stop

Project Filter (optional)

If the user's invocation includes a project name — e.g. /wiki-export prismor, "export the prismor project", "export project:security" — activate project filter mode:

  1. Extract the project name from the argument or phrase. Normalise: lowercase, strip the word "project".
  2. Keep only pages where either condition holds:
    • The page id starts with projects/<name>/ (path-based match)
    • The page's tags array contains <name> (tag-based match)
  3. Drop any edge where either endpoint was excluded.
  4. Note the filter in the summary: (filtered: project:<name> — X of Y pages)
  5. Set graph.graph.filter = "project:<name>" in the JSON output.

If both a project filter and a visibility filter are active, apply both (project filter first, then visibility filter on the remaining set).

Visibility Filter (optional)

By default, all pages are exported regardless of visibility tags. This preserves existing behavior.

If the user requests a filtered export — phrases like "public export", "user-facing export", "exclude internal", "no internal pages" — activate visibility filtered mode:

  • Build a blocked tag set: {visibility/internal, visibility/pii}
  • Skip any page whose frontmatter tags contain a blocked tag when building the node list
  • Skip any edge where either endpoint was excluded
  • Note the filter in the summary: (filtered: visibility/internal, visibility/pii excluded)

Pages with no visibility/ tag, or tagged visibility/public, are always included.

Step 1: Build the Node and Edge Lists

Glob all .md files in the vault (excluding _archives/, _raw/, _readouts/, .obsidian/, index.md, log.md, _insights.md). Apply any active filters (project and/or visibility) after collecting the full file list.

For each page, extract from frontmatter:

  • id — relative path from vault root, without .md extension (e.g. concepts/transformers)
  • label — title field from frontmatter, or filename if missing
  • category — directory prefix (concepts, entities, skills, references, synthesis, projects, or journal)
  • tags — array from frontmatter tags field
  • summary — frontmatter summary field if present

This is your node list.

For each page, Grep the body for \[\[.*?\]\] to extract all wikilinks:

  • Parse each [[target]] or [[target|display]] — use the target part only
  • Resolve the target to a node id (normalize: lowercase, spaces→hyphens, strip .md)
  • Skip links that point outside the node list (broken links)
  • Each resolved link becomes an edge: {source: page_id, target: linked_id, relation: "wikilink", confidence: "EXTRACTED"}
  • If the linking sentence ends with ^[inferred] or ^[ambiguous], override confidence accordingly

Typed edge enrichment: After building the wikilink edge list, read each page's relationships: frontmatter block. For each {target, type} entry:

  • The target YAML value is a quoted wikilink string such as "[[concepts/lstm]]". Strip the surrounding [[ and ]] characters, then apply the same normalization (lowercase, spaces→hyphens, strip .md) to get the node id.
  • Skip entries whose resolved target is not in the node list (broken link)
  • If an edge for this (source, target) pair already exists, override its relation field with the typed value (e.g., "contradicts") and set typed: true
  • If no edge exists yet for this pair, add one: {source: page_id, target: target_id, relation: <type>, confidence: "EXTRACTED", typed: true}

This means relation: "wikilink" is the default for plain untyped links; a relationships: entry promotes it to a named semantic type. Edges that originated from both a body wikilink and a relationships: entry keep a single record — the typed version wins.

This is your edge list.

Step 2: Assign Community IDs

Group pages into communities by tag clustering:

  • Pages sharing the same dominant tag belong to the same community
  • Dominant tag = the first tag in the page's frontmatter tags array
  • Pages with no tags get community id null
  • Number communities starting from 0, ordered by size descending (largest community = 0)

This enables community-based coloring in the HTML visualization and tools like Gephi.

Step 3: Write the Output Files

Create wiki-export/ at the vault root if it doesn't exist. Write all five files:


3a. graph.json

NetworkX node_link format — standard for graph tools and scripts:

json
{
  "directed": false,
  "multigraph": false,
  "graph": {
    "exported_at": "<ISO timestamp>",
    "vault": "<OBSIDIAN_VAULT_PATH>",
    "total_nodes": N,
    "total_edges": M
  },
  "nodes": [
    {
      "id": "concepts/transformers",
      "label": "Transformer Architecture",
      "category": "concepts",
      "tags": ["ml", "architecture"],
      "summary": "The attention-based architecture introduced in Attention Is All You Need.",
      "community": 0
    }
  ],
  "links": [
    {
      "source": "concepts/transformers",
      "target": "entities/vaswani",
      "relation": "wikilink",
      "confidence": "EXTRACTED"
    },
    {
      "source": "concepts/transformers",
      "target": "concepts/lstm",
      "relation": "contradicts",
      "confidence": "EXTRACTED",
      "typed": true
    }
  ]
}

3b. graph.graphml

GraphML XML format — loadable in Gephi, yEd, and Cytoscape:

xml
<?xml version="1.0" encoding="UTF-8"?>
<graphml xmlns="http://graphml.graphdrawing.org/graphml">
  <key id="label" for="node" attr.name="label" attr.type="string"/>
  <key id="category" for="node" attr.name="category" attr.type="string"/>
  <key id="tags" for="node" attr.name="tags" attr.type="string"/>
  <key id="community" for="node" attr.name="community" attr.type="int"/>
  <key id="relation" for="edge" attr.name="relation" attr.type="string"/>
  <key id="type" for="edge" attr.name="type" attr.type="string"/>
  <key id="confidence" for="edge" attr.name="confidence" attr.type="string"/>
  <graph id="wiki" edgedefault="undirected">
    <node id="concepts/transformers">
      <data key="label">Transformer Architecture</data>
      <data key="category">concepts</data>
      <data key="tags">ml, architecture</data>
      <data key="community">0</data>
    </node>
    <!-- Untyped wikilink — no <data key="type"> element -->
    <edge source="concepts/transformers" target="entities/vaswani">
      <data key="relation">wikilink</data>
      <data key="confidence">EXTRACTED</data>
    </edge>
    <!-- Typed edge from relationships: block -->
    <edge source="concepts/transformers" target="concepts/lstm">
      <data key="relation">contradicts</data>
      <data key="type">contradicts</data>
      <data key="confidence">EXTRACTED</data>
    </edge>
  </graph>
</graphml>

Write one <node> per page and one <edge> per link. For typed edges (those where typed: true in the edge list), emit both <data key="relation"> with the semantic type value and <data key="type"> with the same value — this keeps relation readable for tools that already consume it while letting type-aware tools filter on the dedicated type key. Untyped wikilinks omit the <data key="type"> element entirely.


3c. cypher.txt

Neo4j Cypher MERGE statements — paste into Neo4j Browser or run with cypher-shell:

cypher
// Wiki knowledge graph export — <TIMESTAMP>
// Load with: cypher-shell -u neo4j -p password < cypher.txt

// Nodes
MERGE (n:Page {id: "concepts/transformers"}) SET n.label = "Transformer Architecture", n.category = "concepts", n.tags = ["ml","architecture"], n.community = 0;
MERGE (n:Page {id: "entities/vaswani"}) SET n.label = "Ashish Vaswani", n.category = "entities", n.tags = ["person","ml"], n.community = 0;
MERGE (n:Page {id: "concepts/lstm"}) SET n.label = "LSTM", n.category = "concepts", n.tags = ["ml","rnn"], n.community = 0;

// Relationships
// Untyped wikilinks use [:WIKILINK]
MATCH (a:Page {id: "concepts/transformers"}), (b:Page {id: "entities/vaswani"}) MERGE (a)-[:WIKILINK {relation: "wikilink", confidence: "EXTRACTED"}]->(b);
// Typed edges use the relationship type as the label (UPPERCASE)
MATCH (a:Page {id: "concepts/transformers"}), (b:Page {id: "concepts/lstm"}) MERGE (a)-[:CONTRADICTS {relation: "contradicts", confidence: "EXTRACTED"}]->(b);

Write one MERGE node statement per page, then one MATCH/MERGE relationship statement per edge. For typed edges, use the type value uppercased as the Cypher relationship label (e.g., contradicts → [:CONTRADICTS], derived_from → [:DERIVED_FROM]). Untyped wikilinks always use [:WIKILINK].


3d. postgres.sql

Plain SQL — loadable into any Postgres database (local, Supabase, RDS, Neon, …) with psql -f postgres.sql or a migration runner. Two tables: wiki_pages (nodes) and wiki_edges (links), with ON CONFLICT upserts so re-running the export is safe and idempotent, mirroring the MERGE semantics of cypher.txt.

sql
-- Wiki knowledge graph export — <TIMESTAMP>
-- Load with: psql -d yourdb -f postgres.sql

CREATE TABLE IF NOT EXISTS wiki_pages (
  id        TEXT PRIMARY KEY,
  label     TEXT NOT NULL,
  category  TEXT,
  tags      JSONB NOT NULL DEFAULT '[]'::jsonb,
  summary   TEXT,
  community INT
);

CREATE TABLE IF NOT EXISTS wiki_edges (
  source     TEXT NOT NULL REFERENCES wiki_pages(id) ON DELETE CASCADE,
  target     TEXT NOT NULL REFERENCES wiki_pages(id) ON DELETE CASCADE,
  relation   TEXT NOT NULL DEFAULT 'wikilink',
  confidence TEXT,
  typed      BOOLEAN NOT NULL DEFAULT false,
  PRIMARY KEY (source, target, relation)
);

CREATE INDEX IF NOT EXISTS wiki_edges_source_idx ON wiki_edges(source);
CREATE INDEX IF NOT EXISTS wiki_edges_target_idx ON wiki_edges(target);

-- Nodes
INSERT INTO wiki_pages (id, label, category, tags, summary, community)
VALUES ('concepts/transformers', 'Transformer Architecture', 'concepts', '["ml","architecture"]'::jsonb, 'The attention-based architecture introduced in Attention Is All You Need.', 0)
ON CONFLICT (id) DO UPDATE SET
  label = EXCLUDED.label, category = EXCLUDED.category, tags = EXCLUDED.tags,
  summary = EXCLUDED.summary, community = EXCLUDED.community;

-- Edges
-- Untyped wikilink
INSERT INTO wiki_edges (source, target, relation, confidence, typed)
VALUES ('concepts/transformers', 'entities/vaswani', 'wikilink', 'EXTRACTED', false)
ON CONFLICT (source, target, relation) DO UPDATE SET confidence = EXCLUDED.confidence, typed = EXCLUDED.typed;

-- Typed edge from relationships: block
INSERT INTO wiki_edges (source, target, relation, confidence, typed)
VALUES ('concepts/transformers', 'concepts/lstm', 'contradicts', 'EXTRACTED', true)
ON CONFLICT (source, target, relation) DO UPDATE SET confidence = EXCLUDED.confidence, typed = EXCLUDED.typed;

Write one INSERT ... ON CONFLICT (id) DO UPDATE statement per page (values escaped: single quotes doubled, tags serialized as a JSON array literal cast to jsonb), then one INSERT ... ON CONFLICT (source, target, relation) DO UPDATE per edge. relation stays lowercase here (unlike the uppercased Cypher relationship label) since it's a plain column value, not a schema identifier — this keeps it directly filterable with WHERE relation = 'contradicts' or joinable without case-folding. typed is true only for edges promoted by a relationships: frontmatter entry; plain wikilinks stay false.

Skip pages whose id collides only after the ON CONFLICT clause fires from a prior run — do not attempt to deduplicate synthetic multi-edges (e.g. same source/target with both a wikilink and a typed relation) since the composite primary key (source, target, relation) already keeps them as distinct rows, matching the "typed version wins" merge behavior of graph.json/graph.graphml at the query layer (SELECT * FROM wiki_edges WHERE source=$1 AND target=$2 ORDER BY typed DESC LIMIT 1).


3e. graph.html

A self-contained interactive visualization using the vis.js CDN (no local dependencies). The user opens this file in any browser — no server needed.

Build the HTML file by:

  1. Generating a JSON array of node objects for vis.js:
js
{id: "concepts/transformers", label: "Transformer Architecture", color: {background: "#4E79A7"}, size: <degree * 3 + 8>, title: "concepts | #ml #architecture", community: 0}
  • Color by community (cycle through: #4E79A7, #F28E2B, #E15759, #76B7B2, #59A14F, #EDC948, #B07AA1, #FF9DA7, #9C755F, #BAB0AC)
  • Size by degree (incoming + outgoing link count): size = degree * 3 + 8, capped at 60
  • title = tooltip text shown on hover: category, tags, summary (if available)
  1. Generating a JSON array of edge objects for vis.js:
js
// Untyped wikilink
{from: "concepts/transformers", to: "entities/vaswani", dashes: false, width: 1, color: {color: "#666", opacity: 0.6}, title: "wikilink"}
// Typed edge
{from: "concepts/transformers", to: "concepts/lstm", dashes: false, width: 2, color: {color: "#E15759", opacity: 0.8}, label: "contradicts", font: {size: 9, color: "#ccc"}, title: "contradicts"}
  • dashes: true for INFERRED edges
  • dashes: [4,8] for AMBIGUOUS edges
  • Typed edges (typed: true): set width: 2, add a label field showing the type, and apply a type-specific color:
TypeEdge color
extends#59A14F (green)
implements#4E79A7 (blue)
contradicts#E15759 (red)
derived_from#F28E2B (orange)
uses#76B7B2 (teal)
replaces#B07AA1 (purple)
related_to#BAB0AC (grey — same as untyped)

Untyped wikilink edges keep the existing #666 grey color and no label.

  1. Writing the full HTML file:
html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Wiki Knowledge Graph</title>
<script src="https://unpkg.com/vis-network/standalone/umd/vis-network.min.js"></script>
<style>
  * { box-sizing: border-box; margin: 0; padding: 0; }
  body { background: #0f0f1a; color: #e0e0e0; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif; display: flex; height: 100vh; }
  #graph { flex: 1; }
  #sidebar { width: 260px; background: #1a1a2e; border-left: 1px solid #2a2a4e; padding: 14px; overflow-y: auto; font-size: 13px; }
  #sidebar h3 { color: #aaa; font-size: 11px; text-transform: uppercase; letter-spacing: 0.05em; margin: 0 0 10px; }
  #info { margin-bottom: 16px; line-height: 1.6; color: #ccc; }
  .legend-item { display: flex; align-items: center; gap: 8px; padding: 3px 0; font-size: 12px; }
  .dot { width: 10px; height: 10px; border-radius: 50%; flex-shrink: 0; }
  #stats { margin-top: 16px; color: #555; font-size: 11px; }
</style>
</head>
<body>
<div id="graph"></div>
<div id="sidebar">
  <h3>Wiki Knowledge Graph</h3>
  <div id="info">Click a node to see details.</div>
  <h3 style="margin-top:12px">Communities</h3>
  <div id="legend"><!-- populated by JS --></div>
  <div id="stats"><!-- populated by JS --></div>
</div>
<script>
const NODES_DATA = /* NODES_JSON */;
const EDGES_DATA = /* EDGES_JSON */;
const COMMUNITY_COLORS = ["#4E79A7","#F28E2B","#E15759","#76B7B2","#59A14F","#EDC948","#B07AA1","#FF9DA7","#9C755F","#BAB0AC"];

const nodes = new vis.DataSet(NODES_DATA);
const edges = new vis.DataSet(EDGES_DATA);
const network = new vis.Network(document.getElementById('graph'), {nodes, edges}, {
  physics: { solver: 'forceAtlas2Based', forceAtlas2Based: { gravitationalConstant: -60, springLength: 120 }, stabilization: { iterations: 200 } },
  interaction: { hover: true, tooltipDelay: 100 },
  nodes: { shape: 'dot', borderWidth: 1.5 },
  edges: { smooth: { type: 'continuous' }, arrows: { to: { enabled: true, scaleFactor: 0.4 } } }
});
network.once('stabilizationIterationsDone', () => network.setOptions({ physics: { enabled: false } }));

network.on('click', ({nodes: sel}) => {
  if (!sel.length) return;
  const n = NODES_DATA.find(x => x.id === sel[0]);
  if (!n) return;
  document.getElementById('info').innerHTML = `<b>${n.label}</b><br>Category: ${n.category||'—'}<br>Tags: ${n.tags||'—'}<br>${n.summary ? '<br>'+n.summary : ''}`;
});

// Build legend
const communities = {};
NODES_DATA.forEach(n => { if (n.community != null) communities[n.community] = (communities[n.community]||0)+1; });
const leg = document.getElementById('legend');
Object.entries(communities).sort((a,b)=>b[1]-a[1]).forEach(([cid, count]) => {
  const color = COMMUNITY_COLORS[cid % COMMUNITY_COLORS.length];
  leg.innerHTML += `<div class="legend-item"><div class="dot" style="background:${color}"></div>Community ${cid} (${count})</div>`;
});
document.getElementById('stats').textContent = `${NODES_DATA.length} pages · ${EDGES_DATA.length} links`;
</script>
</body>
</html>

Replace /* NODES_JSON */ and /* EDGES_JSON */ with the actual JSON arrays you generated in step 1.


Step 3.5: OKF Bundle Export (optional)

Run this step only when the user asks for OKF / a markdown bundle (phrases like "export to OKF", "OKF bundle", "open knowledge format", "export as markdown bundle"). It is additive — the five graph files above are always produced; this writes an extra full-fidelity markdown bundle.

The five graph files are a lossy projection (graph skeleton only). An OKF bundle is the actual page bodies, so an export→wiki-import round-trip through OKF preserves full content, and the bundle drops straight into MkDocs, Notion, Hugo, GitHub's renderer, or any Open Knowledge Format consumer.

Show full SKILL.md (1,066 more words)Show less
Canonical frontmatter mapping (obsidian-wiki ⇄ OKF)

This table is the single source of truth for the mapping; wiki-import references it for the reverse direction.

OKF key← export from→ import toNotes
type (required)category, title-casedcategory (lower-cased)concepts→Concept, entities→Entity, skills→Skill, references→Reference, synthesis→Synthesis, projects→Project, journal→Journal. OKF requires type; consumers tolerate any string.
titletitletitleVerbatim.
descriptionsummarysummaryOur one-line summary: is exactly OKF's description (used in index.md entries).
tagstagstagsVerbatim list. visibility/* system tags pass through unchanged.
generatedupdated → generated.at; by is the producerupdated ← generated.atWrite generated: { by: obsidian-wiki/<version>, at: <datetime> }, taking <version> from obsidian-wiki --version (plain obsidian-wiki if the CLI isn't installed). OKF §5 requires every timestamp to be a datetime with an explicit offset, so a date-only updated: 2026-04-12 becomes 2026-04-12T00:00:00Z. Replaces v0.1's timestamp, which is no longer written.
sourcessources (list of strings)sources (list of strings)OKF sources is a list of objects with a required resource, so each native string becomes - resource: <string>. Opaque strings like conversation:2026-04-12 are valid: §5.1 allows scope descriptors a consumer can't follow. Emit nothing else per entry, so import recovers the exact strings.
statuslifecycle— (native lifecycle is preserved)draft → draft; reviewed, verified, disputed → stable; archived → deprecated. Omit status when lifecycle is absent (absent means stable in OKF).
verified_meta/trust-ledger.json entry for the page— (preserved verbatim)Only when the page has a ledger entry: verified: { by: human:vault-owner, at: <entry reviewed_at> }. trust-record only writes entries a human approved with --approved, so the human: actor is accurate and gives the page OKF's human-reviewed tier (§5.3). Never derive verified from lifecycle alone.
resourcefirst sources: entry iff it is an http(s):// URL—Optional; omit when no source URL. Most pages describe abstract knowledge and have none.
(extensions)category, created, updated, relationships, lifecycle, lifecycle_changed, tier, base_confidence, …preserved verbatimOKF §4.1 requires consumers to preserve unknown keys. Writing our native keys as OKF extension frontmatter is what makes the round-trip lossless — on import, preserved category/created/updated/lifecycle are preferred over re-deriving from type/generated/status. (updated rides along because generated.at must be a full datetime, so a date-only updated would otherwise come back as midnight UTC.) sources is not an extension any more: it's a spec field (row above).
Steps

Reuse the node list from Step 1 (with any active project/visibility filters already applied). Write a directory tree under wiki-export/okf/:

  1. One file per in-scope page. For each page, parse its frontmatter, apply the mapping table above to build the OKF frontmatter (required type first, then title, description, tags, generated, status, verified, sources, optional resource, then the preserved extension keys), transform the body links (below), and write to wiki-export/okf/<category>/<slug>.md — same relative path the page has in the vault.

  2. Body link transform ([[wikilinks]] → standard markdown links):

    • [[concepts/transformers]] → [<target title>](<file-relative path>.md), e.g. from entities/foo.md a link to concepts/transformers becomes [Transformer Architecture](../concepts/transformers.md). Link text = the target page's title (fall back to the target id if unknown).
    • [[target|display]] → [display](<rel path>.md).
    • Use file-relative paths (../concepts/x.md), never /-absolute — /-rooted links break GitHub rendering. (This matches knowledge-catalog's own production agent.)
    • Compute that relative path from the target file path, not the bare page id: normalize the wikilink target to its page id, append .md, then compute relpath(<target-file>, <source-file-dir>). Never call relpath() on the id before adding .md.
    • This is required for the common "folder note" layout where a page id exists both as a file and as a directory prefix, e.g. projects/social-twitter.md plus projects/social-twitter/.... From projects/social-twitter/concepts/mem0-memory-analysis.md, a link to [[projects/social-twitter]] must export to ../../social-twitter.md, not ...md.
    • Resolve link targets with the same normalization used in Step 1 (lowercase, spaces→hyphens, strip .md). Handle unresolved targets by form, so forward-references survive the round-trip:
      • Resolves to an in-scope page → relative markdown link to it.
      • Path-form target (contains a /, e.g. [[concepts/attention-mechanism]]) with no page yet, and not excluded by an active filter → still emit the relative markdown link. OKF §11 forbids rejecting a bundle over a broken cross-link, and keeping the link makes the user's forward-references lossless on re-import. (Verified on st3ve: dropping these silently deleted real [[wikilinks]].)
      • Excluded by an active project/visibility filter → plain text. Do not emit a path pointing into filtered-out content.
      • Bare-title target with no match (e.g. [[tractorex]] when no such page exists in scope) → plain text; there is no reliable path to write.
    • Leave existing external http(s):// links and # Citations sections untouched.
  3. Generate index.md files (OKF §8 progressive disclosure; these contain no per-entry frontmatter):

    • Bundle root wiki-export/okf/index.md — a # Subdirectories section listing each category folder: * [<category>](<category>/index.md) - <one-line description of the category>. This is the only index permitted frontmatter: add a single key okf_version: "0.2" (OKF §8, §12).
    • One index.md per category folder listing its pages: * [<title>](<slug>.md) - <description from the page's summary>.
  4. Write log.md from the vault root's log.md, reshaped to OKF §9, which requires ## YYYY-MM-DD date headings, newest first. Our log is a flat, oldest-first list of - [<timestamp>] VERB key=value … lines, so: start with # Wiki Update Log; group lines by the date part of <timestamp>; emit groups newest first under ## <date>; render each line as * **<Verb>**: <rest of line>, with the verb title-cased (INGEST → Ingest). Keep lines that don't match the pattern under the date of the line above them, verbatim after * . wiki-import ignores log.md, so this costs nothing on the round-trip.

  5. Filters. Honor the same project/visibility filters as the graph export — filtered pages are omitted from the bundle and their inbound links degrade to plain text per step 2.

Excluded from the bundle (same as the graph export): _archives/, _raw/, _readouts/, .obsidian/, _insights.md, _meta/*.base, and the vault root index.md (regenerated above).


Step 4: Print Summary

Wiki export complete → wiki-export/
  graph.json    — N nodes, M edges (NetworkX node_link format)
  graph.graphml — N nodes, M edges (Gephi / yEd / Cytoscape)
  cypher.txt    — N MERGE nodes + M MERGE relationships (Neo4j)
  postgres.sql  — N upsert rows (wiki_pages) + M upsert rows (wiki_edges) (any Postgres)
  graph.html    — interactive browser visualization (open in any browser)

Append this line only when the OKF bundle was produced (Step 3.5):

  okf/          — OKF v0.2 markdown bundle (N pages, lossless; import via wiki-import)

Append filter notes when active:

  (filtered: project:prismor — 19 of 67 pages)
  (filtered: X of Y pages excluded — visibility/internal, visibility/pii)

Only include lines for filters that were actually applied.

Notes

  • Re-running is safe — all output files (and the okf/ bundle) are overwritten on each run
  • Broken wikilinks are skipped — only edges to pages that exist in the vault are exported; in the OKF bundle, a wikilink to a missing/filtered page degrades to plain text
  • OKF is the lossless format — graph.json reconstructs only stubs on import, while the okf/ bundle preserves full page bodies. Use OKF for vault-to-vault transfer and external markdown tools (MkDocs, Notion, GitHub); use the graph files for analysis tools (Gephi, Neo4j)
  • The wiki-export/ directory should be gitignored if the vault is version-controlled — these are derived artifacts
  • graph.json is the primary format — the others are derived from it. If a future tool supports graph queries natively, point it at graph.json

© Ar9av, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .skills/wiki-export of Ar9av/obsidian-wiki.

Open the folder on GitHubat commit 709727e

Compare with similar skills

Wiki Export next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Wiki Export compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Wiki Export this skillAr9av/obsidian-wiki3.5k—~6.9kAutomated safety check: NotesMIT
Swarmvaultswarmclawai/swarmvault708—~6.1kAutomated safety check: PassMIT
Wiki DiagramIssacW228/student-llm-wiki176—~394Automated safety check: PassMIT
Graphify Dotnetmanagedcode/dotnet-skills486—~1.9kAutomated safety check: PassMIT
Obsidian Wiki Log FoldAgriciDaniel/claude-obsidian15k1 repos~1.2kAutomated safety check: PassMIT
Llmwikiatomicstrata/llm-wiki-compiler2.2k1 repos~814Automated safety check: PassMIT

Similar skills

  • Swarmvault

    swarmclawai/swarmvault

    Use SwarmVault when the user needs a local-first knowledge vault that writes durable markdown, graph, search, dashboard, review, chat-session, context-pack, task-ledger, static AI export, retrieval…

    708 GitHub stars~6.1k tokensUpdated 3 mo ago
    Knowledge ManagementAuto-check passed
  • Wiki Diagram

    IssacW228/student-llm-wiki

    Add Mermaid diagrams to wiki pages to aid understanding. An agent skill from IssacW228/student-llm-wiki.

    176 GitHub stars~394 tokensUpdated 3 mo ago
    Knowledge ManagementAuto-check passed
  • Graphify Dotnet

    managedcode/dotnet-skills

    Use graphify-dotnet to generate codebase knowledge graphs, architecture snapshots, and exportable repository maps from .NET or polyglot source trees, with optional AI-enriched semantic relationships.

    486 GitHub stars~1.9k tokensUpdated yesterday
    Knowledge ManagementAuto-check passed
  • Obsidian Wiki Log Fold

    AgriciDaniel/claude-obsidian

    Creates a bounded, extractive rollup of recent Obsidian wiki log entries, previewed by default, with one optional apply step and no changes to child pages.

    15k GitHub starsUsed in 1 repo~1.2k tokens
    Knowledge ManagementAuto-check passed
  • Llmwiki

    atomicstrata/llm-wiki-compiler

    Build and use a persistent, citation-traceable knowledge wiki from documents, research papers, notes, or project documentation.

    2.2k GitHub starsUsed in 1 repo~814 tokens
    Knowledge ManagementAuto-check passed
  • LLM Wiki

    lewislulu/llm-wiki-skill

    Build and maintain a Karpathy-style LLM knowledge base — a self-compiling Obsidian markdown wiki where an Agent ingests raw sources, compiles cross-linked concept/entity/summary pages, answers…

    655 GitHub stars~3.7k tokensUpdated 5 mo ago
    Knowledge ManagementAuto-check passed

More from Ar9av/obsidian-wiki

All 39 skills in this repo
  • Hermes History Ingest

    Ar9av/obsidian-wiki

    Ingest Hermes agent history into Obsidian as distilled knowledge.

    3.5k GitHub starsUsed in 1 repo~2.2k tokens
    Auto-check: notes
  • Codex History Ingest

    Ar9av/obsidian-wiki

    Ingest Codex CLI conversation/session history into Obsidian as distilled knowledge.

    3.5k GitHub stars~2.2k tokensUpdated yesterday
    Auto-check: notes
  • Copilot History Ingest

    Ar9av/obsidian-wiki

    Ingest GitHub Copilot CLI/session history into Obsidian as distilled knowledge.

    3.5k GitHub stars~4.4k tokensUpdated yesterday
    Auto-check: notes
  • Obsidian Layout Adjustment

    Ar9av/obsidian-wiki

    Adjust the user's Obsidian visual layout with CSS snippets. An agent skill from Ar9av/obsidian-wiki.

    3.5k GitHub stars~2.5k tokensUpdated yesterday
    Auto-check passed
  • Openclaw History Ingest

    Ar9av/obsidian-wiki

    Ingest OpenClaw session/history data into Obsidian as distilled knowledge.

    3.5k GitHub stars~2.5k tokensUpdated yesterday
    Auto-check: notes
  • Wiki Capture

    Ar9av/obsidian-wiki

    Turn the current conversation or finding into a structured permanent wiki note.

    3.5k GitHub stars~4.3k tokensUpdated yesterday
    Auto-check: notes

Questions about Wiki Export

What does Wiki Export do?

Export the Obsidian wiki graph to JSON, GraphML, Neo4j Cypher, Postgres/SQL, HTML, or OKF bundles. Wiki Export is an agent skill from Ar9av/obsidian-wiki. Export the Obsidian wiki graph to JSON, GraphML, Neo4j Cypher, Postgres/SQL, HTML, or OKF bundles.

When should I use Wiki Export?

Wiki Export fits situations like: visualizing wiki data in external tools; wiki-import handles the reverse direction.

How do I install Wiki Export in Claude Code?

Run `npx skills add Ar9av/obsidian-wiki --skill wiki-export -a claude-code`. Or copy the skill folder (.skills/wiki-export in Ar9av/obsidian-wiki) into .claude/skills/wiki-export in your project. Claude Code loads it when a task matches its description.

How do I install Wiki Export in Codex?

Run `npx skills add Ar9av/obsidian-wiki --skill wiki-export -a codex`. Or copy the skill folder (.skills/wiki-export in Ar9av/obsidian-wiki) into .agents/skills/wiki-export in your project. Codex loads it when a task matches its description.

Can I use Wiki Export in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Ar9av/obsidian-wiki --skill wiki-export -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/wiki-export, .gemini/skills/wiki-export, .github/skills/wiki-export and .opencode/skills/wiki-export in your project.

What does Wiki Export need to run?

Going by SKILL.md and its folder, Wiki Export needs the command-line tools its instructions call (psql).

Does Wiki Export access the network?

SKILL.md names 3 domains. In commands or code: graphml.graphdrawing.org and unpkg.com; the agent is likely to contact these when it follows the instructions. As links in the text: github.com. This is read from the text; nothing was executed.

Is Wiki Export safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Wiki Export use?

Wiki Export is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Wiki Export use?

About 6.9k tokens (SKILL.md is roughly 28k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Wiki Export?

Skills that share tags, products or a category with Wiki Export: Swarmvault (swarmclawai/swarmvault, 708 stars), Wiki Diagram (IssacW228/student-llm-wiki, 176 stars), Graphify Dotnet (managedcode/dotnet-skills, 486 stars) and Obsidian Wiki Log Fold (AgriciDaniel/claude-obsidian, 15k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Wiki Export?

Ar9av (a GitHub user) maintains it in Ar9av/obsidian-wiki, which has 3,532 GitHub stars. The repository holds 39 skills in this directory. The repository was last updated on October 7, 2026.

Source: Ar9av/obsidian-wiki on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.