Wiki
Skill aidehua08/codex-obsdian/plugins/codex-obsdian/skills/wiki
Codex-native full core port of claude-obsidian: Obsidian wiki memory, source ingest, hybrid retrieval, locks, DragonScale utilities, canvas, lint, fold, and skills.
npx -y skills add aidehua08/codex-obsdian --skill wikiAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Initialize, adopt, and route work for a separate Obsidian knowledge vault through the portable claude-obsidian core. Use for vault setup, scaffolding, workspace selection, cross-project configuration, or choosing the correct wiki sub-skill. Triggers: /wiki, set up wiki, scaffold vault, create knowledge base, adopt this vault, Obsidian vault, second brain setup, persistent wiki.
SKILL.md
5.3 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
Wiki orchestration
Treat the installed product as code and the selected user vault as data. Never use the plugin/product root as a vault, even when the current directory happens to be the product checkout.
Resolve the portable core from this skill's installation and invoke it by absolute path:
CORE=/absolute/product/root/scripts/claude-obsidian.py
python3 "$CORE" --help
Resolve a vault in this order: explicit --vault,
CLAUDE_OBSIDIAN_VAULT, the nearest .claude-obsidian.json, then an
unambiguous initialized vault at or above the current directory. Fail closed when
selection is missing or ambiguous.
Baseline setup requires no network egress. Do not fetch templates, plugins, or remote content unless the user separately approves the destinations and budget.
Set up a vault
Use the deterministic setup commands. Both are dry-run by default.
For a new, separate vault:
python3 "$CORE" init /absolute/path/to/vault \
--generated-at <ISO-UTC> --operation-id init-reviewed
python3 "$CORE" init /absolute/path/to/vault \
--generated-at <ISO-UTC> --operation-id init-reviewed \
--approved-plan-sha256 <reviewed-sha256> --apply
For an existing Obsidian vault:
python3 "$CORE" adopt /absolute/path/to/vault \
--generated-at <ISO-UTC> --operation-id adopt-reviewed
python3 "$CORE" adopt /absolute/path/to/vault \
--generated-at <ISO-UTC> --operation-id adopt-reviewed \
--approved-plan-sha256 <reviewed-sha256> --apply
Before --apply, show the selected path and changed-path preview, then pass
the emitted approved_plan_sha256 unchanged. Do not use
--force unless the user has reviewed the conflicts and explicitly approved
replacement. Setup is non-destructive by default and creates no upstream Git
remote.
If the user asks for a domain-specific scaffold, establish the baseline first, then read modes.md. Draft the additional pages and configuration as one operation-level transaction. Never mutate vault files with host Write/Edit tools or an Obsidian transport.
Route operations
Route the user's intent without silently broadening it:
| Intent | Skill |
|---|---|
| Ingest supplied sources | wiki-ingest |
| Answer from existing vault knowledge | wiki-query |
| Save a specific conversation result | save |
| Research the public web under a budget | autoresearch |
| Check vault health | wiki-lint |
| Roll up log entries | wiki-fold |
| Work with a canvas | canvas |
Query is read-only. Persistence from a query must be an explicit, separately scoped Save operation. Never capture a transcript or update the hot cache merely because a session ended.
Mutation contract
Read operation-transactions.md before
any custom scaffold or mutation. One logical operation must produce one inspected
and recoverable claude-obsidian.transaction.v1 bundle. Parallel agents may
return drafts and evidence only; the orchestrator merges them and applies once.
Every canonical page create or removal includes an active index or MOC update
in that bundle; update the overview only when the stable high-level picture
changed. Raw source payloads are create-only. There are no automatic commits.
Use provenance.md when initializing or changing source and claim ledgers. Unsupported evidence stays unsupported; never invent a source, quote, date, locator, or confidence.
After a successful apply, report the operation ID and exact changed paths. If the user explicitly wants a Git checkpoint, run it separately:
python3 "$CORE" checkpoint OPERATION_ID --vault /absolute/path/to/vault
On a conflict, re-read and rebuild. On interruption, use transaction recover.
Reuse an operation ID only with the identical bundle.
Installation context
Read install-modes.md when installation or host behavior matters. Hooks are optional adapters; portable behavior lives in the core and skills.
Conditional references
Read only the reference needed for the current request:
- frontmatter.md when defining or adopting a property schema;
- css-snippets.md for requested Obsidian visual customization;
- git-setup.md for explicit local Git or checkpoint setup;
- plugins.md when evaluating optional Obsidian integrations;
- mcp-setup.md when the user asks to evaluate an external read transport;
- rest-api.md only when the user explicitly has or requests the Local REST API adapter.
Think, verify, grow
Before applying, pause once: observe existing state, verify the vault selection and evidence, then choose the smallest reversible operation that satisfies the request. Afterward, report uncertainty and the next useful improvement without performing it automatically.
Gives 0 of the 12 instructions most project setup skills give in ~1.1k tokens
Counted across 999 of the 1,637 authors here whose files we hold, read 2026-08-07
- ask one question at a timein 29 of 999, across 28 files
- detect the package manager from lockfilesin 28 of 999, across 9 files
- present findings to the userin 26 of 999, across 5 files
- explore current repo statein 24 of 999, across 3 files
- update the agent skills block in place if it existsin 24 of 999, across 3 files
- install husky lint-staged and prettierin 23 of 999, across 4 files
- create the lintstagedrc filein 22 of 999, across 3 files
- commit all changed filesin 22 of 999, across 3 files
- run lint-staged to verify it worksin 22 of 999, across 3 files
- create the husky pre-commit filein 21 of 999, across 2 files
- create a prettierrc file if missingin 21 of 999, across 2 files
- initialize huskyin 21 of 999, across 2 files
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.