mcpbeat Sign in

Vault Skill Factory Agent Skill

> Generate a portable, self-contained Agent Skill from mature, curated Obsidian wiki pages — turning a cluster of verified knowledge into a reusable "digital expert" (SKILL.md + references/). Use this skill when the user says "/vault-skill-factory", "make a skill from my wiki", "turn these pages into a skill", "generate an agent skill from my vault", "package my notes on X as a skill", "build a domain-expert skill from my wiki", or wants to distill recurring, mature wiki knowledge into a shareable skill. Inspired by OpenKB's "drop in a book → out comes a digital expert" pattern. The factory ONLY reads the vault and WRITES TO A REVIEW DIRECTORY — it never installs skills, never writes into .skills/, and never touches global skill directories.

2k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
3103
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/Ar9av/obsidian-wiki --skill vault-skill-factory

The instruction itself

9 sections, as written by the author

Vault Skill Factory

You turn a cluster of mature, curated wiki pages into a portable Agent Skill: a

SKILL.md plus a references/ folder, written to a review directory for the human to inspect

and (only if they choose) install. This is the inverse of wiki-capture: capture turns a

conversation into a page; the factory turns a body of pages into a reusable skill.

Hard guardrails (read first)

  • Never write into .skills/ and never run setup.sh or create symlinks into any global

skill directory (~/.claude/skills, ~/.codex/skills, …). Generated skills go to the review

dir only. Installation is a separate, explicit human decision.

  • Never auto-install. End by telling the user where the skill is and how to install it

*project-locally* if they want — do not do it for them.

  • Source pages are trusted vault content, but do not invent capabilities: the generated skill must

reflect what the pages actually say.

Before You Start

  • Resolve config (Config Resolution Protocol in llm-wiki/SKILL.md): get OBSIDIAN_VAULT_PATH,

OBSIDIAN_WIKI_REPO, OBSIDIAN_LINK_FORMAT, the QMD vars, and:

  • SKILL_FACTORY_OUTPUT_DIR — where generated skills land. Default:

$OBSIDIAN_VAULT_PATH/_generated-skills (a vault-level, underscore-prefixed *excluded* dir —

like _raw/_staging/_sources, NOT the skills/ knowledge category). This co-locates

generated skills with the vault they were distilled from. Create it if missing.

Note: _generated-skills/ holds runtime Agent-Skill bundles (name + description frontmatter),

not wiki pages — never write them into skills/ (that category is for knowledge pages and

is graph-/lint-/index-tracked).

  • SKILL_FACTORY_MATURITY — comma list of lifecycle: values that count as "mature".

Default: reviewed,verified. Pages with tier: core also qualify.

  • Read index.md to understand what the vault holds.

Step 1: Choose the cluster

Decide which pages become the skill. The user may name a topic, tag, or project; otherwise propose

candidates.

  • Seed from the user's intent (a topic, tag, project, or a named page).
  • Expand the cluster:
  • If QMD is configured (QMD_WIKI_COLLECTION), run qmd query "<topic>" -c "$QMD_WIKI_COLLECTION" --files

(or vsearch) to gather semantically related pages — this is the intended way to find the

full cluster, not just exact-tag matches.

  • Otherwise Grep/Glob by tag and wikilink-neighbourhood (pages linked from the seed pages).
  • Filter by maturity: keep pages whose lifecycle: is in SKILL_FACTORY_MATURITY or

whose tier: is core. Drop draft pages unless the user explicitly includes them.

  • Confirm the cluster with the user (list page names + count) before generating. If fewer than

~3 mature pages match, say so — a skill from one thin page isn't worth it; offer to proceed anyway

or widen the net.

Step 2: Design the skill

From the cluster, decide:

  • name — kebab-case, derived from the cluster's subject (e.g. french-theory-expert,

peptide-protocols). Must not collide with an existing skill in .skills/.

  • description — the trigger. Write it "pushy" (per skill-creator): state when to use it

(all the phrasings a user might say) and what it does. This field is what makes the skill fire.

  • Reasoning approach — how an agent should *use* this knowledge: the questions it answers, the

method it applies, the caveats it respects. Distil this from the pages' synthesis, not a copy-paste.

  • Depth material — which page bodies become references/ files.

Step 3: Write the skill to the review dir

Create $SKILL_FACTORY_OUTPUT_DIR/<name>/ with:

<name>/
├── SKILL.md            # frontmatter (name + pushy description) + reasoning approach + key knowledge
├── references/         # depth material distilled from the cluster
│   ├── <topic>.md      # one per sub-theme; declarative knowledge, not chat
│   └── sources.md      # provenance: which vault pages this was built from (+ their sources)
└── SKILL_FACTORY.md    # provenance manifest (see below) — NOT part of the installed skill

SKILL.md body should be lean (the trigger logic + a compact reasoning guide), pushing depth into

references/. Follow the structure of existing skills in this repo. Preserve ^[inferred] /

^[ambiguous] markers when carrying over uncertain claims — a generated skill must not launder

synthesis into fact.

