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…
Export the Obsidian wiki graph to JSON, GraphML, Neo4j Cypher, Postgres/SQL, HTML, or OKF bundles.
$ npx skills add Ar9av/obsidian-wiki --skill wiki-export -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install Ar9av/obsidian-wiki wiki-export --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ 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-srcUse ~/.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/
Install the "wiki-export" agent skill from https://github.com/Ar9av/obsidian-wiki/tree/main/.skills/wiki-export into .claude/skills/wiki-export/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "wiki-export", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/Ar9av/obsidian-wiki/tree/main/.skills/wiki-exportType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add Ar9av/obsidian-wiki --skill wiki-export -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install Ar9av/obsidian-wiki wiki-export --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/Ar9av/obsidian-wiki.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.skills/wiki-export .agents/skills/wiki-export && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "wiki-export" agent skill from https://github.com/Ar9av/obsidian-wiki/tree/main/.skills/wiki-export into .agents/skills/wiki-export/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "wiki-export", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add Ar9av/obsidian-wiki --skill wiki-export -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install Ar9av/obsidian-wiki wiki-export --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/Ar9av/obsidian-wiki.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.skills/wiki-export .cursor/skills/wiki-export && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "wiki-export" agent skill from https://github.com/Ar9av/obsidian-wiki/tree/main/.skills/wiki-export into .cursor/skills/wiki-export/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "wiki-export", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/Ar9av/obsidian-wiki.git --path .skills/wiki-export--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add Ar9av/obsidian-wiki --skill wiki-export -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install Ar9av/obsidian-wiki wiki-export --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/Ar9av/obsidian-wiki.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.skills/wiki-export .gemini/skills/wiki-export && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "wiki-export" agent skill from https://github.com/Ar9av/obsidian-wiki/tree/main/.skills/wiki-export into .gemini/skills/wiki-export/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "wiki-export", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install Ar9av/obsidian-wiki wiki-exportInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add Ar9av/obsidian-wiki --skill wiki-export -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/Ar9av/obsidian-wiki.git skills-src && mkdir -p .github/skills && cp -r skills-src/.skills/wiki-export .github/skills/wiki-export && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "wiki-export" agent skill from https://github.com/Ar9av/obsidian-wiki/tree/main/.skills/wiki-export into .github/skills/wiki-export/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "wiki-export", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add Ar9av/obsidian-wiki --skill wiki-export -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install Ar9av/obsidian-wiki wiki-export --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/Ar9av/obsidian-wiki.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.skills/wiki-export .opencode/skills/wiki-export && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "wiki-export" agent skill from https://github.com/Ar9av/obsidian-wiki/tree/main/.skills/wiki-export into .opencode/skills/wiki-export/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "wiki-export", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
wiki-exportExport 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. 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.
5 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 709727e. It shows what the files ask for, not the result of running them.
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.
Shell commands in SKILL.md call:
psqlFrom the folder's file list and the shell code blocks in SKILL.md.
Hosts in commands or code, which the agent is likely to contact:
graphml.graphdrawing.orgunpkg.comAlso links to:
github.comFrom URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
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.
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.
The automated check noted patterns worth knowing about, such as sudo or a known installer.
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.
The full file from Ar9av/obsidian-wiki at commit 709727e, republished under its MIT licence (© Ar9av). 2,366 words, ~6,914 tokens.
.claude/skills/wiki-export/SKILL.md (or your agent's skills folder).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).
llm-wiki/SKILL.md (inline @name override → walk up CWD for .env → global config → prompt setup). This gives OBSIDIAN_VAULT_PATHIf the user's invocation includes a project name — e.g. /wiki-export prismor, "export the prismor project", "export project:security" — activate project filter mode:
id starts with projects/<name>/ (path-based match)tags array contains <name> (tag-based match)(filtered: project:<name> — X of Y pages)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).
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:
{visibility/internal, visibility/pii}(filtered: visibility/internal, visibility/pii excluded)Pages with no visibility/ tag, or tagged visibility/public, are always included.
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 missingcategory — directory prefix (concepts, entities, skills, references, synthesis, projects, or journal)tags — array from frontmatter tags fieldsummary — frontmatter summary field if presentThis is your node list.
For each page, Grep the body for \[\[.*?\]\] to extract all wikilinks:
[[target]] or [[target|display]] — use the target part only.md){source: page_id, target: linked_id, relation: "wikilink", confidence: "EXTRACTED"}^[inferred] or ^[ambiguous], override confidence accordinglyTyped edge enrichment: After building the wikilink edge list, read each page's relationships: frontmatter block. For each {target, type} entry:
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.(source, target) pair already exists, override its relation field with the typed value (e.g., "contradicts") and set typed: true{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.
Group pages into communities by tag clustering:
nullThis enables community-based coloring in the HTML visualization and tools like Gephi.
Create wiki-export/ at the vault root if it doesn't exist. Write all five files:
graph.jsonNetworkX node_link format — standard for graph tools and scripts:
{
"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
}
]
}graph.graphmlGraphML XML format — loadable in Gephi, yEd, and Cytoscape:
<?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.
cypher.txtNeo4j Cypher MERGE statements — paste into Neo4j Browser or run with cypher-shell:
// 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].
postgres.sqlPlain 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.
-- 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).
graph.htmlA 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:
{id: "concepts/transformers", label: "Transformer Architecture", color: {background: "#4E79A7"}, size: <degree * 3 + 8>, title: "concepts | #ml #architecture", community: 0}#4E79A7, #F28E2B, #E15759, #76B7B2, #59A14F, #EDC948, #B07AA1, #FF9DA7, #9C755F, #BAB0AC)size = degree * 3 + 8, capped at 60title = tooltip text shown on hover: category, tags, summary (if available)// 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 edgesdashes: [4,8] for AMBIGUOUS edgestyped: true): set width: 2, add a label field showing the type, and apply a type-specific color:| Type | Edge 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.
<!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.
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.
This table is the single source of truth for the mapping; wiki-import references it for the reverse direction.
| OKF key | ← export from | → import to | Notes |
|---|---|---|---|
type (required) | category, title-cased | category (lower-cased) | concepts→Concept, entities→Entity, skills→Skill, references→Reference, synthesis→Synthesis, projects→Project, journal→Journal. OKF requires type; consumers tolerate any string. |
title | title | title | Verbatim. |
description | summary | summary | Our one-line summary: is exactly OKF's description (used in index.md entries). |
tags | tags | tags | Verbatim list. visibility/* system tags pass through unchanged. |
generated | updated → generated.at; by is the producer | updated ← generated.at | Write 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. |
sources | sources (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. |
status | lifecycle | — (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. |
resource | first 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 verbatim | OKF §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). |
Reuse the node list from Step 1 (with any active project/visibility filters already applied). Write a directory tree under wiki-export/okf/:
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.
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).../concepts/x.md), never /-absolute — /-rooted links break GitHub rendering. (This matches knowledge-catalog's own production agent.).md, then compute relpath(<target-file>, <source-file-dir>). Never call relpath() on the id before adding .md.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..md). Handle unresolved targets by form, so forward-references survive the round-trip:/, 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]].)[[tractorex]] when no such page exists in scope) → plain text; there is no reliable path to write.http(s):// links and # Citations sections untouched.Generate index.md files (OKF §8 progressive disclosure; these contain no per-entry frontmatter):
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).index.md per category folder listing its pages: * [<title>](<slug>.md) - <description from the page's summary>.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.
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).
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.
okf/ bundle) are overwritten on each rungraph.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)wiki-export/ directory should be gitignored if the vault is version-controlled — these are derived artifactsgraph.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
Just SKILL.md in .skills/wiki-export of Ar9av/obsidian-wiki.
Open the folder on GitHubat commit 709727e
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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Wiki Export this skillAr9av/obsidian-wiki | 3.5k | — | ~6.9k | Automated safety check: Notes | MIT | |
| Swarmvaultswarmclawai/swarmvault | 708 | — | ~6.1k | Automated safety check: Pass | MIT | |
| Wiki DiagramIssacW228/student-llm-wiki | 176 | — | ~394 | Automated safety check: Pass | MIT | |
| Graphify Dotnetmanagedcode/dotnet-skills | 486 | — | ~1.9k | Automated safety check: Pass | MIT | |
| Obsidian Wiki Log FoldAgriciDaniel/claude-obsidian | 15k | 1 repos | ~1.2k | Automated safety check: Pass | MIT | |
| Llmwikiatomicstrata/llm-wiki-compiler | 2.2k | 1 repos | ~814 | Automated safety check: Pass | MIT |
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…
IssacW228/student-llm-wiki
Add Mermaid diagrams to wiki pages to aid understanding. An agent skill from IssacW228/student-llm-wiki.
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.
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.
atomicstrata/llm-wiki-compiler
Build and use a persistent, citation-traceable knowledge wiki from documents, research papers, notes, or project documentation.
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…
Ar9av/obsidian-wiki
Ingest Hermes agent history into Obsidian as distilled knowledge.
Ar9av/obsidian-wiki
Ingest Codex CLI conversation/session history into Obsidian as distilled knowledge.
Ar9av/obsidian-wiki
Ingest GitHub Copilot CLI/session history into Obsidian as distilled knowledge.
Ar9av/obsidian-wiki
Adjust the user's Obsidian visual layout with CSS snippets. An agent skill from Ar9av/obsidian-wiki.
Ar9av/obsidian-wiki
Ingest OpenClaw session/history data into Obsidian as distilled knowledge.
Ar9av/obsidian-wiki
Turn the current conversation or finding into a structured permanent wiki note.
Works with
Categories
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.
Wiki Export fits situations like: visualizing wiki data in external tools; wiki-import handles the reverse direction.
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.
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.
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.
Going by SKILL.md and its folder, Wiki Export needs the command-line tools its instructions call (psql).
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.
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.
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.
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.
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.
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.