Save conversation knowledge, code explanations, research, and decisions to Obsidian as beautifully structured markdown notes. Use this skill whenever the user mentions Obsidian, wants to save/store/export notes to their vault, says 'save to obsidian', 'obsidian init', 'read from obsidian', or wants to persist conversation insights as permanent notes. Also trigger when the user wants to organize knowledge, create reference docs, or archive session work into their personal knowledge base — even if they don't say 'Obsidian' explicitly but have previously initialized a vault.

Obsidian Store

Save conversation knowledge into an Obsidian vault as rich, well-structured markdown that looks great in Obsidian's reading view and is queryable with Dataview.

Three Modes

This skill operates in three modes based on what the user asks:

Trigger	Mode	What happens
"obsidian init", "set up obsidian", "connect obsidian"	Init	Detect Obsidian, locate vault, create `Claude/` folder
"save to obsidian", "store this in obsidian", "export to obsidian"	Save	Write structured markdown note to `Claude/` folder
"read from obsidian", "check obsidian", "load from obsidian"	Read	Read notes from vault, optionally humanize before re-saving

Mode 1: Init

Goal: establish the vault path and ensure the Claude/ folder exists.

Steps

Check Obsidian is installed. Look for the app:
- macOS: check if /Applications/Obsidian.app exists OR run mdfind "kMDItemCFBundleIdentifier == 'md.obsidian'"
- Linux: check which obsidian or snap list obsidian or look in /usr/bin/, /usr/local/bin/, flatpak
- If not found, tell the user Obsidian doesn't appear to be installed and ask if they want to proceed anyway (the vault is just a folder of markdown files — Obsidian itself isn't required to write to it)
Locate the vault. Try auto-detection first:
- macOS: read ~/Library/Application Support/obsidian/obsidian.json — it contains a vaults object mapping vault IDs to {path: "/absolute/path"}
- Linux: read ~/.config/obsidian/obsidian.json — same structure
- If multiple vaults found, present them as a numbered list and ask the user to pick
- If no vaults found or auto-detect fails, ask the user for the vault path directly
Create the Claude folder. Inside the chosen vault:
- Check if a Claude/ folder already exists
- If not, create it: <vault_path>/Claude/
- Also create <vault_path>/Claude/Attachments/ for any images or files

Save the config. Write the vault path to ~/.claude/obsidian-config.json:

{
  "vault_path": "/Users/name/Documents/MyVault",
  "claude_folder": "Claude",
  "initialized": true
}

Confirm to the user. Show what was set up:

Obsidian vault connected:
  Vault: /Users/name/Documents/MyVault
  Notes folder: Claude/
  Ready to save notes.

On subsequent runs

If ~/.claude/obsidian-config.json exists and the vault path is still valid, skip init. If the vault path no longer exists (moved/deleted), re-run init.

Mode 2: Save

Goal: take information from the conversation and write it as a polished Obsidian note.

What to save

Ask the user what they want saved if it's ambiguous. Common patterns:

"save this" — save the most recent substantial output (explanation, code, analysis)
"save our discussion about X" — summarize and save the relevant portion
"save everything" — create a comprehensive session summary
"save this code" — save with code blocks and explanation

Before saving: Humanize the content

Invoke the /humanizer skill on the content before writing it to the vault. The content going into Obsidian should read like something a human wrote — not like an AI response. This is the user's personal knowledge base; the notes should feel like their notes.

Note structure

Every note must follow this structure. Adapt sections based on content type — not every note needs every section, but the frontmatter and title are mandatory.

---
title: <descriptive title>
date: <YYYY-MM-DD>
time: <HH:mm>
type: <see type taxonomy below>
tags:
  - <relevant tags>
status: evergreen
source: claude-conversation
aliases:
  - <short alias if the title is long>
---

# <Title>

> [!abstract] Summary
> <2-3 sentence summary of what this note contains and why it matters>

## <Main content sections — adapt headers to the content>

<Body content goes here. Use the formatting patterns below.>

---

> [!tip] Key Takeaways
> - <Actionable insight 1>
> - <Actionable insight 2>

## Related
- <Links to related concepts, if known>

Type taxonomy

Use these values for the type frontmatter field:

Type	When to use
`explanation`	Concept breakdowns, how-things-work notes
`guide`	Step-by-step instructions, tutorials
`decision`	Architecture decisions, trade-off analysis
`debug`	Bug investigation, root cause analysis
`reference`	API docs, cheat sheets, lookup tables
`research`	Exploration results, comparisons
`code`	Code snippets, implementations with context
`session-summary`	Full conversation summary
`meeting`	Meeting notes (if the conversation was about a meeting)

