Agent skill

Wiki Import

by Ar9av in Ar9av/obsidian-wiki

Import a wiki graph into the current vault from graph.json or an OKF/markdown bundle.

MITAuto-check: notesKnowledge Management

Install Wiki Import

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

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

GitHub CLI
$ gh skill install Ar9av/obsidian-wiki wiki-import --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-import .claude/skills/wiki-import && 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-import
GitHub stars
3.5k
Used in
1 other repo
Token cost
~4k tokens
SKILL.md length
1,841 words
Files
1
Skills in repo
39
Repo updated
First seen
Licence
MIT

At a glance

Import a wiki graph into the current vault from graph.json or an OKF/markdown bundle.

  • Works in 7 steps: Locate and Detect Source Type → Determine Conflict Resolution Mode → Build Internal Maps (graph.json only —… → …
  • Transferring previously exported wiki content between vaults
  • SKILL.md covers Before You Start, Step 1: Locate and Detect…, Step 2: Determine Conflict… and Step 3: Build Internal Maps…, plus 5 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Wiki Import is an agent skill from Ar9av/obsidian-wiki. 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.

Its SKILL.md is about 4k 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. 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

  • Transferring previously exported wiki content between vaults
  • Pair with wiki-export for the reverse direction

Example prompts

  • “/wiki-import”

Workflow steps

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

  1. Locate and Detect Source Type
  2. Determine Conflict Resolution Mode
  3. Build Internal Maps (graph.json only — skip for OKF bundles)
  4. Graph: Reconstruct Pages from graph.json (graph.json source only)
  5. OKF: Reconstruct Pages from an OKF bundle (OKF source only)
  6. Update Vault Metadata
  7. 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

    No scripts in the folder and no shell commands in SKILL.md (its code samples are json, markdown and bash).

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

  • Network

    No URLs in SKILL.md.

    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 Import loads about 4k tokens when it runs. Until then it costs about 54 tokens; SKILL.md has 1,841 words of instructions outside code blocks.

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

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:21
    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). 1,841 words, ~4,009 tokens.

Download SKILL.mdSave it as .claude/skills/wiki-import/SKILL.md (or your agent's skills folder).
name
wiki-import
description
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.

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 ## Related link 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.

  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. Read $OBSIDIAN_VAULT_PATH/AGENTS.md if 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 .md files with OKF frontmatter (a type: key), and/or a root index.md with okf_version → OKF bundle import (skip Step 3; go to Step 4-OKF). Both okf_version 0.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 .md file (i.e. not index.md/log.md) with parseable YAML frontmatter containing a non-empty type.
  • A .md with no frontmatter or no type is 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_PATH

OKF 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_PATH

Step 2: Determine Conflict Resolution Mode

Read the user's phrasing to determine mode. Default is merge.

ModeTrigger phrasesBehaviour
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:

  1. Compute page_path = $VAULT/<node.id>.md
  2. Ensure the parent directory exists (e.g. $VAULT/concepts/)
  3. 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
Page template (new or overwrite)
markdown
---
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)
  1. Read the existing page's frontmatter.
  2. Tags: union of existing tags and node.tags (deduplicated, keep existing order, append new ones).
  3. Summary: if the existing page has no summary field and node.summary exists, add it.
  4. Relationships: union of existing relationships: entries and typed_edges[node.id] — skip entries where the same (target, type) pair already exists.
  5. Updated: set updated to the current ISO timestamp.
  6. Body: scan for a ## Related section. If it exists, append any missing wikilinks from adjacency[node.id] that aren't already linked anywhere in the body. If no ## Related section exists, append one with the missing links.
  7. 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):

  1. Parse the YAML frontmatter. If it has no frontmatter or no non-empty type, increment unparseable and skip the file.
  2. Compute the concept id = the file's path relative to the bundle root, with .md stripped (e.g. concepts/transformers.md → concepts/transformers). The target page is $VAULT/<concept-id>.md.
  3. Reverse-map frontmatter (the inverse of the canonical mapping table in wiki-export Step 3.5):
    • title ← title.
    • category ← the preserved category extension key if present; else lower-case the directory prefix of the concept id (concepts/… → concepts); else derive from type (Concept→concepts, Entity→entities, Skill→skills, Reference→references, Synthesis→synthesis, Project→projects, Journal→journal).
    • tags ← tags.
    • summary ← description.
    • updated ← the preserved updated extension key if present; else generated.at; else a legacy v0.1 timestamp; else now.
    • created ← the preserved created extension key if present, else now.
    • sources ← OKF sources, as a list of strings: for each entry that is a mapping, take its resource; keep plain strings as-is (that's how v0.1 bundles from older exports carried our native list). If the bundle has no sources, use ["imported from OKF bundle <bundle path>"]. If a top-level resource URL is present and not already in the list, add it.
    • lifecycle ← the preserved lifecycle extension key if present; else from status: draft → draft, deprecated → archived, stable or absent → leave lifecycle unset. (OKF has no equivalent of reviewed/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 keys generated, verified, stale_after, and usage_window so a later export doesn't lose them. These make the round-trip lossless. Treat a bare verified mapping as a one-element list (OKF §5.2).
    • Except what our own exporter derived. Drop generated when generated.by starts with obsidian-wiki/ (it was computed from updated), and drop verified entries whose by is human: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.
  4. Reverse-transform body links — markdown links that point at .md paths become wikilinks (this restores both real cross-links and forward-references the exporter preserved per wiki-export Step 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]] when text differs 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 .md path relative to the current file, then strip the trailing .md from 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 like projects/social-twitter.md plus projects/social-twitter/..., where ../../social-twitter.md must restore to projects/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=markdown is 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 # Citations sections untouched.
  5. Write the page using the conflict mode from Step 2:
    • merge + exists → reverse-map frontmatter and merge it into the existing page (union tags; fill summary/sources only if missing; union relationships; refresh updated). 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. Increment merged.
    • 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 as Replaced in the summary).
    • overwrite + doesn't exist → write the full page. Increment created.
  6. Ensure the parent directory ($VAULT/concepts/, etc.) exists before writing.