references/sources.md lists every vault page used (by [[wikilink]]) and their upstream

sources: — so the skill stays auditable back to the vault and original sources.

SKILL_FACTORY.md (factory metadata, kept out of the installable skill) records: generation

date, the cluster pages + their lifecycle/tier, the maturity filter used, and the vault commit/hash

if available. This lets a regenerate-on-update workflow diff later.

Optional, if the user asks: append/update a marketplace.json entry in the output dir (the OpenKB

one-line-install convention) — still not an install, just a manifest.

Step 4: Optionally lean on skill-creator

skill-creator ships reusable scripts ($OBSIDIAN_WIKI_REPO/.skills/skill-creator/scripts/):

  • improve_description.py — tighten the generated description for better triggering.
  • package_skill.py — bundle the skill dir into a distributable archive.
  • quick_validate.py — sanity-check the skill's structure.

Use them when the user wants a polished/validated artifact; don't reinvent them.

Step 5: Report — and stop

Tell the user:

  • the path: $SKILL_FACTORY_OUTPUT_DIR/<name>/
  • the cluster it was built from (page count + names)
  • the trigger description
  • How to install if they want it (their decision, project-local only):
  ln -s ../../.skills/<name> <repo>/.claude/skills/<name>   # after copying <name>/ into .skills/, sans SKILL_FACTORY.md

Note explicitly: review first; do not run setup.sh (it fans skills into global dirs); never global-install without explicit agreement.

Do not install it yourself. Do not write to .skills/. Done.

Quality checklist

  • [ ] Output went to $SKILL_FACTORY_OUTPUT_DIR, never .skills/ or a global dir
  • [ ] Cluster confirmed with the user; only mature pages (per SKILL_FACTORY_MATURITY / tier: core)
  • [ ] description is pushy and accurate (when + what)
  • [ ] SKILL.md body is lean; depth lives in references/
  • [ ] ^[inferred]/^[ambiguous] markers preserved; no synthesis laundered into fact
  • [ ] references/sources.md traces back to vault pages + their sources
  • [ ] SKILL_FACTORY.md provenance manifest present (excluded from the installable skill)
  • [ ] Report names the path and the manual, project-local-only install step; nothing auto-installed

Other skills for the same job

different authors, same section of the catalogue
Plugin Settings
by anthropics
vendor ×2

This skill should be used when the user asks about "plugin settings", "store plugin configuration", "user-configurable plugin", ".local.md files", "plugin state files", "read YAML frontmatter", "per-project plugin settings", or wants to make plugin behavior configurable. Documents the .claude/plugin-name.local.md pattern for storing plugin-specific configuration with YAML frontmatter and markdown content.

11k tokens scripts
Skill Seekers
by ComeOnOliver
×2

-Automatically convert documentation websites, GitHub repositories, and PDFs into Claude AI skills in minutes.

2k tokens
Plugin Settings
by anthropics
vendor ×1

This skill should be used when the user asks about "plugin settings", "store plugin configuration", "user-configurable plugin", ".local.md files", "plugin state files", "read YAML frontmatter", "per-project plugin settings", or wants to make plugin behavior configurable. Documents the .claude/plugin-name.local.md pattern for storing plugin-specific configuration with YAML frontmatter and markdown content.

11k tokens scripts
Project Cairn
by iBlinkQ
×1

Standardize how an AI-collaboration project turns work into reusable knowledge. Use when initializing or retrofitting Project Cairn in a project, recording progress after meaningful work, maintaining AGENTS/CLAUDE/cairn docs, auditing project knowledge for drift or missing records, pulling and citing external knowledge, or graduating validated project experience into a reusable knowledge base.

2060k tokens scripts
Opencontext
by ComeOnOliver
×1

Persistent memory and context management for AI agents using OpenContext. Keep context across sessions/repos/dates, store conclusions, and provide document search workflows.

4k tokens
Para Skill
by ComeOnOliver
×1

> PARA method knowledge management for Obsidian vaults. Use this skill whenever the user wants to organize notes using PARA (Projects, Areas, Resources, Archive), classify a note into a PARA category, route a note to the right vault folder, normalize frontmatter fields, run a PARA hygiene review, suggest archiving, audit vault structure, or process new knowledge inputs into an existing PARA-based vault. Also trigger when the user mentions inbox processing, vault cleanup, note classification, PARA review, or asks "where does this note belong?". Works with existing Obsidian skills (obsidian-markdown, obsidian-cli) — never replaces them.

17k tokens
N8n:spec Driven Development
by n8n-io
vendor

Keeps implementation and specs in sync. Use when working on a feature that has a spec in .agents/specs/, when the user says /spec, or when starting implementation of a documented feature. Also use when the user asks to verify implementation against a spec or update a spec after changes.

807 tokens
Knowledge Agent
by thedotmack

Build and query AI-powered knowledge bases from claude-mem observations. Use when users want to create focused "brains" from their observation history, ask questions about past work patterns, or compile expertise on specific topics.

622 tokens

How to use it

Copy the folder

Take ar9av/vault-skill-factory from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.