复制安装命令
用 Codex 或 Claude 安装复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它先审查 Skill 页面再帮你安装。
复制前请先查看来源、License 和安全提示。
Build an Obsidian knowledge base that becomes more useful every time you use it.
用 Codex 或 Claude 安装复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它先审查 Skill 页面再帮你安装。
复制前请先查看来源、License 和安全提示。
来源文件:README.md
Build an Obsidian knowledge base that becomes more useful every time you use it.
Capture sources, create connected notes, retrieve grounded answers, and keep the vault healthy—without giving up ownership of your files.
See the workflow · Quick start · Explore the skills · Installation guide · Windows & WSL
claude-obsidian is a local-first knowledge system for Claude Code and compatible Agent Skills hosts. It turns source material into linked, source-cited Obsidian pages; answers from the evidence already in the vault; and provides explicit workflows for research, retrieval, maintenance, and visual mapping.
Your vault remains a normal directory of Markdown, JSON, and source files. It is not hidden in a plugin cache, locked in a cloud database, or silently uploaded to a model.
Most AI note workflows stop after saving text. claude-obsidian is organized around a repeatable loop: retain the source, ground the claims, connect the knowledge, then put it back to work.
The output is meant to remain useful with or without an agent: plain Markdown for portability, Obsidian for navigation and visual exploration.
Linked knowledge in Graph view · A visual knowledge map in Obsidian Canvas
This is not an automatic transcript recorder, a cloud sync service, a factual oracle, or a substitute for backups and source control.
The safest first run uses a source checkout and a separate user vault. Every mutating setup command previews its exact operation before it can apply.
git clone https://github.com/AgriciDaniel/claude-obsidian.git
cd claude-obsidian
The checkout contains the product. It is not your knowledge vault.
export GENERATED_AT="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
export OPERATION_ID="init-reviewed"
python3 scripts/claude-obsidian.py init "$HOME/Documents/MyKnowledgeVault" \
--generated-at "$GENERATED_AT" --operation-id "$OPERATION_ID"
Review the JSON plan and copy its approved_plan_sha256, then apply that exact
operation:
python3 scripts/claude-obsidian.py init "$HOME/Documents/MyKnowledgeVault" \
--generated-at "$GENERATED_AT" --operation-id "$OPERATION_ID" \
--approved-plan-sha256 "<sha256-from-the-plan>" --apply
For an existing Obsidian vault, use the non-destructive adopt workflow
described in the installation guide.
Open the new directory in Obsidian, then run Claude Code from that directory with the local plugin:
cd "$HOME/Documents/MyKnowledgeVault"
claude --plugin-dir /absolute/path/to/claude-obsidian
Start with:
/claude-obsidian:wiki
Then place a source in inbox/ and invoke
/claude-obsidian:wiki-ingest. Save an answer explicitly with
/claude-obsidian:save; ask the vault with /claude-obsidian:wiki-query.
For Codex, OpenCode, or Gemini, preview and then apply the portable skill links from the product checkout:
bash bin/setup-multi-agent.sh --host codex
bash bin/setup-multi-agent.sh --host codex --apply
Cursor and Windsurf use workspace-local skill discovery. Marketplace setup, every supported host, vault adoption, upgrades, and uninstall steps are covered in the full installation guide.
The skills are small enough to invoke directly and coordinated enough to share the same evidence, vault-selection, and mutation rules.
| Skill | What it does |
|---|---|
wiki | Initializes or adopts a vault, diagnoses readiness, and routes work |
save | Saves one scoped answer or insight—never an automatic transcript |
wiki-ingest | Turns captured sources into linked pages and provenance records |
wiki-query | Answers read-only from relevant vault evidence |
wiki-lint | Reports dead links, orphans, metadata gaps, stale indexes, and empty sections |
| Skill | What it adds |
|---|---|
autoresearch | Bounded web research with explicit egress and a separate canonical merge |
canvas | Wiki-scoped Obsidian Canvas creation and maintenance |
defuddle | Clean, readable web content before ingestion |
wiki-fold | Extractive, traceable rollups of the operation log |
wiki-mode | Generic, LYT, PARA, or Zettelkasten filing conventions |
wiki-retrieve | Contextual prefixes, BM25, and optional cosine reranking |
wiki-cli | Obsidian CLI reads and search with transaction-safe writes |
| Skill | What it provides |
|---|---|
obsidian-markdown | Correct Obsidian Flavored Markdown, links, embeds, and callouts |
obsidian-bases | Native .base tables, cards, filters, formulas, and summaries |
think | A structured observe, listen, connect, create, and grow review loop |
Claude Code exposes namespaced invocations such as
/claude-obsidian:wiki-lint; other hosts use their native Agent Skills
invocation. Trigger phrases and exact contracts live in each
skills/<name>/SKILL.md.
The product never treats a source checkout, plugin cache, or contributor state
as the default vault. A vault is selected explicitly, through
CLAUDE_OBSIDIAN_VAULT, by the nearest .claude-obsidian.json, or by one
unambiguous initialized ancestor. If selection is uncertain, the command exits
without writing.
One logical knowledge operation is one recoverable transaction:
The core holds one process-lifetime vault lock, journals backups, uses atomic replacement, and restores the prior state if an apply cannot finish. A changed target is a conflict, never a silent overwrite. Git checkpoints, destructive repairs, network egress, and canonical research merges remain explicit operations.
Read the transaction contract, provenance contract, and Compound Vault architecture for the machine-facing detail.
| Input or capability | Current support |
|---|---|
| Local filesystem sources | Implemented bounded, content-addressed byte capture |
| Images | Metadata, hash, size, and bounded dimensions when available |
| PDF and EPUB | Metadata, hash, and size; no built-in semantic extraction |
| URL and YouTube | Validated consent plans; a configured external runner is required |
| OCR | Local-file consent plan; a configured external runner is required |
| BM25 retrieval | Local and deterministic |
| Contextual prefixes or remote models | Optional and gated by explicit egress consent |
| Obsidian CLI | Optional for reads/search; filesystem transport remains available |
High-risk accepted claims require two independent sources. Unsupported or contradictory evidence stays visible, and a grounded refusal is preferred over an invented citation. Model-based retrieval falls back to deterministic BM25 when the embedding or reranking stage cannot be trusted.
wiki-mode can route new notes using four methodologies without bulk-moving
existing knowledge:
| Mode | Filing principle |
|---|---|
| Generic | Sources, concepts, entities, and sessions |
| LYT | Maps of Content and linked atomic notes |
| PARA | Projects, Areas, Resources, and Archives |
| Zettelkasten | Stable identifiers, atomic notes, and dense links |
Generic is the default when no mode is configured. Switching modes changes how new notes are routed; it does not silently reorganize old ones. See the methodology modes guide.
The wrapper is python3 scripts/claude-obsidian.py.
| Command | Effect |
|---|---|
doctor --vault PATH | Show vault selection and readiness |
init PATH [--approved-plan-sha256 HASH --apply] | Plan or create a separate vault |
adopt PATH [--approved-plan-sha256 HASH --apply] | Plan or adopt an existing Obsidian vault |
migrate --vault PATH [--approved-plan-sha256 HASH --apply] | Add v1 ledgers and configuration without rewriting legacy data |
transaction inspect BUNDLE --vault PATH | Validate a write bundle without mutation |
transaction apply BUNDLE --vault PATH --approved-plan-sha256 HASH | Apply one inspected, recoverable operation |
transaction recover --vault PATH [--force-stale-lock] | Restore an interrupted operation |
lint --vault PATH [--as-of YYYY-MM-DD] | Emit findings deterministic for the declared UTC date |
contracts --verify --vault PATH | Execute capability readiness contracts |
capture plan --vault PATH [SOURCE ...] | Run a local capture preflight without writes |
capture apply --vault PATH [SOURCE ...] | Plan or create immutable content-addressed copies |
checkpoint OPERATION_ID --vault PATH | Explicitly commit one completed operation |
package validate | Check skills, hooks, manifests, and documentation coherence |
release build --output FILE.zip | Build and self-audit a deterministic public artifact |
release audit FILE.zip | Audit an artifact without extracting or publishing it |
High-level mutating planners emit approved_plan_sha256. Pin
--generated-at and --operation-id, review the JSON operation, and pass that
exact hash with --apply. Filesystem or generated-bundle drift fails before a
vault write.
product repository/ user vault/
├── claude_obsidian/ ├── .gitignore
├── skills/ ├── .claude-obsidian.json
├── hooks/ ├── inbox/
├── scripts/ ├── .raw/
├── templates/vault/ ├── wiki/
├── config/ ├── .obsidian/
├── assets/ └── .vault-meta/ # ignored runtime state
└── tests/
Public artifacts contain product code, deterministic templates, and reviewed README assets. They reject contributor hot/log state, root raw sources, runtime metadata, private paths, recognizable personal email addresses, secrets, symlinks, unsafe archive entries, and unreviewed binaries.
The private development checkout deliberately has no marketplace catalog. The release builder injects the reviewed catalog only into the distribution-clean artifact. A public default branch must be populated from that audited tree, never by pushing contributor-vault state.
Upgrade the product independently from the vault. For an older vault, first preview the additive, idempotent migration:
python3 scripts/claude-obsidian.py migrate --vault /path/to/vault \
--generated-at "$GENERATED_AT" --operation-id migrate-reviewed
Review its hash and rerun with --approved-plan-sha256 HASH --apply.
Migration preserves the legacy raw manifest byte-for-byte and does not infer
claims from prose.
After an interrupted operation, run:
python3 scripts/claude-obsidian.py transaction recover --vault /path/to/vault
Removing the plugin or host links never removes the vault. Delete only the integration you installed; user notes, sources, ledgers, and Obsidian settings remain yours.
CI exercises Linux and macOS, plus a native-Windows smoke job for the portable
surface. On native Windows (including Git Bash), read-only inspection and
dry-run commands work; vault writes require WSL and fail closed with an
UNSUPPORTED_PLATFORM error otherwise. Approval hashes bind to the reviewing
environment, so review inside WSL when the apply will happen there. Platform
details, the support matrix, and WSL troubleshooting (including hangs from
virtualization conflicts) live in the
Windows and WSL guide. The bash setup scripts and shell
test suites remain POSIX-only. Optional tools such as Obsidian CLI, Ollama,
and defuddle are capability-detected and affect only their dependent workflow.
make test
The test target runs every hermetic Python and shell suite, product and capability contracts, skill and hook validation, manifest checks, and package boundaries. CI repeats the suite on supported Linux and macOS/Python combinations and verifies a byte-reproducible release build.
Build and audit locally without publishing:
python3 scripts/claude-obsidian.py release build --output dist/claude-obsidian.zip
python3 scripts/claude-obsidian.py release audit dist/claude-obsidian.zip
No command pushes, tags, publishes, opens issues, or creates releases automatically. See CONTRIBUTING.md, SECURITY.md, and CODE_OF_CONDUCT.md.
The design follows Andrej Karpathy's LLM Wiki pattern and uses kepano/obsidian-skills as the reference substrate for Obsidian Markdown, Bases, and JSON Canvas syntax.
MIT licensed. See ATTRIBUTION.md and CITATION.cff.
name: wiki-mode
description: "Read or configure the vault filing methodology and suggest destinations for planned knowledge creation under Generic, LYT, PARA, or Zettelkasten. Use for wiki mode, methodology mode, what is my vault mode, set vault mode, switch to PARA, use LYT, Zettelkasten setup, change mode, configure mode, or methodology routing. This skill does not save content or migrate notes."This skill returns filing suggestions. It does not write knowledge pages or
move existing notes. If .vault-meta/mode.json is absent, use generic. If
the file exists but is invalid, fail closed and repair it through a reviewed
configuration operation before suggesting routes; never silently substitute
Generic for corrupt user configuration.
Resolve the installed product root from this skill's own location, not from the vault or current working directory:
PRODUCT_ROOT=/absolute/path/to/installed/claude-obsidian
CORE="$PRODUCT_ROOT/scripts/claude-obsidian.py"
MODE_HELPER="$PRODUCT_ROOT/scripts/wiki-mode.py"
test -f "$CORE" && test -f "$MODE_HELPER"
Always select the vault explicitly:
python3 "$MODE_HELPER" --vault "$VAULT" get
python3 "$MODE_HELPER" --vault "$VAULT" config
python3 "$MODE_HELPER" --vault "$VAULT" route concept "Concept name"
python3 "$MODE_HELPER" --vault "$VAULT" route source "Source title"
The helper validates the selected vault, confines paths, sanitizes names, and prints a suggestion only. A calling skill may override the suggestion when the user supplies a more specific project, area, MOC, or parent note, but it must still apply its eventual writes through one operation transaction.
| Mode | Routing intent |
|---|---|
generic | Type-based folders such as sources, entities, concepts, and sessions. |
lyt | Atomic notes under wiki/notes/, connected through MOCs. |
para | Projects, Areas, Resources, or Archives chosen by actionability. |
zettelkasten | Flat atomic notes with time-sortable, collision-resistant identifiers and explicit links. |
Use the templates under templates/ as structural guidance, not authority to
overwrite user conventions.
A mode change is one configuration operation, dry-run first:
Read the current .vault-meta/mode.json, or start from the helper's default
config when it is absent.
Validate the requested mode as exactly generic, lyt, para, or
zettelkasten. Preserve the other mode-specific settings.
Choose and retain a pinned UTC timestamp and operation ID for both commands.
Preview the canonical configuration transaction; the command records the
current target hash and limits the write to .vault-meta/mode.json:
python3 "$CORE" mode set "$MODE" --vault "$VAULT" \
--generated-at "$GENERATED_AT" --operation-id "$OPERATION_ID"
Show the old mode, new mode, exact changed path, and complete preview. Copy
its approved_plan_sha256 only after review.
Apply by regenerating that exact vault-bound plan:
python3 "$CORE" mode set "$MODE" --vault "$VAULT" \
--generated-at "$GENERATED_AT" --operation-id "$OPERATION_ID" \
--approved-plan-sha256 "$APPROVAL_SHA256" --apply
Follow the operation transaction contract.
Do not use scripts/wiki-mode.py's legacy direct-write set action or a setup
script to bypass this workflow.
Changing mode affects routing for future operations only. Never bulk-create folders, move notes, rewrite wikilinks, or migrate existing pages as a side effect. If migration is later requested, plan and review it as a distinct operation with its own hashes and transaction.
Observe the user's current structure, think about how they retrieve and act on notes, verify a few proposed routes before changing configuration, and grow by revisiting the mode only when real filing friction appears.
评论 (0)
暂无评论,成为第一个评论者吧!