Tag conventions

Follow nested tag patterns for discoverability:

tags:
  - source/claude
  - topic/<main-topic>        # e.g., topic/authentication, topic/react
  - lang/<language>            # e.g., lang/go, lang/python (if code-related)
  - project/<project-name>    # if tied to a specific project
  - type/<note-type>          # mirrors the type field for Dataview flexibility

Formatting patterns

Use these Obsidian-native features to make notes visually rich:

Callouts for structured information:

> [!info] Context
> Background the reader needs to understand this note.

> [!tip] Best Practice
> Recommended approach with reasoning.

> [!warning] Caveat
> Limitations, gotchas, or things that could go wrong.

> [!example]- Code Example
> Foldable section with code.

> [!question] Open Question
> Something unresolved worth revisiting.

> [!success] What Worked
> Confirmed approach or solution.

> [!failure] What Didn't Work
> Approaches tried and abandoned, with reasons.

Code blocks with language tags:

```go
func main() {
    fmt.Println("always specify the language")
}
```

Mermaid diagrams when the content involves flows, architectures, or relationships:

```mermaid
graph TD
    A[Input] --> B{Decision}
    B -->|Yes| C[Action]
    B -->|No| D[Alternative]
```

Use Mermaid for: architecture diagrams, decision flows, sequence diagrams, state machines, ER diagrams. Don't force diagrams where a list or table is clearer.

Tables for structured comparisons:

| Option | Pros | Cons |
|--------|------|------|
| Option A | Fast, simple | Limited flexibility |
| Option B | Flexible | More complex |

Highlights for key terms: ==important concept==

Task lists for action items:

- [ ] Follow-up task
- [x] Completed item

File naming

Use this pattern: YYYY-MM-DD-<kebab-case-title>.md

Example: 2026-04-11-understanding-go-interfaces.md

This sorts chronologically in the file explorer and avoids naming conflicts.

Saving the file

Read ~/.claude/obsidian-config.json to get the vault path
If config doesn't exist, run Init mode first
Construct the full path: <vault_path>/Claude/<filename>.md
Write the file using the Write tool

Confirm to the user with the file path:

Saved to Obsidian: Claude/2026-04-11-understanding-go-interfaces.md

Mode 3: Read

Goal: load content from the Obsidian vault into the conversation context.

Steps

Read ~/.claude/obsidian-config.json to get the vault path. If missing, run Init first.
Determine what to read based on the user's request:
- "read from obsidian about X" — search for notes matching X in the Claude/ folder
- "read my obsidian notes on X" — search the entire vault (not just Claude/)
- "read <specific file>" — read that exact file
Search strategy:
- Use Glob to find candidate files: <vault_path>/Claude/**/*.md
- Use Grep to search content for the user's topic
- Read frontmatter tags and title fields to find relevant notes
- If multiple matches, present a list and let the user pick
Read and present the selected note(s) to the user. Summarize if the user asked for a summary, or present the full content if they want details.
Humanize before re-saving (when the user wants to update/rewrite a note):
- If the user asks to "clean up" or "rewrite" an Obsidian note, read it, invoke /humanizer on the content, then save it back
- Preserve the original frontmatter (update modified date if present)
- This is specifically for when content in the vault reads like AI output and the user wants it to sound more natural

Important Guidelines

Always humanize before saving. Content in a personal knowledge base should read like the user's own notes. Invoke /humanizer on the body content (not frontmatter) before writing.
Respect vault structure. Only write to the Claude/ folder unless the user explicitly asks otherwise. Never modify notes outside Claude/ without explicit permission.
Preserve existing notes. When saving, check if a file with the same name exists. If so, ask the user whether to overwrite, append, or create a new version.
Keep frontmatter Dataview-friendly. Use consistent field names, ISO dates, and array syntax for tags.
Adapt formatting to content. A quick code snippet doesn't need a Mermaid diagram. A complex architecture discussion does. Match the formatting to what makes the content clearest.
No emoji in frontmatter or tags. Emoji are fine in headers and body text for visual scanning, but keep metadata clean for querying.

obsidian-store

Obsidian Store

Three Modes

Mode 1: Init

Steps

On subsequent runs

Mode 2: Save

What to save

Before saving: Humanize the content

Note structure

Type taxonomy

Tag conventions

Formatting patterns

File naming

Saving the file

Mode 3: Read

Steps

Important Guidelines