wiki-import
Skill3.7k starsChanged 8 days agoMITView on GitHub
Import a wiki graph into the current vault from graph.json or an OKF/markdown bundle. Use for transferring previously exported wiki content between vaults; pair with wiki-export for the reverse direction.
- Reads credentials
1 other project uses a version of this, 1 of them edited.
Adopted by
Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data
Most recently taken up by
- chobizzy/llm-wikiedited, first seen Nov 1, 2026
Who's talking about Ar9av/obsidian-wiki
- @ar9av.bsky.social“github.com/Ar9av/obsidi...”Bluesky · Oct 8, 2026 · 1 likes
- @pythonhub.dev“obsidian-wiki Framework for AI agents to build and maintain a digital brain through Obsidian wiki using …”Bluesky · Jun 23, 2026 · 1 likes
- sudosubin/agents.nix“claude-code-marketplaces.github.ar9av.obsidian-wiki: 2026.10.4 → 2026.11.2”GitHub · Nov 4, 2026
- sudosubin/agents.nix“claude-code-plugins.github.ar9av.obsidian-wiki: 2026.10.4 → 2026.11.2”GitHub · Nov 4, 2026
- sudosubin/agents.nix“agent-skills.github.ar9av.obsidian-wiki: 2026.10.4 → 2026.11.2”GitHub · Nov 4, 2026
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
- Nov 4, 2026claude-code-marketplaces.github.ar9av.obsidian-wiki: 2026.10.4 → 2026.11.2 — sudosubin/agents.nix0 reactions
- Nov 4, 2026claude-code-plugins.github.ar9av.obsidian-wiki: 2026.10.4 → 2026.11.2 — sudosubin/agents.nix0 reactions
- Nov 4, 2026agent-skills.github.ar9av.obsidian-wiki: 2026.10.4 → 2026.11.2 — sudosubin/agents.nix0 reactions
- Nov 2, 2026fix(deps): update dependency obsidian-wiki to v2026.10.4 — lkshrk/agent-stack0 reactions · 2 comments
- Nov 1, 2026chore(deps): update dependency pipx:obsidian-wiki to v2026.10.4 — lkshrk/agent-stack0 reactions · 2 comments
20 more on GitHub
- Oct 28, 2026claude-code-plugins.github.ar9av.obsidian-wiki: init at 2026.10.4 — sudosubin/agents.nix0 reactions
- Oct 28, 2026claude-code-marketplaces.github.ar9av.obsidian-wiki: init at 2026.10.4 — sudosubin/agents.nix0 reactions
- Oct 27, 2026agent-skills.github.ar9av.obsidian-wiki: 2026.10.3 → 2026.10.4 — sudosubin/agents.nix0 reactions
- Oct 21, 2026agent-skills.github.ar9av.obsidian-wiki: 2026.10.2 → 2026.10.3 — sudosubin/agents.nix0 reactions
- Oct 13, 2026agent-skills.github.ar9av.obsidian-wiki: 2026.10.1 → 2026.10.2 — sudosubin/agents.nix0 reactions
- Oct 3, 2026agent-skills.github.ar9av.obsidian-wiki: init at 2026.10.1 — sudosubin/agents.nix0 reactions
- Sep 27, 2026[Candidate] ar9av/obsidian-wiki/.skills/llm-wiki - llm-wiki — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 27, 2026[Candidate] ar9av/obsidian-wiki/.skills/impl-validator - impl-validator — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 27, 2026[Candidate] ar9av/obsidian-wiki/.skills/hermes-history-ingest - hermes-history-ingest — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 26, 2026[Candidate] ar9av/obsidian-wiki/.skills/graph-colorize - graph-colorize — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 26, 2026[Candidate] ar9av/obsidian-wiki/.skills/cross-linker - cross-linker — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 26, 2026[Candidate] ar9av/obsidian-wiki/.skills/copilot-history-ingest - copilot-history-ingest — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 26, 2026[Candidate] ar9av/obsidian-wiki/.skills/codex-history-ingest - codex-history-ingest — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 26, 2026[Candidate] ar9av/obsidian-wiki/.skills/code-understand - code-understand — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 26, 2026[Candidate] ar9av/obsidian-wiki/.skills/claude-history-ingest - claude-history-ingest — ProSkillsMD/proskills0 reactions · 1 comment
- Jul 12, 2026Add obsidian-wiki as a local workspace — aristoapp/awesome-second-brain0 reactions
- Jun 20, 2026feat: Obsidian-compatible wiki.md output from compiled graph — manhhailua/lorekeep0 reactions · 1 comment
- Jun 15, 2026Daily tribute 2026-06-15: obsidian-wiki by @_ar9av — Talonsturgill/signalsniper0 reactions
- May 15, 2026Tracking: AI workflow patterns & companion plugins — brenthaertlein/universal-skills0 reactions · 1 comment
- Apr 9, 2026wiki 生成质量提高 — nashsu/llm_wiki0 reactions · 2 comments
On Bluesky · 2
- Oct 8, 2026github.com/Ar9av/obsidi... — @ar9av.bsky.social1 likes and repost
- Jun 23, 2026obsidian-wiki Framework for AI agents to build and maintain a digital brain through Obsidian wiki using Karpathy's LLM Wiki pattern.… — @pythonhub.dev1 likes and repost · 1 reply
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- chobizzy/llm-wiki★ 383% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository43 other files it gives its agents.
- AGENTS.mdAGENTS.md
- docs/agents.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/obsidian-wiki.mdcCursor rule
- claude-history-ingestSkill
- code-understandSkill
- codex-history-ingestSkill
- copilot-history-ingestSkill
- cross-linkerSkill
- daily-updateSkill
- graph-colorizeSkill
- hermes-history-ingestSkill
- impl-validatorSkill
- llm-wikiSkill
- memory-bridgeSkill
- obsidian-layout-adjustmentSkill
- openclaw-history-ingestSkill
- pi-history-ingestSkill
- session-brainSkill
- session-searchSkill
- skill-creatorSkill
- tag-taxonomySkill
- vault-skill-factorySkill
- wiki-agentSkill
- wiki-captureSkill
- wiki-context-packSkill
- wiki-dashboardSkill
- wiki-dedupSkill
- wiki-digestSkill
- wiki-exportSkill
- wiki-history-ingestSkill
- wiki-ingestSkill
- wiki-lintSkill
- wiki-narrateSkill
- wiki-querySkill
- wiki-rebuildSkill
- wiki-researchSkill
- wiki-setupSkill
- wiki-stage-commitSkill
- wiki-statusSkill
- wiki-switchSkill
- wiki-synthesizeSkill
- wiki-updateSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
25 rules. About 0 are common, 9 are distinctive, and 16 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
16
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 18
Writing profile: Before drafting or rewriting natural-language Markdown, read and apply the Writing Profile Resolution section in …
- Very specific: line 22
Read $OBSIDIAN_VAULT_PATH/AGENTS.md if it exists — apply any owner-specific conventions.
- Distinctive: line 27
If the user provided a path argument, use it directly.
- Distinctive: line 29
If neither exists, ask the user for the path.
- Distinctive: line 37
Must be valid JSON
- Very specific: line 38
Must have top-level keys: nodes (array), links (array), graph (object)
- Distinctive: line 39
Must have at least 1 node
- Distinctive: line 41
If validation fails, report what's wrong and stop.
- Very specific: line 44
Must contain at least 1 non-reserved .md file (i.e.
- Very specific: line 68
Read the user's phrasing to determine mode.
- Very specific: line 78
Before writing anything, build two maps from the links array:
- Very specific: line 100
Ensure the parent directory exists (e.g.
- Distinctive: line 101
Check if the file already exists:
- Very specific: line 151
If adjacency[node.id] is empty, omit the ## Related section entirely.
- Distinctive: line 155
Read the existing page's frontmatter.
- Very specific: line 157
Summary: if the existing page has no summary field and node.summary exists, add it.
- Distinctive: line 161
Leave the rest of the body untouched.
- Very specific: line 186
When OBSIDIAN_LINK_FORMAT=markdown is set in config, keep markdown links (just rewrite the path to be vault-relative).
- Very specific: line 187
Leave external http(s):// links and # Citations sections untouched.
- Very specific: line 195
Ensure the parent directory ($VAULT/concepts/, etc.) exists before writing.
- Very specific: line 203
Add a new entry keyed by the canonical path of the graph.json file:
- Very specific: line 220
If .manifest.json doesn't exist, create it with the standard structure:
- Very specific: line 257
Only show the Skipped line if skip mode was explicitly requested.
- Distinctive: line 263
Directory creation: Always create missing category directories before writing pages.
- Very specific: line 265
Filtered exports: If the source graph.json was produced with visibility filtering (noted in graph.metadata), imported pages will only …
≈ “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.
Files
Wiki Import — Reconstruct Pages from an Export
You are importing a vault's knowledge into the current vault from one of two sources produced by wiki-export:
graph.json— the graph skeleton. Reconstructs page stubs (frontmatter, typed relationships, a## Relatedlink list — no body). Lossy.- OKF bundle (a
wiki-export/okf/directory) — the actual markdown files. Reconstructs full pages with their real bodies. Lossless. Use this for true vault-to-vault transfer.
Either way, the import writes pages with correct frontmatter and wikilinks, then updates all vault metadata. Step 2, Step 3 (graph only), and Step 5 are shared; Step 4 forks by source type.
Before You Start
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.
Preserve imported source prose; apply WRITING.md preferences only to newly generated metadata or stubs.
- Resolve config — follow the Config Resolution Protocol in
llm-wiki/SKILL.md(inline@nameoverride → walk up CWD for.env→ global config → prompt setup). This givesOBSIDIAN_VAULT_PATH. - Read
$OBSIDIAN_VAULT_PATH/AGENTS.mdif it exists — apply any owner-specific conventions.
Step 1: Locate and Detect Source Type
Find the import source:
- If the user provided a path argument, use it directly.
- Otherwise auto-detect, in order:
./wiki-export/okf/(a directory) →./wiki-export/graph.json(a file). - If neither exists, ask the user for the path.
Detect the source type:
- The path is a file ending in
.json→ graph.json import (validate below, then Step 3 + Step 4-Graph). - The path is a directory containing
.mdfiles with OKF frontmatter (atype:key), and/or a rootindex.mdwithokf_version→ OKF bundle import (skip Step 3; go to Step 4-OKF). Bothokf_version0.1 and 0.2 bundles are accepted; Step 4-OKF reads either. - Anything else → report what's wrong and stop.
Validate a graph.json source:
- Must be valid JSON
- Must have top-level keys:
nodes(array),links(array),graph(object) - Must have at least 1 node
If validation fails, report what's wrong and stop.
Validate an OKF bundle source:
- Must contain at least 1 non-reserved
.mdfile (i.e. notindex.md/log.md) with parseable YAML frontmatter containing a non-emptytype. - A
.mdwith no frontmatter or notypeis skipped (with a count), not fatal — OKF consumers are permissive (OKF §11).
Show a preview before importing:
graph.json:
Import preview (graph.json — stubs)
Source: <path> (exported at <graph.exported_at>)
Nodes: N total (concepts: A, entities: B, skills: C, references: D, ...)
Links: M edges (X typed, Y untyped)
Target: $OBSIDIAN_VAULT_PATHOKF bundle:
Import preview (OKF bundle — full pages)
Source: <dir> (okf_version <ver if present>)
Pages: N total (concepts: A, entities: B, skills: C, references: D, ...)
Target: $OBSIDIAN_VAULT_PATHStep 2: Determine Conflict Resolution Mode
Read the user's phrasing to determine mode. Default is merge.
| Mode | Trigger phrases | Behaviour |
merge | (default, no special phrasing) | Existing pages: update frontmatter tags/summary/relationships and add missing wikilinks; new pages: create stub. |
skip | "skip existing", "don't overwrite", "only new pages" | Leave existing pages completely untouched; only create pages that don't exist yet. |
overwrite | "overwrite", "replace existing", "force import" | Replace all matched pages with freshly reconstructed stubs regardless of existing content. |
Step 3: Build Internal Maps (graph.json only — skip for OKF bundles)
Before writing anything, build two maps from the links array:
Adjacency map — for each node id, collect all neighbour ids (edges in either direction):
adjacency["concepts/transformers"] = ["entities/vaswani", "concepts/lstm", ...]Typed edge map — for each node id, collect outgoing typed edges only (typed: true):
typed_edges["concepts/transformers"] = [
{target: "concepts/lstm", relation: "contradicts"},
...
]Step 4-Graph: Reconstruct Pages from graph.json (graph.json source only)
Record counts: created = 0, skipped = 0, merged = 0.
For each node in nodes:
- Compute
page_path = $VAULT/<node.id>.md - Ensure the parent directory exists (e.g.
$VAULT/concepts/) - Check if the file already exists:
- merge mode (default) + exists → read existing file, apply merge logic (see below), increment
merged - merge mode (default) + doesn't exist → proceed to create stub, increment
created - skip mode + exists → increment
skipped, continue to next node - skip mode + doesn't exist → proceed to create stub, increment
created - overwrite mode + exists → proceed to write fresh stub (overwrite), increment
merged - overwrite mode + doesn't exist → proceed to create stub, increment
created
- merge mode (default) + exists → read existing file, apply merge logic (see below), increment
Page template (new or overwrite)
---
title: <node.label>
category: <node.category>
tags: <node.tags as YAML list>
sources:
- "imported from <graph.json path>"
<if node.summary exists>
summary: "<node.summary>"
</if>
<if typed_edges[node.id] is non-empty>
relationships:
<for each {target, relation} in typed_edges[node.id]>
- target: "[[<target>]]"
type: <relation>
</for>
</if>
lifecycle: draft
lifecycle_changed: <today YYYY-MM-DD>
base_confidence: 0.5
tier: supporting
created: <ISO timestamp>
updated: <ISO timestamp>
---
# <node.label>
<node.summary paragraph if available, else omit>
## Related
<for each neighbour in adjacency[node.id], sorted alphabetically>
<if edge is typed>
- [[<neighbour>]] — <relation>
<else>
- [[<neighbour>]]
</if>
</for>If adjacency[node.id] is empty, omit the ## Related section entirely.
Merge logic (merge mode, existing page)
- Read the existing page's frontmatter.
- Tags: union of existing tags and
node.tags(deduplicated, keep existing order, append new ones). - Summary: if the existing page has no
summaryfield andnode.summaryexists, add it. - Relationships: union of existing
relationships:entries andtyped_edges[node.id]— skip entries where the same(target, type)pair already exists. - Updated: set
updatedto the current ISO timestamp. - Body: scan for a
## Relatedsection. If it exists, append any missing wikilinks fromadjacency[node.id]that aren't already linked anywhere in the body. If no## Relatedsection exists, append one with the missing links. - Leave the rest of the body untouched.
Step 4-OKF: Reconstruct Pages from an OKF bundle (OKF source only)
Record counts: created = 0, skipped = 0, merged = 0, unparseable = 0.
Walk the bundle directory tree. For each .md file that is not a reserved file (index.md, log.md):
- Parse the YAML frontmatter. If it has no frontmatter or no non-empty
type, incrementunparseableand skip the file. - Compute the concept id = the file's path relative to the bundle root, with
.mdstripped (e.g.concepts/transformers.md→concepts/transformers). The target page is$VAULT/<concept-id>.md. - Reverse-map frontmatter (the inverse of the canonical mapping table in
wiki-exportStep 3.5):title←title.category← the preservedcategoryextension key if present; else lower-case the directory prefix of the concept id (concepts/…→concepts); else derive fromtype(Concept→concepts,Entity→entities,Skill→skills,Reference→references,Synthesis→synthesis,Project→projects,Journal→journal).tags←tags.summary←description.updated← the preservedupdatedextension key if present; elsegenerated.at; else a legacy v0.1timestamp; else now.created← the preservedcreatedextension key if present, else now.sources← OKFsources, as a list of strings: for each entry that is a mapping, take itsresource; keep plain strings as-is (that's how v0.1 bundles from older exports carried our native list). If the bundle has nosources, use["imported from OKF bundle <bundle path>"]. If a top-levelresourceURL is present and not already in the list, add it.lifecycle← the preservedlifecycleextension key if present; else fromstatus:draft→draft,deprecated→archived,stableor absent → leavelifecycleunset. (OKF has no equivalent ofreviewed/verified/disputed, so only our own exports restore them, through the preserved key.)- Carry through any other preserved extension keys verbatim (
relationships,lifecycle_changed,tier,base_confidence, …), and the OKF-only keysgenerated,verified,stale_after, andusage_windowso a later export doesn't lose them. These make the round-trip lossless. Treat a bareverifiedmapping as a one-element list (OKF §5.2). - Except what our own exporter derived. Drop
generatedwhengenerated.bystarts withobsidian-wiki/(it was computed fromupdated), and dropverifiedentries whosebyishuman:vault-owner(computed from the source vault's trust ledger, which doesn't travel). Keeping them would add keys the source page never had. Generated or verified blocks from any other producer are kept.
- Reverse-transform body links — markdown links that point at
.mdpaths become wikilinks (this restores both real cross-links and forward-references the exporter preserved perwiki-exportStep 3.5):[text](../concepts/transformers.md)or[text](/concepts/transformers.md)→ resolve the path (relative to this file's dir, or bundle-root for/-absolute) to a concept id →[[concepts/transformers]], or[[concepts/transformers|text]]whentextdiffers from the target's title. The target's title comes from the bundle page when it exists; otherwise the exporter wrote the target's id as the link text, so treat text equal to the full id (or to its last path segment) as no alias.- Treat the markdown target as a file path first: normalize the
.mdpath relative to the current file, then strip the trailing.mdfrom the resolved file path to recover the page id. Do not try to infer the id from directory traversal segments before resolving the full file path. This preserves round-trips for folder-note layouts likeprojects/social-twitter.mdplusprojects/social-twitter/..., where../../social-twitter.mdmust restore toprojects/social-twitter. - This applies even when the target page is not in the bundle — a path-form link to a not-yet-written page round-trips back to a dangling
[[wikilink]](Obsidian supports these; OKF §11 forbids rejecting them). Do not leave it as a markdown link. - When
OBSIDIAN_LINK_FORMAT=markdownis set in config, keep markdown links (just rewrite the path to be vault-relative); do not convert to wikilinks. - Leave external
http(s)://links and# Citationssections untouched.
- Write the page using the conflict mode from Step 2:
- merge + exists → reverse-map frontmatter and merge it into the existing page (union
tags; fillsummary/sourcesonly if missing; unionrelationships; refreshupdated). For the body, OKF carries a real body: replace the existing body with the bundle body only if the existing page is a stub (body is just a heading +## Related); otherwise keep the existing body and append any bundle# Citations/ new##sections not already present. Incrementmerged. - merge + doesn't exist → write the full page (frontmatter + full bundle body). Increment
created. - skip + exists → increment
skipped, continue. - skip + doesn't exist → write the full page. Increment
created. - overwrite + exists → write the full page, replacing the existing one. Increment
merged(label asReplacedin the summary). - overwrite + doesn't exist → write the full page. Increment
created.
- merge + exists → reverse-map frontmatter and merge it into the existing page (union
- Ensure the parent directory (
$VAULT/concepts/, etc.) exists before writing.
Unlike the graph.json path, do not generate a ## Related stub section — the bundle body already contains the real cross-links.
Step 5: Update Vault Metadata
.manifest.json
Add a new entry keyed by the canonical path of the graph.json file:
"<absolute path to source>": {
"ingested_at": "<ISO timestamp>",
"source_type": "wiki-export",
"pages_created": ["list/of/created/pages.md"],
"pages_updated": ["list/of/merged/pages.md"]
}Set source_type to "wiki-export" for a graph.json import or "okf-bundle" for an OKF bundle import. Key the entry by the absolute path of the source (the graph.json file or the bundle directory).
Also increment:
stats.total_sources_ingestedby 1stats.total_pagesby the count of pages actually created (not skipped/merged)
If .manifest.json doesn't exist, create it with the standard structure:
{
"stats": {
"total_sources_ingested": 1,
"total_pages": <created count>
},
"<graph.json path>": { ... }
}index.md, log.md, and hot.md
One locked call. The index is reconciled from the pages now on disk, so every created or merged page lands under its category with the documented ( #tag) spacing:
obsidian-wiki memory sync IMPORT \
source="<bundle path>" \
pages_created=<N> pages_skipped=<K> pages_merged=<M> \
--takeaways "Imported <bundle>: <what it adds to the picture>"Omit --takeaways if the import does not shift the overall picture; the previous takeaways carry across. Never hand-edit index.md, log.md, or hot.md — the command takes the lock that keeps a parallel writer from dropping your update.
See skills/llm-wiki/references/MEMORY.md for the full procedure.
Step 6: Print Summary
Wiki import complete → $OBSIDIAN_VAULT_PATH
Source: <source path> (<graph.json | OKF bundle>)
<graph: exported at <graph.exported_at>, N nodes, M links | okf: N pages, okf_version <ver>>
Created: <X> pages
Merged: <Z> pages (existing pages updated)
Skipped: <Y> pages (only when --skip mode was used)Only show the Skipped line if skip mode was explicitly requested. If overwrite mode was used, label merged pages as Replaced instead. For an OKF import, also report Unparseable: <U> files (no frontmatter/type, skipped) when U > 0.
Notes
- Stub vs full pages: A graph.json import produces stubs — structure and wikilinks but no body, a starting point for future ingestion. An OKF bundle import produces full pages with real bodies — it is the lossless, content-bearing path and the right choice for vault-to-vault transfer.
- Re-running is safe: The default
mergemode is idempotent — re-running on an unchanged export will update timestamps but won't destroy content. Useoverwriteonly when you want to fully reset pages to stubs. - Directory creation: Always create missing category directories before writing pages.
- Broken wikilinks: Since pages are being created together from the same export, most links will resolve. Any node referenced in
linksbut absent fromnodes(broken in the original export) will still appear as a wikilink — it just won't have a corresponding page file, which is valid. - Filtered exports: If the source
graph.jsonwas produced with visibility filtering (noted ingraph.metadata), imported pages will only reflect the filtered set. Note this in the summary ifgraph.graphcontains afilteredkey.
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
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.

