obsidian-markdown

Obsidian Flavored Markdown

Use this as a compact fallback for Obsidian-specific syntax. Prefer a separately installed kepano/obsidian-skills obsidian-markdown skill when available, then current Obsidian Help, for detailed or version-sensitive questions.

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"
test -f "$CORE"

Every ../wiki/references/ link in this file resolves the same way, relative to this skill's own directory under $PRODUCT_ROOT, never relative to the selected vault's wiki/ directory.

Answer syntax questions read-only. If the user requests a vault edit, draft the complete note, read operation-transactions.md, and build one claude-obsidian.transaction.v1 bundle with operation_type: markdown and only wiki/ targets. Inspect it, then set APPROVAL_SHA256 to the returned approval_sha256 after review and apply it through the same vault-bound plan. A canonical page create or removal includes an active index or MOC update in that bundle; update the overview only when its stable high-level synthesis changed:

python3 "$CORE" transaction inspect "$BUNDLE" --vault "$VAULT"
python3 "$CORE" transaction apply "$BUNDLE" --vault "$VAULT" \
  --approved-plan-sha256 "$APPROVAL_SHA256"

Never write a note directly.

Properties

Use flat YAML properties and YYYY-MM-DD dates. Quote wikilinks inside YAML.

---
type: concept
title: "Contextual Retrieval"
created: 2026-07-11
updated: 2026-07-11
status: developing
tags:
  - retrieval
  - ai/knowledge
aliases:
  - Context-aware retrieval
related:
  - "[[Retrieval]]"
sources:
  - "[[Anthropic Contextual Retrieval]]"
---

Do not nest objects in generated wiki properties. Use block lists rather than inline YAML arrays. Quote numeric-only tag values, for example - "2026", so YAML parsers preserve them as tags instead of numbers. Keep unknown existing properties unless the requested edit changes them.

Wikilinks and embeds

[[Note Name]]
[[Note Name|Display text]]
[[Note Name#Heading]]
[[Note Name#^block-id]]
[[Folder/Note Name]]

This paragraph is addressable. ^evidence-block

![[Note Name#Summary]]
![[diagram.png|480]]
![[paper.pdf#page=3]]

Match the target filename exactly. Use a vault-relative folder path when a basename is ambiguous. Use standard Markdown links for external URLs; use wikilinks for this vault's notes.

Callouts

> [!note]
> Supporting context.

> [!warning] Review required
> This claim has contradictory evidence.

> [!question]- Open question
> What evidence would resolve this?

- starts collapsed and + starts expanded. Common built-in types include note, abstract, info, todo, tip, success, question, warning, failure, danger, bug, example, and quote. Preserve custom vault callout types rather than rewriting them.

Other Obsidian syntax

#inline-tag #nested/tag

==Highlighted text==

Visible text %%hidden comment%%

Inline math: $E = mc^2$

$$
\int_0^1 x^2\,dx = \frac{1}{3}
$$

```mermaid
flowchart LR
  Source --> Claim
```

Standard CommonMark/GFM headings, lists, tasks, tables, code fences, and footnotes remain valid. Avoid HTML when native Markdown is sufficient.

Validate a drafted note

• Parse the YAML boundary and keep property types consistent.
• Verify every internal target, heading, and block reference that can be checked locally; never fabricate a target to make a link look complete.
• Keep evidence wording distinct from inference and preserve source locators.
• Ensure code fences and callout quoting are balanced.
• Run deterministic wiki lint after a requested mutation and report remaining findings without silently repairing them.

For source-cited pages, also follow provenance.md. Report the transaction operation ID and exact changed paths after an applied edit.