Show full SKILL.md (378 more words)Show less

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:

json
"<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_ingested by 1
  • stats.total_pages by the count of pages actually created (not skipped/merged)

If .manifest.json doesn't exist, create it with the standard structure:

json
{
  "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:

bash
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 merge mode is idempotent — re-running on an unchanged export will update timestamps but won't destroy content. Use overwrite only 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 links but absent from nodes (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.json was produced with visibility filtering (noted in graph.metadata), imported pages will only reflect the filtered set. Note this in the summary if graph.graph contains a filtered key.

© 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-import of Ar9av/obsidian-wiki.

Open the folder on GitHubat commit 709727e

Used in 1 other repository

We found 1 copy of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in Ar9av/obsidian-wiki, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Wiki Import 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 Import compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Wiki Import this skillAr9av/obsidian-wiki3.5k1 repos~4kAutomated safety check: NotesMIT
Karpathy LLM WikiAstro-Han/karpathy-llm-wiki2.4k—~3.6kAutomated safety check: PassMIT
LLM Wiki Knowledge GraphEgonex-AI/Understand-Anything86k1 repos~1.5kAutomated safety check: PassMIT
LLM Wikilewislulu/llm-wiki-skill655—~3.7kAutomated safety check: PassNone
Wiki Builderrohitg00/pro-workflow2.9k—~1kAutomated safety check: PassNone
Wiki Queryrohitg00/pro-workflow2.9k1 repos~554Automated safety check: PassNone

Similar skills

  • Karpathy LLM Wiki

    Astro-Han/karpathy-llm-wiki

    A skill your agent uses when building or maintaining a personal LLM-powered knowledge base.

    2.4k GitHub stars~3.6k tokensUpdated 2 mo ago
    Knowledge ManagementAuto-check passed
  • LLM Wiki Knowledge Graph

    Egonex-AI/Understand-Anything

    Detects a Karpathy-pattern LLM wiki and builds an interactive knowledge graph with entities, implicit relationships and topic clusters.

    86k GitHub starsUsed in 1 repo~1.5k 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
  • Wiki Builder

    rohitg00/pro-workflow

    Start, structure, and grow a persistent research wiki indexed in pro-workflow's SQLite knowledge base.

    2.9k GitHub stars~1k tokensUpdated 9 days ago
    Knowledge ManagementAuto-check passed
  • Wiki Query

    rohitg00/pro-workflow

    Query pro-workflow wikis via SQLite FTS5 BM25 retrieval. An agent skill from rohitg00/pro-workflow.

    2.9k GitHub starsUsed in 1 repo~554 tokens
    Knowledge ManagementAuto-check passed
  • Arkon Edit

    nduckmink/arkon

    Propose or directly apply edits to Arkon wiki pages, including proposing brand new pages.

    1.5k GitHub stars~1.6k tokensUpdated 4 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 Import

What does Wiki Import do?

Import a wiki graph into the current vault from graph.json or an OKF/markdown bundle. Wiki Import is an agent skill from Ar9av/obsidian-wiki.json or an OKF/markdown bundle.

When should I use Wiki Import?

Wiki Import fits situations like: transferring previously exported wiki content between vaults; pair with wiki-export for the reverse direction.

How do I install Wiki Import in Claude Code?

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

How do I install Wiki Import in Codex?

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

Can I use Wiki Import 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-import -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-import, .gemini/skills/wiki-import, .github/skills/wiki-import and .opencode/skills/wiki-import in your project.

What does Wiki Import need to run?

SKILL.md names no scripts, command-line tools or credentials: Wiki Import is instructions for the agent only.

Does Wiki Import access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Wiki Import 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 Import use?

Wiki Import 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 Import use?

About 4k tokens (SKILL.md is roughly 16k 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 Import?

Skills that share tags, products or a category with Wiki Import: Karpathy LLM Wiki (Astro-Han/karpathy-llm-wiki, 2.4k stars), LLM Wiki Knowledge Graph (Egonex-AI/Understand-Anything, 86k stars), LLM Wiki (lewislulu/llm-wiki-skill, 655 stars) and Wiki Builder (rohitg00/pro-workflow, 2.9k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Wiki Import?

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.