# Obsidian > obsidian — Read, search, create, and edit notes in the Obsidian vault. - **Type:** Skill - **Install:** `agentstack add skill-atlasomnia-donna-starter-obsidian` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [AtlasOmnia](https://agentstack.voostack.com/s/atlasomnia) - **Installs:** 0 - **Category:** [Productivity](https://agentstack.voostack.com/c/productivity) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [AtlasOmnia](https://github.com/AtlasOmnia) - **Source:** https://github.com/AtlasOmnia/donna-starter/tree/main/skills/note-taking/obsidian ## Install ```sh agentstack add skill-atlasomnia-donna-starter-obsidian ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Obsidian Vault Use this skill for filesystem-first Obsidian vault work: reading notes, listing notes, searching note files, creating notes, appending content, and adding wikilinks. ## Vault path Use a known or resolved vault path before calling file tools. The documented vault-path convention is the `OBSIDIAN_VAULT_PATH` environment variable, for example from `~/.hermes/.env`. If it is unset, use `~/Documents/Obsidian Vault`. File tools do not expand shell variables. Do not pass paths containing `$OBSIDIAN_VAULT_PATH` to `read_file`, `write_file`, `patch`, or `search_files`; resolve the vault path first and pass a concrete absolute path. Vault paths may contain spaces, which is another reason to prefer file tools over shell commands. If the vault path is unknown, `terminal` is acceptable for resolving `OBSIDIAN_VAULT_PATH` or checking whether the fallback path exists. Once the path is known, switch back to file tools. ## Read a note Use `read_file` with the resolved absolute path to the note. Prefer this over `cat` because it provides line numbers and pagination. ## List notes Use `search_files` with `target: "files"` and the resolved vault path. Prefer this over `find` or `ls`. - To list all markdown notes, use `pattern: "*.md"` under the vault path. - To list a subfolder, search under that subfolder's absolute path. ## Search Use `search_files` for both filename and content searches. Prefer this over `grep`, `find`, or `ls`. - For filenames, use `search_files` with `target: "files"` and a filename `pattern`. - For note contents, use `search_files` with `target: "content"`, the content regex as `pattern`, and `file_glob: "*.md"` when you want to restrict matches to markdown notes. ## Create a note Use `write_file` with the resolved absolute path and the full markdown content. Prefer this over shell heredocs or `echo` because it avoids shell quoting issues and returns structured results. ## Append to a note Prefer a native file-tool workflow when it is not awkward: - Read the target note with `read_file`. - Use `patch` for an anchored append when there is stable context, such as adding a section after an existing heading or appending before a known trailing block. - Use `write_file` when rewriting the whole note is clearer than constructing a fragile patch. For an anchored append with `patch`, replace the anchor with the anchor plus the new content. For a simple append with no stable context, `terminal` is acceptable if it is the clearest safe option. ## Targeted edits Use `patch` for focused note changes when the current content gives you stable context. Prefer this over shell text rewriting. ## Wikilinks Obsidian links notes with `[[Note Name]]` syntax. When creating notes, use these to link related content. ## Daily wrap-up workflow For evening wrap-up work, follow the exact note structure, carry-forward handling, Todoist integration, monthly index update, and verification pattern below. When you are writing tomorrow's daily note: - Treat the requested structure as a contract; preserve heading order exactly. - Populate carry-forward items from today's incomplete work and Todoist overdue items. - If the note is managed by another process or opens with template scaffolding, verify the on-disk file after writing and again after a brief pause before reporting success. - Prefer an atomic temp-file write + rename when a whole-note rewrite is clearer than incremental edits. When doing the wrap-up itself: - Build tomorrow's note without overwriting today's note. - Follow the requested section order exactly; daily notes are contracts, not freeform summaries. - Pull the carry-forward list from incomplete work and overdue Todoist items, then sort them into the correct task section for tomorrow. - On weekends, omit the entire `### [Work]` section rather than leaving an empty placeholder. - Update the monthly index under the correct `## Weekdays` or `## Weekends` section for tomorrow's actual day. - If the monthly index contains a temporary placeholder or duplicate entry for tomorrow, replace it with the canonical link and remove the placeholder so the index stays clean. - If a write tool warns that the file changed externally, re-read the file from disk before treating the edit as finished. - If a note-tool snapshot still looks stale after a successful atomic rewrite, confirm with a direct filesystem read (`Path.read_text()` + `stat()`) before declaring failure. - For exact-structure notes, prefer a whole-file rewrite over incremental patching when practical, then verify the final on-disk text line-by-line. If a rewrite is needed, use a temp file + atomic rename so the note cannot be left in a half-updated state. - Verify the written note by reading it back before reporting success, and confirm there are no template leftovers such as placeholder bullets or stray `- None (or ...)` text. - For macOS/BSD date math, use `TZ=America/Chicago date -v+1d ...` for tomorrow; GNU `date -d tomorrow` is not portable here. ## Session logs and continuity When a session spans multiple projects, keep a broad **Daily Log** as the top-level continuity note and place project-specific detail in nested notes. - Use the Daily Log for the cross-project summary of what was accomplished, what was learned, and what remains open. - Put each project under its own subheading in the broad log, then link to deeper project notes for detail. - If a project already has its own journal, keep that as the detail layer and link it back to the Daily Log. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [AtlasOmnia](https://github.com/AtlasOmnia) - **Source:** [AtlasOmnia/donna-starter](https://github.com/AtlasOmnia/donna-starter) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** yes - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-atlasomnia-donna-starter-obsidian - Seller: https://agentstack.voostack.com/s/atlasomnia - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.